Re: WGLC: draft-ietf-hip-native-nat-traversal-15

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

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

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

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

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

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

> 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

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?

_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec