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

Miika Komu <miika.komu@ericsson.com> Thu, 23 June 2016 14:45 UTC

Return-Path: <miika.komu@ericsson.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98ED12B029 for <hipsec@ietfa.amsl.com>; Thu, 23 Jun 2016 07:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAXxa5Xzqy11 for <hipsec@ietfa.amsl.com>; Thu, 23 Jun 2016 07:45:36 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74607126B6D for <hipsec@ietf.org>; Thu, 23 Jun 2016 07:45:35 -0700 (PDT)
X-AuditID: c1b4fb2d-f79936d0000030e4-46-576bf60c3ed9
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9B.DE.12516.C06FB675; Thu, 23 Jun 2016 16:45:32 +0200 (CEST)
Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.294.0; Thu, 23 Jun 2016 16:45:31 +0200
To: <hipsec@ietf.org>
References: <56AB5BCD.7060803@ericsson.com> <56BE47BE.9070406@ericsson.com> <56C32BCC.9070105@ericsson.com> <56CB299E.5030704@ericsson.com>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <576BF60B.7030402@ericsson.com>
Date: Thu, 23 Jun 2016 17:45:31 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <56CB299E.5030704@ericsson.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090601050602010005050501"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM2K7ny7Pt+xwg81PtSymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujI5NU9kL1tRU7NxygrmBsT2zi5GTQ0LARKL/xxxGCFtM4sK9 9WxdjFwcQgJHGCW2rZ/NBOGsZpRofnyUHaRKWMBe4uS+W2C2iICoxJQPp5khinqBijr/MIMk 2AS0JFbduQ5m8wtISmxo2A1kc3DwCmhLXJhfCBJmEVCVmNo+GWyOqECExKztP5hAbF4BQYmT M5+wgNicAjoSkyZtZQGZzyzQzSjxZ/kzFpA5QgIqEhePBU9gFJiFpGUWsjKQBLOArcSdubuZ IWxtiWULX0PZ1hIzfh1kg7AVJaZ0P2SHsE0lXh/9yAhhG0ssW/eXbQEjxypG0eLU4uLcdCNj vdSizOTi4vw8vbzUkk2MwPA/uOW37g7G1a8dDzEKcDAq8fAqXMoKF2JNLCuuzD3EqAI059GG 1RcYpVjy8vNSlUR4/T5nhwvxpiRWVqUW5ccXleakFh9ilOZgURLn9X+pGC4kkJ5YkpqdmlqQ WgSTZeLglGpgNG+4/W/1hIwJ7h2zi/n8FX7eu7l3yp4JIpUT+rw3vvm0/s0Mo7cNf28YX1VR jnX4Zr1sku6yTZ93Btf+nbf0m8asR9bCEpWrtdhU309IfN9iZpV9NiB55dHHun6rItz+Pr74 gLNdfOfd87P8J7SdeRjqb3BoTsej93eTYnl/OKlvzT+2VenYq+NKLMUZiYZazEXFiQCPfPbL hwIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/1759pUO8RjXa4WEOv_7ZffG1DiY>
Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jun 2016 14:45:39 -0000

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
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec
>