Re: I-D Action: draft-ietf-6man-default-iids-04.txt

[Kerry Lynn <[e-mail]>]

On Wed, Jul 1, 2015 at 1:20 AM, Fernando Gont <[e-mail]> wrote:

> Ralph, Samita, and co-authors (and wg in general),
>
> Could you please take a look at Mark's comment and rationale, and vice
> your opinion?
>
> He essentially argues that we should remove the "MAY" in:
>  "It is RECOMMENDED by this document that future specifications do not
>   specify IPv6 address generation schemes that embed the underlying
>   link-layer address in the IID.  Future specifications MAY use an IID
>   based on a node's link-layer address if design and engineering
>   considerations warrant."
>
> (his rationale is provided below).
>
> I'm fine with applying his suggested change, but would like to hear your
> thoughts before applying any changes.
>
> As the lead author of https://tools.ietf.org/html/draft-ietf-6man-6lobac,
I'm
strongly in favor of retaining the option to specify IIDs based on locally
assigned link-layer addresses, particularly for link-local addresses.  I'm
prepared to provide a defensible example of "design and engineering
considerations" if that would be useful.

Locally assigned short identifiers (such as the IEEE 802.15.4 short address)
are dynamically assigned on a per-network basis, support the most efficient
compression afforded by LOWPAN_IPHC, and do not "leak" origin of
manufacture or personally identifying information.

The first sentence in the paragraph above could be interpreted as
recommending that authors of future proposals MUST NOT provide a
specification for forming IIDs from link-layer addresses.  The MAY
in the following sentence makes it clear that the recommendation is
SHOULD NOT.

What might be helpful is for the supporters of this proposal to agree on
a suitable "warning label" that could be slotted into the Security section
of future proposals to inform implementers of the risks of specifying IIDs
based on globally unique hardware identifiers (which, I suspect, is what
the concern is).

Regards, Kerry Lynn


