From marcelo@it.uc3m.es Tue May 5 01:41:12 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FE853A69F7 for ; Tue, 5 May 2009 01:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-3.307, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gogZiKW2pyik for ; Tue, 5 May 2009 01:41:11 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id DB3C03A6BA9 for ; Tue, 5 May 2009 01:40:50 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 23E7265A353; Tue, 5 May 2009 10:42:15 +0200 (CEST) Message-ID: <49FFFBE7.7010306@it.uc3m.es> Date: Tue, 05 May 2009 10:42:15 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Guang Yao References: <000001c9c86a$e5d993e0$b18cbba0$@tsinghua.edu.cn> <49F9A9E4.6080204@it.uc3m.es> <000101c9cd2a$dcda14d0$968e3e70$@tsinghua.edu.cn> In-Reply-To: <000101c9cd2a$dcda14d0$968e3e70$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16622.004 Cc: 'SAVI Mailing List' , 'Christian Vogt' Subject: Re: [savi] =?gb2312?b?tPC4tDogQWJvdXQgdGhlIGZhaWx1cmUgc2l0dWF0aW9u?= =?gb2312?b?IG1lbnRpb25lZCBieSBNYXJjZWxv?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 08:41:12 -0000 Guang Yao escribi¨®: > > >> However, there isn¡¯t another ¡°strict secure¡± anchor satisfying this >> requirement currently. >> >> Thus we have two directions here: >> >> 1 bindings are only set up for directly attached hosts, and the >> binding entries are used to ¡°deny¡± the traffic from the legacy-SAVI >> port.(class A) >> > > i am not sure if a follow, what happens to the packets arriving through > the SAV legacy port? No filtering whatsoever is ever made, or a binding > is created using DAD packets or else? > > / *Guang:*/ > I mean, the bindings set up on SAVI-Host port are used to deny the traffic > from SAVI-Legacy port. > For example, > Address A1, A2, A3 are bound on SAVI-Host port, > Then traffic from SAVI-Legacy port is filtered on !A1 && ! A2 && !A3. > > > So basically, if a host is connected through a non SAVI switch to a SAVI device, its source address can be spoofed, by any other host, in particular, by a host that is connected to a _different_ port of the SAVI enabled device, is this correct? >> 2 bindings are also set up for remote hosts without differences with >> directly attached hosts.(class B) >> >> Because of the situation mentioned by Marcelo above, SAVI device >> cannot rely on control packets only, and must use auxiliary protocols, >> >> > > i am not sure why you bring the BDP or MLD protocol here. I mean, this > situation occurs when there is a single SAVI device so a BDP will not > help here. What can be done is to learn using data packets (instead of > discarding them) > > / *Guang:*/ > I'm not sure why you mean there is a single SAVI device here. There can be > another SAVI device > also connected to a same upstream device as this SAVI device. > > right, but my point is that the situation that i described, also occurs in the case that you have a single SAVI device in the whole subnet. so i am not sure why we need to consider the BDP to solve this, since it may occur in a situaton where you don't have a second savi device >> e.g., BDP or MLD. >> >> In this direction, the SAVI device doesn¡¯t have to distinguish >> SAVI-Legacy port and SAVI-Host port. And the packets from the >> SAVI-Legacy port are filtered based on ¡°allow¡± rules. >> >> However, I will try to make out two points here: >> >> (a) Set up bindings for remote hosts will not provide stronger >> security than using bindings from adjacent hosts to ¡°deny¡± packets >> from remote hosts >> >> > i don't understand what you mean here > > >> For a class B device, there are only two kinds of addresses: bound >> addresses and unbound addresses. >> >> Whenever an address appears from a SAVI-Legacy port, and it has been >> bound on other ports, this packet will be dropped by both class A and >> class B device. >> >> > that is not obvious to me from the description you made of the class a above > > >> Whenever a new address appears from a SAVI-Legacy port, the class B >> SAVI cannot drop the packet but set up a new binding for the address, >> typically based on the principle ¡°FCFS¡±. >> >> > right > > >> However, FCFS actually means using existing bindings to ¡°deny¡± packets >> from SAVI-Legacy port, which is used by class A. >> >> > i don't understand what you mean here > > / *Guang:*/ > I mean, for example, > Addresses A1, A2, A3... are bound on SAVI-Host port, > And Address B1 appears on SAVI-Legacy port. > If FCFS is used, if B1!= A1, A2, A3..., a new binding is set up for B1 and > let pass B1. > And in class A solution, if B1 != A1, A2, A3..., B1 is also let pass. > Thus FCFS and class A have the same filtering ability. > > Not really, Using your example above, in the FCFS case you decribe above, if a packet with source address B1 is received through a different port, then it is discarded. In the class A solution, the SAVI device will always let packet with source address B1 pass. irrespectively from which legacy port is received. So, in FCFS, the set of hosts that can spoof address B1 is limited to the set of hosts attached to the same lsavi port. While in the calss a solution above any host can spoof address B1. so, in FCFS source address connected to a SAVI switch through a legacy device, they still obtain some protection while in the class a solution you describe, they obtain none. so, no, the filtering capabilities are not the same Regards, marcelo From marcelo@it.uc3m.es Tue May 5 01:48:06 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1934A3A6C53 for ; Tue, 5 May 2009 01:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[AWL=-3.673, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, J_CHICKENPOX_83=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLEto01Hdg+L for ; Tue, 5 May 2009 01:48:04 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 5151A3A6C34 for ; Tue, 5 May 2009 01:48:04 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 5C06365A2FA; Tue, 5 May 2009 10:49:29 +0200 (CEST) Message-ID: <49FFFD99.8070709@it.uc3m.es> Date: Tue, 05 May 2009 10:49:29 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Guang Yao References: <001101c9c874$23988750$6ac995f0$@tsinghua.edu.cn> <49F9A421.4080400@it.uc3m.es> <000001c9cd25$ec0822d0$c4186870$@tsinghua.edu.cn> In-Reply-To: <000001c9cd25$ec0822d0$c4186870$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16622.004 Cc: 'SAVI Mailing List' Subject: Re: [savi] =?gb2312?b?tPC4tDogICoqKlNQQU0qKiogNi4xODEgKDUpINeqt6I6?= =?gb2312?b?ICBEQUQgYXMgYSBiaW5kaW5nIGRpc3RyaWJ1dGlvbiBwcm90b2NvbDogd2h5?= =?gb2312?b?IG5vdA==?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 08:48:06 -0000 Guang Yao escribi¨®: > Marcelo, > > I think this problem has two aspects: > > 1 Is it reasonable to set up binding without DAD? > > Even there is a BDP, so long as SAVI is not fully deployed, DAD is still > needed to detect whether an address has been used by another node. > According to RFC4429, the probability of a colision if nodes select the iid randomly (whcih is what DAD is aiming to prevent) is: (different values for different number of nodes in the subnte, ranging from 500 to 500000) Pb(2^62, 500) <= 5.4e-14 Pb(2^62, 5000) <= 5.4e-12 Pb(2^62, 50000) <= 5.4e-10 Pb(2^62, 500000) <= 5.4e-08 > This means, SAVI device should never set up a binding without DAD. In > another word, if a binding is set up without DAD, it is suspect the bound > address is reasonable. > > i think with the above probabilities, it is fairly safe to use an address even if the DAD packet was lost (that is essentially the principle behing optimistic DAD) > 2 DAD may be unreliable, but not so unreliable. > > DAD is unreliable by definition i.e. there is no ack back. You cannot get more unreliable than that > The DoD DoD? > situation you mentioned is a specified situation and a configuration > can be made to handle it. > > not sure what you mean by this > DAD can be lost, but it has little possibility. And the retransmission time > of DAD is configurable as described in [RFC4862], [RFC4861]. > > right, but the default value is 1, so you need to configure all the hosts in the network to change that value, which is not desirable and you cannot rely upon > Even fearing the possible DAD loss, it is still unreasonable to set up a > binding only on data packets and BDP. > > why? > Maybe the DAD loss problem can be handled through this way > > A. In PEACEF state, the SAVI device performs DAD for each new address > without previous DAD. > > the problem with the savi device issuing a DAD is that introduces a synch point. I mean, if the savi issues a DAD and it receives two replies, what does the savi does at that point? > B. In WAR state, the SAVI device drops all packets without previous DAD. > > C. If the SAVI device is triggered to perform DAD for more than X times in a > recent period, change the state from PEACE to AWR. > > D. If no filtering happens in a period, change the state from WAR to PEACE. > > This function can be enabled if the administrator find the link state is not > good enough. > > > > If by default connecting the host to the network, it may kill other hosts in > the network how comes this is the case? Regards, marcelo > and why we still need SAVI? > > > Regards, > Guang > > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > ·¢ËÍʱ¼ä: 2009Äê4ÔÂ30ÈÕ 21:14 > ÊÕ¼þÈË: Guang Yao > ³­ËÍ: 'SAVI Mailing List' > Ö÷Ìâ: Re: [savi] ***SPAM*** 6.181 (5) ת·¢: DAD as a binding distribution > protocol: why not > > Guang, > > The problem is that the DAD procedure is inherently unreliable, so the > NASOL msg can be lost and never get the SAVI device, These reasons > include from simply errors in the packets, DAD being lost (for instance > in dial on demand technologies, which are likely to discard the first > packet, which is as you say the DAD packet) > > So, i fully agree with you that when there is a DAD packet, the SAVI > device should use to create a binding. the problem is what if the DAD > packet gets lost. By default disconnecting the host from the network, > seems an overkill to me. > > Regards, marcelo > > > > Guang Yao escribi¨®: > >> Christian, >> >> I want to argue that, control packet snooping(DAD snooping) is both >> sufficient and necessary to set up binding for SLAAC address. >> >> ->: >> >> Obviously. >> >> <-: >> >> RFC 4862 >> >> /* >> >> 5.4. Duplicate Address Detection >> >> Duplicate Address Detection _/MUST/_ be performed on all unicast >> >> addresses prior to assigning them to an interface, regardless of >> >> whether they are obtained through stateless autoconfiguration, >> >> DHCPv6, or manual configuration, with the following exceptions: >> >> - An interface whose DupAddrDetectTransmits variable is set to zero >> >> does not perform Duplicate Address Detection. >> >> - Duplicate Address Detection MUST NOT be performed on anycast >> >> addresses (note that anycast addresses cannot syntactically be >> >> distinguished from unicast addresses). >> >> - Each individual unicast address SHOULD be tested for uniqueness. >> >> Note that there are implementations deployed that only perform >> >> Duplicate Address Detection for the link-local address and skip >> >> the test for the global address that uses the same interface >> >> identifier as that of the link-local address. Whereas this >> >> document does not invalidate such implementations, this kind of >> >> "optimization" is NOT RECOMMENDED, and new implementations MUST >> >> NOT do that optimization. This optimization came from the >> >> assumption that all of an interface's addresses are generated from >> >> the same identifier. However, the assumption does actually not >> >> stand; new types of addresses have been introduced where the >> >> interface identifiers are not necessarily the same for all unicast >> >> addresses on a single interface [RFC4941] [RFC3972]. Requiring >> >> that Duplicate Address Detection be performed for all unicast >> >> addresses will make the algorithm robust for the current and >> >> future special interface identifiers. >> >> */ >> >> Note that this is a MUST. >> >> Although a host may not conform to this specification, DAD is still >> needed. Before DAD, an address is suspicious to be used, in another >> word, it may be spoofing. >> >> Even there is a BDP to sync all the devices, there may be addresses >> not known by BDP, for example, hosts attached to legacy device, and >> their packets go through no SAVI device. >> >> Thus, without DAD, the SAVI device cannot get known whether this >> address has been used by other nodes. Only after a successful DAD, the >> SAVI device has confident to set up a binding for that address; or >> else, it may cause fallacious binding. >> >> And we can think that, when will a host send packets before DAD? >> >> It seems a DoS attacking scenario. >> >> Even it is not attacking, why does it have to act like this? >> >> Regards, >> >> Guang >> >> -----ÓʼþÔ­¼þ----- >> ·¢¼þÈË: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] ´ú±í >> Christian Vogt >> ·¢ËÍʱ¼ä: 2009Äê4ÔÂ23ÈÕ 12:40 >> ÊÕ¼þÈË: Jun Bi >> ³­ËÍ: Guang Yao; 'SAVI Mailing List'; 'Greg Daley'; 'Suresh Krishnan' >> Ö÷Ìâ: Re: [savi] DAD as a binding distribution protocol: why not >> >> On Apr 15, 2009, Jun Bi wrote: >> >> >>> Certainly, the major problem of SAVI-FCFS is not only the first packet >>> >>> lost. Even the first packet is not lost, FCFS still need a BDP, and it >>> >>> might be complex when we have multiple SAVI-swtiches (the real-time >>> >>> sync >>> >>> requirements), we even didn't see a prototype of BDP yet. But SAVI-CPS >>> >>> doesn't need the BDP, just need some enhancement. >>> >> Jun and all - >> >> When comparing FCFS and SAVI-CPS, we should be careful not to mix >> >> DHCP-based and SLAAC-based address configuration. >> >> It is true that SAVI-CPS, or control-packet-only snooping in general, >> >> may not need a BDP in the case of DHCP-assigned addresses. Thanks to >> >> the acknowledged address assignment exchange, the lack of an address >> >> binding in a SAVI device then implies with high reliability that packets >> >> locally originating from this address should be dropped. >> >> But in the case of addresses auto-configured via SLAAC, snooping only >> >> control packets doesn't have the same effect. Since there is no >> >> acknowledged address assignment exchange, the lack of an address binding >> >> in a SAVI device does NOT imply that packets locally originating from >> >> this address should be dropped. I.e., the best a SAVI device can do in >> >> this case is let such packets through. And the scenario that Marcelo >> >> had illustrated earlier shows that this may lead to a vulnerability. >> >> Hence, control-packet-only snooping in SLAAC could in some cases >> >> benefit from a BDP, independent of whether you use FCFS or SAVI-CPS. >> >> So the issue with SLAAC-based address configuration is the same whether >> >> we use FCFS or SAVI-CPS -- independent of whether we believe that this >> >> issue justifies the development of a BDP. >> >> - Christian >> >> _______________________________________________ >> >> savi mailing list >> >> savi@ietf.org >> >> https://www.ietf.org/mailman/listinfo/savi >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> >> > > > > From marcelo@it.uc3m.es Wed May 6 04:11:41 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D0603A6B6F for ; Wed, 6 May 2009 04:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=-3.092, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhMgqLfAdpsA for ; Wed, 6 May 2009 04:11:40 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id B32493A6E9D for ; Wed, 6 May 2009 04:10:55 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 2DCBD6C2583; Wed, 6 May 2009 13:12:19 +0200 (CEST) Message-ID: <4A017093.1040002@it.uc3m.es> Date: Wed, 06 May 2009 13:12:19 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Guang Yao References: <000001c9c86a$e5d993e0$b18cbba0$@tsinghua.edu.cn> <49F9A9E4.6080204@it.uc3m.es> <000101c9cd2a$dcda14d0$968e3e70$@tsinghua.edu.cn> <49FFFBE7.7010306@it.uc3m.es> <005501c9ce39$6f070ac0$4d152040$@tsinghua.edu.cn> In-Reply-To: <005501c9ce39$6f070ac0$4d152040$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16624.006 Cc: 'SAVI Mailing List' , 'Christian Vogt' Subject: Re: [savi] =?gb2312?b?tPC4tDogtPC4tDogQWJvdXQgdGhlIGZhaWx1cmUgc2l0?= =?gb2312?b?dWF0aW9uIG1lbnRpb25lZCBieSBNYXJjZWxv?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 11:11:41 -0000 Guang Yao escribi¨®: > right, but my point is that the situation that i described, also occurs > in the case that you have a single SAVI device in the whole subnet. so i > am not sure why we need to consider the BDP to solve this, since it may > occur in a situaton where you don't have a second savi device > > / *Guang:*/ > I don't think this is a reasonable hypothesis. Multiple SAVI devices is a > more common situation. > It is not an hypothesis that i am stating here. I am saying that the problem occurs even in the case of a single SAVI device, so i am not sure how this relates to an inter savi protocol. > >> / *Guang:*/ >> I mean, for example, >> Addresses A1, A2, A3... are bound on SAVI-Host port, >> And Address B1 appears on SAVI-Legacy port. >> If FCFS is used, if B1!= A1, A2, A3..., a new binding is set up for B1 and >> let pass B1. >> And in class A solution, if B1 != A1, A2, A3..., B1 is also let pass. >> Thus FCFS and class A have the same filtering ability. >> >> >> > > Not really, > > Using your example above, in the FCFS case you decribe above, if a > packet with source address B1 is received through a different port, then > it is discarded. In the class A solution, the SAVI device will always > let packet with source address B1 pass. irrespectively from which legacy > port is received. > > So, in FCFS, the set of hosts that can spoof address B1 is limited to > the set of hosts attached to the same lsavi port. While in the calss a > solution above any host can spoof address B1. > > so, in FCFS source address connected to a SAVI switch through a legacy > device, they still obtain some protection while in the class a solution > you describe, they obtain none. so, no, the filtering capabilities are > not the same > > / *Guang:*/ > > I fully agree that if two or more SAVI-Legacy ports exist on a SAVI switch, > FCFS may have better performance. > great! > But please note that another failure may happen: > Suppose two SAVI-Legacy ports L1, L2 exist on a SAVI device S, > A node B uses address B1, and its packets are forwarded by the legacy switch > attached to L1. Unfortunately, all its traffics > Are delivered to another node attaching to the legacy switch, without being > forwarded to S. Thus you never bind B1 with L1. > However, if another node uses B1 even after B is using B1, and its traffic > are forwarded to S on port L2. Then you will bind B1 with L2. > As a result, packets from B will be filtered by S, even it uses B1 first. > > So, the failure mode here requires that: 1- The DAD msg from the node A (The first one to use the source address is lost) 2- Then, that A sends packets only addressed to nodes connected to the same legacy switch 3- Then that node B autoconfigures the same address than node A 4- The, that the DAD msg of node B is lost (if not node A would defned its address) 5- Then that node B does send a packet through the SAVI device. In this case the node A who was the first to configure would be blocked by the SAVI device. I guess you realize that the probability of step 3 is incredibly low. In addition, this occurs if the TWO DAD packets are also lost and the traffic pattern is very specific. (in particular, i quote again the probability of step 3 According to RFC4429, the probability of a colision if nodes select the iid randomly (whcih is what DAD is aiming to prevent) is: (different values for different number of nodes in the subnte, ranging from 500 to 500000) Pb(262, 500) <= 5.4e-14 Pb(262, 5000) <= 5.4e-12 Pb(262, 50000) <= 5.4e-10 Pb(262, 500000) <= 5.4e-08) So, i don't think this as a failure mode is a real concern, but we may disagree. Regards, marcelo > FCFS is not a good idea for remote nodes. > > If FCFS wants to avoid such bad filtering, it's better not distinguish > SAVI-Legacy port from SAVI legacy port. Then, you can find that class A > Still has same filtering ability as FCFS, in spite of far less memory cost. > > > > > From marcelo@it.uc3m.es Wed May 6 04:14:49 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19E273A6ABD for ; Wed, 6 May 2009 04:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=-3.471, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, J_CHICKENPOX_83=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fT7Oe-uoQUQP for ; Wed, 6 May 2009 04:14:41 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 5CC443A6EAE for ; Wed, 6 May 2009 04:14:32 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 07B796C2597; Wed, 6 May 2009 13:15:50 +0200 (CEST) Message-ID: <4A017165.3030503@it.uc3m.es> Date: Wed, 06 May 2009 13:15:49 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Guang Yao References: <001101c9c874$23988750$6ac995f0$@tsinghua.edu.cn> <49F9A421.4080400@it.uc3m.es> <000001c9cd25$ec0822d0$c4186870$@tsinghua.edu.cn> <49FFFD99.8070709@it.uc3m.es> <005601c9ce3a$5f1cfc90$1d56f5b0$@tsinghua.edu.cn> In-Reply-To: <005601c9ce3a$5f1cfc90$1d56f5b0$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16624.006 Cc: 'SAVI Mailing List' Subject: Re: [savi] =?gb2312?b?tPC4tDogtPC4tDogICoqKlNQQU0qKiogNi4xODEgKDUp?= =?gb2312?b?INeqt6I6ICBEQUQgYXMgYSBiaW5kaW5nIGRpc3RyaWJ1dGlvbiBwcm90b2Nv?= =?gb2312?b?bDogd2h5IG5vdA==?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2009 11:14:49 -0000 Guang Yao escribi¨®: > Guang Yao escribi¨®: > >> Marcelo, >> >> I think this problem has two aspects: >> >> 1 Is it reasonable to set up binding without DAD? >> >> Even there is a BDP, so long as SAVI is not fully deployed, DAD is still >> needed to detect whether an address has been used by another node. >> >> > According to RFC4429, the probability of a colision if nodes select the > iid randomly (whcih is what DAD is aiming to prevent) is: > (different values for different number of nodes in the subnte, ranging > from 500 to 500000) > Pb(2^62, 500) <= 5.4e-14 > Pb(2^62, 5000) <= 5.4e-12 > Pb(2^62, 50000) <= 5.4e-10 > Pb(2^62, 500000) <= 5.4e-08 > > / *Guang:*/ > So, are you declare that DAD is never needed? > DAD is a safety net for extremely rare cases, as the probability above clearly show. In particular, it helps with hosts that are malfunctioning for instance. But in normal operation, the colision probability is really low, which is the basis for optimistic DAD > >> This means, SAVI device should never set up a binding without DAD. In >> another word, if a binding is set up without DAD, it is suspect the bound >> address is reasonable. >> >> >> > i think with the above probabilities, it is fairly safe to use an > address even if the DAD packet was lost (that is essentially the > principle behing optimistic DAD) > > / *Guang:*/ > If it is a probability problem, I could declare that DAD never get lost. > > not really there are some L2 that have a non negligible loss probability. In addition, dial on demand type of links, tend to loose the first packet, which is exactly the dad packet Regards, marcelo > >> 2 DAD may be unreliable, but not so unreliable. >> >> >> > DAD is unreliable by definition i.e. there is no ack back. You cannot > get more unreliable than that > > >> The DoD >> > DoD? > > >> situation you mentioned is a specified situation and a configuration >> can be made to handle it. >> >> >> > not sure what you mean by this > > >> DAD can be lost, but it has little possibility. And the retransmission >> > time > >> of DAD is configurable as described in [RFC4862], [RFC4861]. >> >> >> > > right, but the default value is 1, so you need to configure all the > hosts in the network to change that value, which is not desirable and > you cannot rely upon > > >> Even fearing the possible DAD loss, it is still unreasonable to set up a >> binding only on data packets and BDP. >> >> >> > why? > > >> Maybe the DAD loss problem can be handled through this way >> >> A. In PEACEF state, the SAVI device performs DAD for each new address >> without previous DAD. >> >> >> > the problem with the savi device issuing a DAD is that introduces a > synch point. I mean, if the savi issues a DAD and it receives two > replies, what does the savi does at that point? > >> B. In WAR state, the SAVI device drops all packets without previous DAD. >> >> C. If the SAVI device is triggered to perform DAD for more than X times in >> > a > >> recent period, change the state from PEACE to AWR. >> >> D. If no filtering happens in a period, change the state from WAR to >> > PEACE. > >> This function can be enabled if the administrator find the link state is >> > not > >> good enough. >> >> >> >> If by default connecting the host to the network, it may kill other hosts >> > in > >> the network >> > > how comes this is the case? > > Regards, marcelo > > > >> and why we still need SAVI? >> >> >> Regards, >> Guang >> >> -----ÓʼþÔ­¼þ----- >> ·¢¼þÈË: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> ·¢ËÍʱ¼ä: 2009Äê4ÔÂ30ÈÕ 21:14 >> ÊÕ¼þÈË: Guang Yao >> ³­ËÍ: 'SAVI Mailing List' >> Ö÷Ìâ: Re: [savi] ***SPAM*** 6.181 (5) ת·¢: DAD as a binding distribution >> protocol: why not >> >> Guang, >> >> The problem is that the DAD procedure is inherently unreliable, so the >> NASOL msg can be lost and never get the SAVI device, These reasons >> include from simply errors in the packets, DAD being lost (for instance >> in dial on demand technologies, which are likely to discard the first >> packet, which is as you say the DAD packet) >> >> So, i fully agree with you that when there is a DAD packet, the SAVI >> device should use to create a binding. the problem is what if the DAD >> packet gets lost. By default disconnecting the host from the network, >> seems an overkill to me. >> >> Regards, marcelo >> >> >> >> Guang Yao escribi¨®: >> >> >>> Christian, >>> >>> I want to argue that, control packet snooping(DAD snooping) is both >>> sufficient and necessary to set up binding for SLAAC address. >>> >>> ->: >>> >>> Obviously. >>> >>> <-: >>> >>> RFC 4862 >>> >>> /* >>> >>> 5.4. Duplicate Address Detection >>> >>> Duplicate Address Detection _/MUST/_ be performed on all unicast >>> >>> addresses prior to assigning them to an interface, regardless of >>> >>> whether they are obtained through stateless autoconfiguration, >>> >>> DHCPv6, or manual configuration, with the following exceptions: >>> >>> - An interface whose DupAddrDetectTransmits variable is set to zero >>> >>> does not perform Duplicate Address Detection. >>> >>> - Duplicate Address Detection MUST NOT be performed on anycast >>> >>> addresses (note that anycast addresses cannot syntactically be >>> >>> distinguished from unicast addresses). >>> >>> - Each individual unicast address SHOULD be tested for uniqueness. >>> >>> Note that there are implementations deployed that only perform >>> >>> Duplicate Address Detection for the link-local address and skip >>> >>> the test for the global address that uses the same interface >>> >>> identifier as that of the link-local address. Whereas this >>> >>> document does not invalidate such implementations, this kind of >>> >>> "optimization" is NOT RECOMMENDED, and new implementations MUST >>> >>> NOT do that optimization. This optimization came from the >>> >>> assumption that all of an interface's addresses are generated from >>> >>> the same identifier. However, the assumption does actually not >>> >>> stand; new types of addresses have been introduced where the >>> >>> interface identifiers are not necessarily the same for all unicast >>> >>> addresses on a single interface [RFC4941] [RFC3972]. Requiring >>> >>> that Duplicate Address Detection be performed for all unicast >>> >>> addresses will make the algorithm robust for the current and >>> >>> future special interface identifiers. >>> >>> */ >>> >>> Note that this is a MUST. >>> >>> Although a host may not conform to this specification, DAD is still >>> needed. Before DAD, an address is suspicious to be used, in another >>> word, it may be spoofing. >>> >>> Even there is a BDP to sync all the devices, there may be addresses >>> not known by BDP, for example, hosts attached to legacy device, and >>> their packets go through no SAVI device. >>> >>> Thus, without DAD, the SAVI device cannot get known whether this >>> address has been used by other nodes. Only after a successful DAD, the >>> SAVI device has confident to set up a binding for that address; or >>> else, it may cause fallacious binding. >>> >>> And we can think that, when will a host send packets before DAD? >>> >>> It seems a DoS attacking scenario. >>> >>> Even it is not attacking, why does it have to act like this? >>> >>> Regards, >>> >>> Guang >>> >>> -----ÓʼþÔ­¼þ----- >>> ·¢¼þÈË: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] ´ú±í >>> Christian Vogt >>> ·¢ËÍʱ¼ä: 2009Äê4ÔÂ23ÈÕ 12:40 >>> ÊÕ¼þÈË: Jun Bi >>> ³­ËÍ: Guang Yao; 'SAVI Mailing List'; 'Greg Daley'; 'Suresh Krishnan' >>> Ö÷Ìâ: Re: [savi] DAD as a binding distribution protocol: why not >>> >>> On Apr 15, 2009, Jun Bi wrote: >>> >>> >>> >>>> Certainly, the major problem of SAVI-FCFS is not only the first packet >>>> >>>> lost. Even the first packet is not lost, FCFS still need a BDP, and it >>>> >>>> might be complex when we have multiple SAVI-swtiches (the real-time >>>> >>>> sync >>>> >>>> requirements), we even didn't see a prototype of BDP yet. But SAVI-CPS >>>> >>>> doesn't need the BDP, just need some enhancement. >>>> >>>> >>> Jun and all - >>> >>> When comparing FCFS and SAVI-CPS, we should be careful not to mix >>> >>> DHCP-based and SLAAC-based address configuration. >>> >>> It is true that SAVI-CPS, or control-packet-only snooping in general, >>> >>> may not need a BDP in the case of DHCP-assigned addresses. Thanks to >>> >>> the acknowledged address assignment exchange, the lack of an address >>> >>> binding in a SAVI device then implies with high reliability that packets >>> >>> locally originating from this address should be dropped. >>> >>> But in the case of addresses auto-configured via SLAAC, snooping only >>> >>> control packets doesn't have the same effect. Since there is no >>> >>> acknowledged address assignment exchange, the lack of an address binding >>> >>> in a SAVI device does NOT imply that packets locally originating from >>> >>> this address should be dropped. I.e., the best a SAVI device can do in >>> >>> this case is let such packets through. And the scenario that Marcelo >>> >>> had illustrated earlier shows that this may lead to a vulnerability. >>> >>> Hence, control-packet-only snooping in SLAAC could in some cases >>> >>> benefit from a BDP, independent of whether you use FCFS or SAVI-CPS. >>> >>> So the issue with SLAAC-based address configuration is the same whether >>> >>> we use FCFS or SAVI-CPS -- independent of whether we believe that this >>> >>> issue justifies the development of a BDP. >>> >>> - Christian >>> >>> _______________________________________________ >>> >>> savi mailing list >>> >>> savi@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/savi >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >>> >>> >> >> >> > > > > From zhangdong_rh@huaweisymantec.com Tue May 12 18:32:13 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 416BD3A69EC for ; Tue, 12 May 2009 18:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.502 X-Spam-Level: **** X-Spam-Status: No, score=4.502 tagged_above=-999 required=5 tests=[AWL=-0.448, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zT1GzetP0IbQ for ; Tue, 12 May 2009 18:32:12 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 368333A6BE3 for ; Tue, 12 May 2009 18:32:12 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_qnxwGiwSQT0c/7sWGo9srg)" Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJK000126ZVFB70@hstga02-in.huaweisymantec.com> for savi@ietf.org; Wed, 13 May 2009 09:33:33 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJK005836ZTZQ20@hstml01-in.huaweisymantec.com> for savi@ietf.org; Wed, 13 May 2009 09:33:31 +0800 (CST) Received: from [10.27.154.181] by hstml01-in.huaweisymantec.com (mshttpd); Wed, 13 May 2009 09:33:29 +0800 From: ZhangDong To: 'SAVI Mailing List' Message-id: Date: Wed, 13 May 2009 09:33:29 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal Cc: pnallur@huawei.com Subject: [savi] =?gb2312?b?16q3ojogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv?= =?gb2312?b?ciBkcmFmdC1kb25nLXNhdmktY2dhLWhlYWRlci0wMQ==?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 01:32:13 -0000 This is a multi-part message in MIME format. --Boundary_(ID_qnxwGiwSQT0c/7sWGo9srg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Content-disposition: inline Hi Folks=2C I have published draft-dong-savi-cga-header-01=2E = The main difference between -00- and -01- is that I add a new section in= -01-=2E The new section describes using destination extension header to= take the CGA information instead of creating the new CGA extension head= er=2E Welcome comments=2E The URL is http=3A//tools=2Eietf=2Eorg/html/draft-dong-savi-cga-header-0= 1 Thank you very much=2E Dong Zhang Huaweisymantec Technologies Co=2E=2C Ltd TEL=EF=BC=9A86-10-62721287 FAX=EF=BC=9A86-10-62721347 ADDRESS=EF=BC=9A3rd Floor=2CSection D=2C Keshi Building=2C No=2E28=2C Xi= nxi Rd=2E=2C Shangdi=2C = Haidian Dist=2E=2C Beijing=2C China=2E 100085= --Boundary_(ID_qnxwGiwSQT0c/7sWGo9srg) Content-type: message/rfc822 Content-disposition: inline Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJI00FGEPA62A80@hstga01-in.huaweisymantec.com> for zhangdong_rh@huaweisymantec.com; Tue, 12 May 2009 14:13:20 +0800 (CST) Received: from hstrg01-in.huaweisymantec.com ([172.26.3.37]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KJI004DKPA5RQ00@hstml01-in.huaweisymantec.com> for zhangdong_rh@huaweisymantec.com (ORCPT zhangdong_rh@huaweisymantec.com); Tue, 12 May 2009 14:13:18 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by hstrg01-in.huaweisymantec.com (MOS 3.8.5-GA) id AHP18043; Tue, 12 May 2009 14:08:16 +0800 (CST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by hstrg01-in.huaweisymantec.com (MOS 3.8.5-GA) with ESMTP id AHP18042; Tue, 12 May 2009 14:08:15 +0800 (CST) Received: by core3.amsl.com (Postfix, from userid 30) id F2A253A68B2; Mon, 11 May 2009 23:11:43 -0700 (PDT) Date: Mon, 11 May 2009 23:11:43 -0700 (PDT) From: IETF I-D Submission Tool Subject: New Version Notification for draft-dong-savi-cga-header-01 To: zhangdong_rh@huaweisymantec.com Cc: pnallur@huawei.com Message-id: <20090512061143.F2A253A68B2@core3.amsl.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT X-Junkmail-Status: score=10/55, host=hstrg01-in.huaweisymantec.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A150205.4A09137C.011A:SCFSTAT3674418,ss=1,fgs=0, ip=64.170.98.32, so=2007-07-31 18:51:00, dmn=5.7.1/2008-09-02 X-Mirapoint-Loop-Id: d96dc61453ca59a8fcd67da201864280 A new version of I-D, draft-dong-savi-cga-header-01.txt has been successfuly submitted by Dong Zhang and posted to the IETF repository. Filename: draft-dong-savi-cga-header Revision: 01 Title: CGA Extension Header of IPv6 Creation_date: 2009-05-12 WG ID: Independent Submission Number_of_pages: 15 Abstract: This document specifies a method based on Cryptographically Generated Addresses (CGA) for protecting the IPv6 network from address spoofing. The basic idea is to define a new IPv6 extension header which is called CGA header. Three new options of CGA header are introduced to satisfy the need of verification between all CGA-aware nodes. This document also illustrates the proposed verification procedure under several different situations. Additionally, a possible alternative way using destination options header to take CGA information is described. The IETF Secretariat. --Boundary_(ID_qnxwGiwSQT0c/7sWGo9srg)-- From marcelo@it.uc3m.es Thu May 14 05:25:14 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F72028C273 for ; Thu, 14 May 2009 05:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.526 X-Spam-Level: X-Spam-Status: No, score=-1.526 tagged_above=-999 required=5 tests=[AWL=-3.710, BAYES_05=-1.11, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYuxQKmRCszf for ; Thu, 14 May 2009 05:25:12 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 0609B3A6A3E for ; Thu, 14 May 2009 05:24:56 -0700 (PDT) Received: from r190-135-30-59.dialup.adsl.anteldata.net.uy (r190-135-30-59.dialup.adsl.anteldata.net.uy [190.135.30.59]) by smtp02.uc3m.es (Postfix) with ESMTP id EE1DA6B19E1; Thu, 14 May 2009 14:26:26 +0200 (CEST) Message-ID: <4A0C0DF1.1000605@it.uc3m.es> Date: Thu, 14 May 2009 14:26:25 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Guang Yao References: <000001c9c86a$e5d993e0$b18cbba0$@tsinghua.edu.cn> <49F9A9E4.6080204@it.uc3m.es> <000101c9cd2a$dcda14d0$968e3e70$@tsinghua.edu.cn> <49FFFBE7.7010306@it.uc3m.es> <005501c9ce39$6f070ac0$4d152040$@tsinghua.edu.cn> <4A017093.1040002@it.uc3m.es> <000601c9d388$00ade860$0209b920$@tsinghua.edu.cn> In-Reply-To: <000601c9d388$00ade860$0209b920$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16640.006 Cc: 'SAVI Mailing List' Subject: Re: [savi] =?gb2312?b?tPC4tDogtPC4tDogtPC4tDogQWJvdXQgdGhlIGZhaWx1?= =?gb2312?b?cmUgc2l0dWF0aW9uIG1lbnRpb25lZCBieSBNYXJjZWxv?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 12:25:14 -0000 Guang Yao escribi¨®: > >> But please note that another failure may happen: >> Suppose two SAVI-Legacy ports L1, L2 exist on a SAVI device S, >> A node B uses address B1, and its packets are forwarded by the legacy >> > switch > >> attached to L1. Unfortunately, all its traffics >> Are delivered to another node attaching to the legacy switch, without >> > being > >> forwarded to S. Thus you never bind B1 with L1. >> However, if another node uses B1 even after B is using B1, and its traffic >> are forwarded to S on port L2. Then you will bind B1 with L2. >> As a result, packets from B will be filtered by S, even it uses B1 first. >> >> >> > > So, the failure mode here requires that: > 1- The DAD msg from the node A (The first one to use the source address > is lost) > 2- Then, that A sends packets only addressed to nodes connected to the > same legacy switch > 3- Then that node B autoconfigures the same address than node A > 4- The, that the DAD msg of node B is lost (if not node A would defned > its address) > 5- Then that node B does send a packet through the SAVI device. > In this case the node A who was the first to configure would be blocked > by the SAVI device. > I guess you realize that the probability of step 3 is incredibly low. In > addition, this occurs if the TWO DAD packets are also lost and the > traffic pattern is very specific. > > > /*Guang*/ > See this situation you mentioned: > +-------+ > | HOST | > +-------+ > | > +------------------+ > | LEGACY SWITCH | > +------------------+ > | > +------------------+ > | SAVI CPS DEVICE | > +------------------+ > | > +----------------+ > | REST of WORLD | > +----------------+ > > > You said SAVI device may reboot and lost previous bindings. > > Then the first few packets are not DAD, but data packets. how come? Are you assuming DAD packets were lost? > If the data > packets don't reach SAVI, not binding will be set up. Thus, a second user of > an address may trigger a binding before the first one. Then FCFS will set up > a wrong binding. > this only happens if the set of events i have described below occurs, and i made the point that the probability of that happenining is negligible. > And I don't think it is a collision problem. Triggering the SAVI device to > set up wrong binding is an attacking model against SAVI itself. > > > I am kind of confused here. In your previous email you stated: "But please note that another failure may happen" And then you described a failure. I addressed to you the events that were needed to that failure to happen, and made the point that the probability of that failure was negligible. However, now you talk about an attack. So are you talking about an attack or a failure? If you are talking about an atack, please describe it in detail, cause you have previously described a failure. Regards, marcelo From marcelo@it.uc3m.es Sat May 16 13:54:49 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 514F73A6C30 for ; Sat, 16 May 2009 13:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=-2.952, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BE4Lmj8Lj98 for ; Sat, 16 May 2009 13:54:48 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 243393A67D9 for ; Sat, 16 May 2009 13:54:48 -0700 (PDT) Received: from r190-135-61-225.dialup.adsl.anteldata.net.uy (r190-135-61-225.dialup.adsl.anteldata.net.uy [190.135.61.225]) by smtp02.uc3m.es (Postfix) with ESMTP id 5A8F16BA35D; Sat, 16 May 2009 22:56:17 +0200 (CEST) Message-ID: <4A0F286E.3090400@it.uc3m.es> Date: Sat, 16 May 2009 22:56:14 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Guang Yao References: <000001c9c86a$e5d993e0$b18cbba0$@tsinghua.edu.cn> <49F9A9E4.6080204@it.uc3m.es> <000101c9cd2a$dcda14d0$968e3e70$@tsinghua.edu.cn> <49FFFBE7.7010306@it.uc3m.es> <005501c9ce39$6f070ac0$4d152040$@tsinghua.edu.cn> <4A017093.1040002@it.uc3m.es> <000601c9d388$00ade860$0209b920$@tsinghua.edu.cn> <4A0C0DF1.1000605@it.uc3m.es> <000001c9d500$07ec1b00$17c45100$@tsinghua.edu.cn> In-Reply-To: <000001c9d500$07ec1b00$17c45100$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16646.002 Cc: 'SAVI Mailing List' Subject: Re: [savi] =?gb2312?b?tPC4tDogILTwuLQ6ILTwuLQ6ILTwuLQ6IEFib3V0IHRo?= =?gb2312?b?ZSBmYWlsdXJlIHNpdHVhdGlvbiBtZW50aW9uZWQgYnkgTWFyY2Vsbw==?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2009 20:54:49 -0000 Guang Yao escribi¨®: > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] ´ú±í marcelo > bagnulo braun > ·¢ËÍʱ¼ä: 2009Äê5ÔÂ14ÈÕ 20:26 > ÊÕ¼þÈË: Guang Yao > ³­ËÍ: 'SAVI Mailing List' > Ö÷Ìâ: Re: [savi] ´ð¸´: ´ð¸´: ´ð¸´: About the failure situation mentioned by > Marcelo > > Guang Yao escribi¨®: > >>> But please note that another failure may happen: >>> Suppose two SAVI-Legacy ports L1, L2 exist on a SAVI device S, >>> A node B uses address B1, and its packets are forwarded by the legacy >>> >>> >> switch >> >> >>> attached to L1. Unfortunately, all its traffics >>> Are delivered to another node attaching to the legacy switch, without >>> >>> >> being >> >> >>> forwarded to S. Thus you never bind B1 with L1. >>> However, if another node uses B1 even after B is using B1, and its >>> > traffic > >>> are forwarded to S on port L2. Then you will bind B1 with L2. >>> As a result, packets from B will be filtered by S, even it uses B1 first. >>> >>> >>> >>> >> So, the failure mode here requires that: >> 1- The DAD msg from the node A (The first one to use the source address >> is lost) >> 2- Then, that A sends packets only addressed to nodes connected to the >> same legacy switch >> 3- Then that node B autoconfigures the same address than node A >> 4- The, that the DAD msg of node B is lost (if not node A would defned >> its address) >> 5- Then that node B does send a packet through the SAVI device. >> In this case the node A who was the first to configure would be blocked >> by the SAVI device. >> I guess you realize that the probability of step 3 is incredibly low. In >> addition, this occurs if the TWO DAD packets are also lost and the >> traffic pattern is very specific. >> >> >> /*Guang*/ >> See this situation you mentioned: >> +-------+ >> | HOST | >> +-------+ >> | >> +------------------+ >> | LEGACY SWITCH | >> +------------------+ >> | >> +------------------+ >> | SAVI CPS DEVICE | >> +------------------+ >> | >> +----------------+ >> | REST of WORLD | >> +----------------+ >> >> >> You said SAVI device may reboot and lost previous bindings. >> >> Then the first few packets are not DAD, but data packets. >> > how come? Are you assuming DAD packets were lost? > > >> If the data >> packets don't reach SAVI, not binding will be set up. Thus, a second user >> > of > >> an address may trigger a binding before the first one. Then FCFS will set >> > up > >> a wrong binding. >> >> > > this only happens if the set of events i have described below occurs, > and i made the point that the probability of that happenining is negligible. > > /*Guang*/ > It doesn't require that two DAD both are lost. > If the SAVI device is turned on after the nodes attached to legacy switches > are configured, > FCFS will cause wrong binding. > I am guessing we are making different set of assumptions here, cause i fail to see how this could be the case Regards, marcelo > >> And I don't think it is a collision problem. Triggering the SAVI device to >> set up wrong binding is an attacking model against SAVI itself. >> >> >> >> > > > I am kind of confused here. > In your previous email you stated: "But please note that another failure > may happen" > And then you described a failure. I addressed to you the events that > were needed to that failure to happen, and made the point that the > probability of that failure was negligible. > However, now you talk about an attack. > > So are you talking about an attack or a failure? > If you are talking about an atack, please describe it in detail, cause > you have previously described a failure. > > > Regards, marcelo > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > > > From christian.vogt@ericsson.com Wed May 20 13:28:01 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7650F3A6C20 for ; Wed, 20 May 2009 13:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NW1rieGoixz for ; Wed, 20 May 2009 13:28:00 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 30D9B3A684C for ; Wed, 20 May 2009 13:28:00 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n4KKeEad002735; Wed, 20 May 2009 15:40:16 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 May 2009 15:29:01 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 May 2009 15:29:01 -0500 Message-Id: <2AE43E7B-7B84-4751-8871-B8A949F52666@ericsson.com> From: Christian Vogt To: Marcelo Bagnulo Braun , Guang Yao , SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 20 May 2009 13:29:00 -0700 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 20 May 2009 20:29:01.0402 (UTC) FILETIME=[9C5F7BA0:01C9D989] Subject: [savi] SAVI Bindings For Hosts Behind Legacy Switches? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 20:28:01 -0000 Forked from thread: "About the failure situation mentioned by Marcelo". Marcelo, Guang, and all - Thanks for your discussion on whether SAVI bindings should be created only for directly attached hosts, or also for hosts attached via legacy switches. This discussion was extremely useful. Let me summarize a few conclusions from it. You have identified two classes of SAVI solutions: - Class A, in which SAVI devices create bindings only for hosts that are directly attached. - Class B, in which SAVI devices create bindings also for host that are attached via one or more legacy switches. FWIW, on a personal note, I think that both of these solution classes are FCFS, they are just different variants of it. The variants have important differences, for sure, but they both follow the FCFS model. After all, they only affect which hosts are to be protected, not how the hosts are protected. Given the restrictions set forth by our charter, neither of the above two classes of SAVI solutions can be a silver bullet, of course. Both models have their limitations, as your discussions has shown: - Class A provides a lower level of protection because the addresses of hosts behind a legacy switch are not protected against spoofing. This defeats the purpose of SAVI in deployment scenarios where all hosts are separated from the SAVI device through a legacy switch. An example where this may be the case is DSL networks, where SAVI may be performed on a provider-side device, and all hosts attach to this SAVI device via a legacy switch on the customer side. - Class A requires extra manual configuration of SAVI devices in terms of which binding anchors are to be protected, and which are not. - Class B may, in specific cases, introduce a higher vulnerability to denial of service than class A: In general, a vulnerability to denial of service exists if an attacker (a) finds out about the address of a victim host, and (b) is in a position to trick a SAVI device into creating a fake binding for the victim host's address, using a binding anchor other than the one the victim host would use. This would cause the SAVI device to prevent the victim host from using its own address. A situation where this vulnerability may occur is where a SAVI device does not receive the first packet sent by the victim host, but the attacker does. The SAVI device then does not create a binding for the victim host, potentially enabling the attacker to create a fake binding on behalf of the victim host. The presence of a legacy switch between the SAVI device on one side, and the victim host and the attacker on the other side, increases the chance that this situation occurs for two reasons: First, because the probability for loss is higher for packets that have to traverse a legacy switch to reach the SAVI device. Second, because the legacy switch may deliberately not forward a packet to the SAVI device if the destination is known not to be reachable via the SAVI device. In such a situation, class B would enable the attacker to create a fake binding on behalf of the victim host, whereas class A does not. - Class B may potentially requires more memory per SAVI device than class A. SAVI devices need to maintain bindings not only for directly attached hosts, but also for hosts behind legacy switches. Given that both classes of SAVI solutions have strengths and weaknesses relative to each other, we may consider giving the network administrator the possibility to choose. All that would be needed for this is a capability of SAVI devices to en- or disable protection of specific binding anchors. Protection being enabled for all binding anchors would thus represent a SAVI solution of class A, while disabling protection for binding anchors associated with legacy switches would represent a SAVI solution of class B. The important question is what the default should be. We should discuss this question. - Christian From christian.vogt@ericsson.com Wed May 20 13:51:21 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E16C43A6FBF for ; Wed, 20 May 2009 13:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0Wr2vbWV0h9 for ; Wed, 20 May 2009 13:51:21 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 3447E3A6F0A for ; Wed, 20 May 2009 13:51:20 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n4KL3ajC013854; Wed, 20 May 2009 16:03:38 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 May 2009 15:52:26 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 May 2009 15:52:26 -0500 Message-Id: <9F7E4D0A-C5B3-4F3A-9025-B7BB78997B8E@ericsson.com> From: Christian Vogt To: Guang Yao In-Reply-To: <001101c9c874$23988750$6ac995f0$@tsinghua.edu.cn> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 20 May 2009 13:52:25 -0700 References: <001101c9c874$23988750$6ac995f0$@tsinghua.edu.cn> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 20 May 2009 20:52:26.0440 (UTC) FILETIME=[E1D74480:01C9D98C] Cc: SAVI Mailing List Subject: Re: [savi] DAD as a binding distribution protocol: why not X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 20:51:22 -0000 On Apr 28, 2009, Guang Yao wrote: > Thus, without DAD, the SAVI device cannot get known whether this > address > has been used by other nodes. Only after a successful DAD, the SAVI > device has confident to set up a binding for that address; or else, it > may cause fallacious binding. Guang - As with the first data packet, also the DAD packets are not guaranteed to reach the SAVI device. There are two reasons for this: First, DAD packets may get lost, as Marcelo has mentioned. This is in particular so if the DAD packets have to make an extra hop via a legacy switch. Second, because the DAD packets may deliberately not be forwarded to the SAVI device. DAD packets are not broadcast; they are either unicast or limited to a certain multicast group, so they may not reach the SAVI device. Since DAD packets are not guaranteed to reach the SAVI device just as data packets, CPS may run into problems that are very similar to the FCFS- specific problems you have identified. - Christian From marcelo@it.uc3m.es Thu May 21 10:14:54 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C9A3A6E2F for ; Thu, 21 May 2009 10:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.624 X-Spam-Level: X-Spam-Status: No, score=-5.624 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCdaA1PCjFa5 for ; Thu, 21 May 2009 10:14:49 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 8B2C13A6BA1 for ; Thu, 21 May 2009 10:14:47 -0700 (PDT) Received: from r190-135-20-227.dialup.adsl.anteldata.net.uy (r190-135-20-227.dialup.adsl.anteldata.net.uy [190.135.20.227]) by smtp02.uc3m.es (Postfix) with ESMTP id DE5B26BAC6E; Thu, 21 May 2009 19:16:06 +0200 (CEST) Message-ID: <4A158C55.5030700@it.uc3m.es> Date: Thu, 21 May 2009 19:16:05 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christian Vogt References: <2AE43E7B-7B84-4751-8871-B8A949F52666@ericsson.com> In-Reply-To: <2AE43E7B-7B84-4751-8871-B8A949F52666@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16656.000 Cc: Guang Yao , SAVI Mailing List Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 17:14:54 -0000 Christian, Christian Vogt escribió: > Forked from thread: "About the failure situation mentioned by Marcelo". > > > Marcelo, Guang, and all - > > Thanks for your discussion on whether SAVI bindings should be created > only for directly attached hosts, or also for hosts attached via legacy > switches. This discussion was extremely useful. Let me summarize a few > conclusions from it. > > You have identified two classes of SAVI solutions: > > - Class A, in which SAVI devices create bindings only for hosts that are > directly attached. > > - Class B, in which SAVI devices create bindings also for host that are > attached via one or more legacy switches. > > FWIW, on a personal note, I think that both of these solution classes > are FCFS, they are just different variants of it. The variants have > important differences, for sure, but they both follow the FCFS model. > After all, they only affect which hosts are to be protected, not how the > hosts are protected. > > Given the restrictions set forth by our charter, neither of the above > two classes of SAVI solutions can be a silver bullet, of course. Both > models have their limitations, as your discussions has shown: > > - Class A provides a lower level of protection because the addresses of > hosts behind a legacy switch are not protected against spoofing. > This defeats the purpose of SAVI in deployment scenarios where all > hosts are separated from the SAVI device through a legacy switch. An > example where this may be the case is DSL networks, where SAVI may > be performed on a provider-side device, and all hosts attach to this > SAVI device via a legacy switch on the customer side. > > - Class A requires extra manual configuration of SAVI devices in terms > of which binding anchors are to be protected, and which are not. > > - Class B may, in specific cases, introduce a higher vulnerability to > denial of service than class A: In general, a vulnerability to > denial of service exists if an attacker (a) finds out about the > address of a victim host, and (b) is in a position to trick a SAVI > device into creating a fake binding for the victim host's address, > using a binding anchor other than the one the victim host would use. > This would cause the SAVI device to prevent the victim host from > using its own address. > > A situation where this vulnerability may occur is where a SAVI device > does not receive the first packet sent by the victim host, but the > attacker does. and also the attacker knows that the savi device has not received the packet I mean, i really think this attack as you described, it hardly an attack. I mean, are you suggesting that the attacker will wait to launch an attack until it finds a node that connects to the network, sends it first packet, the packet is not received by the savi device so it can send the first packet to trick the savi device? I am not sure how effective would be such an attack. The attacker needs to wait there till all the conditions hold to manage to block the node. I don't think this is a serious issue. > The SAVI device then does not create a binding for the > victim host, potentially enabling the attacker to create a fake > binding on behalf of the victim host. The presence of a legacy switch > between the SAVI device on one side, and the victim host and the > attacker on the other side, increases the chance that this situation > occurs for two reasons: First, because the probability for loss is > higher for packets that have to traverse a legacy switch to reach the > SAVI device. Second, because the legacy switch may deliberately not > forward a packet to the SAVI device if the destination is known not to > be reachable via the SAVI device. mmm, it is more complex that that. the first packet is expected to be the NADV for DAD, whcih is tracked by the SAVI device and is used to create a binding So, the situation is that the DAD addressed to the sol node mcast group is not forwared. That requires at least that the L2 multicast is implemented (i.e. it is not mapped to the bradcast) and that there is no node of the same sol node mcast group in other ports of the savi device. > In such a situation, class B would > enable the attacker to create a fake binding on behalf of the victim > host, whereas class A does not. > > - Class B may potentially requires more memory per SAVI device than > class A. SAVI devices need to maintain bindings not only for > directly attached hosts, but also for hosts behind legacy switches. sure, the scope of protection is proportional to the memory required. Similarly, you can reduce the memory required by limiting the number of bindings you have. Of course it imply less protection. So, this is not related about class A or Class B, but to the fact that if you want to have n bindings, you need n times the memory requried for a binding. Regards, marcelo > > Given that both classes of SAVI solutions have strengths and weaknesses > relative to each other, we may consider giving the network administrator > the possibility to choose. All that would be needed for this is a > capability of SAVI devices to en- or disable protection of specific > binding anchors. Protection being enabled for all binding anchors would > thus represent a SAVI solution of class A, while disabling protection > for binding anchors associated with legacy switches would represent a > SAVI solution of class B. The important question is what the default > should be. We should discuss this question. > > - Christian > > > From christian.vogt@ericsson.com Thu May 21 10:51:16 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BE6F3A6E04 for ; Thu, 21 May 2009 10:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82ujmQNopXji for ; Thu, 21 May 2009 10:51:14 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id B12C73A6FFA for ; Thu, 21 May 2009 10:51:08 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n4LI3MEq019119; Thu, 21 May 2009 13:03:28 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 May 2009 12:52:28 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 May 2009 12:52:27 -0500 Message-Id: From: Christian Vogt To: marcelo bagnulo braun In-Reply-To: <4A158C55.5030700@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 21 May 2009 10:52:27 -0700 References: <2AE43E7B-7B84-4751-8871-B8A949F52666@ericsson.com> <4A158C55.5030700@it.uc3m.es> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 21 May 2009 17:52:27.0643 (UTC) FILETIME=[E7AB5CB0:01C9DA3C] Cc: Guang Yao , SAVI Mailing List Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 17:51:16 -0000 Marcelo - >> - Class B may, in specific cases, introduce a higher vulnerability to >> denial of service than class A: In general, a vulnerability to >> denial of service exists if an attacker (a) finds out about the >> address of a victim host, and (b) is in a position to trick a SAVI >> device into creating a fake binding for the victim host's address, >> using a binding anchor other than the one the victim host would >> use. >> This would cause the SAVI device to prevent the victim host from >> using its own address. >> >> A situation where this vulnerability may occur is where a SAVI device >> does not receive the first packet sent by the victim host, but the >> attacker does. > > > and also the attacker knows that the savi device has not received the > packet I mean, i really think this attack as you described, it > hardly an > attack. I mean, are you suggesting that the attacker will wait to > launch > an attack until it finds a node that connects to the network, sends it > first packet, the packet is not received by the savi device so it can > send the first packet to trick the savi device? I am not sure how > effective would be such an attack. The attacker needs to wait there > till > all the conditions hold to manage to block the node. I don't think > this > is a serious issue. True. >> The SAVI device then does not create a binding for the victim host, >> potentially enabling the attacker to create a fake binding on >> behalf of >> the victim host. The presence of a legacy switch between the SAVI >> device on one side, and the victim host and the attacker on the other >> side, increases the chance that this situation occurs for two >> reasons: >> First, because the probability for loss is higher for packets that >> have >> to traverse a legacy switch to reach the SAVI device. Second, >> because >> the legacy switch may deliberately not forward a packet to the SAVI >> device if the destination is known not to be reachable via the SAVI >> device. > > mmm, it is more complex that that. the first packet is expected to be > the NADV for DAD, whcih is tracked by the SAVI device and is used to > create a binding So, the situation is that the DAD addressed to the > sol > node mcast group is not forwared. That requires at least that the L2 > multicast is implemented (i.e. it is not mapped to the bradcast) and > that there is no node of the same sol node mcast group in other > ports of > the savi device. Right, the legacy switch would have to be an MLD-snooping switch. Otherwise, the switch would forward the DAD Neighbor Solicitation to all of its ports, hence also always to the SAVI device. This is why I said "the legacy switch /may/ not forward a packet to the SAVI device" because in many cases it will. >> - Class B may potentially requires more memory per SAVI device than >> class A. SAVI devices need to maintain bindings not only for >> directly attached hosts, but also for hosts behind legacy switches. > > sure, the scope of protection is proportional to the memory required. > Similarly, you can reduce the memory required by limiting the number > of > bindings you have. Of course it imply less protection. So, this is not > related about class A or Class B, but to the fact that if you want to > have n bindings, you need n times the memory requried for a binding. What is relevant here is whether we endow SAVI devices with a capability to disable protection of certain binding anchors (typically switch ports). This determines whether a SAVI device can rely on a different SAVI device to handle some of its binding anchors, and hence to refrain from establishing bindings for that anchor. Without such a capability, multiple SAVI devices may end up creating the same binding. According to Guang's definition of class A and class B, the capability to disable protection of certain binding anchors exists only for class A. Therefore, this /is/ related to Guang's classification. Nevertheless, there is nothing that would prevent adding the same capability to FCFS, which we are currently associating with class B. And I think this would make sense because it helps reducing memory requirements for SAVI devices. Do you agree? - Christian From marcelo@it.uc3m.es Thu May 21 10:59:22 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84E33A68C3 for ; Thu, 21 May 2009 10:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.636 X-Spam-Level: X-Spam-Status: No, score=-5.636 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvKdUD8cMg6L for ; Thu, 21 May 2009 10:59:21 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 6BCB828C16A for ; Thu, 21 May 2009 10:59:21 -0700 (PDT) Received: from r190-135-20-227.dialup.adsl.anteldata.net.uy (r190-135-20-227.dialup.adsl.anteldata.net.uy [190.135.20.227]) by smtp03.uc3m.es (Postfix) with ESMTP id 0A7EF7F2DAE; Thu, 21 May 2009 20:00:45 +0200 (CEST) Message-ID: <4A1596CB.6050807@it.uc3m.es> Date: Thu, 21 May 2009 20:00:43 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christian Vogt References: <2AE43E7B-7B84-4751-8871-B8A949F52666@ericsson.com> <4A158C55.5030700@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16656.001 Cc: Guang Yao , SAVI Mailing List Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 17:59:22 -0000 Christian Vogt escribió: > Marcelo - > >>> - Class B may, in specific cases, introduce a higher vulnerability to >>> denial of service than class A: In general, a vulnerability to >>> denial of service exists if an attacker (a) finds out about the >>> address of a victim host, and (b) is in a position to trick a SAVI >>> device into creating a fake binding for the victim host's address, >>> using a binding anchor other than the one the victim host would use. >>> This would cause the SAVI device to prevent the victim host from >>> using its own address. >>> >>> A situation where this vulnerability may occur is where a SAVI device >>> does not receive the first packet sent by the victim host, but the >>> attacker does. >> >> >> and also the attacker knows that the savi device has not received the >> packet I mean, i really think this attack as you described, it hardly an >> attack. I mean, are you suggesting that the attacker will wait to launch >> an attack until it finds a node that connects to the network, sends it >> first packet, the packet is not received by the savi device so it can >> send the first packet to trick the savi device? I am not sure how >> effective would be such an attack. The attacker needs to wait there till >> all the conditions hold to manage to block the node. I don't think this >> is a serious issue. > > True. > >>> The SAVI device then does not create a binding for the victim host, >>> potentially enabling the attacker to create a fake binding on behalf of >>> the victim host. The presence of a legacy switch between the SAVI >>> device on one side, and the victim host and the attacker on the other >>> side, increases the chance that this situation occurs for two reasons: >>> First, because the probability for loss is higher for packets that have >>> to traverse a legacy switch to reach the SAVI device. Second, because >>> the legacy switch may deliberately not forward a packet to the SAVI >>> device if the destination is known not to be reachable via the SAVI >>> device. >> >> mmm, it is more complex that that. the first packet is expected to be >> the NADV for DAD, whcih is tracked by the SAVI device and is used to >> create a binding So, the situation is that the DAD addressed to the sol >> node mcast group is not forwared. That requires at least that the L2 >> multicast is implemented (i.e. it is not mapped to the bradcast) and >> that there is no node of the same sol node mcast group in other ports of >> the savi device. > > Right, the legacy switch would have to be an MLD-snooping switch. > Otherwise, the switch would forward the DAD Neighbor Solicitation to all > of its ports, hence also always to the SAVI device. This is why I said > "the legacy switch /may/ not forward a packet to the SAVI device" > because in many cases it will. > >>> - Class B may potentially requires more memory per SAVI device than >>> class A. SAVI devices need to maintain bindings not only for >>> directly attached hosts, but also for hosts behind legacy switches. >> >> sure, the scope of protection is proportional to the memory required. >> Similarly, you can reduce the memory required by limiting the number of >> bindings you have. Of course it imply less protection. So, this is not >> related about class A or Class B, but to the fact that if you want to >> have n bindings, you need n times the memory requried for a binding. > > What is relevant here is whether we endow SAVI devices with a capability > to disable protection of certain binding anchors (typically switch > ports). This determines whether a SAVI device can rely on a different > SAVI device to handle some of its binding anchors, and hence to refrain > from establishing bindings for that anchor. Without such a capability, > multiple SAVI devices may end up creating the same binding. > > According to Guang's definition of class A and class B, the capability > to disable protection of certain binding anchors exists only for class > A. Therefore, this /is/ related to Guang's classification. > Nevertheless, there is nothing that would prevent adding the same > capability to FCFS, which we are currently associating with class B. > And I think this would make sense because it helps reducing memory > requirements for SAVI devices. Do you agree? sure, disabling SAVI on a per port basis seems a reasonable feature to have in general. Seems a matter of local policy though Moreover i would expect that by default switches will have savi off in all ports and that savi capability needs to be turn on explicitly in the device, and it maybe on for some ports and not for others. This is beyond the issue of memory consumption i guess. But again, this a matter of the swithc vendor and the local policy imho regards, marcelo > > - Christian > > > From christian.vogt@ericsson.com Thu May 21 11:16:23 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 864B23A69A9 for ; Thu, 21 May 2009 11:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oje454y0YWDf for ; Thu, 21 May 2009 11:16:22 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id B45B33A68FC for ; Thu, 21 May 2009 11:16:22 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n4LIHv0n005712; Thu, 21 May 2009 13:18:00 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 May 2009 13:17:57 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 May 2009 13:17:56 -0500 Message-Id: <427DB789-E5B3-4257-992F-65C2A14A82A2@ericsson.com> From: Christian Vogt To: marcelo bagnulo braun In-Reply-To: <4A1596CB.6050807@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 21 May 2009 11:17:56 -0700 References: <2AE43E7B-7B84-4751-8871-B8A949F52666@ericsson.com> <4A158C55.5030700@it.uc3m.es> <4A1596CB.6050807@it.uc3m.es> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 21 May 2009 18:17:56.0426 (UTC) FILETIME=[76E522A0:01C9DA40] Cc: Guang Yao , SAVI Mailing List Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 18:16:23 -0000 > sure, disabling SAVI on a per port basis seems a reasonable feature to > have in general. Seems a matter of local policy though Moreover i > would > expect that by default switches will have savi off in all ports and > that > savi capability needs to be turn on explicitly in the device, and it > maybe on for some ports and not for others. This is beyond the issue > of > memory consumption i guess. But again, this a matter of the swithc > vendor and the local policy imho Yes, this is a good way of looking at it. At the same time, the capability to disable protection of certain binding anchors was the key difference between Guang's class A and class B. My conclusion is hence that we have found consensus here to add this capability to our SAVI solution, and that we can close this issue. (In fact, some of us were discussing such a capability earlier, and the conclusion already then was that this would be a good idea. The capability just wasn't added to the SAVI solution yet.) If somebody thinks there is more to be discussed, please speak up. - Christian From marcelo@it.uc3m.es Thu May 21 11:38:55 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 684EC3A6C60 for ; Thu, 21 May 2009 11:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.957 X-Spam-Level: X-Spam-Status: No, score=-5.957 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOBTjkPrJamd for ; Thu, 21 May 2009 11:38:54 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 5C00F3A68B8 for ; Thu, 21 May 2009 11:38:53 -0700 (PDT) Received: from r190-135-14-198.dialup.adsl.anteldata.net.uy (r190-135-14-198.dialup.adsl.anteldata.net.uy [190.135.14.198]) by smtp01.uc3m.es (Postfix) with ESMTP id BBD6BBA58AD; Thu, 21 May 2009 20:40:28 +0200 (CEST) Message-ID: <4A15A01A.2020206@it.uc3m.es> Date: Thu, 21 May 2009 20:40:26 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christian Vogt References: <2AE43E7B-7B84-4751-8871-B8A949F52666@ericsson.com> <4A158C55.5030700@it.uc3m.es> <4A1596CB.6050807@it.uc3m.es> <427DB789-E5B3-4257-992F-65C2A14A82A2@ericsson.com> In-Reply-To: <427DB789-E5B3-4257-992F-65C2A14A82A2@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16656.001 Cc: Guang Yao , SAVI Mailing List Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 18:38:55 -0000 Christian Vogt escribió: >> sure, disabling SAVI on a per port basis seems a reasonable feature to >> have in general. Seems a matter of local policy though Moreover i would >> expect that by default switches will have savi off in all ports and that >> savi capability needs to be turn on explicitly in the device, and it >> maybe on for some ports and not for others. This is beyond the issue of >> memory consumption i guess. But again, this a matter of the swithc >> vendor and the local policy imho > > > Yes, this is a good way of looking at it. At the same time, the > capability to disable protection of certain binding anchors was the key > difference between Guang's class A and class B. mmm, i understood that the main difference was that bindins were created based only in DAD packets (class A) or were created by DAD and data packts (class B), and that class A was by defualt dropping packets (unless a binding existed) while class B was by default creating a binding (if the binding did not exist) Class A also required to configure which ports were connected to legacy devices to work prperly What we are agreeing here is that it would be reaosnable to allow savi to be disable for a set of ports, but this is not same to impose configuration of which ports are savi and which are not, based on what is connected to them in order to make the solution work. Having the capability of disabling SAVI on a per ports issues is a feature. Requiring to do so when a legacy device is connect to it, is a burden Just to clarify Regards, marcelo > > My conclusion is hence that we have found consensus here to add this > capability to our SAVI solution, and that we can close this issue. (In > fact, some of us were discussing such a capability earlier, and the > conclusion already then was that this would be a good idea. The > capability just wasn't added to the SAVI solution yet.) > > If somebody thinks there is more to be discussed, please speak up. > > - Christian > > > > From christian.vogt@ericsson.com Thu May 21 12:20:39 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70EF13A6784 for ; Thu, 21 May 2009 12:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRzOS25nHQoa for ; Thu, 21 May 2009 12:20:38 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 9D7773A6A4C for ; Thu, 21 May 2009 12:20:38 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n4LJWuHN024329; Thu, 21 May 2009 14:32:59 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 May 2009 14:21:51 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 May 2009 14:21:51 -0500 Message-Id: <4F3B9A6F-A767-44E8-A886-5D33E6B41F51@ericsson.com> From: Christian Vogt To: marcelo bagnulo braun In-Reply-To: <4A15A01A.2020206@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 21 May 2009 12:21:51 -0700 References: <2AE43E7B-7B84-4751-8871-B8A949F52666@ericsson.com> <4A158C55.5030700@it.uc3m.es> <4A1596CB.6050807@it.uc3m.es> <427DB789-E5B3-4257-992F-65C2A14A82A2@ericsson.com> <4A15A01A.2020206@it.uc3m.es> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 21 May 2009 19:21:51.0317 (UTC) FILETIME=[64AB1050:01C9DA49] Cc: Guang Yao , SAVI Mailing List Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 19:20:39 -0000 Marcelo - > mmm, i understood that the main difference was that bindins were > created > based only in DAD packets (class A) or were created by DAD and data > packts (class B), and that class A was by defualt dropping packets > (unless a binding existed) while class B was by default creating a > binding (if the binding did not exist) Guang's definition of classes A and B did not cover which packet types to use for binding creation. It only covered for which binding anchors to create bindings. This said, our discussion did, partly, touch both of these aspects, leading to an association of class A with CPS and of class B with FCFS. But I think the discussion of CPS vs. FCFS should be separate. > What we are agreeing here is that it would be reaosnable to allow savi > to be disable for a set of ports [...] Yes. > [...] but this is not same to impose configuration of which ports are > savi and which are not, based on what is connected to them in order to > make the solution work. Absolutely. - Christian From christian.vogt@ericsson.com Thu May 21 13:59:08 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719923A6D50 for ; Thu, 21 May 2009 13:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKgFcUv6IBEh for ; Thu, 21 May 2009 13:59:07 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 8CF553A6CE2 for ; Thu, 21 May 2009 13:59:07 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n4LLBOl2029488; Thu, 21 May 2009 16:11:27 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 May 2009 16:00:14 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 May 2009 16:00:14 -0500 Message-Id: <8C954FE7-97A9-4128-85A0-76CE6552B68B@ericsson.com> From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 21 May 2009 14:00:14 -0700 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 21 May 2009 21:00:14.0232 (UTC) FILETIME=[23146980:01C9DA57] Subject: [savi] Summary of FCFS-versus-CPS discussion X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2009 20:59:08 -0000 Dear all - There has recently been a discussion on whether a SAVI device should, for a statelessly auto-configured address, create a binding either based on any first packet sent from this address, or based on the result of the DAD procedure for the address. The former approach is followed by FCFS; the latter approach is followed by CPS. The discussion so far has shown that both FCFS and CPS have strengths and weaknesses. I would like to share with you my summary of the discussion so far, to ensure that nothing is missed, and to provide a basis for moving forward: - The advantage of FCFS is that the probability of false packet drops is very low. In general, a risk for a false packet drop exists when a host has an address, but the SAVI device guarding the host does not have a binding for this address. FCFS can deal with this situation because it can create bindings at any time. On the other hand, CPS cannot easily deal with this situation because it can create bindings only during a DAD procedure. Hence, CPS has a higher probability for false packet drops. - The advantage of CPS is that, in most scenarios, there is no need for a designated protocol for binding verification. Since CPS creates bindings only during DAD, it can re-use DAD for binding verification. FCFS cannot re-use DAD for binding verification because it may create bindings when DAD is not performed. This said, there are scenarios in which a designated binding verification protocol may be required also for CPS. DAD is not reliable, and hence cannot provide reliable binding verification either. Reliable binding verification, in turn, may be desired in some scenarios, such as in DSL networks. A designated binding verification protocol may hence be necessary for those scenarios. Do folks agree with this summary? Please speak up if you think the summary above is missing something. - Christian From marcelo@it.uc3m.es Thu May 21 21:20:14 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD193A6FC6 for ; Thu, 21 May 2009 21:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfRZXYyXb+Pa for ; Thu, 21 May 2009 21:20:13 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 8D4FD3A6E4E for ; Thu, 21 May 2009 21:20:13 -0700 (PDT) Received: from r190-135-25-50.dialup.adsl.anteldata.net.uy (r190-135-25-50.dialup.adsl.anteldata.net.uy [190.135.25.50]) by smtp01.uc3m.es (Postfix) with ESMTP id E04EEB4A4D0; Fri, 22 May 2009 06:21:48 +0200 (CEST) Message-ID: <4A16285B.3010901@it.uc3m.es> Date: Fri, 22 May 2009 06:21:47 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christian Vogt References: <8C954FE7-97A9-4128-85A0-76CE6552B68B@ericsson.com> In-Reply-To: <8C954FE7-97A9-4128-85A0-76CE6552B68B@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16656.004 Cc: SAVI Mailing List Subject: Re: [savi] Summary of FCFS-versus-CPS discussion X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 04:20:14 -0000 Christian, Christian Vogt escribió: > Dear all - > > There has recently been a discussion on whether a SAVI device should, > for a statelessly auto-configured address, create a binding either based > on any first packet sent from this address, or based on the result of > the DAD procedure for the address. The former approach is followed by > FCFS;the latter approach is followed by CPS. I don't think this description is accurate. FCFS as defined in http://www.ietf.org/internet-drafts/draft-ietf-savi-fcfs-01.txt creates binding using _both_ data packets and the DAD packets. I understand that the distinction is the following: - FCFS uses _both_ data and DAD packets to create the bindings - CPS uses _only_ DAD packets to create the bindings (i.e. does not uses data packets) The main difference imho is not that one: the main difference imho is the default behaviour of the mechanism. In FCFS, if a data packet arrives for which there is no binding, the FCFS SAVI device learns the binding and forwards the packet. In CPS, if a data packet arrives for which there is no binding, the packet is discarded. there are several implications of such behaviour, as you mention below... I agree with the description you make below regards, marcelo > The discussion so far has > shown that both FCFS and CPS have strengths and weaknesses. I would > like to share with you my summary of the discussion so far, to ensure > that nothing is missed, and to provide a basis for moving forward: > > - The advantage of FCFS is that the probability of false packet drops is > very low. In general, a risk for a false packet drop exists when a > host has an address, but the SAVI device guarding the host does not > have a binding for this address. FCFS can deal with this situation > because it can create bindings at any time. On the other hand, CPS > cannot easily deal with this situation because it can create > bindings only during a DAD procedure. Hence, CPS has a higher > probability for false packet drops. > > - The advantage of CPS is that, in most scenarios, there is no need for > a designated protocol for binding verification. Since CPS creates > bindings only during DAD, it can re-use DAD for binding > verification.FCFS cannot re-use DAD for binding verification > because it may create bindings when DAD is not performed. This > said, there are scenarios in which a designated binding verification > protocol may be required also for CPS. DAD is not reliable, and > hence cannot provide reliable binding verification either. Reliable > binding verification, in turn, may be desired in some scenarios, > such as in DSL networks. A designated binding verification protocol > may hence be necessary for those scenarios. > > Do folks agree with this summary? Please speak up if you think the > summary above is missing something. > > - Christian > > > From yaoa02@mails.tsinghua.edu.cn Sun May 31 01:01:48 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40F0F3A6A6F for ; Sun, 31 May 2009 01:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.965 X-Spam-Level: ** X-Spam-Status: No, score=2.965 tagged_above=-999 required=5 tests=[AWL=2.964, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YB8op5DFJphK for ; Sun, 31 May 2009 01:01:47 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id E0DB43A67D8 for ; Sun, 31 May 2009 01:01:46 -0700 (PDT) Received: from tu132214.ip.tsinghua.edu.cn ([166.111.132.214] helo=netarchld5f663) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1MAg0i-00071R-1B; Sun, 31 May 2009 16:03:16 +0800 From: "Guang Yao" To: "'Christian Vogt'" , "'Marcelo Bagnulo Braun'" , "'SAVI Mailing List'" References: <2AE43E7B-7B84-4751-8871-B8A949F52666@ericsson.com> In-Reply-To: <2AE43E7B-7B84-4751-8871-B8A949F52666@ericsson.com> Date: Sun, 31 May 2009 16:03:03 +0800 Message-ID: <001201c9e1c6$399cc780$acd65680$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnZib/lOVWuo+aSSb+KHa6gI/wA5QIKjSzw Content-Language: zh-cn Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 08:01:48 -0000 -----Original Message----- From: Christian Vogt [mailto:christian.vogt@ericsson.com] Sent: Thursday, May 21, 2009 4:29 AM To: Marcelo Bagnulo Braun; Guang Yao; SAVI Mailing List Subject: SAVI Bindings For Hosts Behind Legacy Switches? Forked from thread: "About the failure situation mentioned by Marcelo". Marcelo, Guang, and all - Thanks for your discussion on whether SAVI bindings should be created only for directly attached hosts, or also for hosts attached via legacy switches. This discussion was extremely useful. Let me summarize a few conclusions from it. You have identified two classes of SAVI solutions: - Class A, in which SAVI devices create bindings only for hosts that are directly attached. - Class B, in which SAVI devices create bindings also for host that are attached via one or more legacy switches. FWIW, on a personal note, I think that both of these solution classes are FCFS, they are just different variants of it. The variants have important differences, for sure, but they both follow the FCFS model. After all, they only affect which hosts are to be protected, not how the hosts are protected. IMO, both solution classes are also working for CPS. They can be discussed without regarding whether FCFS or CPS or something else is chosen. Given the restrictions set forth by our charter, neither of the above two classes of SAVI solutions can be a silver bullet, of course. Both models have their limitations, as your discussions has shown: - Class A provides a lower level of protection because the addresses of hosts behind a legacy switch are not protected against spoofing. This defeats the purpose of SAVI in deployment scenarios where all hosts are separated from the SAVI device through a legacy switch. An example where this may be the case is DSL networks, where SAVI may be performed on a provider-side device, and all hosts attach to this SAVI device via a legacy switch on the customer side. - Class A requires extra manual configuration of SAVI devices in terms of which binding anchors are to be protected, and which are not. - Class B may, in specific cases, introduce a higher vulnerability to denial of service than class A: In general, a vulnerability to denial of service exists if an attacker (a) finds out about the address of a victim host, and (b) is in a position to trick a SAVI device into creating a fake binding for the victim host's address, using a binding anchor other than the one the victim host would use. This would cause the SAVI device to prevent the victim host from using its own address. A situation where this vulnerability may occur is where a SAVI device does not receive the first packet sent by the victim host, but the attacker does. The SAVI device then does not create a binding for the victim host, potentially enabling the attacker to create a fake binding on behalf of the victim host. The presence of a legacy switch between the SAVI device on one side, and the victim host and the attacker on the other side, increases the chance that this situation occurs for two reasons: First, because the probability for loss is higher for packets that have to traverse a legacy switch to reach the SAVI device. Second, because the legacy switch may deliberately not forward a packet to the SAVI device if the destination is known not to be reachable via the SAVI device. In such a situation, class B would enable the attacker to create a fake binding on behalf of the victim host, whereas class A does not. Exactly! And I want to give two of my points here: 1 FCFS I think there are at least 3 kinds of FCFS: (1) FCFS to the routing system (2) FCFS to the SAVI system (3) FCFS to a SAVI device Only (1) is reasonable to trigger a new binding. However, in FCFS draft, (3) is taken as (1). This defect of class B is actually due to (3) is not equal to (1), especially for indirect connected hosts. If hosts are direct connected to SAVI device, (1) can be inferred from (3). This is the reason why I prefer class A than class B. The same thing also happens on CPS. And as I mentioned in previous mails, even with a perfect BDP, FCFS is still not reasonable to set up legal bindings, because (3) cannot be inferred from (2). However, for CPS, (1) can be inferred from CPS. There is actually no difference between FCFS and CPS on the basic idea: who uses it first, and who gets it. The real difference is, which is real FCFS, and which just looks like "FCFS". - Class B may potentially requires more memory per SAVI device than class A. SAVI devices need to maintain bindings not only for directly attached hosts, but also for hosts behind legacy switches. I think the memory cost problem is an important problem. I have discussed with some switch vendors, and they told me it is very hard for an access device to set up a filtering table for potentially thousands of hosts Given that both classes of SAVI solutions have strengths and weaknesses relative to each other, we may consider giving the network administrator the possibility to choose. All that would be needed for this is a capability of SAVI devices to en- or disable protection of specific binding anchors. Protection being enabled for all binding anchors would thus represent a SAVI solution of class A, while disabling protection for binding anchors associated with legacy switches would represent a SAVI solution of class B. The important question is what the default should be. We should discuss this question. - Christian From marcelo@it.uc3m.es Sun May 31 03:36:38 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B53228C16B for ; Sun, 31 May 2009 03:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.368 X-Spam-Level: X-Spam-Status: No, score=-6.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-koxvo+C3cs for ; Sun, 31 May 2009 03:36:37 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 36BFA28C112 for ; Sun, 31 May 2009 03:36:36 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (42.pool85-53-143.dynamic.orange.es [85.53.143.42]) by smtp01.uc3m.es (Postfix) with ESMTP id 5AC36B4D1A3; Sun, 31 May 2009 12:38:19 +0200 (CEST) Message-ID: <4A225E1C.1080300@it.uc3m.es> Date: Sun, 31 May 2009 12:38:20 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Guang Yao References: <2AE43E7B-7B84-4751-8871-B8A949F52666@ericsson.com> <001201c9e1c6$399cc780$acd65680$@tsinghua.edu.cn> In-Reply-To: <001201c9e1c6$399cc780$acd65680$@tsinghua.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16674.006 Cc: 'SAVI Mailing List' , 'Christian Vogt' Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 10:36:38 -0000 Guang Yao escribió: > -----Original Message----- > From: Christian Vogt [mailto:christian.vogt@ericsson.com] > Sent: Thursday, May 21, 2009 4:29 AM > To: Marcelo Bagnulo Braun; Guang Yao; SAVI Mailing List > Subject: SAVI Bindings For Hosts Behind Legacy Switches? > > Forked from thread: "About the failure situation mentioned by Marcelo". > > > Marcelo, Guang, and all - > > Thanks for your discussion on whether SAVI bindings should be created > only for directly attached hosts, or also for hosts attached via legacy > switches. This discussion was extremely useful. Let me summarize a few > conclusions from it. > > You have identified two classes of SAVI solutions: > > - Class A, in which SAVI devices create bindings only for hosts that are > directly attached. > > - Class B, in which SAVI devices create bindings also for host that are > attached via one or more legacy switches. > > FWIW, on a personal note, I think that both of these solution classes > are FCFS, they are just different variants of it. The variants have > important differences, for sure, but they both follow the FCFS model. > After all, they only affect which hosts are to be protected, not how the > hosts are protected. > > IMO, both solution classes are also working for CPS. They can be discussed > without regarding whether FCFS or CPS or something else is chosen. > > Given the restrictions set forth by our charter, neither of the above > two classes of SAVI solutions can be a silver bullet, of course. Both > models have their limitations, as your discussions has shown: > > - Class A provides a lower level of protection because the addresses of > hosts behind a legacy switch are not protected against spoofing. > This defeats the purpose of SAVI in deployment scenarios where all > hosts are separated from the SAVI device through a legacy switch. An > example where this may be the case is DSL networks, where SAVI may > be performed on a provider-side device, and all hosts attach to this > SAVI device via a legacy switch on the customer side. > > - Class A requires extra manual configuration of SAVI devices in terms > of which binding anchors are to be protected, and which are not. > > - Class B may, in specific cases, introduce a higher vulnerability to > denial of service than class A: In general, a vulnerability to > denial of service exists if an attacker (a) finds out about the > address of a victim host, and (b) is in a position to trick a SAVI > device into creating a fake binding for the victim host's address, > using a binding anchor other than the one the victim host would use. > This would cause the SAVI device to prevent the victim host from > using its own address. > > A situation where this vulnerability may occur is where a SAVI device > does not receive the first packet sent by the victim host, but the > attacker does. The SAVI device then does not create a binding for > the > victim host, potentially enabling the attacker to create a fake > binding on behalf of the victim host. The presence of a legacy > switch > between the SAVI device on one side, and the victim host and the > attacker on the other side, increases the chance that this situation > occurs for two reasons: First, because the probability for loss is > higher for packets that have to traverse a legacy switch to reach the > SAVI device. Second, because the legacy switch may deliberately not > forward a packet to the SAVI device if the destination is known not > to > be reachable via the SAVI device. In such a situation, class B would > enable the attacker to create a fake binding on behalf of the victim > host, whereas class A does not. > > I am kind of confused with the format of the reply, since it is hard to distinguish the original text from Christian and Guang's reply, but, i understnad that the text below is Guang's reply.... > Exactly! > And I want to give two of my points here: > 1 FCFS > I think there are at least 3 kinds of FCFS: > (1) FCFS to the routing system > I don't understnad what do you mean by FCFS to the routing system, do you mean the case the SAVI device is colocated with a router? > (2) FCFS to the SAVI system > (3) FCFS to a SAVI device > I fail to see the difference between these two... do you mean 2) is the case you have multiple SAVI devices and 3) being the case where you have only one SAVI device? > Only (1) is reasonable to trigger a new binding. However, in FCFS draft, > (3) is taken as (1). This defect of class B is actually due to (3) is not > equal to (1), > especially for indirect connected hosts. If hosts are direct connected to > SAVI device, > (1) can be inferred from (3). This is the reason why I prefer class A than > class B. The > same thing also happens on CPS. > > And as I mentioned in previous mails, even with a perfect BDP, FCFS is still > not > reasonable to set up legal bindings, because (3) cannot be inferred from > (2). However, > for CPS, (1) can be inferred from CPS. > > I cannot comment on this since i don't understand the definitions of 1,2 and 3 > There is actually no difference between FCFS and CPS on the basic idea: who > uses it first, and who gets it. > i agree with this > The real difference is, which is real FCFS, and which just looks like > "FCFS". > > no, the difference is what is the default action when the device receives a data packet for which it doesn't have a binding, to learn or to discard > - Class B may potentially requires more memory per SAVI device than > class A. SAVI devices need to maintain bindings not only for > directly attached hosts, but also for hosts behind legacy switches. > > I think the memory cost problem is an important problem. I have discussed > with some switch vendors, > and they told me it is very hard for an access device to set up a filtering > table for potentially thousands of hosts > > I disagree that the memory requirements are different both FCFS and CPS learn based on DAD packets (FCFS also learns in the case of data packets) In general, hosts will issue the DAD and as i understand both CPS and FCFS will generate a binding based on the DAD packet, is this correct for CPS? If so, then i argue that the amount of memory is very similar in both cases. I mean, the need to use data packets to create binding is deal with those cases where the DAD is lost or not issued after a change in the topology, which will not change significantly the amount of memory needed Regards, marcelo > Given that both classes of SAVI solutions have strengths and weaknesses > relative to each other, we may consider giving the network administrator > the possibility to choose. All that would be needed for this is a > capability of SAVI devices to en- or disable protection of specific > binding anchors. Protection being enabled for all binding anchors would > thus represent a SAVI solution of class A, while disabling protection > for binding anchors associated with legacy switches would represent a > SAVI solution of class B. The important question is what the default > should be. We should discuss this question. > > - Christian > > > > > From yaoa02@mails.tsinghua.edu.cn Sun May 31 06:50:26 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23DD3A6CF3 for ; Sun, 31 May 2009 06:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.369 X-Spam-Level: * X-Spam-Status: No, score=1.369 tagged_above=-999 required=5 tests=[AWL=3.968, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgIQ5dDB1xZt for ; Sun, 31 May 2009 06:50:21 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 9FE8C3A69CF for ; Sun, 31 May 2009 06:50:19 -0700 (PDT) Received: from tu132214.ip.tsinghua.edu.cn ([166.111.132.214] helo=netarchld5f663) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1MAlRu-0002nw-BF; Sun, 31 May 2009 21:51:42 +0800 From: "Guang Yao" To: "'marcelo bagnulo braun'" References: <2AE43E7B-7B84-4751-8871-B8A949F52666@ericsson.com> <001201c9e1c6$399cc780$acd65680$@tsinghua.edu.cn> <4A225E1C.1080300@it.uc3m.es> In-Reply-To: <4A225E1C.1080300@it.uc3m.es> Date: Sun, 31 May 2009 21:51:29 +0800 Message-ID: <001e01c9e1f6$e609b4d0$b21d1e70$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acnh2+v78Xxc2rU9S9CakrRGhHQOsAAGLrSw Content-Language: zh-cn Cc: 'SAVI Mailing List' , 'Christian Vogt' Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 13:50:26 -0000 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: Sunday, May 31, 2009 6:38 PM > To: Guang Yao > Cc: 'Christian Vogt'; 'SAVI Mailing List' > Subject: Re: SAVI Bindings For Hosts Behind Legacy Switches? >=20 > Guang Yao escribi=F3: > > -----Original Message----- > > From: Christian Vogt [mailto:christian.vogt@ericsson.com] > > Sent: Thursday, May 21, 2009 4:29 AM > > To: Marcelo Bagnulo Braun; Guang Yao; SAVI Mailing List > > Subject: SAVI Bindings For Hosts Behind Legacy Switches? > > > > Forked from thread: "About the failure situation mentioned by = Marcelo". > > > > > > Marcelo, Guang, and all - > > > > Thanks for your discussion on whether SAVI bindings should be = created > > only for directly attached hosts, or also for hosts attached via = legacy > > switches. This discussion was extremely useful. Let me summarize a > few > > conclusions from it. > > > > You have identified two classes of SAVI solutions: > > > > - Class A, in which SAVI devices create bindings only for hosts that = are > > directly attached. > > > > - Class B, in which SAVI devices create bindings also for host that = are > > attached via one or more legacy switches. > > > > FWIW, on a personal note, I think that both of these solution = classes > > are FCFS, they are just different variants of it. The variants have > > important differences, for sure, but they both follow the FCFS = model. > > After all, they only affect which hosts are to be protected, not how = the > > hosts are protected. > > > > IMO, both solution classes are also working for CPS. They can be discussed > > without regarding whether FCFS or CPS or something else is chosen. > > > > Given the restrictions set forth by our charter, neither of the = above > > two classes of SAVI solutions can be a silver bullet, of course. = Both > > models have their limitations, as your discussions has shown: > > > > - Class A provides a lower level of protection because the addresses = of > > hosts behind a legacy switch are not protected against spoofing. > > This defeats the purpose of SAVI in deployment scenarios where = all > > hosts are separated from the SAVI device through a legacy switch. = An > > example where this may be the case is DSL networks, where SAVI = may > > be performed on a provider-side device, and all hosts attach to = this > > SAVI device via a legacy switch on the customer side. > > > > - Class A requires extra manual configuration of SAVI devices in = terms > > of which binding anchors are to be protected, and which are not. > > > > - Class B may, in specific cases, introduce a higher vulnerability = to > > denial of service than class A: In general, a vulnerability to > > denial of service exists if an attacker (a) finds out about the > > address of a victim host, and (b) is in a position to trick a = SAVI > > device into creating a fake binding for the victim host's = address, > > using a binding anchor other than the one the victim host would = use. > > This would cause the SAVI device to prevent the victim host from > > using its own address. > > > > A situation where this vulnerability may occur is where a SAVI = device > > does not receive the first packet sent by the victim host, but = the > > attacker does. The SAVI device then does not create a binding = for > > the > > victim host, potentially enabling the attacker to create a fake > > binding on behalf of the victim host. The presence of a legacy > > switch > > between the SAVI device on one side, and the victim host and the > > attacker on the other side, increases the chance that this = situation > > occurs for two reasons: First, because the probability for loss = is > > higher for packets that have to traverse a legacy switch to reach = the > > SAVI device. Second, because the legacy switch may deliberately = not > > forward a packet to the SAVI device if the destination is known = not > > to > > be reachable via the SAVI device. In such a situation, class B = would > > enable the attacker to create a fake binding on behalf of the = victim > > host, whereas class A does not. > > > > > I am kind of confused with the format of the reply, since it is hard = to > distinguish the original text from Christian and Guang's reply, but, i > understnad that the text below is Guang's reply.... Sorry for confusing.=20 >=20 > > Exactly! > > And I want to give two of my points here: > > 1 FCFS > > I think there are at least 3 kinds of FCFS: > > (1) FCFS to the routing system > > > I don't understnad what do you mean by FCFS to the routing system, do > you mean the case the SAVI device is colocated with a router? >=20 > > (2) FCFS to the SAVI system > > (3) FCFS to a SAVI device > > > I fail to see the difference between these two... do you mean 2) is = the > case you have multiple SAVI devices and 3) being the case where you = have > only one SAVI device? (1) means the address is first ever appearing on the current routing = system, including all the network device. (2) means the address is first ever appearing on one of all the SAVI devices. >=20 > > Only (1) is reasonable to trigger a new binding. However, in FCFS = draft, > > (3) is taken as (1). This defect of class B is actually due to (3) = is not > > equal to (1), > > especially for indirect connected hosts. If hosts are direct = connected to > > SAVI device, > > (1) can be inferred from (3). This is the reason why I prefer class = A than > > class B. The > > same thing also happens on CPS. > > > > And as I mentioned in previous mails, even with a perfect BDP, FCFS = is still > > not > > reasonable to set up legal bindings, because (3) cannot be inferred = from > > (2). However, > > for CPS, (1) can be inferred from CPS. > > > > > I cannot comment on this since i don't understand the definitions of = 1,2 > and 3 >=20 > > There is actually no difference between FCFS and CPS on the basic = idea: > who > > uses it first, and who gets it. > > > i agree with this >=20 > > The real difference is, which is real FCFS, and which just looks = like > > "FCFS". > > > > > no, the difference is what is the default action when the device > receives a data packet for which it doesn't have a binding, to learn = or > to discard I think the inner difference is which is real FCFS. >=20 > > - Class B may potentially requires more memory per SAVI device than > > class A. SAVI devices need to maintain bindings not only for > > directly attached hosts, but also for hosts behind legacy = switches. > > > > I think the memory cost problem is an important problem. I have discussed > > with some switch vendors, > > and they told me it is very hard for an access device to set up a filtering > > table for potentially thousands of hosts > > > > >=20 > I disagree that the memory requirements are different > both FCFS and CPS learn based on DAD packets (FCFS also learns in the > case of data packets) > In general, hosts will issue the DAD and as i understand both CPS and > FCFS will generate a binding based on the DAD packet, is this correct > for CPS? > If so, then i argue that the amount of memory is very similar in both > cases. I mean, the need to use data packets to create binding is deal > with those cases where the DAD is lost or not issued after a change in > the topology, which will not change significantly the amount of memory > needed >=20 Here we just discuss that class B requires more memory than class A, not CPS and FCFS. > Regards, marcelo >=20 >=20 > > Given that both classes of SAVI solutions have strengths and = weaknesses > > relative to each other, we may consider giving the network = administrator > > the possibility to choose. All that would be needed for this is a > > capability of SAVI devices to en- or disable protection of specific > > binding anchors. Protection being enabled for all binding anchors = would > > thus represent a SAVI solution of class A, while disabling = protection > > for binding anchors associated with legacy switches would represent = a > > SAVI solution of class B. The important question is what the = default > > should be. We should discuss this question. > > > > - Christian > > > > > > > > > > From marcelo@it.uc3m.es Sun May 31 07:08:58 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE153A6D42 for ; Sun, 31 May 2009 07:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRSi8tv5ZgYs for ; Sun, 31 May 2009 07:08:57 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id B5F333A6C9D for ; Sun, 31 May 2009 07:08:56 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (42.pool85-53-143.dynamic.orange.es [85.53.143.42]) by smtp02.uc3m.es (Postfix) with ESMTP id E6F6B655862; Sun, 31 May 2009 16:10:37 +0200 (CEST) Message-ID: <4A228FDD.9060207@it.uc3m.es> Date: Sun, 31 May 2009 16:10:37 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Guang Yao References: <2AE43E7B-7B84-4751-8871-B8A949F52666@ericsson.com> <001201c9e1c6$399cc780$acd65680$@tsinghua.edu.cn> <4A225E1C.1080300@it.uc3m.es> <001e01c9e1f6$e609b4d0$b21d1e70$@tsinghua.edu.cn> In-Reply-To: <001e01c9e1f6$e609b4d0$b21d1e70$@tsinghua.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16674.007 Cc: 'SAVI Mailing List' , 'Christian Vogt' Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 14:08:58 -0000 Guang Yao escribió: > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Sunday, May 31, 2009 6:38 PM >> To: Guang Yao >> Cc: 'Christian Vogt'; 'SAVI Mailing List' >> Subject: Re: SAVI Bindings For Hosts Behind Legacy Switches? >> >> Guang Yao escribió: >> >>> -----Original Message----- >>> From: Christian Vogt [mailto:christian.vogt@ericsson.com] >>> Sent: Thursday, May 21, 2009 4:29 AM >>> To: Marcelo Bagnulo Braun; Guang Yao; SAVI Mailing List >>> Subject: SAVI Bindings For Hosts Behind Legacy Switches? >>> >>> Forked from thread: "About the failure situation mentioned by Marcelo". >>> >>> >>> Marcelo, Guang, and all - >>> >>> Thanks for your discussion on whether SAVI bindings should be created >>> only for directly attached hosts, or also for hosts attached via legacy >>> switches. This discussion was extremely useful. Let me summarize a >>> >> few >> >>> conclusions from it. >>> >>> You have identified two classes of SAVI solutions: >>> >>> - Class A, in which SAVI devices create bindings only for hosts that are >>> directly attached. >>> >>> - Class B, in which SAVI devices create bindings also for host that are >>> attached via one or more legacy switches. >>> >>> FWIW, on a personal note, I think that both of these solution classes >>> are FCFS, they are just different variants of it. The variants have >>> important differences, for sure, but they both follow the FCFS model. >>> After all, they only affect which hosts are to be protected, not how the >>> hosts are protected. >>> >>> IMO, both solution classes are also working for CPS. They can be >>> > discussed > >>> without regarding whether FCFS or CPS or something else is chosen. >>> >>> Given the restrictions set forth by our charter, neither of the above >>> two classes of SAVI solutions can be a silver bullet, of course. Both >>> models have their limitations, as your discussions has shown: >>> >>> - Class A provides a lower level of protection because the addresses of >>> hosts behind a legacy switch are not protected against spoofing. >>> This defeats the purpose of SAVI in deployment scenarios where all >>> hosts are separated from the SAVI device through a legacy switch. An >>> example where this may be the case is DSL networks, where SAVI may >>> be performed on a provider-side device, and all hosts attach to this >>> SAVI device via a legacy switch on the customer side. >>> >>> - Class A requires extra manual configuration of SAVI devices in terms >>> of which binding anchors are to be protected, and which are not. >>> >>> - Class B may, in specific cases, introduce a higher vulnerability to >>> denial of service than class A: In general, a vulnerability to >>> denial of service exists if an attacker (a) finds out about the >>> address of a victim host, and (b) is in a position to trick a SAVI >>> device into creating a fake binding for the victim host's address, >>> using a binding anchor other than the one the victim host would use. >>> This would cause the SAVI device to prevent the victim host from >>> using its own address. >>> >>> A situation where this vulnerability may occur is where a SAVI device >>> does not receive the first packet sent by the victim host, but the >>> attacker does. The SAVI device then does not create a binding for >>> the >>> victim host, potentially enabling the attacker to create a fake >>> binding on behalf of the victim host. The presence of a legacy >>> switch >>> between the SAVI device on one side, and the victim host and the >>> attacker on the other side, increases the chance that this situation >>> occurs for two reasons: First, because the probability for loss is >>> higher for packets that have to traverse a legacy switch to reach the >>> SAVI device. Second, because the legacy switch may deliberately not >>> forward a packet to the SAVI device if the destination is known not >>> to >>> be reachable via the SAVI device. In such a situation, class B would >>> enable the attacker to create a fake binding on behalf of the victim >>> host, whereas class A does not. >>> >>> >>> >> I am kind of confused with the format of the reply, since it is hard to >> distinguish the original text from Christian and Guang's reply, but, i >> understnad that the text below is Guang's reply.... >> > > Sorry for confusing. > >>> Exactly! >>> And I want to give two of my points here: >>> 1 FCFS >>> I think there are at least 3 kinds of FCFS: >>> (1) FCFS to the routing system >>> >>> >> I don't understnad what do you mean by FCFS to the routing system, do >> you mean the case the SAVI device is colocated with a router? >> >> >>> (2) FCFS to the SAVI system >>> (3) FCFS to a SAVI device >>> >>> >> I fail to see the difference between these two... do you mean 2) is the >> case you have multiple SAVI devices and 3) being the case where you have >> only one SAVI device? >> > > (1) means the address is first ever appearing on the current routing system, > including all the network device. > (2) means the address is first ever appearing on one of all the SAVI > devices. > I fail to see how is this relevant. I mean, the savi device can only create binding when the savi device sees the packet. How is it relevant when the address is first ever appearing in the routing system, or any other netowrk device if the device is not savi capable? regards, marcelo >>> Only (1) is reasonable to trigger a new binding. However, in FCFS draft, >>> (3) is taken as (1). This defect of class B is actually due to (3) is >>> > not > >>> equal to (1), >>> especially for indirect connected hosts. If hosts are direct connected >>> > to > >>> SAVI device, >>> (1) can be inferred from (3). This is the reason why I prefer class A >>> > than > >>> class B. The >>> same thing also happens on CPS. >>> >>> And as I mentioned in previous mails, even with a perfect BDP, FCFS is >>> > still > >>> not >>> reasonable to set up legal bindings, because (3) cannot be inferred from >>> (2). However, >>> for CPS, (1) can be inferred from CPS. >>> >>> >>> >> I cannot comment on this since i don't understand the definitions of 1,2 >> and 3 >> >> >>> There is actually no difference between FCFS and CPS on the basic idea: >>> >> who >> >>> uses it first, and who gets it. >>> >>> >> i agree with this >> >> >>> The real difference is, which is real FCFS, and which just looks like >>> "FCFS". >>> >>> >>> >> no, the difference is what is the default action when the device >> receives a data packet for which it doesn't have a binding, to learn or >> to discard >> > > I think the inner difference is which is real FCFS. > > >>> - Class B may potentially requires more memory per SAVI device than >>> class A. SAVI devices need to maintain bindings not only for >>> directly attached hosts, but also for hosts behind legacy switches. >>> >>> I think the memory cost problem is an important problem. I have >>> > discussed > >>> with some switch vendors, >>> and they told me it is very hard for an access device to set up a >>> > filtering > >>> table for potentially thousands of hosts >>> >>> >>> >> I disagree that the memory requirements are different >> both FCFS and CPS learn based on DAD packets (FCFS also learns in the >> case of data packets) >> In general, hosts will issue the DAD and as i understand both CPS and >> FCFS will generate a binding based on the DAD packet, is this correct >> for CPS? >> If so, then i argue that the amount of memory is very similar in both >> cases. I mean, the need to use data packets to create binding is deal >> with those cases where the DAD is lost or not issued after a change in >> the topology, which will not change significantly the amount of memory >> needed >> >> > > Here we just discuss that class B requires more memory than class A, not > CPS and FCFS. > > >> Regards, marcelo >> >> >> >>> Given that both classes of SAVI solutions have strengths and weaknesses >>> relative to each other, we may consider giving the network administrator >>> the possibility to choose. All that would be needed for this is a >>> capability of SAVI devices to en- or disable protection of specific >>> binding anchors. Protection being enabled for all binding anchors would >>> thus represent a SAVI solution of class A, while disabling protection >>> for binding anchors associated with legacy switches would represent a >>> SAVI solution of class B. The important question is what the default >>> should be. We should discuss this question. >>> >>> - Christian >>> >>> >>> >>> >>> >>> > > > > From yaoa02@mails.tsinghua.edu.cn Sun May 31 07:50:34 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BA9B3A6D7E for ; Sun, 31 May 2009 07:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.008 X-Spam-Level: * X-Spam-Status: No, score=1.008 tagged_above=-999 required=5 tests=[AWL=3.607, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id equmkzAnWRn5 for ; Sun, 31 May 2009 07:50:32 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 52C743A6D8A for ; Sun, 31 May 2009 07:50:32 -0700 (PDT) Received: from tu132214.ip.tsinghua.edu.cn ([166.111.132.214] helo=netarchld5f663) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1MAmOP-0000Jt-Q1; Sun, 31 May 2009 22:52:09 +0800 From: "Guang Yao" To: "'marcelo bagnulo braun'" References: <2AE43E7B-7B84-4751-8871-B8A949F52666@ericsson.com> <001201c9e1c6$399cc780$acd65680$@tsinghua.edu.cn> <4A225E1C.1080300@it.uc3m.es> <001e01c9e1f6$e609b4d0$b21d1e70$@tsinghua.edu.cn> <4A228FDD.9060207@it.uc3m.es> In-Reply-To: <4A228FDD.9060207@it.uc3m.es> Date: Sun, 31 May 2009 22:51:56 +0800 Message-ID: <002001c9e1ff$581a79d0$084f6d70$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acnh+ZPTCaoiMRn5TlWBcJUytE3IHwAA9VPQ Content-Language: zh-cn Cc: 'SAVI Mailing List' , 'Christian Vogt' Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 14:50:34 -0000 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: Sunday, May 31, 2009 10:11 PM > To: Guang Yao > Cc: 'Christian Vogt'; 'SAVI Mailing List' > Subject: Re: SAVI Bindings For Hosts Behind Legacy Switches? >=20 > Guang Yao escribi=F3: > > > >> -----Original Message----- > >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > >> Sent: Sunday, May 31, 2009 6:38 PM > >> To: Guang Yao > >> Cc: 'Christian Vogt'; 'SAVI Mailing List' > >> Subject: Re: SAVI Bindings For Hosts Behind Legacy Switches? > >> > >> Guang Yao escribi=F3: > >> > >>> -----Original Message----- > >>> From: Christian Vogt [mailto:christian.vogt@ericsson.com] > >>> Sent: Thursday, May 21, 2009 4:29 AM > >>> To: Marcelo Bagnulo Braun; Guang Yao; SAVI Mailing List > >>> Subject: SAVI Bindings For Hosts Behind Legacy Switches? > >>> > >>> Forked from thread: "About the failure situation mentioned by > Marcelo". > >>> > >>> > >>> Marcelo, Guang, and all - > >>> > >>> Thanks for your discussion on whether SAVI bindings should be = created > >>> only for directly attached hosts, or also for hosts attached via legacy > >>> switches. This discussion was extremely useful. Let me summarize = a > >>> > >> few > >> > >>> conclusions from it. > >>> > >>> You have identified two classes of SAVI solutions: > >>> > >>> - Class A, in which SAVI devices create bindings only for hosts = that are > >>> directly attached. > >>> > >>> - Class B, in which SAVI devices create bindings also for host = that are > >>> attached via one or more legacy switches. > >>> > >>> FWIW, on a personal note, I think that both of these solution = classes > >>> are FCFS, they are just different variants of it. The variants = have > >>> important differences, for sure, but they both follow the FCFS = model. > >>> After all, they only affect which hosts are to be protected, not = how the > >>> hosts are protected. > >>> > >>> IMO, both solution classes are also working for CPS. They can be > >>> > > discussed > > > >>> without regarding whether FCFS or CPS or something else is chosen. > >>> > >>> Given the restrictions set forth by our charter, neither of the = above > >>> two classes of SAVI solutions can be a silver bullet, of course. = Both > >>> models have their limitations, as your discussions has shown: > >>> > >>> - Class A provides a lower level of protection because the = addresses of > >>> hosts behind a legacy switch are not protected against = spoofing. > >>> This defeats the purpose of SAVI in deployment scenarios where = all > >>> hosts are separated from the SAVI device through a legacy = switch. > An > >>> example where this may be the case is DSL networks, where SAVI > may > >>> be performed on a provider-side device, and all hosts attach to this > >>> SAVI device via a legacy switch on the customer side. > >>> > >>> - Class A requires extra manual configuration of SAVI devices in = terms > >>> of which binding anchors are to be protected, and which are = not. > >>> > >>> - Class B may, in specific cases, introduce a higher vulnerability = to > >>> denial of service than class A: In general, a vulnerability to > >>> denial of service exists if an attacker (a) finds out about the > >>> address of a victim host, and (b) is in a position to trick a = SAVI > >>> device into creating a fake binding for the victim host's = address, > >>> using a binding anchor other than the one the victim host would > use. > >>> This would cause the SAVI device to prevent the victim host = from > >>> using its own address. > >>> > >>> A situation where this vulnerability may occur is where a SAVI device > >>> does not receive the first packet sent by the victim host, but = the > >>> attacker does. The SAVI device then does not create a binding = for > >>> the > >>> victim host, potentially enabling the attacker to create a fake > >>> binding on behalf of the victim host. The presence of a legacy > >>> switch > >>> between the SAVI device on one side, and the victim host and = the > >>> attacker on the other side, increases the chance that this situation > >>> occurs for two reasons: First, because the probability for = loss is > >>> higher for packets that have to traverse a legacy switch to = reach the > >>> SAVI device. Second, because the legacy switch may = deliberately > not > >>> forward a packet to the SAVI device if the destination is known = not > >>> to > >>> be reachable via the SAVI device. In such a situation, class B would > >>> enable the attacker to create a fake binding on behalf of the victim > >>> host, whereas class A does not. > >>> > >>> > >>> > >> I am kind of confused with the format of the reply, since it is = hard to > >> distinguish the original text from Christian and Guang's reply, = but, i > >> understnad that the text below is Guang's reply.... > >> > > > > Sorry for confusing. > > > >>> Exactly! > >>> And I want to give two of my points here: > >>> 1 FCFS > >>> I think there are at least 3 kinds of FCFS: > >>> (1) FCFS to the routing system > >>> > >>> > >> I don't understnad what do you mean by FCFS to the routing system, = do > >> you mean the case the SAVI device is colocated with a router? > >> > >> > >>> (2) FCFS to the SAVI system > >>> (3) FCFS to a SAVI device > >>> > >>> > >> I fail to see the difference between these two... do you mean 2) is = the > >> case you have multiple SAVI devices and 3) being the case where you have > >> only one SAVI device? > >> > > > > (1) means the address is first ever appearing on the current routing system, > > including all the network device. > > (2) means the address is first ever appearing on one of all the SAVI > > devices. > > >=20 > I fail to see how is this relevant. I mean, the savi device can only > create binding when the savi device sees the packet. How is it = relevant > when the address is first ever appearing in the routing system, or any > other netowrk device if the device is not savi capable? >=20 > regards, marcelo Sure, only after the packet appears on a savi device, the savi device = can know which address will be bound. But before binding, it must decide whether to bind and which to bind = with. If an address is first ever appearing on all the savi devices, is it reasonable to bind it with the anchor it appears with? I don't think so. A host may be the second to use that address in the routing system, but fortunately, it appears first on the savi device. That's what I mean, "FCFS to the savi system" doesn't necessarily mean = "FCFS to the routing system". Protection should be provide to the entity who uses an address first in = a routing system, but not the entity who first forwards the packet to the = savi system. >=20 >=20 > >>> Only (1) is reasonable to trigger a new binding. However, in FCFS draft, > >>> (3) is taken as (1). This defect of class B is actually due to (3) = is > >>> > > not > > > >>> equal to (1), > >>> especially for indirect connected hosts. If hosts are direct = connected > >>> > > to > > > >>> SAVI device, > >>> (1) can be inferred from (3). This is the reason why I prefer = class A > >>> > > than > > > >>> class B. The > >>> same thing also happens on CPS. > >>> > >>> And as I mentioned in previous mails, even with a perfect BDP, = FCFS is > >>> > > still > > > >>> not > >>> reasonable to set up legal bindings, because (3) cannot be = inferred from > >>> (2). However, > >>> for CPS, (1) can be inferred from CPS. > >>> > >>> > >>> > >> I cannot comment on this since i don't understand the definitions = of 1,2 > >> and 3 > >> > >> > >>> There is actually no difference between FCFS and CPS on the basic idea: > >>> > >> who > >> > >>> uses it first, and who gets it. > >>> > >>> > >> i agree with this > >> > >> > >>> The real difference is, which is real FCFS, and which just looks = like > >>> "FCFS". > >>> > >>> > >>> > >> no, the difference is what is the default action when the device > >> receives a data packet for which it doesn't have a binding, to = learn or > >> to discard > >> > > > > I think the inner difference is which is real FCFS. > > > > > >>> - Class B may potentially requires more memory per SAVI device = than > >>> class A. SAVI devices need to maintain bindings not only for > >>> directly attached hosts, but also for hosts behind legacy = switches. > >>> > >>> I think the memory cost problem is an important problem. I have > >>> > > discussed > > > >>> with some switch vendors, > >>> and they told me it is very hard for an access device to set up a > >>> > > filtering > > > >>> table for potentially thousands of hosts > >>> > >>> > >>> > >> I disagree that the memory requirements are different > >> both FCFS and CPS learn based on DAD packets (FCFS also learns in = the > >> case of data packets) > >> In general, hosts will issue the DAD and as i understand both CPS = and > >> FCFS will generate a binding based on the DAD packet, is this = correct > >> for CPS? > >> If so, then i argue that the amount of memory is very similar in = both > >> cases. I mean, the need to use data packets to create binding is = deal > >> with those cases where the DAD is lost or not issued after a change = in > >> the topology, which will not change significantly the amount of = memory > >> needed > >> > >> > > > > Here we just discuss that class B requires more memory than class A, = not > > CPS and FCFS. > > > > > >> Regards, marcelo > >> > >> > >> > >>> Given that both classes of SAVI solutions have strengths and weaknesses > >>> relative to each other, we may consider giving the network > administrator > >>> the possibility to choose. All that would be needed for this is a > >>> capability of SAVI devices to en- or disable protection of = specific > >>> binding anchors. Protection being enabled for all binding anchors > would > >>> thus represent a SAVI solution of class A, while disabling = protection > >>> for binding anchors associated with legacy switches would = represent a > >>> SAVI solution of class B. The important question is what the = default > >>> should be. We should discuss this question. > >>> > >>> - Christian > >>> > >>> > >>> > >>> > >>> > >>> > > > > > > > > From marcelo@it.uc3m.es Sun May 31 08:01:28 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4DAE3A6CF0 for ; Sun, 31 May 2009 08:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4n4TrpAJUYk for ; Sun, 31 May 2009 08:01:27 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id CF8DD3A6A31 for ; Sun, 31 May 2009 08:01:26 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (37.pool85-53-139.dynamic.orange.es [85.53.139.37]) by smtp03.uc3m.es (Postfix) with ESMTP id 886417F0C18; Sun, 31 May 2009 17:03:07 +0200 (CEST) Message-ID: <4A229C27.6030309@it.uc3m.es> Date: Sun, 31 May 2009 17:03:03 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Guang Yao References: <2AE43E7B-7B84-4751-8871-B8A949F52666@ericsson.com> <001201c9e1c6$399cc780$acd65680$@tsinghua.edu.cn> <4A225E1C.1080300@it.uc3m.es> <001e01c9e1f6$e609b4d0$b21d1e70$@tsinghua.edu.cn> <4A228FDD.9060207@it.uc3m.es> <002001c9e1ff$581a79d0$084f6d70$@tsinghua.edu.cn> In-Reply-To: <002001c9e1ff$581a79d0$084f6d70$@tsinghua.edu.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16676.000 Cc: 'SAVI Mailing List' , 'Christian Vogt' Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 15:01:28 -0000 Guang Yao escribió: > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Sunday, May 31, 2009 10:11 PM >> To: Guang Yao >> Cc: 'Christian Vogt'; 'SAVI Mailing List' >> Subject: Re: SAVI Bindings For Hosts Behind Legacy Switches? >> >> Guang Yao escribió: >> >>>> -----Original Message----- >>>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >>>> Sent: Sunday, May 31, 2009 6:38 PM >>>> To: Guang Yao >>>> Cc: 'Christian Vogt'; 'SAVI Mailing List' >>>> Subject: Re: SAVI Bindings For Hosts Behind Legacy Switches? >>>> >>>> Guang Yao escribió: >>>> >>>> >>>>> -----Original Message----- >>>>> From: Christian Vogt [mailto:christian.vogt@ericsson.com] >>>>> Sent: Thursday, May 21, 2009 4:29 AM >>>>> To: Marcelo Bagnulo Braun; Guang Yao; SAVI Mailing List >>>>> Subject: SAVI Bindings For Hosts Behind Legacy Switches? >>>>> >>>>> Forked from thread: "About the failure situation mentioned by >>>>> >> Marcelo". >> >>>>> Marcelo, Guang, and all - >>>>> >>>>> Thanks for your discussion on whether SAVI bindings should be created >>>>> only for directly attached hosts, or also for hosts attached via >>>>> > legacy > >>>>> switches. This discussion was extremely useful. Let me summarize a >>>>> >>>>> >>>> few >>>> >>>> >>>>> conclusions from it. >>>>> >>>>> You have identified two classes of SAVI solutions: >>>>> >>>>> - Class A, in which SAVI devices create bindings only for hosts that >>>>> > are > >>>>> directly attached. >>>>> >>>>> - Class B, in which SAVI devices create bindings also for host that >>>>> > are > >>>>> attached via one or more legacy switches. >>>>> >>>>> FWIW, on a personal note, I think that both of these solution classes >>>>> are FCFS, they are just different variants of it. The variants have >>>>> important differences, for sure, but they both follow the FCFS model. >>>>> After all, they only affect which hosts are to be protected, not how >>>>> > the > >>>>> hosts are protected. >>>>> >>>>> IMO, both solution classes are also working for CPS. They can be >>>>> >>>>> >>> discussed >>> >>> >>>>> without regarding whether FCFS or CPS or something else is chosen. >>>>> >>>>> Given the restrictions set forth by our charter, neither of the above >>>>> two classes of SAVI solutions can be a silver bullet, of course. Both >>>>> models have their limitations, as your discussions has shown: >>>>> >>>>> - Class A provides a lower level of protection because the addresses >>>>> > of > >>>>> hosts behind a legacy switch are not protected against spoofing. >>>>> This defeats the purpose of SAVI in deployment scenarios where all >>>>> hosts are separated from the SAVI device through a legacy switch. >>>>> >> An >> >>>>> example where this may be the case is DSL networks, where SAVI >>>>> >> may >> >>>>> be performed on a provider-side device, and all hosts attach to >>>>> > this > >>>>> SAVI device via a legacy switch on the customer side. >>>>> >>>>> - Class A requires extra manual configuration of SAVI devices in terms >>>>> of which binding anchors are to be protected, and which are not. >>>>> >>>>> - Class B may, in specific cases, introduce a higher vulnerability to >>>>> denial of service than class A: In general, a vulnerability to >>>>> denial of service exists if an attacker (a) finds out about the >>>>> address of a victim host, and (b) is in a position to trick a SAVI >>>>> device into creating a fake binding for the victim host's address, >>>>> using a binding anchor other than the one the victim host would >>>>> >> use. >> >>>>> This would cause the SAVI device to prevent the victim host from >>>>> using its own address. >>>>> >>>>> A situation where this vulnerability may occur is where a SAVI >>>>> > device > >>>>> does not receive the first packet sent by the victim host, but the >>>>> attacker does. The SAVI device then does not create a binding for >>>>> the >>>>> victim host, potentially enabling the attacker to create a fake >>>>> binding on behalf of the victim host. The presence of a legacy >>>>> switch >>>>> between the SAVI device on one side, and the victim host and the >>>>> attacker on the other side, increases the chance that this >>>>> > situation > >>>>> occurs for two reasons: First, because the probability for loss is >>>>> higher for packets that have to traverse a legacy switch to reach >>>>> > the > >>>>> SAVI device. Second, because the legacy switch may deliberately >>>>> >> not >> >>>>> forward a packet to the SAVI device if the destination is known not >>>>> to >>>>> be reachable via the SAVI device. In such a situation, class B >>>>> > would > >>>>> enable the attacker to create a fake binding on behalf of the >>>>> > victim > >>>>> host, whereas class A does not. >>>>> >>>>> >>>>> >>>>> >>>> I am kind of confused with the format of the reply, since it is hard to >>>> distinguish the original text from Christian and Guang's reply, but, i >>>> understnad that the text below is Guang's reply.... >>>> >>>> >>> Sorry for confusing. >>> >>> >>>>> Exactly! >>>>> And I want to give two of my points here: >>>>> 1 FCFS >>>>> I think there are at least 3 kinds of FCFS: >>>>> (1) FCFS to the routing system >>>>> >>>>> >>>>> >>>> I don't understnad what do you mean by FCFS to the routing system, do >>>> you mean the case the SAVI device is colocated with a router? >>>> >>>> >>>> >>>>> (2) FCFS to the SAVI system >>>>> (3) FCFS to a SAVI device >>>>> >>>>> >>>>> >>>> I fail to see the difference between these two... do you mean 2) is the >>>> case you have multiple SAVI devices and 3) being the case where you >>>> > have > >>>> only one SAVI device? >>>> >>>> >>> (1) means the address is first ever appearing on the current routing >>> > system, > >>> including all the network device. >>> (2) means the address is first ever appearing on one of all the SAVI >>> devices. >>> >>> >> I fail to see how is this relevant. I mean, the savi device can only >> create binding when the savi device sees the packet. How is it relevant >> when the address is first ever appearing in the routing system, or any >> other netowrk device if the device is not savi capable? >> >> regards, marcelo >> > > Sure, only after the packet appears on a savi device, the savi device can > know which address will be bound. > But before binding, it must decide whether to bind and which to bind with. > If an address is first ever appearing on all the savi devices, is it > reasonable to bind it with the anchor it appears with? > I don't think so. A host may be the second to use that address in the > routing system, but fortunately, it appears first on the savi device. > That's what I mean, "FCFS to the savi system" doesn't necessarily mean "FCFS > to the routing system". > Protection should be provide to the entity who uses an address first in a > routing system, but not the entity who first forwards the packet to the savi > system. > > i understnad now I agree that would be the ideal case, indeed. I am not sure we can actually achieve that in the general case though and i am not yet convinced the corner cases are a problem. I mean, we do have a set of border constraints that make the savi solution to have some limitiations so, i am not sure we will be able to achieve the ideal case w.r.t. this Regards, marcelo >> >>>>> Only (1) is reasonable to trigger a new binding. However, in FCFS >>>>> > draft, > >>>>> (3) is taken as (1). This defect of class B is actually due to (3) is >>>>> >>>>> >>> not >>> >>> >>>>> equal to (1), >>>>> especially for indirect connected hosts. If hosts are direct connected >>>>> >>>>> >>> to >>> >>> >>>>> SAVI device, >>>>> (1) can be inferred from (3). This is the reason why I prefer class A >>>>> >>>>> >>> than >>> >>> >>>>> class B. The >>>>> same thing also happens on CPS. >>>>> >>>>> And as I mentioned in previous mails, even with a perfect BDP, FCFS is >>>>> >>>>> >>> still >>> >>> >>>>> not >>>>> reasonable to set up legal bindings, because (3) cannot be inferred >>>>> > from > >>>>> (2). However, >>>>> for CPS, (1) can be inferred from CPS. >>>>> >>>>> >>>>> >>>>> >>>> I cannot comment on this since i don't understand the definitions of >>>> > 1,2 > >>>> and 3 >>>> >>>> >>>> >>>>> There is actually no difference between FCFS and CPS on the basic >>>>> > idea: > >>>> who >>>> >>>> >>>>> uses it first, and who gets it. >>>>> >>>>> >>>>> >>>> i agree with this >>>> >>>> >>>> >>>>> The real difference is, which is real FCFS, and which just looks like >>>>> "FCFS". >>>>> >>>>> >>>>> >>>>> >>>> no, the difference is what is the default action when the device >>>> receives a data packet for which it doesn't have a binding, to learn or >>>> to discard >>>> >>>> >>> I think the inner difference is which is real FCFS. >>> >>> >>> >>>>> - Class B may potentially requires more memory per SAVI device than >>>>> class A. SAVI devices need to maintain bindings not only for >>>>> directly attached hosts, but also for hosts behind legacy switches. >>>>> >>>>> I think the memory cost problem is an important problem. I have >>>>> >>>>> >>> discussed >>> >>> >>>>> with some switch vendors, >>>>> and they told me it is very hard for an access device to set up a >>>>> >>>>> >>> filtering >>> >>> >>>>> table for potentially thousands of hosts >>>>> >>>>> >>>>> >>>>> >>>> I disagree that the memory requirements are different >>>> both FCFS and CPS learn based on DAD packets (FCFS also learns in the >>>> case of data packets) >>>> In general, hosts will issue the DAD and as i understand both CPS and >>>> FCFS will generate a binding based on the DAD packet, is this correct >>>> for CPS? >>>> If so, then i argue that the amount of memory is very similar in both >>>> cases. I mean, the need to use data packets to create binding is deal >>>> with those cases where the DAD is lost or not issued after a change in >>>> the topology, which will not change significantly the amount of memory >>>> needed >>>> >>>> >>>> >>> Here we just discuss that class B requires more memory than class A, not >>> CPS and FCFS. >>> >>> >>> >>>> Regards, marcelo >>>> >>>> >>>> >>>> >>>>> Given that both classes of SAVI solutions have strengths and >>>>> > weaknesses > >>>>> relative to each other, we may consider giving the network >>>>> >> administrator >> >>>>> the possibility to choose. All that would be needed for this is a >>>>> capability of SAVI devices to en- or disable protection of specific >>>>> binding anchors. Protection being enabled for all binding anchors >>>>> >> would >> >>>>> thus represent a SAVI solution of class A, while disabling protection >>>>> for binding anchors associated with legacy switches would represent a >>>>> SAVI solution of class B. The important question is what the default >>>>> should be. We should discuss this question. >>>>> >>>>> - Christian >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > > > From christian.vogt@ericsson.com Sun May 31 15:37:36 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 770DE28C1D5 for ; Sun, 31 May 2009 15:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHGnu0vV8hyy for ; Sun, 31 May 2009 15:37:35 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 9109C28C1C4 for ; Sun, 31 May 2009 15:37:32 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n4VMmebH028094; Sun, 31 May 2009 17:48:41 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 31 May 2009 17:37:26 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 31 May 2009 17:37:25 -0500 Message-Id: <3C7216EA-FE6C-4151-8468-B9F7FFF87D06@ericsson.com> From: Christian Vogt To: Marcelo Bagnulo Braun , Guang Yao In-Reply-To: <4A225E1C.1080300@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 31 May 2009 15:37:24 -0700 References: <2AE43E7B-7B84-4751-8871-B8A949F52666@ericsson.com> <001201c9e1c6$399cc780$acd65680$@tsinghua.edu.cn> <4A225E1C.1080300@it.uc3m.es> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 31 May 2009 22:37:25.0735 (UTC) FILETIME=[5F0EA770:01C9E240] Cc: SAVI Mailing List Subject: Re: [savi] SAVI Bindings For Hosts Behind Legacy Switches? X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 22:37:36 -0000 On May 31, 2009, Marcelo Bagnulo Braun wrote: >> - Class B may potentially requires more memory per SAVI device than >> class A. SAVI devices need to maintain bindings not only for >> directly attached hosts, but also for hosts behind legacy switches. >> >> I think the memory cost problem is an important problem. I have >> discussed with some switch vendors, and they told me it is very >> hard for >> an access device to set up a filtering table for potentially >> thousands >> of hosts > > I disagree that the memory requirements are different both FCFS and > CPS > learn based on DAD packets (FCFS also learns in the case of data > packets) In general, hosts will issue the DAD and as i understand both > CPS and FCFS will generate a binding based on the DAD packet, is this > correct for CPS? If so, then i argue that the amount of memory is very > similar in both cases. I mean, the need to use data packets to create > binding is deal with those cases where the DAD is lost or not issued > after a change in the topology, which will not change significantly > the > amount of memory needed There is one reason why CPS requires less state than FCFS, as the protocols are defined /currently/: CPS calls for SAVI devices to create bindings only for directly attached hosts, not for hosts attached via another switch. This is based on the assumption that the ports of SAVI devices are configured with respect to whether they connect to a host directly, or whether they connect to another switch. For ports connecting to another switch, SAVI protection is disabled. However, the same trick that CPS uses to reduce state can be applied to FCFS. All it requires is adding an option to disable SAVI protection for certain ports. Such an option would be useful anyhow, as Marcelo stated earlier. And I would encourage Marcelo to add this feature to the FCFS specification. Given that the option to disable SAVI protection for certain ports is not really CPS-specific, I had refrained from comparing CPS and FCFS in my original email in this thread. Instead, I wrote the email in terms of a SAVI device's behavior for ports connecting to another switch. Later, the discussion flipped back to comparing CPS and FCFS, but this was not the original intention. - Christian