[dhcwg] Review of draft-ietf-dhc-sedhcpv6-13
"Bernie Volz (volz)" <volz@cisco.com> Mon, 25 July 2016 19:04 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 61D2312D925; Mon, 25 Jul 2016 12:04:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.807
X-Spam-Level:
X-Spam-Status: No, score=-15.807 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 xU8b41klP0IZ; Mon, 25 Jul 2016 12:04:38 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B03C12D929; Mon, 25 Jul 2016 12:04:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31598; q=dns/txt; s=iport; t=1469473478; x=1470683078; h=from:to:cc:subject:date:message-id:mime-version; bh=j9FE3pqo69G0xXsGP6ywkQePE7xa2cIcgt3YjbrMRho=; b=NJL6hVMDHN28QJoQLgJvTcGQOKoGQumHq/eGejFBTNAu6nTx2bhFrz7H DTy040x1BXC9JoWYitHGYxR0BT8eDjwOBt279UUHo6wBoQ3p2kE9oNvaS zAJN+PYwS1dygzbRxA+6NYwr41Bbx96VdpZKWQYiJju3K07/tnmEG0Ju0 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BSAgD6YZZX/4oNJK1cgnFOVoECuGKBfIYdgUM4FAEBAQEBAQFdHAuEYycGTBIBQAE/JgEEDg2IKLV1AQEBAQEBAQECAQEBAQEBAQEBAQEcineEKgKFbwWIGYcoiWcBgTSHXYVWgXONU4ZgiUABHjaCCgEcgUyIOAEkBxh/AQEB
X-IronPort-AV: E=Sophos;i="5.28,420,1464652800"; d="scan'208,217";a="129787640"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Jul 2016 19:04:36 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u6PJ4aT9010382 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Jul 2016 19:04:36 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 25 Jul 2016 14:04:36 -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; Mon, 25 Jul 2016 14:04:35 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "draft-ietf-dhc-sedhcpv6@ietf.org" <draft-ietf-dhc-sedhcpv6@ietf.org>
Thread-Topic: Review of draft-ietf-dhc-sedhcpv6-13
Thread-Index: AdHmoExcXWlYnzeiQFeAnecnkzkN3g==
Date: Mon, 25 Jul 2016 19:04:35 +0000
Message-ID: <609b0e38a87945bf90c55ac8e084d638@XCH-ALN-003.cisco.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.198]
Content-Type: multipart/alternative; boundary="_000_609b0e38a87945bf90c55ac8e084d638XCHALN003ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/HN0X-4q4vk6RU0sT2uJxmuvqZRA>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: [dhcwg] Review of draft-ietf-dhc-sedhcpv6-13
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: Mon, 25 Jul 2016 19:04:41 -0000
Hi: Thanks for your continued efforts on this draft. Here are some comments from my reading of draft-ietf-dhc-sedhcpv6-13 (while reading it in preparation for Berlin IETF). I just now had some time to write them up. Section 1: o encryption between the DHCPv6 client and the DHCPv6 server in order to protect the DHCPv6 from pervasive monitoring. "the DHCPv6" is a bit odd here. Perhaps better to say to "product the DHCPv6 communication"? Section 4, 2nd paragraph: Perhaps mention that the bis document removes this support from the protocol specification? Section 5.2, 3rd bullet - "Timestamp is one of the possible implementation choices." (Choice -> choices) Section 5.3, 1st paragraph: - Algorithm is misspelled. - Last sentence is odd: "The same client and server SHOULD use the various algorithm in a single communication session." Not sure what you mean (client and server use the same algorithm in a single session)? Section 5.4, 1st paragraph: I think "can be applied for secure DHCPv6 deployment" should be "can be applied to secure DHCPv6 deployments"? And, in last paragraph, "issues with PKI deployment [to] be addressed"? Add "to". Section 6 - 2nd paragraph, "except [the] ORO option" (add "the"). - Note: We may want to discuss whether the other options related to requesting the certificate option should or should not be in the ORO (i.e., signature). I don't have a problem either way but we should probably be consistent with whatever we end up in 3315bis about which options should be in the ORO and which should not. - Is the "If the hash algorithm field is zero, the signature algorithm and hash algorithm are not separated" clear enough? I'm not exactly sure myself what this means exactly. - "The message transaction-id is used as the identifier" ... what exactly does this mean? Do future Encrypted-Query message (and hence Encrypted-Response) use this same transaction-id? Or how is this used? - On storage of the increasing-number option, I would expect that the client (and server) must keep track of this on a per server (per client) basis? So, a client perhaps should keep a record of this "forever", but how should servers manage this? When can they forget this information (when all leases have expired)? Or do they need to keep this for a period? - This is perhaps an issue for section 9.1.3, but I would think a 64-bit value would be better for the Increasing Number option? And, should this be modulo 2^32 (or 2^64) check to see if the current number if "higher" than the previous? Otherwise, what happens if the number wraps around? - For sentence at end of paragraph on page 9, "If contained number is lower than the stored number on the server, the server MUST drop the DHCPv6 message". This section is all about client behavior, so should this server processing be in elsewhere (or was this supposed to say client, not server)? Perhaps the how each (client or server) handles this increasing number option can be more generic and moved to a separate section (perhaps with the option definition)? You could then say client (or server) does increasing number check as documented in section 9.1.3? - While not wrong, saying "for the following network parameters configuration" is a bit odd. How about just "for the remainder of the client/server interaction"? (Or just drop it - i.e., client selects ONE). - On page 10, top paragraph ... changing "Server Identifier option MUST be contained" to "MUST be included"? Contained may confuse people to imply encapsulation of some kind? And, "to avoid the extra decryption for the DHCPv6 servers not for it" to "to avoid the need for other servers receiving the message to attempt to decrypt it"? - On page 10, 2nd paragraph. It is a bit odd for the server to send an ORO to the client. While the server can do that in a Reconfigure, it is not generally expected in a Reply. We should consider this carefully and it may be better to have the server send back a specific option (Client Certificate Request or something like that)? - On page 10, 3rd paragraph. See earlier about transaction-id and how this is used. Section 9.1.2 - Perhaps more should be said as to how signature of message is created (signature field set to all 0's when generating and validating)? - I think note about Authentication option in 3315 could be dropped (given that 3315bis has removed that)? There might be a question as to whether to "update" RFC 3315bis to say that if seDHCPv6 is used, the Reconfigure Key Authentication Protocol SHOULD or SHOULD NOT (?) be used. Perhaps there is also some work needed to define how Reconfigure is sent when seDHCPv6 is being used? After all, it would be nice to make use of this to secure it better. Section 9.1.3 - I think using OPTION_INCREASING_NUM[BER] would be better (add underscore is most important). This will use more consistent naming with current options. - Again see earlier for comments regarding: o Number of bits (consider 64) o How to compare (modulo 2^32 or 2^64 comparison to allow for rollover). See TCP RFC (793) section 3.3. Section 9.2 - See earlier about my comments about transaction-id and what this means and how it is used for this message as I think it is a bit more involved than normal? - Options field - I think "or" is wrong here and you want and (Server Identifier Option AND Encrypted-message)? This might be too simple a rewrite as it MUST contain the Encrypted-message option and MUST contain the Server Identifier if the message in the Encrypted-message option has a Server Identifier option - when sent from Client). Section 9.3: - Would changing "IncreasingNumFail" status to "ReplayDetected" be more meaningful? Other items: - As mentioned for 9.1.2, adding something about how server/client deal with Reconfigure would be useful. - Clarifying whether Rebind can use seDHCPv6 or not would be good? And how this is done (or not done)? It might be that when using this, one is stuck with Renew or having to return to Solicit instead of using Rebind? - "Coffee room" might be changed to "coffee shop"? - DHPCv6 is used in at least one place (instead of DHCPv6). And finally ... the text in the -12 (or was it -11) was more descriptive as to how the client especially should behave. While I think that was probably over specified, it now seems that perhaps it is a bit under specified (section 6)?
- [dhcwg] Review of draft-ietf-dhc-sedhcpv6-13 Bernie Volz (volz)
- Re: [dhcwg] Review of draft-ietf-dhc-sedhcpv6-13 Lishan Li