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

From: Jeff Ahrenholz <[email-masked]>
Date: Thu, 9 Mar 2017 15:39:31 +0000

> 3) In section 4.10 (NAT keepalives), it states:
>    
>        Both a registered client and relay server SHOULD
>        send a HIP NOTIFY packets to each other every 15 seconds (the so-
>        called Tr value in ICE) unless they have exchange some other traffic
>        over the used UDP ports.
>    
>    However, I couldn't find an explanation anywhere (also in RFC 5770) about
> how to code this NOTIFY.  Would it make sense to define also a "NAT_KEEPALIVE"
> NOTIFY message type for this purpose?

Tom has a good point here, about how to code the NOTIFY keepalive.

I have a more general question about NAT keepalives based on some recent experiences with implementing/fielding this approach.
(My comments below shouldn’t hold up the publishing of this draft...)

Have we considered using UPDATE packets versus NOTIFY?
What are the tradeoffs?

I was thinking about the following advantages of the UPDATE:
- SEQ protects against packet replays
- instead of each endpoint periodically tx NOTIFY, one side could send an UPDATE and request acknowledgement (a bi-directional check)
- you could send an UPDATE or an UPDATE acknowledgement every 15 seconds (no need for both)
- if you’re not sending data, but only receiving, you can still do a bi-directional check to ensure liveness (and vice versa)
- you can include ESP_INFO with SPI number (old SPI == new SPI), which will help HIP middleboxes, and will help endpoints know which SA is being kept alive
- NOTIFY should not be used to change state (RFC 7401)

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

Potential drawbacks:
- is UPDATE considered too heavyweight?
- UPDATE doesn’t have a purpose code, is the swiss army knife of HIP packets (rekey, readdress, address check, etc.)
- UPDATE requires established state; NOTIFY does not

thanks,
-Jeff

---

From: Miika Komu <[email-masked]>
Date: Thu, 9 Mar 2017 18:01:45 +0200

Hi Jeff,

> Tom has a good point here, about how to code the NOTIFY keepalive.

yes, I agree. The document lists also another option:

4.10.  NAT Keepalives

Likewise, if a host has
    not sent any data to another host it has established a host
    association in the ICE-HIP_UDP mode within 15 seconds, it MUST send
    either a HIP NOTIFY packet or, alternatively, an ICMPv6 echo request
    inside the related ESP tunnel.

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.)

> Have we considered using UPDATE packets versus NOTIFY?

This is possible, but probably three options is too much?

> - NOTIFY should not be used to change state (RFC 7401)

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

> - if your UPDATE goes unacknowledged, do something -- retransmit, or start an address check, rekey, or teardown procedure

Good point.

> - UPDATE requires established state; NOTIFY does not

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?

---

From: Jeff Ahrenholz <[email-masked]>
Date: Thu, 9 Mar 2017 16:23:09 +0000

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

> remains throughout the session.

OK, this makes sense. The controller [host having the larger HIT] can send the UPDATEs.
    
>> - if your UPDATE goes unacknowledged, do something -- retransmit, or start an address check, rekey, or teardown procedure

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 (?).

> two (probably three is too much):

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

---

From: Miika Komu <[email-masked]>
Date: Tue, 14 Mar 2017 11:19:29 +0200

Hi Tom,

On 02/19/2017 05:18 PM, Tom Henderson wrote:
> Hello, I have read the latest (-17) draft and sent some purely editorial
> comments to Miika.  I had a few non-editorial questions and comments.

thanks for the feedback. I fixed the editorial issues in version 18:

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-18

I did not fix these (because I would prefer to keep the artwork small):

* Figure acronym un-abbreviations were not included
* ISPI and OSPI acronyms remain

(Also, if we use long parameter names in figures, I think all names 
should be long, not just mobility related)

A couple of fixes for me to edit:

* Appendix B: normative vs non-normative terminology
* Alex Elsayed reported imbalanced parentheses in one picture

These and the non-editorial comments from Tom and Jeff will be resolved 
in the next version.

---

From: Tom Henderson <[email-masked]>
Date: Tue, 14 Mar 2017 11:18:57 -0700 (PDT)

On Tue, 14 Mar 2017, Miika Komu wrote:

> (Also, if we use long parameter names in figures, I think all names should be 
> long, not just mobility related)

Miika, as I was preparing those editorial comments and I read onward, I realized that addressing some of my comments might raise some internal consistency issues, or cause some more significant editing, so I am fine if you decide that they are too disruptive.

- Tom

---

From: Tom Henderson <[email-masked]>
Date: Tue, 14 Mar 2017 11:29:52 -0700 (PDT)

> 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

---

From: Miika Komu <[email-masked]>
Date: Wed, 15 Mar 2017 13:10:18 +0000

Hi Tom and Jeff,

> -----Original Message-----
> From: Tom Henderson [mailto:[email-masked]]
> Sent: Tuesday, March 14, 2017 8:30 PM
> To: Jeff Ahrenholz <[email-masked]>
> Cc: Miika Komu <[email-masked]>; Gonzalo Camarillo
> <[email-masked]>; HIP <[email-masked]>
> Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15
> 
> 
> 
> 
> >> 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.
> >
> > 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).

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)

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

