Subject: Re: [6lowpan] ND Short Address Collisions

From: Robert Cragie <[email-masked]>
Date: Tue, 14 Sep 2010 19:18:45 +0100

Hi Erik,

I have gone through your responses carefully. My conclusion is that the 
"errors-to" (or just sending to the EUI-64 in the returning ARO) would 
work but is not as clean as carrying them in the ARO. I would like to 
work through the messaging in more detail as I think some of the MAC 
address/IPv6 address combinations and the special case for errored 
status need to be worked through.

So, if the general consensus ends up being that sending to the EUI-64 in 
the case of an error is the right way forward, I will accept that but I 
would still like due consideration given to the alternative approach 
being put forward by Colin O'Flynn, Mads, Dario and myself.

Other comments inline, bracketed by <RCC3></RCC3>

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>

On 09/09/2010 3:54 AM, Erik Nordmark wrote:
> On 08/31/10 02:10 AM, Robert Cragie wrote:
>
>>>> Would there be support for putting in 6lowpan-ND that you must send 
>>>> from
>>>> an address based on the EUI-64 instead of anticipated 16-bit 
>>>> address? I
>>>> think it is more consistent with what is already in 6lowpan-ND. 
>>>> Consider
>>>> the following:
>>>
>>> What you are proposing is very different than how RFC 4861 and
>>> 6lowpan-nd works for NS and NA.
>> <RCC>NS and NA behave very differently for 6lowpan ND than RFC 4861 ND
>> with regard to address registration. I never really understood the
>> necessity to use NS for address registration; personally I preferred the
>> earlier NR/NC approach. NS/NA doesn't align with what's in RFC 4861
>> anyway. Whilst there isn't an equivalent of address registration, DAD
>> seems to be the closest function and this uses unspecified address as
>> the source address.</RCC>
>
> If you'd like we can sit down and go over this in person at the next 
> IETF, or talk on the phone before then.
>
> We don't currently have an address registration mechanism in an IETF 
> RFC. The closest there is would be the ISO ES-IS protocol, but that is 
> rather chatty (fixed period multicast packets sent by every host).
>
> The DAD messages in 4861 are not a good fit either. Not only are they 
> multicast, and any response is multicast, but also there is no "ack" 
> message resulting in unreliable behavior if the medium has unknown 
> reliability. Thus 4861 DAD is fine for checking conflicting 64 bit 
> IIDs on reasonably reliable media, but when the probability of 
> collisions goes up and/or the packet loss probability goes up, then 
> such an approach isn't appropriate.
<RCC3>I agree with what you say</RCC3>
>
>>> Currently NS and NA make a statement about the source address when
>>> they include a SLLAO. But with your approach it is sometimes a
>>> statement about the source address, and sometimes a statement about
>>> the ARO registered address.
>> <RCC>Quite the contrary. The way it is written now the SLLAO makes a
>> statement about the registration address (which is also the unproven and
>> possibly duplicate source address) in the NS. In the proposal, the SLLAO
>> would always be consistent with the source address and not refer the ARO
>> registered address at all (if I understand the proposal 
>> correctly).</RCC>
>
> There is no registered address field in the NS message with an ARO 
> sent by a host, thus in that case the SLLAO is about the IPv6 source 
> address of the NS.
<RCC3>That's the point I am making - the SLLAO pertains to the (to be) 
*registered* address by virtue of using 16-bit autoconfigured 
address.</RCC3>
> And the special NS messages sent from 6LR to 6LBR as part of multihop 
> DAD has an ARO which includes the registered address field, but no 
> SLLAO (section 8.2.3.).
>
>>> I think this will lead to confusion, and result in corner cases that
>>> are hard to handle.
>> <RCC>There is confusion currently amongst multiple vendors trying to do
>> interoperability testing with real products. I thought the IETF way was
>> to a) put out a specification, b) try it and c) change it if it doesn't
>> work. The process for (c) doesn't seem to be happening well for some
>> reason.</RCC>
>
> My understanding of the IETF process is that your item c) is supposed 
> to read "improve the specification" instead of "change the 
> specification" ;-)
<RCC3>I would hope any change is for the better ;-)</RCC3>
>
>>> And in fact you don't need any of that. All you seem to need to handle
>>> your concerns is an "errors-to" MAC address, which the host might set
>>> to its EUI-64 MAC address. (It could also be an "errors-to" IPv6
>>> address like the LP64.) We can easily add such a field to the ARO.
>> <RCC>I disagree. Strictly speaking you should not be using that 16-bit
>> MAC address at all as a source or destination until you are convinced
>> that it is unique within the PAN. MAC association in 802.15.4 is built
>> around that principle. Perhaps we should be using that mechanism for
>> registration, although that would complicate matters by introducing
>> another management entity function when there seems to be a perfectly
>> acceptable alternative. On the other hand, if it were done using MAC
>> association, in 6lowpan (or indeed any network where the IP address is
>> autoconfigured from its IID (hence MAC address), the need for
>> independent address registration of IP addresses would probably go
>> away.</RCC>
>
> I think I asked these question earlier, and saw no response.
> What part of 802.15.4 breaks if we carry a 16-bit MAC address as an 
> SLLAO option in ND before it has been verified to be unique?
<RCC3>None as such as SLLAO is just payload carrying a number at this 
point.</RCC3>
> What part of 802.15.4 breaks if we use a 16-bit MAC address as a MAC 
> source address before it has been verified to be unique?
<RCC3>
Whilst it is difficult to specify in 802.15.4 (because it stops at the 
MAC layer), short address use is based on allocation by a coordinator 
(i.e. parent node). The assumption in this case is that the coordinator 
is sufficiently able to pick an address which at least is not in use 
with any other neighbors already associated through it. When it comes to 
more complex topologies, a higher layer management entity needs to be 
responsible for ensuring uniqueness. So whilst there is no explicit text 
regarding uniqueness, it is implied through the association procedure.

In practice in the ND case, it may not be an issue. The EUI-64 can be 
used to distinguish the originator therefore it is possible to 
distinguish the origin of the NS using a duplicate MAC and IPv6 address. 
Sending a response - again, the nodes can distinguish based on the 
EUI-64. But this ends up as one packet potentially "bicast" to two 
nodes, which will both respond with a MAC ack., according to 802.15.4 
rules. These MAC acks. could collide and interfere for a number of 
reasons (distance, vendor) as they are not sent using CSMA/CA, thus they 
may not be seen by the transmitter. In the worst (admittedly unlikely 
but not impossible) case, the relationship between the two nodes could 
conspire to never produce a valid MAC ack.

So, whilst it may work, it seems to be the wrong basis for a 
specification. You could, as you suggest, send an errored NA to the 
EUI-64 (using 16-bit based IPv6 address still; also I am not sure you 
need an extra field) but that tends to go against most of the rules that 
have been written so far wrt. autoconfiguration of IPv6 addresses and 
MAC addresses as far as I can see.
</RCC3>
>
> Note that in 6lowpan-nd-12 we only do the first of the two, and I 
> can't possibly see how the MAC layer can break as a result.
<RCC3>Not so - if the IPv6 address is 16-bit based and fully elided, 
then the MAC header will carry a 16-bit short address as defined in 
6lowpan-hc.</RCC3>
>
>>> But having some packets, depending on option content, redefine the
>>> IPv6 source address field as the "errors-to" field makes no sense to 
>>> me.
>>>
>>> Two examples of corner cases to worry about in the short term.
>>> 1. Assume an NS with ARO+SLLAO where IPv6 source is LL64 and the
>>> registered address is a GP16. In that case what should happen if
>>>  1a. There is no NCE for the LL64? (Should one be created?)
>> <RCC>I am assuming one isn't needed just as one isn't strictly needed
>> for RS/RA, which uses LL64. The LBR should not strictly have to maintain
>> state for the joining node for address registration purposes. The NCE
>> would be created when the successful NA comes back from the
>> authoritative 6LBR.</RCC>
>
> Creating an NCE at that point in time has security issues, since we 
> don't have a hoplimit=255 check on the multihop DAD messages.
<RCC3>I agree there may be potential issues here re. overriding the 
hoplimit on the NA. However I don't see it much different to validating 
an already-created NCE from the original NS which is currently needed. I 
think this is an orthogonal issue.</RCC3>
>
>>>  1b. There is an NCE for the LL64, but the stored mac address is
>>> different than what is in the SLLAO. (Should it be updated?)
>>> Those questions don't arise in 6lowpan-nd-12 because the NS only
>>> applies to one address - the one in the IPv6 source field.
>> <RCC>There shouldn't be one. This would actually be end up being more
>> consistent as it means that NCEs only exist for the registered IPv6/MAC
>> address pair.</RCC>
>
> In agree that in normal operation there shouldn't be one, but our goal 
> is presumably to create robust protocols that don't fall over and 
> crash just because something unusual happened.
<RCC>If we use 64-bit for NS and only create the NCE on valid NA then I 
cannot see how you could ever get an NCE with a 64-bit based address in. 
The processing precludes it. I agree the way it is specified in nd-12 
also precludes it in a different way.</RCC2>

>>> 2. Apply ARO to CGA addresses and Secure Neighbor Discovery. In that
>>> case, which addresses should be used for the SeND verification?
>>> In 6lowpan-nd-12 the answer is simple since it is always the IPv6
>>> source address.
>> <RCC>CGAs do not occur in 6lowpan (this is *6lowpan* ND we are talking
>> about here). If you really needed a CGA, you can add the option in for
>> the registered address.</RCC>
>
> Thirty-odd years of experience with IP protocols has taught us that a 
> protocol is often applied outside of the context of the original design.
>
> Thus I think our responsibility of designers is to have a slightly 
> longer time perspective than the products that people want to build 
> this year and next, and ensure that the architecture of the protocols 
> allow for future evolution.
<RCC>I agree, but there will always be bridges which will have to be 
crossed at some point. Ironically, the development of 6lowpan ND is a 
perfect example of how the original specification did not end up 
catering for a network not anticipated or considered (either is OK in my 
book - we don't all have crystal balls :-) at the time of writing.</RCC2>
>
>
>>> I listed a few architectural disadvantages above. In addition this
>>> causes more complexity in the implementation since an implementation
>>> still has to handle NS and NA messages that do not contain an ARO, and
>>> the rules for how such messages are processed will be different than
>>> when the ARO is in place.
>> <RCC>In my opinion, it causes less complexity in that NCEs only exist
>> for addresses which will be used. The LL64 can be considered ephemeral
>> up to the point the registered address is acknowledged to be unique. As
>> for the other uses of NS in 6lowpan from RFC 4861, I think we need to
>> carefully go through them as it is not clear from the current draft
>> exactly when they would be used as 6lowpan ND is written as a kind of
>> 'addendum' to RFC 4861.</RCC>
>
> I don't think "complexity" and "memory consumption" is the same 
> concept, but ignoring that for the moment.
<RCC2>I was thinking more from the point of view of a clear demarcation 
of address use in certain phases.</RCC2>
>
> Can you explain to me how, in the "errors-to" proposal, there will be 
> NCEs for addresses which will not be used. The LP64 addresses will be 
> used for the RS/RA exchange will the 6LRs in both cases.
<RCC2>See my comments above. I can see how the "errors-to" proposal 
would work. I would like to see a detailed breakdown of the messages and 
the fields as I feel we will be sending to 64-bit MAC addresses inlining 
a 16-bit based IPv6 address and I am not sure what will be in the SLLAO 
(16-bit presumably) and that a special rule will have to exist for 
sending to EUI-64 when status indicates an error. I think carrying the 
data in the ARO is a cleaner solution.</RCC2>
>
>
>>> The ARO length is already overloaded to distinguish between multi-hop
>>> DAD messages (which are disjoint for all other use of NS and NA) from
>>> normal NS/NA.
>>>
>>> Hence as 6lowpan-nd is currently written hosts can't send ARO with
>>> length=4 since those have completely different semantics. That detail
>>> could be fixed, but is an example of the confusion in this space.
>> <RCC>Multihop NS/NA will by necessity use IP addresses which have a
>> global/UL prefix. This distiguishes them.</RCC>
>
> A host also sends NS to the 6LR for its global/UL prefixes, thus this 
> can't possibly be used to distinguish multihop DAD messages from the 
> normal AROs from the hosts.
>
> What am I missing?
<RCC>I thought RS/RA was used to obtain prefix information - these are 
link local. The only time non-link local IPv6 addresses are used in the 
IPv6 header for both source and destination are for multihop DAD NS/NA. 
The initial NS will have link-local destination (and we are debating on 
the source right now) and the final NA will have link-local source (and 
we are debating on the destination right now).</RCC2>
>
>>> First of all, wouldn't you need the SRAM once the DAD has completed?
>>> Second of all, I think the notion of a temporary NCE is needed to
>>> avoid security issues (preventing an off-link attacker from creating
>>> bogus NCEs - there is no ttl check on the multi-hop DAD messages to
>>> protect against such attacks.)
>> <RCC>
>> Another kludge and why it is wrong to overload NS/NA in this way. There
>> are two solutions here:
>>
>> 1) Set ttl properly. This limits the attacker space to the same radius
>> as the 6LBR which in practice means inside the 6lowpan.
>
> The security issue is with reception of packets sent by remote 
> attackers. I don't think we can assume that the attackers should set a 
> sufficiently small ttl so that there packets do not reach the 6lowpan ;-)
<RCC2>I agree that an outside attacker could be clever enough to figure 
out what to bump its ttl field up to. You could put harder rules around 
ttl usage for the multihop NS/NA although I admit it's not nice. So, 
yes, I am not sure this is a solution</RCC2>
>
>> 2) Create state for the NS/NA. This doesn't have to be a NCE, simply a
>> record of the corresponding NS. This would be a 'belt and braces'
>> approach on top of (1)
>> </RCC>
>
> The amount of state you need to record is the same as the minimum 
> amount of state needed for an NCE.
<RCC2>Agreed</RCC2>
>
>
>>> So while I understand the problem you are trying to solve, the
>>> proposed solution looks like it is making things a few orders of
>>> magnitude worse than the problem you tried to solve.
>> <RCC>Like it or not, 6lowpan, 802.15.4 and the 'schizophrenic' MAC
>> address add complexity. The aim is surely to deal with these in L2/L3
>> management cleanly and not to violate the rules. L3 management has to
>> consider the properties of L2 addressing (if it is used); the use of
>> LLAOs throughout indicate the need to propagate L2 addresses into L3
>> managament. Quite simply, the use of a 16-bit MAC address before it has
>> been proven to the best of the network's ability to be unique should be
>> avoided, so deliberately specifying it like is done in nd-12 clearly
>> violates the requirement.</RCC>
>
> See my questions about "use" above.
>
>    Erik
>
>