Re: [mif] MIF draft issues
Suresh Krishnan <suresh.krishnan@ericsson.com> Wed, 04 November 2015 14:26 UTC
Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1F01B306E; Wed, 4 Nov 2015 06:26:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 0lFFXCfOOTE0; Wed, 4 Nov 2015 06:25:59 -0800 (PST)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4D81B306A; Wed, 4 Nov 2015 06:25:59 -0800 (PST)
X-AuditID: c6180641-f792c6d00000686a-e0-5639a805c719
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 85.0C.26730.508A9365; Wed, 4 Nov 2015 07:39:02 +0100 (CET)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Wed, 4 Nov 2015 09:25:57 -0500
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
To: "mif-chairs@ietf.org" <mif-chairs@ietf.org>, "cyrus@openwrt.org" <cyrus@openwrt.org>
Thread-Topic: [mif] MIF draft issues
Thread-Index: AQHRFv5nROJZ0uoSVk+SmDFBENDXQZ6L63Rr
Date: Wed, 04 Nov 2015 14:25:56 +0000
Message-ID: <E87B771635882B4BA20096B589152EF63AA170F5@eusaamb107.ericsson.se>
References: <5639FD5B.5040507@openwrt.org>
In-Reply-To: <5639FD5B.5040507@openwrt.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_E87B771635882B4BA20096B589152EF63AA170F5eusaamb107erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZXLonXJdthWWYwaWpfBbnDm9isji1/BmL RdeeG0wOzB5Llvxk8tiyOCOAKYrLJiU1J7MstUjfLoErY3vPAtaClVsZK/YuymhgXDqVsYuR k0NCwETi/boF7BC2mMSFe+vZuhi5OIQEjjBK3N3SygSSEBJYxigxv1cTxGYDatiw8zNYXEQg SuLs9xYwm1lAUWLtn68sILawgLLEtGvH2CBqVCR+rJ4CVW8k8ejQezCbBSi+dvV9sBpeAV+J p+++s0Ds0pJYtHMOWJxTQFviyKPtYMcxAh33/dQaqF3iEreezGeCOFpAYsme88wQtqjEy8f/ WCFq8iV+7P7FCDFfUOLkzCcsExhFZiFpn4WkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZC Fl/AyL6KkaO0OLUsN93IcBMjMI6OSbA57mBc8MnyEKMAB6MSD++GyRZhQqyJZcWVuYcYJTiY lUR4TU9ZhgnxpiRWVqUW5ccXleakFh9ilOZgURLnnTfjfqiQQHpiSWp2ampBahFMlomDU6qB cY3x2gax81mKtyOfMe+/E3P/jvfrB8+OvbI6+CDUMsEl8pTbdYGu3qsPRItf9Ouel9+4U+Tb /B4L5VzR39csMn6Xbt28ukaW2fGp7eNvp676HS3pVPKe8t/Ldlvm/mz2M0EWp1RtFHJm+LZ9 451Sk1d4SO3b+dutF9OvpUn8Za5YHx/A5LrERYmlOCPRUIu5qDgRANr2KZGfAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/azWpY1HU39QRNGn8Wx_E1_0MjGM>
Cc: "mif@ietf.org" <mif@ietf.org>
Subject: Re: [mif] MIF draft issues
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Nov 2015 14:26:04 -0000
Hi Steven, Thanks for your review. I will create an issue tracker to keep track of each issue you raised. There are some decisions the WG needs to make to proceed further with some of the changes required and I hope we can get some direction during and after this Friday's session. Thanks Suresh -----Original Message----- From: Steven Barth [cyrus@openwrt.org] Received: Wednesday, 04 Nov 2015, 9:43PM To: mif-chairs@ietf.org [mif-chairs@ietf.org] CC: mif@ietf.org [mif@ietf.org] Subject: [mif] MIF draft issues As requested in the DT meeting, here is a summary of the issues and from my reviews of the 3 "core drafts". To be honest I'm totally put off by the lack of responsiveness from all draft authors and will probably not do any more reviews here if there isn't a significant improvement on this matter. Cheers, Steven *** Conceptual (apply to all 3) *** 1. Lack of metadata Neither draft defines any kind of metadata or seems to consider any addition of it. Currently only opaque identifiers are used which must be previously acquired via other means to understand a PVD, i.e. it is not possible to convey: * if the PVD offers intenet access or not * if use of the PVD is metered or not * general constraints of using the PVD * even a human readable name *** mpvd-id *** It is not clear why this multitude of types is needed. If it is kept there should be some guidance on why it is not possible to simply use one unique type format like FQDN or a reasonably small unique fixed-length ID based on e.g. a PEN or IPv6-prefix assigned to the PVD owner followed by a small localy significant ID. 1+3. "Any source that does not provide either guaranteed or probabilistic uniqueness is probably not a good candidate for identifying provisioning domains." - I don't see how type "UTF-8 string" fits this definition. Abstract: the abstract claims the document "describes several methods of generating identification information for provisioning them". However I can't find that anywhere, I can only find a TLV-definition. 3: It is unclear what the actual format for the specified id-types is, at least for some of them, e.g. is the UUID in binary format or string-representation? FQDN is unclear as well, RFC1035 never mentions this abbreviation and also given it would be clear it still doesn't say if it uses the textual or label sequence representation? 4: Security Considerations do not apply at all. Your abstract says: "This document describes several methods of generating identification information for provisioning them and a format for carrying such identification in configuration protocols." however your security considerations explain attacks on (2 specific) protocols the TLV might be used in instead of security implications of using different types of identifiers e.g. like security considerations of UUID in RFC4122 5: IANA Section lacks policy for further allocations (see RFC5226) 3: "The configuration protocol used and its extensions are meant for that purpose [I-D.ietf-mif-mpvd-dhcp-support] [I-D.ietf-mif-mpvd-ndp-support]." - This sentence does not parse. *** ndp-support *** 1. It is unclear what to do with enclosed TLVs Section 5 defines what TLVs can and cannot be enclosed, however it is unclear how any enclosed TLVs are treated or whether and in what respect they are treated differently from if they would occur on the top-level. To be more concrete, what should a PVD-aware node do if it receives e.g. a PIO with A=1 inside a PVD_CO? Assign an address, perform DAD and then use it at will as defined in RFC 4862 ('Initially, an address is "preferred", meaning that its use in arbitrary communication is unrestricted.'). If all PVD SLAAC addresses are unrestricted what is the point of the exercise of the container? Supposedly similar things could be said about RDNSS, DNS-Search or other enclosed PVD types as well. 2. The solicitation mechanism using RS seems underspecified. It is not mentioned how the router should react to receiving a PVD CO / ID (e.g., include PVD-information only in the specific reply, or in all subsequent unsolicited RAs for an undefined period of time, ...). This is unclear esp. considering that hosts do not send RS regularly and the draft does not place an such requirements on hosts. The draft also does. Also it is unclear what the semantic difference between an RS with a PVD_ID inside a PVD_CO (with S=0) and an RS with a PVD_ID is and if there is none, what the reasoning for this redundancy is. 3. Hosts not supporting security cannot use secured PVD information. The length of the fields "Key Hash" and "Digital Signature" depend on the meaning of the field "Name Type" and are thus unskippable in general. 4. Signature calculation is unclear. The signature generation defined in RFC 3971 includes several other components (e.g. a CGA message type tag, a kind of pseudoheader, etc.) besides the actual NDP message being signed. It is unclear is your signature mechanism uses the same header fields or if the intention was just to use a plain RSASSA-PKCS1-v1_5 over the PVD_CO. 5. Mandatory to implement security seems outdated. The use of SHA-1 as only mandatory hash for key identification and as only defined hash for signatures seems a bit outdated these days especially in the light of recent advancements in its cryptanalysis. This seems especially problematic since there does not seem to be a way to signal the use of a different signature algorithm. 6. Replay Protection seems not adequately addressed. No specific mechanism is defined. It is suggested to use either timestamps or a nonce of an undefined format. However nonces do not seem particularly effective for unsolicited RAs and timestamps rely on accurate wall-clocks on both server and client side which is not mentioned. Also the suggested use of SeND would not provide replay protection for the PVD_CO however only for the whole RA being secured. 7. It is unclear how TLVs are enclosed in the PVD_CO The PVD_CO definition does not mention where TLVs are enclosed, i.e., before or after either Header, Key Hash, Digital Signature, Padding etc. 8. General Design is very space-intensive. Notably for support of both PVD-aware and unaware nodes enclosed TLVs need to occur both inside and outside of the container. Also if some enclosed TLVs apply to multiple PVDs they will be duplicated in different containers. In addition in-band security and signatures can easily increase the size of the overall messages very much, especially since RSA is the only defined scheme. 9. "The PVD identity option (PVD_ID) is used to explicitly _identity_ a provisioning domain." *** dhcp-support *** 0. This draft cannot be freely implemented in open source software. 1. It is unclear what to do with enclosed TLVs The reasoning is similar to the NDP TLVs in the other draft: The draft defines what TLVs can be enclosed but not how the enclosing affects the meaning of the TLVs, e.g. is an enclosed RDNSS-TLV or an IAAddr still generally applicable for all purposes and if not how is the meaning changed specifically? This is especially problematic since the draft does not disallow any TLVs from being inside the container, see also 2. 2. It is unclear how this draft interacts with the Identity Association state machines defined in RFC3315 i.e. how are IAs and addresses and prefixes actually enclosed here. The draft needs to specify clearly what happens to identity associations / address assignments and how they are associated to PVDs especially taking into account the possibility of having multiple IAs (e.g. IA_NA and IA_PD) or addresses from different PVDs in the same IA. See also 3. 3. It is unclear where the PVD container option can occur. Is it restricted to only occur on the top-level or can it occur also inside other containers (e.g. Identity Associations), if the latter is true, how does it affect what options can be enclosed in it. 4. Signature calculation is unclear. The signature generation defined in RFC 3971 includes several other components (e.g. a CGA message type tag, a kind of pseudoheader, etc.) besides the actual NDP message being signed. It is unclear if your signature mechanism uses the same header fields or if the intention was just to use a plain RSASSA-PKCS1-v1_5 over the PVD container. 5. Mandatory to implement security seems outdated. The use of SHA-1 as only mandatory hash for key identification and as only defined hash for signatures seems a bit outdated these days especially in the light of recent advancements in its cryptanalysis. This seems especially problematic since there does not seem to be a way to signal the use of a different signature algorithm. 6. Replay Protection seems not adequately addressed. No specific mechanism is defined. It is suggested to use either timestamps or a nonce of an undefined format. Also the suggested use of DHCPv6 AUTH would not provide replay protection for the PVD container but for the whole DHCPv6 message being secured. 7. Contradicting requirements language #1: "The PVD container option SHOULD contain at most one (i.e. zero or one) OPTION_PVD_AUTH." #2: "If present, the OPTION_PVD_AUTH option MUST be the last option inside the OPTION_PVD option." #1 implies I could choose to send more than one OPTION_PVD_AUTH (by not following the SOHULD) however #2 implies there can only be 0 or 1. 8. Missing normative reference to RFC 3971 (see Section 5). 9. Client and Server Behavior inconsistent Section 7.1 only instructs client to send an ORO in SOLICIT messages, however in Section 7.3. servers expect it to be sent (only?) in request messages. 10. Security concept seems mostly redundant Since addresses or prefixes are expected to be part of most PVD containers, DHCPv6 servers need to modify PVD containers in nearly all cases (by including IA_NA, IAPD, IAAddr, IAPrefix, ... options). Therefore - aside for very special cases - the DHCPv6 server would need the private key for signing in any case so plain DHCPv6 authentication could be used in the first place. _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
- [mif] MIF draft issues Steven Barth
- Re: [mif] MIF draft issues Suresh Krishnan
- Re: [mif] MIF draft issues Jouni Korhonen
- Re: [mif] MIF draft issues Steven Barth
- Re: [mif] MIF draft issues Steven Barth
- Re: [mif] MIF draft issues Jouni Korhonen