Lin Tao <lint at h3c.com> dijo:
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.
First, i am not sure we want to impose such restriction. this is one possible configuration, but depending what do you want to enforce, it may be ok to have the SAVI function in a higher part of the topology (for instance, if you have a switch topology Second, if the host is connected to a hub, for instance, and the hub is then connected to a switch where the SAVI function is performed, then from the host perspective, the DAD procedure would have been successfull but the sav device will not be aware of the NADV packet. IF the failure is restored after that, then the SAVI will filter the data packets Bottom line is, what do you do when the savi device receives a data packet contianing a source address that is not present in the savi db? I can see 3 options here: 1- one is to filter it. I don't think this is acceptable 2- the other one is to create a new savi db entry with the information of the data packet 3- the third option is to perfrom some check, like the NUD procedure with the information contained in the packet. I don 't feel this is necesary, since i fail to see what additional information would this new check would provide Do you think there are more options that this? which option do you think is reasonable and why?
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).
I fail to see why do you think that a control packet packet provides a higher security level than the data packets BEsides as i mention already, i don't see using control packets and data packets as mutually exclusive, but as complementing each other. The question here is about a tradeoff between simplicity and capabilities.
3.Same approach in IPv4. Yes, DAD mandatory in IPv4 is one.
I don't understand what you mean here...
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.
I don't understand what you mean here We can certainly require new capabilities in the SAVI device, but to rely in IPv4 DAD, the hosts need to implement it In order to define a mechanism that is suscetible of wide deployment we need to rely on features that are actually widely deployed in the hosts and i am not sure rfc5227 is one of them Regards, marcelo
----- 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 snoopingHow 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 draftAnd 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, marceloHappy 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 DocumentsLin 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, marceloThis 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
-- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.