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

[Miika Komu <[e-mail]>]

Hi Tom and Jeff,

> -----Original Message-----
> From: Tom Henderson [mailto:[e-mail]]
> Sent: Tuesday, March 14, 2017 8:30 PM
> To: Jeff Ahrenholz <[e-mail]>
> Cc: Miika Komu <[e-mail]>; Gonzalo Camarillo
> <[e-mail]>; HIP <[e-mail]>
> 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?