Subject: [Hipsec] more comments on hip-over-hip draft

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 5 Apr 2010 16:31:04 -0700

Ari,

Here are a few more comments on the HIP over HIP draft.

In section 3.1, it is not clear whether the hosts MUST use the negotiated
mode once it is negotiated for all subsequent messages while the association
is active (or until it is renegotiated via UPDATEs).   Suggest to clarify
this and what is the host behavior if it is expecting a mode but gets
another mode instead.

In section 3.1, it is not clear whether the order of these parameters
expresses a priority preference; plaese clarify.  It probably would be
easier to treat this as a prioritized list.

In section 3.2, would it be better if the sender was required to specify
the currently running mode as one of the options so the recipient could
always successfully bail out of the renegotiation without responding
with an error code?  It seems a bit cleaner to me than reporting an
error yet continuing on with the association as if nothing happened.

Section 3.3, please specify what a receiving host should do if these
ESP modes are mistakenly offered in the HIP_TRANSPORT_MODE parameter
despite ESP transport format not being used.

Section 3.3 has this comment:
   Instead, a host simply waits for the same time that
   would be taken by the maximum amount of retransmissions with
   unreliable transmission before concluding that there is no response.

I see a couple of issues with this advice.  First, a host may not want
to wait for the maximal number of TCP retransmissions before trying
a non-TCP approach to getting the message through.  Second, HIP process
may not have visibility into the maximum number of TCP retransmissions
anyway.  I would suggest to instead say:  "a host waits to detect that
the TCP connection has failed to retransmit the packet successfully
in a timely manner (such detection is platform- and policy-specific)
before concluding that there is no response."

Regards,
Tom

---

From: Ari Keranen <[email-masked]>
Date: Tue, 06 Apr 2010 18:43:56 +0300

Hi Tom,

Thanks a lot for the comments! Responses inline.

> easier to treat this as a prioritized list.

Good points. The section 3.1 says now:

    [...] first the Responder lists the supported
    modes in a HIP_TRANSPORT_MODE parameter (see Figure 1) in the R1
    packet.  The modes are listed in priority order; the more preferred
    mode(s) first.  If the Initiator supports, and is willing to use, any
    of the modes proposed by the Responder, it selects one of the modes
    by adding a HIP_TRANSPORT_MODE parameter containing the selected mode
    to the I2 packet.  Finally, if the Initiator selected one of the
    modes and the base exchange succeeds, hosts MUST use the selected
    mode for the following HIP signaling messages sent between them for
    the duration of the HIP association or until another mode is
    negotiated.

    If the Initiator cannot or will not use any of the modes proposed by
    the Responder, the Initiator SHOULD include an empty
    HIP_TRANSPORT_MODE parameter to the I2 packet to signal that it
    support this extension but will not use any of the proposed modes.
    Depending on local policy, the Responder MAY either abort the base
    exchange or continue HIP signaling without using an encrypted
    connection.  If the Initiator selects a mode that the Responder does
    not support (and hence was not included in R1), the Responder SHOULD
    reply with a NO_VALID_HIP_TRANSPORT_MODE NOTIFY packet (see
    Section 4) and abort the base exchange.

> error yet continuing on with the association as if nothing happened.

Makes sense. Although I would make the "currently running mode" an 
implicit option and the answer could always contain that mode even if 
the offer didn't. This way we would not have an error case for UPDATE 
without the currently used mode (and we would save a few bytes :).

I would change the 1st paragraph of 3.2 into:

    If a HIP hosts wants to change to a different transport mode (or
    start using a transport mode) some time after the base exchange, it
    sends a HIP UPDATE packet with a HIP_TRANSPORT_MODE parameter
    containing the mode(s) it would prefer to use.  The host receiving
    the UPDATE MUST respond with an UPDATE packet containing the mode
    that is selected as in the negotiation during the base exchange.  If
    the receiving host does not support, or is not willing to use, any of
    the listed modes, it MUST respond with an UPDATE packet containing
    only the currently used transport mode (even if one was not included
    in the previous UPDATE packet) and continue using it.

> despite ESP transport format not being used.

Added to the first paragraph:

    [...] If the ESP transport format is not used, these modes MUST
    NOT be offered in the HIP_TRANSPORT_MODE parameter.  If a
    HIP_TRANSPORT_MODE parameter containing an ESP transport mode is
    received but the ESP transport format is not used, a host MUST NOT
    select such a mode but act as specified in Section 3.1 (if performing
    a base exchange) or Section 3.2 (if performing an UPDATE) when no
    valid mode is offered.

I think this solves the problem cleanly and with smallest amount of new 
code paths.

> before concluding that there is no response."

Good point. Added your suggested text almost verbatim:

    [...] Instead, a host SHOULD wait to detect that the TCP
    connection has failed to retransmit the packet successfully in a
    timely manner (such detection is platform- and policy-specific)
    before concluding that there is no response.

Thanks,
Ari