From hiroa-ha at is.naist.jp Tue Dec 4 07:06:36 2007 From: hiroa-ha at is.naist.jp (hiroa-ha) Date: Tue, 04 Dec 2007 08:06:36 +0900 Subject: [SAVA] SAVI Dinner: Tuesday, Dec. 4, 20:15 @ Registration Desk In-Reply-To: <474DF27E.4030404@nomadiclab.com> References: <474DF27E.4030404@nomadiclab.com> Message-ID: <47548BFC.3040008@is.naist.jp> I'm Hiroaki Hazeyama from NAIST, Japan. I'd like to join SAVI dinner. Thanks, ---- Hiroaki Hazeyama Ph.D of Engineering Nara Institue of Science and Technology. Christian Vogt wrote: > Folks, > > let's have a SAVI dinner on Tuesday, December 4, and meet at 20:15 at > the registration desk. > > Dinner on Tuesday is the clear winner according to our Doodle poll. > > Looking forward to seeing you! > > - Christian > > > _______________________________________________ > SAVA mailing list > SAVA at mail.nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava From ayinhan at huawei.com Tue Dec 4 07:46:36 2007 From: ayinhan at huawei.com (Han Yin) Date: Mon, 03 Dec 2007 15:46:36 -0800 Subject: [SAVA] SAVI Dinner? References: <474C3ECF.5080509@nomadiclab.com> Message-ID: <200712031546345257434@huawei.com> I 'd like to join the dinner. Thanks ------------------ Han Yin Huawei Technologies 2007-12-03 ------------------------------------------------------------- ????Christian Vogt ?????2007-11-28 00:01:46 ????SAVA Mailing List ??? ???[SAVA] SAVI Dinner? Folks, are you interested in a "SAVI dinner"? How about Wednesday after the IESG/IAOC plenary? - Danny and Christian _______________________________________________ SAVA mailing list SAVA at mail.nrc.tsinghua.edu.cn http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava From fred at cisco.com Wed Dec 5 09:00:14 2007 From: fred at cisco.com (Fred Baker) Date: Tue, 4 Dec 2007 17:00:14 -0800 Subject: [SAVA] Fwd: IPR Statement RE: draft-baker-sava-implementation-00 References: <200712050003.lB503Iu18209@tarkin.cisco.com> Message-ID: <1FD191BD-F5F2-4E39-BDA6-B66068B47930@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Begin forwarded message: > From: Mary Shannon > Date: December 4, 2007 4:03:18 PM PST > To: ietf-ipr at ietf.org > Cc: fred at cisco.com > Subject: IPR Statement RE: draft-baker-sava-implementation-00 > Reply-To: mashanno at cisco.com > > Cisco is the owner of US Patent Application Serial Numbers > 10/654,388 and 10/971,523 relating to the subject matter of "Source > address validation in the local environment" implementation-00>. > > If technology in this document is included in a standard adopted by > IETF and any claims of any Cisco patents are necessary for > practicing the standard, any party will have the right to use any > such patent claims under reasonable, non-discriminatory terms, with > reciprocity, to implement and fully comply with the standard. > > The reasonable non-discriminatory terms are: > > If this standard is adopted, Cisco will not assert any patents > owned or controlled by Cisco against any party for making, using, > selling, importing or offering for sale a product that implements > the standard, provided, however that Cisco retains the right to > assert its patents (including the right to claim past royalties) > against any party that asserts a patent it owns or controls (either > directly or indirectly) against Cisco or any of Cisco's affiliates > or successors in title or against any products of Cisco or any > products of any of Cisco's affiliates either alone or in > combination with other products; and Cisco retains the right to > assert its patents against any product or portion thereof that is > not necessary for compliance with the standard. > > Royalty-bearing licenses will be available to anyone who prefers > that option. > > For information contact: > > Dan Lang > Director, Patents and Standards IPR > Cisco Systems > +1 408-526-6672 > standards-ipr at cisco.com -----BEGIN PGP SIGNATURE----- iD8DBQFHVfgebjEdbHIsm0MRAuvBAKDtLsmSZKMzD6efeaEVNm3iAVlj+ACeOHuy hX+cTOImkSoS4je5mJMgfmk= =FYqN -----END PGP SIGNATURE----- From christian.vogt at nomadiclab.com Wed Dec 5 15:40:20 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Tue, 04 Dec 2007 23:40:20 -0800 Subject: [SAVA] Charter Proposal To Be Discussed at BoF Message-ID: <475655E4.8080805@nomadiclab.com> Folks, below is a copy of the charter proposal that we are going to discuss in tomorrow's SAVI BoF. This is the same charter proposal that has been discussed on this mailing list, and that was sent by Jari on Oct. 24, modulo some updated milestones. CU tomorrow, - Christian Source Address Validation Improvements (SAVI) While the MIT Spoofer project has measured that about 75% of networks deploy ingress filtering, ingress filtering at a finer granularity is not yet as common. A number of proprietary mechanisms exist (e.g., "IP source guard") which offer partial solutions to prevent hosts from spoofing the source address of another host in the same subnet. The purpose of the proposed "Source Address Validation Improvements" working group is to standardize mechanisms to prevent source address spoofing in the access network. Specifically, the group shall define solutions such that hosts attached to the same router cannot spoof each other's addresses. The following assumptions apply: - The WG considers only solutions on layer 3 aware Ethernet switches. - Two solutions are needed, one for IPv4 and another one for IPv6 - The IPv4 solution depends on tracking the DHCP traffic on a port. - The IPv6 solution depends on tracking the ND and DHCP traffic on a port. - All address assignment mechanisms in IPv6 need to be supported, including stateless, stateful, privacy, and so on. - The solutions are turned on for on host ports by configuration, and do not apply to routers. The WG recognizes anti-spoofing deployment efforts, motivation, and best practices development in various forums around the world (including RIPE). The WG is only chartered to deliver two specific solution components that such efforts could employ. The bigger questions are out of scope. Milestones: Done First draft on IPv4 solution Done First draft on IPv6 solution Done BOF decision Dec 07 BOF in IETF-70 Jan 08 WG approval Feb 08 First WG draft on IPv4 solution Apr 08 First WG draft on IPv6 solution Jun 08 Submit IPv4 solution to IESG for Proposed Standard Dec 08 Submit IPv6 solution to IESG for Proposed Standard From fergdawg at netzero.net Wed Dec 5 15:46:32 2007 From: fergdawg at netzero.net (Paul Ferguson) Date: Wed, 5 Dec 2007 07:46:32 GMT Subject: [SAVA] Charter Proposal To Be Discussed at BoF Message-ID: <20071204.234632.17255.3@webmail11.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Christian Vogt wrote: > - The IPv4 solution depends on tracking the DHCP traffic on a port. First, let me say that I'm sorry that I cannot be in attendance for the BoF. My "day job" issues at the moment, unfortunately, prohibit the luxury of being there. Second, I'm a little concerned about the scope of the IPv4 SAVI "solution" as described in the above BoF agenda item. Now, I've been following the mailing list traffic, and perhaps I missed something, but I'm a little unclear on why the focus of the IPv4 SAVI "solution" is so centrally bound to DHCP? This seems like a monumental mistake to me. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHVldVq1pz9mNUZTMRAjffAJsEJwz9hoV1hXwO1GWUoz70KmpJkACfbPQ+ 1Krn+gOMZ2jG++i0VzFpeGw= =dwWn -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ From miw at computer.org Wed Dec 5 17:00:42 2007 From: miw at computer.org (Mark Williams) Date: Wed, 05 Dec 2007 17:00:42 +0800 Subject: [SAVA] Charter Proposal To Be Discussed at BoF In-Reply-To: <20071204.234632.17255.3@webmail11.vgs.untd.com> References: <20071204.234632.17255.3@webmail11.vgs.untd.com> Message-ID: <475668BA.6000505@computer.org> I tend to agree on the last point. I mean, having a solution tied to DHCP is important, but actually there needs to be solutions for all methods of IP address provisioning. cheers, Mark Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > - -- Christian Vogt wrote: > > >> - The IPv4 solution depends on tracking the DHCP traffic on a port. >> > > First, let me say that I'm sorry that I cannot be in attendance for > the BoF. > > My "day job" issues at the moment, unfortunately, prohibit the > luxury of being there. > > Second, I'm a little concerned about the scope of the IPv4 SAVI > "solution" as described in the above BoF agenda item. > > Now, I've been following the mailing list traffic, and perhaps > I missed something, but I'm a little unclear on why the focus > of the IPv4 SAVI "solution" is so centrally bound to DHCP? > > This seems like a monumental mistake to me. > > - - ferg > > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.6.3 (Build 3017) > > wj8DBQFHVldVq1pz9mNUZTMRAjffAJsEJwz9hoV1hXwO1GWUoz70KmpJkACfbPQ+ > 1Krn+gOMZ2jG++i0VzFpeGw= > =dwWn > -----END PGP SIGNATURE----- > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawg(at)netzero.net > ferg's tech blog: http://fergdawg.blogspot.com/ > > > _______________________________________________ > SAVA mailing list > SAVA at mail.nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > > From jari.arkko at piuha.net Wed Dec 5 17:22:03 2007 From: jari.arkko at piuha.net (Jari Arkko) Date: Wed, 05 Dec 2007 01:22:03 -0800 Subject: [SAVA] Charter Proposal To Be Discussed at BoF In-Reply-To: <475668BA.6000505@computer.org> References: <20071204.234632.17255.3@webmail11.vgs.untd.com> <475668BA.6000505@computer.org> Message-ID: <47566DBB.5080002@piuha.net> > I mean, having a solution tied to DHCP is important, but actually there > needs to be solutions for all methods of IP address provisioning. Its late so I'm probably missing something. But which methods are you talking about? Jari From fergdawg at netzero.net Wed Dec 5 23:33:47 2007 From: fergdawg at netzero.net (Paul Ferguson) Date: Wed, 5 Dec 2007 15:33:47 GMT Subject: [SAVA] Charter Proposal To Be Discussed at BoF Message-ID: <20071205.073347.13846.0@webmail15.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Jari Arkko wrote: >> I mean, having a solution tied to DHCP is important, but actually there >> needs to be solutions for all methods of IP address provisioning. > >Its late so I'm probably missing something. But which methods are you >talking about? > Hi Jari, It's early, and I haven't even had my first cup of coffee yet, but I'll take a stab at this. First, it would appear to me that by binding SAVI to DHCP (for IPv4), that would (seem to imply, at least to me) that we're talking about host-based source validation -- which cannot be trusted. My impression that the most critical place to do validation is at the (IP) first-hop -- and I'm unclear here where & how DHCP plays into this. A RFC2827/BCP38 -style validation could easily be done there, based on either loose (prefix) or strict (MAC) enforcement. At least that is how I always envisioned SAVI/SAVA being done for first-hop. Perhaps I missed a document revision somewhere, or missed as consensus somehow, so perhaps if someone could explain to me how DHCP comes into this equation (or point me to specific document paragraph), I'd be happy to acquiesce. Also, I'm a little concerned about statically addressed hosts on a segment (which in a data center or hosting provider will be a very high percentage) because of ARP spoofing issues. Thanks, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHVsTGq1pz9mNUZTMRAsLGAJ9yH51qyTzWwIJE3x5NZkQVDODodwCfcxZ3 MDSOIC4ndoNGgwsUVxivqAY= =012K -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _____________________________________________________________ Click to make millions by owning your own franchise. http://thirdpartyoffers.netzero.net/TGL2221/fc/Ioyw6i4t12iipMvzfVDd88l1eAWtEuza4xFeW6dtXR5xFNhwNwXSyx/ From fergdawg at netzero.net Wed Dec 5 23:44:14 2007 From: fergdawg at netzero.net (Paul Ferguson) Date: Wed, 5 Dec 2007 15:44:14 GMT Subject: [SAVA] Charter Proposal To Be Discussed at BoF Message-ID: <20071205.074414.13846.1@webmail15.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- "Paul Ferguson" wrote: >Also, I'm a little concerned about statically addressed hosts on >a segment (which in a data center or hosting provider will be a >very high percentage) because of ARP spoofing issues. Actually, strike that part about ARP spoofing (although it's still a concern, it is not appropriate in this context), but keep the concerned note of statically assigned host addresses. (I told you I hadn't had any coffee yet.... :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHVsdLq1pz9mNUZTMRAuI9AKDLY3S+AWQtehLjHKWiSmP7RVbdZQCdHUOY Kgo5fxz5bh0Wb9T1ChFbbts= =1CG9 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _____________________________________________________________ Digital Photography - Click Now. http://thirdpartyoffers.netzero.net/TGL2221/fc/Ioyw6i4sv56rNcFzx7UHFzwherj3RAj67U05lkL1BCOPlVMG4aBwt7/ From fred at cisco.com Wed Dec 5 23:59:24 2007 From: fred at cisco.com (Fred Baker) Date: Wed, 5 Dec 2007 07:59:24 -0800 Subject: [SAVA] Charter Proposal To Be Discussed at BoF In-Reply-To: <20071205.073347.13846.0@webmail15.vgs.untd.com> References: <20071205.073347.13846.0@webmail15.vgs.untd.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Dec 5, 2007, at 3:33 PM, Paul Ferguson wrote: > First, it would appear to me that by binding SAVI to DHCP (for > IPv4), that would (seem to imply, at least to me) that we're talking > about host-based source validation -- which cannot be trusted. Cisco and Foundry's IP Source Guard features depend on DHCP snooping in the switch. > My impression that the most critical place to do validation is > at the (IP) first-hop -- and I'm unclear here where & how DHCP plays > into this. it tells you what to validate against. You know what the host is authorized to use. > Also, I'm a little concerned about statically addressed hosts on > a segment (which in a data center or hosting provider will be a > very high percentage) because of ARP spoofing issues. If someone is willing to manually configure a host, it is not unlikely that they can manually configure the filter as well. The question is "how do you know what the host SHOULD say and discard datagrams that say something else" -----BEGIN PGP SIGNATURE----- iD8DBQFHVsrcbjEdbHIsm0MRAh4oAKDtQTGoB/UBopho3Rn6bLzUR34OdgCgmee+ WmA9nlZxHsnJlGpJLj8Vuws= =NzWy -----END PGP SIGNATURE----- From fred at cisco.com Thu Dec 6 00:05:55 2007 From: fred at cisco.com (Fred Baker) Date: Wed, 5 Dec 2007 08:05:55 -0800 Subject: [SAVA] Charter Proposal To Be Discussed at BoF In-Reply-To: <475655E4.8080805@nomadiclab.com> References: <475655E4.8080805@nomadiclab.com> Message-ID: <22EEAFB0-B5BE-4DFE-A3BA-FFE90C99CEA9@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 comments inline On Dec 4, 2007, at 11:40 PM, Christian Vogt wrote: > Source Address Validation Improvements (SAVI) > > While the MIT Spoofer project has measured that about 75% of networks > deploy ingress filtering, ingress filtering at a finer granularity is > not yet as common. A number of proprietary mechanisms exist (e.g., > "IP > source guard") which offer partial solutions to prevent hosts from > spoofing the source address of another host in the same subnet. The > purpose of the proposed "Source Address Validation Improvements" > working > group is to standardize mechanisms to prevent source address > spoofing in > the access network. > > Specifically, the group shall define solutions such that hosts > attached > to the same router cannot spoof each other's addresses. The following > assumptions apply: > > - The WG considers only solutions on layer 3 aware Ethernet switches. I would also suggest that we develop tools for switchless (wireless, dumb switch, etc) environments. > - Two solutions are needed, one for IPv4 and another one for IPv6 query: to what degree is an IPv4 solution a special case of an IPv6 solution, as far as algorithms go? For example, having solved the multiple address problem for v6, restricting to one address in v4 makes sense. > - The IPv4 solution depends on tracking the DHCP traffic on a port. or manual configuration > - The IPv6 solution depends on tracking the ND and DHCP traffic on a > port. what I proposed actually doesn't use DHCP - you need a solution for SAA as well. It turns out that once the address is configured, whether auto or dhcp, it has to be exchanged. You only need ND. You could, though, additionally watch DHCP as an authorization approach. > - All address assignment mechanisms in IPv6 need to be supported, > including stateless, stateful, privacy, and so on. > - The solutions are turned on for on host ports by configuration, and > do not apply to routers. you might say that it cannot protect against routers. I first read this as saying "hosts and routers need not be changed", and that is only true in the switched solution; switchless environments call for host and router changes as they are the only systems there. > The WG recognizes anti-spoofing deployment efforts, motivation, and > best > practices development in various forums around the world (including > RIPE). The WG is only chartered to deliver two specific solution > components that such efforts could employ. The bigger questions are > out > of scope. Too narrow. Include wireless network solutions. -----BEGIN PGP SIGNATURE----- iD8DBQFHVsxjbjEdbHIsm0MRAgLQAKCVxcTRnSGXjjmlAzHMSkNx3QLnjwCfdfsP sDoYRRfof8J2AYKPoX/YMW4= =r2eX -----END PGP SIGNATURE----- From junbi at cernet.edu.cn Thu Dec 6 01:11:06 2007 From: junbi at cernet.edu.cn (Jun Bi) Date: Thu, 6 Dec 2007 01:11:06 +0800 Subject: [SAVA] Charter Proposal To Be Discussed at BoF In-Reply-To: <22EEAFB0-B5BE-4DFE-A3BA-FFE90C99CEA9@cisco.com> References: <475655E4.8080805@nomadiclab.com> <22EEAFB0-B5BE-4DFE-A3BA-FFE90C99CEA9@cisco.com> Message-ID: ----- Original Message ----- From: "Fred Baker" >> >> - The WG considers only solutions on layer 3 aware Ethernet switches. > > I would also suggest that we develop tools for switchless (wireless, > dumb switch, etc) environments. Agree. Multiple solutions for operators would be good, because a operator could chose the best he can deploy for his situation. > > you might say that it cannot protect against routers. I first read > this as saying "hosts and routers need not be changed", and that is > only true in the switched solution; switchless environments call for > host and router changes as they are the only systems there. Agree, different environment may require different solution (e.g. for the switchless environment as Fred mentioned, or for a situation that the network administrator can't fully upgrade switches in a big campus network). Thanks, Jun Bi From jari.arkko at piuha.net Thu Dec 6 02:03:40 2007 From: jari.arkko at piuha.net (Jari Arkko) Date: Wed, 05 Dec 2007 10:03:40 -0800 Subject: [SAVA] Charter Proposal To Be Discussed at BoF In-Reply-To: <22EEAFB0-B5BE-4DFE-A3BA-FFE90C99CEA9@cisco.com> References: <475655E4.8080805@nomadiclab.com> <22EEAFB0-B5BE-4DFE-A3BA-FFE90C99CEA9@cisco.com> Message-ID: <4756E7FC.4070503@piuha.net> Lets be careful with those calls for extending the scope. I think I understand what we need to do technically in the switch case. I'm not sure I do in other cases. Perhaps you can educate me and if the support for the other cases falls nicely within the same behaviour for an implementation, maybe we can extend the scope. Otherwise, do the simple thing first and recharter/extend later for other cases. Jari From bgreene at cisco.com Thu Dec 6 02:22:52 2007 From: bgreene at cisco.com (Barry Greene (bgreene)) Date: Wed, 5 Dec 2007 10:22:52 -0800 Subject: [SAVA] Charter Proposal To Be Discussed at BoF In-Reply-To: <475655E4.8080805@nomadiclab.com> References: <475655E4.8080805@nomadiclab.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Change: "The purpose of the proposed "Source Address Validation Improvements" working group is to standardize mechanisms to prevent source address spoofing in the access network." To: "The purpose of the proposed "Source Address Validation Improvements" working group is to update practices, document experience with existing technology, document all existing practices and limitations, and develop potential new mechanisms which would allow a broad anti-source spoof capabilities." The language focused on "IP source address" needs to be expanded to any source spoof. IP address, MAC, DSCP, protocol type, etc. etc. all need to be included. > -----Original Message----- > From: sava-bounces at mail.nrc.tsinghua.edu.cn > [mailto:sava-bounces at mail.nrc.tsinghua.edu.cn] On Behalf Of > Christian Vogt > Sent: Tuesday, December 04, 2007 11:40 PM > To: SAVA Mailing List > Subject: [SAVA] Charter Proposal To Be Discussed at BoF > > Folks, > > below is a copy of the charter proposal that we are going to > discuss in tomorrow's SAVI BoF. This is the same charter > proposal that has been discussed on this mailing list, and > that was sent by Jari on Oct. 24, modulo some updated milestones. > > CU tomorrow, > - Christian > > > Source Address Validation Improvements (SAVI) > > While the MIT Spoofer project has measured that about 75% of > networks deploy ingress filtering, ingress filtering at a > finer granularity is not yet as common. A number of > proprietary mechanisms exist (e.g., "IP source guard") which > offer partial solutions to prevent hosts from spoofing the > source address of another host in the same subnet. The > purpose of the proposed "Source Address Validation > Improvements" working group is to standardize mechanisms to > prevent source address spoofing in the access network. > > Specifically, the group shall define solutions such that > hosts attached to the same router cannot spoof each other's > addresses. The following assumptions apply: > > - The WG considers only solutions on layer 3 aware Ethernet > switches. - Two solutions are needed, one for IPv4 and another one > for IPv6 > - The IPv4 solution depends on tracking the DHCP traffic on a port. > - The IPv6 solution depends on tracking the ND and DHCP traffic on > a > port. > - All address assignment mechanisms in IPv6 need to be supported, > including stateless, stateful, privacy, and so on. > - The solutions are turned on for on host ports by configuration, > and > do not apply to routers. > > The WG recognizes anti-spoofing deployment efforts, > motivation, and best practices development in various forums > around the world (including RIPE). The WG is only chartered > to deliver two specific solution components that such efforts > could employ. The bigger questions are out of scope. > > Milestones: > > Done First draft on IPv4 solution > Done First draft on IPv6 solution > Done BOF decision > Dec 07 BOF in IETF-70 > Jan 08 WG approval > Feb 08 First WG draft on IPv4 solution > Apr 08 First WG draft on IPv6 solution > Jun 08 Submit IPv4 solution to IESG for Proposed Standard > Dec 08 Submit IPv6 solution to IESG for Proposed Standard > > > _______________________________________________ > SAVA mailing list > SAVA at mail.nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBR1bsfL/UEA/xivvmEQKBGQCg4ldhWAX4dsg9W1U1LkSCqGcflOwAnR89 oCCV/KHkevmrLpQl7/0mqI9h =9tzx -----END PGP SIGNATURE----- From bgreene at cisco.com Thu Dec 6 02:40:25 2007 From: bgreene at cisco.com (Barry Greene (bgreene)) Date: Wed, 5 Dec 2007 10:40:25 -0800 Subject: [SAVA] Charter Proposal To Be Discussed at BoF In-Reply-To: <4756E7FC.4070503@piuha.net> References: <475655E4.8080805@nomadiclab.com><22EEAFB0-B5BE-4DFE-A3BA-FFE90C99CEA9@cisco.com> <4756E7FC.4070503@piuha.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Reminder - goals for today. We have the BCP - 38 - which says what we need to accomplish. We have lots of tools to implement BCP 38. We have enough experience with this implementation to know that you CANNOT have one solution that would work everywhere. So, to really get new IETF work, we need to look at what beyond BCP 38 we are going to accomplish. -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBR1bwmb/UEA/xivvmEQKTXgCgggkTF7zkjbCr0CWkc4cwmL4+2V8AoMc0 +maD3U4rgo4Te/DeE7sQLJYo =8cvo -----END PGP SIGNATURE----- From fred at cisco.com Thu Dec 6 05:35:07 2007 From: fred at cisco.com (Fred Baker) Date: Wed, 5 Dec 2007 13:35:07 -0800 Subject: [SAVA] Charter Proposal To Be Discussed at BoF In-Reply-To: <4756E7FC.4070503@piuha.net> References: <475655E4.8080805@nomadiclab.com> <22EEAFB0-B5BE-4DFE-A3BA-FFE90C99CEA9@cisco.com> <4756E7FC.4070503@piuha.net> Message-ID: <0DCA3CB3-0BDF-4302-85CA-E72FFB89BA0B@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 for the record, the draft and presentation I will be discussing this afternoon covers all of these cases including unicast rpf. I'm not sure I see the point of the discussion if we're going to hamstring its utility. On Dec 5, 2007, at 10:03 AM, Jari Arkko wrote: > Lets be careful with those calls for extending the scope. I think I > understand what we need to do technically in the switch case. I'm not > sure I do in other cases. Perhaps you can educate me and if the > support > for the other cases falls nicely within the same behaviour for an > implementation, maybe we can extend the scope. Otherwise, do the > simple > thing first and recharter/extend later for other cases. > > Jari -----BEGIN PGP SIGNATURE----- iD8DBQFHVxmMbjEdbHIsm0MRAuavAJ9ThO7LsoBIMl0rSR7ilRb9/vEYHgCg6odp yf2/vfxzeSTWOMxcK9lGYHs= =6ffO -----END PGP SIGNATURE----- From miw at juniper.net Thu Dec 6 05:47:36 2007 From: miw at juniper.net (Mark Williams) Date: Thu, 06 Dec 2007 05:47:36 +0800 Subject: [SAVA] Charter Proposal To Be Discussed at BoF In-Reply-To: <47566DBB.5080002@piuha.net> References: <20071204.234632.17255.3@webmail11.vgs.untd.com> <475668BA.6000505@computer.org> <47566DBB.5080002@piuha.net> Message-ID: <47571C78.1020902@juniper.net> Static address assignment springs immediately to mind. I know it's a trivial case, but it's important. (To tell the truth I thought there were other ways a host could get a dynamic IP address besides DHCP, but I can't find evidence of any in normal use today based on a quick search.) cheers, Mark Jari Arkko wrote: >> I mean, having a solution tied to DHCP is important, but actually there >> needs to be solutions for all methods of IP address provisioning. >> > > Its late so I'm probably missing something. But which methods are you > talking about? > > Jari > > > _______________________________________________ > SAVA mailing list > SAVA at mail.nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > > -- "Product roadmap and/or product discussion in this email set forth Juniper Networks' current intention and is subject to change at any time without notice. No purchases are contingent upon Juniper Networks delivering any feature or functionality expressed or implied in this roadmap or product discussion." ----------------------------------------------------------------- Mark Williams Juniper Networks Liaison Beijing Office Academic Networking Sector Tel: +86 10 6528 8800 x16032 Asia Pacific FAX: +61 7 3251 0155 miw at juniper.net Cell: +86 1370-111-4749 From bgreene at cisco.com Thu Dec 6 05:53:39 2007 From: bgreene at cisco.com (Barry Greene (bgreene)) Date: Wed, 5 Dec 2007 13:53:39 -0800 Subject: [SAVA] Charter Proposal To Be Discussed at BoF In-Reply-To: <47571C78.1020902@juniper.net> References: <20071204.234632.17255.3@webmail11.vgs.untd.com> <475668BA.6000505@computer.org><47566DBB.5080002@piuha.net> <47571C78.1020902@juniper.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > (To tell the truth I thought there were other ways a host > could get a dynamic IP address besides DHCP, but I can't find > evidence of any in normal use today based on a quick search.) Dynamic IP Addressing: 1. AAA (Radius, TACACS+, Kerberos, and Diameter) 2. DHCP 3. PPP with address ranges configured on the network gear (pre DHCP) There are a couple of other techniques - LAT (DEC), Banyan, and other really old technologies had dynamic IP address allocation features. DHCP is the body of work that standardized this patch work. -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBR1cd47/UEA/xivvmEQLfpwCgv4bHSpNXDcufBnUiAvsHWUjYO1oAnilW fiRkiTeWh2CZX01FPLnIOsl1 =R9hy -----END PGP SIGNATURE----- From christian.vogt at nomadiclab.com Thu Dec 6 06:35:34 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Wed, 05 Dec 2007 14:35:34 -0800 Subject: [SAVA] Charter Proposal To Be Discussed at BoF In-Reply-To: <475655E4.8080805@nomadiclab.com> References: <475655E4.8080805@nomadiclab.com> Message-ID: <475727B6.9020504@nomadiclab.com> Folks, please bring up your comments during the microphone discussion. We will base the discussion on the charter below for now, and evolve from there. - Danny and Christian Christian Vogt wrote: > Folks, > > below is a copy of the charter proposal that we are going to discuss in > tomorrow's SAVI BoF. This is the same charter proposal that has been > discussed on this mailing list, and that was sent by Jari on Oct. 24, > modulo some updated milestones. > > CU tomorrow, > - Christian > > > Source Address Validation Improvements (SAVI) > > While the MIT Spoofer project has measured that about 75% of networks > deploy ingress filtering, ingress filtering at a finer granularity is > not yet as common. A number of proprietary mechanisms exist (e.g., "IP > source guard") which offer partial solutions to prevent hosts from > spoofing the source address of another host in the same subnet. The > purpose of the proposed "Source Address Validation Improvements" working > group is to standardize mechanisms to prevent source address spoofing in > the access network. > > Specifically, the group shall define solutions such that hosts attached > to the same router cannot spoof each other's addresses. The following > assumptions apply: > > - The WG considers only solutions on layer 3 aware Ethernet switches. > - Two solutions are needed, one for IPv4 and another one for IPv6 > - The IPv4 solution depends on tracking the DHCP traffic on a port. > - The IPv6 solution depends on tracking the ND and DHCP traffic on a > port. > - All address assignment mechanisms in IPv6 need to be supported, > including stateless, stateful, privacy, and so on. > - The solutions are turned on for on host ports by configuration, and > do not apply to routers. > > The WG recognizes anti-spoofing deployment efforts, motivation, and best > practices development in various forums around the world (including > RIPE). The WG is only chartered to deliver two specific solution > components that such efforts could employ. The bigger questions are out > of scope. > > Milestones: > > Done First draft on IPv4 solution > Done First draft on IPv6 solution > Done BOF decision > Dec 07 BOF in IETF-70 > Jan 08 WG approval > Feb 08 First WG draft on IPv4 solution > Apr 08 First WG draft on IPv6 solution > Jun 08 Submit IPv4 solution to IESG for Proposed Standard > Dec 08 Submit IPv6 solution to IESG for Proposed Standard From christian.vogt at nomadiclab.com Thu Dec 6 10:45:06 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Wed, 05 Dec 2007 18:45:06 -0800 Subject: [SAVA] Thanks to Note Takers! Message-ID: <47576232.6070103@nomadiclab.com> We would like to thank our note takers in today's SAVI BoF: Behcet Sarikaya Ralph Droms Mark Williams Mikko S?rel? Best regards, - Danny and Christian From pekkas at netcore.fi Thu Dec 6 13:42:31 2007 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 6 Dec 2007 07:42:31 +0200 (EET) Subject: [SAVA] Charter Proposal To Be Discussed at BoF In-Reply-To: References: <20071204.234632.17255.3@webmail11.vgs.untd.com> <475668BA.6000505@computer.org><47566DBB.5080002@piuha.net> <47571C78.1020902@juniper.net> Message-ID: On Wed, 5 Dec 2007, Barry Greene (bgreene) wrote: > 1. AAA (Radius, TACACS+, Kerberos, and Diameter) > 2. DHCP > 3. PPP with address ranges configured on the network gear (pre DHCP) + IKE. Not sure if I understand how AAA in and of itself can provide addresses? Isn't it used in conjunction with PPP or DHCP? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From fergdawg at netzero.net Thu Dec 6 13:57:48 2007 From: fergdawg at netzero.net (Paul Ferguson) Date: Thu, 6 Dec 2007 05:57:48 GMT Subject: [SAVA] Charter Proposal To Be Discussed at BoF Message-ID: <20071205.215748.13245.2@webmail09.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Pekka Savola wrote: >On Wed, 5 Dec 2007, Barry Greene (bgreene) wrote: >> 1. AAA (Radius, TACACS+, Kerberos, and Diameter) >> 2. DHCP >> 3. PPP with address ranges configured on the network gear (pre DHCP) > >+ IKE. > >Not sure if I understand how AAA in and of itself can provide addresses? Isn't it used in conjunction with PPP or DHCP? > Yes. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHV49Zq1pz9mNUZTMRAkulAKD71Os0BJt85N6OpNUzS8zb6hD2TwCgs9is ZRNupZoxG9kcXYZkvJym1kA= =feUH -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _____________________________________________________________ Free information - Easy Relocation Services. Click now! http://thirdpartyoffers.netzero.net/TGL2221/fc/Ioyw6i4tUOc1CmBPlInCLbd0ZZsWQtNYL6uEP0cbUC8hM5GXHUEKK3/ From fred at cisco.com Wed Dec 12 06:18:16 2007 From: fred at cisco.com (Fred Baker) Date: Tue, 11 Dec 2007 14:18:16 -0800 Subject: [SAVA] Review of draft-baker-sava-implementation-00 In-Reply-To: <474724DD.4050202@nomadiclab.com> References: <474724DD.4050202@nomadiclab.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So I'm thinking about your comments. It comes down to - you want the document completely rewritten in a different order and in a different style. How badly do you want that? I might be of the opinion that you should write it. If we can find a way to meet somewhere in the middle, with an edited version of this document, I have some questions interspersed. I'd also like to know whether there are any sections you want added or deleted in the current IPv6 document. On Nov 23, 2007, at 11:07 AM, Christian Vogt wrote: > Fred, > > thanks for writing this document. It is very good to have an overview > of this IP source address verification solution. Still, to help a > reader understand the feasibility, requirements, and implications > of the > solution, the document needs to be a bit more detailed and concise > IMO. > > Below are suggestions on restructuring the document to this > extent. It > would be great if you could give the document a revision based on > those, > possibly even before the SAVI BoF in Vancouver. The structure below > should also be helpful for a presentation of your solution at the BoF. > > > (1) Begin with a brief summary of the main idea: > > - Address filter located on the path of to-be verified packets, > capable > of dropping packets > > - monitors address configuration signaling in order to build up a list > of legitimate bindings between IP addresses and link layer addresses > > - can additionally be manually configured with static bindings > > - drops packets of which IP and link layer addresses do not match an > entry in the list Would adding this paragraph meet your needs, given that what you say above is repeated in the next section? The key point is the association of an IPv6 source address with a lower layer identifier, which might be purely local in significance like a port identifier on a switch, might be visible in the LAN like a MAC address, and might be a combination of lower layer identifiers like "the system on one of two ports using a stated MAC address". The association is called a "trust binding", and is fundamental to the solution. The implementation details are left to the implementor. > (2) Then start adding details: > > - Location of filter: Must be on same link as packet sender since > original link layer addresses are otherwise not visible. Can be > on a > switch, on an access router, on a neighbor. > > - Means for address configuration we need to consider: DHCP, > autonomous configuration how, precisely, does one snoop SAA, given that it sends no "Hey, everybody, I have chosen to use this address" message? The reason I went to what you call "double checking" is that it is the first time we see the device assert that it is in fact using a given address in SAA. The DAD check asserts that it *might* start using it and gives an opportunity for someone else to say "please don't". > - Link layer addresses to which IP addresses may be bound: Add your > first list in section 2.1. there are a lot more than addresses... > - Reactive verification of address binding (double-checking): If no > binding exists for a packet, double check addresses prior to > dropping > the packet, e.g., based on Neighbor Unreachability Detection. A host might check the address before dropping it. A router will simply drop the packet if it has no neighbor binding. > - Hard-state for manually configured bindings, soft-state otherwise. > > > (3) A discussion of things to be worked out: > > - What happens if a filter misses part of the address configuration > signaling before it boots up or appears on a link? (E.g., what > about > filters on mobile hosts?) I'm not sure I follow. When a host decides to use a new address and sends a datagram using it to a neighboring host, RFC 4862 has the neighboring host send the Neighbor Solicit sometime between receiving the datagram and sending a response. As a "security consideration" recommendation, I assert that instead of sending the NS when it has operated on the datagram and is about to reply, it should send the NS on receipt and then either force the neighbor to retransmit or queue the packet pending the NA response. WHat part of that would the host miss and still be able to continue? If you're talking about DHCP, I guarantee that a neighboring host in a switched network will miss it, and by the way it will always miss the part of SAA where the host autonomously decides that DAD has failed to produce a competitor, so the host will go ahead and use a given address. For this to work in IPv6, I really think it has to key off NS/SeND, not DHCP or SAA. If it does as I suggest, I don't think this is a question. > - Packet caching or not during double-checking? already covered. > - How long should refresh triggers and timeout values for soft-state > bindings be? what is the refresh timeout for ND? > > (4) Security considerations: > > - DoS threat: Legitimate host prevented by attacker from using its > own IP address. This is already possible with NDP. > - Flooding threat: Attacker floods packet cache in filter. Mitigation > possible through limiting number of IP addresses per link layer > address. Align soft-state timeouts with change interval for privacy > addresses so that limit does not get reached. -----BEGIN PGP SIGNATURE----- iD8DBQFHXwyobjEdbHIsm0MRAliTAKChaKHwRWQ7YQ8sjYHxuQz91Z8+VACbBtpD iMh5WAqCNrJFQ6sa78kmzDk= =hY2q -----END PGP SIGNATURE----- From christian.vogt at nomadiclab.com Sat Dec 15 06:08:50 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Fri, 14 Dec 2007 23:08:50 +0100 Subject: [SAVA] SAVI Charter Revision after Vancouver Message-ID: <4762FEF2.2020502@nomadiclab.com> Folks, according to comments raised during the SAVI BoF in Vancouver as well as meanwhile on the mailing list, I have revised the charter for the proposed SAVI working group. Enclosed is the new version of the charter, followed by a change log. Comments appreciated. Best regards, - Christian -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: savi-charter-2007-12-14.txt Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20071214/3b9b5ecf/attachment.txt From christian.vogt at nomadiclab.com Sat Dec 15 06:09:18 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Fri, 14 Dec 2007 23:09:18 +0100 Subject: [SAVA] Charter Proposal To Be Discussed at BoF In-Reply-To: References: <475655E4.8080805@nomadiclab.com> Message-ID: <4762FF0E.9000003@nomadiclab.com> Barry, we need to make sure that our charter does not collide with activities in RIPE's Anti-Spoofing task force [1]. While I agree that an analysis of existing mechanism would be useful to identify the intended scope for SAVI, documentation for its own benefit would certainly get into the realm of the IP Anti-Spoofing task force. [1] http://www.ripe.net/ripe/tf/anti-spoofing/index.html Also, our scope is IP source address validation specifically. - Christian Barry Greene (bgreene) wrote: > Change: > > "The purpose of the proposed "Source Address Validation Improvements" > working group is to standardize mechanisms to prevent source address > spoofing in the access network." > > To: > > "The purpose of the proposed "Source Address Validation Improvements" > working group is to update practices, document experience with > existing technology, document all existing practices and limitations, > and develop potential new mechanisms which would allow a broad > anti-source spoof capabilities." > > > The language focused on "IP source address" needs to be expanded to > any source spoof. IP address, MAC, DSCP, protocol type, etc. etc. all > need to be included. From fergdawg at netzero.net Sat Dec 15 13:11:06 2007 From: fergdawg at netzero.net (Paul Ferguson) Date: Sat, 15 Dec 2007 05:11:06 GMT Subject: [SAVA] SAVI Charter Revision after Vancouver Message-ID: <20071214.211106.3436.4@webmail05.vgs.untd.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Christian Vogt wrote: >Folks, > >according to comments raised during the SAVI BoF in Vancouver as well >as meanwhile on the mailing list, I have revised the charter for the >proposed SAVI working group. Enclosed is the new version of the >charter, followed by a change log. > >Comments appreciated. > >Best regards, >- Christian > The only comment I would have here is that RFC2827 should (also) be referenced as BCP38. I'll save further comment until... later. :-) Thanks, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHY2Hnq1pz9mNUZTMRAm9nAJ9drN4H7BVt5RsDV2DD+/o9fUrTPgCgx1Dw s7WkSSdVegZWWc3kyvZPd8U= =RaZ8 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ From danny at tcb.net Mon Dec 17 12:39:40 2007 From: danny at tcb.net (Danny McPherson) Date: Sun, 16 Dec 2007 21:39:40 -0700 Subject: [SAVA] SAVI Charter Revision after Vancouver In-Reply-To: <4762FEF2.2020502@nomadiclab.com> References: <4762FEF2.2020502@nomadiclab.com> Message-ID: On Dec 14, 2007, at 3:08 PM, Christian Vogt wrote: > > - The working group considers only solutions implemented on systems > located on the same IP link as a to-be-verified host > - The solutions verify the addresses of hosts; verification of router > addresses is out of scope What does the above mean, exactly? Addresses for transit packets AND locally connected interfaces (e.g., any device that'll forward IP packets and has one ore more IP interfaces)? > - Two solutions are needed, one for IPv4 and another one for IPv6 > - The IPv4 solution depends on tracking the DHCP traffic Why? Seems to me this very quickly limits the solutions space, when I'm not sure we've fully documented the problem space? > - The IPv6 solution depends on tracking the Neighbor Discovery traffic > or DHCP traffic Same comment above applies here. > - All address assignment mechanisms in IPv6 need to be supported, > including stateless, stateful, and manual configuration; as well as > privacy and cryptographically generated addresses Then why not in IPv4? > - The solutions must allow for interfaces with multipe IP addresses > - The solutions must allow for hosts with multiple interfaces What does that mean? > - The solutions must interoperate with mobile hosts Precisely what is a mobile host? > - The working group will document how the to-be-developed solutions > relate to existing IP source address validation mechanisms It sounds a lot like we've written the charter to comply with them, so that shouldn't be to tough. > The working group recognizes anti-spoofing deployment efforts, > motivation, and best practices development in various forums around > the > world (including RIPE). AND the OPSEC WG? > The working group is only chartered to deliver > two specific solution components that such efforts could employ. The > bigger questions are out of scope. > > Milestones: > Done First draft on IPv4 solution > Done First draft on IPv6 solution The two items above assume the SAVI community permits the published documents as the basis for WG documents. I'm not sure we're anywhere near reaching that consensus. > Done BOF decision > Dec 07 BOF in IETF-70 Guess that's done.. > Jan 08 WG approval I really believe the first document here needs to be a full problem statement. From there, drafts on v4 and v6 solutions need to talk about which components of that problem space they address. The problem space document(s) should talk about all the IP allocation schemas, the various topologies that might be encountered in the LAN, and which problems are believed exist as a result of spoofing (e.g., various blind and non-blind attacks) that are worth addressing. As noted, I'm happy to help draft such a document, as I consider it a prerequisite to help with charter direction and scope of SAVI. I also believe SAVI needs to think about what protocol what can be done that in some manner equates to bits on the wire, versus intra-switch implementation alone. -danny From junbi at cernet.edu.cn Wed Dec 19 16:58:04 2007 From: junbi at cernet.edu.cn (Jun Bi) Date: Wed, 19 Dec 2007 16:58:04 +0800 Subject: [SAVA] SAVI Charter Revision after Vancouver In-Reply-To: References: <4762FEF2.2020502@nomadiclab.com> Message-ID: <7DD061CF01144565B964CFAF4E378125@userPC> ----- Original Message ----- From: "Danny McPherson" To: "Christian Vogt" Cc: "Bill Fenner" ; "Eric Rescorla" ; "SAVI Mailing List" Sent: Monday, December 17, 2007 12:39 PM Subject: Re: [SAVA] SAVI Charter Revision after Vancouver > > On Dec 14, 2007, at 3:08 PM, Christian Vogt wrote: >> >> - The working group considers only solutions implemented on systems >> located on the same IP link as a to-be-verified host >> - The solutions verify the addresses of hosts; verification of router >> addresses is out of scope > > What does the above mean, exactly? Addresses for transit > packets AND locally connected interfaces (e.g., any device > that'll forward IP packets and has one ore more IP interfaces)? The scope of the charter could be limited in the host-level, then we may re-charter to resovle other problems. > >> - Two solutions are needed, one for IPv4 and another one for IPv6 >> - The IPv4 solution depends on tracking the DHCP traffic > > Why? Seems to me this very quickly limits the solutions > space, when I'm not sure we've fully documented the > problem space? I agree that we may need multipule solutions for opeators so that the opeator can choce for different network environment.(e.g., some opeator can upgrade the switches, somelese may not). > > I really believe the first document here needs to be a > full problem statement. From there, drafts on v4 and > v6 solutions need to talk about which components of > that problem space they address. > > The problem space document(s) should talk about all > the IP allocation schemas, the various topologies that > might be encountered in the LAN, and which problems > are believed exist as a result of spoofing (e.g., various > blind and non-blind attacks) that are worth addressing. > As noted, I'm happy to help draft such a document, as > I consider it a prerequisite to help with charter direction > and scope of SAVI. > > I also believe SAVI needs to think about what protocol > what can be done that in some manner equates to > bits on the wire, versus intra-switch implementation > alone. > I agree that we need a problem statement document. We may also need a "framework" document to define the fundamental to solutions (refer to Fred's comments below), and leave the design details to different solution drafts. The WG should welcome any new solution draft that follows the framework document,then choice the best solution that resolves the same problem for same environment. thanks, Jun >Fred wrote: > The key point is the association of an IPv6 source address with a > lower layer identifier, which might be purely local in significance > like a port identifier on a switch, might be visible in the LAN like > a MAC address, and might be a combination of lower layer identifiers > like "the system on one of two ports using a stated MAC address". The > association is called a "trust binding", and is fundamental to the > solution. The implementation details are left to the implementor. From hiroa-ha at is.naist.jp Wed Dec 19 17:39:36 2007 From: hiroa-ha at is.naist.jp (hiroa-ha) Date: Wed, 19 Dec 2007 18:39:36 +0900 Subject: [SAVA] SAVI Charter Revision after Vancouver In-Reply-To: <7DD061CF01144565B964CFAF4E378125@userPC> References: <4762FEF2.2020502@nomadiclab.com> <7DD061CF01144565B964CFAF4E378125@userPC> Message-ID: <4768E6D8.9050001@is.naist.jp> I have a question. Current WG's mission is to write down several documents about ; 1. what kinds of problems we are bothered in daily operation or event operation like IETF meeting about source address validation ? 2. what we want to do against problems (prevent? guard? track? shoot? claim? clean up?) or what kinds of tools we need in daily/event operation? 3. what kinds of solutions are available now in each situation ? , is it? ---- Hiroaki Hazeyama Ph.D of Engineering Internet Engineering Lab. Nara Institute of Science and Technology Jun Bi wrote: > ----- Original Message ----- > From: "Danny McPherson" > To: "Christian Vogt" > Cc: "Bill Fenner" ; "Eric Rescorla" ; "SAVI > Mailing List" > Sent: Monday, December 17, 2007 12:39 PM > Subject: Re: [SAVA] SAVI Charter Revision after Vancouver > > >> On Dec 14, 2007, at 3:08 PM, Christian Vogt wrote: >>> - The working group considers only solutions implemented on systems >>> located on the same IP link as a to-be-verified host >>> - The solutions verify the addresses of hosts; verification of router >>> addresses is out of scope >> What does the above mean, exactly? Addresses for transit >> packets AND locally connected interfaces (e.g., any device >> that'll forward IP packets and has one ore more IP interfaces)? > > The scope of the charter could be limited in the host-level, then > we may re-charter to resovle other problems. > >>> - Two solutions are needed, one for IPv4 and another one for IPv6 >>> - The IPv4 solution depends on tracking the DHCP traffic >> Why? Seems to me this very quickly limits the solutions >> space, when I'm not sure we've fully documented the >> problem space? > > > I agree that we may need multipule solutions for opeators so that > the opeator can choce for different network environment.(e.g., some > opeator can upgrade the switches, somelese may not). > >> I really believe the first document here needs to be a >> full problem statement. From there, drafts on v4 and >> v6 solutions need to talk about which components of >> that problem space they address. >> >> The problem space document(s) should talk about all >> the IP allocation schemas, the various topologies that >> might be encountered in the LAN, and which problems >> are believed exist as a result of spoofing (e.g., various >> blind and non-blind attacks) that are worth addressing. >> As noted, I'm happy to help draft such a document, as >> I consider it a prerequisite to help with charter direction >> and scope of SAVI. >> >> I also believe SAVI needs to think about what protocol >> what can be done that in some manner equates to >> bits on the wire, versus intra-switch implementation >> alone. >> > > I agree that we need a problem statement document. > We may also need a "framework" document to define the fundamental > to solutions (refer to Fred's comments below), and leave the design > details to different solution drafts. The WG should welcome > any new solution draft that follows the framework document,then choice > the best solution that resolves the same problem for same environment. > > thanks, > Jun > >> Fred wrote: >> The key point is the association of an IPv6 source address with a >> lower layer identifier, which might be purely local in significance >> like a port identifier on a switch, might be visible in the LAN like >> a MAC address, and might be a combination of lower layer identifiers >> like "the system on one of two ports using a stated MAC address". The >> association is called a "trust binding", and is fundamental to the >> solution. The implementation details are left to the implementor. > > > > > > _______________________________________________ > SAVA mailing list > SAVA at mail.nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava From christian.vogt at nomadiclab.com Fri Dec 21 07:56:42 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Fri, 21 Dec 2007 00:56:42 +0100 Subject: [SAVA] SAVI Charter Revision after Vancouver In-Reply-To: <20071214.211106.3436.4@webmail05.vgs.untd.com> References: <20071214.211106.3436.4@webmail05.vgs.untd.com> Message-ID: <476B013A.1000806@nomadiclab.com> > The only comment I would have here is that RFC2827 should (also) > be referenced as BCP38. Right, good point. - Christian From christian.vogt at nomadiclab.com Fri Dec 21 07:57:04 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Fri, 21 Dec 2007 00:57:04 +0100 Subject: [SAVA] SAVI Charter Revision after Vancouver In-Reply-To: References: <4762FEF2.2020502@nomadiclab.com> Message-ID: <476B0150.6080307@nomadiclab.com> Danny - >> - The solutions verify the addresses of hosts; verification of router >> addresses is out of scope > > What does the above mean, exactly? Addresses for transit > packets AND locally connected interfaces (e.g., any device > that'll forward IP packets and has one ore more IP interfaces)? It means that the entities whose IP addresses will be verified by the SAVI mechanism are supposed to be hosts, not routers. Thinking more about it, I come to the conclusion that we should drop this statement. After all, we want the SAVI mechanism to also work for nodes with multiple interfaces, and I don't see a reason why it should not also work for routers (i.e., nodes with multiple interfaces that forward packets between those interfaces). Any comments? >> - Two solutions are needed, one for IPv4 and another one for IPv6 >> - The IPv4 solution depends on tracking the DHCP traffic > > Why? Seems to me this very quickly limits the solutions > space, when I'm not sure we've fully documented the > problem space? > >> - The IPv6 solution depends on tracking the Neighbor Discovery traffic >> or DHCP traffic > > Same comment above applies here. The rationale for these limitations is that they will keep us from drifting away from the narrow charter that we proposed in Vancouver compared to the much wider charter that was proposed in Prague. >> - All address assignment mechanisms in IPv6 need to be supported, >> including stateless, stateful, and manual configuration; as well as >> privacy and cryptographically generated addresses > > Then why not in IPv4? Good point -- although in the v4 case, there are only stateful and manual configuration modes. >> - The solutions must allow for interfaces with multipe IP addresses >> - The solutions must allow for hosts with multiple interfaces > > What does that mean? s/must allow for/must support/ >> - The solutions must interoperate with mobile hosts > > Precisely what is a mobile host? A host that may change the point of network attachment for one of its interfaces. Do you think this is ambiguous? >> The working group recognizes anti-spoofing deployment efforts, >> motivation, and best practices development in various forums around the >> world (including RIPE). > > AND the OPSEC WG? Added. > I really believe the first document here needs to be a > full problem statement. From there, drafts on v4 and > v6 solutions need to talk about which components of > that problem space they address. How about the new milestones below? It now includes the finalization of the charter proposal and the (previously missing) problem statement. Moreover, I removed the "first non-WG drafts" on IPv4 and IPv6 solutions, which were supposed to be done by now. Milestones: Done BOF decision Done BOF in IETF-70 Dec 07 Charter proposal Jan 08 Problem statement Feb 08 WG approval Apr 08 First WG draft on IPv4 solution Apr 08 First WG draft on IPv6 solution Jun 08 Submit document on existing SAVI-related mechansims to IESG for Informational RFC Jun 08 Submit IPv4 solution to IESG for Proposed Standard Dec 08 Submit IPv6 solution to IESG for Proposed Standard - Christian From christian.vogt at nomadiclab.com Fri Dec 21 08:00:09 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Fri, 21 Dec 2007 01:00:09 +0100 Subject: [SAVA] SAVI Charter Revision after Vancouver In-Reply-To: <4768E6D8.9050001@is.naist.jp> References: <4762FEF2.2020502@nomadiclab.com> <7DD061CF01144565B964CFAF4E378125@userPC> <4768E6D8.9050001@is.naist.jp> Message-ID: <476B0209.1070908@nomadiclab.com> Hiroaki, yes, these items will be part of the proposed SAVI charter, and they are to be tackled by a problem statement document. - Christian hiroa-ha wrote: > > I have a question. > > Current WG's mission is to write down several documents about ; > > 1. what kinds of problems we are bothered in daily operation or > event operation like IETF meeting about source address validation ? > > 2. what we want to do against problems (prevent? guard? track? shoot? > claim? clean up?) or what kinds of tools we need in daily/event > operation? > > 3. what kinds of solutions are available now in each situation ? > > , is it? > > ---- > Hiroaki Hazeyama > Ph.D of Engineering > Internet Engineering Lab. > Nara Institute of Science and Technology From christian.vogt at nomadiclab.com Fri Dec 21 08:12:52 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Fri, 21 Dec 2007 01:12:52 +0100 Subject: [SAVA] SAVI BoF Meeting Minutes Available Message-ID: <476B0504.2050203@nomadiclab.com> The meeting minutes for the SAVI BoF in Vancouver are now on-line available at [1] -- thanks to Mark William's great job in compiling the minutes from himself, Ralph Droms, and Behcet Sarikaya. Agenda and presentation slides are available at [2]. [1] http://www3.ietf.org/proceedings/07dec/minutes/savi.txt [2] https://datatracker.ietf.org/meeting/70/materials.html - Christian From christian.vogt at nomadiclab.com Sun Dec 23 19:56:45 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Sun, 23 Dec 2007 12:56:45 +0100 Subject: [SAVA] SAVI Charter Revision after Vancouver, Take 2 Message-ID: <476E4CFD.9000803@nomadiclab.com> Folks, enclosed you find an updated charter version. Please take a look at the milestones specifically because those have changed quite a bit and now also include a problem statement deliverable. Comments appreciated. - Christian -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: savi-charter-2007-12-23.txt Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20071223/5b580c94/attachment.txt From christian.vogt at nomadiclab.com Sun Dec 23 20:01:53 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Sun, 23 Dec 2007 13:01:53 +0100 Subject: [SAVA] Vacation Notice Message-ID: <476E4E31.4020807@nomadiclab.com> Folks, I will be away from email until January 7, 2008, for some Christmas and New Year vacation. Wish you all happy holidays! - Christian From christian.vogt at nomadiclab.com Sun Dec 23 20:05:47 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Sun, 23 Dec 2007 13:05:47 +0100 Subject: [SAVA] SAVI Charter Revision after Vancouver In-Reply-To: <476B0150.6080307@nomadiclab.com> References: <4762FEF2.2020502@nomadiclab.com> <476B0150.6080307@nomadiclab.com> Message-ID: <476E4F1B.9050607@nomadiclab.com> > Thinking more about it, I come to the conclusion that we should drop > this statement. After all, we want the SAVI mechanism to also work for > nodes with multiple interfaces, and I don't see a reason why it should > not also work for routers (i.e., nodes with multiple interfaces that > forward packets between those interfaces). > > Any comments? Sorry, I have to correct myself. I believe we should support multi- interfaced hosts that do not forward packets, but the validation of routers' IP addresses should be out of scope IMO. The reason is that the validation of routers' IP addresses would likely require a more complex technique than a Source-Guard-like function because routers send packets from IP addresses of other hosts. - Christian From miw at juniper.net Mon Dec 24 12:34:29 2007 From: miw at juniper.net (Mark Williams) Date: Mon, 24 Dec 2007 12:34:29 +0800 Subject: [SAVA] SAVI Charter Revision after Vancouver In-Reply-To: References: <4762FEF2.2020502@nomadiclab.com> Message-ID: <476F36D5.1000302@juniper.net> Danny McPherson wrote: > > On Dec 14, 2007, at 3:08 PM, Christian Vogt wrote: > > > > - The working group considers only solutions implemented on systems > > located on the same IP link as a to-be-verified host > > - The solutions verify the addresses of hosts; verification of router > > addresses is out of scope > > What does the above mean, exactly? Addresses for transit > packets AND locally connected interfaces (e.g., any device > that'll forward IP packets and has one ore more IP interfaces)? > Hmm. I think transit packets are out-of-scope for SAVI. Am I correct in the assumption that we are looking at preventing spoofing from end systems here? Not saying transit packets aren't important. Just a different problem. > > > > - Two solutions are needed, one for IPv4 and another one for IPv6 > > - The IPv4 solution depends on tracking the DHCP traffic > > Why? Seems to me this very quickly limits the solutions > space, when I'm not sure we've fully documented the > problem space? > > > - The IPv6 solution depends on tracking the Neighbor Discovery traffic > > or DHCP traffic > > Same comment above applies here. > Tend to agree here. It's the way it might end up, but at this stage I don't like to exclude any address-provisioning method. --Mark -- "Product roadmap and/or product discussion in this email set forth Juniper Networks' current intention and is subject to change at any time without notice. No purchases are contingent upon Juniper Networks delivering any feature or functionality expressed or implied in this roadmap or product discussion." ----------------------------------------------------------------- Mark Williams Juniper Networks Liaison Beijing Office Academic Networking Sector Tel: +86 10 6528 8800 x16032 Asia Pacific FAX: +61 7 3251 0155 miw at juniper.net Cell: +86 1370-111-4749