Hi Jeff,
On 03/09/2017 05:39 PM, Jeff Ahrenholz wrote:
3) In section 4.10 (NAT keepalives), it states:
Both a registered client and relay server SHOULD
send a HIP NOTIFY packets to each other every 15 seconds (the so-
called Tr value in ICE) unless they have exchange some other traffic
over the used UDP ports.
However, I couldn't find an explanation anywhere (also in RFC 5770) about
how to code this NOTIFY. Would it make sense to define also a "NAT_KEEPALIVE"
NOTIFY message type for this purpose?
Tom has a good point here, about how to code the NOTIFY keepalive.
yes, I agree. The document lists also another option:
4.10. NAT Keepalives
Likewise, if a host has
not sent any data to another host it has established a host
association in the ICE-HIP_UDP mode within 15 seconds, it MUST send
either a HIP NOTIFY packet or, alternatively, an ICMPv6 echo request
inside the related ESP tunnel.
Actually ICMPv6 would be my personal choice as a implementer instead of
NOTIFY. You can also detect connectivity problems at the data plane this
way and trigger a LOCATOR UPDATE.
(ICMPv6 is not a control plane keepalive, but since the control and data
plane share the same port, this does not matter.)
I have a more general question about NAT keepalives based on some recent
experiences with implementing/fielding this approach.
(My comments below shouldn’t hold up the publishing of this draft...)
Have we considered using UPDATE packets versus NOTIFY?
What are the tradeoffs?
This is possible, but probably three options is too much?
I was thinking about the following advantages of the UPDATE:
- SEQ protects against packet replays
- instead of each endpoint periodically tx NOTIFY, one side could send an
UPDATE and request acknowledgement (a bi-directional check)
- you could send an UPDATE or an UPDATE acknowledgement every 15 seconds (no
need for both)
- if you’re not sending data, but only receiving, you can still do a
bi-directional check to ensure liveness (and vice versa)
- you can include ESP_INFO with SPI number (old SPI == new SPI), which will
help HIP middleboxes, and will help endpoints know which SA is being kept alive
- NOTIFY should not be used to change state (RFC 7401)
Only one side sending the UPDATE is possible because the CONTROLLED role
remains throughout the session.
What happens if you don’t receive keepalives?
- if your UPDATE goes unacknowledged, do something -- retransmit, or start an
address check, rekey, or teardown procedure
Good point.
Potential drawbacks:
- is UPDATE considered too heavyweight?
- UPDATE doesn’t have a purpose code, is the swiss army knife of HIP packets
(rekey, readdress, address check, etc.)
- UPDATE requires established state; NOTIFY does not
UPDATE is certainly more heavy-weight especially since it occurs every
15 seconds. We have three choices of which we could select just one or
two (probably three is too much):
1. ICMPv6
2. NOTIFY
3. UPDATE
What do you think?
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
