Mobility Support in IPv6
draft-ietf-mext-rfc3775bis-13

[Ballot discuss]
[revised discuss.]

This is a good document, and I don't want to delay publication unnecessarily.  However, there are two issues I
would like to discuss: the use of subject alternative names in PKIX certificates and the use of SHA-1.

(1) I would like to confirm that subject alternative names are commonly used in Mobile IPv6.  While the subject alternative name would be the most appropriate field for Mobile IPv6, many protocols rely in practice on other
fields.  If subject alternative names are not commonly used, I beleive it is important for the text to reflect actual
practice.

(2) There is no risk incurred by the use of SHA-1 in this document.  However, this is a source of great confusion
to many readers.  Could we add a brief section 15.10 "Use of SHA-1" with an informative reference to
[I-D.turner-sha0-sha1-seccon]?

I would suggest something like:

This document relies on hash-based message authentication codes (HMAC) computed using the SHA-1 hash
algorithm for the home keygen token, care-of keygen token, as well as the authentication fields in the binding
update and binding authorization data.  While SHA-1 has been deprecated for some cryptographic mechanisms,
SHA-1 is considered secure for the foreseeable future when used as specified here. For additional details,
see [I-D.turner-sha0-sha1-seccon].

I am not wedded to these words, but include them as an example.

[Ballot comment]
FWIW I have reviewed the final list of changes from RFC 3775 and I
think they are all good. Thank you Charlie for doing this work so
carefully.

With respect to comments raised in IESG and directorate reviews:

David's comment about the normative text from RFC 3775. Not sure I
understand your comment. The rules on these were one of the specific
changes in the bis version. What's wrong with the bis text, specifically?

Tim's comments on SHA-1: It would be lovely to add more material about
this. I need to look at the review to find out if there's something
that we could use. However, I do not believe this should be a blocking
comment given that this code and spec has been out there for years;
if substantial work is needed for the analysis, I'd prefer to do that
as a separate document. In any case, since the return routability
mechanism that uses SHA1 is very weak (yet sufficient), I'd be really
surprised if attacking SHA1 was the easiest route to disrupting
communications.

Sean: Yes, we should add the normative reference on HMAC.

[Ballot comment]
#1) Is there a reason not to point to the latest FIPS PUB 180-3?

        National Institute of Standards and Technology (NIST), FIPS
        Publication 180-3: Secure Hash Standard, October 2008.

#2) I assume we want good keys?  Add the following to the first paragraph in 5.2.1:

The keys MUST be generated by using a random number generator that is known to have good randomness properties [13].

#3) Section 5.2.4: People keep telling me it's SHA-1 not SHA1 when not used with HMAC.

#3) Should the recommendations in Section 5.2.2 and 5.2.4 be made upper case? (i.e., r/recommended/RECOMMENDED).

[Ballot comment]
#1) Is there a reason not to point to the latest FIPS PUB 180-3?

#2) I assume we want good keys?  Add the following to the first paragraph in 5.2.1:

The keys MUST be generated by using a random number generator that is known to have good randomness properties [13].

#3) Section 5.2.4: People keep telling me it's SHA-1 not SHA1 when not used with HMAC.

#3) Should the recommendations in Section 5.2.2 and 5.2.4 be made upper case? (i.e., r/recommended/RECOMMENDED).

[Ballot comment]
These are preliminary!

Is there a reason not to point to the latest FIPS PUB 180-3?

HMAC [26] appears to be normative. 

I assume we want good keys?  Add the following to the first paragraph in 5.2.1:

The keys MUST be generated by using a random number generator that is known to have good randomness properties [13].

Section 5.2.2: r/recommended/RECOMMENDED

Section 5.2.4: People keep telling me it's SHA-1 not SHA1 when not used with HMAC.

[Ballot discuss]
1) the follwoing text (from rfc3775) should probably be made more/less normative:
  The deletion of a binding can be indicated by setting the Lifetime
  field to 0 and by setting the care-of address equal to the home
  address.  In deletion, the generation of the binding management key
  depends exclusively on the home keygen token, as explained in Section
  5.2.5.  (Note that while the senders are required to set both the
  Lifetime field to 0 and the care-of address equal to the home
  address, Section 9.5.1 rules for receivers are more liberal, and
  interpret either condition as a deletion.)
What is REQUIRED of a compliant inmplementation?

[Ballot comment]
Please review Nico's discussion of " Enrolment/assignment of home address bindings to mobile node
credentials."  If work is underway, an informative reference would be nice.

[Ballot discuss]
This is a good document, and I don't want to delay publication unnecessarily.  However, Nico Williams raised
some important points in his (late) secdir review, and I want to be sure the authors consider these points before
publication.

The two issues I was particularly interested in are  the use of subject alternative names in PKIX certificates and
the use of SHA-1.  (See "Binding of home addresses to mobile node credentials when using IKEv2" and "Hash/MAC algorithm agility" in the review, respectively)

(1) I would like to confirm that subject alternative names are commonly used in Mobile IPv6.  If subject alternative
names are not commonly used, as Nico suggests, I beleive it is important for the text to reflect actual practice.

(2) I believe that Nico is correct, and there is no risk incurred by the use of SHA-1 in this document.  However, this
is a source of great confusion to many readers.  Adding text to the security considerations noting that the use of
SHA-1 has been reviewed and is safe would be a really good idea.  If such a review has not been performed, I would
be glad to connect the authors to some NIST cryptographers to do that review...

