Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

"Bernie Volz (volz)" <volz@cisco.com> Wed, 14 June 2017 20:14 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680F212EB3C for <dhcwg@ietfa.amsl.com>; Wed, 14 Jun 2017 13:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.824
X-Spam-Level:
X-Spam-Status: No, score=-11.824 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GUARANTEED_100_PERCENT=2.699, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0onflUbveVGz for <dhcwg@ietfa.amsl.com>; Wed, 14 Jun 2017 13:13:58 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84F1712EB3B for <dhcwg@ietf.org>; Wed, 14 Jun 2017 13:13:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17694; q=dns/txt; s=iport; t=1497471238; x=1498680838; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mb2vlSkz6ksywZjZZH7vbnQYBiQNIsFakySr1mWTiCo=; b=aBzbDYHLxB3KgPd7m7HUOjQ8gWf4yWNh6dQgE5PGDVaNTKiqIntN2p95 d6beviMJTZFTnT0pJ/m1jWv6gmf6Msta56KnBSnMdhlcjKpLePlwXhCv7 HjGrAmtsLTrfTMKZVYwOcMwi5W5HzLi2Cd3EnWIfxDiBifWAA6K/W8ef6 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C3AADPl0FZ/5tdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1iBbweDb4oYkXaDI4UIjVuCEYYkAhqCOD8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQEDIxE+BwwEAgEIEQQBAQMCIwMCAgIfERQBCAgBAQQOBQiKDAMVrWOCJ?= =?us-ascii?q?oc5DYN+AQEBAQEBAQEBAQEBAQEBAQEBAQEBHYELhzYBgyGBPYEbgVsTCgQ8gmy?= =?us-ascii?q?CYQWJRohMi3o7Ao5qhF2CEJACiRmCNYkrAR84gQp0FUiFDByBZnaHPIEygQ0BA?= =?us-ascii?q?QE?=
X-IronPort-AV: E=Sophos;i="5.39,341,1493683200"; d="scan'208";a="435505248"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2017 20:13:57 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v5EKDvGL008398 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Jun 2017 20:13:57 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 14 Jun 2017 15:13:56 -0500
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Wed, 14 Jun 2017 15:13:56 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: =?utf-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
CC: "dhcwg@ietf.org" <dhcwg@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017
Thread-Index: AdLI0aZmS0Xgn7D6S1m3YZ8hZorkbQLWe7cAAIVlReABPEJZgAKF0ckg
Date: Wed, 14 Jun 2017 20:13:56 +0000
Message-ID: <7f897317e79e4576bebc772c45edb703@XCH-ALN-003.cisco.com>
References: <8418750467ae490ea50e342380a565be@XCH-ALN-003.cisco.com> <CAJE_bqcMLz7JBaSA2h6_xiB3AyxQzkMGfL87WeqKzwxKoSeD-w@mail.gmail.com> <67c761541b674041ba5a2eb0b9ea41fa@XCH-ALN-003.cisco.com> <CAJE_bqeBg-va5zr=4HNrecECg_mmGpWECAc8V5UL0ckhHnJcNQ@mail.gmail.com>
In-Reply-To: <CAJE_bqeBg-va5zr=4HNrecECg_mmGpWECAc8V5UL0ckhHnJcNQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.131.33.27]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/UrbyDa-S4X9Pu-7eq4q5A5Yyuvg>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Jun 2017 20:14:01 -0000

Jinmei:

We are working to get the -09 version out before the July 3rd IETF-99 cutoff. And, I think we're waiting on text for you regarding one item:

-- start
>>> - Section 20.22
> [...]
>>> This choice of valid/preferred lifetime in an IA prefix and the
>>> (possible) relationship between them and those lifetimes advertised 
>>> in the delegated site do not make perfect sense to me. [...]
>
> I don't think the revised version addresses the main point.  The new 
> text simply avoids saying specifics about these lifetimes, but then 
> it's even more unclear about what these lifetimes are (especially the 
> preferred lifetime).
>
> BV> Unless you provide text, I think we'll leave this alone as
> mentioned earlier we feel that this document is not the one that 
> should describe how these lifetimes are to be used.

This is not just about wording.  It's about actual protocol behavior, and I don't even know if we have common consensus on it.  I also think we can't simply ignore the issue by being silence, since it could result in a bad situation like a site keeps advertising a prefix in RA as a preferred one even when it's already "deprecated" or even "invalidated" in terms of prefix delegation.  I'll see if I can offer something more concrete, but I'd like to raise it as a possible blocking issue.
-- end

For reference this is section 21.22 in the -08 version.

And, added a few comments below (BV>) as to actions we did or did not take.

Again, thanks for the suggestions and review!

- Bernie

-----Original Message-----
From: jinmei.tatuya@gmail.com [mailto:jinmei.tatuya@gmail.com] On Behalf Of ????
Sent: Thursday, June 01, 2017 2:53 PM
To: Bernie Volz (volz) <volz@cisco.com>
Cc: dhcwg@ietf.org; Ralph Droms <rdroms.ietf@gmail.com>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

