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