Subject: [mif] I-D Action: draft-ietf-mif-mpvd-dhcp-support-02.txt

From: [email-masked]
Date: Mon, 19 Oct 2015 15:26:59 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiple Interfaces Working Group of the IETF.

        Title           : Support for multiple provisioning domains in DHCPv6
        Authors         : Suresh Krishnan
                          Jouni Korhonen
                          Shwetha Bhandari
	Filename        : draft-ietf-mif-mpvd-dhcp-support-02.txt
	Pages           : 10
	Date            : 2015-10-19

Abstract:
   The MIF working group is producing a solution to solve the issues
   that are associated with nodes that can be attached to multiple
   networks.  One part of the solution requires associating
   configuration information with provisioning domains.  This document
   details how configuration information provided through DHCPv6 can be
   associated with provisioning domains.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-dhcp-support/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-mif-mpvd-dhcp-support-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mif-mpvd-dhcp-support-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Steven Barth <[email-masked]>
Date: Thu, 29 Oct 2015 10:56:13 +0100

As for the NDP-support draft:

Thanks for the updated version, here is a second review of the draft. I
intentionally did not look at my first review notes so there might be
duplicates. Feel free to ignore them if they are invalid.

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.