[6lo] RFC 6775 security section (was: Draft applicability for 6775bis)

["Pascal Thubert (pthubert)" <[e-mail]>]

Point well taken, Christian;

Please note that this is an update of RFC 6775, and we inherit from that; I can add text to make that more explicit.

RFC 6775 section 11<https://tools.ietf.org/html/rfc6775#section-11> “  Security Considerations” has

“

   This specification assumes that the link layer is sufficiently
   protected -- for instance, by using MAC-sublayer cryptography.  Thus,
   its threat model is no different from that of IPv6 ND [RFC4861<https://tools.ietf.org/html/rfc4861>].  The
   first trust model listed in Section 3 of [RFC3756]<https://tools.ietf.org/html/rfc3756#section-3> applies here.
   However, any future 6LoWPAN security protocol that applies to ND for
   the 6LoWPAN protocol is out of scope of this document.

“

Now, this particular text and the rest of the section do not seem to really address your point beyond “we trust devices on the network, therefore it is expected that they won’t perform a DOS attack on the 6L(B)R NCE”. With RFC 6775, we were addressing 6LoWPAN, this implicitly to IEEE Std. 802.15.4, so we did not expect that the 6LR or the 6LBR will be overwhelmed by non-aggressive registration due to the constrained nature if the IOT devices that we address.

On the one hand, trusting IOT devices may be quite optimistic. OTOH, 6lo addresses a larger variety of devices beyond the inherited scope of 6LoWPAN, and we care that this work may be applicable for multiple cases of IPv6 over foo, to be validated by the WG in charge of the particular foo.

All in all, seems clear to me that we need the text that you suggest.

What about:

“ as indicated in section < 2.  Considerations On Registration Rejection >, this protocol does not aim at limiting the number of addresses that a device can form, and a host should be able to register any address that is topologically correct in the subnet(s) advertised by the 6LR/6LBR.

On the other hand, the registration mechanism may be used by a rogue node to attack the 6LR or the 6LBR with a Denial-of-Service attack against the registry. It may also happen that the registry of a 6LR or a 6LBR is saturated and cannot take more registration, which effectively denies the requesting a node the capability to use a new address.

In order to alleviate those concerns, this specification RECOMMENDS the following:

-         A node that ceases to use an address should attempt to deregister that address from all the 6LR to which it is registered, using an EARO with a registration lifetime of 0.

-         The nodes should be configured with a registration lifetime that reflects their expectation of how long they will use the address with the 6LR to which it is registered. In particular, use cases that involve mobility or rapid address changes should use lifetimes that are homogeneous with the expectation of presence.

-         The router (6LR or 6LBR) should be configurable so as to limit the number of addresses that can be registered by a single node, as identified at least by MAC address and preferably by security credentials. When that maximum is reached, the router should use a Least-Recently-Used (LRU) logic so as to clean up the addresses that were not used for the longest time, keeping at least one Link-Local address, and attempting to keep one or more stable addresses if such can be recognized, e.g. by of the way the IID is formed or because they are used over a much longer time span than other (privacy, shorter-lived) addresses.

-         Administrators should take great care to deploy adequate numbers of 6LR to cover the needs of the nodes in their range, so as to avoid a situation of starving. It is expected that the 6LBR is usually a much more capable node then the average 6LR, but if it may be saturated, a particular deployment may leverage a high speed backbone and Backbone Routers to aggregate multiple LLNs into a larger subnet.
“

Please note also that this discussion raises the problem of a 6LR that receives a deregistration for a particular address. Does that mean that the node ceases to use the address, or that it will stop using that particular 6R, e.g. in a mobility scenario. Seems that there is a need to signal the difference to the 6LR, so it notifies the 6LBR only in the former case. Proposal: add a flag in the EARO for the registering node to indicate the case to the 6LR.

Also, there is a distinction on the status 2  “Neighbor Cache Full”, when received by the node from the 6LR in a NA message. Does that indicate that the 6LR reaches an administrative maximum number of addresses, in which case the node may give up another address first, that the 6LR is completely saturated, in which case the node can try with a different 6LR, or is it the 6LBR that is saturated, in which case the node must look for another LLN. We may hide the first case with the LRU behavior in the routers, but we still need to at least indicate whether the saturation is local to the 6LR or global to the LLN.

What do others think?

Pascal

From: Christian Huitema [mailto:[e-mail]]
Sent: jeudi 20 avril 2017 20:06
To: Pascal Thubert (pthubert) <[e-mail]>; Lorenzo Colitti <[e-mail]>; Gabriel Montenegro <[e-mail]>
Cc: Erik Nordmark <[e-mail]>; [e-mail]; Suresh Krishnan <[e-mail]>; [e-mail]
Subject: Re: [6lo] Draft applicability for 6775bis




On 4/20/2017 9:15 AM, Pascal Thubert (pthubert) wrote:
What about :

«
    This implies that a 6LR or 6LBR which is intended to support N hosts MUST have space to register at least on the order of 10N IPv6 addresses.
«
->
«
    This implies that the capabilities of 6LR and 6LBRs in terms of number of registrations must be clearly announced in the router documentation, and that a network administrator should deploy adapted 6LR/6LBRs to support the number and type of devices in his network, based on the number of IPv6 addresses that those devices require.
«

Works ?

I don't have a strong opinion on this wording, but I have a recommendation for the authors of the draft. This discussion outlined a couple of concerns about potential abuses. For example, I noted the following:

1) Registration procedure could be used to deny access, by abusing the administrative rejection option.

2) Nodes registering a large number of IID could overwhelm the registration system.

I would also add a generic concern about unique identifiers and privacy. This is an obvious concern in mobility scenarios, but even for static networks it also is a concern if the option can be observed outside the network. I understand that the encrypted link provides some mitigation, but having provisions to vary the IID over time would be even better.

It might be a good idea to document these issues in the security considerations.

-- Christian Huitema