Hello, Christian, Marcelo and Frank: I agree with Frank's view. Because the forwarding packet is observed in FCFS draft, so the forwarding process is disrupted, and the device is vulnerable, e.g. savi cache table exhausted, the cpu of switch busy, etc. In my opinion, observing the Control Protocol, e.g. DHCP or ND etc, is easy to implement in switch for these protocol have special characteristic that can be filtered in switch port while the forwarding packet is blocked. ----- Original Message ----- From: "Christian Vogt" <christian.vogt at ericsson.com> To: "Marcelo Bagnulo Braun" <marcelo at it.uc3m.es>; "Frank Xia" <xiayangsong at huawei.com> Cc: "SAVI Mailing List" <savi at ietf.org> Sent: Saturday, December 20, 2008 7:28 PM Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents > Marcelo and Frank - > >>> It seems to be hard to deal with the following scenarios: 1)A host is >>> authorized to use a static address, while the host does not >>> connect the >>> network >> >> right, we need to think how to deal with this case one obvious >> option is >> that since the address is manually configured in the host, it can also >> be manually included in the SAVI cache, so it knows that has been >> manually assigned > > Right. An alternative, more automated solution might be to have the > switch perform proxy DAD when a new address is used on a given port. > This would enable the switch to determine whether the new address is > pre-configured and hence already in use, because the pre-configured host > would respond to the switch's Neighbor Solicitation during the proxy DAD > procedure. > > FCFS already uses proxy DAD -- in the Neighbor Unreachability Detection > variant -- to prevent attackers from hijacking an address by faking > link-layer movements. > > An obvious optimization to avoid unnecessary proxy DAD is for the switch > to listen for non-proxy DAD, and to skip proxy DAD if non-proxy DAD was > performed for the same address/port combination. > > - Christian > > > _______________________________________________ > savi mailing list > savi at ietf.org > https://www.ietf.org/mailman/listinfo/savi >
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.