Subject: Éric Vyncke's No Objection on draft-ietf-6man-rfc4941bis-11: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 20 Oct 2020 06:49:43 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-6man-rfc4941bis-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4941bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. It is an important topic and it
had stimulated a lot of hot discussions on the 6MAN list ;-)

I also appreciate the new section 3.7 where an admin can disable the mechanism.
Is there a reason why this document does not briefly compare its addresses with
RFC 7217 (stable address) ? It could be helpful for the reader.

Please find below a couple of non-blocking COMMENT points and nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Should link-local address generation also be considered here ? While the text
is clear about 'global', there is no clear indication that this document does
not apply to link-local addresses.

-- Section 1 --
First sentence, should "or by static configuration" be added ?

Should a reference to DHCPv6 be added ?

-- Section 1.2 --
Should IPPIX collectors also be mentioned in the first bullet list ?

On path attacker (really close to the node though !) can also do the
correlation based on the layer-2 address. Should this be added to the 2nd list ?

-- Section 2.2 --
I find the focus on DNS as 'rendez-vous' a little limiting. Why not mentioning
DNS-SD or SIP proxy or ... Perhaps, prefixing the explanation with "When DNS is
used" rather than using "machine would need a DNS name" (and BTW, it is also
limiting to refer to a 'machine' as per container IPv6 address could be used)

-- Section 3.1 --
Point 5) the 2nd and 3rd sentences are really repeating themselves and not
bringing a lot of value. Let's keep only one of the 2 or even none as the last
sentence is really clear.

-- Section 3.4 --
Should the text be clear on whether optimistic DAD may be used?

-- Section 3.6 --
Last paragraph "when an interface connects to a new (different) link, a new set
of temporary addresses MUST be generated immediately" seems to imply more than
1 temporary address with the use of 'set' and the plural form. Unsure whether
it is the right behavior (esp if no RA-PIO are received yet).

-- Section 6 --
If only this was not 'future work' but I agree, this is not up to this document
to specify such kernel API/implementation.

-- Section 9 --
Should the ingress filtering be also part of the section 4 (implications) ?

-- Section 11.2 --
I am afraid that RFC 7721 should be normative (introducing a downref though) as
it is used in section 1.1 (terminology).

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Oct 2020 13:15:48 -0300

Hello, Eric,

Thanks a lot for your comments! In-line....

On 20/10/20 10:49, Éric Vyncke via Datatracker wrote:
[....]
> RFC 7217 (stable address) ? It could be helpful for the reader.

Such topic has been discussed at length in RFC7721.  That's why we've 
referenced such document instead of trying to rehash the discussion.

> not apply to link-local addresses.

The idea of this document was to revise RFC4941, addressing shortcomings 
in said RFC. That's why the document remains the same wrt link-locals.

That said, link-locals are a different problem space. e.g., there's not 
much of a point in doing temporary addresses for link-locals if you 
don't randomize link-layer addresses. For some technologies, randomizing 
link layer addresses might force a network disconnect, etc.

> Should a reference to DHCPv6 be added ?

We should probably add a ref to DHCPv6, yes. And the other bit wouldn't 
hurt, either. So, how about:

OLD:
    Stateless address autoconfiguration (SLAAC) [RFC4862] defines how an
    IPv6 node generates addresses without the need for a Dynamic Host
    Configuration Protocol for IPv6 (DHCPv6) server.

NEW:

    Stateless address autoconfiguration (SLAAC) [RFC4862] defines how an
    IPv6 node generates addresses without the need for a Dynamic Host
    Configuration Protocol for IPv6 (DHCPv6) server [RFC8415] or manual
    configuration.

?

> Should IPPIX collectors also be mentioned in the first bullet list ?

WOuldn't that be somewhat included in bullet #1?

> correlation based on the layer-2 address. Should this be added to the 2nd list ?

I wouldn't add it, since this two-bullet list is mostly a non-exhaustive 
list of where correlation might happen based on the IPv6 addresses (note 
that the bulleted list also doesn't mention higher-layer IDs).

> limiting to refer to a 'machine' as per container IPv6 address could be used)

Good points!

So, how about s/machines/nodes/. and also

s/In such cases, the machine would need a DNS name for its use as a 
server/In such cases, the node might need..."

?

> sentence is really clear.

How about:

OLD:
    5.  By default, one address is generated for each prefix advertised
        by stateless address autoconfiguration.  The resulting Interface
        Identifiers must be statistically different when addresses are
        configured for different prefixes.  That is, when temporary
        addresses are generated for different autoconfiguration prefixes
        for the same network interface, the resulting Interface
        Identifiers must be statistically different.  This means that,
        given two addresses that employ different prefixes, it must be
        difficult for an outside entity to tell whether the addresses
        correspond to the same network interface or even whether they
        have been generated by the same host.

NEW:
    5.  By default, one address is generated for each prefix advertised
        by stateless address autoconfiguration.  The resulting Interface
        Identifiers must be statistically different when addresses are
        configured for different prefixes or different network
        interfaces. This means that, given two addresses that employ
        different prefixes, it must be difficult for an outside entity to
        tell whether the addresses correspond to the same network
        interface or even whether they have been generated by the same
        host.

