Last Call Review of draft-ietf-hip-rfc5203-bis-09
review-ietf-hip-rfc5203-bis-09-secdir-lc-takahashi-2015-12-28-00

Hello,

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.

[overall feeling on this draft]

ready, and good to proceed

[overview]

This draft updates RFC 5203 to cope with HIPv2 (RFC 7401).
RFC 5203 specifies a registration mechanism for HIPv1 (RFC 5201).
Likewise, this draft specifies the mechanism for HIPv2.

[questions]

Below are simply clarification questions, and these do not block the further
process of this document.
I am not that familiar with HIP, so it would be helpful if you could provide
me some comments on them to deepen my understanding.

1. "If the requester has one or more suitable certificates, the host SHOULD
include them (or just the most suitable one)"(in section 3.3)

I wonder whether it would be better to let the requester send only the most
suitable certificate.
The requester may send multiple certificates, but it would be helpful if the
requester sends only the most suitable certificate, I guess. (It is easy to
process from the standpoint of the receiver, isn't it?) Would you explain
why the draft encourages to send multiple certificates rather than sending
only the most suitable certificate?

2. "it SHOULD send the registration request without the CERT parameter to
test whether the registrar accepts the request based on the host's
identity." (in Section 3.3)

In this situation, if a malicious party knows the identity of the requester,
the party can get the access right.
Is the identity protected so that no malicious party can get it?

3. "Other documents will define specific values for registration types. See
Section 7 for more information" (Section 4.3)

I looked at Section 7 to understand the types and values of Reg Type, but I
guess the section does not define any on them.
Are the types and values completely the same as the ones defined by RFC
5203?

4. "Insufficient resource" and "Invalid certificate" (in the table in
Section 7) When a requester sends requests without sending CERT parameters,
the requester expects to be authenticated based on its identity.
But sometimes it fails.
In this case, which of the failure type will be used? "Insufficient
resources"? or "Invalid certificate"? or none of them?

Thank you for your kind contributions.
Take