Re: 6man w.g. last call for <draft-ietf-6man-default-iids-11.txt>

[Fernando Gont <[e-mail]>]

Hi, Jinmei,

Thanks so much for your feedback! Comments in-line....

On 05/13/2016 01:55 PM, 神明達哉 wrote:
[....]
> 
> I've read version 11 of the document.  Personally I don't have a
> strong objection to publishing it, but, if I understand the past
> concerns correctly, I suspect this version don't fully address them.
> I also have one non-trivial point, which I would like to be address
> before publication.
> 
> If my understanding is correct, one major concern raised in the past
> was that some implementors may simply not see the need for the
> stability and just want to address the security/privacy issues in a
> different way (such as just using randomized link-layer addresses).  I
> don't have a strong opinion on this particular concern myself, but I
> see the point of such concerns.  If the intent of this document is not
> to refuse the concern (which I'm not sure about), the current tone
> still seems to be too normative.

There are multiple reasons for which that is the wrong approach and/or
incorrect.

They are stated in the I-D as:
   More generally, the reuse of identifiers that have their own
   semantics or properties across different contexts or scopes can be
   detrimental for security and privacy
   [I-D.gont-predictable-numeric-ids].  In the case of traditional
   stable IPv6 IIDs, some of the security and privacy implications are
   dependent on the properties of the underlying link-layer addresses
   (e.g., whether the link-layer address is ephemeral or randomly
   generated), while other implications (e.g., reduction of the entropy
   of the IID) depend on the algorithm for generating the IID itself.


A more thorough explanation was provided by Alissa during the last IETF
meeting, and can be summarized as:

* Using an ID in a different context or different scope (than originally
meant for), or with additional semantics than those required for
interoperability results in security/privacy implications. Please read:
draft-gont-predictable-numeric-ids

* Sticking to MAC-based IIDs (when randomizing MAC addresses) is not a
good idea because:
  + Attempts to ignore a flaw, relying on something the host does not
control
     e.g. we do not control whether MAC addr randomization algorithm is
     appropriate or if it is actually possible Wastes 18 bits of entropy

 + Might even lead to interoperability problems
     There's no recovery strategy for DAD failures in traditional SLAAC


* RFC7217 and default-iids is about replacing the
default scheme for generating stable addresses

* Don't want stable addresses?
  1) Update RFC 4941 such that stable addresses are not required (huge
potential for interoperability problems)
  2) Use the randomized MAC address as the Net_Iface parameter of RFC7217.
  3) Note: IEEE has RFC7217-like stable per network MAC addresses



Besides the "concerns" raised by Lorenzo assume you use RFC7217-only. If
you care about privacy, you should be using RFC4941, in which all
outgoiing connections would prefer the temporary addresses, rather than
the stable ones -- that's what RFC4941 is about, anyway.


> Again, I'm not sure if the intent is
> to address the concern, but if it is, I think something like the
> following will be necessary:
> 
> - clarify that this recommendation is only for environments where
>   address stability is needed

This is already noted in the current version of this document.
That said, the current specs (see RFC4941) essentially require stable
addresses 8temp addresses are generated along the traditional/stable ones).

Another way to put is s that this recommendation applies where hosts
would otherwise embed a link-layer address in the IID (this is stated in
the draft already, anyway).


> - clarify that this document assumes "link layer addresses" are
>   something permanent, such as MAC addresses that don't change
>   throughout the lifetime of the node using the hardware
> - update the requirement level and wording to existing RFCs. 

We don't really need to make assumptions about layer-2
addresses/identifiers -- we're standardizing what we do at layer-3.

The root of this and many other flaws is making assumptions at layer N
regarding things at layer (N-1) where there's no reason at all to make
such assumptions.


>   For
>   example, replaced text for RFC2462 provided in Section 6.1
> 
>    The Interface Identifier [AARCH] for an Ethernet interface MUST be
>    generated as specified in [RFCXXXX].
> 
>   is probably too strong, since this would invalidate any
>   implementation that doesn't implement or use RFCXXXX.  The same
>   sense of comment applies to all similar changes.

RFCXXXX essentially just says what the default algorithm should be.



> And, one other point I want to be addressed: in Section 4 it states:
> 
>    By default, DHCPv6 server implementations SHOULD NOT generate
>    predictable IPv6 addresses (such as IPv6 addresses where the IIDs are
>    consecutive small numbers).  [I-D.ietf-dhc-stable-privacy-addresses]
>    specifies one possible algorithm that could be employed to comply
>    with this requirement.  Another possible algorithm would be to select
>    a pseudo-random value chosen from a discrete uniform distribution,
>    while avoiding the reserved IPv6 Interface Identifiers [RFC5453]
>    [IANA-RESERVED-IID].
> 
>  I suggest just removing the second sentence.
>  ietf-dhc-stable-privacy-addresses is not a dhc wg item anymore due to
>  some controversy, and it's not clear what will happen to its
>  successor in the form of individual submission:
>  draft-gont-dhcpv6-stable-privacy-addresses-01
>  Since this sentence is only to show an example, just showing the
>  "another possible algorithm" would suffice.

I will check what the status of the corresponding draft-gont version of
the I-D is. To the extent that is possible, I'd keep it, since
ietf-dhc-stable-privacy-addresses leads to stable addresses, while a
simple randomization scheme doesn't.


> Finally, one minor editorial nit: in section 6.14
> 
>    for instance, using a method described in [8], to autoconfigure one
>    or more global unicast addresses.
> 
> there should be a 'cut here' line after this text.

Good grief!

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492