Re: <draft-ietf-6man-default-iids> update to rfc2464bis

On 12 Jan. 2017 23:19, "Lorenzo Colitti" <lorenzo@google.com> wrote:

On Thu, Jan 12, 2017 at 8:29 PM, Fernando Gont <fgont@si6networks.com> wrote:
>
> >     All these documents are about generating stable addresses, not temporary
> >     addresses. So I'm not sure why the text should be removed. The text in
> >     all this documents ae about stable addresses. IETF-wise, the only doc
> >     that is about temporary addresses is RFC4941. Hence the text seems
> >     correct to me.
> >
> > If instead of removing that text we can clarify that it only applies to
> > stable addresses, that works for me. Suggestion: change "These are
> > described in Appendix A and are no longer recommended." to ""These are
> > described in Appendix A and are no longer recommended for stable addresses."
>
> Fine. Isn't the assumption in all these RFCs that the addresses are
> stable, and that the MAC addresses are unique?

> Yes, those documents were written when randomized MAC addresses did not yet exist, yes. But those assumptions are not valid today; randomized MAC addresses are not only in use, there are standards track documents that assume their use (e.g., RFC7844). Since we're now republishing these documents, we need to make them reflect the state of the world as it is today, and the revised documents must not assume that MAC addresses are unique and static.

(IEEE) MAC addresses aren't the only types of link layer addresses and
may not be in the future.

ARCNet only has 8 bit link-layer addresses and despite its age, it
still looks like it is being manufactured and used.

https://www.ccontrols.com/tech/arcnet.htm

CanBus, used in cars, looks to only have 11 bit or 29 bit addresses

https://en.wikipedia.org/wiki/CAN_bus#Frames

I'm sure there are other link layers out there that we would want IPv6
to run over that have similar sorts of link layer address sizes.

I don't think we shouldn't bind IPv6 address security properties to
link layer address properties, because then it puts the IPv6 address
security properties out of our control.

We could require link-layer addresses to be of a certain size and have
certain properties before running IPv6 over it, however that will
limit IPv6 applicability (in other words, demand that the link layer
addresses under IPv6 MUST be IEEE MAC addresses.)

We could try to check the randomness properties of the link layer
address before using it in a IPv6 address, however then you still need
a fall back if the link-layer address fails that test, so you're going
to have general, non-link layer specific fall back method available
anyway, and the extra code complexity of link layer address validation
checks.

I think it is simpler and easier to ignore the link layer address
properties and generate IPv6 addresses with good security properties
independently of them. The only use of link layer properties is as a
possible seed and as an interface distinguisher when useful or
necessary, which is what RFC7217 does.

I think it is better to try to minimise the coupling and dependencies
between the link layer and link layer properties and the IPv6 layer
rather than trying to tighten it. That seems to have been a theme of
IPv6 e.g., using DHCPv6 over PPP rather than embedding IPv6 upper
layer parameters in PPP such as DNS addresses, and the shifting of
neighbor discovery into IPv6 rather than having a parallel link layer
specific neighbor discovery protocol (i.e., ARP and IPv4 being in a
parallel, and ARP being Ethernet specific.)

This theme is described in RFC1958, even though security benefits may
not have been the reason for it at the time.

"The Internet level protocol must be independent of the hardware
   medium and hardware addressing.  This approach allows the Internet to
   exploit any new digital transmission technology of any kind, and to
   decouple its addressing mechanisms from the hardware. It allows the
   Internet to be the easy way to interconect fundamentally different
   transmission media, and to offer a single platform for a wide variety
   of Information Infrastructure applications and services. There is a
   good exposition of this model, and other important fundemental
   issues, in [Clark]."

> > The reason the text needs to be changed is because during the discussion
> > of default-iids there was substantial discussion of the use case of
> > using EUI-64 with randomized MAC addresses. There was consensus that
> > this is a use case we want to support, and as a result, the working
> > group concluded that we should change every occurrence of the phrase
> > "based on a link-layer address" to "based on a stable link-layer
> > address" in the default-iids draft.
>
> My read of the discussion is that you didn't want default-iids to ban
> this case (and maybe there was not more than one or two voices in this
> direction), and we simply decided to have default-iids fous on stable
> addresses to be able to do progress on something. Claiming that doing
> temp adderesses by doing MOdified-EUI64 is streching that outcome quite
> a bit, IMO.

> Funny... my read of the discussion is that everyone wanted to support this case and only you didn't (and maybe there was not more than one or two voices in this direction". :-P

I also supported the decoupling. I understand the convenience and
motivation for using random MAC addresses (I've had many of my systems
including my main laptop changing them at boot for a number of years
now), however I think it is a layer dependency that is better to avoid
(i.e., have addresses at both layers that have good security
properties and that don't have any security bindings or couplings
between each other.)

Regards,
Mark.

>But seriously: regardless of which of the two interpretations above is correct (likely neither), the fact of the matter is that the text in default-iids says "stable" and that did not happen by chance, but through explicit working group discussion. We have to respect that here.

> All this documents talk about stable addresses. Discussing temp
> addresses in them is actually talking about stuff that simply wasn't
> there, with operating conditions different from those assummed so far.

Again: we are republish these documents and we have to do so taking
into account things as they are today. Today, the fact of the matter
today is that MAC addresses are in use and the documents have to
reflect that.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------