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

Looking forward to seeing the discuss resolutions.

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

Thanks for addressing my DISCUSS points.

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.

I agree with Stephen's DISCUSS.  The cryptographic algorithm choices here seem incrementally better than RFC 5201, but not very forward-looking.

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?