[Ballot comment]
I've scanned wdiff changes since RFC 3775 and I don't think my review can add much value to the quality of the document. So I have No Objections to its publication.

IANA understands that there are four IANA Actions that need to be
completed upon approval of this document.

First, the Mobility Header has been assigned protocol number 135 in the
Protocol Numbers registry located at:

http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

This registration will be updated with a reference of [RFC-to-be]

Second, the document creates a new registry called the Mobility Header
Type in the IPv6 parameters registry located at:

http://www.iana.org/assignments/ipv6-parameters

The newly created registry has values between 0 and 255 inclusive. New
registrations in this registry require IESG approval or Standards
Action. The initial values of this registry are:

Value Type

0 Binding Refresh Request
1 Home Test Init
2 Care-of Test Init
3 Home Test
4 Care-of Test
5 Binding Update
6 Binding Acknowledgement
7 Binding Error

All of the new registrations in this registry will have [RFC-to-be] as a
reference.

Third, the document creates another new registry called the Mobility
Option in the IPv6 parameters registry located at:

http://www.iana.org/assignments/ipv6-parameters

The newly created registry has values between 0 and 255 inclusive. New
registrations in this registry require IESG approval or Standards
Action. The initial values of this registry are:

Value Mobility Option

0 Pad1
1 PadN
2 Binding Refresh Advice
3 Alternate Care-of Address
4 Nonce Indices
5 Authroization Data

All of the new registrations in this registry will have [RFC-to-be] as a
reference.

Fourth, the document creates a third new registry called the Binding
Acknowledgment Status Code in the IPv6 parameters registry located at:

http://www.iana.org/assignments/ipv6-parameters

The newly created registry has values between 0 and 255 inclusive. New
registrations in this registry require IESG approval or Standards Action.

Values of the Status field less than 128 indicate that the Binding
Update was accepted by the receiving node. Values greater than or equal
to 128 indicate that the Binding Update was rejected by the receiving node.

The initial values of this registry are:

Value Status

0 Binding Update accepted
1 Accepted but prefix discovery necessary
2-127 Unassigned
128 Reason unspecified
129 Administratively prohibited
130 Insufficient resources
131 Home registration not supported
132 Not home subnet
133 Not home agent for this mobile node
134 Duplicate Address Detection failed
135 Sequence number out of window
136 Expired home nonce index
137 Expired care-of nonce index
138 Expired nonces
139 Registration type change disallowed
TBD Invalid Care-of Address

All of the new registrations in this registry will have [RFC-to-be] as a
reference.

Fifth, this document defines a new IPv6 destination option, the Home
Address option. This option has already been assigned the Option Value
0xC9 in the Destination Options and Hop-by-Hop Options registry located at:

http://www.iana.org/assignments/ipv6-parameters

The reference will be updated to [RFC-to-be].

Sixth, this document defines a new IPv6 routing header, the Type 2
Routing Header. This header type has already been assigned the Value 2
in the Routing Types registry located at:

http://www.iana.org/assignments/ipv6-parameters

The reference will be updated to [RFC-to-be].

Seventh, this document defines four ICMP message types. They are:

- The Home Agent Address Discovery Request message
- The Home Agent Address Discovery Reply message
- The Mobile Prefix Solicitation
- The Mobile Prefix Advertisement

These ICMP message types are already registered in the ICMPv6 Parameters
registry located at:

http://www.iana.org/assignments/icmpv6-parameters

The references will be updated to [RFC-to-be].

Eighth, this document define two new Neighbor Discovery Options. They are:

- The Advertisement Interval Option
- The Home Agent Information Option

These Neighbor Discovery Options are already registered in the IPv6
Neighbor Discovery Option Formats registry located at:

http://www.iana.org/assignments/icmpv6-parameters

The references will be updated to [RFC-to-be].

IANA understands that these eight IANA Actions are all that need to be
completed upon approval of this document.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The Document Shepherd is Julien Laganier, MEXT co-chair. He
        has personally done a thorough review of the document. He
        believe the document is ready for forwarding to IESG for
        publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

        The document was given adequate reviews. The Document Shepherd has
        no concerns about the depth or breadth of these reviews.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

        The Document Shepherd has no such concerns.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

        The Document Shepherd has no such concerns.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

There is WG consensus behind this document.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

        No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Yes.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The document has split its references into normative and
        informative. There are neither normative references in an unclear
        state, nor downward references.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

        Yes.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

        There are no such sections.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

  This document specifies Mobile IPv6, a protocol which allows nodes to
  remain reachable while moving around in the IPv6 Internet.  Each
  mobile node is always identified by its home address, regardless of
  its current point of attachment to the Internet.  While situated away
  from its home, a mobile node is also associated with a care-of
  address, which provides information about the mobile node's current
  location.  IPv6 packets addressed to a mobile node's home address are
  transparently routed to its care-of address.  The protocol enables
  IPv6 nodes to cache the binding of a mobile node's home address with
  its care-of address, and to then send any packets destined for the
  mobile node directly to it at this care-of address.  To support this
  operation, Mobile IPv6 defines a new IPv6 protocol and a new
  destination option.  All IPv6 nodes, whether mobile or stationary,
  can communicate with mobile nodes.  This document obsoletes RFC 3775.

    Working Group Summary

  The normal WG process was followed and the document revisions have been
  discussed for over two years. The document as it is now, reflects WG
  consensus, with nothing special worth noting.

    Document Quality

  The document was given adequate reviews. The Document Shepherd has
  no concerns about the depth or breadth of these reviews.