Re: [dhcwg] Comments on draft-ietf-dhc-relay-server-security-01

"Bernie Volz (volz)" <volz@cisco.com> Fri, 09 December 2016 16:27 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 340C71293D6 for <dhcwg@ietfa.amsl.com>; Fri, 9 Dec 2016 08:27:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.418
X-Spam-Level:
X-Spam-Status: No, score=-17.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, 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 9BJpXvWiU6-Y for <dhcwg@ietfa.amsl.com>; Fri, 9 Dec 2016 08:27:30 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A231294D2 for <dhcwg@ietf.org>; Fri, 9 Dec 2016 08:27:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4695; q=dns/txt; s=iport; t=1481300850; x=1482510450; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1ZDxXg+toYrBMg0DtDW6IB8Z3NsiufyC3tRhl9Nk6R0=; b=M2KzqYHlW5AbC7SKm/ReHNA2XzZQWYm0YclY/iVt6UKBjYF7W0/5OuFb MLloHf36VJSetmAzUn3CUJ8H6cohbY1/k9JvHWpL3wKTUVfK2ZFxrJpgX DDlkwtD+aB+OiQgb4Og+nfz4YcHcOAX+cmqt5ua+3c5CHCTt6Cto3Xlrp s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AVAQDw2kpY/5xdJa1dGQEBAQEBAQEBAQEBBwEBAQEBgzcBAQEBAR9agQYHjUKXFJUCggoeC4V4AoFvPxQBAgEBAQEBAQFiKIRoAQEBAwEBATg0CwUHBAIBCA4DBAEBHwkHJwsUCQgCBAENBQgTiEgIDqtpiyoBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYsZhDKFdwWVAIVrAZEXgXyEf4lTh2aGJYQNAR83MHEkhTVyiC+BDQEBAQ
X-IronPort-AV: E=Sophos;i="5.33,324,1477958400"; d="scan'208";a="358086421"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Dec 2016 16:27:29 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id uB9GRSmD015090 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Dec 2016 16:27:28 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 9 Dec 2016 10:27:28 -0600
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; Fri, 9 Dec 2016 10:27:28 -0600
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Tomek Mrugalski <tomasz.mrugalski@gmail.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: [dhcwg] Comments on draft-ietf-dhc-relay-server-security-01
Thread-Index: AQHSUjkhT9JOp3hHvECIavEM/yivMg==
Date: Fri, 09 Dec 2016 16:27:28 +0000
Message-ID: <0fa0546d1f0e4a2f951db3f7ed9c992b@XCH-ALN-003.cisco.com>
References: <147671242179.4527.12337010225582460227.idtracker@ietfa.amsl.com> <7e03afc26a08461e8308d5bdf985bed9@XCH-ALN-003.cisco.com> <ccbfe561da43469e8f894e2235c4b429@XCH15-06-08.nw.nos.boeing.com> <6a8f5646aedb44b5af85d7a45039eb02@XCH-ALN-003.cisco.com> <ed09c191c9a24989b38ec3db233e04d1@XCH15-06-08.nw.nos.boeing.com> <CA+dB4X4edhyJa+FR8phiJvQqi1wPU+eqsZ4=b4WHL7mFj-Dkgw@mail.gmail.com> <6c57d13d-7f48-67b5-fdad-4f230f46553f@gmail.com> <82f50590-1a44-a19d-3cb1-8ca2ce44f5d0@gmail.com>
In-Reply-To: <82f50590-1a44-a19d-3cb1-8ca2ce44f5d0@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.98.1.201]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/yxD4XH0F4aVA5pPeDhbNuelqnZY>
Cc: "Yogendra Pal (yogpal)" <yogpal@cisco.com>
Subject: Re: [dhcwg] Comments on draft-ietf-dhc-relay-server-security-01
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: Fri, 09 Dec 2016 16:27:32 -0000

I discussed some of these issues with Tomek a bit.

Regarding the non-normative language issue, we have a proposal as follows:
- We will move the existing (non-normative language) into draft-ietf-dhc-rfc3315bis as it is best we don't require (but recommend) IPsec for DHCPv6. This would also correct the open issue we have in the draft-ietf-dhc-rfc3315bis document regarding the algorithms to use.
- We will reword this draft (in the 02) to use the normative (i.e., MUST) language. That way, if a vendor claims to be in compliance with this (future) RFC, they would have to fully support IPsec for the relay to server communication.

> idnits report some issues with references. The text cites RFC2409, but it was obsoleted by RFC4306.

I could be wrong, but my understanding is that RFC 2409 documents IKEv1. This was indeed obsoleted by IKEv2 (which is actually specified in RFC 7296 now -- 4306 was obsoleted by 5996 which was obsoleted by 7296). The reason we have both here is that we are referencing IKEv1 and IKEv2. I'm not so sure if there is any value in specifying IKEv1 anymore given that this us now almost 20 years old. I think the best move might be to change " Accordingly, IKE [RFC2409] / IKE2 [RFC7296] with preshared..." to just be " Accordingly, IKE2 [RFC7296] with preshared ..." and drop RFC 2409 altogether.

> idnits also complains about a disclaimer for pre-RFC5378 work. I think this is ok, because you're providing an updated text from RFC3315.

Correct.

>The document is very specific as to what is updated in RFC3315 (section 21.1), but it's blurry regarding RFC1542 update. Is there any specific text that is being updated? If there is, please clearly state so. If there isn't, maybe this draft doesn't update RFC1542?

For 1542, it really "extends" it since that document was silent about IPsec ... so we can remove this.

And, I wonder if we should even say it updates 3315 as that might imply it is "required" -- and we'll be updating draft-ietf-dhc-rfc3315bis already, as mentioned above. Thus I propose to just remove that (in the meta data and in the text). 

I'll wait a few days to see if anyone has any comments to this thread before publishing the -02 revision.

- Bernie

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Tomek Mrugalski
Sent: Friday, December 09, 2016 9:58 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Comments on draft-ietf-dhc-relay-server-security-01

Hi,

There are my review of the draft. Apologies for sending it up so late, but I was travelling a lot recently. Finally got back home and catching up on my IETF duties.

Section 3 uses non-normative language like "it is highly recommended"
and "relay agents A and B must be configured to use IPsec". This is a standards track document, so why not normative language? I would very much prefer to have a normative text. When a vendor claims "my solution supports this RFC", what would it mean in its current form? The text is not normative, so technically someone could claim compliance and not do any of the IPsec at all.

The text in section 3 is also a bit conflicting. One part says "highly recommended" and the next sentence says "must". This should be consistent. My preferred way would be to go with "implementations conformant to this document MUST ...". This wording does not enforce vendors to implement it, but if they want to claim compliance, they really need to be able to do IPsec.

idnits report some issues with references. The text cites RFC2409, but it was obsoleted by RFC4306. If you have specific reasons why you reference the old text, please state it in the text explicitly.
Otherwise, just update the references.

idnits also complains about a disclaimer for pre-RFC5378 work. I think this is ok, because you're providing an updated text from RFC3315.

When you upload the next rev, make sure you bump up reference to
sedhcpv6 to -18.

The document is very specific as to what is updated in RFC3315 (section 21.1), but it's blurry regarding RFC1542 update. Is there any specific text that is being updated? If there is, please clearly state so. If there isn't, maybe this draft doesn't update RFC1542?

Other than the normative text clarification and 1542 update clarification, I think the draft is in very good shape. With my co-chair hat off, I support this work. With one more rev it should be ready to go.

Tomek

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg