Re: [Hipsec] Mirja Kühlewind's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

Miika Komu <> Wed, 19 February 2020 18:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D6E81208B5; Wed, 19 Feb 2020 10:39:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dhs9w-elm2pf; Wed, 19 Feb 2020 10:39:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D8C1F120137; Wed, 19 Feb 2020 10:39:21 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=Im16lj6Sv6O4hUgjJ1lYzBJsngo+hFZyx47cr3d8Ckjp42gH+gbyPOcpuU1anyAWWE1tAp9cIEFudv10cc2cGOk5OZA3Fg9N49iBE9a9Jcrzy7pgXAhwT4jcdqVOnc2tTkWdY/PgYC+uLBIKg2mxafmGyCU5zyQyK6D05Y2XeQgcwBE776t+7m89GK9pMCbhWIOGfiF+5jjfunKAwHkyDjWhkdDxdegoZN3p2XT1YmYUZRkvDqS5epKU6XNNfoKol6ZCNodY4nm04h/RERACSy/gWktuOZwidB0woK+iwpnm2P7ejurB5UDanvAHcMPekH+2xtzeDeMontTcjU2Fnw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zn3rMG9A72d+oAC6w4gbA79heeYkNUXR8NNxXxW/AIQ=; b=hOznJhHocnB6prNN8XihMo9sOdcTdzlMBNky59bKYhw5JL3XUVE3RuqGqoYmpOSrB5o2i3idsa0I9Ugg1dKZEf4mOaWEwoXGtH43+MHpA/g1Efd9+GcuGgb9ElsHYYClGrJXO7V+8y3k5KiekkQLldnITKg7e+cIieodK/Tq+WPxqqvZOVOKuMhmy5IVCo49HPoIt31fet+hjlYBP8wGukUsEhExc2Ve+Ph3anB3e9XzT3UX/uzAyENoXFp97yNVlVQIpTL09c0oB4mOBq3eZ2L+AkdqINZQZDSEE4W1YIgnusgfRzyiSUdiv8otVvE8gDUfiOEvqP2xIPPHY0fN5Q==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zn3rMG9A72d+oAC6w4gbA79heeYkNUXR8NNxXxW/AIQ=; b=V5wvqx9XTwQo5mJeBWZu8cdVYF4TSCSKd0KH+Cdv2Kp4vXxRj6SubiDXriDXrh6HqulbTPURoPpWfETRpmoEtc9fyvxeu+EzxBevsgxbjLC7PeyWzF2IpfG3XE8+uuWeaofL+Lwp9pg9xRnYyjeg+9dYgwAZ+aACRa2C15Q6xes=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.9; Wed, 19 Feb 2020 18:39:19 +0000
Received: from ([fe80::790c:4b51:77d2:7767]) by ([fe80::790c:4b51:77d2:7767%5]) with mapi id 15.20.2750.016; Wed, 19 Feb 2020 18:39:19 +0000
From: Miika Komu <>
To: "" <>, "" <>
CC: "" <>, "" <>, Gonzalo Camarillo <>, "" <>
Thread-Topic: Mirja Kühlewind's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)
Thread-Index: AQHT6EXFYVxCAyS5RkaJuve993bnxqgm1z0A
Date: Wed, 19 Feb 2020 18:39:19 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: fi-FI, en-US
Content-Language: en-US
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 396597f7-ca13-4250-a1dd-08d7b56b080e
x-ms-traffictypediagnostic: AM0PR07MB5682:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 0318501FAE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(346002)(39860400002)(136003)(396003)(189003)(199004)(71200400001)(966005)(66946007)(66556008)(64756008)(224303003)(478600001)(4326008)(66446008)(44832011)(66476007)(2906002)(110136005)(6512007)(54906003)(76116006)(316002)(2616005)(91956017)(186003)(5660300002)(26005)(6486002)(36756003)(66574012)(81166006)(81156014)(86362001)(8936002)(6506007)(99106002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5682;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 7PBYf3fRJH75vHLZvjx7njyX5WxYP3YvGnsEgKhXLTW9NWsCmd6rgXCoBpJrhRFsvavs6LRuA8eQoMsc9MUBI8NX3UcFpqKoFptxtL20OXFEdWvfvYpiI891ZXyf29wGxnm4iepFhX3cYmF7MrRPkeae7v2k8H1ZvhjLkcMa2BzG/iSf1Uz1gwq8o8Vb2nseAOpNsOVYIAp88RsDM8wuszRafI4EZNv5a8L1K4rmWLn57UiKUERyikBW7MHmg/rx/gWh1iy5bbnDlS4U2Cj3J6MOQydP7lBqJrRZtyOTDzBHwfmAvrRTT+P4biDF9klQPNWh0tbCVx5CBWgRxKkiSBXhmXFV4Slqh+na+oIVbAGjMTn6Ij2tUTAD5la+VGj5oC+MlnTgTeZjF7J1fzh/47TJgwUQlShcCNJATCXzkDhyQGspeQkXtRYV0o3gqi+eMHqv1DDb5FUZVe51e0iFkNsWA9ly3lnQ52Q33BfIOWMXNVEwJrN1CWb0+vvchexsXC72rQUIwbB04Wm+QVZMHtLkr6/io9VryLcE/tLDJYhRwRcGZ/9hfQGArT5zdKu/
x-ms-exchange-antispam-messagedata: DQKrz2WJ+WhXRIQczLS7FRuTTCeHUK1IjMp+myy87t7oGsSY/TCaVBJeEcVbEJRk0OvFHUEKlVFq8PmeCPE1Q7sm4rRTbKJ7t0uLUr6hybLxKHcuqlq2HkU1vqgrkgui1iuiuZdXW66nUZMQF8UwlA==
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 396597f7-ca13-4250-a1dd-08d7b56b080e
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2020 18:39:19.6669 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ZesOCCfQozuWdwArvV3zti4tn91ySm6NNZ8q699krhjkJd6nBA1UaWmAyS+ydzDlMKOtCE+KTRO5nbMg3TkVLg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5682
Archived-At: <>
Subject: Re: [Hipsec] Mirja Kühlewind's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Feb 2020 18:39:26 -0000

Hi Mirja,

thanks for your comments! My response is below, let me know if you have
further concerns.

to, 2018-05-10 kello 03:00 -0700, Mirja Kühlewind kirjoitti:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-hip-native-nat-traversal-28: Discuss
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut
> this
> introductory paragraph, however.)
> Please refer to 
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> -------------------------------------------------------------------
> ---
> -------------------------------------------------------------------
> ---
> 1) This document should also update the IANA port registry to add a
> reference
> to this RFC-to-be to the existing entry for port 10500 (eventually
> even with
> note that this RFC-to-be discusses how to distinguish the services
> using

IANA section should describe this:

   This document reuses the same default UDP port number 10500 as
   specified by Legacy ICE-HIP [RFC5770] for tunneling both HIP control
   plane and data plane traffic.  The selection between Legacy ICE-HIP
   and Native ICE-HIP mode is negotiated using NAT_TRAVERSAL_MODE
   parameter during the base exchange.

Let me know if something needs to be added.

> 2) Sec 4.4: "Hosts SHOULD NOT use values smaller than 5 ms for the
> minimum
> Ta,..." In rfc5245bis this is a MUST. Why is this a SHOULD here?

