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

From: Miika Komu <[email-masked]>
Date: Thu, 23 Jun 2016 17:45:31 +0300

FYI,

my original concerns are now addressed in the 12 version of the draft. 
Regarding to my last question on OSPI and ISPI, I think it is better to 
keep things as they are (i.e. it is not mandatory for the Initiator to 
even have a HIP relay). I discussed the topic with Ari and this follows 
better the ICE methodology.

On 02/22/2016 05:30 PM, Miika Komu wrote:
> Hi Ari,
>
> below is more detailed list of the nits and also some technical comments
> about the protocol.
>
> On 02/16/2016 04:01 PM, Ari Keränen wrote:
>> On 12/02/16 22:59, Miika Komu wrote:
>>> Hi,
>>>
>>> On 01/29/2016 02:32 PM, Gonzalo Camarillo wrote:
>>>> Hi,
>>>>
>>>> I would like to start a WGLC on the following draft. This WGLC will end
>>>> on February 12th:
>>>>
>>>> https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/
>>>>
>>>> Please, send your comments to this list.
>>>
>>> in general, the draft should have a short intro to the NAT traversal
>>> procedure and re-introduce some terms even though it all is specified in
>>> RFC5770. This would make the draft a bit easier to read. I have also
>>> some other nits which I'll send a bit later.
>>
>> Thanks for the review Miika! Also Petri commented along the same lines.
>> We'll add some intro text to the draft to address this.
>
>  > 2.  Terminology
>
> I would repeat some of the terms used in RFC5770. Particularly these
> would be useful:
>
> * relayed address
> * server reflexive candidate
> * relayed candidate
> * mapped address
>
> They are used the text and it would be nice to make the draft a bit more
> self-explanatory.
>
> I would also suggest to explain the ICE term "permission" here.
>
>  > 3.  Protocol Description
>
> I would suggest to add a small intro here of the entire process
> (registration, discovery of relay, base exchange, hole punching, ESP). A
> picture similar to figure 1 in RFC5770 would be nice.
>
>  > 3.1.  Relay Registration
>
>  > Section 3.3 at [I-D.ietf-hip-rfc5203-bis]), and the relay has
>
> at -> in
>
>  > 3.2.  Forwarding Rules and Permissions
>  >
>  > Permissions are not required for the connectivity checks, but if a
>  > relayed address is selected to be used for data, the registered host
>  > MUST send an UPDATE message [RFC7401] with a PEER_PERMISSION
>  > parameter (see Section 4.2) with the address of the peer and the
>  > outbound and inbound SPI values the host is using with this peer.
>
> PEER_PERMISSION is not a part of RFC5770, why is it introduced here?
>
> The description is missing also the destination where this message is to
> be sent (it is the relay).
>
>  > 3.3.  Relaying UDP Encapsulated Data and Control Packets
>
>  > When a host wants to send a HIP control packet (such as a
>  > connectivity check packet) to a peer via the data relay, it MUST add
>
> * wants -> intends (machines don't have a will, at least yet :)
> * it -> ambiguous, should be "the host"
> * via the *peer's* data relay, right? I mean both hosts may have their
> own data relays.
>
>  > send it to the data relay's address.  The data relay MUST send the
>
> address of the data relay of the peer (right?)
>
>  > When a host wants to send a UDP encapsulated ESP packet to a peer via
>  > the data relay, it MUST have an active permission at the data relay
>  > for the peer with the outbound SPI value it is using.
>
> *peer* data relay
>
>  > The host MUST send the UDP encapsulated ESP packet to the data
> relay's address.
>
> What host? Whose data relay?
>
> * wants -> intends
> * peer's data relay (right? please correct twice)
>
> The third ("If the data relay..."), fourth (When a host) and fifth
> ("When the data relay...") paragraphs appear a bit of
> redundant/overlapping, perhaps it is better to merge them together.
>
> Please state the owner of the data relay (i.e. registered host) in all
> cases. The data relay only relays data traffic to one way (to the
> registered host), right?
>
>  > 3.4.  Candidate Gathering
>
>  > Gathering of candidates MAY also be performed like specified in
>
> like -> as
>
>  > 3.7.  Connectivity Check Pacing Negotiation
>
>  > the check pacing negotiation -> the connectivity check pacing
> negotiation
>
>  > 3.8.  Connectivity Checks
>
>  > [RFC5770] but instead of STUN packets, the connectivity checks are
>
> ..., but instead of STUN packets,,,
>
>  > checklist and start check transactions every Ta milliseconds as long
>
> ..start *to* check..
>
>  > The UPDATE packets that acknowledge a
>  > connectivity check requests MUST be sent from the same address that
>  > received the check and to the same address where the check was
>  > received from.
>
> it would be easier to read this in singular form rather than plural:
>
> An/Any UPDATE packet that acknowledges a connectivity check request MUST
> originate from the same address that
> was used to receive the check and destined to the same address where the
> check was
> received from.
>
> (please note that I changed the wording a bit)
>
>  > The acknowledgment UPDATE packets MUST contain a MAPPED_ADDRESS
>  > parameter with the port, protocol, and IP address of the address
>  > where the connectivity check request was received from.
>
> same here:
>
> An/Any acknowledgment UPDATE packet MUST...
>
>  > If the controlling host
>  > does not have any data to send, it SHOULD send an ICMP echo request
>
> ICMPv6 inside the tunnel - right?
>
>  > using the nominated pair to signal to the controlled host that it can
>
> ... in order to signal ...
>
>  > stop checks and start using the nominated pair.  When the controlled
>  > host receives the first ESP packet, it MUST select that pair for use
>  > and send back an ESP packet to acknowledge a working candidate pair.
>  > If the controlled host does not have any data to send, it SHOULD send
>  > an ICMP echo request.
>
> ICMPv6 inside the tunnel?
>
>  > If the connectivity checks failed the hosts SHOULD notify each other
>  > about the failure with a CONNECTIVITY_CHECKS_FAILED Notify Message
>  > Type [RFC5770].
>
> ... failed, the hosts SHOULD ...
>
> It would also worthwhile to explain how the connectivity end in the case
> of success, maybe through an example.
>
>  > 3.9.  NAT Keepalives
>
>  > To keep the NAT bindings towards the HIP relay server and the HIP
>  > data relay alive, if a registered host has not sent any data or
>  > control messages to the relay for 15 seconds, it MUST send a HIP
>  > NOTIFY packet to the relay.
>
> When a registered host has not sent any data or control messages to the
> relay for 15 seconds,
> it MUST send a HIP NOTIFY packet to the relay in order to keep the NAT
> bindings towards the HIP relay server and the HIP
> data relay alive.
>
>  > Likewise, if the host has not sent any
>  > data to a host it has security association and has run connectivity
>
> ... to a *peer* host ...
> ... and with which it has run ...
>
>
>  > checks with, it MUST send either a HIP NOTIFY packet or an ICMP echo
>  > request using the same locators as the security association is using.
>
> ICMPv6 inside the tunnel, right?
>
> ... security association is based on.
>
>  > 3.10.  Handling Conflicting SPI Values
>
>  > Since the HIP data relay determines from the SPI value to which peer
>  > an ESP packet should be forwarded, the outbound SPI values need to be
>  > unique for each relayed address registration.  Thus, if a registered
>  > host detects that a peer would use an SPI value that is already used
>  > with another peer via the relay, it MUST NOT select the relayed
>  > address for use.
>
> This is a bit confusing, do you mean inbound SPI values? Or from which
> viewpoint is this written?
>
>  > However, a host with many peers MAY decrease the odds of a conflict
>  > by registering more than one relayed address using different local
>  > addresses.
>
> local addresses? Do you mean in the case the host is multihomed? Or just
> by using different SPI values?
>
>  > 4.1.  RELAYED_ADDRESS and MAPPED_ADDRESS Parameters
>
>  > This document specifies only use of UDP relaying and...
>
> ... the use of ...
>
>  > 4.2.  PEER_PERMISSION Parameter
>
>  > The parameter is used for setting up and refreshing forwarding rules
>  > and permissions at the data relay for data packets.
>
> ... and the permission for data packets at the data relay.
>
>  > OSPI      the outbound SPI value the registered host is using for
>  >           the peer with the Address and Port
>  > ISPI      the inbound SPI value the registered host is using for
>  >           the peer with the Address and Port
>
> What happens if both of the end-host have their own data relays? Then I
> think the OSPI could be zero.
>
> Why do you need to open both directions explicitly? I think the
> registered host should be allowed to send through the relay after
> successfuly data relay registration. So just opening the inbound
> direction should be sufficient and OSPI could be removed?
>
>  > 4.3.  HIP Connectivity Check Packets
>
> Why is the priority included separately in a new parameter since it was
> already exhanged in the locator?
>
>  > 5.  Security Considerations
>
> I didn't find the described issue from RFC5770, but I would add that
> you're talking about non-HIP aware firewalls. Also, the relay listens at
> a fixed port for registered clients, but it can decide about the port
> facing the peer host.
>
>
>
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Miika Komu <[email-masked]>
Date: Wed, 29 Jun 2016 21:41:11 +0300

Hi,

On 02/16/2016 04:22 PM, Ari Keränen wrote:
> Thank you for the review Tom! Please see below.
>
>> On 12/02/2016 11:54 PM, Tom Henderson wrote:
>>> Gonzalo and all,
>>>
>>> My understanding is that the WG reached consensus several years ago
>>> that the standards-track NAT traversal variant would be the native
>>> NAT traversal and not the RFC5770-based ICE/STUN/TURN version.
>>>
>>> I reviewed the above draft and noticed that it still contains
>>> normative references to RFC5770 (pointers to material found only in
>>> RFC5770) throughout, and contains RFC5770 as a normative reference
>>> in Section 8.1.  It seems to me that the WG ought to produce a
>>> specification that can stand alone from RFC5770, because as it
>>> stands now, it seems to me that someone implementing it would need
>>> to consult both drafts and may be uncertain about what is still
>>> applicable from RFC5770.  For example, is the UDP-ENCAPSULATION
>>> mode still valid?
>
> Indeed this variant is the standards-track solution, but I think it
> makes sense to not obsolete the RFC5770. For example, in some scenario
> the STUN based solution could be better than native HIP based. And also
> the UDP-ENCAPSULATION mode should be still valid.

the draft does not replace RFC5770, but offers a parallel/independent 
way to implement NAT traversal. UDP-ENCAPSULATION mode is still valid.

>>> ICE (RFC 5245) is also still listed as normative but it seems to me
>>> that it should also be informative in this draft.
>
> The details of e.g., how ICE checklists are used are defined in RFC5245
> so I think it needs to be normative.

You're right, and new ICE (rfc5245bis) is now normative.

>>> I think it would be appropriate to just reference 5770 in the
>>> Introduction, stating that this specification replaces RFC 5770
>>> with a different mechanism than ICE/STUN/TURN, and then try to
>>> avoid referencing 5770 from then on.
>
> Avoiding RFC 5770 altogether would require lots of editorial work with
> this draft for a questionable amount of benefit, so I think it's better
> if we simply have it as normative reference. The maturity level of 5770
> (experimental) is an issue, but I think it is possible - and makes sense
> - to make an exception here.

The draft has been improved radically from the viewpoint of readability 
and it is more independent from RFC5770. The old draft is somehow more 
mature in the sense that it has been implemented and successfully 
interoperated. However, it is based on the old ICE specification that is 
going to be deprecated this year.

---

From: Tom Henderson <[email-masked]>
Date: Wed, 29 Jun 2016 22:44:59 -0700 (PDT)

Hi Miika,

> 
> trying to recap your complete opinion... do you think the 
> UDP-ENCAPSULATION should be MUST and ICE-HIP-UDP SHOULD? And RFC5770 
> MAY? Or do you think the draft should just deprecate RFC5770?

I think that UDP-ENCAPSULATION should be a MUST option because that option is sufficient if the implementation does not have to deal with inbound connections.

ICE-HIP-UDP should be a MUST for implementations that wish to support inbound, and I don't think that RFC5770 solutions for inbound should be suggested as options.  Maybe the use of STUN servers for candidate gathering is fine as a MAY since it doesn't affect HIP interoperability, but otherwise, why suggest to support two parallel implementations for the same function?  

I would be fine with making an allowance for RFC5770 implementations to live on as an option; by this I mean to not overwrite RFC5770 codepoints, etc. but stop short of suggesting it as a MAY in this document.

> 
> Btw, RFC5770 is still a normative reference because we are redundantly 
> explaining some parts of the RFC in the draft.
> 

I still believe that it would be better if this draft did not depend on reading RFC5770.

- Tom