From tianbin at cernet.edu.cn Wed May 2 00:06:03 2007 From: tianbin at cernet.edu.cn (Bin Tian) Date: Wed, 02 May 2007 00:06:03 +0800 Subject: [SAVA] test from Bin Tian Message-ID: <4637656B.6050303@cernet.edu.cn> sava mailing list test From junbi at cernet.edu.cn Wed May 2 01:12:59 2007 From: junbi at cernet.edu.cn (Jun Bi) Date: Wed, 2 May 2007 01:12:59 +0800 Subject: [SAVA] test email Message-ID: <001801c78c14$00daead0$082018ac@junbipc> Test. Jun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070502/a73fa41a/attachment.html From junbi at cernet.edu.cn Wed May 2 01:13:08 2007 From: junbi at cernet.edu.cn (Jun Bi) Date: Wed, 2 May 2007 01:13:08 +0800 Subject: [SAVA] test email Message-ID: <001901c78c14$05613640$082018ac@junbipc> Test. Jun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070502/0a1c7e27/attachment.htm From Paul_Ferguson at trendmicro.com Wed May 2 01:41:44 2007 From: Paul_Ferguson at trendmicro.com (Paul_Ferguson at trendmicro.com) Date: Tue, 1 May 2007 10:41:44 -0700 Subject: [SAVA] Fwd: [spoofing-tf] BCP38 Business Case Document Message-ID: Hello, I've tried posting this to the list a few times already, but the SAVA list seems to have been broken for a few days. I've been told that it is fixed now, so let's try again. If you haven't seen this yet, I think it is peripherally interesting to some of our efforts here. - ferg p.s. If this message makes it through, I would like to ask Mark Williams to post the notes from our SAVA meeting in Beijing on April 22, and begin some active dialog on a game plan for Chicago... [snip] From: Daniel Karrenberg To: RIPE IP Anti-Spoofing Task Force Subject: [spoofing-tf] BCP38 Business Case Document Date: Thu, 26 Apr 2007 16:14:31 +0200 Here is the latest draft of the "Network Hygiene Pays Off" document. The goal is to publish this after Talinn. Daniel ---- "Network Hygiene Pays Off" The Business Case for IP Source Address Verification Joao Luis Silva Damas Daniel Karrenberg v0.3 Tue Apr 24 09:45:15 CEST 2007 Introduction IP source address verification entirely prevents a class of prevalent reflector-type DDoS attacks, helps to track down attacking hosts and simplifies some network management tasks. Yet a significant number of ISPs do not deploy it at the edge of their networks. Common wisdom seems to be that doing so would be expensive and would only help they "other guy" who is being attacked. This memo tries to contrast common wisdom with some facts. What is BCP38 BCP 38 is a "Best Current Practice" document of the IETF. BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. BCP 38 has been updated by BCP 84, RFC3704. No Confidence in IP Source Addresses is Bad Suppose you need to investigate some unusual traffic flows or you just plain want to analyze current traffic load. If you do not do BCP38 there is absolutely nothing you can get to know about the source of a packet from the packet alone. You cannot trust the source address at all. They packet could have entered your network *anywhere*. Can that be good? Suppose someone launches an attack on one of your customers with packets that appear to come from another customer. The victim will likely request that you take action and stop the harmful traffic that appears to originate from another customer of yours. If you do not do BCP38 you will have to tell the victim that this traffic could come from anywhere and that you cannot determine very quickly where the traffic is indeed coming from. Someone Can Pretend to be You Even worse, if you do not do BCP38 an attacker can launch an attack with packets that appear to be coming from one of the machines you operate yourself. Imagine the reaction of a customer that gets attacked by such packets. Are they going to trust you when you explain it is not really you? What will they think if you tell them that your network operating practices allow such masquerading? Imagine the cost of that. Good Practice is Not Hard It is not hard to prevent such a scenario. You simply have to do BCP38 towards your customers and drop all packets with internal source addresses coming in from external peerings. Once you have done that you *know* exactly who has sent a packet with an internal source address and you also know that any packet with an external source address must have come in via one of the external peerings. Some multi-homing customers may require special configuration efforts. However these are neither impossible or very costly if implemented well. Our how-to documents explain the technical details. Since large classes of customers cannot be multi-homed to start with, you can gain a lot by starting to do BCP38 for them. Doing BCP38 Helps A Lot and Builds Confidence Doing BCP38 helps a lot with analyzing anomalies and makes understanding normal traffic load very much more reliable. In case any attacks or anomalies do happen, you can determine with any source within your own network or from any customer with confidence, simply by looking at the traffic itself! The decision about any countermeasures can be made very quickly and without any involved specialist traceback analysis. In case the source of the attack traffic is external, you can also state that with confidence to your customers and take action. Reflector Attacks Cannot Happen Between Customers If you do not do BCP38 one customer can attack another with a DoS reflector attack. Consider your responsibility and possible liability if this were possible. If you do BCP38 your customers cannot do this to each other and any reflector attack traffic has to come from outside your network, thus form outside your direct responsibility. Doing BCP38 is Good Publicity Showing that you operate your network responsibly and safely is good publicity; stating that you do BCP38 is helps with that. Showing responsibility for operating safely discourages regulation and legislation of operating practices. Consider the difficulty to convince policy makers that enabling users to lie about their "caller-ID" is your normal operating practice. Consider All Costs When considering the cost of implementing BCP38 in your network, you should consider the costs of not doing so together with the costs for implementation of BCP38 itself. The savings in the network management area and in mitigation of DoS attacks may well outweigh the implementation costs. The added good publicity and confidence in good operating practices should not be neglected either. Testimonials of ISPs Who Do BCP38 [Add ISP statements about experiences, illustrating both cost and benefits.] [snip] -- "Fergie", a.k.a. Paul Ferguson Network Architect, Office of the CTO Trend Micro, Inc., San Jose, CA paul_ferguson at trendmicro.com TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From rg03 at mails.tsinghua.edu.cn Wed May 2 02:09:44 2007 From: rg03 at mails.tsinghua.edu.cn (Ren Gang) Date: Wed, 2 May 2007 02:09:44 +0800 Subject: [SAVA] =?gb2312?b?tPC4tDogIEZ3ZDogW3Nwb29maW5nLXRmXSBCQ1AzOCBC?= =?gb2312?b?dXNpbmVzcyBDYXNlIERvY3VtZW50?= In-Reply-To: Message-ID: <000c01c78c1b$e6f4b170$cf32fea9@SONYG> Hi,Paul. This time I received the mail. Ren Gang -----????----- ???: sava-bounces at nrc.tsinghua.edu.cn [mailto:sava-bounces at nrc.tsinghua.edu.cn] ?? Paul_Ferguson at trendmicro.com ????: 2007?5?2? 1:42 ???: sava at nrc.tsinghua.edu.cn ??: [SAVA] Fwd: [spoofing-tf] BCP38 Business Case Document Hello, I've tried posting this to the list a few times already, but the SAVA list seems to have been broken for a few days. I've been told that it is fixed now, so let's try again. If you haven't seen this yet, I think it is peripherally interesting to some of our efforts here. - ferg p.s. If this message makes it through, I would like to ask Mark Williams to post the notes from our SAVA meeting in Beijing on April 22, and begin some active dialog on a game plan for Chicago... [snip] From: Daniel Karrenberg To: RIPE IP Anti-Spoofing Task Force Subject: [spoofing-tf] BCP38 Business Case Document Date: Thu, 26 Apr 2007 16:14:31 +0200 Here is the latest draft of the "Network Hygiene Pays Off" document. The goal is to publish this after Talinn. Daniel ---- "Network Hygiene Pays Off" The Business Case for IP Source Address Verification Joao Luis Silva Damas Daniel Karrenberg v0.3 Tue Apr 24 09:45:15 CEST 2007 Introduction IP source address verification entirely prevents a class of prevalent reflector-type DDoS attacks, helps to track down attacking hosts and simplifies some network management tasks. Yet a significant number of ISPs do not deploy it at the edge of their networks. Common wisdom seems to be that doing so would be expensive and would only help they "other guy" who is being attacked. This memo tries to contrast common wisdom with some facts. What is BCP38 BCP 38 is a "Best Current Practice" document of the IETF. BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. BCP 38 has been updated by BCP 84, RFC3704. No Confidence in IP Source Addresses is Bad Suppose you need to investigate some unusual traffic flows or you just plain want to analyze current traffic load. If you do not do BCP38 there is absolutely nothing you can get to know about the source of a packet from the packet alone. You cannot trust the source address at all. They packet could have entered your network *anywhere*. Can that be good? Suppose someone launches an attack on one of your customers with packets that appear to come from another customer. The victim will likely request that you take action and stop the harmful traffic that appears to originate from another customer of yours. If you do not do BCP38 you will have to tell the victim that this traffic could come from anywhere and that you cannot determine very quickly where the traffic is indeed coming from. Someone Can Pretend to be You Even worse, if you do not do BCP38 an attacker can launch an attack with packets that appear to be coming from one of the machines you operate yourself. Imagine the reaction of a customer that gets attacked by such packets. Are they going to trust you when you explain it is not really you? What will they think if you tell them that your network operating practices allow such masquerading? Imagine the cost of that. Good Practice is Not Hard It is not hard to prevent such a scenario. You simply have to do BCP38 towards your customers and drop all packets with internal source addresses coming in from external peerings. Once you have done that you *know* exactly who has sent a packet with an internal source address and you also know that any packet with an external source address must have come in via one of the external peerings. Some multi-homing customers may require special configuration efforts. However these are neither impossible or very costly if implemented well. Our how-to documents explain the technical details. Since large classes of customers cannot be multi-homed to start with, you can gain a lot by starting to do BCP38 for them. Doing BCP38 Helps A Lot and Builds Confidence Doing BCP38 helps a lot with analyzing anomalies and makes understanding normal traffic load very much more reliable. In case any attacks or anomalies do happen, you can determine with any source within your own network or from any customer with confidence, simply by looking at the traffic itself! The decision about any countermeasures can be made very quickly and without any involved specialist traceback analysis. In case the source of the attack traffic is external, you can also state that with confidence to your customers and take action. Reflector Attacks Cannot Happen Between Customers If you do not do BCP38 one customer can attack another with a DoS reflector attack. Consider your responsibility and possible liability if this were possible. If you do BCP38 your customers cannot do this to each other and any reflector attack traffic has to come from outside your network, thus form outside your direct responsibility. Doing BCP38 is Good Publicity Showing that you operate your network responsibly and safely is good publicity; stating that you do BCP38 is helps with that. Showing responsibility for operating safely discourages regulation and legislation of operating practices. Consider the difficulty to convince policy makers that enabling users to lie about their "caller-ID" is your normal operating practice. Consider All Costs When considering the cost of implementing BCP38 in your network, you should consider the costs of not doing so together with the costs for implementation of BCP38 itself. The savings in the network management area and in mitigation of DoS attacks may well outweigh the implementation costs. The added good publicity and confidence in good operating practices should not be neglected either. Testimonials of ISPs Who Do BCP38 [Add ISP statements about experiences, illustrating both cost and benefits.] [snip] -- "Fergie", a.k.a. Paul Ferguson Network Architect, Office of the CTO Trend Micro, Inc., San Jose, CA paul_ferguson at trendmicro.com TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. _______________________________________________ SAVA mailing list SAVA at nrc.tsinghua.edu.cn http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava From Paul_Ferguson at trendmicro.com Wed May 2 02:33:10 2007 From: Paul_Ferguson at trendmicro.com (Paul_Ferguson at trendmicro.com) Date: Tue, 1 May 2007 11:33:10 -0700 Subject: [SAVA] Still having problems with the list? [Was: RE: Fwd: [spoofing-tf] BCP38 Business Case Document] In-Reply-To: <000c01c78c1b$e6f4b170$cf32fea9@SONYG> References: <000c01c78c1b$e6f4b170$cf32fea9@SONYG> Message-ID: > From: Ren Gang [mailto:rg03 at mails.tsinghua.edu.cn] > Sent: Tuesday, May 01, 2007 11:10 AM > To: Paul Ferguson (RD-US); sava at nrc.tsinghua.edu.cn > Subject: ??: [SAVA] Fwd: [spoofing-tf] BCP38 Business Case Document > > Hi,Paul. > This time I received the mail. > Ren Gang > Well, I have another external e-mail address that is subscribed to the SAVA list that hasn't received that message yet (or any others since this problem originally ocurred). Also, the list archives still do not appear to be working properly: http://www.nrc.tsinghua.edu.cn/pipermail/sava/ FYI, - ferg -- "Fergie", a.k.a. Paul Ferguson Network Architect, Office of the CTO Trend Micro, Inc., San Jose, CA paul_ferguson at trendmicro.com TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From fred at cisco.com Wed May 2 02:50:18 2007 From: fred at cisco.com (Fred Baker) Date: Tue, 1 May 2007 11:50:18 -0700 Subject: [SAVA] test from Bin Tian In-Reply-To: <4637656B.6050303@cernet.edu.cn> References: <4637656B.6050303@cernet.edu.cn> Message-ID: <6BC1E14F-A4C3-4F4D-9496-DB9EC2737C52@cisco.com> I received this. It is the first note I have received from the list in quite a while. I have been told that it was only supporting participants on IPv6 networks. What is the current status? On May 1, 2007, at 9:06 AM, Bin Tian wrote: > sava mailing list test > > _______________________________________________ > SAVA mailing list > SAVA at nrc.tsinghua.edu.cn > http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava From tianbin at cernet.edu.cn Wed May 2 09:27:12 2007 From: tianbin at cernet.edu.cn (Bin Tian) Date: Wed, 02 May 2007 09:27:12 +0800 Subject: [SAVA] test from Bin Tian In-Reply-To: <6BC1E14F-A4C3-4F4D-9496-DB9EC2737C52@cisco.com> References: <4637656B.6050303@cernet.edu.cn> <6BC1E14F-A4C3-4F4D-9496-DB9EC2737C52@cisco.com> Message-ID: <4637E8F0.3040607@cernet.edu.cn> Hi, It should be the same as before. The new server and the old one are on the same subnet. And it's dual stack. I changed the MTA software to exim4. It do support IPv6. The MTA log told me that it's trying to deliever by IPv6 when the other end has AAAA record. I have been told to solve the problem and I have no idea about the exact status before. If there are something wrong, please let me know. Best regards, Bin Tian Fred Baker wrote: > I received this. It is the first note I have received from the list in > quite a while. I have been told that it was only supporting participants > on IPv6 networks. What is the current status? > > On May 1, 2007, at 9:06 AM, Bin Tian wrote: > >> sava mailing list test >> >> _______________________________________________ >> SAVA mailing list >> SAVA at nrc.tsinghua.edu.cn >> http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava > > From miw at juniper.net Wed May 2 10:05:34 2007 From: miw at juniper.net (Mark Williams) Date: Wed, 02 May 2007 10:05:34 +0800 Subject: [SAVA] Notes from SAVA Interim Workshop 21st April, 2007 Message-ID: <4637F1EE.8070602@juniper.net> [resend because of some issues with the list last week.] Folks, meeting notes and presentations attached. 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 -------------- A non-text attachment was scrubbed... Name: Sava-Fred-1.ppt Type: application/vnd.ms-powerpoint Size: 986112 bytes Desc: not available Url : http://www.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070502/a9515c11/attachment-0003.ppt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: meeting-notes-070421.txt Url: http://www.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070502/a9515c11/attachment-0001.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: SAVA Potential Solution and Deployment-20070421-bis.ppt Type: application/vnd.ms-powerpoint Size: 2843648 bytes Desc: not available Url : http://www.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070502/a9515c11/attachment-0004.ppt -------------- next part -------------- A non-text attachment was scrubbed... Name: SAVA_Interim_Mtg-Paul.ppt Type: application/vnd.ms-powerpoint Size: 2018816 bytes Desc: not available Url : http://www.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070502/a9515c11/attachment-0005.ppt From fergdawg at netzero.net Thu May 3 14:00:42 2007 From: fergdawg at netzero.net (Fergie) Date: Thu, 3 May 2007 06:00:42 GMT Subject: [SAVA] test Message-ID: <20070502.230127.808.2125373@webmail07.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://www.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070503/ac14b683/attachment.txt From Paul_Ferguson at trendmicro.com Thu May 3 14:06:20 2007 From: Paul_Ferguson at trendmicro.com (Paul_Ferguson at trendmicro.com) Date: Wed, 2 May 2007 23:06:20 -0700 Subject: [SAVA] SAVA mailing list still broken [WAS: RE: Notes from SAVA Interim Workshop 21st April, 2007] In-Reply-To: <4637F1EE.8070602@juniper.net> References: <4637F1EE.8070602@juniper.net> Message-ID: Hello, The SAVA mailing list still appears to be broken -- it is still not distributing mail properly to subscribed participants, nor is it archiving e-mails -- both functions which are required going forward. Personally, I'm willing to wait until the end of this week for it to be _completely_ repaired/fixed, but after that, I think that if we wish to continue discussions on this topic, we will have to find another home for the SAVA mailing list. We have work to get done, and the current broken state of the mailing list is really standing in the way of facilitating an open discussion forum to that end. Please let me know how you folks want to proceed on this. Thanks, - ferg -- "Fergie", a.k.a. Paul Ferguson Network Architect, Office of the CTO Trend Micro, Inc., San Jose, CA paul_ferguson at trendmicro.com TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From Paul_Ferguson at trendmicro.com Thu May 3 14:09:23 2007 From: Paul_Ferguson at trendmicro.com (Paul_Ferguson at trendmicro.com) Date: Wed, 2 May 2007 23:09:23 -0700 Subject: [SAVA] SAVA mailing list still broken [WAS: RE: Notes from SAVA Interim Workshop 21st April, 2007] References: <4637F1EE.8070602@juniper.net> Message-ID: Okay, so the mail distribution issue seems to have been worked out, but the archives are still broken. Could someone please fix that? Thanks, - ferg > -----Original Message----- > From: Paul Ferguson (RD-US) > Sent: Wednesday, May 02, 2007 11:06 PM > To: sava at nrc.tsinghua.edu.cn > Cc: 'Jun Bi'; RenGang; jianping at cernet.edu.cn; rbonica at juniper.net; 'Fred > Baker'; Lixia Zhang; 'jari.arkko at piuha.net'; 'miw at juniper.net' > Subject: SAVA mailing list still broken [WAS: RE: [SAVA] Notes from SAVA > Interim Workshop 21st April, 2007] > Importance: High > > Hello, > > The SAVA mailing list still appears to be broken -- it is still not > distributing mail properly to subscribed participants, nor is it archiving > e-mails -- both functions which are required going forward. > > Personally, I'm willing to wait until the end of this week for it to be > _completely_ repaired/fixed, but after that, I think that if we wish to > continue discussions on this topic, we will have to find another home for > the SAVA mailing list. > > We have work to get done, and the current broken state of the mailing list > is really standing in the way of facilitating an open discussion forum to > that end. > > Please let me know how you folks want to proceed on this. > > Thanks, > > - ferg > > -- > "Fergie", a.k.a. Paul Ferguson > Network Architect, Office of the CTO > Trend Micro, Inc., San Jose, CA > paul_ferguson at trendmicro.com TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From junbi at cernet.edu.cn Thu May 3 16:42:44 2007 From: junbi at cernet.edu.cn (Jun Bi) Date: Thu, 3 May 2007 16:42:44 +0800 Subject: [SAVA] SAVA mailing list still broken [WAS: RE: Notes from SAVA Interim Workshop 21st April, 2007] References: <4637F1EE.8070602@juniper.net> Message-ID: <004901c78d5f$0afd4b10$6401a8c0@junbipc> Hi Paul, When fixing the mailing-list problem, the new mail archive is moved to http://mail.nrc.tsinghua.edu.cn/pipermail/sava/. Sorry for the inconvenient. Thanks, Jun Bi ----- Original Message ----- From: To: Cc: ; ; ; ; ; ; ; ; Sent: Thursday, May 03, 2007 2:09 PM Subject: RE: SAVA mailing list still broken [WAS: RE: [SAVA] Notes from SAVA Interim Workshop 21st April, 2007] Okay, so the mail distribution issue seems to have been worked out, but the archives are still broken. Could someone please fix that? Thanks, - ferg > -----Original Message----- > From: Paul Ferguson (RD-US) > Sent: Wednesday, May 02, 2007 11:06 PM > To: sava at nrc.tsinghua.edu.cn > Cc: 'Jun Bi'; RenGang; jianping at cernet.edu.cn; rbonica at juniper.net; 'Fred > Baker'; Lixia Zhang; 'jari.arkko at piuha.net'; 'miw at juniper.net' > Subject: SAVA mailing list still broken [WAS: RE: [SAVA] Notes from SAVA > Interim Workshop 21st April, 2007] > Importance: High > > Hello, > > The SAVA mailing list still appears to be broken -- it is still not > distributing mail properly to subscribed participants, nor is it archiving > e-mails -- both functions which are required going forward. > > Personally, I'm willing to wait until the end of this week for it to be > _completely_ repaired/fixed, but after that, I think that if we wish to > continue discussions on this topic, we will have to find another home for > the SAVA mailing list. > > We have work to get done, and the current broken state of the mailing list > is really standing in the way of facilitating an open discussion forum to > that end. > > Please let me know how you folks want to proceed on this. > > Thanks, > > - ferg > > -- > "Fergie", a.k.a. Paul Ferguson > Network Architect, Office of the CTO > Trend Micro, Inc., San Jose, CA > paul_ferguson at trendmicro.com TREND MICRO EMAIL NOTICE The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From jaap at NLnetLabs.nl Thu May 3 20:52:22 2007 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Thu, 03 May 2007 14:52:22 +0200 Subject: [SAVA] test from Bin Tian In-Reply-To: Your message of Wed, 02 May 2007 09:27:12 +0800. <4637E8F0.3040607@cernet.edu.cn> Message-ID: <200705031252.l43CqMT3096724@bartok.nlnetlabs.nl> Hi, I also didn't see abything on this list for a long time. It should be the same as before. The new server and the old one are on the same subnet. And it's dual stack. I changed the MTA software to exim4. It do support IPv6. The MTA log told me that it's trying to deliever by IPv6 when the other end has AAAA record. I have been told to solve the problem and I have no idea about the exact status before. If there are something wrong, please let me know. It turns out that the machine/domain which is hosting this list (SAVA) is marken as SPAM by spamassassin. If I look at the headers, that is because the Razor2 filetr is (default swithed on in spamassassin) is maring this at such, see the header below. jaap Return-Path: sava-bounces at nrc.tsinghua.edu.cn Delivery-Date: Wed May 2 03:29:14 2007 Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by bartok.nlnetlabs.nl (8.14.1/8.14.1) with ESMTP id l421T4NK066014 for ; Wed, 2 May 2007 03:29:05 +0200 (CEST) (envelope-from sava-bounces at nrc.tsinghua.edu.cn) Received: from debian ([IPv6:2001:da8:200:101:20d:60ff:fe6f:a7f2]) by open.nlnetlabs.nl (8.13.8/8.13.8) with ESMTP id l421Sx5N030368 for ; Wed, 2 May 2007 03:29:00 +0200 (CEST) (envelope-from sava-bounces at nrc.tsinghua.edu.cn) Received: from localhost ([127.0.0.1] helo=[166.111.8.146]) by debian with esmtp (Exim 4.63) (envelope-from ) id 1Hj3dC-0002ti-SO; Wed, 02 May 2007 09:27:46 +0800 Received: from sea.net.edu.cn ([202.112.3.66] helo=cernet.edu.cn) by debian with smtp (Exim 4.63) (envelope-from ) id 1Hj3dB-0002td-0W for sava at nrc.tsinghua.edu.cn; Wed, 02 May 2007 09:27:45 +0800 Received: from [203.91.120.152]([203.91.120.152]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm284638225b; Wed, 02 May 2007 09:27:44 +0800 Message-ID: <4637E8F0.3040607 at cernet.edu.cn> Date: Wed, 02 May 2007 09:27:12 +0800 From: Bin Tian User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Fred Baker References: <4637656B.6050303 at cernet.edu.cn> <6BC1E14F-A4C3-4F4D-9496-DB9EC2737C52 at cisco.com> In-Reply-To: <6BC1E14F-A4C3-4F4D-9496-DB9EC2737C52 at cisco.com> X-Enigmail-Version: 0.94.2.0 X-AIMC-AUTH: tianbin X-AIMC-MAILFROM: tianbin at cernet.edu.cn X-AIMC-Msg-ID: 9zKdDjRB Cc: sava at nrc.tsinghua.edu.cn Subject: Re: [SAVA] test from Bin Tian X-BeenThere: sava at nrc.tsinghua.edu.cn X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sava-bounces at nrc.tsinghua.edu.cn Errors-To: sava-bounces at nrc.tsinghua.edu.cn X-Spam-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_00, RAZOR2_CF_RANGE_51_100,RAZOR2_CF_RANGE_E8_51_100,RAZOR2_CHECK autolearn=no version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on bartok.nlnetlabs.nl X-Razor2-Warning: SPAM. Hi, It should be the same as before. The new server and the old one are on the same subnet. And it's dual stack. I changed the MTA software to exim4. It do support IPv6. The MTA log told me that it's trying to deliever by IPv6 when the other end has AAAA record. etc.. From fergdawg at netzero.net Fri May 4 01:34:17 2007 From: fergdawg at netzero.net (Fergie) Date: Thu, 3 May 2007 17:34:17 GMT Subject: [SAVA] test Message-ID: <20070503.121004.3483.2995214@webmail12.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://www.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070503/97685f98/attachment.txt From fergdawg at netzero.net Fri May 4 00:42:58 2007 From: fergdawg at netzero.net (Fergie) Date: Thu, 3 May 2007 16:42:58 GMT Subject: [SAVA] SAVA mailing list still broken [WAS: RE: Notes from SAVA In terim Workshop 21st April, 2007] Message-ID: <20070503.122121.3483.2995837@webmail12.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://www.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070503/5df8fa01/attachment.txt From fergdawg at netzero.net Sat May 5 02:38:23 2007 From: fergdawg at netzero.net (Fergie) Date: Fri, 4 May 2007 18:38:23 GMT Subject: [SAVA] draft-ietf-opsec-infrastructure-security-01 - InfrastructureHiding Message-ID: <20070504.113826.3483.3008034@webmail12.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://www.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070504/432fbc05/attachment.txt From junbi at cernet.edu.cn Tue May 8 18:52:20 2007 From: junbi at cernet.edu.cn (Jun Bi) Date: Tue, 8 May 2007 18:52:20 +0800 Subject: [SAVA] New SAVA list archives Message-ID: <03bb01c7915e$f4244700$6401a8c0@junbipc> Hi, We moved the sava mail-list to a new server recently. The new list archives: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/ The existing mail-list membership remain unchanged. For new members to subscribe: http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava Best Regards, Jun Bi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070508/e26234a2/attachment.html From fergdawg at netzero.net Thu May 10 09:46:11 2007 From: fergdawg at netzero.net (Fergie) Date: Thu, 10 May 2007 01:46:11 GMT Subject: [SAVA] Some thoughts on the direction(s) SAVA should take... Message-ID: <20070509.184617.724.1330089@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/20070510/85617cac/attachment.txt From fergdawg at netzero.net Thu May 10 10:14:24 2007 From: fergdawg at netzero.net (Fergie) Date: Thu, 10 May 2007 02:14:24 GMT Subject: [SAVA] Some thoughts on the direction(s) SAVA should take... Message-ID: <20070509.191512.724.1330420@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/20070510/189228f4/attachment.txt From miaofy at huawei.com Thu May 10 12:14:49 2007 From: miaofy at huawei.com (Miao Fuyou) Date: Thu, 10 May 2007 12:14:49 +0800 Subject: [SAVA] Some thoughts on the direction(s) SAVA should take... In-Reply-To: <20070509.184617.724.1330089@webmail26.lax.untd.com> Message-ID: <007e01c792b9$c0a1c220$9f0c6f0a@china.huawei.com> > Which is why I think that whatever work is brought to the > IETF (if it is brought into the IETF) needs to be somewhat > compartmentalized, given defined deliverables & milestones, > such that the architecture lends it self to various sorts of > locally implemented _mechanism_, but a commonly defined and > implemented end-to-end transitive implementation. > > So, what I propose is to break SAVA work items into > _at_least_ two parts: local subnet/first-hop source address > validation, and secondly, how to communicate that this has > been done upstream. I like this compartmentalization, it clearly shows the primary (but, functionally quite different) parts of SAVA: validation and end-to-end transition of trust. There are quite some mechanisms for subnet/first hop source address validation, such as BCP38 and MAC/IP/Line binding checking. Probably there will be some more BCP documents on how to first hop address checking, however, I believe the major work for these group would be in end-to-end transition of trust part. Miao From pekkas at netcore.fi Thu May 10 13:09:49 2007 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 10 May 2007 08:09:49 +0300 (EEST) Subject: [SAVA] Some thoughts on the direction(s) SAVA should take... In-Reply-To: <20070509.184617.724.1330089@webmail26.lax.untd.com> References: <20070509.184617.724.1330089@webmail26.lax.untd.com> Message-ID: Hi, I agree with almost all you write so I won't quote it, but there are some minor differences further down.. On Thu, 10 May 2007, Fergie wrote: > [...] > The real issues here is to describe what "SAVA validation" really > means, and what the desired result is within any particular locally > administered domain ("You must be at least 'this tall' to claim to > be 'SAVA Compliant'"), and then figure out how to communicate this > in a transitive nature from end-to-end such that any "SAVA Compliant" > or "SAVA Validated" prefixes can be recognized [...] The first question I'd ask here, is the IETF the right place to specify what constitutes 'SAVA compliancy'? Maybe we could have a BCP on this, but to me this choice of venue is not obvious. At least, I suspect this shouldn't done until the mechanisms such a BCP refers to have been sufficiently deployed so that there is real experience on using them. I'll note that if the mechanisms available to the network operators are good enough (which probably means: better than they're today), benefits might come automatically as a result of the mechanisms being available, and I don't see that such a BCP is necessarily needed. > Which is why I think that whatever work is brought to the IETF (if > it is brought into the IETF) needs to be somewhat compartmentalized, > given defined deliverables & milestones, such that the architecture > lends it self to various sorts of locally implemented _mechanism_, but > a commonly defined and implemented end-to-end transitive > implementation. > > So, what I propose is to break SAVA work items into _at_least_ > two parts: local subnet/first-hop source address validation, and > secondly, how to communicate that this has been done upstream. Yes, I agree that the work needs to be split. I'd say we'd need to look at more than two parts but until there's more detail that's fine. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From fergdawg at netzero.net Thu May 10 13:25:52 2007 From: fergdawg at netzero.net (Fergie) Date: Thu, 10 May 2007 05:25:52 GMT Subject: [SAVA] Some thoughts on the direction(s) SAVA should take... Message-ID: <20070509.222647.725.1316393@webmail18.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070510/aea19d3f/attachment.txt From fergdawg at netzero.net Thu May 10 15:11:48 2007 From: fergdawg at netzero.net (Fergie) Date: Thu, 10 May 2007 07:11:48 GMT Subject: [SAVA] RIPE Anti-Spoofing Task Force: "How To" Documentation Process Message-ID: <20070510.001226.725.1316630@webmail18.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070510/4f8e283b/attachment.txt From fergdawg at netzero.net Sat May 19 01:31:15 2007 From: fergdawg at netzero.net (Fergie) Date: Fri, 18 May 2007 17:31:15 GMT Subject: [SAVA] Fw: [Int-area] BOF and WG request cutoff date approaching Message-ID: <20070518.103129.26645.3149384@webmail39.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070518/b16ec51f/attachment.ksh From fergdawg at netzero.net Tue May 22 01:00:13 2007 From: fergdawg at netzero.net (Fergie) Date: Mon, 21 May 2007 17:00:13 GMT Subject: [SAVA] Request for SAVA BoF at IETF69 [Was: Re: [Int-area] BOF and WG request cutoff date approaching] Message-ID: <20070521.100105.8794.3164973@webmail03.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070521/d2af64b4/attachment.txt From fergdawg at netzero.net Tue May 22 01:58:51 2007 From: fergdawg at netzero.net (Fergie) Date: Mon, 21 May 2007 17:58:51 GMT Subject: [SAVA] Request for SAVA BoF at IETF69 [Was: Re: [Int-area] BOF and WG request cutoff date approaching] Message-ID: <20070521.105953.8794.3165766@webmail03.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070521/9b542dd9/attachment.txt From fergdawg at netzero.net Wed May 23 12:03:39 2007 From: fergdawg at netzero.net (Fergie) Date: Wed, 23 May 2007 04:03:39 GMT Subject: [SAVA] Problems persist with the SAVA mailing list... Message-ID: <20070522.210346.15664.2960497@webmail32.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070523/9c43fa60/attachment.txt From junbi at cernet.edu.cn Wed May 23 13:29:42 2007 From: junbi at cernet.edu.cn (Jun Bi) Date: Wed, 23 May 2007 13:29:42 +0800 Subject: [SAVA] Problems persist with the SAVA mailing list... References: <20070522.210346.15664.2960497@webmail32.lax.untd.com> Message-ID: <003101c79cfb$5ebce2f0$7c18423b@junbipc> Hi, We did check the subscription page, it does work. Please note that the mailinglist was changed to: mail.nrc.tsinghua.edu.cn, not www.nrc.tsinghua.edu.cn. I sent this info to the mailing list on May 8 (see the email copied below). Again, the current subscripiton page is: http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava and on this page, we can see the archives is: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/, and I believe the archives is correct now. Best Regards, Jun [SAVA] New SAVA list archives Jun Bi junbi at cernet.edu.cn Tue May 8 18:52:20 CST 2007 a.. Previous message: [SAVA] draft-ietf-opsec-infrastructure-security-01 - InfrastructureHiding b.. Next message: [SAVA] Some thoughts on the direction(s) SAVA should take... c.. Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] -------------------------------------------------------------------------------- Hi, We moved the sava mail-list to a new server recently. The new list archives: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/ The existing mail-list membership remain unchanged. For new members to subscribe: http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava Best Regards, Jun Bi ----- Original Message ----- From: "Fergie" To: Sent: Wednesday, May 23, 2007 12:03 PM Subject: [SAVA] Problems persist with the SAVA mailing list... > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > There appears to still be problems with the SAVA mailing list. > > First, I have received numerous report sof people trying to > get subscribed, and never getting subscribed. Can someone please > look into this and get it fixed? > > Secondly, the pointer to the proper archives still points to the > wrong place on the mailman page. > > Folks, let's please get the simple stuff fixed properly, so that > we can move on to other more productive issues? > > Thanks! > > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.6.1 (Build 1012) > > wj8DBQFGU70Hq1pz9mNUZTMRAp1MAKDAPA/bERUc/SRCsrYr2rcuhTPZMQCgpG0l > DOSkpKs4CM8h0WVLjfOQD2c= > =5XoN > -----END PGP SIGNATURE----- > > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawg(at)netzero.net > ferg's tech blog: http://fergdawg.blogspot.com/ > > > _______________________________________________ > SAVA mailing list > SAVA at nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > From fergdawg at netzero.net Wed May 23 13:33:21 2007 From: fergdawg at netzero.net (Fergie) Date: Wed, 23 May 2007 05:33:21 GMT Subject: [SAVA] Problems persist with the SAVA mailing list... Message-ID: <20070522.223405.15664.2960944@webmail32.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070523/7ca0593b/attachment.txt From junbi at cernet.edu.cn Wed May 23 13:40:55 2007 From: junbi at cernet.edu.cn (Jun Bi) Date: Wed, 23 May 2007 13:40:55 +0800 Subject: [SAVA] Request for SAVA BoF at IETF69 [Was: Re: [Int-area] BOF andWG request cutoff date approaching] References: <20070521.100105.8794.3164973@webmail03.lax.untd.com> Message-ID: <006901c79cfc$f0a252d0$7c18423b@junbipc> Just a minor revision to the BoF request. The SAVA mailing list info should be: General Discussion: sava at nrc.tsinghua.edu.cn To Subscribe: http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava (was changed) Mailing List Archive: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/ (was changed) Document Repository: http://narl.tsinghua.edu.cn/sava thanks, Jun Bi Source Address Verification and Authentication (SAVA) Co-chairs TBD Internet Area Directors: Jari Arkko Mark Townsley Internet Area Advisor: TBD Routing Area Advisor: TBD Security Area Advisor: TBD Technical Advisors: TBD Mailing Lists: General Discussion: sava at nrc.tsinghua.edu.cn To Subscribe: http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava Mailing List Archive: http://www.nrc.tsinghua.edu.cn/pipermail/sava/ Document Repository: http://narl.tsinghua.edu.cn/sava Description of Working Group/s: The proposed "Source Address Validation Architecture" Working Group is chartered to specify standardization of methods for building an IP (both IPv4 and IPv6) addressing architecture to ensure that every packet received and forwarded holds an authentic source address. "Valid source address" in this case has two meanings: i) First, the address must have been appropriately allocated and not be forged. (i.e. the route to the address must have been injected into the routing tables by someone authorized to inject such a route, and the packet must have been injected into the network by an entity authorized to use that source address.) ii) Second, the address except in cases where global uniqueness is specifically excluded, must be globally unique and traceable to its origin. That is, information about the address's location and ownership must be verifiable and correct. The current Internet addressing architecture does not verify the source address of the packets received and forwarded, although RFC 1812 has mentioned that a router SHOULD implement the ability to validate source IP addresses. In the current Internet addressing architecture using IPv4, it is difficult to ensure the authenticity of the source IP address of every packet forwarded in the network. This leads to many security, management, and accounting problems. There are many mechanisms related to the validation of source IP addresses, (see the appendix,) but few of them are widely deployed by the current Internet addressing architecture. Because the current Internet addressing architecture using IPv4, which does not verify the source address of the packets received and forwarded, has been in operation for many years, it is not feasible or cost-effective to change from the current Internet infrastructure. The main purpose of the SAVA WG is to propose a source address validation architecture. The first step will be a detailed categorization and description of the problem and sub-problems that ...(problem statement document) The framework for design and possibilities for the implementation of the architecture will be discussed and outlined in a separate framework document. Existing protocols and technologies may be extended, and new mechanisms and protocols to support the architecture may be created. The deployment policy and network transition mechanism also need to be taken into account. The WG should not limit itself to a single architectural design or a single solution for any given part of the architecture, although there should be an over-arching framework to which all designs, mechanisms, operational practices and other solutions must adhere. The thirds step is to..(solutions) Important characteristics of any solutions produced by the SAVA WG include: 1. Operators should receive a significant benefit from deploying the architectural mechanisms in their own network, even if many parts of the Internet have not deployed. This is required to give operators an incentive to adopt the architecture as early as possible. 2. The architecture should support incremental deployment, so that there is tangible benefit to be gained from partial deployment on the Internet. 3. The architecture must not have any significant negative impact on throughput or latency. 4. The relation between different components of the architecture should be loosely-coupled. That is, where there are multiple mechanisms to address a particular problem or function within the architecture, it should be possible for network operators to choose the mechanism they find most suitable. 5. The architecture should support multi-fence solutions to provide different granularities of authenticity. That is, there should be mechanisms to deal with address authenticity at the local network level, at the provider edge, at intra-provider router connections and at inter-provider boundaries. 6. The solutions should focus both on IPv4 and IPv6, but solutions suitable for IPv6 should not be excluded simply because they are not suitable for IPv4. Within this in mind, the goals of the WG are to complete the following work items . Document the problem statement for which the work of SAVA is a solution, and submit it to the IESG as an Informational Standard. . Design an architectural framework for SAVA and its component solutions, identifying the interactions between them, and submit it to the IESG for publication as a Proposed Standard. . Develop [individual solutions for each component for the framework architecture] to support SAVA and submit them to the IESG for publication as Proposed Standards. The WG Will NOT: . Work on end-end verification for applications and hosts, although hooks may be provided to allow applications to discover if the source address of a packet comes from a "SAVA Compliant" Network. . Mechanisms to implement SAVA functionality where exact mechanisms are better left to individual vendors to implement. Goals and Milestones: Jun-07 Submit -01 versions of problem statement, framework document and test-bed experience. Jul 07 Hold BoF in Chicago, asking for this Charter to be approved Aug 07 Final version of Charter approved and WG created. Aug 07 Submit draft-00 of SAVA first-hop validation draft. Oct 07 Submit WG Draft-00 on Problem Statement for SAVA Oct 07 Submit WG Draft 00 on Architectural Framework for SAVA Feb 08 Submit WG draft 00 SAVA first-hop validation solution Feb-08 Collect non-WG drafts for intra- and inter- AS validation solutions. Mar 08 Final Drafts of problem statement and framework document for submission to IESG Jun-08 Submit WG draft 00 for intra and inter-AS validation solutions Aug 08 Submit final draft of SAVA first-hop validation draft to IESG for approval. Dec 08 Submit final drafts for intra- and inter- AS validation solutions to IESG -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.1 (Build 1012) wj8DBQFGUdATq1pz9mNUZTMRAjBRAKCK+Vt5Uck6OZ3j0c5lbVPf5iBu7ACgr9IF YEpjKUwPClV2cPhG95i8RJU= =zh99 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ -------------------------------------------------------------------------------- > _______________________________________________ > SAVA mailing list > SAVA at nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava From tianbin at cernet.edu.cn Wed May 23 13:42:25 2007 From: tianbin at cernet.edu.cn (Bin Tian) Date: Wed, 23 May 2007 13:42:25 +0800 Subject: [SAVA] Problems persist with the SAVA mailing list... In-Reply-To: <003101c79cfb$5ebce2f0$7c18423b@junbipc> References: <20070522.210346.15664.2960497@webmail32.lax.untd.com> <003101c79cfb$5ebce2f0$7c18423b@junbipc> Message-ID: <4653D441.5090502@cernet.edu.cn> Hi, The mailman service of www.nrc.tsinghua.edu was shutted down, but the apache's configuration wasn't correted. And I did see a guy was trying to subscribe in www.nrc.tsinghua.edu.cn. Now the apache's configuration is corredted. If someone visits http://www.nrc.tsinghua.edu.cn/mailman/..., it will be redirected to http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/... Sorry for any inconvenience. Best Regards, Bin Tian Jun Bi wrote: > Hi, > > We did check the subscription page, it does work. > Please note that the mailinglist was changed to: > mail.nrc.tsinghua.edu.cn, not www.nrc.tsinghua.edu.cn. > > I sent this info to the mailing list on May 8 (see the email copied below). > > Again, the current subscripiton page is: > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > > and on this page, we can see the archives is: > http://mail.nrc.tsinghua.edu.cn/pipermail/sava/, and I believe the archives is correct now. > > Best Regards, > Jun > > [SAVA] New SAVA list archives > Jun Bi junbi at cernet.edu.cn > Tue May 8 18:52:20 CST 2007 > > a.. Previous message: [SAVA] draft-ietf-opsec-infrastructure-security-01 - InfrastructureHiding > b.. Next message: [SAVA] Some thoughts on the direction(s) SAVA should take... > c.. Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > > -------------------------------------------------------------------------------- > > Hi, > > We moved the sava mail-list to a new server recently. > > The new list archives: > http://mail.nrc.tsinghua.edu.cn/pipermail/sava/ > > The existing mail-list membership remain unchanged. > > For new members to subscribe: > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > > Best Regards, > Jun Bi > ----- Original Message ----- > From: "Fergie" > To: > Sent: Wednesday, May 23, 2007 12:03 PM > Subject: [SAVA] Problems persist with the SAVA mailing list... > > > Hello, > > There appears to still be problems with the SAVA mailing list. > > First, I have received numerous report sof people trying to > get subscribed, and never getting subscribed. Can someone please > look into this and get it fixed? > > Secondly, the pointer to the proper archives still points to the > wrong place on the mailman page. > > Folks, let's please get the simple stuff fixed properly, so that > we can move on to other more productive issues? > > Thanks! > > - ferg > >> >> -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ >> >> _______________________________________________ SAVA mailing list SAVA at nrc.tsinghua.edu.cn http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava >> > _______________________________________________ > SAVA mailing list > SAVA at nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava From junbi at netarchlab.tsinghua.edu.cn Wed May 23 13:49:21 2007 From: junbi at netarchlab.tsinghua.edu.cn (Jun Bi) Date: Wed, 23 May 2007 13:49:21 +0800 Subject: [SAVA] Problems persist with the SAVA mailing list... References: <20070522.210346.15664.2960497@webmail32.lax.untd.com><003101c79cfb$5ebce2f0$7c18423b@junbipc> <4653D441.5090502@cernet.edu.cn> Message-ID: <00a601c79cfe$1daece10$7c18423b@junbipc> Thanks to Bin Tian. I believe that's the reason, somebody still used the old mailing address . I just tried subscribing as a new user, the mailing list works well. Thanks, Jun ----- Original Message ----- From: "Bin Tian" To: "Jun Bi" Cc: Sent: Wednesday, May 23, 2007 1:42 PM Subject: Re: [SAVA] Problems persist with the SAVA mailing list... > Hi, > > The mailman service of www.nrc.tsinghua.edu was shutted down, but the > apache's configuration wasn't correted. And I did see a guy was trying > to subscribe in www.nrc.tsinghua.edu.cn. > > Now the apache's configuration is corredted. If someone visits > http://www.nrc.tsinghua.edu.cn/mailman/..., it will be redirected to > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/... > > Sorry for any inconvenience. > > Best Regards, > Bin Tian > > Jun Bi wrote: >> Hi, >> >> We did check the subscription page, it does work. >> Please note that the mailinglist was changed to: >> mail.nrc.tsinghua.edu.cn, not www.nrc.tsinghua.edu.cn. >> >> I sent this info to the mailing list on May 8 (see the email copied below). >> >> Again, the current subscripiton page is: >> http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava >> >> and on this page, we can see the archives is: >> http://mail.nrc.tsinghua.edu.cn/pipermail/sava/, and I believe the archives is correct now. >> >> Best Regards, >> Jun >> >> [SAVA] New SAVA list archives >> Jun Bi junbi at cernet.edu.cn >> Tue May 8 18:52:20 CST 2007 >> >> a.. Previous message: [SAVA] draft-ietf-opsec-infrastructure-security-01 - InfrastructureHiding >> b.. Next message: [SAVA] Some thoughts on the direction(s) SAVA should take... >> c.. Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] >> >> -------------------------------------------------------------------------------- >> >> Hi, >> >> We moved the sava mail-list to a new server recently. >> >> The new list archives: >> http://mail.nrc.tsinghua.edu.cn/pipermail/sava/ >> >> The existing mail-list membership remain unchanged. >> >> For new members to subscribe: >> http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava >> >> Best Regards, >> Jun Bi >> ----- Original Message ----- >> From: "Fergie" >> To: >> Sent: Wednesday, May 23, 2007 12:03 PM >> Subject: [SAVA] Problems persist with the SAVA mailing list... >> >> >> Hello, >> >> There appears to still be problems with the SAVA mailing list. >> >> First, I have received numerous report sof people trying to >> get subscribed, and never getting subscribed. Can someone please >> look into this and get it fixed? >> >> Secondly, the pointer to the proper archives still points to the >> wrong place on the mailman page. >> >> Folks, let's please get the simple stuff fixed properly, so that >> we can move on to other more productive issues? >> >> Thanks! >> >> - ferg >> >>> >>> > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawg(at)netzero.net > ferg's tech blog: http://fergdawg.blogspot.com/ >>> >>> > _______________________________________________ > SAVA mailing list > SAVA at nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava >>> >> _______________________________________________ >> SAVA mailing list >> SAVA at nrc.tsinghua.edu.cn >> http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > > > _______________________________________________ > SAVA mailing list > SAVA at nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > From fenner at research.att.com Wed May 23 20:29:53 2007 From: fenner at research.att.com (Bill Fenner) Date: Wed, 23 May 2007 05:29:53 -0700 Subject: [SAVA] Request for SAVA BoF at IETF69 [Was: Re: [Int-area] BOF and WG request cutoff date approaching] Message-ID: <200705231229.l4NCTsOS031507@bright.research.att.com> I notice that the proposed charter wasn't updated to explicitly address the cost of the solutions. I think this is a key aspect: much has been said about the benefits but without knowing the costs it's hard to decide if the tradeoff is worth it. Bill From fergdawg at netzero.net Thu May 24 01:44:57 2007 From: fergdawg at netzero.net (Fergie) Date: Wed, 23 May 2007 17:44:57 GMT Subject: [SAVA] Request for SAVA BoF at IETF69 [Was: Re: [Int-area] BOF and WG request cutoff date approaching] Message-ID: <20070523.104550.29529.3201806@webmail25.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070523/84f9df2f/attachment.txt From fenner at research.att.com Thu May 24 02:36:15 2007 From: fenner at research.att.com (Bill Fenner) Date: Wed, 23 May 2007 11:36:15 -0700 Subject: [SAVA] Request for SAVA BoF at IETF69 [Was: Re: [Int-area] BOF and WG request cutoff date approaching] Message-ID: <200705231836.l4NIaFoe027941@bright.research.att.com> >One of the reasons why I didn't go down [the "cost"] path is that, initially, >I'd like to see us define the desired functionality/behavior and >desired result of source validation, and not necessarily the >specific mechanisms themselves (since some will be vendor and >implementation-specific). When I was on the IESG, one of the things that I wanted to be able to do as input to my decision of whether the WG should be chartered is have a feeling for the cost/benefit tradeoff of the proposed work. To give extreme examples, if it provided perfect security at the cost of halving the forwarding rate, I'd probably push back on it; if the scheme could be implemented with no cost to any device anywhere I'd say "absolutely". Perhaps I'm looking for another bullet in the "Important characteristics of any solutions" section; #3 mentions a couple of dimensions (throughput and latency) but there are also considerations like "increases router cost by 200%" or other harder-to-evaluate measures. Bill From fergdawg at netzero.net Thu May 24 02:50:03 2007 From: fergdawg at netzero.net (Fergie) Date: Wed, 23 May 2007 18:50:03 GMT Subject: [SAVA] Request for SAVA BoF at IETF69 [Was: Re: [Int-area] BOF and WG request cutoff date approaching] Message-ID: <20070523.115010.29529.3202583@webmail25.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070523/ab4aad43/attachment.txt From fergdawg at netzero.net Tue May 29 02:44:15 2007 From: fergdawg at netzero.net (Fergie) Date: Mon, 28 May 2007 18:44:15 GMT Subject: [SAVA] Fwd: [Int-area] BOF requests for the Internet Area Message-ID: <20070528.114514.26645.3234577@webmail39.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070528/44b7e7ec/attachment.txt From fergdawg at netzero.net Tue May 29 15:18:12 2007 From: fergdawg at netzero.net (Fergie) Date: Tue, 29 May 2007 07:18:12 GMT Subject: [SAVA] Need your input: draft-sava-problem-statement-01 Message-ID: <20070529.001902.694.1487366@webmail29.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070529/81f087c5/attachment.txt From bgreene at cisco.com Tue May 29 22:15:06 2007 From: bgreene at cisco.com (Barry Greene (bgreene)) Date: Tue, 29 May 2007 07:15:06 -0700 Subject: [SAVA] Need your input: draft-sava-problem-statement-01 In-Reply-To: <20070529.001902.694.1487366@webmail29.lax.untd.com> References: <20070529.001902.694.1487366@webmail29.lax.untd.com> Message-ID: The general problem of supporting authenticity of source address in the Internet is divided into three separated sub-problems, referred as "First-hop, local subnet source validation", "Intra-AS Communication of SAVA validation", and "Inter-AS Communication of SAVA validation." This is not an accurate break out. -> You need tools to validate within the organization (what people are calling subnet). -> You need tools to validate when you cross organizational boundaries where policy cannot be communicated (AS boundaries are too limiting). -> You need tools to validate when you cross organizational boundaries where policy can be communicated -> You need ways to communicated the validation of trust through the End-to-End system (beyond using IPSEC - which is the end-to-end system of trust designed for the Internet). > -----Original Message----- > From: sava-bounces at nrc.tsinghua.edu.cn > [mailto:sava-bounces at nrc.tsinghua.edu.cn] On Behalf Of Fergie > Sent: Tuesday, May 29, 2007 12:18 AM > To: sava at nrc.tsinghua.edu.cn > Subject: [SAVA] Need your input: draft-sava-problem-statement-01 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Okay, so I'm tired and cranky, but here's a rough cut of the > new problem statement. > > PLEASE send comments ASAP so that we can get this thing > re-submitted this week, and begin to re-craft the framework draft. > > We have a lot to do. > > Thanks, > > - - ferg > > [snip] > > Network Working Group > Paul Ferguson > > Internet-Draft > Trend Micro, > Inc. > Intended status: Experimental > 31 May 2007 > Expires: Novermber 30, 2007 > > > > > > > Source Address Verification Architecture Problem Statement > draft-sava-problem-statement-01 > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of > six months > and may be updated, replaced, or obsoleted by other > documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on November 30, 2007. > > Copyright Notice > > Copyright (C) The IETF Trust (2007). > > Abstract > > This document outlines the problems that the Source Address > Verification Architecture (SAVA) initiative plans to solve. It > examines the current state in the internet, looks at current best > practices, and discusses why the current approaches are unlikely to > ever solve the problem of IP address spoofing. It also discusses > some of the problems that SAVA should NOT attempt to solve. > > Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . > . . . . . 3 > 2. Current State of Affairs . . . . . . . . . . . . . . > . . . . . 3 > 3. Shortcomings of Best Current Practices . . . . . . . > . . . . . 4 > 4. Framework Requiremenmts/Discussion . . . . . . . . . > . . . . . 4 > 5. Scaling & Methodlogy . . . . . . . . . . . . . . . . > . . . . . 5 > 6. IANA Considerations . . . . . . . . . . . . . . . . . > . . . . . 5 > Authors' Addresses . . . . . . . . . . . . . . . . . . . > . . . . . 7 > Intellectual Property and Copyright Statements . . . . . > . . . . . 9 > > > > > 1. Introduction > > As we all know, the Internet is a decentralized system > which basically > provides best effort, packet-based data forwarding service. In the > forwarding process, intermediate devices (routers, switches, other > gateway devices, etc.) forwards IP packets based on the destination > IP address. > > This is how the Internet was designed to operate, and these are the > principle contraints that we must acknowledge in the > approach that SAVA > attempts to address. > > In virtaully all cases of processing traffic in the > Internet, the source > IP address is generally not validated as being genuine. It > is accepted as > being som simply because that it is written into the IP > header datagram. > > This is no longer acceptable as method of assuring the > validity of the > geneuine source of traffic, since it is trivial for any host in the > Internet to re-write this value, or simply misrepresent > itself as the > originator of traffic. > > This lack of source IP address validation makes it easy > for anyone to > spoof the originating IP host address, and has facilitated > many existing > historical (and current) instances of maliciousness (e.g. > hiding behind > spoofed IP source addresses, et al.). > > In recent years, there have been some efforts in the research > community to design mechanisms to expose efforts to which employ > IP source address spoofing -- plenty of instances of this > are readily > available. > > The motivation of this document is to clarify the problem > in solving > the spoofing of source address. > > The general problem of supporting authenticity of source address in > the Internet is divided into three seperated sub-problems, refered > as "First-hop, local subnet source validation", "Intra-AS > Communication > of SAVA validation", and "Inter-AS Communication of SAVA > validation." > > The primary difference between these three topological applications > details each issue and implementation is unique to the > place where it > is actually enabled. > > This problem statement attempts to illustrate why these > problems are > uniquely different, and why the SAVA framework, and > subsequent soutions, > must be implemented in such a fashion as to take into account the > placement of each function into the heierachy of the > Internet itself. > > > > 2. Current State of Affairs > > In the MIT Spoofer Project [Bev05], the authors found that > approximately one-quarter of the observed addresses, netblocks and > autonomous systems (AS) permit full or partial spoofing. And they > suggested that a large portion of the Internet is vulnerable to > spoofing and concerted attacks employing spoofing remain a serious > concern. > > While this is by no means an authoritative measurement of the scope > of the problem, it does, however, illustrate the difficulty in > measuring how deep this rabbit-hole actually goes. > > Commentary: There as much heated discussion, in various forums, on > the relative threat of spoofed IP host source addresses. Some of it > is valid, some invalid. > > One thing is for sure, however, andis still held true -- spoofed > IP host source address traffic still exists, for one > reason or another, > and still poses a conundrum insofar as validating the source of > maliciousness. > > > 3. Shortcomings of Best Current Practices > > While there are sverela BCPs in this area, the wide-spead adoption > of them remains elusive. > > There is only one Best Current Practice (BCP) published in the > IETF that deals with this issue, and there can be any number of > discussions on why it is not widely delpoyed (but that is a topic > for any number of other discussions): > > > Ingress Filtering, as described in BCP38 [RFC2827], descibes > a simple methodology for ISPs and any other Internet-facing > organisation to apply filters limiting the source addresses that > are allowed on to "source" packets into the Internet from a select > and predetermined set of prefixes. > > If BCP0038 were followed at all ingress points to the > Internet, then > there would be no spoofed packets on the Internet. > > One of the problem with BCP38 is that there is no measuareable or > incremental method to determine it's success -- either it > is deployed > globally, or else there is no way to determine it's effectiveness. > > What we attempt to do with SAVA, is to bring incremental benefit > to incremetal deployment of BCP38, as well as a way to meaure it's > global deployment and benefit. > > > > 4. Framework Requirements > > SAVA Architecural and WG framework disucssions will be > more completely > defined and addressed in the proposed workgroup charter and the > framework document. > > > > 5. Scaling & Methodology > > SAVA functionality solutions will be feasible for all network sizes > due to the manner in which we plan to dissect the > framework -- each of > the desired SAVA functionalities will be defined in > individual documents > that approximate their ability to perfoerm a specific > function relative > to their placement and function in the network heiracrhy: > > - First-hop, local-subnet source-address validation (and > enforcement); > - Intra-AS communication of SAVA validation; > - Inter-AS communication of SAVA validation. > > > 6. IANA Considerations > > This document makes no request of IANA. > > Note to RFC Editor: this section may be removed on > publication as an > RFC. > > > 7. Security Considerations > > For this document, no specific security considerations. > Many of the > solution elements will need to be examined carefully for robustness > and to see if they do not in themselves introduce security > problems. > > > 8. Acknowledgements > > Mark Williams & Jun Bi > did > most of the footwork on the original version of this > draft, which I > have notoriosuly gutted. > > > 9. References > > > 9.1. Normative References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > 9.2. Informative References > > [Bev05] Beverley, S. and S. Bauer, ""The spoofer project: > inferring the extent of source address filtering on the > Internet", USENIX SRUTI 2005", 2005. > > [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: > Defeating Denial of Service Attacks which > employ IP Source > Address Spoofing", BCP 38, RFC 2827, May 2000. > > [RFC3871] Jones, G., "Operational Security Requirements for Large > Internet Service Provider (ISP) IP Network > Infrastructure", RFC 3871, September 2004. > > > Authors' Addresses > > > Paul Ferguson > Trend Micro, Inc. > San Jose, California > Paul_Ferguson at trendmicro.com > +1.408.625.1068 > > > > > > > > > > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2007). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > This document and the information contained herein are > provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE > IETF TRUST AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL > WARRANTIES, EXPRESS > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT > THE USE OF > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be > claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. > Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for > the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR > repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr at ietf.org. > > > Acknowledgment > > Funding for the RFC Editor function is provided by the IETF > Administrative Support Activity (IASA). > > > > > [end] > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.6.1 (Build 1012) > > wj8DBQFGW9Otq1pz9mNUZTMRAnIRAJ9e7/8aVWZpLb+sWfIWPIqSWUUaPACaAgFw > ek+rFsWhVQY3UATp0/dQ78Q= > =96Om > -----END PGP SIGNATURE----- > > > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawg(at)netzero.net ferg's tech blog: > http://fergdawg.blogspot.com/ > > > _______________________________________________ > SAVA mailing list > SAVA at nrc.tsinghua.edu.cn > http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava > From fergdawg at netzero.net Wed May 30 02:37:46 2007 From: fergdawg at netzero.net (Fergie) Date: Tue, 29 May 2007 18:37:46 GMT Subject: [SAVA] Need your input: draft-sava-problem-statement-01 Message-ID: <20070529.113839.784.473129@webmail24.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070529/aa7d22b2/attachment.txt From fergdawg at netzero.net Thu May 31 11:37:26 2007 From: fergdawg at netzero.net (Fergie) Date: Thu, 31 May 2007 03:37:26 GMT Subject: [SAVA] Updated: SAVA problem statement draft Message-ID: <20070530.203731.773.1247330@webmail45.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070531/19cbca76/attachment.txt From fergdawg at netzero.net Thu May 31 12:22:48 2007 From: fergdawg at netzero.net (Fergie) Date: Thu, 31 May 2007 04:22:48 GMT Subject: [SAVA] 69th IETF Meeting: Cutoff Dates Message-ID: <20070530.212325.773.1247629@webmail45.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070531/237e2e07/attachment.txt From denghui02 at gmail.com Thu May 31 12:37:06 2007 From: denghui02 at gmail.com (Hui Deng) Date: Thu, 31 May 2007 12:37:06 +0800 Subject: [SAVA] SAVA and Mobile IP Message-ID: <1d38a3350705302137n56c644f2le83f06b0d83b2270@mail.gmail.com> Hello? all based on the discussion with Ferg of the below, I also put down this draft as the reference for this bof, many thanks -Hui Hui, I think these should be worked on, refined, and submitted on their own. The original SAVA "problem statement" draft is just making the case for why SAVA needs to be done, not in addressing other problems that it will have to address along the way. :-) That's why I think they need to be separate drafts. If you agree, please forward these to the mailing list for comment, along my remarks (if you would like to do so). Thanks! - - ferg SAVA BoF H. Deng Internet-Draft Hitachi Intended status: Standards Track May 30, 2007 Expires: December 1, 2007 Problem Statement for SAVA Mobile IP draft-deng-sava-mobileip-problem-statement-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 1, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Deng Expires December 1, 2007 [Page 1] Internet-Draft SAVA Multihome Problem Statement May 2007 Abstract This document specifies the problems for the SAVA (Source Address Verification Architecture) regarding to mobile IP issue. There are still some issues in respect of Mobile IPv4 Foreign Agent Care of Address mode, and Mobile IPv6 home adress destination option and type 2 routing header. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problems about Mobile IPv4 Foreign Agent Care of Address Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Problems about Mobile IPv6 Destination Option and Type 2 Routing Header . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Deng Expires December 1, 2007 [Page 2] Internet-Draft SAVA Multihome Problem Statement May 2007 1. Introduction In the current SAVA BOF proposal[SAVA-FRAMEWORK], the architecture has been categorized into three type of defense: "First-hop, local subnet source validation", "Intra-AS Communication of SAVA validation", and "Inter-AS Communication of SAVA validation." In the current Mobile IPv4 [RFC3344]specification, during the mobile Foreign Agent Care of Address model, reverse tunneling based mechanism could be used in case of ingress filtering[RFC2827], but it will constraint application where foreign agent could forward packet directly. When routing packets directly to the mobile node, the correspondent node sets the Destination Address in the IPv6 header to the care-of address of the mobile node. A new type of IPv6 routing header [RFC3775] is also added to the packet to carry the desired home address. Similarly, the mobile node sets the Source Address in the packet's IPv6 header to its current care-of addresses. The mobile node adds a new IPv6 "Home Address" destination option to carry its home address. The inclusion of home addresses in these packets makes the use of the care-of address transparent above the network layer. When the mobile node sends packets directly to the correspondent node, the Source Address field of the packet's IPv6 header is the care-of address. Therefore, ingress filtering works in the usual manner even for mobile nodes, as the Source Address is topologically correct. which is intended for ingress filter during access network. The Home Address option is used to inform the correspondent node of the mobile node's home address. This document defines a problem with SAVA related to Mobile IP. Deng Expires December 1, 2007 [Page 3] Internet-Draft SAVA Multihome Problem Statement May 2007 2. Terminology It is assumed that the reader is familiar with the terminology used in [RFC1654], [RFC2827]. In addition, the following terms are defined: The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. Deng Expires December 1, 2007 [Page 4] Internet-Draft SAVA Multihome Problem Statement May 2007 3. Problems about Mobile IPv4 Foreign Agent Care of Address Model Many routers implement security policies such as "ingress filtering" that do not allow forwarding of packets that have a Source Address which appears topologically incorrect. Current Mobile IPv4 support reverse tunneling [RFC3024] with the foreign agent supplied care-of address as the Source Address. but it will lead to all traffice have to go through the home agent even foreign agent is location far away from home agent, In this network architecutre, as the Figure 1, if the Host A MN want to communicate with Host B CN, if there is no ingress filter after foreign agent, and if Mobile IPv4 Foreign Agent Care of Address mode is adopted, source address of packets initiated from mobile node will be mobilde node's source address, but if ingress filter is supported in the router after foreign agent, then source address is mobile node's home address, but it will distort the network architecutre. Mobile IPv4 adopt reverse tunneling [RFC3024] to support tunneling between foreign agent and home agent which source address is care of address. Deng Expires December 1, 2007 [Page 5] Internet-Draft SAVA Multihome Problem Statement May 2007 +----------+ +----------+ |Home | | Host B | |Agent | | CN | | | | | +----------+ +----------+ reverse || | tunneling || | +----------+ +----------+ | | | | | Router | | Router | | | | | +----------+ +----------+ || | |+-----------+---------------+ +----------- | || || || +----------+ |Routers | |(ingress | | filter) | +----------+ || || +----------+ | Foreign | | Agent | | MIP4 | +----------+ | +-----------+ | Host A | | MN | |Mobile IP | +-----------+ Figure 1: MIP4 FA CoA mode in case of ingress filter Deng Expires December 1, 2007 [Page 6] Internet-Draft SAVA Multihome Problem Statement May 2007 4. Problems about Mobile IPv6 Destination Option and Type 2 Routing Header When routing packets directly to the mobile node, the correspondent node sets the Destination Address in the IPv6 header to the care-of address of the mobile node. A new type of IPv6 routing header [RFC3775] is also added to the packet to carry the desired home address. Similarly, the mobile node sets the Source Address in the packet's IPv6 header to its current care-of addresses. The mobile node adds a new IPv6 "Home Address" destination option to carry its home address. The inclusion of home addresses in these packets makes the use of the care-of address transparent above the network layer. When the mobile node sends packets directly to the correspondent node, the Source Address field of the packet's IPv6 header is the care-of address. Therefore, ingress filtering works in the usual manner even for mobile nodes, as the Source Address is topologically correct. which is intended for ingress filter during access network. The Home Address option is used to inform the correspondent node of the mobile node's home address. In this network architecutre, as the Figure 2, if care of address mobile node is not belong to SAVA alliance, but home address of mobile node is belong to SAVA Alliance, this packet will be discarded based on SAVA policy, but network operator may not expect this happen, they also expect that mobile node where home address is belong to alliance still could visit Host B. even . Deng Expires December 1, 2007 [Page 7] Internet-Draft SAVA Multihome Problem Statement May 2007 +----------+ +----------+ |Home | | Host B | |Agent | | CN | | | | | +----------+ +----------+ | | | | +----------+ +----------+ |BGP Router| |BGP Router| |(SAVA | | (SAVA | | Support) | | Support) | +----------+ +----------+ | AS=y | | | +-----------+--------------+ |AS=x +----------+ |BGP Router| |(SAVA not | | Support) | +----------+ | | +-----------+ | Host A | | MN | |Mobile IPv6| +-----------+ Figure 2: MIP6 network in the SAVA Deng Expires December 1, 2007 [Page 8] Internet-Draft SAVA Multihome Problem Statement May 2007 5. Security Considerations This specification operates in the security constraints and requirements of about some events and provides the same level of security for all three nodes. Deng Expires December 1, 2007 [Page 9] Internet-Draft SAVA Multihome Problem Statement May 2007 6. IANA Considerations This document provides the problem description for an Mobile IP usage in SAVA network architecture, BGP based routing protocol Deng Expires December 1, 2007 [Page 10] Internet-Draft SAVA Multihome Problem Statement May 2007 7. References 7.1. Normative References [RFC1654] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1654, July 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3871] Jones, G., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, September 2004. 7.2. Informative References [SAVA-E2E] Wu, JP., "A End-to-end Source Address Validation Solution for IPv6", Feb 2007, . [SAVA-FRAMEWORK] Wu, JP., "Source Address Validation Architecture (SAVA) Framework", Feb 2007, . [SAVA-PS] Wu, JP., "Source Address Validation Architecture Problem Statement", Feb 2007, . [SAVA-SIMPLE] Baker, F., "Simple Source Address Validation", March 2007, . [SAVA-TESTBED] Deng Expires December 1, 2007 [Page 11] Internet-Draft SAVA Multihome Problem Statement May 2007 Wu, JP., "SAVA Testbed and Experiences to Date", Feb 2007, . Deng Expires December 1, 2007 [Page 12] Internet-Draft SAVA Multihome Problem Statement May 2007 Author's Address Hui Deng Hitachi 301, North Building, Tower C, Raycom Infotech Park, 2, Kexueyuan Nanlu Hai Dian District Beijing 100080 China Email: hdeng at hitachi.cn From denghui02 at gmail.com Thu May 31 12:38:48 2007 From: denghui02 at gmail.com (Hui Deng) Date: Thu, 31 May 2007 12:38:48 +0800 Subject: [SAVA] SAVA and Multihoming Message-ID: <1d38a3350705302138n2b72c5a2qc0a7e4dc8af7adc6@mail.gmail.com> Hello? all based on the discussion with Ferg of the below, I also put down this draft as the reference for this bof, many thanks -Hui Hui, I think these should be worked on, refined, and submitted on their own. The original SAVA "problem statement" draft is just making the case for why SAVA needs to be done, not in addressing other problems that it will have to address along the way. :-) That's why I think they need to be separate drafts. If you agree, please forward these to the mailing list for comment, along my remarks (if you would like to do so). Thanks! - - ferg SAVA BoF H. Deng Internet-Draft Hitachi Intended status: Standards Track May 28, 2007 Expires: November 29, 2007 Problem Statement for SAVA Multihome draft-deng-sava-multihoming-problem-statement-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 29, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Deng Expires November 29, 2007 [Page 1] Internet-Draft SAVA Multihome Problem Statement May 2007 Abstract This document specifies the problems for the SAVA (Source Address Verification Architecture) regarding to multihoming issue. The packets coming from the multihoming location may have two different AS numbers, this will be a issue for inter-domain source address verification. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problems about Multihoming in the Inter-domain SAVA architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Deng Expires November 29, 2007 [Page 2] Internet-Draft SAVA Multihome Problem Statement May 2007 1. Introduction In the current SAVA BOF proposal[SAVA-FRAMEWORK], the architecture has been categorized into three type of defense: access network, intra-domain, and inter-domain. When a host is located in multihoming scenario, the packet coming from this host may go through two different network access providers. In this case, the AS number with this host may have two. And current SAVA only assume the packet coming from one AS number. This document defines a problem with inter-domain SAVA about multihoming issue. Deng Expires November 29, 2007 [Page 3] Internet-Draft SAVA Multihome Problem Statement May 2007 2. Terminology It is assumed that the reader is familiar with the terminology used in [RFC1654], [RFC2827]. In addition, the following terms are defined: The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. Deng Expires November 29, 2007 [Page 4] Internet-Draft SAVA Multihome Problem Statement May 2007 3. Problems about Multihoming in the Inter-domain SAVA architecture A multihoming host in SAVA network architecture may have two AS numbers which may conflict with SAVA inter-domain solution. In this network architecutre, as the Figure 1, the host A have two network access connnection: ISP 1 which has network prefix a.b.c.0/24 and ISP 2 which has network prefix d.e.f.0/24, if host A follow the case of load balance which could enhance multihoming service. the packet from host A could go through left side router which is SAVA supported and the other router which is SAVA supported too, but the top BGP router will find that packet will have two type AS number label but come from the same network address host A. SAVA may discard the packet where come late than previous and think it is a kind of malicuous attack +----------+ | Provider | | | |m.n.o.0/24| +----------+ | | +----------+ |BGP Router| +--------|(SAVA |--------+ | | Support) | | |AS x +----------+ |AS y | | +----------+ +----------+ |BGP Router| |BGP Router| |(SAVA | | (SAVA | | Support) | | Support) | +----------+ +----------+ | | | | +----------+ +----------+ | ISP 1 | | ISP 2 | | Network | | Network | |a.b.c.0/24| |d.e.f.0/24| +----------+ +----------+ | | | +-----------+ | | | Host A | | +-------| |--------+ |Multihoming| +-----------+ Deng Expires November 29, 2007 [Page 5] Internet-Draft SAVA Multihome Problem Statement May 2007 Figure 1: SAVA Inter-domain Network Architecture for Multihoming Deng Expires November 29, 2007 [Page 6] Internet-Draft SAVA Multihome Problem Statement May 2007 4. Security Considerations This specification operates in the security constraints and requirements of about some events and provides the same level of security for all three nodes. Deng Expires November 29, 2007 [Page 7] Internet-Draft SAVA Multihome Problem Statement May 2007 5. IANA Considerations This document provides the problem description for an Inter-domain SAVA network architecture, BGP based routing protocol Deng Expires November 29, 2007 [Page 8] Internet-Draft SAVA Multihome Problem Statement May 2007 6. References 6.1. Normative References [RFC1654] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1654, July 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC3871] Jones, G., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, September 2004. 6.2. Informative References [SAVA-E2E] Wu, JP., "A End-to-end Source Address Validation Solution for IPv6", Feb 2007, . [SAVA-FRAMEWORK] Wu, JP., "Source Address Validation Architecture (SAVA) Framework", Feb 2007, . [SAVA-PS] Wu, JP., "Source Address Validation Architecture Problem Statement", Feb 2007, . [SAVA-SIMPLE] Baker, F., "Simple Source Address Validation", March 2007, . [SAVA-TESTBED] Wu, JP., "SAVA Testbed and Experiences to Date", Feb 2007, . Deng Expires November 29, 2007 [Page 9] Internet-Draft SAVA Multihome Problem Statement May 2007 Author's Address Hui Deng Hitachi 301, North Building, Tower C, Raycom Infotech Park, 2, Kexueyuan Nanlu Hai Dian District Beijing 100080 China Email: hdeng at hitachi.cn