From fergdawg at netzero.net Mon Jul 2 10:16:34 2007 From: fergdawg at netzero.net (Paul Ferguson) Date: Mon, 2 Jul 2007 02:16:34 GMT Subject: [SAVA] Next steps regarding SAVA Message-ID: <20070701.191634.6341.1@webmail16.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070702/d89cd05c/attachment.txt From miw at juniper.net Fri Jul 6 22:18:59 2007 From: miw at juniper.net (Mark Williams) Date: Fri, 06 Jul 2007 22:18:59 +0800 Subject: [SAVA] Drafts submitted to IETF.org Message-ID: <468E4F53.1070600@juniper.net> Folks, The attached drafts have been submitted to ietf-drafts. 1. draft-wu-sava-framework-01 2. draft-wu-sava-solution-firsthop-eap-00 3. draft-bi-sava-solution-ipv6-edge-network-signature-00 draft-wu-sava-testbed-experience-01 is still being edited, will be submitted tomorrow. draft-wu-sava-problem-statement-01 I am waiting on Ferg to see if he has any more edits. cheers, 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 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: draft-wu-sava-solution-firsthop-00.txt Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070706/19ca09bf/attachment-0003.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: draft-wu-sava-framework-01.txt Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070706/19ca09bf/attachment-0004.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: draft-bi-sava-solution-ipv6-edge-network-signature-00.txt Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070706/19ca09bf/attachment-0005.txt From miw at juniper.net Sun Jul 8 13:22:21 2007 From: miw at juniper.net (Mark Williams) Date: Sun, 08 Jul 2007 13:22:21 +0800 Subject: [SAVA] 2 more drafts submitted.... Message-ID: <4690748D.2000805@juniper.net> Folks, just fired off these two drafts: 1. draft-wu-sava-problem-statement-01 - updated problem statement, as edited/rejigged by fergie 2. draft-wu-sava-testbed-exprience-01 - significantly edited in terms of figures and test result section added. cheers, 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 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: draft-wu-sava-testbed-experience-01.txt Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070708/22015d19/attachment-0002.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: draft-wu-sava-problem-statement-01.txt Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070708/22015d19/attachment-0003.txt From jari.arkko at piuha.net Sun Jul 8 19:48:36 2007 From: jari.arkko at piuha.net (Jari Arkko) Date: Sun, 08 Jul 2007 14:48:36 +0300 Subject: [SAVA] 2 more drafts submitted.... In-Reply-To: <4690748D.2000805@juniper.net> References: <4690748D.2000805@juniper.net> Message-ID: <4690CF14.9020006@piuha.net> Thanks for submitting these. Jari Mark Williams kirjoitti: > Folks, > > just fired off these two drafts: > > 1. draft-wu-sava-problem-statement-01 - updated problem statement, > as edited/rejigged by fergie > 2. draft-wu-sava-testbed-exprience-01 - significantly edited in > terms of figures and test result section added. > > cheers, > > Mark > > ------------------------------------------------------------------------ > > _______________________________________________ > SAVA mailing list > SAVA at mail.nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava From denghui02 at gmail.com Mon Jul 9 17:35:36 2007 From: denghui02 at gmail.com (Hui Deng) Date: Mon, 9 Jul 2007 17:35:36 +0800 Subject: [SAVA] two drafts w.r.t SAVA Message-ID: <1d38a3350707090235h23542281x988bae823ebb585f@mail.gmail.com> Hello, all I revised some part and posted, any advices are appreciated, http://www.ietf.org/internet-drafts/draft-deng-sava-mobileip-problem-statement-00.txt http://www.ietf.org/internet-drafts/draft-deng-sava-multihoming-problem-statement-00.txt many thanks -Hui From jari.arkko at piuha.net Wed Jul 11 18:50:20 2007 From: jari.arkko at piuha.net (Jari Arkko) Date: Wed, 11 Jul 2007 13:50:20 +0300 Subject: [SAVA] Next steps regarding SAVA In-Reply-To: <20070701.191634.6341.1@webmail16.lax.untd.com> References: <20070701.191634.6341.1@webmail16.lax.untd.com> Message-ID: <4694B5EC.8000305@piuha.net> Paul, > Having said that (Jari), do we still need to have a brief > teleconference call prior to IETF week in Chicago? > I _do_ plan on helping move forward the SAVA work/agenda, so > please pipe up on what you folks think is "next steps". > One of the next steps, publication of the various drafts has gone ahead well. Thanks everyone. The next step from my perspective is getting together a presentation for the open internet area meeting in Chicago. The presentation should highlight what the potential new direction for SAVA is in the local subnet and bring up some of potential work items and pointers to early drafts. The main goal is to get a feeling from the room of whether this direction is reasonable, and gather interested people so that we can progress the work after Chicago. We need a volunteer that puts this presentation together and leads the discussion. Can you Paul make sure that someone has this task? If you think it would be useful, we could also talk about this in a phone conf. I'm available this week Thu 7:30 AM PST, Thu 10 AM PST, Fri 7 AM PST, and next week on Monday any time or Thursday 11 AM PST. I would like to see an early version of the presentation by start of next week. Jari From bgreene at cisco.com Tue Jul 24 05:00:50 2007 From: bgreene at cisco.com (Barry Greene (bgreene)) Date: Mon, 23 Jul 2007 14:00:50 -0700 Subject: [SAVA] FW: I-D ACTION:draft-wu-sava-solution-firsthop-eap-00.txt Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This work is directly replicating work already completed with: 1. Cable Source Verify (DHCP Lease Query) http://www.cisco.com/en/US/tech/tk86/tk803/technologies_tech_note09186 a00800a7828.shtml 2. IP Source Guard http://www.cisco.com/en/US/products/hw/switches/ps708/products_configu ration_guide_chapter09186a008022f26c.html#wp1083306 The Source Address Management Server (SAMS) and Interface to the Authentication Server (IAS) are both equal to a DHCP or AAA/Radius server. Both of these technologies are deployed in really huge Cable and ETTX/MetroE providers. So, what is new? Why was there _no_ due diligence done? DHCP Lease Query work is already in RFC4388 as a proposed standard (ftp://ftp.rfc-editor.org/in-notes/rfc4388.txt) and is also part if DOCSIS 3.0. My biggest problem with the SAVA work and IETF is the 'driver's' theme of ignoring all other academic and operational work in this sphere. - -----Original Message----- From: Internet-Drafts at ietf.org [mailto:Internet-Drafts at ietf.org] Sent: Monday, July 23, 2007 10:15 AM To: i-d-announce at ietf.org Subject: I-D ACTION:draft-wu-sava-solution-firsthop-eap-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A First-Hop Source Address Validation Solution for SAVA Author(s) : J. Wu, et al. Filename : draft-wu-sava-solution-firsthop-eap-00.txt Pages : 9 Date : 2007-7-23 This document describes a solution for preventing source address spoofing in the first hop, local subnet of the Internet. The main idea of the solution is to get a dynamic binding between IP address and access switch port. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wu-sava-solution-firsthop-ea p-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-wu-sava-solution-firsthop-eap-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-wu-sava-solution-firsthop-eap-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBRqUXAr/UEA/xivvmEQL8AQCfYy/mUI4AWdVN6k+B4XyY3ZWWxmIAnRNP ZuBiJtVNx3ARAh58hpStyKpk =Uyrx -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: ATT2307521.TXT Type: application/octet-stream Size: 249 bytes Desc: ATT2307521.TXT Url : http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070723/80f8cecc/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: draft-wu-sava-solution-firsthop-eap-00.URL Type: application/octet-stream Size: 103 bytes Desc: draft-wu-sava-solution-firsthop-eap-00.URL Url : http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070723/80f8cecc/attachment-0001.obj -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT2307522.txt Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070723/80f8cecc/attachment.txt From miw at juniper.net Tue Jul 24 08:16:35 2007 From: miw at juniper.net (Mark Williams) Date: Tue, 24 Jul 2007 08:16:35 +0800 Subject: [SAVA] FW: I-D ACTION:draft-wu-sava-solution-firsthop-eap-00.txt In-Reply-To: References: Message-ID: <46A544E3.2010408@juniper.net> *sigh* Present a framework without the solutions filled in and you get accused of presenting a problem without solutions. Colour in the boxes with an existing solution and you get accused of re-inventing the wheel or copying somebody else's work. In my presentation to the INT open meeting this afternoon, I was at some pains to point out that there were already many technologies out there that probably conform to the framework and that most of the work for the first hop validation in SAVA will be documentation/survey of existing methods for SAVA. If it turns out that there is no actual need for new protocols and/or mechanisms at this level then that is a good thing. There will need to be many methods, because organisations dole out addresses and do authentication and access control in different ways. The draft actually mentions one implementation that uses EAP/802.1x and RADIUS. RFC4388 solves the main problem with DHCP snooping (state loss in the snooper causes security loss) which is a good thing. But the draft in question did not actually propose DHCP snooping other than to say it was an alternative candidate so accusations of "direct replication" are quite far from the mark here. cheers, Mark Barry Greene (bgreene) wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > This work is directly replicating work already completed with: > > 1. Cable Source Verify (DHCP Lease Query) > http://www.cisco.com/en/US/tech/tk86/tk803/technologies_tech_note09186 > a00800a7828.shtml > > 2. IP Source Guard > http://www.cisco.com/en/US/products/hw/switches/ps708/products_configu > ration_guide_chapter09186a008022f26c.html#wp1083306 > > The Source Address Management Server (SAMS) and Interface to the > Authentication Server (IAS) are both equal to a DHCP or AAA/Radius > server. > > Both of these technologies are deployed in really huge Cable and > ETTX/MetroE providers. > > So, what is new? Why was there _no_ due diligence done? > > DHCP Lease Query work is already in RFC4388 as a proposed standard > (ftp://ftp.rfc-editor.org/in-notes/rfc4388.txt) and is also part if > DOCSIS 3.0. > > My biggest problem with the SAVA work and IETF is the 'driver's' > theme of ignoring all other academic and operational work in this > sphere. > > > > - -----Original Message----- > From: Internet-Drafts at ietf.org [mailto:Internet-Drafts at ietf.org] > Sent: Monday, July 23, 2007 10:15 AM > To: i-d-announce at ietf.org > Subject: I-D ACTION:draft-wu-sava-solution-firsthop-eap-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A First-Hop Source Address Validation Solution > for SAVA > Author(s) : J. Wu, et al. > Filename : draft-wu-sava-solution-firsthop-eap-00.txt > Pages : 9 > Date : 2007-7-23 > > This document describes a solution for preventing source address > spoofing in the first hop, local subnet of the Internet. The main > idea of the solution is to get a dynamic binding between IP > address > and access switch port. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wu-sava-solution-firsthop-ea > p-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request at ietf.org with the word unsubscribe in the body > of > the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-wu-sava-solution-firsthop-eap-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv at ietf.org. > In the body type: > "FILE > /internet-drafts/draft-wu-sava-solution-firsthop-eap-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.1 > > iQA/AwUBRqUXAr/UEA/xivvmEQL8AQCfYy/mUI4AWdVN6k+B4XyY3ZWWxmIAnRNP > ZuBiJtVNx3ARAh58hpStyKpk > =Uyrx > -----END PGP SIGNATURE----- > > -- "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 jari.arkko at piuha.net Tue Jul 24 08:32:25 2007 From: jari.arkko at piuha.net (Jari Arkko) Date: Mon, 23 Jul 2007 19:32:25 -0500 Subject: [SAVA] FW: I-D ACTION:draft-wu-sava-solution-firsthop-eap-00.txt In-Reply-To: <46A544E3.2010408@juniper.net> References: <46A544E3.2010408@juniper.net> Message-ID: <46A54899.6080104@piuha.net> I can confirm that the existence of solutions is well-known by everyone who has been involved in this discussion. If pointers were missing in some document, that is an oversight, not an attempt to claim originality or avoid giving credit where it is due. The question I would pose is: if vendors have solutions in this space, is there need or interest in documenting some of them in an IETF standard? I.e., - are the solutions relevant for the users? - do we think we could find consensus in the IETF that they should indeed be standard solutions? - is there willingness from the vendors and others to spend effort in doing this? Jari From bgreene at cisco.com Tue Jul 24 09:09:09 2007 From: bgreene at cisco.com (Barry Greene (bgreene)) Date: Mon, 23 Jul 2007 18:09:09 -0700 Subject: [SAVA] FW: I-D ACTION:draft-wu-sava-solution-firsthop-eap-00.txt In-Reply-To: <46A54899.6080104@piuha.net> References: <46A544E3.2010408@juniper.net> <46A54899.6080104@piuha.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > The question I would pose is: if vendors have solutions in > this space, is there need or interest in documenting some of > them in an IETF standard? I.e., > > - are the solutions relevant for the users? There are source address validation techniques used by a wide range of networks today. Are they relevant? Yes. What the SAVA work has never demonstrated a willingness to tackle is a complete survey of the work that is done today. In fact, I think SAVA is pulling resources away from the work we started on this in RIPE. In other word, I think SAVA is becoming a distraction to the work flow that was already in progress before SAVA started. > - do we think we could find consensus in the IETF that > they should indeed be standard solutions? Been there - done that. We have BCPs. We have the DHCP Lease Query work. We have the Diameter work. In other words, work never stopped on source address validation techniques and approaches in the IETF. > - is there willingness from the vendors and others > to spend effort in doing this? Good question. I wonder on that one. Speaking for my experience in Cisco, we've opened many of the techniques so that any vendor can code and deploy them. Most of the time operator pressure needs to be applied to get our peers to code the work. -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBRqVOx7/UEA/xivvmEQJ2pACg46iJnMkyce0ab5jfPJfLzAP0ZK0AoMeF RhkdLfJ0/aV8HwAHu142uuXM =sAyg -----END PGP SIGNATURE----- From fergdawg at netzero.net Tue Jul 24 09:26:10 2007 From: fergdawg at netzero.net (Paul Ferguson) Date: Tue, 24 Jul 2007 01:26:10 GMT Subject: [SAVA] FW: I-D ACTION:draft-wu-sava-solution-firsthop-eap-00.txt Message-ID: <20070723.182610.11112.0@webmail26.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070724/3acc142b/attachment.txt From whaddad at tcs.hut.fi Tue Jul 24 09:44:39 2007 From: whaddad at tcs.hut.fi (Wassim Haddad) Date: Tue, 24 Jul 2007 04:44:39 +0300 (EEST) Subject: [SAVA] SAVA: Prefix Reachability Detection Message-ID: Hi, We have submitted a new proposal which enables a prefix reachability detection, i.e., location authentication. The protocol is described in draft-haddad-sava-prefix-reachability-detection-00. Comments are appreciated. Regards, Wassim H. From jari.arkko at piuha.net Tue Jul 24 09:54:57 2007 From: jari.arkko at piuha.net (Jari Arkko) Date: Mon, 23 Jul 2007 20:54:57 -0500 Subject: [SAVA] FW: I-D ACTION:draft-wu-sava-solution-firsthop-eap-00.txt In-Reply-To: References: <46A544E3.2010408@juniper.net> <46A54899.6080104@piuha.net> Message-ID: <46A55BF1.2030702@piuha.net> Barry, > >> - is there willingness from the vendors and others > >> to spend effort in doing this? > > Good question. I wonder on that one. Speaking for my experience in > Cisco, we've opened many of the techniques so that any vendor can > code and deploy them. Most of the time operator pressure needs to be > applied to get our peers to code the work. So, the incentives for you or other vendors to do something relate to either (a) improving the solutions or their completeness is some manner or (b) true interest in having a standard solution as opposed to marketing a vendor-specific solution or being happy with an industry standard. The latter relates typically to customer push to do something, or need to interoperate. With regards to the first item, are the currently solutions complete? Can they handle IPv6 as well as IPv4? Are all the components in place, either in vendor docs or in some of the IETF components that you mentioned? AAA/DHCP/IPv4/ IPv6/stateless autoconfig, etc? Jari From miw at juniper.net Fri Jul 27 08:40:22 2007 From: miw at juniper.net (Mark Williams) Date: Fri, 27 Jul 2007 08:40:22 +0800 Subject: [SAVA] IETF 69 update Message-ID: <46A93EF6.6050407@juniper.net> All, as you will know, there was no SAVA BoF at IETF 69 in Chicago, with BoF decision deferred to IETF 70 in Vancouver. All the same, there was SAVA activity at IETF 69: * 5-minute update presentation (attached) about the rescoping of SAVA to focus on the first-hop for potential chartering after Vancouver. In the main this work would be survey of existing mechanisms, proprietary and standard, for IPv4 and IPv6, followed by documentation work and gap analysis. Where there are gaps mechanisms may be proposed to fill them. It could be seen as an update and extension of BCP38. * Some meetings working on updated presentation for proposed BoF at Vancouver (version 0.5 attached), review and revision of the testbed draft with a view to publication as an experimental RFC, and the creation of an applicability statement based on real-world data. More on these later. (Anybody who has real-world data on attacks, spoofing or otherwise, if you are willing to have it published in an applicability draft, then please contact me!) * Tentatively, and assuming that we make sufficient progress to make it worthwhile, we are looking at having an interim meeting in Helsinki in the last week of September (some time in the week of 24-28 Sep Most likely). Watch the list for more announcements on this. cheers, Mark ----------------------------------------------------------------- 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 -------------- A non-text attachment was scrubbed... Name: SAVA-IETF69-v0.5.ppt Type: application/vnd.ms-powerpoint Size: 2692608 bytes Desc: not available Url : http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070727/5c68cbee/attachment-0002.ppt -------------- next part -------------- A non-text attachment was scrubbed... Name: SAVA Update and Refocus-v4.ppt Type: application/vnd.ms-powerpoint Size: 23552 bytes Desc: not available Url : http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070727/5c68cbee/attachment-0003.ppt