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

From: Erik Nordmark <[email-masked]>
Date: Fri, 03 Sep 2010 13:14:29 -0700

On 08/31/10 01:21 AM, Colin O'Flynn wrote:
> Hi Erik,
>
> Thanks for looking through my proposal&  commenting. I think a lot of the
> problems come from my original e-mail/proposal not being clear enough, or
> mixing possible implementation-specific optimizations with what the general
> case I saw was. Let me try to clarify some of those:

Sorry for the delay - too many things going on.

>> . 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.
>
> Not sure I understand that one. If the SLLAO is included, the LLAO has the
> address associated with the IPv6 source address is all I assume. The ARO
> registered address is ALWAYS the address which you wish the 6lowpan-ND
> action on (register, re-register, etc).

So in your proposal the IPv6 source address in the packet should be 
completely ignored (when there is an ARO) except for the case when an 
error needs to be sent back?

That would be a fairly radical change to 4861.

>> 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?)
>
> 6lowpan-nd-12 already has this if I'm reading your e-mail correctly. Section
> 5.2 Interface Initialization says that:
>
>     A link-local address is formed based on
>     the EUI-64 assigned to the interface, and then the host sends Router
>     Solicitation messages as described in [RFC4861] Section 6.3.7.
>
> Hence the router may have already created a NC entry if it is using standard
> ND. In my suggestion it's up to implementers HOW the deal with routing the
> NA response back. They may use a normal NC, they may use a special NC that
> only stores entries from NS, or they may fake it out by sending to the
> EUI-64 of the ARO if their specific network design allows such faking.

6lowpan-nd-12 doesn't have the issue I tried to point out. For 
6lowpan-nd-12 the NCE associated with the sender of a NS (and hence the 
SLLAO) is always looked up based on IPv6 source field. No exceptions.

>> 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?)
>
> My understanding is standard ND processing would deal with this. When the NS
> (or anything else) was sent from the LL64, the SLLAO would always point to
> the correct mac address to use. Which will for efficiency reasons always be
> the EUI-64 in 6LoWPAN networks.

Question is really to what degree you envisioned changing 4861. Omitting 
looking for an NCE based on the IPv6 source field would be a radical 
change. Looking for an NCE based on the IPv6 source field, and then 
separately looking for an NCE based on the registered address would at 
least be inefficient, and seems a bit complex.

>> 2. Apply ARO to CGA addresses and Secure Neighbor Discovery.
>
> Not sure on this one. I've never implemented SeND so don't know about
> resource requirements, is it something which could be implemented on the
> type of nodes we are looking to run 6lowpan-ND on?

The decades of history we have for IETF protocols indicates that the 
hardware capabilities evolve a lot faster than the protocols, and that 
successful protocols often get applied outside of their initial indented 
domain.

Thus I wouldn't be surprised if the optimizations provided by 6lowpan-nd 
would be applied in contexts where people would also like to use SeND.

> But I don't have a good response to that concern, AFAIK my proposal isn't
> cleanly compatible with SeND.
>
>> . 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
>
> Huh? How is this different from 6lowpan-ND currently? In fact I thought it
> even easier, as the processing only needs to check the EUI-64, and generally
> keeps processing of messages more streamlined.

The difference is that currently the processing of an ARO is localized.
The base NS/NA header is processed, and then each option is processed 
independently.

With your proposal it seems like the processing of the base NS/NA header 
needs to be different whether or not an ARO is present, which would be a 
departure from how we currently try to manage complexity in RFC 4861.

> These observations are at least based on how I've implemented 6lowpan-ND.
> Perhaps I'm missing very obvious optimizations in ND-12, but from my
> perspective of someone who has written a 6lowpan-ND implementation, the
> proposed changes would be considerably easier.

While that might be the case for a minimal implementation, I don't think 
that is true as you look at all of ND. If we think that ND will continue 
to be carefully extended, then SeND becomes merely one example of where 
redefining the semantics of the IPv6 source address for NS/NA will cause 
issues.

>> The ARO length is already overloaded to distinguish between multi-hop
>> DAD messages
>
> My proposal moves to distinguishing based on the src/dest IP addresses.
> Multi-hop uses global IP addresses, everything else uses link-local.

