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