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

From: Ari Keranen <[email-masked]>
Date: Mon, 04 Oct 2010 19:30:25 +0300

Hi Tom,

Thanks a lot for the review! Comments inline.

On 09/29/2010 08:36 PM, Henderson, Thomas R wrote:
> 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).

Good point. I changed the sentence describing this behavior into:

    Depending on local policy, the Responder MAY either abort the base
    exchange or continue HIP signaling without using an encrypted
    connection, if there was no HIP_TRANSPORT_MODE parameter in I2 or the
    parameter was empty.

> 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?

I assume you mean the following in 3.1:

    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.

Now when you mentioned this, I would lean towards making it a MUST here 
too. I was thinking about use cases where one would not want to reveal 
support for this in BeX, but can't find really compelling ones. And this 
is important behavior for interoperability, so it would make sense to 
have it as MUST.. Or what do you think, are there cases which would make 
SHOULD really useful?

> 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.

True, if we end up making this SHOULD level, that would make sense.

> 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).

Actually, the intention with that text was that one would not send those 
messages over the connection using the *old* keying material. This 
change was made when Jan commented that using the encrypted connection 
would result in unnecessary complexity with SA selection and 
retransmissions: 
http://www.ietf.org/mail-archive/web/hipsec/current/msg02975.html

That said, I could clarify that neither the new keying material can be 
used. I guess adding "nor over an encrypted connection using the newly 
created keying material" to the end would be sufficient. Or do you think 
it still needs the additional clarification?

> 3.3.2  ESP-TCP mode
> s/lower HIT/smaller HIT/

Good catch, fixed.

> 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."?

The "MUST" in 3.2. means that "MUST send over ESP as long as the ESP 
tunnel works". The latter part was implicit, but I could make it more 
explicit there. Also, hosts should not send other than 
encryption-reestablishment-messages outside of the encrypted 
connections; I'll clarify this too. I added to the end of that paragraph:

    Hosts SHOULD send
    outside of the encrypted connection only HIP messages that are used
    to reestablish the encrypted connection.  Especially, messages that
    are intended to be sent only encrypted (e.g., DATA messages using an
    encrypted transport mode) MUST NOT be sent before the encrypted
    connection is reestablished.

> 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/

Good catch here too.

> 5.  Security
>
> s/Thus, host requiring/Thus, a host requiring/

Fixed.

> 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?

I think it's enough if we propose such a value in this document (as we 
do) and make sure IANA uses that, like we've done with the other 
documents so far.

Cheers,
Ari

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 6 Oct 2010 21:49:02 -0700

>     support this extension but will not use any of the proposed modes.

Yes

> have it as MUST.. Or what do you think, are there cases which

I don't think it really matters from the Initiator's perspective whether it is a SHOULD or MUST, because this is a non-critical parameter.  Even if the supporting Responder MUST reply, the non-supporting Responder will not reply, and the Initiator has to handle both cases.

I'm neutral to whether this should be a SHOULD or MUST; suggest to just pick the same one in both cases.

> True, if we end up making this SHOULD level, that would make sense.

It seems to me to be somewhat independent of the SHOULD or MUST; it is a matter of whether to help the Responder to log the reason why the Initiator decided to shut down the association.

> messages over the connection using the *old* keying material. This

Yes, I read it the other way.

> it still needs the additional clarification?

I would be fine with your suggested brief change above.

> do) and make sure IANA uses that, like we've done with the other

OK

- Tom

---

From: Ari Keranen <[email-masked]>
Date: Mon, 11 Oct 2010 15:48:36 +0300

Tom,

Thanks for the follow-up comments, I've updated the draft accordingly. 
Details in-line.

On 10/07/2010 07:49 AM, Henderson, Thomas R wrote:
>>> 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?
>>
>> If the Initiator cannot or will not use any of the modes proposed
>> by the Responder, the Initiator SHOULD include an empty
>> Now when you mentioned this, I would lean towards making it a MUST
>> here too. I was thinking about use cases where one would not want
>> to reveal support for this in BeX, but can't find really
>> compelling ones. And this is important behavior for
>> interoperability, so it would make sense to have it as MUST.. Or
>> what do you think, are there cases which would make SHOULD really
>> useful?
>
> I don't think it really matters from the Initiator's perspective
> whether it is a SHOULD or MUST, because this is a non-critical
> parameter.  Even if the supporting Responder MUST reply, the
> non-supporting Responder will not reply, and the Initiator has to
> handle both cases.
>

You have a point; I changed this into SHOULD.

>>> 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.
>>
> It seems to me to be somewhat independent of the SHOULD or MUST; it
> is a matter of whether to help the Responder to log the reason why
> the Initiator decided to shut down the association.

OK, I changed the last paragraph into:

    Since the HIP_TRANSPORT_MODE parameter's type is not critical (as
    defined in Section 5.2.1 of [RFC5201]), a host not supporting this
    extension would simply reply with an acknowledgement UPDATE packet
    without a HIP_TRANSPORT_MODE parameter.  In such a case, depending on
    local policy as in mode negotiation during the base exchange, the
    host that requested the new transport mode MAY close the HIP
    association.  If the association is closed, the host closing the
    association SHOULD send a NO_VALID_HIP_TRANSPORT_MODE NOTIFY packet
    to the other host before closing the association.

I also clarified the negotiation in BeX section to have the same logic 
(should send the notify when aborting BeX due to HIP_TRANSPORT_MODE 
parameter; if there's no valid mode or the parameter was not there but 
is needed to continue). Now it says:

    Depending on local policy, the Responder MAY either abort the base
    exchange or continue HIP signaling without using an encrypted
    connection, if there was no HIP_TRANSPORT_MODE parameter in I2 or the
    parameter was empty.  If the Initiator selects a mode that the
    Responder does not support (and hence was not included in R1), the
    Responder MUST abort the base exchange.  If the base exchange is
    aborted due to (possibly lack of) HIP_TRANSPORT_PARAMETER, the
    Responder SHOULD send a NO_VALID_HIP_TRANSPORT_MODE NOTIFY packet
    (see Section 4) to the Initiator.

Cheers,
Ari