From jari.arkko at piuha.net Mon Oct 1 03:59:00 2007 From: jari.arkko at piuha.net (Jari Arkko) Date: Sun, 30 Sep 2007 22:59:00 +0300 Subject: [SAVA] Sava meeting in Helsinki on October 11-12th In-Reply-To: References: <20070723.182610.11112.0@webmail26.lax.untd.com> <46FCA26C.6070503@piuha.net> Message-ID: <47000004.1080605@piuha.net> Barry, I realize this is a short notice. We've been trying to get a few known-to-be-interested individuals in the same place and time, and once that was settled the list was notified too. I'm sorry if the time and place does not work for everyone, but its very hard to make it so. We can make teleconf facilities available, but its not the same thing as being present. Note that SAVA does not formally exist as an IETF activity, and hence there's really no official status for pre-WG/BOF meetings like this. An open meeting of interested individuals, at best. Jari Barry Greene (bgreene) kirjoitti: > > Hum. Very short notice. > > Will there be conference or video facilities to allow for remote > participation? Without it, I would not call it a "SAVA Meeting." > > >> -----Original Message----- > >> From: sava-bounces at mail.nrc.tsinghua.edu.cn > >> [mailto:sava-bounces at mail.nrc.tsinghua.edu.cn] On Behalf Of Jari > >> Arkko Sent: Thursday, September 27, 2007 11:43 PM > >> To: sava at nrc.tsinghua.edu.cn > >> Subject: [SAVA] Sava meeting in Helsinki on October 11-12th > >> > >> > >> There will be a meeting about SAVA in Helsinki on October > >> 11th to 12th, hosted by Ericsson Research. Anyone interested > >> is welcome to join; contact me for the practical details. > >> > >> The goal of the meeting is to assess the situation after > >> discussions in previous IETFs and invite contributors to > >> describe their proposals for improvements for address > >> validation in local subnets or between ISPs. Emphasis is > >> placed on trying to find solutions that there is real-world > >> interest for, e.g., we could start from documenting > >> mechanisms that vendors already have in place. Another > >> important question is whether there is common interest > >> between the participants to focus on a particular part of the > >> problem space. > >> > >> Based on results of this meeting we hope it will be clear > >> what the next steps with respect to this effort in the IETF > >> should be. E.g., do we have common ground, is there practical > >> interest, etc. > >> > >> Jari Arkko > >> > >> > >> _______________________________________________ > >> 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 Thu Oct 4 03:47:45 2007 From: jari.arkko at piuha.net (Jari Arkko) Date: Wed, 03 Oct 2007 22:47:45 +0300 Subject: [SAVA] program for the Helsinki meeting, take one Message-ID: <4703F1E1.1090600@piuha.net> WEDNESDAY, October 10th 17:00- Welcome, TBD THURSDAY, October 11th 09:00 Opening and practical arrangements -- Jari Arkko 09:20 Operational aspects -- Fred Baker 10:00 Survey of deployed local-subnet solutions -- Fred Baker 11:00 Design space and missing pieces for local-subnet -- All 12:00 Lunch 13:00 Local-subnet discussion -- All 14:30 The revised SAVA problem statement (local-subnet) -- TBD 16:00 (Unallocated) 17:00- Close meeting, begin of evening program TBD FRIDAY, October 12th 09:00 Inter-AS needs and solutions -- Pekka Savola 10:00 SEND- and RR-based inter-AS design space -- Christian Vogt 11:00 (Unallocated) 12:00 Lunch 13:00 Test bed draft revision -- Jari Arkko 14:00 SAVA IETF plans, BOFs, drafts, way forward -- All 16:00 Wrap-up -- All 17:00 Close From jari.arkko at piuha.net Mon Oct 8 23:26:52 2007 From: jari.arkko at piuha.net (Jari Arkko) Date: Mon, 08 Oct 2007 18:26:52 +0300 Subject: [SAVA] program for the Helsinki meeting, take two Message-ID: <470A4C3C.6010807@piuha.net> Location: Ericsson Offices in Jorvas, Finland [1]. WEDNESDAY, October 10th 17:00 Welcome dinner & sauna at [2] 20:00 End THURSDAY, October 11th at Ericsson [1] 09:00 Opening and practical arrangements -- Jari Arkko 09:20 Operational aspects -- Fred Baker 10:00 Survey of deployed local-subnet solutions -- Fred Baker 11:00 Design space and missing pieces for local-subnet -- All 12:00 Lunch 13:00 Local-subnet discussion -- All 14:30 The revised SAVA problem statement (local-subnet) -- TBD 16:00 Test bed draft revision -- Jari Arkko 17:00 Close meeting 17:00 Dinner in Jorvas 20:00 End FRIDAY, October 12th at Ericsson [1] 09:00 Inter-AS needs and solutions -- Pekka Savola 10:00 SEND- and RR-based inter-AS design space -- Christian Vogt 11:00 Packet Level Authentication proposal, Billy Brumley 12:00 Lunch 13:00 SAVA IETF plans, BOFs, drafts, way forward -- All 14:00 Wrap-up -- All 15:00 Close Transportation is best handled via taxi. The addresses are below. Call Jari at +358 40 5079256 if there are any problems. Location 1: Ericsson Offices, Jorvas, Finland. Address Hirsalantie 1, Jorvas, Kirkkonummi. Google maps link: http://maps.google.com/maps?f=q&hl=en&geocode=&time=&date=&ttype=&q=1+Hirsalantie,+02420+Kirkkonummi,+Finland&sll=60.114829,24.566116&sspn=0.159433,0.615234&ie=UTF8&ll=60.134111,24.509511&spn=0.009959,0.038452&z=15&om=1 http://www.ericsson.com/fi/images/kartta_jorvas.gif Location 2: Jari's home, Kauniainen, Finland. Address V?litie 1B, Kauniainen. Google maps link: http://maps.google.com/maps?f=q&hl=en&geocode=&time=&date=&ttype=&q=v%C3%A4litie+1b,+kauniainen&sll=60.134111,24.509511&sspn=0.009959,0.038452&ie=UTF8&ll=60.214431,24.725547&spn=0.009934,0.038452&z=15&om=1 On this second location you could also take a train from the Helsinki city center. The trains marked with "S", "U", "L" and "E" come here, and you get off the Kauniainen station, then either walk or call me. Participants that I know of: - Jari Arkko - Fred Baker - Prof. Jun Bi - Billy Brumley - Assoc Prof. Haixin Duan - Pekka Nikander (day 2) - Gang Ren - Pekka Savola - Christian Vogt - Prof. Jianping Wu - Assoc Prof. Ke Xu From jari.arkko at piuha.net Tue Oct 9 19:09:48 2007 From: jari.arkko at piuha.net (Jari Arkko) Date: Tue, 09 Oct 2007 14:09:48 +0300 Subject: [SAVA] program for the Helsinki meeting, take three Message-ID: <470B617C.50406@piuha.net> Location: Ericsson Offices in Jorvas, Finland [1]. WEDNESDAY, October 10th 17:00 Welcome dinner & sauna at [2] 20:00 End THURSDAY, October 11th at Ericsson [1] 09:00 Opening and practical arrangements -- Jari Arkko 09:20 Operational aspects -- Fred Baker 10:00 Survey of deployed local-subnet solutions -- Fred Baker 11:00 Access network solutions -- Ke Xu 11:30 Design space and missing pieces for local-subnet -- All 12:00 Lunch 13:00 Local-subnet discussion -- All 14:30 The revised SAVA problem statement (local-subnet) -- Jun Bi 16:00 Test bed draft -- Gang Ren 16:30 Test bed draft way forward -- Jari Arkko 17:00 Close meeting 17:00 Dinner in Jorvas 20:00 End FRIDAY, October 12th at Ericsson [1] 09:00 Inter-AS needs and solutions -- Pekka Savola 10:00 SEND- and RR-based inter-AS design space -- Christian Vogt 11:00 Packet Level Authentication proposal, Billy Brumley 12:00 Lunch 13:00 SAVA IETF plans, BOFs, drafts, way forward -- All 14:00 Wrap-up -- All 15:00 Close Transportation is best handled via taxi. The addresses are below. Call Jari at +358 40 5079256 if there are any problems. Location 1: Ericsson Offices, Jorvas, Finland. Address Hirsalantie 1, Jorvas, Kirkkonummi. Google maps link: http://maps.google.com/maps?f=q&hl=en&geocode=&time=&date=&ttype=&q=1+Hirsalantie,+02420+Kirkkonummi,+Finland&sll=60.114829,24.566116&sspn=0.159433,0.615234&ie=UTF8&ll=60.134111,24.509511&spn=0.009959,0.038452&z=15&om=1 http://www.ericsson.com/fi/images/kartta_jorvas.gif Location 2: Jari's home, Kauniainen, Finland. Address V?litie 1B, Kauniainen. Google maps link: http://maps.google.com/maps?f=q&hl=en&geocode=&time=&date=&ttype=&q=v%C3%A4litie+1b,+kauniainen&sll=60.134111,24.509511&sspn=0.009959,0.038452&ie=UTF8&ll=60.214431,24.725547&spn=0.009934,0.038452&z=15&om=1 On this second location you could also take a train from the Helsinki city center. The trains marked with "S", "U", "L" and "E" come here, and you get off the Kauniainen station, then either walk or call me. Participants that I know of: - Jari Arkko - Fred Baker - Prof. Jun Bi - Billy Brumley - Assoc Prof. Haixin Duan - Pekka Nikander (day 2) - Gang Ren - Pekka Savola - Christian Vogt - Prof. Jianping Wu - Assoc Prof. Ke Xu _______________________________________________ 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 Tue Oct 9 19:42:27 2007 From: jari.arkko at piuha.net (Jari Arkko) Date: Tue, 09 Oct 2007 14:42:27 +0300 Subject: [SAVA] program for the Helsinki meeting, take three In-Reply-To: <470B617C.50406@piuha.net> References: <470B617C.50406@piuha.net> Message-ID: <470B6923.9050707@piuha.net> Also, if people have special dietary requirements, let me know. Jari From fred at cisco.com Wed Oct 10 15:53:45 2007 From: fred at cisco.com (Fred Baker) Date: Wed, 10 Oct 2007 09:53:45 +0200 Subject: [SAVA] program for the Helsinki meeting, take three In-Reply-To: <470B617C.50406@piuha.net> References: <470B617C.50406@piuha.net> Message-ID: <5F480CB7-B28E-4928-900D-62F5D7AC7DB2@cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 works for me. On Oct 9, 2007, at 1:09 PM, Jari Arkko wrote: > > Location: Ericsson Offices in Jorvas, Finland [1]. > > WEDNESDAY, October 10th > > 17:00 Welcome dinner & sauna at [2] > 20:00 End > > THURSDAY, October 11th at Ericsson [1] > > 09:00 Opening and practical arrangements -- Jari Arkko > 09:20 Operational aspects -- Fred Baker > 10:00 Survey of deployed local-subnet solutions -- Fred Baker > 11:00 Access network solutions -- Ke Xu > 11:30 Design space and missing pieces for local-subnet -- All > 12:00 Lunch > 13:00 Local-subnet discussion -- All > 14:30 The revised SAVA problem statement (local-subnet) -- Jun Bi > 16:00 Test bed draft -- Gang Ren > 16:30 Test bed draft way forward -- Jari Arkko > 17:00 Close meeting > 17:00 Dinner in Jorvas > 20:00 End > > FRIDAY, October 12th at Ericsson [1] > > 09:00 Inter-AS needs and solutions -- Pekka Savola > 10:00 SEND- and RR-based inter-AS design space -- Christian Vogt > 11:00 Packet Level Authentication proposal, Billy Brumley > 12:00 Lunch > 13:00 SAVA IETF plans, BOFs, drafts, way forward -- All > 14:00 Wrap-up -- All > 15:00 Close > > Transportation is best handled via taxi. The addresses > are below. Call Jari at +358 40 5079256 if there are > any problems. > > Location 1: Ericsson Offices, Jorvas, Finland. Address > Hirsalantie 1, Jorvas, Kirkkonummi. Google maps link: > http://maps.google.com/maps? > f=q&hl=en&geocode=&time=&date=&ttype=&q=1+Hirsalantie,+02420 > +Kirkkonummi, > +Finland&sll=60.114829,24.566116&sspn=0.159433,0.615234&ie=UTF8&ll=60. > 134111,24.509511&spn=0.009959,0.038452&z=15&om=1 > http://www.ericsson.com/fi/images/kartta_jorvas.gif > > Location 2: Jari's home, Kauniainen, Finland. Address > V?litie 1B, Kauniainen. Google maps link: > http://maps.google.com/maps? > f=q&hl=en&geocode=&time=&date=&ttype=&q=v%C3%A4litie+1b, > +kauniainen&sll=60.134111,24.509511&sspn=0.009959,0.038452&ie=UTF8&ll= > 60.214431,24.725547&spn=0.009934,0.038452&z=15&om=1 > > On this second location you could also take a train from > the Helsinki city center. The trains marked with "S", > "U", "L" and "E" come here, and you get off the Kauniainen > station, then either walk or call me. > > Participants that I know of: > - Jari Arkko > - Fred Baker > - Prof. Jun Bi > - Billy Brumley > - Assoc Prof. Haixin Duan > - Pekka Nikander (day 2) > - Gang Ren > - Pekka Savola > - Christian Vogt > - Prof. Jianping Wu > - Assoc Prof. Ke Xu -----BEGIN PGP SIGNATURE----- iD8DBQFHDIUJbjEdbHIsm0MRAjQTAKCdZN0NfRZ9MiOzwNN85Ki5t9gb0QCfb4Vo rvEtQZyLWrVjNblsS2DIleY= =xcjR -----END PGP SIGNATURE----- From christian.vogt at nomadiclab.com Wed Oct 10 19:22:48 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Wed, 10 Oct 2007 14:22:48 +0300 Subject: [SAVA] Remote Participation in SAVA Meeting on Oct. 11-12 Message-ID: <470CB608.3080803@nomadiclab.com> Folks, for those of you who won't come to the SAVA meeting in Jorvas on October 11-12, but would like to participate remotely, we set up a telephone bridge. To attend the SAVA meeting via telephone, please dial: 850 99500 if you are calling from Sweden +46 8 719 9500 if you are calling from elsewhere When prompted for your conference code, please enter 29450 on your telephone keypad. The telephone bridge will be available throughout the scheduled meeting hours, i.e., from 9:00 am to 5:00 pm eastern European time on October 11, and from 9:00 am to 3:00 pm eastern European time on October 12. Best regards, - Christian From christian.vogt at nomadiclab.com Wed Oct 10 19:27:43 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Wed, 10 Oct 2007 14:27:43 +0300 Subject: [SAVA] Remote Participation in SAVA Meeting on Oct. 11-12 In-Reply-To: <470CB608.3080803@nomadiclab.com> References: <470CB608.3080803@nomadiclab.com> Message-ID: <470CB72F.3040508@nomadiclab.com> Christian Vogt wrote: > for those of you who won't come to the SAVA meeting in Jorvas on October > 11-12, but would like to participate remotely, we set up a telephone > bridge. Please send a note to me (christian.vogt at nomadiclab.com) if you intend to participate. Thanks, - Christian From jari.arkko at piuha.net Thu Oct 11 14:59:46 2007 From: jari.arkko at piuha.net (Jari Arkko) Date: Thu, 11 Oct 2007 09:59:46 +0300 Subject: [SAVA] Remote Participation in SAVA Meeting on Oct. 11-12 In-Reply-To: <470CB608.3080803@nomadiclab.com> References: <470CB608.3080803@nomadiclab.com> Message-ID: <470DC9E2.1090502@piuha.net> We were a bit delayed, but the phone bridge is now on. I will also put out presentations on the web, at http://www.arkko.com/temp/sava Jari From fred at cisco.com Thu Oct 11 22:12:52 2007 From: fred at cisco.com (Fred Baker) Date: Thu, 11 Oct 2007 17:12:52 +0300 Subject: [SAVA] Capturing the board discussion on objectives and cases Message-ID: A non-text attachment was scrubbed... Name: SAVA Workshop - board discussion #1.ppt Type: application/vnd.ms-powerpoint Size: 122880 bytes Desc: not available Url : http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20071011/169cda30/attachment-0001.ppt -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 155 bytes Desc: This is a digitally signed message part Url : http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20071011/169cda30/attachment-0001.pgp From jari.arkko at piuha.net Mon Oct 22 23:40:57 2007 From: jari.arkko at piuha.net (Jari Arkko) Date: Mon, 22 Oct 2007 17:40:57 +0200 Subject: [SAVA] new bof proposal, take one Message-ID: <471CC489.4000606@piuha.net> IETF BOF Proposal: Source Address Validation Improvements (SAVI) Co-chairs Paul Ferguson Internet Area Directors: Jari Arkko Mark Townsley Technical Advisors: Fred Baker Jianping Wu Mailing Lists: General Discussion: sava at nrc.tsinghua.edu.cn To Subscribe: http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava Mailing List Archive: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/ Document Repository: http://narl.tsinghua.edu.cn/sava The Current situation in IPv4 and IPv6 is that the source IP address is not checked in most cases. The purpose of the proposed "Source Address Validation Improvements " working group is to standardise mechanisms to prevent source address spoofing in the access network. Sepecifically: 1. Ensure that a host only uses IP source addresses that are assigned to it. 2. Support IPv4 and IPv6 with mechanisms as similar as possible. 3. Support multiple IPv4/IPv6 address assignment types. The source address validation points may include: 1. At the first hop in a local area network (where can see the port and MAC address information) 2. On an upstream exit router. 3. Or on a remote host. There are many cases in enterprise networks and residential broadband networks, all requiring their own solutions: 1 Ethernet/IEEE 802.3. 2 Wireless: 802.11/16. 3 DSL. 4 Cable Modem, etc. With this in mind, the goals of the WG are to complete the following work items: 1 Document the problem statement and submit it to the IESG as an Informational Standard. 2 Survey all existing methods and evaluate compliance to the framework model, then submit architectural framework document to the IESG. 3 For exisiting solutions, document or encourage vendor to document as RFC. 4 Identify any remaining gaps and devise solutions, then submit them to the IESG. Milestones: Dec 07 Plan to hold BoF in IETF 70, asking for this Charter to be approved Jan 08 Plan to get Final version of Charter approved and WG created. March 08 Plan to submit WG Draft 00 on Problem Statement and Architectural Framework for SAVI July 08 Plan to submit WG draft 00 SAVI solutions Dec 08 Plan to submit final Drafts of Problem Statement and Framework to IESG March 09 Plan to submit final Drafts of SAVI solutions to IESG From bgreene at cisco.com Mon Oct 22 23:53:37 2007 From: bgreene at cisco.com (Barry Greene (bgreene)) Date: Mon, 22 Oct 2007 08:53:37 -0700 Subject: [SAVA] new bof proposal, take one In-Reply-To: <471CC489.4000606@piuha.net> References: <471CC489.4000606@piuha.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Restating - again and again. The problem with deployment of source address policing in networks is NOT Standardization! It is economics! This proposal is ignoring operational input from the networks who have to deploy, operate and maintain the "framework." > -----Original Message----- > From: sava-bounces at mail.nrc.tsinghua.edu.cn > [mailto:sava-bounces at mail.nrc.tsinghua.edu.cn] On Behalf Of Jari > Arkko Sent: Monday, October 22, 2007 8:41 AM > To: SAVA Mailing List > Subject: [SAVA] new bof proposal, take one > > IETF BOF Proposal: Source Address Validation Improvements (SAVI) > > Co-chairs > Paul Ferguson > > Internet Area Directors: > Jari Arkko > Mark Townsley > > Technical Advisors: > Fred Baker > Jianping Wu > > Mailing Lists: > General Discussion: sava at nrc.tsinghua.edu.cn To Subscribe: > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > Mailing List Archive: > http://mail.nrc.tsinghua.edu.cn/pipermail/sava/ Document > Repository: http://narl.tsinghua.edu.cn/sava > > The Current situation in IPv4 and IPv6 is that the source IP > address is not checked in most cases. The purpose of the > proposed "Source Address Validation Improvements " working > group is to standardise mechanisms to prevent source address > spoofing in the access network. Sepecifically: > > 1. Ensure that a host only uses IP source addresses that are > assigned to it. > 2. Support IPv4 and IPv6 with mechanisms as similar as possible. > 3. Support multiple IPv4/IPv6 address assignment types. > > The source address validation points may include: > > 1. At the first hop in a local area network (where can see > the port and MAC address information) 2. On an upstream exit > router. 3. Or on a remote host. > > There are many cases in enterprise networks and residential > broadband networks, all requiring their own solutions: > 1 Ethernet/IEEE 802.3. > 2 Wireless: 802.11/16. > 3 DSL. > 4 Cable Modem, etc. > > With this in mind, the goals of the WG are to complete the > following work items: > 1 Document the problem statement and submit it to the IESG as > an Informational Standard. > 2 Survey all existing methods and evaluate compliance to the > framework model, then submit architectural framework document > to the IESG. > 3 For exisiting solutions, document or encourage vendor to > document as RFC. > 4 Identify any remaining gaps and devise solutions, then > submit them to the IESG. > > Milestones: > Dec 07 Plan to hold BoF in IETF 70, asking for this Charter > to be approved Jan 08 Plan to get Final version of Charter > approved and WG created. > March 08 Plan to submit WG Draft 00 on Problem Statement and > Architectural Framework for SAVI July 08 Plan to submit WG > draft 00 SAVI solutions Dec 08 Plan to submit final Drafts of > Problem Statement and Framework to IESG March 09 Plan to > submit final Drafts of SAVI solutions to IESG > > > > > _______________________________________________ > 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/AwUBRxzHgb/UEA/xivvmEQKL9gCgrAgHCnmVu+GxneZEcBWFdL2u+yMAn0Vk PXJo5XfDtQqGXHjHYAihaNWr =C+gr -----END PGP SIGNATURE----- From marc.blanchet at viagenie.ca Mon Oct 22 23:55:22 2007 From: marc.blanchet at viagenie.ca (Marc Blanchet) Date: Mon, 22 Oct 2007 11:55:22 -0400 Subject: [SAVA] new bof proposal, take one In-Reply-To: <471CC489.4000606@piuha.net> References: <471CC489.4000606@piuha.net> Message-ID: - should it have a specific reference to MobileIP support, since the use of MIP may have an impact on this work? - s/Sepecifically/Specifically/ - s/of the proposed "Source Address Validation Improvements" working group/of the working group/ Marc. Le 07-10-22 ? 11:40, Jari Arkko a ?crit : > IETF BOF Proposal: Source Address Validation Improvements (SAVI) > > Co-chairs > Paul Ferguson > > Internet Area Directors: > Jari Arkko > Mark Townsley > > Technical Advisors: > Fred Baker > Jianping Wu > > Mailing Lists: > General Discussion: sava at nrc.tsinghua.edu.cn > To Subscribe: http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/ > listinfo/sava > Mailing List Archive: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/ > Document Repository: http://narl.tsinghua.edu.cn/sava > > The Current situation in IPv4 and IPv6 is that the source IP > address is > not > checked in most cases. The purpose of the proposed "Source Address > Validation Improvements " working group is to standardise > mechanisms to > prevent source > address spoofing in the access network. Sepecifically: > > 1. Ensure that a host only uses IP source addresses that are > assigned to > it. > 2. Support IPv4 and IPv6 with mechanisms as similar as possible. > 3. Support multiple IPv4/IPv6 address assignment types. > > The source address validation points may include: > > 1. At the first hop in a local area network (where can see the port > and > MAC address information) > 2. On an upstream exit router. > 3. Or on a remote host. > > There are many cases in enterprise networks and residential broadband > networks, all requiring their own solutions: > 1 Ethernet/IEEE 802.3. > 2 Wireless: 802.11/16. > 3 DSL. > 4 Cable Modem, etc. > > With this in mind, the goals of the WG are to complete the following > work items: > 1 Document the problem statement and submit it to the IESG as an > Informational > Standard. > 2 Survey all existing methods and evaluate compliance to the framework > model, > then submit architectural framework document to the IESG. > 3 For exisiting solutions, document or encourage vendor to document > as RFC. > 4 Identify any remaining gaps and devise solutions, then submit > them to > the IESG. > > Milestones: > Dec 07 Plan to hold BoF in IETF 70, asking for this Charter to be > approved > Jan 08 Plan to get Final version of Charter approved and WG created. > March 08 Plan to submit WG Draft 00 on Problem Statement and > Architectural Framework for SAVI > July 08 Plan to submit WG draft 00 SAVI solutions > Dec 08 Plan to submit final Drafts of Problem Statement and > Framework to > IESG > March 09 Plan to submit final Drafts of SAVI solutions to IESG > > > > > _______________________________________________ > SAVA mailing list > SAVA at mail.nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava ----- IPv6 book: Migrating to IPv6, Wiley, 2006, http://www.ipv6book.ca From miw at juniper.net Mon Oct 22 23:57:52 2007 From: miw at juniper.net (Mark Williams) Date: Mon, 22 Oct 2007 23:57:52 +0800 Subject: [SAVA] new bof proposal, take one In-Reply-To: References: <471CC489.4000606@piuha.net> Message-ID: <471CC880.20306@juniper.net> So you are saying..... 1. it is a good thing to have source policing.... 2. it is a bad thing to have a recommended way in which to do it ?? cheers, Mark Barry Greene (bgreene) wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Restating - again and again. > > The problem with deployment of source address policing in networks is > NOT Standardization! It is economics! > > This proposal is ignoring operational input from the networks who > have to deploy, operate and maintain the "framework." > > > > >> -----Original Message----- >> From: sava-bounces at mail.nrc.tsinghua.edu.cn >> [mailto:sava-bounces at mail.nrc.tsinghua.edu.cn] On Behalf Of Jari >> Arkko Sent: Monday, October 22, 2007 8:41 AM >> To: SAVA Mailing List >> Subject: [SAVA] new bof proposal, take one >> >> IETF BOF Proposal: Source Address Validation Improvements (SAVI) >> >> Co-chairs >> Paul Ferguson >> >> Internet Area Directors: >> Jari Arkko >> Mark Townsley >> >> Technical Advisors: >> Fred Baker >> Jianping Wu >> >> Mailing Lists: >> General Discussion: sava at nrc.tsinghua.edu.cn To Subscribe: >> http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava >> Mailing List Archive: >> http://mail.nrc.tsinghua.edu.cn/pipermail/sava/ Document >> Repository: http://narl.tsinghua.edu.cn/sava >> >> The Current situation in IPv4 and IPv6 is that the source IP >> address is not checked in most cases. The purpose of the >> proposed "Source Address Validation Improvements " working >> group is to standardise mechanisms to prevent source address >> spoofing in the access network. Sepecifically: >> >> 1. Ensure that a host only uses IP source addresses that are >> assigned to it. >> 2. Support IPv4 and IPv6 with mechanisms as similar as possible. >> 3. Support multiple IPv4/IPv6 address assignment types. >> >> The source address validation points may include: >> >> 1. At the first hop in a local area network (where can see >> the port and MAC address information) 2. On an upstream exit >> router. 3. Or on a remote host. >> >> There are many cases in enterprise networks and residential >> broadband networks, all requiring their own solutions: >> 1 Ethernet/IEEE 802.3. >> 2 Wireless: 802.11/16. >> 3 DSL. >> 4 Cable Modem, etc. >> >> With this in mind, the goals of the WG are to complete the >> following work items: >> 1 Document the problem statement and submit it to the IESG as >> an Informational Standard. >> 2 Survey all existing methods and evaluate compliance to the >> framework model, then submit architectural framework document >> to the IESG. >> 3 For exisiting solutions, document or encourage vendor to >> document as RFC. >> 4 Identify any remaining gaps and devise solutions, then >> submit them to the IESG. >> >> Milestones: >> Dec 07 Plan to hold BoF in IETF 70, asking for this Charter >> to be approved Jan 08 Plan to get Final version of Charter >> approved and WG created. >> March 08 Plan to submit WG Draft 00 on Problem Statement and >> Architectural Framework for SAVI July 08 Plan to submit WG >> draft 00 SAVI solutions Dec 08 Plan to submit final Drafts of >> Problem Statement and Framework to IESG March 09 Plan to >> submit final Drafts of SAVI solutions to IESG >> >> >> >> >> _______________________________________________ >> 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/AwUBRxzHgb/UEA/xivvmEQKL9gCgrAgHCnmVu+GxneZEcBWFdL2u+yMAn0Vk > PXJo5XfDtQqGXHjHYAihaNWr > =C+gr > -----END PGP SIGNATURE----- > > _______________________________________________ > 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 Tue Oct 23 00:02:29 2007 From: bgreene at cisco.com (Barry Greene (bgreene)) Date: Mon, 22 Oct 2007 09:02:29 -0700 Subject: [SAVA] new bof proposal, take one In-Reply-To: <471CC880.20306@juniper.net> References: <471CC489.4000606@piuha.net> <471CC880.20306@juniper.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > So you are saying..... > > 1. it is a good thing to have source policing.... That funny. I guess you don't know me or know the work I've been doing to get source address spoofing technologies built (uRPF, IP Source Verify, DHCP Lease Query, etc.) and deployed. The deployment in really big SPs across the planet is important. > 2. it is a bad thing to have a recommended way in which to do it This is not needed. We have those documents now. If you want to work on a document, help finish the RIPE document. > ?? > > cheers, > > Mark > > Barry Greene (bgreene) wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Restating - again and again. > > > > The problem with deployment of source address policing in > networks is > > NOT Standardization! It is economics! > > > > This proposal is ignoring operational input from the > networks who have > > to deploy, operate and maintain the "framework." > > > > > > > > > >> -----Original Message----- > >> From: sava-bounces at mail.nrc.tsinghua.edu.cn > >> [mailto:sava-bounces at mail.nrc.tsinghua.edu.cn] On Behalf Of Jari > >> Arkko Sent: Monday, October 22, 2007 8:41 AM > >> To: SAVA Mailing List > >> Subject: [SAVA] new bof proposal, take one > >> > >> IETF BOF Proposal: Source Address Validation Improvements (SAVI) > >> > >> Co-chairs > >> Paul Ferguson > >> > >> Internet Area Directors: > >> Jari Arkko > >> Mark Townsley > >> > >> Technical Advisors: > >> Fred Baker > >> Jianping Wu > >> > >> Mailing Lists: > >> General Discussion: sava at nrc.tsinghua.edu.cn To Subscribe: > >> http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > >> Mailing List Archive: > >> http://mail.nrc.tsinghua.edu.cn/pipermail/sava/ Document > >> Repository: http://narl.tsinghua.edu.cn/sava > >> > >> The Current situation in IPv4 and IPv6 is that the source > IP address > >> is not checked in most cases. The purpose of the proposed "Source > >> Address Validation Improvements " working group is to standardise > >> mechanisms to prevent source address spoofing in the > access network. > >> Sepecifically: > >> > >> 1. Ensure that a host only uses IP source addresses that > are assigned > >> to it. > >> 2. Support IPv4 and IPv6 with mechanisms as similar as possible. > >> 3. Support multiple IPv4/IPv6 address assignment types. > >> > >> The source address validation points may include: > >> > >> 1. At the first hop in a local area network (where can see > the port > >> and MAC address information) 2. On an upstream exit > router. 3. Or on > >> a remote host. > >> > >> There are many cases in enterprise networks and > residential broadband > >> networks, all requiring their own solutions: > >> 1 Ethernet/IEEE 802.3. > >> 2 Wireless: 802.11/16. > >> 3 DSL. > >> 4 Cable Modem, etc. > >> > >> With this in mind, the goals of the WG are to complete the > following > >> work items: > >> 1 Document the problem statement and submit it to the IESG as an > >> Informational Standard. > >> 2 Survey all existing methods and evaluate compliance to the > >> framework model, then submit architectural framework > document to the > >> IESG. > >> 3 For exisiting solutions, document or encourage vendor to > document > >> as RFC. > >> 4 Identify any remaining gaps and devise solutions, then > submit them > >> to the IESG. > >> > >> Milestones: > >> Dec 07 Plan to hold BoF in IETF 70, asking for this Charter to be > >> approved Jan 08 Plan to get Final version of Charter > approved and WG > >> created. > >> March 08 Plan to submit WG Draft 00 on Problem Statement and > >> Architectural Framework for SAVI July 08 Plan to submit WG > draft 00 > >> SAVI solutions Dec 08 Plan to submit final Drafts of Problem > >> Statement and Framework to IESG March 09 Plan to submit > final Drafts > >> of SAVI solutions to IESG > >> > >> > >> > >> > >> _______________________________________________ > >> 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/AwUBRxzHgb/UEA/xivvmEQKL9gCgrAgHCnmVu+GxneZEcBWFdL2u+yMAn0Vk > > PXJo5XfDtQqGXHjHYAihaNWr > > =C+gr > > -----END PGP SIGNATURE----- > > _______________________________________________ > > > > 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 -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBRxzJlb/UEA/xivvmEQLSMgCfd7cym9khjUvXjASvqJEmXx2creoAn0K3 GXjDdx6B+SMyV5FJIXGm4DGL =L/ya -----END PGP SIGNATURE----- From junbi at cernet.edu.cn Tue Oct 23 01:27:21 2007 From: junbi at cernet.edu.cn (Jun Bi) Date: Tue, 23 Oct 2007 01:27:21 +0800 Subject: [SAVA] new bof proposal, take one References: <471CC489.4000606@piuha.net><471CC880.20306@juniper.net> Message-ID: <019c01c814d0$d0381ab0$7c18423b@IBMC9236A69C07> Hi Barry, I should say, this SAVI WG isn't going to ignore anything. Please see the goals: "3 For existing solutions, document or encourage vendor to document as RFC." So please join this WG and contribute your work to IETF. During the "interim meeting" held in Finland, I belive Fred introduced some of the cisco work. You may give the WG more inputs. BTW, you may already found that the WG goal is rescoped to the access network. thanks, Jun Bi . ----- Original Message ----- From: "Barry Greene (bgreene)" To: Cc: "SAVA Mailing List" Sent: Tuesday, October 23, 2007 12:02 AM Subject: Re: [SAVA] new bof proposal, take one > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >> So you are saying..... >> >> 1. it is a good thing to have source policing.... > > That funny. I guess you don't know me or know the work I've been > doing to get source address spoofing technologies built (uRPF, IP > Source Verify, DHCP Lease Query, etc.) and deployed. The deployment > in really big SPs across the planet is important. > >> 2. it is a bad thing to have a recommended way in which to do it > > This is not needed. We have those documents now. If you want to work > on a document, help finish the RIPE document. > > > >> ?? >> >> cheers, >> >> Mark >> >> Barry Greene (bgreene) wrote: >> > >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > Restating - again and again. >> > >> > The problem with deployment of source address policing in >> networks is >> > NOT Standardization! It is economics! >> > >> > This proposal is ignoring operational input from the >> networks who have >> > to deploy, operate and maintain the "framework." >> > >> > >> > >> > >> >> -----Original Message----- >> >> From: sava-bounces at mail.nrc.tsinghua.edu.cn >> >> [mailto:sava-bounces at mail.nrc.tsinghua.edu.cn] On Behalf Of Jari >> >> Arkko Sent: Monday, October 22, 2007 8:41 AM >> >> To: SAVA Mailing List >> >> Subject: [SAVA] new bof proposal, take one >> >> >> >> IETF BOF Proposal: Source Address Validation Improvements (SAVI) >> >> >> >> Co-chairs >> >> Paul Ferguson >> >> >> >> Internet Area Directors: >> >> Jari Arkko >> >> Mark Townsley >> >> >> >> Technical Advisors: >> >> Fred Baker >> >> Jianping Wu >> >> >> >> Mailing Lists: >> >> General Discussion: sava at nrc.tsinghua.edu.cn To Subscribe: >> >> http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava >> >> Mailing List Archive: >> >> http://mail.nrc.tsinghua.edu.cn/pipermail/sava/ Document >> >> Repository: http://narl.tsinghua.edu.cn/sava >> >> >> >> The Current situation in IPv4 and IPv6 is that the source >> IP address >> >> is not checked in most cases. The purpose of the proposed "Source >> >> Address Validation Improvements " working group is to standardise >> >> mechanisms to prevent source address spoofing in the >> access network. >> >> Sepecifically: >> >> >> >> 1. Ensure that a host only uses IP source addresses that >> are assigned >> >> to it. >> >> 2. Support IPv4 and IPv6 with mechanisms as similar as possible. >> >> 3. Support multiple IPv4/IPv6 address assignment types. >> >> >> >> The source address validation points may include: >> >> >> >> 1. At the first hop in a local area network (where can see >> the port >> >> and MAC address information) 2. On an upstream exit >> router. 3. Or on >> >> a remote host. >> >> >> >> There are many cases in enterprise networks and >> residential broadband >> >> networks, all requiring their own solutions: >> >> 1 Ethernet/IEEE 802.3. >> >> 2 Wireless: 802.11/16. >> >> 3 DSL. >> >> 4 Cable Modem, etc. >> >> >> >> With this in mind, the goals of the WG are to complete the >> following >> >> work items: >> >> 1 Document the problem statement and submit it to the IESG as an >> >> Informational Standard. >> >> 2 Survey all existing methods and evaluate compliance to the >> >> framework model, then submit architectural framework >> document to the >> >> IESG. >> >> 3 For exisiting solutions, document or encourage vendor to >> document >> >> as RFC. >> >> 4 Identify any remaining gaps and devise solutions, then >> submit them >> >> to the IESG. >> >> >> >> Milestones: >> >> Dec 07 Plan to hold BoF in IETF 70, asking for this Charter to be >> >> approved Jan 08 Plan to get Final version of Charter >> approved and WG >> >> created. >> >> March 08 Plan to submit WG Draft 00 on Problem Statement and >> >> Architectural Framework for SAVI July 08 Plan to submit WG >> draft 00 >> >> SAVI solutions Dec 08 Plan to submit final Drafts of Problem >> >> Statement and Framework to IESG March 09 Plan to submit >> final Drafts >> >> of SAVI solutions to IESG >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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/AwUBRxzHgb/UEA/xivvmEQKL9gCgrAgHCnmVu+GxneZEcBWFdL2u+yMAn0Vk >> > PXJo5XfDtQqGXHjHYAihaNWr >> > =C+gr >> > -----END PGP SIGNATURE----- >> > _______________________________________________ >> > > > 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 > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.1 > > iQA/AwUBRxzJlb/UEA/xivvmEQLSMgCfd7cym9khjUvXjASvqJEmXx2creoAn0K3 > GXjDdx6B+SMyV5FJIXGm4DGL > =L/ya > -----END PGP SIGNATURE----- > > _______________________________________________ > SAVA mailing list > SAVA at mail.nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > From bgreene at cisco.com Tue Oct 23 01:40:06 2007 From: bgreene at cisco.com (Barry Greene (bgreene)) Date: Mon, 22 Oct 2007 10:40:06 -0700 Subject: [SAVA] new bof proposal, take one In-Reply-To: <019c01c814d0$d0381ab0$7c18423b@IBMC9236A69C07> References: <471CC489.4000606@piuha.net><471CC880.20306@juniper.net> <019c01c814d0$d0381ab0$7c18423b@IBMC9236A69C07> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You can have a multitude of "technology," "solutions," and "standards" to achieve BCP38. But, if you do not take the factors of how you deploy, maintain, and manage cost, none of these "tools" will ever get deployed through out the Internet. I'm glad SAVA is waking up to the fact that there are other technologies. Now how about waking up to the fact that there have been people working to get deployment for close to a decade. That "deployment experience" needs to be pulled into any new IETF work. If not, then there is no need for a new WG. We already have BCP 38. > -----Original Message----- > From: Jun Bi [mailto:junbi at cernet.edu.cn] > Sent: Monday, October 22, 2007 10:27 AM > To: Barry Greene (bgreene); miw at juniper.net > Cc: SAVA Mailing List > Subject: Re: [SAVA] new bof proposal, take one > > Hi Barry, > > I should say, this SAVI WG isn't going to ignore anything. > Please see the goals: > "3 For existing solutions, document or encourage vendor to > document as RFC." > > So please join this WG and contribute your work to IETF. > During the "interim meeting" held in Finland, I belive Fred > introduced some of the cisco work. > You may give the WG more inputs. > > BTW, you may already found that the WG goal is rescoped to > the access network. > > thanks, > Jun Bi > . > > ----- Original Message ----- > From: "Barry Greene (bgreene)" > To: > Cc: "SAVA Mailing List" > Sent: Tuesday, October 23, 2007 12:02 AM > Subject: Re: [SAVA] new bof proposal, take one > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > >> So you are saying..... > >> > >> 1. it is a good thing to have source policing.... > > > > That funny. I guess you don't know me or know the work I've been > > doing to get source address spoofing technologies built (uRPF, IP > > Source Verify, DHCP Lease Query, etc.) and deployed. The deployment > > in really big SPs across the planet is important. > > > >> 2. it is a bad thing to have a recommended way in which to do it > > > > This is not needed. We have those documents now. If you want to work > > on a document, help finish the RIPE document. > > > > > > > >> ?? > >> > >> cheers, > >> > >> Mark > >> > >> Barry Greene (bgreene) wrote: > >> > > >> > -----BEGIN PGP SIGNED MESSAGE----- > >> > Hash: SHA1 > >> > > >> > Restating - again and again. > >> > > >> > The problem with deployment of source address policing in > >> networks is > >> > NOT Standardization! It is economics! > >> > > >> > This proposal is ignoring operational input from the > >> networks who have > >> > to deploy, operate and maintain the "framework." > >> > > >> > > >> > > >> > > >> >> -----Original Message----- > >> >> From: sava-bounces at mail.nrc.tsinghua.edu.cn > >> >> [mailto:sava-bounces at mail.nrc.tsinghua.edu.cn] On > Behalf Of Jari > >> >> Arkko Sent: Monday, October 22, 2007 8:41 AM > >> >> To: SAVA Mailing List > >> >> Subject: [SAVA] new bof proposal, take one > >> >> > >> >> IETF BOF Proposal: Source Address Validation Improvements (SAVI) > >> >> > >> >> Co-chairs > >> >> Paul Ferguson > >> >> > >> >> Internet Area Directors: > >> >> Jari Arkko > >> >> Mark Townsley > >> >> > >> >> Technical Advisors: > >> >> Fred Baker > >> >> Jianping Wu > >> >> > >> >> Mailing Lists: > >> >> General Discussion: sava at nrc.tsinghua.edu.cn To Subscribe: > >> >> http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > >> >> Mailing List Archive: > >> >> http://mail.nrc.tsinghua.edu.cn/pipermail/sava/ Document > >> >> Repository: http://narl.tsinghua.edu.cn/sava > >> >> > >> >> The Current situation in IPv4 and IPv6 is that the source > >> IP address > >> >> is not checked in most cases. The purpose of the > proposed "Source > >> >> Address Validation Improvements " working group is to > standardise > >> >> mechanisms to prevent source address spoofing in the > >> access network. > >> >> Sepecifically: > >> >> > >> >> 1. Ensure that a host only uses IP source addresses that > >> are assigned > >> >> to it. > >> >> 2. Support IPv4 and IPv6 with mechanisms as similar as possible. > >> >> 3. Support multiple IPv4/IPv6 address assignment types. > >> >> > >> >> The source address validation points may include: > >> >> > >> >> 1. At the first hop in a local area network (where can see > >> the port > >> >> and MAC address information) 2. On an upstream exit > >> router. 3. Or on > >> >> a remote host. > >> >> > >> >> There are many cases in enterprise networks and > >> residential broadband > >> >> networks, all requiring their own solutions: > >> >> 1 Ethernet/IEEE 802.3. > >> >> 2 Wireless: 802.11/16. > >> >> 3 DSL. > >> >> 4 Cable Modem, etc. > >> >> > >> >> With this in mind, the goals of the WG are to complete the > >> following > >> >> work items: > >> >> 1 Document the problem statement and submit it to the > IESG as an > >> >> Informational Standard. > >> >> 2 Survey all existing methods and evaluate compliance to the > >> >> framework model, then submit architectural framework > >> document to the > >> >> IESG. > >> >> 3 For exisiting solutions, document or encourage vendor to > >> document > >> >> as RFC. > >> >> 4 Identify any remaining gaps and devise solutions, then > >> submit them > >> >> to the IESG. > >> >> > >> >> Milestones: > >> >> Dec 07 Plan to hold BoF in IETF 70, asking for this > Charter to be > >> >> approved Jan 08 Plan to get Final version of Charter > >> approved and WG > >> >> created. > >> >> March 08 Plan to submit WG Draft 00 on Problem Statement and > >> >> Architectural Framework for SAVI July 08 Plan to submit WG > >> draft 00 > >> >> SAVI solutions Dec 08 Plan to submit final Drafts of Problem > >> >> Statement and Framework to IESG March 09 Plan to submit > >> final Drafts > >> >> of SAVI solutions to IESG > >> >> > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> 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/AwUBRxzHgb/UEA/xivvmEQKL9gCgrAgHCnmVu+GxneZEcBWFdL2u+yMAn0Vk > >> > PXJo5XfDtQqGXHjHYAihaNWr > >> > =C+gr > >> > -----END PGP SIGNATURE----- > >> > _______________________________________________ > >> > > > 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 > > > > -----BEGIN PGP SIGNATURE----- > > Version: PGP 8.1 > > > > iQA/AwUBRxzJlb/UEA/xivvmEQLSMgCfd7cym9khjUvXjASvqJEmXx2creoAn0K3 > > GXjDdx6B+SMyV5FJIXGm4DGL > > =L/ya > > -----END PGP SIGNATURE----- > > _______________________________________________ > > > > 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/AwUBRxzgdr/UEA/xivvmEQKARgCfYLA91UPxxIM+jyrDUV07pDss7CcAoKIU gQhczTU5NIRy3FJNcgwp2hG7 =IPj4 -----END PGP SIGNATURE----- From fred at cisco.com Tue Oct 23 02:59:14 2007 From: fred at cisco.com (Fred Baker) Date: Mon, 22 Oct 2007 11:59:14 -0700 Subject: [SAVA] new bof proposal, take one In-Reply-To: References: <471CC489.4000606@piuha.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 22, 2007, at 8:53 AM, Barry Greene (bgreene) wrote: > This proposal is ignoring operational input from the networks who > have to deploy, operate and maintain the "framework." Remind me. I thought it was brought to us by a network that wanted to deploy, operate, and maintain the framework? -----BEGIN PGP SIGNATURE----- iD8DBQFHHPMCbjEdbHIsm0MRAsTQAJ9QjV7IDu6MmnUrdkq/HRwSCPe9FwCfd6Jd DOqnC4myVxSqyKdN2OrPdbc= =5Z6w -----END PGP SIGNATURE----- From christian.vogt at nomadiclab.com Tue Oct 23 05:01:54 2007 From: christian.vogt at nomadiclab.com (Christian Vogt) Date: Tue, 23 Oct 2007 00:01:54 +0300 Subject: [SAVA] new bof proposal, take one In-Reply-To: References: <471CC489.4000606@piuha.net> Message-ID: <471D0FC2.8020608@nomadiclab.com> Marc: > - should it have a specific reference to MobileIP > support, since the use of MIP may have an impact on this > work? It would be worthwhile to depend this on the extent of deployment of Mobile IP*v4* without support for reverse tunneling because IP source addresses may be topologically incorrect only in case of this Mobile IP variant. If deployment of Mobile IPv4 without reverse tunneling is negligible, we may not need to handle Mobile IP separately in this working group. - Christian From junbi at cernet.edu.cn Tue Oct 23 13:28:54 2007 From: junbi at cernet.edu.cn (Jun Bi) Date: Tue, 23 Oct 2007 13:28:54 +0800 Subject: [SAVA] new bof proposal, take one References: <471CC489.4000606@piuha.net><471CC880.20306@juniper.net> <019c01c814d0$d0381ab0$7c18423b@IBMC9236A69C07> Message-ID: <03ae01c81535$9ec6fc70$7c18423b@IBMC9236A69C07> I believe the incentive mechnism for deployment is also within the scope of the proposed WG. I also believe any deployment experience form opereators or vendors are valuable inputs for this WG. thanks, Jun Bi ----- Original Message ----- From: "Barry Greene (bgreene)" To: "Jun Bi" ; Cc: "SAVA Mailing List" Sent: Tuesday, October 23, 2007 1:40 AM Subject: RE: [SAVA] new bof proposal, take one -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You can have a multitude of "technology," "solutions," and "standards" to achieve BCP38. But, if you do not take the factors of how you deploy, maintain, and manage cost, none of these "tools" will ever get deployed through out the Internet. I'm glad SAVA is waking up to the fact that there are other technologies. Now how about waking up to the fact that there have been people working to get deployment for close to a decade. That "deployment experience" needs to be pulled into any new IETF work. If not, then there is no need for a new WG. We already have BCP 38. > -----Original Message----- > From: Jun Bi [mailto:junbi at cernet.edu.cn] > Sent: Monday, October 22, 2007 10:27 AM > To: Barry Greene (bgreene); miw at juniper.net > Cc: SAVA Mailing List > Subject: Re: [SAVA] new bof proposal, take one > > Hi Barry, > > I should say, this SAVI WG isn't going to ignore anything. > Please see the goals: > "3 For existing solutions, document or encourage vendor to > document as RFC." > > So please join this WG and contribute your work to IETF. > During the "interim meeting" held in Finland, I belive Fred > introduced some of the cisco work. > You may give the WG more inputs. > > BTW, you may already found that the WG goal is rescoped to > the access network. > > thanks, > Jun Bi > . > > ----- Original Message ----- > From: "Barry Greene (bgreene)" > To: > Cc: "SAVA Mailing List" > Sent: Tuesday, October 23, 2007 12:02 AM > Subject: Re: [SAVA] new bof proposal, take one > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > >> So you are saying..... > >> > >> 1. it is a good thing to have source policing.... > > > > That funny. I guess you don't know me or know the work I've been > > doing to get source address spoofing technologies built (uRPF, IP > > Source Verify, DHCP Lease Query, etc.) and deployed. The deployment > > in really big SPs across the planet is important. > > > >> 2. it is a bad thing to have a recommended way in which to do it > > > > This is not needed. We have those documents now. If you want to work > > on a document, help finish the RIPE document. > > > > > > > >> ?? > >> > >> cheers, > >> > >> Mark > >> > >> Barry Greene (bgreene) wrote: > >> > > >> > -----BEGIN PGP SIGNED MESSAGE----- > >> > Hash: SHA1 > >> > > >> > Restating - again and again. > >> > > >> > The problem with deployment of source address policing in > >> networks is > >> > NOT Standardization! It is economics! > >> > > >> > This proposal is ignoring operational input from the > >> networks who have > >> > to deploy, operate and maintain the "framework." > >> > > >> > > >> > > >> > > >> >> -----Original Message----- > >> >> From: sava-bounces at mail.nrc.tsinghua.edu.cn > >> >> [mailto:sava-bounces at mail.nrc.tsinghua.edu.cn] On > Behalf Of Jari > >> >> Arkko Sent: Monday, October 22, 2007 8:41 AM > >> >> To: SAVA Mailing List > >> >> Subject: [SAVA] new bof proposal, take one > >> >> > >> >> IETF BOF Proposal: Source Address Validation Improvements (SAVI) > >> >> > >> >> Co-chairs > >> >> Paul Ferguson > >> >> > >> >> Internet Area Directors: > >> >> Jari Arkko > >> >> Mark Townsley > >> >> > >> >> Technical Advisors: > >> >> Fred Baker > >> >> Jianping Wu > >> >> > >> >> Mailing Lists: > >> >> General Discussion: sava at nrc.tsinghua.edu.cn To Subscribe: > >> >> http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > >> >> Mailing List Archive: > >> >> http://mail.nrc.tsinghua.edu.cn/pipermail/sava/ Document > >> >> Repository: http://narl.tsinghua.edu.cn/sava > >> >> > >> >> The Current situation in IPv4 and IPv6 is that the source > >> IP address > >> >> is not checked in most cases. The purpose of the > proposed "Source > >> >> Address Validation Improvements " working group is to > standardise > >> >> mechanisms to prevent source address spoofing in the > >> access network. > >> >> Sepecifically: > >> >> > >> >> 1. Ensure that a host only uses IP source addresses that > >> are assigned > >> >> to it. > >> >> 2. Support IPv4 and IPv6 with mechanisms as similar as possible. > >> >> 3. Support multiple IPv4/IPv6 address assignment types. > >> >> > >> >> The source address validation points may include: > >> >> > >> >> 1. At the first hop in a local area network (where can see > >> the port > >> >> and MAC address information) 2. On an upstream exit > >> router. 3. Or on > >> >> a remote host. > >> >> > >> >> There are many cases in enterprise networks and > >> residential broadband > >> >> networks, all requiring their own solutions: > >> >> 1 Ethernet/IEEE 802.3. > >> >> 2 Wireless: 802.11/16. > >> >> 3 DSL. > >> >> 4 Cable Modem, etc. > >> >> > >> >> With this in mind, the goals of the WG are to complete the > >> following > >> >> work items: > >> >> 1 Document the problem statement and submit it to the > IESG as an > >> >> Informational Standard. > >> >> 2 Survey all existing methods and evaluate compliance to the > >> >> framework model, then submit architectural framework > >> document to the > >> >> IESG. > >> >> 3 For exisiting solutions, document or encourage vendor to > >> document > >> >> as RFC. > >> >> 4 Identify any remaining gaps and devise solutions, then > >> submit them > >> >> to the IESG. > >> >> > >> >> Milestones: > >> >> Dec 07 Plan to hold BoF in IETF 70, asking for this > Charter to be > >> >> approved Jan 08 Plan to get Final version of Charter > >> approved and WG > >> >> created. > >> >> March 08 Plan to submit WG Draft 00 on Problem Statement and > >> >> Architectural Framework for SAVI July 08 Plan to submit WG > >> draft 00 > >> >> SAVI solutions Dec 08 Plan to submit final Drafts of Problem > >> >> Statement and Framework to IESG March 09 Plan to submit > >> final Drafts > >> >> of SAVI solutions to IESG > >> >> > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> 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/AwUBRxzHgb/UEA/xivvmEQKL9gCgrAgHCnmVu+GxneZEcBWFdL2u+yMAn0Vk > >> > PXJo5XfDtQqGXHjHYAihaNWr > >> > =C+gr > >> > -----END PGP SIGNATURE----- > >> > _______________________________________________ > >> > > > 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 > > > > -----BEGIN PGP SIGNATURE----- > > Version: PGP 8.1 > > > > iQA/AwUBRxzJlb/UEA/xivvmEQLSMgCfd7cym9khjUvXjASvqJEmXx2creoAn0K3 > > GXjDdx6B+SMyV5FJIXGm4DGL > > =L/ya > > -----END PGP SIGNATURE----- > > _______________________________________________ > > > > 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/AwUBRxzgdr/UEA/xivvmEQKARgCfYLA91UPxxIM+jyrDUV07pDss7CcAoKIU gQhczTU5NIRy3FJNcgwp2hG7 =IPj4 -----END PGP SIGNATURE----- From junbi at cernet.edu.cn Tue Oct 23 13:37:23 2007 From: junbi at cernet.edu.cn (Jun Bi) Date: Tue, 23 Oct 2007 13:37:23 +0800 Subject: [SAVA] new bof proposal, take one References: <471CC489.4000606@piuha.net> Message-ID: <03b501c81536$ca972720$7c18423b@IBMC9236A69C07> I think, as one of the network operators, CERNET is willing to deploy some cost-effective solutions so that the administrators and users can be away from the source address spoofing problem. thanks, Jun Bi ----- Original Message ----- From: "Fred Baker" To: "Barry Greene (bgreene)" Cc: "SAVA Mailing List" Sent: Tuesday, October 23, 2007 2:59 AM Subject: Re: [SAVA] new bof proposal, take one > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Oct 22, 2007, at 8:53 AM, Barry Greene (bgreene) wrote: > >> This proposal is ignoring operational input from the networks who >> have to deploy, operate and maintain the "framework." > > > Remind me. I thought it was brought to us by a network that wanted to > deploy, operate, and maintain the framework? From pekkas at netcore.fi Tue Oct 23 17:18:21 2007 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 23 Oct 2007 12:18:21 +0300 (EEST) Subject: [SAVA] new bof proposal, take one In-Reply-To: <471CC489.4000606@piuha.net> References: <471CC489.4000606@piuha.net> Message-ID: On Mon, 22 Oct 2007, Jari Arkko wrote: > The Current situation in IPv4 and IPv6 is that the source IP address > is not checked in most cases. The purpose of the proposed "Source > Address Validation Improvements " working group is to standardise > mechanisms to prevent source address spoofing in the access network. The first sentence seems somewhat loose, and the charter does not emphasize strongly enough its focus on host-specific checking. Maybe reword: 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 standardise mechanisms to prevent source address spoofing in the access network. > The source address validation points may include: > > 1. At the first hop in a local area network (where can see the port and > MAC address information) "hop" is not a good word here, as we're not talking about the _IP_ hop. Maybe: 1. At the first network device in a local area network (e.g., Ethernet switch, where you can see the port and MAC address information) [[ note: the term 'local area network' is somewhat ethernet-centric and a better more generic word would be better..]] > 2. On an upstream exit router. Too ambiguous: in the context of SAVI, you're referring to the first-hop router, right, not e.g., site's exit router? Maybe: 2. On the local area network's first-hop exit router(s). > 3. Or on a remote host. Misleading: in the context of SAVI, we're talking about the host in the same subnet. Remote host verification is out of scope. Maybe: 3. Or on another host in the same local area network. > With this in mind, the goals of the WG are to complete the following > work items: > 1 Document the problem statement and submit it to the IESG as an > Informational > Standard. s/Standard/RFC/ > 2 Survey all existing methods and evaluate compliance to the framework > model, > then submit architectural framework document to the IESG. "evaluate compliance to the framework model, ... submit architectural framework document". I'm not sure what this is supposed to mean. Which category would this document be? I guess you'd first write up the "framework model", look how existing mechanisms fit in there, revise as needed, and then submit the document to the IESG. Maybe the formulation of this could be more straightforward. Is this even needed? I suspect the problem statement draft needs to discuss existing approaches to some degree and maybe the framework would not be needed after all. > 3 For exisiting solutions, document or encourage vendor to document as RFC. Informational RFC? Through RFC-editor's process or through this WG? > 4 Identify any remaining gaps and devise solutions, then submit them to > the IESG. This seems to imply that the work items of the WG are not well thought out. If the WG would need to produce (or help significantly in others doing so) problem statement/framework/existing solutions, do we wait until that work is complete before starting something new? My suggestion would be that the WG would recharter after the first steps, i.e., when it thinks it knows what kind of protocol it needs to develop (if any). Getting a couple of general documents out and helping in vendors documenting, or documenting in the WG, existing solutions probably already takes 1-2 years (even with optimistic estimiates). > March 08 Plan to submit WG Draft 00 on Problem Statement and > Architectural Framework for SAVI > July 08 Plan to submit WG draft 00 SAVI solutions > Dec 08 Plan to submit final Drafts of Problem Statement and Framework to > IESG > March 09 Plan to submit final Drafts of SAVI solutions to IESG "draft 00 SAVI solutions" -- is that one document? March 09 DL seems to imply multiple drafts. -- 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 miw at juniper.net Tue Oct 23 23:44:48 2007 From: miw at juniper.net (Mark Williams) Date: Tue, 23 Oct 2007 23:44:48 +0800 Subject: [SAVA] new bof proposal, take two In-Reply-To: References: <471CC489.4000606@piuha.net> Message-ID: <471E16F0.5060108@juniper.net> I've incorporated most of these suggestions and a couple of others into the document attached. I didn't do anything about the three points below, not because I necessarily disagree but because they are probably worth more discussion. > 2 Survey all existing methods and evaluate compliance to the framework > model, > then submit architectural framework document to the IESG. "evaluate compliance to the framework model, ... submit architectural framework document". I'm not sure what this is supposed to mean. Which category would this document be? I guess you'd first write up the "framework model", look how existing mechanisms fit in there, revise as needed, and then submit the document to the IESG. Maybe the formulation of this could be more straightforward. Is this even needed? I suspect the problem statement draft needs to discuss existing approaches to some degree and maybe the framework would not be needed after all. > 3 For exisiting solutions, document or encourage vendor to document as RFC. Informational RFC? Through RFC-editor's process or through this WG? > 4 Identify any remaining gaps and devise solutions, then submit them to > the IESG. This seems to imply that the work items of the WG are not well thought out. If the WG would need to produce (or help significantly in others doing so) problem statement/framework/existing solutions, do we wait until that work is complete before starting something new? My suggestion would be that the WG would recharter after the first steps, i.e., when it thinks it knows what kind of protocol it needs to develop (if any). Getting a couple of general documents out and helping in vendors documenting, or documenting in the WG, existing solutions probably already takes 1-2 years (even with optimistic estimiates). Pekka Savola wrote: > > On Mon, 22 Oct 2007, Jari Arkko wrote: > > The Current situation in IPv4 and IPv6 is that the source IP address > > is not checked in most cases. The purpose of the proposed "Source > > Address Validation Improvements " working group is to standardise > > mechanisms to prevent source address spoofing in the access network. > > The first sentence seems somewhat loose, and the charter does not > emphasize strongly enough its focus on host-specific checking. > > Maybe reword: > > 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 standardise mechanisms to prevent source address > spoofing in the access network. > > > The source address validation points may include: > > > > 1. At the first hop in a local area network (where can see the port and > > MAC address information) > > "hop" is not a good word here, as we're not talking about the _IP_ > hop. Maybe: > > 1. At the first network device in a local area network (e.g., Ethernet > switch, where you can see the port and MAC address information) > > [[ note: the term 'local area network' is somewhat ethernet-centric > and a better more generic word would be better..]] > > > 2. On an upstream exit router. > > Too ambiguous: in the context of SAVI, you're referring to the > first-hop router, right, not e.g., site's exit router? Maybe: > > 2. On the local area network's first-hop exit router(s). > > > 3. Or on a remote host. > > Misleading: in the context of SAVI, we're talking about the host in > the same subnet. Remote host verification is out of scope. Maybe: > > 3. Or on another host in the same local area network. > > > With this in mind, the goals of the WG are to complete the following > > work items: > > 1 Document the problem statement and submit it to the IESG as an > > Informational > > Standard. > > s/Standard/RFC/ > > > 2 Survey all existing methods and evaluate compliance to the framework > > model, > > then submit architectural framework document to the IESG. > > "evaluate compliance to the framework model, ... submit architectural > framework document". I'm not sure what this is supposed to mean. > > Which category would this document be? > > I guess you'd first write up the "framework model", look how existing > mechanisms fit in there, revise as needed, and then submit the > document to the IESG. > > Maybe the formulation of this could be more straightforward. > > Is this even needed? I suspect the problem statement draft needs to > discuss existing approaches to some degree and maybe the framework > would not be needed after all. > > > 3 For exisiting solutions, document or encourage vendor to document > as RFC. > > Informational RFC? Through RFC-editor's process or through this WG? > > > 4 Identify any remaining gaps and devise solutions, then submit them to > > the IESG. > > This seems to imply that the work items of the WG are not well thought > out. If the WG would need to produce (or help significantly in others > doing so) problem statement/framework/existing solutions, do we wait > until that work is complete before starting something new? > > My suggestion would be that the WG would recharter after the first > steps, i.e., when it thinks it knows what kind of protocol it needs to > develop (if any). Getting a couple of general documents out and > helping in vendors documenting, or documenting in the WG, existing > solutions probably already takes 1-2 years (even with optimistic > estimiates). > > > March 08 Plan to submit WG Draft 00 on Problem Statement and > > Architectural Framework for SAVI > > July 08 Plan to submit WG draft 00 SAVI solutions > > Dec 08 Plan to submit final Drafts of Problem Statement and Framework to > > IESG > > March 09 Plan to submit final Drafts of SAVI solutions to IESG > > "draft 00 SAVI solutions" -- is that one document? March 09 DL seems > to imply multiple drafts. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > _______________________________________________ > 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 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: savi-ietf70-BoF proposal.txt Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20071023/a82f2eed/attachment-0001.txt From hartmans-ietf at mit.edu Wed Oct 24 01:16:18 2007 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Tue, 23 Oct 2007 13:16:18 -0400 Subject: [SAVA] new bof proposal, take one In-Reply-To: <471CC489.4000606@piuha.net> (Jari Arkko's message of "Mon, 22 Oct 2007 17:40:57 +0200") References: <471CC489.4000606@piuha.net> Message-ID: Jari, thanks for this proposal. This proposed charter is clear enough that I can think about it and come to a crisp opinion on whether I think the work should proceed. That has not been true in the past. To that end, I don't think the problem stated in this charter justifies creation of a working group. The charter makes it clear that we're not even sure that there are gaps in this area requiring standardization within the IETF. The charter also hints that the problem space is likely to be very layer-2 specific. I do not think the criteria of RFC 2418 for forming a working group have been met. I don't think a second BOF will help. A study group is inappropriate because there has not been demonstrated IETF consensus that the problem area is one we'd like to work on. So, I think we should say no. I appreciate your efforts in getting to a point where it's clear enough what we're discussing. From junbi at cernet.edu.cn Wed Oct 24 11:42:07 2007 From: junbi at cernet.edu.cn (Jun Bi) Date: Wed, 24 Oct 2007 11:42:07 +0800 Subject: [SAVA] new bof proposal, take one References: <471CC489.4000606@piuha.net> Message-ID: <06ce01c815ef$db848000$7c18423b@IBMC9236A69C07> Hi Sam, I am not quit catch your point. Do you mean, the new SAVI WG should include the work rather than the access network ? Let me try to give some explanation. First, because the problem to fix in the whole Internet is too complicated, so during the parts months, most participants suggested that the WG should resolve the problem in the access network as the first step. The access network is an administration level that is feasible to be deployed with doable solutions, which are based on the improvement of existing (but may no be fully IETF standardized ) technologies. The remaining problem in the Internet will be resolved later. Actually, the "interim meeting" did discuss the inter-/intra-AS problem and ideas, please refer to documents on the meeting website. Second, it's not the layer2-only stuff. At the access network level, we have difference validation points (e.g. switch, exit router), so we need difference src addr validation solutions for different validation points. I guess only the first validation point is layer-2 related (because at other validation point, the Layer-2 information carried in the packet/frame is lost). So that will be within the scope of IETF. Thanks, Jun Bi ----- Original Message ----- From: "Sam Hartman" To: "Jari Arkko" Cc: "SAVA Mailing List" Sent: Wednesday, October 24, 2007 1:16 AM Subject: Re: [SAVA] new bof proposal, take one > Jari, thanks for this proposal. > > This proposed charter is clear enough that I can think about it and > come to a crisp opinion on whether I think the work should proceed. > That has not been true in the past. > > To that end, I don't think the problem stated in this charter > justifies creation of a working group. > > The charter makes it clear that we're not even sure that there are > gaps in this area requiring standardization within the IETF. The > charter also hints that the problem space is likely to be very layer-2 > specific. > > I do not think the criteria of RFC 2418 for forming a working group > have been met. I don't think a second BOF will help. A study group > is inappropriate because there has not been demonstrated IETF > consensus that the problem area is one we'd like to work on. So, I > think we should say no. > > I appreciate your efforts in getting to a point where it's clear > enough what we're discussing. > > _______________________________________________ > 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 Oct 24 16:59:55 2007 From: jari.arkko at piuha.net (Jari Arkko) Date: Wed, 24 Oct 2007 10:59:55 +0200 Subject: [SAVA] new bof proposal, take three In-Reply-To: <471E16F0.5060108@juniper.net> References: <471CC489.4000606@piuha.net> <471E16F0.5060108@juniper.net> Message-ID: <471F098B.6010506@piuha.net> I tend to agree with the comments made so far. Version one was way too vague about the scope of the proposed work, and some of that still remains in version two. But we need everyone to wipe their minds about the earlier SAVA proposals. What we have now on the table is completely different, and very focused. For background, the SAVA effort started a year ago from a very ambitious plan that involved improvements in being able to validate decisions made networks on the other side of the planet. For various reasons the IETF community has not found this approach worthwhile to pursue. The primary reason in my mind is that the required changes in the routers and supporting infrastructure would be extremely costly for what appears to be an improvement of debatable value. However, this does not necessarily imply that there is no work in this space. Indeed, when talking about the topic we found vendors and users doing simple things to provide better support against address spoofing in their local networks. With this in mind, we met in Helsinki a couple of weeks ago to do a reset and see if there was something concrete that we could do. My conclusion from those discussions was that there's plenty of research topics in this space that should stay as such. But at the same time, there were also concrete items relating to checking for address spoofing in a local network that would seem to benefit from standardization. One of these items was what Cisco and other vendors do for IPv4 address spoofing checks in a switch; the question is whether an IETF specification of such behavior would be useful. I think so, because an IETF document of an existing practice can make it more attractive to a wider range of users and vendors. Another item was the same feature in IPv6. This is currently not implemented, and is technically more challenging than the IPv4 version. However, it appeared to be a feasible task for IETF work. And I believe doing this would be useful, because if left to individual programmers, we probably have many different versions of it, some not completely functional in all circumstances. Relating to Sam's comment: yes, this is a link layer dependent effort. But making IP run over link layers is within IETF's scope, and I believe we are better equipped than the link layer organizations to think about what IP layer messages need to be tracked to achieve the desired functionality. I personally believe these two tasks would justify a focused WG. However, one of the gating items is whether the proponents of the WG are capable of delivering an early draft of the IPv6 specification. As of today, I still do not have this draft. Fred, Pekka: please submit the IPv4 version that you already have, and see if you can come up with the early version for IPv6 -- preferably today! (We need to take decisions tomorrow.) Please find a third revision of the charter proposal below: Source Address Validation Improvements (SAVI) Co-chairs TBD Internet Area Directors: Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: sava at nrc.tsinghua.edu.cn To Subscribe: http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava Mailing List Archive: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/ Document Repository: http://narl.tsinghua.edu.cn/sava 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 Oct 07 First draft on IPv6 solution Oct 07 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 miw at juniper.net Wed Oct 24 22:51:33 2007 From: miw at juniper.net (Mark Williams) Date: Wed, 24 Oct 2007 22:51:33 +0800 Subject: [SAVA] new bof proposal, take one In-Reply-To: References: <471CC489.4000606@piuha.net> Message-ID: <471F5BF5.5060108@juniper.net> Let me give a perspective on SAVI based on a previous life. Note here that I am talking specifically about SAVI and not SAVA. SAVA is basically two problems: (1.) How do I establish the validity of a packet's source address, and (2.) Once it is established, how do I preserve the knowledge of its validity as the packet traverses the Internet. SAVI only addresses problem (1). It's not the full story, but it is a precondition for really solving (2), and it is useful in itself as I will discuss. Before I ran off and joined the circus I was the engineer in charge of design, operation and procurement of a campus network with about 7,000 Ethernet ports which was quite big in those days in Australia. One of the issues I had was that I had no bulletproof way of ascribing activity to an individual. I could take dumps of activity using TCPDump, but since IP addresses and of course MAC addresses were easily spoofable within a broadcast domain, about the only way to collar people was to catch them when they used dialup (because our dialup servers, unlike Ethernet were *not* spoofable) or hope that they used the campus email servers. Note that we didn't have the time or the interest to chase minor stuff like copyright offendors. In those distant days the RIAA had not yet bought our legislators. In order to get us to go to the expense and trouble of building a case against someone, it had to be a case of racketeering, drug dealing, child pornography or major hacking, which are more common on campuses than one would like to think. I guess if you have a community in excess of 30,000 people some of them wil not be nice people. So IP address spoofing in the campus was definitely a problem then. Is it still a problem? in fact, yesterday I was talking to an engineer for an NREN backbone and his opinion was that most campus networks in his country were still spoofable. I asked why people didn't specify infrastructure that had something that could enforce anti-spoofing. He said it was because there are no standards. If there are no standards, you can't specify in a public tender process. "If I specify IP source Guard, then everyone other than Cisco will sue us". In other words, in the many parts of the world where public tender processes are important in procurement, they need an RFC or at least a generally accepted de facto standard in order to be able to buy the appropriate kit. I would respectfully submit: 1) Source IP address spoofing *is* a problem, and the ease with which Source IP addresses can be spoofed in many places is a fundamental flaw in the way the Internet is built today. It cases problems in the assignment of responsibility for evil/illegal acts and it also represents a threat to the Internet's infrastructure. Packets with Spoofed Source Addresses are Undeniably unwanted. 2) IP source address spoofing in the access network is a problem for which there are solutions. Some of them have been implemented. There needs to be at least one openly specified set of mechanisms so that there is a good way for people to specify and procure compliant equipment. 3) Vendors will implement what comes out of the process. (in fact, some already have implemented proprietary solutions, simply because of customer demand.) 4) There is a community of people within the IETF who want to work on this, and they are drawn from a mix of vendors, backbone operators and campus network operators. 5) Since this is specific to IP networking (yes, each mechanism may be link-layer specific, but the problem is that of validating an IP address, not a link-layer address), the IETF is the right place for this work to be done. The only other candidate might be the IEEE, but I feel they are not the right choice. Someone suggested a European Internet Registry as the right place to specify a global standard. I certainly differ on that score. Each of these points is open to debate, which is obviously welcome, but I'd suggest if they stand, then the WG charter and goals satisfies section 2.1 of RFC2418 cheers, Mark Sam Hartman wrote: > Jari, thanks for this proposal. > > This proposed charter is clear enough that I can think about it and > come to a crisp opinion on whether I think the work should proceed. > That has not been true in the past. > > To that end, I don't think the problem stated in this charter > justifies creation of a working group. > > The charter makes it clear that we're not even sure that there are > gaps in this area requiring standardization within the IETF. The > charter also hints that the problem space is likely to be very layer-2 > specific. > > I do not think the criteria of RFC 2418 for forming a working group > have been met. I don't think a second BOF will help. A study group > is inappropriate because there has not been demonstrated IETF > consensus that the problem area is one we'd like to work on. So, I > think we should say no. > > I appreciate your efforts in getting to a point where it's clear > enough what we're discussing. > > _______________________________________________ > 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 hartmans-ietf at mit.edu Wed Oct 24 23:31:33 2007 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Wed, 24 Oct 2007 11:31:33 -0400 Subject: [SAVA] new bof proposal, take one In-Reply-To: <06ce01c815ef$db848000$7c18423b@IBMC9236A69C07> (Jun Bi's message of "Wed, 24 Oct 2007 11:42:07 +0800") References: <471CC489.4000606@piuha.net> <06ce01c815ef$db848000$7c18423b@IBMC9236A69C07> Message-ID: >>>>> "Jun" == Jun Bi writes: Jun> Hi Sam, I am not quit catch your point. Do you mean, the new Jun> SAVI WG should include the work rather than the access No, I mean the WG should not exist. From junbi at cernet.edu.cn Thu Oct 25 11:09:20 2007 From: junbi at cernet.edu.cn (Jun Bi) Date: Thu, 25 Oct 2007 11:09:20 +0800 Subject: [SAVA] new bof proposal, take one References: <471CC489.4000606@piuha.net> <06ce01c815ef$db848000$7c18423b@IBMC9236A69C07> Message-ID: <002001c816b4$7160e900$7c18423b@IBMC9236A69C07> Now, some peoeple discussed your questions and I found the bof proposal is also improved according to suggestions posted on the mailing-list. So do you feel the new charter is better ? Begards, Jun ----- Original Message ----- From: "Sam Hartman" To: "Jun Bi" Cc: "Jari Arkko" ; "SAVA Mailing List" Sent: Wednesday, October 24, 2007 11:31 PM Subject: Re: [SAVA] new bof proposal, take one >>>>>> "Jun" == Jun Bi writes: > > Jun> Hi Sam, I am not quit catch your point. Do you mean, the new > Jun> SAVI WG should include the work rather than the access > > No, I mean the WG should not exist. > From Hannes.Tschofenig at gmx.net Sun Oct 28 17:40:05 2007 From: Hannes.Tschofenig at gmx.net (Hannes Tschofenig) Date: Sun, 28 Oct 2007 10:40:05 +0100 Subject: [SAVA] Pictures from the Helsinki Meeting In-Reply-To: <002001c816b4$7160e900$7c18423b@IBMC9236A69C07> References: <471CC489.4000606@piuha.net> <06ce01c815ef$db848000$7c18423b@IBMC9236A69C07> <002001c816b4$7160e900$7c18423b@IBMC9236A69C07> Message-ID: <472458F5.4000107@gmx.net> I promised to send the pictures from the Helsinki SAVA meeting around. Here they are: http://www.tschofenig.com/private/SAVA_Oct2007/ Ciao Hannes From jari.arkko at piuha.net Mon Oct 29 15:50:53 2007 From: jari.arkko at piuha.net (Jari Arkko) Date: Mon, 29 Oct 2007 09:50:53 +0200 Subject: [SAVA] SAVI BOF in Vancouver Message-ID: <472590DD.4010502@piuha.net> Your BOF has been approved for Vancouver, for the "take three" scope proposal. However, I would like to see a an early draft of the IPv6 solution proposal in the next two weeks. And the submission of the IPv4 solution proposal that we've already seen but that does not exist in the I-D directories. Otherwise we do not have a lot to discuss. Please work on this, possibly other drafts, revised charter proposals, etc. in the coming weeks. I am also looking for chairs for the BOF, given that Paul will not be able to come to Vancouver. Please volunteer by sending mail to me. Jari