Host Identity Protocol Version 2 (HIPv2)
draft-ietf-hip-rfc5201-bis-20

[Ballot comment]


The original DISCUSS and COMMENT points are below. I
think only this one remains to be discussed:

(3) Continuing to support the 1536 MODP DHE group but not
supporting the 2048 equivalent seems a bit odd, as does
not having a code point for the 4096 but group.
Similarly, making the 1536 bit group the MTI (in 5.2.7)
is odd as is the assertion that "web surfing" can use a
lower security level.

And we discussed it! Seems like adding the 2048 bit
group would be good. I'm fine that the WG decide what
they want there.

(In other words ignore text below here.)

--- original discuss below

This review is based on the diff from 5201 [1]

  [1] https://tools.ietf.org/rfcdiff?url1=rfc5201&url2=draft-ietf-hip-rfc5201-bis-14.txt

Work started on this in 2009 it appears and the backwards
incompatible changes made to the BEX are roughly what I'd
expect to have seen for good work done around that time.
However, some things have changed since, that I don't see
reflected in the changes made to the BEX, so I'd like to
chat about those for a bit, in case they're still
malleable. If it is really the case that the boat has
sailed for such changes, then that's life, but I wonder
has it? (I really don't know for HIP.)

I think the features in the changes to the BEX that one
would consider noteworthy were that work done today are:

(1) Mandating some form of variability of, and
confidentiality for, the (non-routable?) HIT to enhance
privacy or at least mitigate trival passive tracking of
activity across time and different connections. (Or maybe
the "anonymous HI" mechanism achieves this, I wasn't
sure? If it does, then why have any other?)

(2) There is no support for newer elliptic curves or
representations like 25519.


(4) (5.2.8) Did the WG discuss deprecating the NULL
encryption option? (Haven't you finished testing yet:-)
Also - there are no counter modes, is that wise? Finally,
HIPv1's encryption codepoint 1 was for a 3DES option, but
here you have 1 == NULL, yet you deprecate codepoint 3,
which is confusing. Why is that?

(5) Requiring HMAC-SHA-1 in 6.4.1 seems a bit odd. If
HMAC-SHA-256 is supported, then why not just use that?
Is there are real benefit in the sha1 variant?

-- old comment below

- abstract: SIGMA-compliant is a bit of a mouthful for an
abstract - how many readers do we really expect to get
that?

- 1.1: Saying the HI is the identity of the host seems a
little overstated to me, but I guess that's accepted as
a description for HIP, so not objecting, but it'd seem
more natural to me to say that a HI is an identifier that
a host can use. (Presumably load-balancing and mobility
scenarios could mean that a private key could be on more
than one host or one "host" might have >1 private key.)

- section 3: 3110 doesn't seem like a great reference
for RSA. Isn't there better?

[Ballot discuss]

The original DISCUSS and COMMENT points are below. I
think only this one remains to be discussed:

(3) Continuing to support the 1536 MODP DHE group but not
supporting the 2048 equivalent seems a bit odd, as does
not having a code point for the 4096 but group.
Similarly, making the 1536 bit group the MTI (in 5.2.7)
is odd as is the assertion that "web surfing" can use a
lower security level.

(In other words ignore text below here.)

[Ballot comment]

--- original discuss below

This review is based on the diff from 5201 [1]

  [1] https://tools.ietf.org/rfcdiff?url1=rfc5201&url2=draft-ietf-hip-rfc5201-bis-14.txt

Work started on this in 2009 it appears and the backwards
incompatible changes made to the BEX are roughly what I'd
expect to have seen for good work done around that time.
However, some things have changed since, that I don't see
reflected in the changes made to the BEX, so I'd like to
chat about those for a bit, in case they're still
malleable. If it is really the case that the boat has
sailed for such changes, then that's life, but I wonder
has it? (I really don't know for HIP.)

I think the features in the changes to the BEX that one
would consider noteworthy were that work done today are:

(1) Mandating some form of variability of, and
confidentiality for, the (non-routable?) HIT to enhance
privacy or at least mitigate trival passive tracking of
activity across time and different connections. (Or maybe
the "anonymous HI" mechanism achieves this, I wasn't
sure? If it does, then why have any other?)

(2) There is no support for newer elliptic curves or
representations like 25519.


(4) (5.2.8) Did the WG discuss deprecating the NULL
encryption option? (Haven't you finished testing yet:-)
Also - there are no counter modes, is that wise? Finally,
HIPv1's encryption codepoint 1 was for a 3DES option, but
here you have 1 == NULL, yet you deprecate codepoint 3,
which is confusing. Why is that?

(5) Requiring HMAC-SHA-1 in 6.4.1 seems a bit odd. If
HMAC-SHA-256 is supported, then why not just use that?
Is there are real benefit in the sha1 variant?

-- old comment below

- abstract: SIGMA-compliant is a bit of a mouthful for an
abstract - how many readers do we really expect to get
that?

- 1.1: Saying the HI is the identity of the host seems a
little overstated to me, but I guess that's accepted as
a description for HIP, so not objecting, but it'd seem
more natural to me to say that a HI is an identifier that
a host can use. (Presumably load-balancing and mobility
scenarios could mean that a private key could be on more
than one host or one "host" might have >1 private key.)

- section 3: 3110 doesn't seem like a great reference
for RSA. Isn't there better?

[Ballot discuss]

Sent a mail Aug 23rd. No response seen except to the NULL issue
dealt with in 5205bis, -16 doesn't address.


--- original discuss below

This review is based on the diff from 5201 [1]

  [1] https://tools.ietf.org/rfcdiff?url1=rfc5201&url2=draft-ietf-hip-rfc5201-bis-14.txt

Work started on this in 2009 it appears and the backwards
incompatible changes made to the BEX are roughly what I'd
expect to have seen for good work done around that time.
However, some things have changed since, that I don't see
reflected in the changes made to the BEX, so I'd like to
chat about those for a bit, in case they're still
malleable. If it is really the case that the boat has
sailed for such changes, then that's life, but I wonder
has it? (I really don't know for HIP.)

I think the features in the changes to the BEX that one
would consider noteworthy were that work done today are:

(1) Mandating some form of variability of, and
confidentiality for, the (non-routable?) HIT to enhance
privacy or at least mitigate trival passive tracking of
activity across time and different connections. (Or maybe
the "anonymous HI" mechanism achieves this, I wasn't
sure? If it does, then why have any other?)

(2) There is no support for newer elliptic curves or
representations like 25519.

(3) Continuing to support the 1536 MODP DHE group but not
supporting the 2048 equivalent seems a bit odd, as does
not having a code point for the 4096 but group.
Similarly, making the 1536 bit group the MTI (in 5.2.7)
is odd as is the assertion that "web surfing" can use a
lower security level.

(4) (5.2.8) Did the WG discuss deprecating the NULL
encryption option? (Haven't you finished testing yet:-)
Also - there are no counter modes, is that wise? Finally,
HIPv1's encryption codepoint 1 was for a 3DES option, but
here you have 1 == NULL, yet you deprecate codepoint 3,
which is confusing. Why is that?

(5) Requiring HMAC-SHA-1 in 6.4.1 seems a bit odd. If
HMAC-SHA-256 is supported, then why not just use that?
Is there are real benefit in the sha1 variant?

[Ballot comment]
Thanks for posting -16.  There's only one minor thing that's still missed -- you can change it or not, as you see best.  Thanks very much for the work on this document.

In the IANA Considerations, similar to what was done for R1_COUNTER, I suggest this:

OLD
      A new value (579) for a new Parameter Type HIP_CIPHER should be
      added, with reference to this specification.  This Parameter Type
      functionally replaces the HIP_TRANSFORM Parameter Type (value 577)
      which can be left in the table with existing reference to
      [RFC5201].
NEW
      A new value (579) for a new Parameter Type HIP_CIPHER should be
      added, with reference to this specification.  This Parameter Type
      functionally replaces the HIP_TRANSFORM Parameter Type (value 577)
      which can be left in the table with existing reference to
      [RFC5201].  For clarity, we recommend that the name for the
      value 577 be changed from "HIP_TRANSFORM" to "HIP_TRANSFORM
      (v1 only)".
END

[Ballot discuss]
Thanks for posting -15, which resolves most of my comments about the IANA Considerations.  I'm updating this with the things that remain -- most are now non-blocking comments, below.

1. In the table at the end of Section 5.2, the reserved range that follows the experimental one seems to have a typo in it: it says "41952", and should say "49152".  There's also a discrepancy between the "61440 - 64443" range and the following "62464 - 63487" range.

2.
  IANA has reserved protocol number 139 for the Host Identity Protocol
  and included it in the "IPv6 Extension Header Types" registry
  [RFC7045].  No new action regarding this value is required by this
  specification.

There are actually two registries with the 139 value:

"IPv6 Extension Header Types"
http://www.iana.org/assignments/ipv6-parameters#extension-header

"Assigned Internet Protocol Numbers"
http://www.iana.org/assignments/protocol-numbers#protocol-numbers-1

In both of those registries, HIP is assigned the value 139, with a
reference document of [RFC5201].  Both entries should have the
reference document changed to this RFC.

[Ballot discuss]
Thanks for posting -15, which resolves most of my comments about the IANA Considerations.  I'm updating this with the things that remain -- most are now non-blocking comments, below.

1. In the table at the end of Section 5.2, the reserved range that follows the experimental one seems to have a typo in it: it says "41952", and should say "49152".  There's also a discrepancy between the "61440 - 64443" range and the following "62464 - 63487" range.

2.
  IANA has reserved protocol number 139 for the Host Identity Protocol
  and included it in the "IPv6 Extension Header Types" registry
  [RFC7045].  No new action regarding this value is required by this
  specification.

Do you really still want that reference to point to 5201, and not to this?  Why?  Isn't this the definitive reference for HIP once it's published?  (The way you're handling the HIP Version reference seems correct though.)

[Ballot comment]
  HIT Suite ID

      This specification creates a new registry for "HIT Suite ID".
      This is different than the existing registry for "Suite ID" which
      can be left unmodified for version 1 of the protocol ([RFC5201]).

Should the v1 registry be closed to new registrations?

      HIT
      Suite IDs must be allocated carefully to avoid namespace
      exhaustion.  Moreover, deprecated IDs should be reused after an
      appropriate time span.

I think it would be useful to add something like this, just to make sure everything is clear to all readers, including IANA, and to help make sure that the right thing happens in the future:

ADD
Requests to register reused values should include a note that the value is being reused after a deprecation period, to ensure appropriate IETF review and approval.
END

      A new value (129) for R1_COUNTER should be introduced, with a
      reference to this specification, and the existing value (128) for
      R1_COUNTER left in place with a reference to [RFC5201].  This
      documents the change in value that has occurred in version 2 of
      this protocol.

A question: Would it be sensible, for this and for HIP_TRANSFORM, to add a notation to the old entry?  Something like this:

OLD
  | 128  | R1_COUNTER              | 12      | [RFC5201]  |
...
  | 577  | HIP_TRANSFORM          | variable | [RFC5201]  |
NEW
  | 128  | R1_COUNTER (v1 only)    | 12      | [RFC5201]  |
...
  | 577  | HIP_TRANSFORM (v1 only) | variable | [RFC5201]  |
END

That way, no one has to infer it from the fact that 5201 is still the reference for it.

      The name of the HMAC Parameter Type (value 61505) should be
      changed to HIP_MAC.  The name of the HMAC_2 Parameter Type (value
      61569) should be changed to HIP_MAC_2.

This should say whether the reference is changing or staying as 5201.  It looks like it should change, but if it's staying, the same comment applies to this as to HIP_TRANSFORM.

      The Type codes 32768 through 49151 are reserved for
      experimentation.  Types SHOULD be selected in a random fashion
      from this range, thereby reducing the probability of collisions.
      A method employing genuine randomness (such as flipping a coin)
      SHOULD be used.

I think this should be worded slightly differently to be clear that it's not an instruction to IANA, but to implementors.  Changing to active voice should do that nicely:

NEW
      The Type codes 32768 through 49151 are reserved for
      experimentation.  Implementors SHOULD select types in a
      random fashion from this range, thereby reducing the
      probability of collisions. A method employing genuine
      randomness (such as flipping a coin) SHOULD be used.
END

[Ballot comment]
4.4.1:

  Maximum Segment Lifetime (MSL):  Maximum time that a TCP segment is
      expected to spend in the network.

TCP segment? First mention of use of TCP in this document.

[Ballot discuss]
I need to add a DISCUSS to Ted's on IANA registry issues.

1. It seems to me that this document needs to change all the registration entries that cite 5201, making them point to this document instead.

2. This document doesn't create the registries that it says it creates, and it shouldn't say that it does.  But this document changes the registration policies of some of the registries, so it needs to make those changes clear.  Perhaps (1) and (2) are already in the plan, in response to IANA's questions.

3. The last paragraph describing the Parameter Type registry says that "all other values" (it would be better to list them: 1024 through 32767 and 49152 through 61439) are assigned through "Fist Come First Served, with Specification Required."  I realize the policy specification is unchanged from 5201, but it's not a valid policy combination.  What is it intended to mean?  FCFS and Specification Required are contradictory policies.  Perhaps what you want is FCFS, with a documentation reference recorded in the registry.  You can then say a few words about what registrants should make sure the reference document contains, but realize that it will not be validated by anyone for completeness or sensibility.

4. 5201 specified that the experimentation range ended at 49141; this changes it to 49151.  I just want to make sure that was intentional, and not a typo.  Will you confirm that?

5. In the table at the end of Section 5.2, the reserved range that follows the experimental one seems to have a typo in it: it says "41952", and should say "49152".  There's also a discrepancy between the "61440 - 64443" range and the following "62464 - 63487" range.  I have no idea which one has the typo there.

6. The comment in (3) about FCFS also applies to the Notify Message Type registry.  Also, in the ranges given, the value 16384 doesn't fall in any range.

[Ballot comment]
-- Section 4.1.8 --

  Therefore, the Responder SHOULD should select its HIT from the same
  HIT Suite as the Initiator's HIT

"SHOULD should" typo.

[Ballot discuss]
This review is based on the diff from 5201 [1]

  [1] https://tools.ietf.org/rfcdiff?url1=rfc5201&url2=draft-ietf-hip-rfc5201-bis-14.txt

Work started on this in 2009 it appears and the backwards
incompatible changes made to the BEX are roughly what I'd
expect to have seen for good work done around that time.
However, some things have changed since, that I don't see
reflected in the changes made to the BEX, so I'd like to
chat about those for a bit, in case they're still
malleable. If it is really the case that the boat has
sailed for such changes, then that's life, but I wonder
has it? (I really don't know for HIP.)

I think the features in the changes to the BEX that one
would consider noteworthy were that work done today are:

(1) Mandating some form of variability of, and
confidentiality for, the (non-routable?) HIT to enhance
privacy or at least mitigate trival passive tracking of
activity across time and different connections. (Or maybe
the "anonymous HI" mechanism achieves this, I wasn't
sure? If it does, then why have any other?)

(2) There is no support for newer elliptic curves or
representations like 25519.

(3) Continuing to support the 1536 MODP DHE group but not
supporting the 2048 equivalent seems a bit odd, as does
not having a code point for the 4096 but group.
Similarly, making the 1536 bit group the MTI (in 5.2.7)
is odd as is the assertion that "web surfing" can use a
lower security level.

(4) (5.2.8) Did the WG discuss deprecating the NULL
encryption option? (Haven't you finished testing yet:-)
Also - there are no counter modes, is that wise? Finally,
HIPv1's encryption codepoint 1 was for a 3DES option, but
here you have 1 == NULL, yet you deprecate codepoint 3,
which is confusing. Why is that?

(5) Requiring HMAC-SHA-1 in 6.4.1 seems a bit odd. If
HMAC-SHA-256 is supported, then why not just use that?
Is there are real benefit in the sha1 variant?

[Ballot comment]
- abstract: SIGMA-compliant is a bit of a mouthful for an
abstract - how many readers do we really expect to get
that?

- 1.1: Saying the HI is the identity of the host seems a
little overstated to me, but I guess that's accepted as
a description for HIP, so not objecting, but it'd seem
more natural to me to say that a HI is an identifier that
a host can use. (Presumably load-balancing and mobility
scenarios could mean that a private key could be on more
than one host or one "host" might have >1 private key.)

- section 3: 3110 doesn't seem like a great reference
for RSA. Isn't there better?

[Ballot discuss]
The Gen-ART review from Tom Taylor raised a couple of issues that in my mind require at least clarification. The authors have acknowledged the review, but I think we still need to see you answer if changes are necessary.

Otherwise I am very happy with this document, and will be happy to recommend "Yes" for it once the above is clear.

[Ballot discuss]
I have no objection to the publication of this document, but I do have two small points to discuss in section 5.2.3.

1. The R1_COUNTER parameter was labeled as optional in RFC 5201, but made mandatory in this revision.  However, the text says it SHOULD be included in R1.  If it is not included in R1 (violates the SHOULD), where will it be included given it is mandatory?

2. The Type value of R1_COUNTER was 128 in 5201 and is now 129.  Is that correct?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-hip-rfc5201-bis-14.  Authors SHOULD review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has questions about some of the IANA Actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are eight actions which IANA must complete.

First, in the CGA Extension Type Tags subregistry of the Cryptographically Generated Addresses (CGA) Message Type Name Space registry located at:

http://www.iana.org/assignments/cga-message-types/

a new value is to be registered as follows:

CGA Type Tag: F0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA
Reference: [ RFC-to-be ]

Second, in the HIP Version subregistry of the Host Identity Protocol (HIP) Parameters registry located at:

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

a new version is to be registered as follows:

Value: 2
Reference: [ RFC-to-be ]

IANA Question -> The current document creates a series of new namespaces.  Are these new namespaces to be standalone registries or are they to be subregistries of the existing Host Identity Protocol (HIP) Parameters registry located at:

http://www.iana.org/assignments/hip-parameters/  ??

Third, in a location [ TBD, see question above ] a new registry is to be created called the "HIP Packet Type."  The HIP packet type is a 7-bit value.  The new registry is maintained via IETF Review or IESG Approval as defined by RFC 5226.

There are initial values in the new registry as follows.

+------------------+------------------------------------------------+
|    Packet type  | Packet name                                    |
+------------------+------------------------------------------------+
|        1        | I1 - the HIP Initiator Packet                  |
|                  |                                                |
|        2        | R1 - the HIP Responder Packet                  |
|                  |                                                |
|        3        | I2 - the Second HIP Initiator Packet          |
|                  |                                                |
|        4        | R2 - the Second HIP Responder Packet          |
|                  |                                                |
|        16        | UPDATE - the HIP Update Packet                |
|                  |                                                |
|        17        | NOTIFY - the HIP Notify Packet                |
|                  |                                                |
|        18        | CLOSE - the HIP Association Closing Packet    |
|                  |                                                |
|        19        | CLOSE_ACK - the HIP Closing Acknowledgment    |
|                  | Packet                                        |
+------------------+------------------------------------------------+

For each of the packet type values above, IANA will use a reference of [ RFC-to-be ].

Fourth, in a location [ TBD, see question above ] a new registry is to be created called the "HIT Suite."  The HIP packet type is a 4-bit value.  The new registry is maintained via IETF Review or IESG Approval as defined by RFC 5226. 

IANA Question -> The IANA Considerations section states that "This document defines two HIT Suites (see Appendix E)."  However, Appendix E seems to provide three HIT Suites.  Which is correct?

There are initial registrations in this new registry as follows:

+-------+----------+--------------+------------+--------------------+
| Index | Hash    | HMAC        | Signature  | Description        |
|      | function |              | algorithm  |                    |
|      |          |              | family    |                    |
+-------+----------+--------------+------------+--------------------+
|    0 |          |              |            | Reserved          |
|    1 | SHA-256  | HMAC-SHA-256 | RSA, DSA  | RSA or DSA HI      |
|      |          |              |            | hashed with        |
|      |          |              |            | SHA-256, truncated |
|      |          |              |            | to 96 bits        |
|    2 | SHA-384  | HMAC-SHA-384 | ECDSA      | ECDSA HI hashed    |
|      |          |              |            | with SHA-384,      |
|      |          |              |            | truncated to 96    |
|      |          |              |            | bits              |
|    3 | SHA-1    | HMAC-SHA-1  | ECDSA_LOW  | ECDSA_LOW HI      |
|      |          |              |            | hashed with SHA-1, |
|      |          |              |            | truncated to 96    |
|      |          |              |            | bits              |
+-------+----------+--------------+------------+--------------------+

For each of the HIT Suite values above, IANA will use a reference of [ RFC-to-be ].

Fifth, in a location [ TBD, see question above ] a new registry is to be created called the "Parameter Type."  The Parameter type is a 16-bit value. 

The Type codes 0 through 1023 and 61440 through 65535 are reserved for future base protocol extensions, and are assigned through IETF Review or IESG Approval as defined by RFC 5226.

The Type codes 32768 through 49151 are reserved for experimentation. Types SHOULD be selected in a random fashion from this range, thereby reducing the probability of collisions. A method employing genuine randomness (such as flipping a coin) SHOULD be used.

All other Type codes are assigned through First Come First Served, with Specification Required as defined by RFC 5226.

There are initial values in this new registry as follows:

+------------------------+-------+-----------+----------------------+
| TLV                    | Type  | Length    | Data                |
+------------------------+-------+-----------+----------------------+
| R1_COUNTER            | 129  | 12        | Puzzle generation    |
|                        |      |          | counter              |
|                        |      |          |                      |
| PUZZLE                | 257  | 12        | K and Random #I      |
|                        |      |          |                      |
| SOLUTION              | 321  | 20        | K, Random #I and    |
|                        |      |          | puzzle solution J    |
|                        |      |          |                      |
| SEQ                    | 385  | 4        | UPDATE packet ID    |
|                        |      |          | number              |
|                        |      |          |                      |
| ACK                    | 449  | variable  | UPDATE packet ID    |
|                        |      |          | number              |
|                        |      |          |                      |
| DH_GROUP_LIST          | 511  | variable  | Ordered list of DH  |
|                        |      |          | Group IDs supported  |
|                        |      |          | by a host            |
|                        |      |          |                      |
| DIFFIE_HELLMAN        | 513  | variable  | public key          |
|                        |      |          |                      |
| HIP_CIPHER            | 579  | variable  | List of HIP          |
|                        |      |          | encryption          |
|                        |      |          | algorithms          |
|                        |      |          |                      |
| ENCRYPTED              | 641  | variable  | Encrypted part of a  |
|                        |      |          | HIP packet          |
|                        |      |          |                      |
| HOST_ID                | 705  | variable  | Host Identity with  |
|                        |      |          | Fully-Qualified      |
|                        |      |          | Domain FQDN (Name)  |
|                        |      |          | or Network Access    |
|                        |      |          | Identifier (NAI)    |
|                        |      |          |                      |
| HIT_SUITE_LIST        | 715  | variable  | Ordered list of the  |
|                        |      |          | HIT suites supported |
|                        |      |          | by the Responder    |
|                        |      |          |                      |
| CERT                  | 768  | variable  | HI Certificate; used |
|                        |      |          | to transfer          |
|                        |      |          | certificates.        |
|                        |      |          | Specified in a      |
|                        |      |          | separate docment.    |
|                        |      |          |                      |
| NOTIFICATION          | 832  | variable  | Informational data  |
|                        |      |          |                      |
| ECHO_REQUEST_SIGNED    | 897  | variable  | Opaque data to be    |
|                        |      |          | echoed back; signed  |
|                        |      |          |                      |
| ECHO_RESPONSE_SIGNED  | 961  | variable  | Opaque data echoed  |
|                        |      |          | back by request;    |
|                        |      |          | signed              |
|                        |      |          |                      |
| TRANSPORT_FORMAT_LIST  | 2049  | Ordered  | variable            |
|                        |      | list of  |                      |
|                        |      | preferred |                      |
|                        |      | HIP      |                      |
|                        |      | transport |                      |
|                        |      | type      |                      |
|                        |      | numbers  |                      |
|                        |      |          |                      |
| HIP_MAC                | 61505 | variable  | HMAC-based message  |
|                        |      |          | authentication code, |
|                        |      |          | with key material    |
|                        |      |          | from KEYMAT          |
|                        |      |          |                      |
| HIP_MAC_2              | 61569 | variable  | HMAC based message  |
|                        |      |          | authentication code, |
|                        |      |          | with key material    |
|                        |      |          | from KEYMAT. Unlike  |
|                        |      |          | HIP_MAC, the HOST_ID |
|                        |      |          | parameter is        |
|                        |      |          | included in          |
|                        |      |          | HIP_MAC_2            |
|                        |      |          | calculation.        |
|                        |      |          |                      |
| HIP_SIGNATURE_2        | 61633 | variable  | Signature used in R1 |
|                        |      |          | packet              |
|                        |      |          |                      |
| HIP_SIGNATURE          | 61697 | variable  | Signature of the    |
|                        |      |          | packet              |
|                        |      |          |                      |
| ECHO_REQUEST_UNSIGNED  | 63661 | variable  | Opaque data to be    |
|                        |      |          | echoed back; after  |
|                        |      |          | signature            |
|                        |      |          |                      |
| ECHO_RESPONSE_UNSIGNED | 63425 | variable  | Opaque data echoed  |
|                        |      |          | back by request;    |
|                        |      |          | after signature      |
+------------------------+-------+-----------+----------------------+

IANA Question -> Parameter Type 768 indicates that the reference for this parameter should be another document.  What is that document?

All other parameter types will be given a reference of [ RFC-to-be ].

Sixth, in a location [ TBD, see question above ] a new registry is to be created called the "Group ID."  The Group ID is a 8-bit value.  The new registry is maintained via IETF Review or IESG Approval as defined by RFC 5226.

Thre are initial registrations in this new registry as follows:

Value    Group                              KDF              Reference
--------+----------------------------------+----------------+-------------   
0        Reserved                                            [ RFC-to-be ]
1        DEPRECATED                                          [ RFC-to-be ]
2        DEPRECATED                                          [ RFC-to-be ]
3        1536-bit MODP group  [RFC3526]    HKDF [RFC5869]  [ RFC-to-be ]
4        3072-bit MODP group  [RFC3526]    HKDF [RFC5869]  [ RFC-to-be ]
5        DEPRECATED                                          [ RFC-to-be ]
6        DEPRECATED                                          [ RFC-to-be ]
7        NIST P-256 [RFC5903]              HKDF [RFC5869]  [ RFC-to-be ]
8        NIST P-384 [RFC5903]              HKDF [RFC5869]  [ RFC-to-be ]
9        NIST P-521 [RFC5903]              HKDF [RFC5869]  [ RFC-to-be ]
10      SECP160R1  [SECG]                  HKDF [RFC5869]  [ RFC-to-be ]

Seventh, in a location [ TBD, see question above ] a new registry is to be created called the "HIP Cipher ID."  The Cipher ID is a 16-bit value.  The new registry is maintained via IETF Review or IESG Approval as defined by RFC 5226.

There are initial registrations in the HIP Cipher ID registry as follows:

Value  Suite ID          Reference
-------+------------------+---------------
0      RESERVED          [ RFC-to-be ]
1      NULL-ENCRYPT      [RFC2410]
2      AES-128-CBC        [RFC3602]
3      DEPRECATED        [ RFC-to-be ]
4      AES-256-CBC        [RFC3602]

Seventh, in a location [ TBD, see question above ] a new registry is to be created called the "DI-type."  The DI-type is a 4-bit value.  The new registry is maintained via IETF Review or IESG Approval as defined by RFC 5226.

There are initial registrations in the DI-type registry as follows:

Value  Type            Reference
------+---------------+--------------
0      non included    [ RFC-to-be ]
1      FQDN            [ RFC-to-be ]
2      NAI            [ RFC-to-be ]

Eighth, in a location [ TBD, see question above ] a new registry is to be created called the "Notify Message Type."  The DI-type is a 16-bit value. 

Registration rules are as follows:

51-8191 are error types reserved to be allocated by IANA
8192-16383 are error types for experimentation
16385-40959 are status types to be allocated by IANA
40960-65535 are status types for experimentation

New values in ranges 51-8191 and 16385-40959 are assigned through First Come First Served, with Specification Required.

IANA Question -> what are the registration rules for values 0-50?
IANA Question -> what are the registration rules for values 40960-65535?

IANA understands that there are initial values for the Notify Message Type registry as follows:

Value  Notify Message Type                    Reference
-------+--------------------------------------+----------------
1      UNSUPPORTED_CRITICAL_PARAMETER_TYPE    [ RFC-to-be ]
7      INVALID_SYNTAX                        [ RFC-to-be ]
14      NO_DH_PROPOSAL_CHOSEN                  [ RFC-to-be ]
15      INVALID_DH_CHOSEN                      [ RFC-to-be ]
16      NO_HIP_PROPOSAL_CHOSEN                [ RFC-to-be ]
17      INVALID_HIP_CIPHER_CHOSEN              [ RFC-to-be ]
20      UNSUPPORTED_HIT_SUITE                  [ RFC-to-be ]
24      AUTHENTICATION_FAILED                  [ RFC-to-be ]
26      CHECKSUM_FAILED                        [ RFC-to-be ]
28      HIP_MAC_FAILED                        [ RFC-to-be ]
32      ENCRYPTION_FAILED                      [ RFC-to-be ]
40      INVALID_HIT                            [ RFC-to-be ]
42      BLOCKED_BY_POLICY                      [ RFC-to-be ]
44      RESPONDER_BUSY_PLEASE_RETRY            [ RFC-to-be ]
16384  I2_ACKNOWLEDGEMENT                    [ RFC-to-be ]

IANA understands that these eight actions are the only actions required to be completed by IANA upon approval of this document.


Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Host Identity Protocol Version 2 (HIPv2)) to Proposed Standard


The IESG has received a request from the Host Identity Protocol WG (hip)
to consider the following document:
- 'Host Identity Protocol Version 2 (HIPv2)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-06-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies the details of the Host Identity Protocol
  (HIP).  HIP allows consenting hosts to securely establish and
  maintain shared IP-layer state, allowing separation of the identifier
  and locator roles of IP addresses, thereby enabling continuity of
  communications across IP address changes.  HIP is based on a SIGMA-
  compliant Diffie-Hellman key exchange, using public key identifiers
  from a new Host Identity namespace for mutual peer authentication.
  The protocol is designed to be resistant to denial-of-service (DoS)
  and man-in-the-middle (MitM) attacks.  When used together with
  another suitable security protocol, such as the Encapsulated Security
  Payload (ESP), it provides integrity protection and optional
  encryption for upper-layer protocols, such as TCP and UDP.

  This document obsoletes RFC 5201 and addresses the concerns raised by
  the IESG, particularly that of crypto agility.  It also incorporates
  lessons learned from the implementations of RFC 5201.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1541/

PROTO Writeup for draft-ietf-hip-rfc5201-bis

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

  Proposed Standard, as indicated in the header. The HIP WG is
  currently chartered to revise a few Experimental RFCs into Proposed
  Standards. This is one of those RFCs. The HIP WG learned a few
  lessons experimenting with those Experimental RFCs. RFC 6538
  documents those learnings.


(2) 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 the details of the Host Identity Protocol
  (HIP).  HIP allows consenting hosts to securely establish and
  maintain shared IP-layer state, allowing separation of the
  identifier and locator roles of IP addresses, thereby enabling
  continuity of communications across IP address changes.  HIP is
  based on a SIGMA- compliant Diffie-Hellman key exchange, using
  public key identifiers from a new Host Identity namespace for
  mutual peer authentication.  The protocol is designed to be
  resistant to denial-of-service (DoS) and man-in-the-middle (MitM)
  attacks.  When used together with another suitable security
  protocol, such as the Encapsulated Security Payload (ESP), it
  provides integrity protection and optional encryption for
  upper-layer protocols, such as TCP and UDP.

  This document obsoletes RFC 5201 and addresses the concerns raised
  by the IESG, particularly that of crypto agility.  It also
  incorporates lessons learned from the implementations of RFC 5201.


Working Group Summary:

  There is full consensus behind this document.


Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  As discussed in RFC 6538, there are several implementations of the
  Experimental HIP specs. At least HIP for Linux and OpenHIP will be
  updated to comply with the standards-track specs.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Gonzalo Camarillo is the document shepherd.
Ted Lemon is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd has reviewed version 12 of the document and
  believes it is ready for publication request.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No special reviews are needed.


(6) Describe any specific concerns or issues that the Document
Shepherd has 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.

  None.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

  Yes.


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  Yes, an IPR disclosure was filed against this draft in 2011. The WG
  decided to mandate a co-factor of 1 in an attempt to avoid the first
  patent referenced in the IPR disclosure.


(9) 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?

  The whole WG understands the document and agree with it. Note that
  this is the revision of an existing RFC (i.e., a bis document).


(10) 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 publicly available.)

  No.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

  The warnings given by the ID nits tool are not relevant as they do
  not represent actual issues.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No further formal reviews are needed.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.


(14) 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 plan for their completion?

  There are two normative references to Internet drafts. Those two
  drafts are being progressed at the same time as this one.


(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

  No.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

  Yes, the publication of this RFC will obsolete RFC 5201. RFC 4843 is
  listed in the document header and is discussed in the Abstract,
  although not in the Introduction.  If having the Introduction
  discuss RFC 4843 as well was considered necessary, copying the last
  paragraph of the Abstract and pasting it into the Introduction could
  be trivially done.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

  The IANA Considerations Section is consisten with the body of the
  document.


(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

  No new registries follow the Expert Review policy.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No formal language review is needed.