Last Call Review of draft-ietf-hip-cert-
review-ietf-hip-cert-secdir-lc-gondrom-2011-03-03-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.


The draft is experimental and specifies for the Host Identity Protocol
(HIP, RFC5201, experimental) the certificate parameter and the error
signaling in case of a failed verification.

From the security perspective, the considerations in this document
appear to be overall sufficient (note that RFC5201 already covers
several of the security consideration scenarios of the base protocol).


A few small comments:
1. section 2.CERT 2nd paragraph:
"The CERT parameter is covered, when present, by the HIP SIGNATURE field
and is a non-critical parameter."
Not sure it is sufficiently clear what you mean by "covered", maybe the
word "protected" is better in this context.

2. Personally I would have liked to see at least one user scenario for
the CERT with this document, but acknowledge that the document
intentionally excludes such use cases (though I do understand why they
would not want to provide an example).

3. section 2.CERT 8th paragraph: expand "HIT" on first use => "HIT (Host
Identity Tag)" or introduce abbrevation in abstract "Host Identity Tags"
=> "Host Identity Tags (HIT)"

4. the authors should run idnits when submitting the documents:
"There are 2 instances of lines with non-RFC3849-compliant IPv6
addresses in the document.
If these are example addresses, they should be changed.
- line 356: Found possible IPv6 address
'2001:13:724d:f3c0:6ff0:33c2:15d8:5f50' in position 53 in the paragraph;
this doesn't match RFC 3849's suggested 2001:DB8::/32 address range or
RFC 4193's Unique Local Address range FC00::/7.
- and line 537: Found possible IPv6 address
'2001:15:2453:698a:9aa:253a:dcb5:981e' in position 264 in the paragraph;
this doesn't match RFC 3849's suggested 2001:DB8::/32 address range or
RFC 4193's Unique Local Address range FC00::/7."

Best regards, Tobias