> Should the text be clear on whether optimistic DAD may be used?

I'd believe the use of optimistic DAD is more of a general SLAAC thing 
than something related to temporary addresses. So I'd personally leave 
such discussion out.

> it is the right behavior (esp if no RA-PIO are received yet).

How about

OLD:
    Finally, when an interface connects to a new (different) link, a new
    set of temporary addresses MUST be generated immediately for use on
    the new link.  If a device moves from one link to another, generating
    a new set of temporary addresses ensures that the device uses
    different randomized interface identifiers for the temporary
    addresses associated with the two links, making it more difficult to
    correlate addresses from the two different links as being from the
    same node.

NEW:
    Finally, when an interface connects to a new (different) link,
    temporary addresses MUST be generated immediately for use on
    the new link.  If a device moves from one link to another, generating
    a new set of temporary addresses ensures that the device uses
    different randomized interface identifiers for the temporary
    addresses associated with the two links, making it more difficult to
    correlate addresses from the two different links as being from the
    same node.

Xor, one might be more specific as in:

NEW:
    Finally, when an interface connects to a new (different) link,
    existing temporary addresses for that interface MUST be
    eliminated, and new temporary addresses MUST be generated immediately
    for use on the new link, according to the algorithm in Section 3.4.
    If a device moves from one link to another, this will ensure that the
    device uses different randomized interface identifiers for the
    temporary addresses associated with the two links, making it more
    difficult to correlate addresses from the two different links as
    being from the same node.

Thoughts?

> to specify such kernel API/implementation.

Double-checking: No changes suggested here, right?

> Should the ingress filtering be also part of the section 4 (implications) ?

How about, in Section 4:

OLD:
    Network deployments are currently recommended to provide multiple
    IPv6 addresses from each prefix to general-purpose hosts [RFC7934].
    However, in some scenarios, use of a large number of IPv6 addresses
    may have negative implications on network devices that need to
    maintain entries for each IPv6 address in some data structures (e.g.,
    [RFC7039]).  Additionally, concurrent active use of multiple IPv6
    addresses will increase neighbour discovery traffic if Neighbour
    Caches in network devices are not large enough to store all addresses
    on the link.  This can impact performance and energy efficiency on
    networks on which multicast is expensive (e.g.
    [I-D.ietf-mboned-ieee802-mcast-problems]).

NEW:
    Network deployments are currently recommended to provide multiple
    IPv6 addresses from each prefix to general-purpose hosts [RFC7934].
    However, in some scenarios, use of a large number of IPv6 addresses
    may have negative implications on network devices that need to
    maintain entries for each IPv6 address in some data structures (e.g.,
    [RFC7039]).  For example, concurrent active use of multiple IPv6
    addresses will increase neighbour discovery traffic if Neighbour
    Caches in network devices are not large enough to store all addresses
    on the link.  This can impact performance and energy efficiency on
    networks on which multicast is expensive (e.g.
    [I-D.ietf-mboned-ieee802-mcast-problems]). Additionally, some network
    security devices might incorrectly infer IPv6 address forging if
    temporary addresses are regenerated at a high rate.

Thoughts?

> it is used in section 1.1 (terminology).

One possible alternative would be to copy the definitions of such terms 
to Section 1.1, and note that they have been borrowed from RFC7721.

Thoughts?

Thanks!

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

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 21 Oct 2020 13:57:55 +0000

Buenos dias Fernando,

As you know, all my COMMENT points were non-blocking; therefore, I really appreciate your replies and your proposed changes (I agree with all of them + one preference for an alternative text) => this should improve the document quality!

See inline for EV> for any additional comments. I have removed all lines where we are in agreement.

Regards

-éric

-----Original Message-----
From: Fernando Gont <[email-masked]>
Date: Tuesday, 20 October 2020 at 18:18
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Ole Trøan <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-6man-rfc4941bis-11: (with COMMENT)

    Hello, Eric,

 

EV> I agree that this document should not spend too much time in the comparison; but, when doing my IESG review I failed to see *where* in the document is the reference to this discussion in RFC 7721.

...%<....%<......  

EV> I still believe that it is worth mentioning even if only to avoid the EUI-64 based on MAC address for link-local (done in most OS AFAIK :-) ) but also keeping the same LLA when randomizing the MAC address is also kind of defeating the layer-2 privacy. We could talk for ever on this topic of course but my I kindly suggest to change the title of this document into " Temporary *Global* Address Extensions" (the abstract is clear about the coverage) and adding a few words on the importance of LLA ?

...%<....%<.....

