Subject: [6lo] Potential requirements for 6775bis

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Aug 2014 10:44:27 -0700

I think the WG should collect together requirements for RFC6775bis in a 
concise form.

The potential ones I know of are:
  - Handling host movement better by being able to determine the most 
recent ARO
  - Working on link-layers and devices that do not use/have EUI-64 
identifiers
  - Removing the dependency (from the privacy discussion) on having a 
link-local address which corresponds to the EUI-64
  - There are use cases where it it useful to proxy registrations. We 
probably want to have explicit support for this.
  - Secure? What threats would we be concerned about? Do we need the 
same protections as one would get with SeND? Or would it be
     sufficient to secure the binding between the unique id in the ARO 
and the host which sent it?
  - Handle constrained devices on links that are not necessarily low 
power? (Currently the assumption is that all the devices on the link are 
constrained devices that perform ARO).

Are there other potential requirements?

    Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 14 Aug 2014 17:47:25 +0000

Thanks a bunch Erik!

I'll add this list to the req draft And republish.

Pascal

> Le 14 août 2014 à 19:44, "Erik Nordmark" <[email-masked]> a écrit :
> 
> 
> I think the WG should collect together requirements for RFC6775bis in a concise form.
> 
> - Handling host movement better by being able to determine the most recent ARO
> - Working on link-layers and devices that do not use/have EUI-64 identifiers
> - Removing the dependency (from the privacy discussion) on having a link-local address which corresponds to the EUI-64
> - There are use cases where it it useful to proxy registrations. We probably want to have explicit support for this.
> - Secure? What threats would we be concerned about? Do we need the same protections as one would get with SeND? Or would it be
>    sufficient to secure the binding between the unique id in the ARO and the host which sent it?
> - Handle constrained devices on links that are not necessarily low power? (Currently the assumption is that all the devices on the link are constrained devices that perform ARO).
> 
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 19 Aug 2014 12:01:08 -0500

Hi Erik, Pascal,

Please see my comments inline.

Regards,

Behcet
On Thu, Aug 14, 2014 at 12:47 PM, Pascal Thubert (pthubert)
>> - There are use cases where it it useful to proxy registrations. We probably want to have explicit support for this.

I have comments on this:

 - Secure? What threats would we be concerned about? Do we need the
same protections as one would get with SeND? Or would it be sufficient
to secure the binding between the unique id in the ARO and the host
which sent it?

I think SeND for RFC 6775 is a very light weight extension and with
recent suggestions for optimization from Pascal and possibly from
Rene, it is going to become even more light weight. Why not work on
it?

So in view of this, I suggest modifying Erik's suggestion as follows:

Support to secure the binding between the unique id in the ARO and the
host which sent it.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 20 Aug 2014 09:46:25 +0000

Hello Behcet;

I'm with you here. I can refine the requirements draft as follows:

1) The draft must indicate what attacks are considered. I already addded in 03 that we need to defeat the spoofing of role (6LR, 6LBR, 6BBR), and the spoofing an address (registering somebody else's address to hijack his traffic).  Are there others that people are concerned with?

2) I can add the following the security section:

   This specification expects that the link layer is sufficiently
   protected, either by means of physical or IP security for the
   Backbone Link or MAC sublayer cryptography.  In particular, it is
   expected that the LLN MAC provides secure unicast to/from the
   Backbone Router and secure broadcast from the Backbone Router in a
   way that prevents tempering with or replaying the RA messages.
   Still, Section 4.5 has a requirement for a mutual authentication and
   authorization for a role for 6LRs, 6LBRs and 6BBRs.

   This documents also suggests in Section 5.4 that a 6LoWPAN Node could
   form a single Unique Interface ID (CUID) based on cryptographic
   techniques similar to CGA.  The CUID would be used as Unique
   Interface Identifier in the ARO option and new Secure ND procedures
   would be proposed to use it as opposed to the source IPv6 address to
   secure the binding between an Address and its owning Node, and
   enforce First/Come-First/Serve at the 6LBR.

We will note that the draft in it current state goes beyond the pure requirement and suggests approaches. 
That can always be filtered out, or placed in appendix as a place holder.
You may also pick text from the draft to include into yours if that suits your needs.

What do you think?

Pascal

> -----Original Message-----
> From: Behcet Sarikaya [mailto:[email-masked]]
> Sent: mardi 19 août 2014 19:01
> To: Pascal Thubert (pthubert)
> Cc: Erik Nordmark; 6lo WG
> Subject: Re: [6lo] Potential requirements for 6775bis
> 
> Hi Erik, Pascal,
> 
> same protections as one would get with SeND? Or would it be sufficient to
> secure the binding between the unique id in the ARO and the host which
> sent it?
> 
> I think SeND for RFC 6775 is a very light weight extension and with recent
> suggestions for optimization from Pascal and possibly from Rene, it is going
> to become even more light weight. Why not work on it?
> 
> >> - Handle constrained devices on links that are not necessarily low power?
> (Currently the assumption is that all the devices on the link are constrained
> devices that perform ARO).
> >>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 21 Aug 2014 12:01:30 -0500

Hi Pascal,

> 1) The draft must indicate what attacks are considered. I already addded in 03 that we need to defeat the spoofing of role (6LR, 6LBR, 6BBR), and the spoofing an address (registering somebody else'…

Agree with these.

In my draft, I had a few requirements, like:

- The solution should lead to small packet sizes

- Key hash calculation should be light weight and should avoid SHA-1,

- Public key and signature sizes should be minimized

>    authorization for a role for 6LRs, 6LBRs and 6BBRs.

Agree with these.

>    enforce First/Come-First/Serve at the 6LBR.

This looks like going into solution space.
Maybe you can restate it in view of the requirements I have above.
Then it could fit better into a requirements draft, I think.

Regards,

Behcet

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 22 Aug 2014 11:33:26 -0700

> Support to secure the binding between the unique id in the ARO and the

I think that is a reasonable security requirement.

    Erik