1. About NADV message lost. The SAVI device is the first access device, so if this message is lost, we can consider the host is offline. 2.Secure level. All the SAVI feature(ND proxy, etc) should be optional, we can define the feature in differ level. The weakest level is no SAVI, than deal with forwarding parcket, than controling parcket (there are more level in controling parcket, ND/ARP, DHCP, etc). 3.Same approach in IPv4. Yes, DAD mandatory in IPv4 is one. We have more approach, for example, ARP proxy, ARP snooping, ARP detection for same source MAC, etc. 4. About RFC5227 This RFC may not be universally implemented. But SAVI group dicuss the device, and the device can implement it first. Otherwise, we can improve it for device in SAVI standard, the same as ND. ----- Original Message ----- From: "MARCELO BAGNULO BRAUN" <marcelo at it.uc3m.es> To: "Lin Tao" <lint at h3c.com> Cc: "Guang Yao" <yaog at netarchlab.tsinghua.edu.cn>; "'SAVIMailing List'" <savi at ietf.org>; "'Christian Vogt'" <christian.vogt at ericsson.com>; "'Frank Xia'" <xiayangsong at huawei.com> Sent: Wednesday, December 31, 2008 9:00 PM Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents Lin, Lin Tao <lint at h3c.com> dijo: > Sorry so late. I think Guang have explained the meaning. > I agree his idea, the control protocol must be snooping How do you suggest to deal with the case the NADV message is lost and the SAVI device does not receives it? > or proxy to protect the network security. as i mentioned already, this is included already in the fcfs draft > And we can > layout different secure level in this way. What do you mena by this? > There is the > same approach in IPv4. how are you planning to do this? IS DAD mandatory in IPv4? Regards, marcelo > > > Happy new year! > > > ----- Original Message ----- > From: "marcelo bagnulo braun" <marcelo at it.uc3m.es> > To: "Lin Tao" <lint at h3c.com> > Cc: "Guang Yao" <yaog at netarchlab.tsinghua.edu.cn>; "'Christian Vogt'" > <christian.vogt at ericsson.com>; "'Frank Xia'" > <xiayangsong at huawei.com>; "'SAVI Mailing List'" <savi at ietf.org> > Sent: Monday, December 29, 2008 3:17 AM > Subject: Re: [savi] Working Group Adoption of Individual SAVI Documents > > >> Lin Tao escribió: >>> Dear Christian, Guang and Marcelo, >>> >>> I agree with Guang that the normal behaviors and good guys >>> MUST be protected, so we should snoop at control packets than >>> datagram packets. >> I fail to see why this is so >> could you expand? >> >> regards, marcelo >> >> >> >>> This is the worthest thing in SAVI. >>> There is two plane in SWITCH: ASIC and CPU, it >>> is easy to implement ACL in ASIC to filter control packets to >>> CPU, and the datagram packets is discarded by default. Otherwise, >>> all datagram packets that havn't right to forward are all >>> delivered to CPU, than it will be forwarded by CPU, this is >>> a bader granularity than snooping control packets. >>> >>> Best regards >>> >>> >>> ----- Original Message ----- >>> From: "Guang Yao" <yaog at netarchlab.tsinghua.edu.cn> >>> To: "'Christian Vogt'" <christian.vogt at ericsson.com>; "'Lin Tao'" >>> <lint at h3c.com> >>> Cc: "'Frank Xia'" <xiayangsong at huawei.com>; "'Marcelo Bagnulo >>> Braun'" <marcelo at it.uc3m.es>; "'SAVI Mailing List'" <savi at ietf.org> >>> Sent: Tuesday, December 23, 2008 8:12 PM >>> Subject: ??: [savi] Working Group Adoption of Individual SAVI Documents >>> >>> >>> Dear Christian and Lin, >>> >>> It's clear that snooping ND cannot achieve better performance and security >>> than snooping data traffic. Actually snooping ND may cost more for it must >>> trace >>> the state of DAD. >>> >>> But IMO, it is not an issue of resource saving, but an issue that what SAVI >>> is intending >>> to protect. If the SAVI device snoops ND to bind address and anchor, it >>> protects >>> good guys who are working according to the standard. But if it snoops data >>> traffic and >>> binds address and anchor using the principle of FCFS, bad >>> behaviors, such as >>> attacks against >>> DAD, are protected. >>> >>> Mr. Fred Baker once gave us a convincing example: when an attacker receives >>> a >>> DAD NS, it immediately sends a packet with source address set to the Target >>> Address in the NS >>> to make the SAVI device set up binding without replying a NA. Then the DAD >>> node, although has finished >>> a successful DAD, cannot use the tentative address for the SAVI device will >>> take its traffic as spoofing traffic. >>> >>> Although it is rather a security problem of ND then the fault of SAVI, the >>> SAVI device is >>> protecting bad doings in the example. >>> >>> I think SAVI should at least protect normal behaviors and good >>> guys, but not >>> protect bad behaviors. >>> >>> I also think SAVI should protect the Target Address in NA message, >>> for it is >>> another kind of source address. >>> >>> Guang >>> -----????----- >>> ???: Christian Vogt [mailto:christian.vogt at ericsson.com] >>> ????: 2008?12?23? 18:36 >>> ???: Lin Tao >>> ??: Frank Xia; Marcelo Bagnulo Braun; SAVI Mailing List; ? ? >>> ??: Re: [savi] Working Group Adoption of Individual SAVI Documents >>> >>> Lin - >>> >>> I agree with you that DoS is an unsolved issue that we have yet to >>> tackle. However, I don't think we can solve the issue, for all address >>> configuration methods, simply by changing which packets we snoop. SLAAC >>> in particular is an address configuration method where an attacker can >>> overload a SAVI device just as easily with control packets (i.e., >>> Neighbor Solicitation packets) as with datagram packets. >>> >>> The only scenario in which snooping control packets instead of datagram >>> packets could mitigate the DoS issue is where addresses are exclusively >>> assigned via DHCP. A SAVI device can then exclusively rely on messages >>> being sent by a server (not directly by the attacker), such that a DoS >>> attack against a SAVI device reduces to the existing threat of a DoS >>> attack against a DHCP server. >>> >>> FWIW: Some SAVI participants were considering a DHCP-only option for >>> SAVI during IETF 73. >>> >>> - Christian >>> >>> >>> >>> On Dec 22, 2008, Lin Tao wrote: >>> >>> >>>> 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. >>>> >>> >>> >>> >>> >> >> -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid _______________________________________________ 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.