On Fri, May 26, 2017 at 10:56 AM, Bernie Volz (volz) <volz@cisco.com> wrote:

>>> - I'm okay with deprecating the delayed authentication protocol, but 
>>> I'm not sure if it's okay to ship the spec with no built-in 
>>> authentication (the reconfigure key protocol is very limited and too 
>>> weak).
>
> BV> We are working on sedhcpv6 but this has not been so simple and quick. And, DHCPv6 is in use and deployed today without an authentication protocol. There are other actions that can be taken such as stated in section 22:
>
>    Many of these rogue server attacks can be mitigated by making use of
>    the mechanism described in [RFC7610].

I personally wouldn't argue that it's a blocking issue, and, to be clear, I'm not requesting sedhcpv6 be specified as *the* authentication protocol in rfc3315bis.  But I'd suggest chairs to explicitly leave notes about the point for security ADs when the doc is sent to the IESG.

BV> We discussed with Ralph and he plans to note it in the shepherd document.


>>> - Section 5.2
>>>   the "stateful address autoconfiguration protocol" for IPv6 [RFC2462].
>>>  s/RFC2462/RFC4862/.
>
> and there are still more references to RFC2462.
>
> BV> This is by design. RFC4862 does not mention the M & O bits so we
> can't reference that RFC. We documented the reason for this in 
> Appendix A:

I believe at least the reference to RFC2462 in Section 6.2 is not really appropriate:

   This model of operation was the original motivation for DHCP and is
   the "stateful address autoconfiguration protocol" for IPv6 which is
   discussed in [RFC2462].

Simply because RFC4862 doesn't use the term "stateful address autoconfiguration protocol" doesn't make this text appropriate.
RFC2462 used the term "stateful address autoconfiguration protocol"
just because DHCPv6 wasn't fully standardized at that time.  RFC4862 just replaced it with the term "DHCPv6".  If you want suggested text, my suggestion is simply remove the second half the sentence:

   This model of operation was the original motivation for DHCP.  It
   is appropriate for situations where stateless address
   autoconfiguration alone is insufficient or impractical, e.g.,
   because of network policy, additional requirements such as dynamic
   updates to the DNS, or client-specific requirements.

As for the references to RFC2462 due to M/O RA flags, I still think it can be rather misleading.  The sad fact is that M/O flags are dead - all previous attempts at the 6man wg of making them workable failed, and different implementations handle these flags very differently.
You simply cannot rely on these flags, and it doesn't make sense to me newer protocol documents like rfc3315bis still talk about them simply because its predecessor talked about them.

BV> OK, cleaned up text as recommended and there are no more references to 2462.


Now, if you want suggested text, this is my suggestion:

Section 18
OLD
   A client initiates a message exchange with a server or servers to
   acquire or update configuration information of interest.  A client
   has many reasons to initiate the configuration exchange:
...
   3.    when required by Stateless Address Autoconfiguration (as
         defined in [RFC2462] Section 5.2),
NEW1 (my preferred suggestion) remove this bullet
NEW2
   3.    when Router Advertisement indicates DHCPv6 is available for
         address configuration (see [RFC4861] Section 4.2)

BV> Used NEW2. There are probably existing implementations that follow the old recommendations.

(unrelated) side note: there's a duplicate bullet #4 here.

Section 18
OLD
   The client has many reasons to initiate the configuration exchange:
...
   3.    when required by Stateless Address Autoconfiguration (as
         defined in [RFC2462])
NEW1 (my preferred suggestion) remove this bullet
NEW2
   3.    when Router Advertisement indicates DHCPv6 is available for
         address configuration (see [RFC4861] Section 4.2)

BV> This second version of the list was removed. I think it was left behind by accident during an editing session.

Section 18.2.1
OLD:
   In the case of a Solicit message transmitted when DHCP is initiated,
   the delay gives the amount of time to wait after IPv6 Neighbor
   Discovery causes the client to invoke the stateful address
   autoconfiguration protocol (see section 5.5.3 of [RFC2462]).  This
   random delay desynchronizes clients which start at the same time (for
   example, after a power outage).

NEW: I actually suggest removing this paragraph.  Especially given M&O flags are "dead", I don't see a strong reason for retaining it in addition to its previous paragraph (which also talks about the delay and for the case of power outage).  If we still want to say something about the interaction with RA, my suggestion is to revise the previous paragraph as follows:

   The first Solicit message from the client on the interface SHOULD be
   delayed by a random amount of time between 0 and SOL_MAX_DELAY.  This
   mechanism is essential for devices that are not battery powered, as
   they may suffer from power failure.  After recovering from a power
   outage, many devices may start their transmission at the same time.
   This is much less of a concern for battery powered devices.  This
   random delay also helps descynronize clients which start DHCPv6
   session by seeing it available in Router Advertisement messages
   (see Section 4.2 of [RFC4861]).

