Re: Comments on draft-ietf-6man-default-iids-01.txt

[Kerry Lynn <[e-mail]>]

Fernando,

Comments inline...

On Mon, Nov 10, 2014 at 10:45 PM, Fernando Gont <[e-mail]>
wrote:

> Hi, Ralph,
>
> Thanks so much for your feedback! (and apologies for the delay in my
> response)...
>
> On 10/27/2014 08:03 AM, Ralph Droms (rdroms) wrote:
> > In this document, I think it is important to be explicit about the
> > considerations that might lead to a decision not to follow the RFC
> > 2119 language recommendations in this document.  My immediate concern
> > is the 6LoWPAN standards, which use IIDs based on hardware addresses
> > as a method for IPv6 header compression.
>
> My personal take (also rather off-topic, you might argue) is that while
> the MAC address has been typically embedded in the IID, one cannot
> really (architecturally speaking) expect that to be the case. -- but
> yes, this is kind of off-topic.
>
> Have you read RFC 6282?  IPHC compression efficiency is *based* on the
idea that redundant information appears in both the L2 and L3 (IPv6) header
address fields and may be elided from the latter.

Having said that, some link technologies (e.g. 802.15.4) allow for
dynamically
assigned short-form identifiers assigned by a local coordinator.  Greater
IPHC compression efficiency is realized in this case.  In terms of your
concerns, short L2 addresses may make address scanning easier but
mitigate node tracking (since a device will get a different identifier when
it
changes networks) and device-specific attacks (since OUI is absent).

In general, we need to distinguish between L2 addresses (which may be
dynamic) and "hardware" addresses (which I take to mean EUI-64 or
Modified EUI-64 Format addresses formed from MAC-48 addresses).

>
>
> > As an editorial detail, the document lists the various RFCs that are
> > update, but does not explicitly state what is to be updated in those
> > documents.  While the updates could be reasonably inferred, seems to
> > me an explicit statement about what is to be updated would be good.
>
> Essentially, what we're updating is how Interface IDs should be
> generated for such technologies. Quoting the text to be replaced would
> make this document ugly... mm.. maybe just mention the relevant
> section(s)? Something else?
>
> (i.e., I understand your point, but do not (yet) see a cleaner way to do
> that than the one (rather vague, if you want) that we're currently
> employing) -- i.e., ideas are welcome.
>
> It was raised by Carsten in 6lo that we have to be more specific regarding
the use of the term "hardware address".  To discuss one 6lo proposal with
which I am intimately familiar (draft-ietf-6lo-6lobac), MS/TP master nodes
effectively have a 7-bit hardware address.  This is right-justified in a
field
of zeros to create a 16-bit short-form identifier, which is then converted
to
a 64-bit Modified EUI-64 Format IID (just as in RFC 4944).  Why?  It's
designed
to work with IPHC.  My point is that not all hardware addresses are EUI-64s
and not all L2 address are hardware addresses, so let's be more precise in
our
language and in our recommendations.

>
>
> > With those comments in mind, I'll suggest the following text
> > changes:
> >
> > In section 1, add this paragraph before the "NOTE":
> >
> > In some network technologies and adaptation layers, the use of an IID
> > based on a hardware address offers some advantages.  For example, the
> > IP-over-IEEE802.15.4 standard in RFC6775 allows for compression of
> > IPv6 addresses when the IID the address is based on the corresponding
> > hardware address.  The design and engineering tradeoffs between
> > security and privacy, and network efficiency should be considered in
> > any decision about the use of an IID based on a hardware address.
>
> I'm personally fine with haing an exception for say 6775 and similar
> technologies. However, as noted above, I'm not sure I'd state it as
> suggested - i.e., trading efficiency for security & privacy.
>
> It's actually trading cost for security and privacy.  Legacy technologies
like
MS/TP are designed to run on any micro-controller that has a UART, a 5 ms
resolution timer, and an RS-485 driver.  These technologies compete in very
cost-sensitive markets.  The system designer is making a conscious decision
to place security features elsewhere, e.g. in gateways. If privacy is a
concern
they can specify a more capable processor, more memory, and a different link
technology - but only of the customers will pay for it.

>
>
> > Replace section 3 with:
> >
> > It is RECOMMENDED by this document that nodes implement and employ
> > RFC 7217 as the default scheme for generating stable IPv6 addresses
> > with SLAAC.  Some specifications MAY use a an IID based on a node's
> > hardware address if design and engineering considerations warrant.
> >
> > It is RECOMMENDED by this document that nodes do not employ IPv6
> > address generation schemes that embed the underlying hardware address
> > in the Interface Identifier.  In particular, this document RECOMMENDS
> > that nodes do not generate Interface Identifiers with the schemes
> > specified in [RFC2464], [RFC2467], [RFC2470], [RFC2491], [RFC2492],
> > [RFC2497], [RFC2590], [RFC3146], [RFC3572], [RFC4338], [RFC4391],
> > [RFC5121], and [RFC5072], and updates those documents with this
> > recommendation.
> >
> > It is RECOMMENDED by this document that future specifications no not
> > specify IPv6 address generation schemes that embed the underlying
> > hardware address in the Interface Identifier. Future specifications
> > MAY use a an IID based on a node's hardware address if design and
> > engineering considerations warrant.
>
> Overall, the above seem fine to me. What do other folks think?
>
> As long as it remains RECOMMENDED and not a SHALL, I have no major
issue (implementers may follow the recommendation, or not, according to
their particular threat analyses).

Regards, Kerry

>
>
> > In section 4, replace the last paragraph with:
> >
> > Future revisions or updates of these documents should take the issues
> > of privacy and security mentioned in section 1 and explain any design
> > and engineering considerations that lead to the use of IIDs based on
> > a node's hardware address.
>
> This seems fine, too.
>
> Thanks!
>
> Best regards,
> --
> 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
> --------------------------------------------------------------------
>