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

Ari Keränen <ari.keranen@ericsson.com> Sun, 10 April 2016 06:29 UTC

Return-Path: <ari.keranen@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 67C6712D5C3 for <hipsec@ietfa.amsl.com>; Sat, 9 Apr 2016 23:29:00 -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 loNlWX_yJ7rc for <hipsec@ietfa.amsl.com>; Sat, 9 Apr 2016 23:28:58 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3170F12D5C0 for <hipsec@ietf.org>; Sat, 9 Apr 2016 23:28:57 -0700 (PDT)
X-AuditID: c1b4fb25-f79f86d00000400a-c5-5709f2a7ca5c
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 20.33.16394.7A2F9075; Sun, 10 Apr 2016 08:28:55 +0200 (CEST)
Received: from ESESSMB205.ericsson.se ([169.254.5.173]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0248.002; Sun, 10 Apr 2016 08:28:55 +0200
From: =?Windows-1252?Q?Ari_Ker=E4nen?= <ari.keranen@ericsson.com>
To: Miika Komu <miika.komu@ericsson.com>
Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal
Thread-Index: AdFowpWe9jrdmw5kTlK+lzLVKf/ImwEuwOgACUx9fYA=
Date: Sun, 10 Apr 2016 06:28:54 +0000
Message-ID: <B26604D1-C537-438B-92CC-B3C05C486F1F@ericsson.com>
References: <56AB5BCD.7060803@ericsson.com> <56BE47BE.9070406@ericsson.com> <56C32BCC.9070105@ericsson.com> <56CB299E.5030704@ericsson.com>
In-Reply-To: <56CB299E.5030704@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <1D97AB8A8E8C5F4883DB2B9A26FFC85B@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7uu7yT5zhBu1rzCymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujN4NlxgL5hhXfFy4namB8Yt6FyMnh4SAicTXw3uZIWwxiQv3 1rN1MXJxCAkcYZQ48O0hlLOEUeLPrHdsIFVsAo4Spx6uZQWxRQQ0JBpPbgKzmQW8Jfrv3WAC sYUF7CVO7rvFDlHjILF58zKoeiuJk5t6wbaxCKhK3Ll5ESzOC1Tfu+woK8SyXkaJ5s4/YEWc AjoSkyZtZQGxGYHO+35qDRPEMnGJW0/mM0GcLSCxZM95qBdEJV4+/scKYStJrD28nQWi3kDi /bn5zBC2tcSv7otQc7Qlli18zQxxhKDEyZlPWCYwis9CsmIWkvZZSNpnIWmfhaR9ASPrKkbR 4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzA+Dq45bfqDsbLbxwPMQpwMCrx8CZUc4YLsSaWFVfm HmKU4GBWEuH99AEoxJuSWFmVWpQfX1Sak1p8iFGag0VJnDc78l+YkEB6YklqdmpqQWoRTJaJ g1OqgdHxXrRymmDf/nWMF6b4v9hT575X5uu8w/q8B+ZLTrE9yVD3wptxS58d9yyuchkPkQ7m i3/nLTuy7mA0280fayPvT/S65LN/AeeHTIHXfOUnVB6va7Gd8fNN3a8fnRuWdQR3cx/0z2ze XaDQ+8fDMyROabW/+ktOV195k0ZPh5NTPRMmxOSmb1JiKc5INNRiLipOBAARVWT9qwIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/izOlctvtQVgoVvm4k7taikr0OCU>
Cc: "hipsec@ietf.org" <hipsec@ietf.org>, Jan Melen <jan.melen@ericsson.com>
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: Sun, 10 Apr 2016 06:29:00 -0000

Hi,

Thanks Miika and sorry for belated answer. Your suggestions sound good. See inline for comments on the questions. I clipped out parts that needed no comments.

> On 22 Feb 2016, at 12:30, Miika Komu <miika.komu@ericsson.com> wrote:
[...]
> I would also suggest to explain the ICE term "permission" here.

OK. TURN RFC has text for that.

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

Because that's needed for the data relay in order to have the same functionality as TURN server (c.f. PEER_PERMISSION in TURN RFC), i.e., to allow only explicitly singled peers to connect to the host via 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.

No, RELAY_TO is used only with own relay. With peer's relay you don't need the parameter but can send plain connectivity check. This should be clarified.

> > send it to the data relay's address.  The data relay MUST send the
> 
> address of the data relay of the peer (right?)

No, own relay. Let's clarify that.
> 
> > 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

Own again.

> > The host MUST send the UDP encapsulated ESP packet to the data relay's address.
> 
> What host? Whose data relay?

The whose whose data relay is being used.

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

Return traffic from the host that is registered with PEER_PERMISSION is relayed too.

[...]
> > If the controlling host
> > does not have any data to send, it SHOULD send an ICMP echo request
> 
> ICMPv6 inside the tunnel - right?

Yes.

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

Yes (also other instances).

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

That's explained in 5770 and 5245. But perhaps little redundancy would not hurt here.

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

It's the inbound SPI from the peer's perspective.

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

Yes, multiple IP addresses. Could be just different IP address from the same interface too.

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

The SPIs would still be the SPIs both endpoints use when sending ESP packets like in other cases. The relays don't touch the SPI values; just read them to know where to forward.

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

You want to also send data to the peer and then there's only OSPI in ESP packets. The relay works both ways.

> > 4.3.  HIP Connectivity Check Packets
> 
> Why is the priority included separately in a new parameter since it was already exhanged in the locator?

For peer-reflexive priorities (see RFC 5245). The priority for those is different from the host priorities 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.

Yes.


Cheers,
Ari