Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15

[Jeff Ahrenholz <[e-mail]>]

> 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