EV> up to you as authors, but for me the collector (== receive of IPFIX records) is not the monitor (== the node in bullet #1)

    How about

    OLD:

    NEW:

    NEW:

    Thoughts?

EV> I prefer the 2nd alternative but the 1st one is also good IMHO

---

From: Fernando Gont <[email-masked]>
Date: Wed, 21 Oct 2020 11:38:41 -0300

Bonjour, Eric,

On 21/10/20 10:57, Eric Vyncke (evyncke) wrote:
> Buenos dias Fernando,
> 
> As you know, all my COMMENT points were non-blocking; therefore, I
> really appreciate your replies and your proposed changes (I agree
> with all of them + one preference for an alternative text) => this
> should improve the document quality!

I'm all for improvements! -- thanks for your suggestions!

[....]
> On 20/10/20 10:49, Éric Vyncke via Datatracker wrote: [....]
> 
>> I also appreciate the new section 3.7 where an admin can disable
>> the mechanism. Is there a reason why this document does not briefly
>> compare its addresses with RFC 7217 (stable address) ? It could be
>> helpful for the reader.
> 
> Such topic has been discussed at length in RFC7721.  That's why
> we've referenced such document instead of trying to rehash the
> discussion.
> 
> EV> I agree that this document should not spend too much time in the
> comparison; but, when doing my IESG review I failed to see *where* in
> the document is the reference to this discussion in RFC 7721.

Do you mean we might want to reference RFC7721 from Section 3.7?

> ...%<....%<......
>> 
>> Should link-local address generation also be considered here ?
>> While the text is clear about 'global', there is no clear
>> indication that this document does not apply to link-local
>> addresses.
> 
> The idea of this document was to revise RFC4941, addressing
> shortcomings in said RFC. That's why the document remains the same
> wrt link-locals.
> 
> That said, link-locals are a different problem space. e.g., there's
> not much of a point in doing temporary addresses for link-locals if
> you don't randomize link-layer addresses. For some technologies,
> randomizing link layer addresses might force a network disconnect,
> etc.
> 
> EV> I still believe that it is worth mentioning even if only to avoid
> the EUI-64 based on MAC address for link-local (done in most OS AFAIK
> :-) ) but also keeping the same LLA when randomizing the MAC address
> is also kind of defeating the layer-2 privacy. 

The thing here is that it would be RFC8064/RFC7217 (rather than RFC4941) 
affecting this case. i.e., if you do MAC address randomization, , you 
probably want to make sure that your stable addresses are ... *not* 
stable :-).   Put another way: even if this document (rfc4941bis) was 
suggesting the generation of temporary addresses for link-local 
addresses, the potential problem in this respect is that the node might 
be doing RFC7217 for link-locals, in which case you'd have both stable 
link-locals (which wouldn't change, and would defeat MAC address 
randomization), plus the temporary link-local addresses.

> We could talk for ever
> on this topic of course but my I kindly suggest to change the title
> of this document into " Temporary *Global* Address Extensions" (the
> abstract is clear about the coverage) and adding a few words on the
> importance of LLA ?

To make things more complicated :-), this document does accommodate 
temporary addresses for ULAs (it even mentions them explicitly in one 
example), which are global (globally unique), but not globally-reachable.

Thoughts?

> ...%<....%<.....
> 
>> -- Section 1.2 -- Should IPPIX collectors also be mentioned in the
>> first bullet list ?
> 
> EV> up to you as authors, but for me the collector (== receive of
> IPFIX records) is not the monitor (== the node in bullet #1)

My bad! -- Will do.

>> -- Section 3.6 -- Last paragraph "when an interface connects to a
>> new (different) link, a new set of temporary addresses MUST be
>> generated immediately" seems to imply more than 1 temporary address
>> with the use of 'set' and the plural form. Unsure whether it is the
>> right behavior (esp if no RA-PIO are received yet).
> 
> How about
[...]
> NEW: Finally, when an interface connects to a new (different) link, 
> existing temporary addresses for that interface MUST be eliminated,
> and new temporary addresses MUST be generated immediately for use on
> the new link, according to the algorithm in Section 3.4. If a device
> moves from one link to another, this will ensure that the device uses

Will apply the second one, then!

Thanks!

Cheers,

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 23 Oct 2020 14:38:21 +0000

Fernando

Sorry for belated reply... See in-line for EV-2>

Enjoy your W-E ;-) (my European Friday is mostly over now...)

-éric

-----Original Message-----
From: Fernando Gont <[email-masked]>
Date: Wednesday, 21 October 2020 at 16:39
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Ole Trøan <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-6man-rfc4941bis-11: (with COMMENT)

    Bonjour, Eric,

    [....]

EV-2> Not really in section 3.7. I put the two sentences in a single paragraph but they are not actually linked together. RFC 7721 should be commented briefly in the introduction or somewhere as it is important to mention the differences.

EV-2> of course if you do MAC randomization you should also do IPv6 temporary, I guess we agree. Perhaps, I was not clear. The MAC and IPv6 (global _and_ link-local) addresses randomizations are orthogonal but we should aim for doing both. So, it is worth stating this in the document. BTW, I am not too in favor of multiple LLA (not even sure whether it is 'allowed')

EV-2> I also consider 'ULA' as 'global' for this document, I was really wondering about LLA

    Thoughts?

    My bad! -- Will do.

    [...]

    Thanks!

    Cheers,