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.
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
