Re: [Hipsec] WGLC: draft-ietf-hip-over-hip-01

["Henderson, Thomas R" <[e-mail]>]

Gonzalo and Ari, here are a few comments on this draft.

3.1  Mode Negotiation

In the second paragraph, perhaps clarify that if either an empty HIP_TRANSPORT_MODE parameter or the absence of a HIP_TRANSPORT_MODE parameter in the I2 packet will invoke the policy decision by the responder (presently, it does not talk about what to do if no parameter is returned in the I2).

3.2  Mode Negotiation after HIP Base Exchange

During the base exchange in 3.1, the initiator is not required to respond (it is a SHOULD) but here, it is a MUST.  I think it probably should be relaxed to a SHOULD, or if not, can you please clarify why it is a MUST here but not in 3.1?

Likewise, at the end of this section, it probably should be stated that the host that receives the acknowledged UPDATE that does not contain any parameter will make a local policy decision whether to continue or close the association.  If it were to decide to close the association, perhaps it would be good practice to have it issue a Notify before it closes down.

3.3   HIP Messages on Encrypted Connections

   "HIP messages that result in changing or generating new keying
   material, i.e., the base exchange and re-keying UPDATE messages, MUST
   NOT be sent over an encrypted connection that is created using the
   keying material that is being changed."

I think that the above could be more clearly stated as:

   "HIP messages that result in changing or generating new keying
   material, i.e., the base exchange and re-keying UPDATE messages, MUST
   NOT be sent over an encrypted connection using the newly created
   keying material.  It should be obvious that messages that generate
   new keying material cannot be sent over sessions that require the
   keying material to already be in place, but this statement pertains
   to the case in which one side of the association has obtained the
   new keying material but the other has not, such as an R2 or UPDATE
   ACK packet."

(if you agree that the above is what is intended).

3.3.2  ESP-TCP mode

s/lower HIT/smaller HIT/

3.4  Recovering from Failed Encrypted Connections

   "Hence, while listening for incoming HIP messages on the
   encrypted connection, hosts MUST still accept incoming HIP messages
   using the same transport method (e.g., UDP or plain IP) that was used
   for the base exchange.  When responding to a HIP message sent outside
   of encrypted connection, the response MUST be sent using the same
   transport method as the original message used."

It seems to me that the specification allows a host to negotiate the use of encrypted mode, but then can disregard the "MUST send over ESP" (seciton 3.2) and send outside of the security association, and the peer must use non-encrypted messaging according to the above text.  Is this what is intended, or should there be some statement such as "if the host receives a HIP message outside of an encrypted connection when the encrypted mode has previously been negotiated, it MAY or SHOULD conclude that the ESP association is failed and must be restarted."?

4.  Notify Packet Types

The indentation of the last paragraph should be moved leftward.

s/If a host sends UPDATE/If a host sends an UPDATE/
s/it sends back/the receiving host sends back/

5.  Security

s/Thus, host requiring/Thus, a host requiring/

6.  IANA

Should the document specify to IANA that whatever type value is selected must have lower bit equal to zero, so that the parameter is interpreted as being non-critical?


Regards,
Tom