Encrypted Signaling Transport Modes for the Host Identity Protocol
RFC 6261

Note: This ballot was opened for revision 06 and is now closed.

(Jari Arkko) (was Discuss) Yes

(Gonzalo Camarillo) Yes

(Ralph Droms) Yes

(Stewart Bryant) No Objection

(Lars Eggert) (was Discuss) No Objection

Comment (2011-03-01)
No email
send info
INTRODUCTION, paragraph 2:
>         Host Identity Protocol Signaling Message Transport Modes

  I think this title sets a record for most number of consecutive nouns.
  Can we maybe stick a verb and an object in there to improve clarity?

Section 4.2., paragraph 4:
>    Since TCP provides reliable transport, the HIP messages sent over TCP
>    MUST NOT be retransmitted for the purpose of achieving reliable
>    transmission.

  Does this mean that HIP messages may be retransmitted for other
  purposes? Or it this phrasing inaccurate?

(Adrian Farrel) No Objection

Comment (2011-03-02 for -)
No email
send info
I was surprised to see no discussion of TCP-AO.


I agree with the Discuss about downgrade attacks. These seem to be particularly open in the mobility/multi-homing case described in Section 6.

(Russ Housley) No Objection

(Dan Romascanu) No Objection

Comment (2011-03-02 for -)
No email
send info
The OPS-DIR review performed by David Black pointed to the following problem: 

The draft is somewhat inconsistent about support for a HIP node policy that requires use of an encrypted transport for HIP signaling.  Section 3.3 provides an essential building block, the error signaling mechanism to indicate that an encrypted transport is required and none was proposed.  On the other hand, Section 5 is unclear with respect to this class of policy in that it strongly recommends (SHOULD) fallback to a non-encrypted HIP connection but requires (MUST) that "messages that are intended to be sent only encrypted" not be sent unencrypted.  If the "messages that are intended to be sent only encrypted" are all HIP messages after the base exchange, these two requirements appear to be in conflict.

I suggest adding a short explanation to Section 5 of what would be reasonable vs. unreasonable policy for "messages that are intended to be sent only encrypted", and how to use the Section 3.3 error report when a failed encrypted connection is recovered by attempting to fall back to an unencrypted connection when HIP node policy requires encryption of all signaling after the base exchange.

The change was agreed by the document editor and the OPS-DIR reviewer and needs to find its way either in a revised I-D or in a note to the RFC Editor. 

(Peter Saint-Andre) (was Discuss) No Objection

(Robert Sparks) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2011-03-02)
No email
send info
1) It would have helped me had the packet figures from RFC 5201 were added here (assume I'm getting it right):

The HIP header values for the R1 packet:

      IP ( HIP ( [ R1_COUNTER, ]
                 [ ECHO_REQUEST_SIGNED, ]
->              [ HIP_TRANSPORT_MODE,]
                 HIP_SIGNATURE_2 )
                 <, ECHO_REQUEST_UNSIGNED >i)

Not sure if it's exactly in the right place.  This would make it clear that the transport mode is signed.  Same for I2:

   IP ( HIP ( [R1_COUNTER,]
                 ENCRYPTED { HOST_ID } or HOST_ID,
->              [ HIP_TRANSPORT_MODE, ]
                 [ ECHO_RESPONSE_SIGNED ,]
                 <, ECHO_RESPONSE_UNSIGNED>i ) )

2) Sec 4.2: Difficult to parse the sentence Lars has a discuss on.

3) Why SHOULD the TCP originator use the source port they said they'd use? I could understand a MUST or with NATs a MAY but can't figure why SHOULD?