Re: WGLC: draft-ietf-hip-native-nat-traversal-15

Hi,

On 03/15/2017 04:37 PM, Jeff Ahrenholz wrote:
>>> I might suggest to recommend NOTIFY (and define the keepalive) and state
>>> that other messages including ICMPv6 or UPDATE may be substituted.  If
>>> there is a need for bi-directional connectivity checking, recommend to use
>>> UPDATE;  if there are specific known scenarios where an ICMPv6 is
>>> recommended instead, state those scenarios.
>>
>> Tom, this sounds fine to me. Normal UPDATEs over UDP should be fine, but I
>> think we shouldn't device a new UPDATE mechanism tied to controlled role
>> (sorry for thinking aloud :)
>>
>> Jeff, is this ok for you?
>
> Yes, this sounds good.

I have reflected this discussion now in section 5.3 of the preliminary 
version:

http://mkomu.kapsi.fi/temp/draft-hip-native-nat-traversal-19.txt

    The RECOMMENDED encoding format for keepalives is HIP NOTIFY packets
    as specified in [RFC7401] with Notify message type field set to
    NAT_KEEPALIVE [TBD by IANA: 16384] and with an empty Notification
    data field.  It is worth noting that sending of such a HIP NOTIFY
    message MAY be omitted if the host is actively (or passively) sending
    other traffic to the peer host over the UDP tunnel associate with the
    host association (and IPsec security associations since the same port
    pair is reused) during the Tr period.  For instance, the host MAY
    actively send ICMPv6 requests (or respond with an ICMPv6 response)
    inside the ESP tunnel to test the health of the associated IPsec
    security associations.  Alternatively, the host MAY use UPDATE
    packets as a substitute.  A minimal UPDATE packet would consist of a
    SEQ and ECHO_REQ_SIGN parameters, and a more complex would involve
    rekeying procedures as specified in section 6.8 in [RFC7402].  It is
    worth noting that a host actively sending periodic UPDATE packets to
    a busy server may increase the computational load of the server since
    it has to verify HMACs and signatures in UPDATE messages.