To: Jeff Ahrenholz <j.ahrenholz@temperednetworks.com>, Tom Henderson
 <tomhend@u.washington.edu>, Gonzalo Camarillo
 <Gonzalo.Camarillo@ericsson.com>, HIP <hipsec@ietf.org>
References: <f70ecd7b-9558-806e-319c-9e85f263e1e3@ericsson.com>
 <alpine.LRH.2.01.1702190718360.26978@hymn03.u.washington.edu>
 <98E7B40F-8DB4-45C6-8550-9C1DA71BBF08@temperednetworks.com>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <6c9e9624-537d-3355-772f-23212543c9d9@ericsson.com>
Date: Thu, 9 Mar 2017 18:01:45 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <98E7B40F-8DB4-45C6-8550-9C1DA71BBF08@temperednetworks.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/eE8VZMhmt7yVVBxbulBUVU1Ewqs>
Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal-15
Precedence: list

Hi Jeff,

On 03/09/2017 05:39 PM, Jeff Ahrenholz wrote:
>> 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 s=
o-
>>        called Tr value in ICE) unless they have exchange some other tr=
affic
>>        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_KE=
EPALIVE"
>> NOTIFY message type for this purpose?
>
> 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=20
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 have a more general question about NAT keepalives based on some recen=
t experiences with implementing/fielding this approach.
> (My comments below shouldn=E2=80=99t hold up the publishing of this dra=
ft...)
>
> Have we considered using UPDATE packets versus NOTIFY?
> What are the tradeoffs?

This is possible, but probably three options is too much?

> 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 second=
s (no need for both)
> - if you=E2=80=99re 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 =3D=3D new SPI), wh=
ich will help HIP middleboxes, and will help endpoints know which SA is b=
eing kept alive
> - 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.

> What happens if you don=E2=80=99t receive keepalives?
> - if your UPDATE goes unacknowledged, do something -- retransmit, or st=
art an address check, rekey, or teardown procedure

Good point.

> Potential drawbacks:
> - is UPDATE considered too heavyweight?
> - UPDATE doesn=E2=80=99t have a purpose code, is the swiss army knife o=
f HIP packets (rekey, readdress, address check, etc.)
> - UPDATE requires established state; NOTIFY does not

UPDATE is certainly more heavy-weight especially since it occurs every=20
15 seconds. We have three choices of which we could select just one or=20
two (probably three is too much):

1. ICMPv6
2. NOTIFY
3. UPDATE

What do you think?