SAVI Meeting at IETF 72, Dublin ------------------------------- Monday, July 28, 2008, 17:40-19:50, in Ballroom 1 at the Citywest Hotel. Charter and goals of SAVI WG Christian Vogt and Bill Fenner Christian Vogt introduces the agenda and WG formation. Christian Vogt: 1 why we need SAVI 2 current solution are not sufficient 3 possible solution scopes 4 SAVI goals and requirements 5 challenges 6 deliverables Dave: why broadband solution is in addition to ipv4/IPv6 solutions Jari Arkko: DSL has different technologies may require different solutions. Dave: Need a problem statement Bill: need feedback on what deployment is different. Maybe do it later. Design taxonomy and analysis for SAVI solutions Christian Vogt, Jari Arkko Yoshihiro, Toshiba: address may be updated after the initial validation SAVI source guard Fred Baker, draft-baker-sava-implementation-00 1 for switched LAN 2 for non-switched LAN 3 value of source address versification 4 security consideration Fred Baker: Like what I presented in the BoF, here I am going to show there is one possible solution somebody: which threat to be handled? If somebody spoof with the same MAC and IP, you can't tell where the packet came from. Fred Baker: Looking for adding some other security. Source address validation in first hop local subnet environment Gang Ren, draft-wu-sava-solution-firsthop-eap-01 Erik Nordmark: can it handle the host moving to different port Gang: currently no, but will try to support in the next version. Erik Nordmark, Fred Baker, Jari: Should support more address assign methods. Should consider to minimize the protocol changes. Somebody: too much enquiry, why not using existing protocol to do some functions. Gangļ¼šProtocol changes currently are limited, and will make modification to follow the advices. A CGA based source address authorization and authentication for the first Layer-3 hop Jun Bi, draft-bi-savi-csa-00 Baker, Erick: different user uses different address or same address? Jun: It depends on what existing address assignment method the administrator wants to use. The solution supports both, so it's beyond the mechanism discussion. Fred Baker, Jari: Address rewrite may have problem Jun: not test it yet, will consider it will work or it's wrong. Christian Vogt: in the phase 1, may use SEND directly, without extension. Jun: good suggestion, we are looking to minimize of the protocol extension, will study it. Christian Vogt: Regarding to the host change, it depends on how much it will change. If we really need host change to handle a specific scenario and the change is not too much, then it will be acceptable. SAVI thoughts Erik Nordmark, no draft. Somebody: Track what trust computing group do. Bill Fenner: the direction. Current charter prevent host A using host B's address, do we need to deal with off-link address, etc. Fred Baker: to find the one who is responsible for the address, then need to deal any forged address. Jari: I support to prevent using off-link address, but need to consider what we can do. Somebody: I am curious how much spoofing in the DHCP case (?) Pascal: If can do the validation on multicasting, it would be better. Somebody: only authorized address would be used. Pekka: Assuming router can only use uRPF Somebody: but the granularity is only prefix based, which is not enough. Bill Fenner: the accountability is important. Bill Fenner: thank you for attending, to follow the discussion on the mailing list.