Because it used to be like that in an earlier version of ICE. Good
catch, I have now changed SHOULD to MUST now.

> Also in sec 4.6.2.:
> "If neither one of the hosts announced a minimum pacing value, a
> value of 50 ms
> SHOULD be used." This must be a MUST to be inline with sec 4.4.

thanks, both are now "MUST"s.

> 3) Appendix A: "Ta value so that only two connectivity check messages
> are sent
> on every RTT." Why two? RFC8085 recommends (SHOULD) at may one packet
> per RTT
> for non-congestion control transmissions

aligned with RFC8085 as you requested:

 In this case, it is recommended that the hosts
   estimate the round-trip time (RTT) between them and SHOULD set the
   minimum Ta value so that at most a single connectivity check message
   is sent on every RTT.

> -------------------------------------------------------------------
> ---
> -------------------------------------------------------------------
> ---
> I agree with other ADs that it is not clear to me why this mechanism
> is needed
> in addition RFC5770. This is a use case for ICE and I would think
> that re-using
> existing code and library would make implementation easier, fast and
> less-error-prone. I especially agree to the comments from Adam!

ICE was not designed with IPsec in mind, so the performance overhead is
unacceptable. I have also some additional reasoning for Adam Roach

and here:

> Other comments/nits:
> 1) sec 4.6.2: "Upon successful nomination an address pair, a host MAY
> immediately stop sending such retransmissions." Not sure I understand
> this
> sentence; why MAY?

It should read "nomination *of* an address". I changed the MAY to

Upon successful nomination of an
   address pair, a host MUST immediately stop sending such

> 2) sec 4.1: The registration to the Control Relay Server can be
> achieved using
>    RELAY_UDP_ESP parameter as explained later in this section."
> I guess that should be RELAY_UDP_HIP?

good catch, corrected this.

> 3) sec 4.1: "It is RECOMMENDED that the Relay Client select a random
> port
> number..." Please say source port -> s/random port number/random
> source port
> number/


> 4) sec 4.8: "When a host does not receive
>    acknowledgments, e.g., to an UPDATE or CLOSE packet after a
> timeout
>    based on local policies, a host SHOULD resend the packet through
> the
>    associated Data Relay Server of the peer (if the peer listed it in
>    its LOCATOR_SET parameter in the base exchange."
> I did not really find anything about this in section 5.10 of RFC5770.
> In think
> the timeout needs to be further specified.

section 4.8 is "Sending Control Packets after the Base Exchange". Do
you mean section 4.10 in RFC57700:

...which is also suggests "timeout based on local policies".

> 5) sec 5.3: "It is worth noting that sending of such a HIP NOTIFY
>    message MAY be omitted if the host is actively (or passively)
> sending
>    some other traffic (HIP or ESP) "
> This should really be a SHOULD (at least).

agreed, changed to SHOULD.

> 6) Appendix A: "One way to estimate the RTT is to use the time that
> it takes
> for the Control Relay Server registration exchange to complete;" That
> does
> estimate the RTT between the endhost... I not aware of a good way to
> estimate
> that, so I'm actually not convinced that the recommendation in
> appendix A is
> that useful at all.

I reflected your concerns by adding a disclaimer:
In general, estimating RTT can be difficult and error prone; further
experimentation is required for reliable RTT estimation.