yaog escribió: > -----邮件原件----- > 发件人: marcelo bagnulo braun [mailto:marcelo at it.uc3m.es] > 发送时间: 2009年1月22日 18:34 > 收件人: Christian Vogt > 抄送: SAVI Mailing List; Guang Yao > 主题: Re: Binding establishment based on data or control packets? > > Christian Vogt escribió: > >> Marcelo - >> >> In your email below, you identified several situation in which a SAVI >> device may erroneously discard packets if binding establishment was >> based on control packets only. This is correct if you assume that the >> SAVI device does not react to data packets. OTOH, the SAVI device may >> initiate the necessary control packet exchange upon receiving a data >> packet. This is what I was assuming to be the case, and what you were >> assuming not to be the case, I guess. Hence the misunderstanding. I >> think we are on the same page. >> >> Having said this, I like the summary of possible solution approaches >> that you have suggested earlier: When a SAVI device receives a data >> packet for which source address it does not have a binding, does it... >> >> (1) discard the packet >> (2) create a binding for the packet's source address directly >> (3) initiate a control packet exchange (such as NUD) to verify the >> packet's source address before creating a binding >> >> I agree with you that option (3) does not have a directly apparent >> advantage. The only /potential/ advantage that I can think of is that >> the control packet exchanges initiated in option (3) might be re-usable >> as a protocol for inter-SAVI-device coordination. However, this >> requires more analysis. >> >> > > right > I have been thinking about this > Triggering an NSOL upon the reception of a data packet for which there > is no binding in the SAVI device could have two potential advantages: > - first, that can be used to synchronize multiple SAVI devices. this is > indeed a benefit > - second that could allow a victim to know if an attacker is trying to > set up a savi state for the victim's address. Now this seems like an > advanatage, but after some thought, i don't think it is. > > Let's suppose that the savi device sends a RSOL packet upon the > reception of a data packet with an unknown source address. > Suppose the SAVI device receives two replies. What can the SAVI device > do with this? > ~Comment Start~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~Guang: > Actually, I have a method to distinguish spoofing and a node with two > interfaces to the same LAN, which both can cause two replies. > The NA packet has such format: > [source address][dest address][target address] > If two replies are got, then we should get two source address S1, S2. > Generally S1,S2 are link local addresses. This point depends on the source > address the SAVI device chooses to send NS. > Then we can ask the attempt node if it knows S2(suppose it sends packet with > S1). > If it knows, they are the same nodes. > If it doesn’t know, it is spoofing or incorrect configuration. > More details can be discussed. I have some ideas to make this procedure more > secure. > but this requires changes in the host, right? i think host changes are ut of scope > ~ Comment End~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Actually what happens when we design SAVI such that it sends RSOL > packets, is that the RSOL packet acts as a synchronization point, that > can be used by attacker to claim the address ownership and confuse the > SAVI device. In other words, the whole point of a FCFS appraoch, is that > requests arrive in the natural. If we introduce the RSOL > synchronization, the order is broken and we can hardly tell who is the > first one to request. > > ~Comment Start~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~Guang: > I don't think the SAVI device should allow spoofing NA. > Maybe you are considering the partial deployment, and there can be spoofing > from local nodes. This is a problem. If we specify that the mechanism should > work when partially deployed, many things should be re-considered. > what do you mean by partially deployed? > I don't quite catch this sentence: > " In other words, the whole point of a FCFS appraoch, is that > requests arrive in the natural. If we introduce the RSOL > synchronization, the order is broken and we can hardly tell who is the > first one to request." > The whole point in FCFS is that the first one that claims an address has it. Now, an attacker could claim all the addresses and if it does so, we have a problem (that is why i am more and more convinced that FCFS SAVI is not good enough for IPv4). In IPv6, the attacker cannot claim all the addresses cause there are simply too many addresses. So, an attacker needs to choose which addresses have "value". One of the things that gives value to an address is that this particular address is configured in a host. The problem that the attacker has is that in order to launch the attack it needs to know which address to attack. One way of knowing that is looking into DAD. That is the attack you described a while ago. The attacker learns what address has a value by looking into DAD and then creates a SAVI binding for that address. Now, we have closed that vulnerability by using the DAD to create the SAVI binding. Now, if we allow the SAVI device to send a NSOL for an address, this acts as a call for arms for the attacker. It bassically tells the attacker "this si the right moment to try to get over this address", and the savi device has no way to defend itself, cause it cannot know if the NADV comes from an attacker or not. Makes sense? > ~ Comment End~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > So, i don't think SAVI should send a RSOL upon the reception of a data > packet > > BTW this has implications for the inter savi protocol, since we > shouldn't use any broadcasted message (at least in the clear) cause it > would have the same effect > > ~Comment Start~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~Guang: > What I want to emphasize is, DAD packet loss is of little possibility. > Even the solution brings some false negative, it is still acceptable. > not really in a wireless network, i don't think the possibility of packets not being delivered is so small in addition, you have to deal with the case of gargabe collection, as i have described in the previous email regards, marcelo > ~ Comment End~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Regards, marcelo > > > > >> - Christian >> >> PS: Sorry for the delay in responding. I relocated to the U.S. >> recently, and this has been consuming part of my time. >> >> >> >> >> >>> -----Original Message----- >>> From: MARCELO BAGNULO BRAUN [mailto:marcelo at it.uc3m.es] >>> Sent: Wednesday, January 07, 2009 7:29 PM >>> To: Christian Vogt >>> Cc: SAVI Mailing List; Guang Yao >>> Subject: Re: Binding establishment based on data or control packets? >>> >>> Hi Christian, >>> >>> thanks for the summary >>> >>> some comments below... >>> >>> Christian Vogt <christian.vogt at ericsson.com> dijo: >>> >>> >>> >>> >>>> More specifically, the reason for the aforementioned attack is the >>>> existence of a shortcut for binding establishment, which is >>>> non-legitimate, but which is not prevented either. To prevent the >>>> attack, the shortcut must be eliminated. And this means >>>> >>>> >>> that binding >>> >>> >>>> establishment should be based on the first packet independent of >>>> whether this is a data packet or a control packet. >>>> >>>> >>> Right, i concur with this, the savi state must be created >>> with the firs packet, either data or control packet (dhcp, ND) >>> >>> >>> >>>> The residual question therefore is whether or not data >>>> >>>> >>> packets should >>> >>> >>>> be used for binding establishment in addition to control packets. >>>> There are pros and cons for either approach: >>>> >>>> - The advantage of using data packets is that statically configured >>>> addresses become straightforward to support. Hosts with >>>> >>>> >>> statically >>> >>> >>>> configured addresses cannot be expected to engage in any >>>> >>>> >>> exchange of >>> >>> >>>> control packets, so a simple method to establish a binding in this >>>> case is based on the first data packet. >>>> >>>> >>>> >>> Actually, i think there are more reasons for using data packets >>> >>> The main reason is that DAD is not reliable. The ND packet >>> can be lost and not make it to the SAVI device (e.g. error in >>> the packet for >>> instance) >>> >>> Let's consider the following situation: >>> Suppose that the SAVI device receives a data packet for which >>> source address it doens't have a binding, what does the savi >>> device does_? >>> does it discards the packet? It seems an overkill to me, >>> since we are not sure what happned. In the data based >>> approach, we create the state. >>> Using only control packet introduces this error mode. >>> >>> >>> >>>> - The advantage of /not/ using data packets is that it becomes less >>>> likely for hosts and SAVI devices to lose sync regarding a host's >>>> right to use an address. A host and its connected SAVI >>>> >>>> >>> device then >>> >>> >>>> always determine such right based on the same control >>>> >>>> >>> packets, so in >>> >>> >>>> the absence of control packet loss on the link segment between the >>>> host and the SAVI device, it is impossible for the host >>>> >>>> >>> and the SAVI >>> >>> >>>> device to have different understanding regarding the >>>> >>>> >>> host's right to >>> >>> >>>> use an address. >>>> >>>> >>>> >>> I don't understand this. >>> Suppose that a host configures the address performs DAD and >>> then goes quit for a really long time. At some point the SAVI >>> device will discard the state for that address. The node then >>> sends a data packet, what happnes? In this case, they are out >>> of sync and the straight forward way to deal with this is to >>> react upon the reception of data packets. >>> >>> >>> >>>> However, neither of these is a strong argument for or >>>> >>>> >>> against the use >>> >>> >>>> of data packets for binding establishment. >>>> >>>> >>> IMHO there is strong case for using data packets, as described above >>> >>> >>> >>> >>>> Statically configured addresses >>>> could also be supported if bindings were established based on only >>>> control packets: A SAVI device could, e.g., initiate a Duplicate >>>> Address Detection procedure on behalf of a host when the host sends >>>> the first data packet from a statically configured address. >>>> >>>> >>> Loss of >>> >>> >>>> synchronization between hosts and SAVI devices could, e.g., also be >>>> resolved with the Neighbor Unreachability Detection >>>> >>>> >>> procedure, such as >>> >>> >>>> proposed in draft-bagnulo-savi-fcfs. >>>> >>>> >>>> >>> Right, actually this is what i was thinking as inter switch >>> protocol to spread the state crated using data packets >>> >>> >>> >>>> I think that, in order to move forward and decide whether or not to >>>> use data packets for binding establishment, we should also consider >>>> the affects on SAVI solution components other than the >>>> >>>> >>> initial binding >>> >>> >>>> establishment. One such component is inter-switch mobility: Would >>>> the re-establishment of the binding in the new switch become easier >>>> based on data packets or control packets? >>>> >>>> >>> Does the node needs to perform DAD when the host moves from >>> one swithc to another? >>> >>> How about the removal of the binding >>> >>> >>>> in the old switch? Another component is SeND support (in the >>>> SeND-based SAVI variant): If binding establishment is exclusively >>>> based on control packets, the use of SeND automatically >>>> >>>> >>> protects binding establishment. >>> >>> >>>> This is not the case if data packets are used to establish bindings >>>> because SeND does not protect the source address in data packets. >>>> >>>> >>> The SEND based savi already performs a ND query to verify >>> address ownership. i.e. upon the reception of a data packet >>> it forces the sender to generate a control packet, which is >>> ok for send imho >>> >>> Regards, marcelo >>> >>> >>> SeND >>> >>> >>>> can then only protect the Neighbor Unreachability Detection >>>> >>>> >>> procedure, >>> >>> >>>> which is used for garbage collection in draft-bagnulo-savi-fcfs. >>>> >>>> What does the working group think about this? Please comment. >>>> >>>> One final, important note: Of course, the FCFS principle, the core >>>> idea of draft-bagnulo-savi-fcfs, is orthogonal to whether >>>> >>>> >>> or not data >>> >>> >>>> packets are used for binding establishment. And based on >>>> >>>> >>> the feedback >>> >>> >>>> we got at the SAVI meeting in Minneapolis and so far on >>>> >>>> >>> this mailing >>> >>> >>>> list, the FCFS principle is by many considered the way to go. >>>> >>>> - Christian >>>> >>>> >>>> >>>> >>>> >>> -- >>> ---- >>> 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.