[Sorry for replying late. There is something wrong with my mail server and I have to reply using this mail address.] -----邮件原件----- 发件人: marcelo bagnulo braun [mailto:marcelo at it.uc3m.es] 发送时间: 2008年12月30日 22:29 收件人: Guang Yao 抄送: 'Christian Vogt'; 'Lin Tao'; 'Frank Xia'; 'SAVI Mailing List'; 'Jun Bi' 主题: Re: 答复: 答复: 答复: [savi] Working Group Adoption of Individual SAVI Documents [Meta comment: Guang, please indent or mark somehow your text in order to distinguish from my previous comments, cause it is becoming increasingly hard to follow this thread) below... Guang Yao escribió: > > I think we are having two somehow orthogonal issues here: > - On one hand we are discussing what is the type of address ownership > proof that we want to have. I think that irrespectively whether you use > control messages or data packets, you can use the FCFS principle as > address ownership. I mean, in both cases, the first node that sends a > packet with a given address claims the address ownership. The first > packet can be a data packet or a NS or NADV packet, but it is FCFS > principle all the way. I don't thing you are propising a different > address ownership proof afaict > > For the SAVI device, it is correct that address ownership can be assigned > according > to the principle of FCFS, no matter data traffic or control traffic is > chosen. It is not the fault > of the principle of FCFS. But it is correct from the view of the SAVI > device. > > Please consider the hosts in the same network. For currently we cannot > modify the > host, they have none sense of the existing of a SAVI device. They are > working assuming > all the nodes are working according to the standard and > the switch or router would never drop its traffic if it obeys the rules, > unless congestion. > > mmm, what about ingress filtering? If a node has multiple addresses with different prefixes, packets can get dropped cause ingress filtering (this is fairly common case in multihomed scenarios for instance) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~Guang, 1.4: ~As I know, ingress filtering has loose and feasible mode to handle multihoming [RFC 3704]. ~Anyway, false positive is a very bad feature for a mechanism. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The point that i am trying to make is that if we intend to create a SAVI mechanism that is transparent to the edn nodes, we will need to make some assumptions and these assumptions are likely to not hold for every possible scenario, and when they don't hold, some things are likely to fail. Of course we must minimize the situations where that happens, i agree ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~Guang, 1.4: ~I'm not sure it's a problem of assumption. ~Maybe you can make your assumptions clear. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > However, we put a superpower manager into the network without notifying the > hosts. > And the manager designed two new rules: > 1a, if you use an address in the data traffic firstly, you get > the ownership; > 2a, if you use an address given to another, your packet will be dropped. > Unfortunately, these rules are not known by any host. The host runs > according to these two rules: > 1b, If a tentative address is not replied by another, I can use it; > 2b, My packet will be delivered if I use my address. > Well, DAD is not guaranteed to work in all the cases, so it may be possible that there is a collision even with DAD being successful. In that case, you enter in very strange failure modes. So, you can use that address indeed but there is no guarantees it will your own and your own only ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~Guang, 1.4: ~Yes, I agree it's not perfect. However, we can compare the failure possibility of DAD snooping ~and FCFS(false positive only): ~1. FCFS fails if (1.1) normal DAD is being attacked; ~ (1.2) DAD NA is missing; ~ (1.3)Collision you mentioned ~2. DAD snooping fails when (2.1) DAD NA is missing ~ (2.2) Collision you mentioned ~ ~I think it is quite clear (1.2),(1.3) ,(2.1),(2.2) happen with very little possibility, but (1.1) ~can happen with great possibility. ~And (1.2),(1.3) ,(2.1),(2.2) is the failure of DAD mechanism, not the fault of SAVI. (1.1) is ~the fault of SAVI. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > The first rules of SAVI device and host are very different. > 1 the owner of a tentative traffic what do you mean by the owner of tentative traffic? > is not enforced to reply a DAD NA. So 1a > is not the sufficient condition of 1b. > 2 any host can reply the DAD NS. So 1a is not the necessary condition of 1b. > And there may be more examples to prove that 1a is not a necessary and > sufficient condition of 1b. > So 1a and 1b are separate conditions. > If we want to use 1a, we must assure that all hosts run according to 1a. Or > else, something goes bad. > But actually, all normal hosts run according to 1b. > > In short, FCFS is OK, but it will be bad if the FCFS principle is not known > clearly by host. If we don't want to modify > host, we must make the SAVI device transparent and import no new rule. > > I am not sure what is the problem here. We can use the FCFS principle both with data traffic and control packets as i suggested in the previous email The SAVI device can create state both based on the ND traffic and the data traffic, there is no problem with that. I guess it is up to the WG to decide if we think that the additional complexity required for the SAVI device to also understand ND messages is worth it. I am not sure we are disagreeing here... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~Guang, 1.4: ~I think "both" would not solve the problem. ~ND only is the reasonable solution. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > - On the other hand, there is the disucssion if we do this based on data > packets or using control packets, in particular NSol and NAdv). I don't > have a problem in doing it in both. I don't think you can do it only > with control packets. In particular, consider the case of optimistic > DAD. In that case, the node starts using the address even wihtout having > the DAD completed. Moreover, DAD is a one time operation that is > succesfull when there is no reply. So if we have a transite failure > duringt he DAD period, and packets are not delivered to the SAVI device > during that time, SAVI would fail. I do agree that it would be > interesting to evaluate if looking into ND messages could help to > prevent some scenarion as the one you mention above. But i think that a > solution that solely relies in ND messages would be not very robust > (i.e. it would fail if the DAD packet is lost for instance) > > Optimistic DAD would not trouble for a DAD NS has been sent and the SAVI > device > knows exactly whether there is a collision. If there is a collision, the > source address > without finishing DAD will be dropped. There is no problem. And if no > collision, there > is no problem to forward these packets. > > > I agree that SAVI will fail if the DAD NA message is not delivered to the > tentative node. > So I think maybe the SAVI device should guarantee the procedure will not be > disrupted, > e.g., it can play as a ND proxy. but how do you guarantee that the ND message was delviered to the SAVI device in the first place? (And how do you guarantee that the ND message is delviered to all the nodes?) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~Guang, 1.4: ~SAVI device is always the device directly connected with the host(first hop switch or router). ~So it is not hard to guarantee the first point. ~And I don't think we have to guarantee ND message is delivered to all nodes. It is enforced ~by standard and it only fails with little possibility. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I mean, the problem with DAD robustness is that the topology can change after the DAD procedure was done. So, suppose you have two lans that are working and that at some point in time they are merged into one lan. In that case, the nodes on each lan have already executed the DAD procedure and they are not even aware of the merging, so they will not repeat the DAD procedure. (this can happne when there is a failure and a network gets partitioned and then repaired for example) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~Guang, 1.4: ~A great example. But ~(1) If the nodes are not aware of merging, they must not leave their switch (or else it is the same ~as a node is attached to the LAN for the first time.) and the switch must be used in the new LAN. If ~the binding is performed on the switch, there is no trouble. If the binding is performed on the router, ~also no trouble. The binding information is always not removed and it can be used again, without requirement ~of another DAD. ~(2) It is really an infrequent situation. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ So DAD is inherently non robust cause the procedure is successful when there is NO reply, but you cannot know if there is no reply cause there is no address collision or because the packet was lost. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~Guang, 1.4: ~(1) The SAVI device knows what the situation is clearly, because it has recorded all addresses. ~(2) And my point is: We choose DAD snooping for host relies on DAD exclusively, rather than ~DAD is robust. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > But I think relying on data traffic has the > same problem, right? > > not really, cause there are many data packets. So, if one data packet gets lost, there will be more to come, so sooner or later one of them will make it (or we have bigger problems) The problem with DAD is that we send only one packet and if it is lost we are out of luck. BEsides, we could send several packets, but this would imply longer delay, whcih is also bad. Data pakcet otoh, there are plenty of them, so the problem is handled better ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~Guang, 1.4: ~Well, I wonder will DAD message be dropped at the first link? I remember link layer protocol ~has acknowledgement and retransmission policy. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> And I mentioned SAVI must control the NA messages, for the Target Address >> > in > >> the NA message is another kind of source address. If the SAVI device has >> > set > >> up >> a binding table, it can filter spoofed NA with ease. >> >> It may be argued that in any situation, a node can avoid replying to NS >> message even the >> Target Address has been assigned to it, and the tentative node will be >> assigned duplicated and "spoofing" address. >> But still it is very different because the probability for two node to >> generate same address is little and the possible damage >> Is trivial. >> But if an attacker designedly attacks against the tentative address, the >> consequence is very bad. Unfortunately, FCFS >> using data traffic makes this situation possible. >> >> IMO, binding address using data traffic is wrong because data traffic is >> > not > >> defined to have the >> function of assigning address to node. It is the necessary condition but >> > not > >> sufficient condition. >> >> >> >> > but the problem is that there is no sufficient condition for knowing > that a node has configured an address. I mean, DAD messages can be lost > and they are only sent once in a nion reliable fashion. In addition, > nodes do optimistic DAD and start using the address without waiting for > the DAD to be completed. > > So, if you want to design a robust mechanism you need to deal with all > that, and using data packets seem the ultimate line > > Yes, I want to design a robust mechanism. But I don’t think we have to use > data traffic. > I think the mechanism can be like this: > 1 It must ensure the security and completeness of DAD. > how do you think you can do that? As i said, imho DAD is inherently non robust > 1.1 Address can be bound only after a DAD NS and there is no > collision in local binding table. > as i said several times, i thin it may be ok to use ND messages to populate the SAVI DB, but i don't think we should rely solely on ND. I think we need to use data packets as well, in case DAD packets are missing for soem reason BTW, i also think we should use dhcp messages if we can I think we need to understnad what do we gain by adding this complexity (clearly relying solely on dat packets is simpler, but relying on signaling packets as well may prevent som attacks, but we need to understadn that better imho) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~Guang, 1.4: ~OK, I will make clear WHAT we lose if we use data packet solely. ~(1) Normal behavior hosts will face additional vulnerability for their legally got addresses ~can be regarded as spoofing by SAVI device. Attack against Target Address in DAD NS message ~is connived and protected by SAVI device. ~(2)Evil behavior hosts benefit from easily flooding addresses. They easily take control of ~an amount of addresses in an address-critical network and make other hosts hard to find a ~useable address. Moreover, such attack is also protected by SAVI device. However, DAD snooping ~can at least reduce the speed of address occupation. ~(3)For any data traffic may trigger binding, the cost of processing a single packet is heavy. ~Any packet with new address will trigger a binding and attacker can design a rather easy attack ~against SAVI device. ~ FCFS flow: Data packet----(source in binding table)----->forward ----(source not in binding table)----->check whether to bind or not--------(address used by another)-->drop -------(first use)->bind and forward Signal packet (I'm not clear) DAD Snooping flow: Data packet---(source in binding table)----->forward ---(source not in binding table)----->drop Signal Packet--------(address used by another)-->drop -------(first use)->bind and forward For any packet, DAD snooping has only a check process. But FCFS may have two checks. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~Guang, 1.4: ~And if use signal packets and data packets together, (2) and (3) will still stand. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 1.2 If there is a collision in local binding, and a DAD NA is > replied from the address owner, it must > ensure the NA will be delivered to the tentative node. > sure, this is basic DAD behaviour, nothing new here, right? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~Guang, 1.4: ~Yes. If every NA is delivered to the tentative node, the SAVI device doesn't have to do anything here. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 1.3 If the address owner doesn't reply, it may either: 1, delete > former binding and set up new binding; > or 2 Send a NA to the tentative node instead of the address > owner. > sure, this is done already in the FCFS draft, > 1.4 Any NA with spoofed Target Address must be dropped. > 2 Data traffic is either dropped or forwarded according to binding, without > triggering new binding entry. > > here, i disagree as i said, i think we should also use data traffic as well > I think the security and completeness of DAD is necessary even using data > traffic to bind address. > how do you plan to achieve that? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~Guang, 1.4: ~The security problem of DAD is easy to handle since the SAVI device has recorded all the addresses ~a node owns. So it is easy to filter spoofing DAD NA. ~The completeness is harder. But the SAVI device can run as a ND proxy as mention above. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~Guang, 1.4: ~Regards, Guang ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ regards, marcelo > If this condition is not guaranteed, there will be varies of attacks and > collisions. > > (In order to deal with the attack you mention, the SAVI device can sniff > DAD packets and identify the suggested attacks if it first sees a DAD > packet and then a data packet with the same address and no DAD reply to > the original request... of course this makes the logic more comlex) > > Regards, marcelo > > > >>> 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. >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> > > > > >
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.