Hi Tom and Jeff, > -----Original Message----- > From: Tom Henderson [mailto:[email protected]] > Sent: Tuesday, March 14, 2017 8:30 PM > To: Jeff Ahrenholz <[email protected]> > Cc: Miika Komu <[email protected]>; Gonzalo Camarillo > <[email protected]>; HIP <[email protected]> > Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15 > > > > > 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.?
Jeff, this would occur *inside* the tunnel, so it would be prevented in the end-host directly (which seems a bit unlikely scenario to me) > >> 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. thinking about this option further, I think it's probably not a good idea after all to enforce the controlling host send UPDATEs every 15 seconds: 1. A server connected to a large number of clients would get too much unnecessary computational load 2. This option would trump the rest of the options - Detection logic would be become cumbersome (node has to decide based on the other side if e.g. ICMPv6 keepalives are needed) - So it would be easier just to implement controlled host sending UPDATEs (which leads to [1]) > >>> 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 (?). NOTIFY messages are not acked anyway. They are sent every 15 secs, so couple of them can be easily lost. (ICE keepalives don't have acknowledgements either) > >> 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, this sounds fine to me. Normal UPDATEs over UDP should be fine, but I think we shouldn't device a new UPDATE mechanism tied to controlled role (sorry for thinking aloud :) Jeff, is this ok for you?
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
