Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt

"Templin, Fred L" <Fred.L.Templin@boeing.com> Thu, 16 February 2017 19:01 UTC

Return-Path: <Fred.L.Templin@boeing.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 1899B129668 for <dhcwg@ietfa.amsl.com>; Thu, 16 Feb 2017 11:01:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 f__ll9HS1PtF for <dhcwg@ietfa.amsl.com>; Thu, 16 Feb 2017 11:01:17 -0800 (PST)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76EC112955E for <dhcwg@ietf.org>; Thu, 16 Feb 2017 11:01:16 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v1GJ1GJj031837; Thu, 16 Feb 2017 12:01:16 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v1GJ16XN031750 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 16 Feb 2017 12:01:06 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 16 Feb 2017 11:01:05 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Thu, 16 Feb 2017 11:01:05 -0800
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: 神明達哉 <jinmei@wide.ad.jp>
Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt
Thread-Index: AQHSglOjbTsgor1qYk63PeyrUa0poqFi1e9wgAgT1ID//3y08IAAjtcA//98D6CAAJdggIAA+dIg
Date: Thu, 16 Feb 2017 19:01:05 +0000
Message-ID: <fcb561d914634b25bea7e8ed3dce73ca@XCH15-06-08.nw.nos.boeing.com>
References: <148455739520.22478.14651605359463322132.idtracker@ietfa.amsl.com> <CAJ3w4NdCk8CBfNagcXT_VW_50+=xK=N7aB5HHqqn3stMt7Gy-Q@mail.gmail.com> <CAJE_bqf_AP9w1Bh_5kSB4YkLaV9XJ1tngufAiOMxVqQLwMruNA@mail.gmail.com> <aba52c11e462426bb3cbf66fcdca7783@XCH15-06-08.nw.nos.boeing.com> <CAJE_bqcG004FuUkKa0Xk1AiOo-bO4aHweYDpxMeeg+_=dSK6FQ@mail.gmail.com> <5c9ed55cfdc94456baf19740ba62910c@XCH15-06-08.nw.nos.boeing.com> <CAJE_bqeshAHmvGukto+PKs_skVPF5bnukvw8+5_04YEx_6m_sQ@mail.gmail.com> <8549b0b78c2e47e1a1839133dbc5b73a@XCH15-06-08.nw.nos.boeing.com> <CAJE_bqdvXwJjZJbwjC6eT6Fy6LQURDnmdBeP39g6WiaiPkJOiw@mail.gmail.com>
In-Reply-To: <CAJE_bqdvXwJjZJbwjC6eT6Fy6LQURDnmdBeP39g6WiaiPkJOiw@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: [137.136.248.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/1ChYef1n30GzpIeQGL7Np0AGj9c>
Cc: dhcwg <dhcwg@ietf.org>
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 16 Feb 2017 19:01:19 -0000

Hi Jinmei-san,

> -----Original Message-----
> From: jinmei.tatuya@gmail.com [mailto:jinmei.tatuya@gmail.com] On Behalf Of ????
> Sent: Wednesday, February 15, 2017 11:42 AM
> To: Templin, Fred L <Fred.L.Templin@boeing.com>
> Cc: dhcwg <dhcwg@ietf.org>
> Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ietf-dhc-sedhcpv6-20.txt
> 
> At Wed, 15 Feb 2017 18:51:26 +0000,
> "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:
> 
> > > > > It's probably better to describe the issue in
> > > > > sedhcpv6 with a reference to the RAAN draft as a possible future
> > > > > solution to it if and when it's adopted and standardized.
> > > >
> > > > If sedhcpv6 will not support an authentication-only mode, then it
> > > > can' t go forward until RAAN is adopted as a wg item. Otherwise,
> > > > an encryption-only sedhcpv6 w/o RAAN would break DHCPv6 PD.
> > >
> > > I personally don't think it a blocking issue for sedhcpv6, but, of
> > > course, the wg should decide it.
> >
> > Some uses of DHCPv6 PD require a secure exchange between the client and
> > server supported by an LDRA [RFC6221] that is in the same physical stack as
> > the server. The LDRA needs to peek into the server's Reply in order to discover
> > the delegated prefixes for the purpose of configuring routes. This all needs to
> 
> Where in RFC6221 is that need described?  From a quick re-read of the
> RFC I can't find it.  But in any case,

There is at least one use case where an RFC6221 LDRA resides in lower levels of
the stack that supports the DHCPv6 server and manages routing information
based on DHCPv6 PDs issued by the server. Because an unmodified DHCPv6
server cannot reach across the layers to manipulate the routing information,
it relies on the LDRA to do so. So, when sedhcpv6 is applied, there is a
requirement for RAAN options to allow the server to pass information to
 the LDRA.

> > work with a standards-compliant DHCPv6 server that implements both
> > sedhcpv6 and RAAN. Meaning that sedhcpv6 and RAAN would need to be
> > advanced together as standards.
> 
> I don't follow the logic of the final sentence.  I see this means
> sedhcpv6 at least initially wouldn't work for a particular scenario
> without RAAN.  But I don't think it automatically means sedhcpv6 can't
> be standardized with that limitation.  It would depend on how this
> incompatibility is critical for the overall purpose of sedhcpv6, and
> it doesn't seem to be that substantial - we can eventually standardize
> RAAN, and then update sedhcpv6 to fill the incompatibility.  I
> understand you have a different opinion, but to me it's a matter of
> opinion, not an only possible interpretation of this situation.  I'm
> not insisting my opinion should win, of course, and that's why I said
> the wg should decide it.
> 
> > Maybe better yet would be to bring the RAAN option into the sedhcpv6
> > spec itself?
> 
> For the same reason I don't think so, but, again, it should be up to
> the wg.

There is another example where a security-specific solution published
general-purpose options potentially useful for other purposes. In RFC3971
(the SEND spec) the Timestamp and Nonce options are defined. The assigned
numbers for these options occupy IPv6 ND Option Type values, and they are
therefore presumably applicable for IPv6 ND messaging even when SEND is
not in effect.

In the same fashion, if the RAAN option were incorporated into the
sedhcpv6 spec, it could be applied for other purposes even when
sedhcpv6 is not in effect. And, there would no longer be concerns for
a synchronized publication of multiple documents since both sedhcpv6
and RAAN would go forward together in a single package.

Thanks - Fred
fred.l.templin@boeing.com

> --
> JINMEI, Tatuya