Skip to main content

Encrypted Signaling Transport Modes for the Host Identity Protocol
draft-ietf-hip-over-hip-06

Yes

(Gonzalo Camarillo)
(Jari Arkko)
(Ralph Droms)

No Objection

(Peter Saint-Andre)
(Robert Sparks)
(Russ Housley)
(Stewart Bryant)

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

Gonzalo Camarillo Former IESG member
Yes
Yes () Unknown

                            
Jari Arkko Former IESG member
(was Discuss) Yes
Yes (2011-03-10) Unknown

                            
Ralph Droms Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2011-03-02) Unknown
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.
Dan Romascanu Former IESG member
No Objection
No Objection (2011-03-02) Unknown
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. 
Lars Eggert Former IESG member
(was Discuss) No Objection
No Objection (2011-03-01) Unknown
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?
Peter Saint-Andre Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection (2011-03-02) Unknown
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, ]
                 PUZZLE,
                 DIFFIE_HELLMAN,
                 HIP_TRANSFORM,
                 HOST_ID,
                 [ 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,]
                 SOLUTION,
                 DIFFIE_HELLMAN,
                 HIP_TRANSFORM,
                 ENCRYPTED { HOST_ID } or HOST_ID,
->              [ HIP_TRANSPORT_MODE, ]
                 [ ECHO_RESPONSE_SIGNED ,]
                 HMAC,
                 HIP_SIGNATURE
                 <, 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?
Stewart Bryant Former IESG member
No Objection
No Objection () Unknown