Since I missed that, I suspect it would be far too subtle.

In any case, the currently length distinction is a source of continued 
confusion and complexity. I think we actually need to split out the 
multihop DAD messages as I indicated in an email a few weeks back.

>> First of all, wouldn't you need the SRAM once the DAD has completed?
>
> It was more that you could get away without a NC at all in the intermediate
> 6LR. Again this isn't required in the general case, but if using for example
> RPL on top you could get away without a NC on the 6LRs.

I don't understand unless you have RPL and no hosts.
The 1st hop router needs to track the (successfully) registered hosts, 
which means an NCE for each of them.
Intermediate 6LRs don't necessarily need to track them. But this has 
nothing to do with what happens when there is a duplicate AFICT.

>> Second of all, I think the notion of a temporary NCE is needed to avoid
>> security issues
>
> Hmm good point. That would require changes to my proposal, either:
>
> -Include the temporary NCE again
>
> -On receiving a NA, check if the IPv6 address you will send to based on the
> EUI-64 is already in your NC. It should be in the NC as you received a NS
> from it. This basically uses the LL64 as the temporary NCE.

I think that still allows a remote attacker to create bogus 
registrations by sending the multihop NAs; the attacker just need to 
know the EUI-64.

> -Include something like a nonce in the reserved space of the ARO. This is
> less in line with current 6lowpan-ND so probably not worth the hassle.

To check the nonce you'd need to remember which one you used. Hence you 
need state. And since you probably don't want the nonce to be easy to 
guess it makes sense having a difference nonce per IP address; thus it 
ends up looking like a temporary NCE.

>> How
>> does it relate to the overall goal of making 6lowpan compact, simple,
>> and sufficient to handle 6lowpans.
>
> It would cleanly allow extensions to 6lowpan-ND that could do the following
> (if someone later wanted to):
>
> * Have the 6LBR tell you a better short address to use instead of the one
> you picked. If the network is packed, maybe it's better than the guess&
> check method.

If that flexibility is needed, then I suggest that DHCPv6 is the best 
approach.

> * Would let the 6LBR tell a node which is re-registering what his old short
> address was.

Why would the node forget the old short address?
And again, sounds like DHCPv6.

> I don't mean we will add them to 6lowpan-ND immediately. But these are
> things I could see being useful, and having the protocol designed such that
> the EUI-64 and NOT the registered address is used to uniquely identify the
> NS sender makes sense to me.
>
>> Thus for robustness all messages that contain the ARO must be able to
>> function whether or not the 6LR has an NCE
>
> My message probably wasn't clear, as I didn't mean in the general case you
> can remove the SLLAO. Just that in specific implementations, it would give
> them the flexibility to remove the SLLAO as they KNOW the same information
> is carried in e.g. the EUI-64. But I probably shouldn't have mixed
> implementation-specific optimizations and the general case.
>
>> Introducing an "errors-to" field in the ARO (either as a MAC address or
>> an IP address) solves the problem
>
> One of the problems I was looking to solve is with people using "standard"
> stacks. Such stacks had trouble sending a packet to a destination IPv6
> address that was in the neighbor cache, BUT the mac address was something
> different. Thus it should be an IP address that the "error-to" is.

I don't see a problem with it being an IPv6 address. It makes the 
formatting of the option simpler, even if it becomes a bit larger.

> To save space though it would be better if the error-to was just a MAC
> address&  you auto-configure the IPv6 address based on this. Or if the
> error-to is the LL64. After all the RS should have come from the LL64, so
> presumably you have an entry in your NC for the LL64 of that node.

If we want the semantics of it being an IPv6 address, then anything that 
is more compressed is in essence a form of header compression. I don't 
think it makes too much sense to think of header compression one field 
at a time; if we need it shouldn't we look more generally at all the 
NS/NA content?

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 08 Sep 2010 19:54:04 -0700

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.

>> 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. 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" ;-)

>> 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?
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?

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.

>> 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.
> <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.

>> 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.

>> 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.

>> 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.

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.

>> 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?

>> 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 ;-)

> 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.

>> 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