---

From: Jeff Ahrenholz <[email-masked]>
Date: Wed, 15 Mar 2017 14:37:30 +0000

> Jeff, is this ok for you?

Yes, this sounds good.

thanks,
-Jeff

---

From: Miika Komu <[email-masked]>
Date: Tue, 21 Mar 2017 13:14:08 +0200

Hi,

a preliminary version here:

http://mkomu.kapsi.fi/temp/draft-hip-native-nat-traversal-19.txt

Not yet on IETF site since I missed the cut-off deadline.

On 02/19/2017 05:18 PM, Tom Henderson wrote:
> 1) In appendix D, it states:
>
>    o  A minimal implementation would conform only to Section 4.7.1 or
>       Section 4.7.2, thus merely tunneling HIP control and data traffic
>       over UDP.  The drawback here is that it works only in the limited
>       cases where the Responder has a public address.
>
> However, in section 5.4, it states:
>
>    Implementations conforming to this specification MUST implement both
>    UDP-ENCAPSULATION and ICE-HIP-UDP modes.
>
> The contradictory text should be resolved.  In my opinion,
> implementations that want to support only the UDP-ENCAPSULATION mode
> (and its restricted set of use cases) should be allowed.  However, I
> don't know what might need to be done to avoid a situation where a
> product claims RFC compliance but only implements one of the two modes.
> It could perhaps be avoided by a statement that states "Implementations
> that choose to only support the UDP-ENCAPSULATION mode should clarify
> this point when any claims of <RFC-to-be> compliance are made."

now it says:

"Implementations conforming to this specification MUST implement UDP-
ENCAPSULATION and SHOULD implement ICE-HIP-UDP modes."

I can also add some other wording if it is really necessary (and common 
in RFC specifications). Btw, while ICE lite is not really the same as 
ICE-HIP-UDP, ICE lite vs full ICE is not really enforced in the 
specification.

> 2) Appendix C states:
>
>    o  The considerations on Diffserv Codepoint markings in ICE are not
>       applicable to HIP since Diffserv is not used in HIP.
>
> Why wouldn't the same issues arise in HIP as in ICE on this matter?
> Should this draft instead copy or reference the RFC 5245 recommendation:
>
>    If the agent is using Diffserv Codepoint markings [RFC2475] in its
>    media packets, it SHOULD apply those same markings to its
>    connectivity checks.
>
> Also, I don't think that the HIP control plane should be excluded from
> using diffserv.

done.

> However, I couldn't find an explanation anywhere (also in RFC 5770)
> about how to code this NOTIFY.  Would it make sense to define also a
> "NAT_KEEPALIVE" NOTIFY message type for this purpose?
>
> Once these issues are resolved, I think that the draft would be ready to
> publish.

done.

P.S. The new version of the draft also includes some nits from Alex Elsayed.

---

From: Miika Komu <[email-masked]>
Date: Tue, 21 Mar 2017 13:26:03 +0200

Hi Tom,

On 03/14/2017 11:19 AM, Miika Komu wrote:

[..]

 > [...]

so the appendix was using normative terminology which was a bit strange. 
As a quick fix, I thought about moving this appendix to the body, but 
after reading this extension (that was inherited as a legacy from the 
earlier specification) I decided to remove it. The section basically 
suggested allowing source routing via HIP relay for the sake of 
compatibility with RVS servers. I think this could be exploited in a bad 
way to DoS other hosts. I think it is more secure if the HIP relay only 
forwards inbound packets, not outbound. If you disagree with this 
change, please discuss on the list.

---

From: Miika Komu <[email-masked]>
Date: Tue, 21 Mar 2017 13:30:59 +0200

Hi,

>> Jeff, is this ok for you?

I have reflected this discussion now in section 5.3 of the preliminary 
version:

    The RECOMMENDED encoding format for keepalives is HIP NOTIFY packets
    as specified in [RFC7401] with Notify message type field set to
    NAT_KEEPALIVE [TBD by IANA: 16384] and with an empty Notification
    data field.  It is worth noting that sending of such a HIP NOTIFY
    message MAY be omitted if the host is actively (or passively) sending
    other traffic to the peer host over the UDP tunnel associate with the
    host association (and IPsec security associations since the same port
    pair is reused) during the Tr period.  For instance, the host MAY
    actively send ICMPv6 requests (or respond with an ICMPv6 response)
    inside the ESP tunnel to test the health of the associated IPsec
    security associations.  Alternatively, the host MAY use UPDATE
    packets as a substitute.  A minimal UPDATE packet would consist of a
    SEQ and ECHO_REQ_SIGN parameters, and a more complex would involve
    rekeying procedures as specified in section 6.8 in [RFC7402].  It is
    worth noting that a host actively sending periodic UPDATE packets to
    a busy server may increase the computational load of the server since
    it has to verify HMACs and signatures in UPDATE messages.