> Thanks!
>
> Best regards,
> Fernando
>
>
>
>
> On 07/01/2015 01:33 AM, Mark Smith wrote:
> > Hi Fernando,
> >
> > On 1 July 2015 at 08:52, Fernando Gont <[e-mail]> wrote:
> >> Hi, Mark,
> >>
> >> On 06/30/2015 04:25 AM, Mark Smith wrote:
> >>>>> "Future specifications that specify IPv6 address generation schemes
> >>>>> SHOULD NOT embed the underlying link-address in the IID. Even when
> the
> >>>>> link-layer address is randomised as recommended previously, the IPv6
> >>>>> IID becomes a globally unique identifier for as long as the
> link-layer
> >>>>> address derived IID continues to be used. For low powered battery
> >>>>> operated devices, this globally unique IID may persist for many
> months
> >>>>> and possibly years. Random, yet rarely or never changing IIDs derived
> >>>>> from link-layer addresses are vulnerable to the threats described for
> >>>>> Constant IIDs in [draft-ietf-6man-ipv6-address-generation-privacy]"
> >>>>
> >>>> I will let others weigh in. IMHO, this is getting into to many details
> >>>> regarding an approach that we're recommending against in the first
> >>>> place. If anything, we might include something along these lines in
> >>>> draft-ietf-6man-ipv6-address-generation-privacy but it would seem out
> of
> >>>> scope to me.
> >>>
> >>>
> >>> The key thing I'm concerned about is the MAY in the last sentence
> >>> about future specifications. MAY means optional in any case rather
> >>> than only allowed in corner cases after careful consideration.
> >>
> >> I kind of agree with what you say. However, please note that the
> >> previous sentence says that the privacy-enhanced approach should be the
> >> default IID generation scheme.
> >>
> >> That is, hosts SHOULD implement and employ (by default) RFC7217, and MAY
> >> implement an IID generation scheme based on the link-layer addresses.
> >> So, you have to have "a very good reason" no to use (by default)
> >> RFC7217. -- i.e., the end-result is the same as the one you intend.
> >>
> >>
> >>
> >>> Perhaps all that is really necessary is to remove that sentence, as it
> >>> seems to be mostly contradicting the previous one ("you should not
> >>> embed link-layer addresses as IIDs, but you can if you need to or want
> >>> if it is easier to design or engineer it that way" - and as smart
> >>> people are usually naturally lazy, they'll avoid doing harder stuff
> >>> that they don't have to.)
> >>
> >> You MAY implement it, but SHOULD NOT use it by default.
> >
> > Re-quoting the text just to make the context clearer:
> >
> > "It is RECOMMENDED by this document that future specifications do not
> >    specify IPv6 address generation schemes that embed the underlying
> >    link-layer address in the IID.  Future specifications MAY use an IID
> >    based on a node's link-layer address if design and engineering
> >    considerations warrant."
> >
> > I think the MAY in very limited corner cases is implicit in the use of
> > SHOULD NOT in the previous sentence rather than a MUST. I don't really
> > see why it is necessary to subsequently explicitly state the MAY case,
> > which I fear can also be used to excuse not implementing RFC7217 when
> > it might be possible to.
> >
> > A "design" consideration from the "design and engineering
> > considerations warrant" caveat is what are the minimum features
> > necessary to ship the product as soon as possible - so optional or
> > possibly optional security (i.e., RFC7217) will get dropped if it
> > delays the product, unless it is perceived that it would cause market
> > failure of the product.
> >
> > As a broad observation, I think security/privacy has unfortunately
> > ended up being "too optional" in the past. Specific examples that have
> > effected me that I can think of are DECT devices for where encryption
> > was optional (I couldn't find a home phone that implemented DECT
> > encryption when I went to buy one) and much more recently
> > Bluetooth/Bluetooth LE devices, where encryption is also optional, and
> > since both those types of devices use radio signals, the exposure is
> > much larger then when I've either used wired Internet access or
> > properly secured Wifi.
> >
> >>
> >> FWIW, I'm okay myself with what you propose... But since the
> >> requirements language was hand-crafted with the 6lo people (the guys
> >> that essentially asked for some room for exception). - i.e., it took a
> >> while to converge to the current text... and if we start tweaking it,
> >> I'm afraid it might take forever (if ever) to converge.
> >>
> >
> > With how widely the types and numbers of IoT devices that 6lo will be
> > implemented on, how sensitive the data they may be collecting, what
> > they're controlling, and how visible the radio signals of these
> > devices might be in public spaces, I'm starting to think that the
> > savings of using link-layer IIDs to avoid of a few ND packets and to
> > avoid implementing RFC7217 might not be worth the security risk. Those
> > specific types of devices might be the ones where RFC7217 might be
> > actually more important than in other cases.
> >
> > I don't think going back to the 6lo people will end up an endless
> > loop. I think all it would be necessary to ask them is would they be
> > happy for the second sentence to be dropped in the following. The
> > RECOMMENDED ("SHOULD") rather than a MUST in the first sentence allows
> > them room to use link-layer addresses as IIDs if they absolutely must.
> > I think if they're unhappy with the first sentence by itself, then I
> > think it'd actually be a disagreement with the first sentence, and we
> > should then find out why they actually think implementing RFC7271 is
> > really a MAY rather than a RECOMMENDED/SHOULD.
> >
> > "It is RECOMMENDED by this document that future specifications do not
> >    specify IPv6 address generation schemes that embed the underlying
> >    link-layer address in the IID.  <strike>Future specifications MAY use
> an IID
> >    based on a node's link-layer address if design and engineering
> >    considerations warrant.</strike>"
> >
> >
> > Thanks very much,
> > Mark.
> >
> >
> >
> >> Thanks!
> >>
> >> Cheers,
> >> --
> >> Fernando Gont
> >> SI6 Networks
> >> e-mail: [e-mail]
> >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> >>
> >>
> >>
> >>
> >
>
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>