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

[Jeff Ahrenholz <[e-mail]>]

> 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 forgot about that ‘ping6 destination-HIT’ inside-the-tunnel option.

Certainly, this would be a good test of tunnel liveliness.
 
I’m a little concerned about implementation of this -- if you think about the control plane differing from the data plane (i.e. maybe userspace control daemon managing kernel IPsec state.) The control plane would be reaching into the data plane. What if sysadmin administratively turned off ping6 echo replies, local firewall blocks, etc.?

> Only one side sending the UPDATE is possible because the CONTROLLED role
> remains throughout the session.

OK, this makes sense. The controller [host having the larger HIT] can send the UPDATEs.
    
>> 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.

Note that just using NOTIFY, we’re NOT supposed to change state (RFC 7401 section 5.2.19).
So I guess reacting to lost NOTIFY-keepalives is forbidden (?).

> 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?

Maybe we could leave the door open for implementation flexibility?

While three options is a bit much, it seems very flexible to allow for 1, 2, and/or 3.

(“Three shall be the number of the counting and the number of the counting shall be three.”)

-Jeff