Subject: Re: [6lo] Potential requirements for 6775bis

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 22 Aug 2014 12:14:24 +0000

Hello Behcet:

I agree, the draft goes beyond requirements, and is a place holder for hints towards solutions.
It is very likely that if the draft gets adopted, that text will have to be eliminated. We could move some of it to personal submissions solution drafts.
In the meantime, the extra text provides at least a hint that the requirements can be achieved and that there is at least one simple way to achieve them.

I also agree with your requirements, and added them to the draft with a slight rewrite. Could you please have a look at -04?

Cheers,

Pascal

> -----Original Message-----
> From: Behcet Sarikaya [mailto:[email-masked]]
> Sent: jeudi 21 août 2014 19:02
> To: Pascal Thubert (pthubert)
> Cc: Erik Nordmark; 6lo WG
> Subject: Re: [6lo] Potential requirements for 6775bis
> 
> Hi Pascal,
> 
> On Wed, Aug 20, 2014 at 4:46 AM, Pascal Thubert (pthubert)
> <[email-masked]> wrote:
> > 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?
> >
> 
> 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
> 
> 
> 
> > 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.
> 
> Agree with these.
> 
> >
> >    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.
> >
> 
> 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
> 
> > 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,
> >>
> >> Please see my comments inline.
> >>
> >> Regards,
> >>
> >> Behcet
> >> On Thu, Aug 14, 2014 at 12:47 PM, Pascal Thubert (pthubert)
> >> <[email-masked]> wrote:
> >> > 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.
> >> >>
> >> >> 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.
> >>
> >> 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.
> >>
> >>
> >> >> - 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