BV> I used this suggested paragraph.

Note that if all of the above suggestions are adopted, there will be no reference to RFC2462.  So you can also remove it from the Refereneces section.

BV> Correct, they are now all gone.

>>> - Section 5.4
>>> [...] the requesting router MUST set the valid lifetime in those 
>>> advertisements to be no later than the valid lifetime specified in 
>>> the IA_PD Prefix option.
>>>  "no later than" sounds awkward as the lifetime is a duration, not  
>>> a particular point in time.
>
> This is simply open as before.
>
> BV> Unless you suggest some text, we will leave this be. I think the
> point of the text is rather clear.

If you want suggestion, this can be fixed easily:
NEW:
 [...] the requesting router MUST set the valid lifetime in those  advertisements to be no larger than the valid lifetime specified in  the IA_PD Prefix option.

i.e., s/later/larger/

BV> Done.

>>> - Section 8.1
> [...]
>
>>> site-scope unicast address has been deprecated.  Also, the phrase 
>>> "global or ULA" is awkward as ULA is a global (scoped) address.
>
> The 08 version states:
>
>                            This is typically a globally unique
>                            address or unique local address (ULA)
>                            [RFC4193],
>
> This is still awkward to me, since in a sense ULAs are also "globally unique" (even if the uniqueness is not 100% guaranteed).  Personally I'd simply avoid mentioning ULAs unless there is a specific to reason to refer to it in the context (and I don't see such a reason here), but if we want to refer to ULAs here, I'd say, e.g., "a global address (including unique local addresses)".
>
> BV> Unless you suggest some text, we will leave it be. I don't see that this is necessarily in conflict - yes, ULA is in the "global address space". But I also think it adds value to explicitly mention ULAs here as otherwise someone could confuse the subtly that ULA is allowed.

I've already suggested text (I admit the point may be a bit pedantic, though).

BV> We decided to say "global address (including unique local addresses, [RFC4193])" or something very close to that.

>>> - Section 17.1.10.1
>>> "no later than" sounds awkward for these lifetimes (see also Sec 
>>> 5.4).
>
> BV> See above.

Ditto:-)

BV> Done.

>>> - Section 17.1.10.1
> [...]
>>> Specifically, the bullet description seems to lead to multiple 
>>> separate state machines for different bindings.
>
> BV> I believe we addressed this by other text in the document - for example, see in 18.2.4 the following text:
>
>    The server controls the time at which the client should contact the
>    server to extend the lifetimes on assigned leases through the T1 and
>    T2 parameters assigned to an IA.  However, as the client Renews/
>    Rebinds all IAs from the server at the same time, the client MUST
>    select a T1 and T2 time from all IA options, which will guarantee
>    that the client will send Renew/Rebind messages not later than at the
>    T1/T2 times associated with any of the client's bindings (earliest
>    T1/T2).

Hmm...this is one of the things why I can't be confident about this spec without actually trying to implement it from the text.  But I don't have enough time to check if the concern is addressed in the entire context, I'll simply give up with it.

BV> We believe we are ok with this as is.

>>> - Section 20.22
> [...]
>>> This choice of valid/preferred lifetime in an IA prefix and the
>>> (possible) relationship between them and those lifetimes advertised 
>>> in the delegated site do not make perfect sense to me. [...]
>
> I don't think the revised version addresses the main point.  The new 
> text simply avoids saying specifics about these lifetimes, but then 
> it's even more unclear about what these lifetimes are (especially the 
> preferred lifetime).
>
> BV> Unless you provide text, I think we'll leave this alone as
> mentioned earlier we feel that this document is not the one that 
> should describe how these lifetimes are to be used.

This is not just about wording.  It's about actual protocol behavior, and I don't even know if we have common consensus on it.  I also think we can't simply ignore the issue by being silence, since it could result in a bad situation like a site keeps advertising a prefix in RA as a preferred one even when it's already "deprecated" or even "invalidated" in terms of prefix delegation.  I'll see if I can offer something more concrete, but I'd like to raise it as a possible blocking issue.

BV> See top of the message and main reason for sending it!

>>> - Section 20.23
> [...]
>>> The expected usage is not very clear to me here.  Is it intended to 
>>> be used for Advertise and apply the value to the ongoing 
>>> Solicit-Advertise exchange?  Or is it mainly intended to be used for 
>>> a possible subsequent restart of a DHCPv6 session?
[...]
> BV> You original question was I think about why SOL_MAX_RT MUST be
> in ORO. It MUST be as per RFC 7083 so that clients can get updated 
> SOL_MAX_RT values. And, yes, the idea is that the Advertise with the 
> SOL_MAX_RT value is used (even if it offers no leases) so that the 
> client applies this value for any future requests. I don't see the 
> need for this to be spelled out?

I'd think it's worth explaining, but I'll leave it to you.

BV> We think we're OK with this as is.

--
JINMEI, Tatuya