On Thu, 9 Mar 2017, Jeff Ahrenholz wrote:
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?
I might suggest to recommend NOTIFY (and define the keepalive) and state that
other messages including ICMPv6 or UPDATE may be substituted. If there is a
need for bi-directional connectivity checking, recommend to use UPDATE; if
there are specific known scenarios where an ICMPv6 is recommended instead,
state those scenarios.
- Tom
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
