Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

Gonzalo Camarillo <gonzalo.camarillo@ericsson.com> Thu, 20 February 2020 12:45 UTC

Return-Path: <gonzalo.camarillo@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 88FDE1200EF; Thu, 20 Feb 2020 04:45:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 TJ09hP9ijJgf; Thu, 20 Feb 2020 04:44:58 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10055.outbound.protection.outlook.com [40.107.1.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BF7B12001A; Thu, 20 Feb 2020 04:44:58 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W0rJsZ9Y+9p2SYrdVijbnvrrPaiU24yAwsAelXABq6m7HBR/Ewj8E5qT63KXgiX8ceCJkF8Mv/DYi8xh4iml9fcumGoOn8rs8yAhwTkM38XHjDymEuM5sH+wVTVBa+hZxPxHW7WLWKLsYg6N9cV9S9+3zI7Ms2gpyghELoWmyIkScFR0BqH73XwTWvLuigj7TLbAUN1iu+xk4PZ7U6oNTXjz0iwP6D+ZRnqUFhnbkj7NcglojqyzsFe1tOP7BWLpoNBFKVCgnKU5Ir3bNS2ce7DZ7PPGkR+n8vHdkdLAdvPEiRK4NWQIqWMFLOMqm9pCVWUwNwyJIi9SCI8/AhwiPQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FEZ66KH5HMpKe+GiU/3jF7Q8Lks0QAx3xPLc+J32NJY=; b=e/S7rlCYEbrseO+px1sLF+qmjrfKAphJs4Bn7K+kvf68ZPUIytdih5AuzcP8YpLIwJVvcz6o5bjLBWWSwf9Pa1DhONJye7bajrOaEpLs9d5aRkJ70NDYUiZf1HRVUdA9OcMYwKTljl99BwAgisrBpAngwCtYd9R4p5X0EPn43eoSvAGGISIV4E6vRJTTG2465dHL28n5Jrsxosgn9TiRxBTcw7qaHsQrqUKjrSwP2zoxhRqlvqWkbOrzeORbC/V5nEjJET9vXlMAkQ1BH3yzp4uEQKWl25s+kc4MvRBO21xY89VXCnI3zzVIc7n3FSc+B8gfnYVpcBuY+8c5h8Gojw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FEZ66KH5HMpKe+GiU/3jF7Q8Lks0QAx3xPLc+J32NJY=; b=YrK2UrMnljGbRBBSRiMMRnLME4H1j5RUIjQx/x2LPSxLYZwa/PHpZ515GEN9/ojQGqvy41fNlvSdkTehEc+zuHnUERFV1wyNMoCfQM6x6C+7PRlnfHsb6cCzREFYN/UXHvXGGolX2ugnt0qphDhStnytB4CcbhUF1vmf3Q2ifds=
Received: from AM4PR07MB3379.eurprd07.prod.outlook.com (10.171.189.20) by AM4PR07MB3489.eurprd07.prod.outlook.com (10.171.190.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.8; Thu, 20 Feb 2020 12:44:55 +0000
Received: from AM4PR07MB3379.eurprd07.prod.outlook.com ([fe80::b838:e3d4:d1e8:f8e4]) by AM4PR07MB3379.eurprd07.prod.outlook.com ([fe80::b838:e3d4:d1e8:f8e4%6]) with mapi id 15.20.2750.016; Thu, 20 Feb 2020 12:44:55 +0000
From: Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
To: Eric Rescorla <ekr@rtfm.com>, "evyncke@cisco.com" <evyncke@cisco.com>
CC: "draft-ietf-hip-native-nat-traversal@ietf.org" <draft-ietf-hip-native-nat-traversal@ietf.org>, "hip-chairs@ietf.org" <hip-chairs@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "hipsec@ietf.org" <hipsec@ietf.org>, Miika Komu <miika.komu@ericsson.com>
Thread-Topic: Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)
Thread-Index: AQHT497tUmBXmn8MOU+Q++wdbIVom6VF/FUAgE08J4CCk9E3AIAAA4SAgAEBhIA=
Date: Thu, 20 Feb 2020 12:44:55 +0000
Message-ID: <AM4PR07MB3379491335878866A056471783130@AM4PR07MB3379.eurprd07.prod.outlook.com>
References: <152546246777.11589.13288594519409569524.idtracker@ietfa.amsl.com> <a657ffe0-3574-850e-3b8d-9b21f6f8825b@ericsson.com> <CABcZeBO3gLUZevW0zTN6RHiuYBY+7d-4DefSNBA3FzhXFWfGQw@mail.gmail.com> <47c0cdb7980fa6b9d85d71de926d24ea50a90930.camel@ericsson.com> <CABcZeBOVzKyd1Q6uYi66AFEazhW5OSOwYMBnUqGvjHRk4+0DtA@mail.gmail.com>
In-Reply-To: <CABcZeBOVzKyd1Q6uYi66AFEazhW5OSOwYMBnUqGvjHRk4+0DtA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gonzalo.camarillo@ericsson.com;
x-originating-ip: [37.33.8.11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b33accd2-0c73-4af5-ac73-08d7b602b021
x-ms-traffictypediagnostic: AM4PR07MB3489:|AM4PR07MB3489:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <AM4PR07MB3489C7E545381ECA06E76B7683130@AM4PR07MB3489.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 031996B7EF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(136003)(366004)(396003)(189003)(199004)(316002)(110136005)(54906003)(26005)(9686003)(5660300002)(107886003)(21615005)(55016002)(44832011)(966005)(478600001)(71200400001)(33656002)(66946007)(66476007)(81156014)(81166006)(8936002)(8676002)(2906002)(52536014)(86362001)(7696005)(6506007)(53546011)(66556008)(64756008)(66446008)(76116006)(4326008)(186003)(4001150100001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3489; H:AM4PR07MB3379.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: E9L5EqetTuxfZ/i/4FJPlh/ViNsWyKCqOs5QGDpH+M7f57NbGjyltuDXf1ZKuicflBixGkZieGigzjldZOLzthhAnA6QBToGvLKGviCikTzNMdDuViIWZTQSDbnqJRQt6l1PiFFbG5PYCeeDcd4p4ffxkByRIszTVpt5Q8a9PL0UNxsotXN8CxGB4dTH+HGhcVr44D0hyEDdXhuaVfv+q1jBB2xiMnJ5BMXwy0AWoE5aVI0akHXBD8d0iIWLFJ2V4iPliM2Z+vlp3tPhFIxpdW4mJGeOL8SlzONi9N3giwj7P/ZkcLoEiJ1dn6wifp7hvV9K7aXUpv/MPfTc+oRHLT1DyNfenEN3QNW0qsixZG2d9/Lec5/ESShshur5I9N08NOWkh5XnKnfsccg2bbhh+Z0bABfLbB/hqX9Xsu9PFsa8eG5EIBJvp2D8eFpG+CtNNrvf/sounxzsykHWTZmEdAh/tVdbEnPiGjFQy5dV9dGnnAmiE9iSXm6EebAFnIP6t5BXS+idfhVifR820moFg==
x-ms-exchange-antispam-messagedata: 2qEDnuaxrFOrQJYgOnuwbKBpjOGYT2oUhIB/eKZbafDYvkDAhClhqLGNlKn5rV6V27Rdp1gjusn9DepDcW7YDxVmQe+Wi3PoAkUuovdJGugAVBK+IeESYRJuIFSEaTnMv7lTRidzB15bQZnfmQhRCQ==
Content-Type: multipart/alternative; boundary="_000_AM4PR07MB3379491335878866A056471783130AM4PR07MB3379eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b33accd2-0c73-4af5-ac73-08d7b602b021
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2020 12:44:55.6401 (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: 4G9oSgKPtDisI5O3HpeE0XowUNAZ9D4FBEyBRSHB1+mSxAQlyePjMcOBOYgkYJ71hlaptGztdEw72fOSrfdaJl77q4CuK/4GHcqd8YT3qWY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3489
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/qv1-8FNjtWBBAwCt-b6WKRJUFag>
Subject: Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.29
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, 20 Feb 2020 12:45:02 -0000

Thanks for the quick response, Eric R!

Eric V, could you please let Miika know how do you want to proceed?

For background, this is the status of the ballot for this draft:
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ballot/

Thanks,

Gonzalo

From: Eric Rescorla <ekr@rtfm.com>
Sent: Wednesday, February 19, 2020 23:21
To: Miika Komu <miika.komu@ericsson.com>
Cc: draft-ietf-hip-native-nat-traversal@ietf.org; hip-chairs@ietf.org; iesg@ietf.org; Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>; hipsec@ietf.org
Subject: Re: Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

I am no longer an area director, so generally I  suggest you take up these comments with the current ADs.

On Wed, Feb 19, 2020 at 1:08 PM Miika Komu <miika.komu@ericsson.com<mailto:miika.komu@ericsson.com>> wrote:
Hi Eric,

thanks for your comments, my response below.

ke, 2018-12-26 kello 17:04 -0800, Eric Rescorla kirjoitti:
>
>
> On Wed, Nov 7, 2018 at 1:37 PM Miika Komu <miika.komu@ericsson.com<mailto:miika.komu@ericsson.com>>
> wrote:
> > Hi Eric,
> >
> > apologies for the belated response, I am not working on HIP
> > anymore, so
> > it has been rather difficult to find time for this.
> >
> > On 5/4/18 22:34, Eric Rescorla wrote:
> > > Eric Rescorla 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
> > https://www.ietf.org/iesg/statement/discuss-criteria.html<https://protect2.fireeye.com/v1/url?k=4df5b2b9-117c6895-4df5f222-0cc47ad93da2-c63b54a62d6e5f37&q=1&e=7142dcd0-5df7-4a81-aaf2-5f5e8ee90c29&u=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html>
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found
> > here:
> > >
> > https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/<https://protect2.fireeye.com/v1/url?k=d572ef6f-89fb3543-d572aff4-0cc47ad93da2-ec72a0e72bb1caa3&q=1&e=7142dcd0-5df7-4a81-aaf2-5f5e8ee90c29&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-hip-native-nat-traversal%2F>
> > >
> > >
> > >
> > > ---------------------------------------------------------------
> > -------
> > > DISCUSS:
> > > ---------------------------------------------------------------
> > -------
> > >
> > > Rich version of this review at:
> > > https://mozphab-ietf.devsvcdev.mozaws.net/D3099<https://protect2.fireeye.com/v1/url?k=770d951d-2b844f31-770dd586-0cc47ad93da2-ca3aaf2e40abb1bd&q=1&e=7142dcd0-5df7-4a81-aaf2-5f5e8ee90c29&u=https%3A%2F%2Fmozphab-ietf.devsvcdev.mozaws.net%2FD3099>
> > >
> > >
> > > I am very familiar with ICE and yet I found this document
> > extremely
> > > hard to follow. The problem is that it cherry-picks pieces of ICE
> > and
> > > I'm just not sure that it's a complete specification when put all
> > > together. I have noted a number of places where I actually am not
> > sure
> > > how to implement something, and fixing those will resolve this
> > > DISCUSS, but IMO you really should totally rewrite this document
> > > either (a) as a variant of ICE or (b) as an entirely new document
> > not
> > > with a pile of new text and then references out to ICE sections.
> >
> > the expected receivers of the work are the implementers of RFC5770,
> > so
> > the draft follows the sectioning of the RFC5770 (which has two
> > interoperable implementations).
> >
> > If I understood your comment right, the variant of ICE (a) would
> > follow
> > the ICE document structure but then the document would not serve
> > anymore
> > HIP implementers so well. What comes to option (b), I think it
> > would
> > make the the document quite long if we replicated everything in the
> > ICE
> > specification (and possibly from the HIP specifications) in the
> > draft.
>
> Yes, it would be long, because ICE is complicated. It would also be
> complete.
> As I said in my initial ballot, if you resolve the ambiguities I
> noted I will
> clear my DISCUSS, but I think that this document should really be
> rewritten
> and i would urge the AD to require it.
>
>
>
> > > S 4.6.2.
> > >>
> > >>       A host may receive a connectivity check before it has
> > received the
> > >>       candidates from its peer.  In such a case, the host MUST
> > immediately
> > >>       generate a response, and then continue waiting for the
> > candidates.  A
> > >>       host MUST NOT select a candidate pair until it has
> > verified the pair
> > >>       using a connectivity check as defined in Section 4.6.1.
> > >
> > > Are you supposed to put this on a TODO check list as with ICE?
> >
> > I believe you refer to the triggered-check queue:
> >
> > https://tools.ietf.org/html/rfc8445#section-6.1.4.1<https://protect2.fireeye.com/v1/url?k=b1768830-edff521c-b176c8ab-0cc47ad93da2-0e377742be9101ab&q=1&e=7142dcd0-5df7-4a81-aaf2-5f5e8ee90c29&u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8445%23section-6.1.4.1>
> >
> > I changed the text as follows:
> >
> > A host may receive a connectivity check before it has
> >
> > received the candidates from its peer. In such a case, the
> >
> > host MUST immediately generate a response by placing it in the
> > triggered-check queue, and then continue
> > waiting for the candidates.
>
> Well, this isn't generating a response, it's queueing a response.

reworded as follows:

In such a case, the host MUST immediately queue a response by placing
it in the triggered-check queue, and  then continue waiting for the
candidates.

> > > S 5.8.
> > >>
> > >>    5.8.  RELAY_HMAC Parameter
> > >>
> > >>       As specified in Legacy ICE-HIP [RFC5770], the RELAY_HMAC
> > parameter
> > >>       value has the TLV type 65520.  It has the same semantics
> > as RVS_HMAC
> > >>       [RFC8004].
> > >
> > > What key is used for the HMAC?
> >
> > clarified this as follows:
> >
> > [..] It has the same semantics as RVS_HMAC as specified in section
> > 4.2.1
> > in [RFC8004].  Similarly as with RVS_HMAC, also RELAY_HMAC is is
> > keyed
> > with the HIP integrity key (HIP-lg or HIP-gl as specified in
> > section 6.5
> > in [RFC7401]), established during the relay registration procedure
> > as
> > described in Section 4.1.
>
> This seems like it might have potential for cross-protocol attacks on
> the key. Why
> is this OK>

this is standard way of deriving keys in HIP. The keying procedure is
the same as with specified in RFC8004. If there is some attack
scenario, please describe it in detail?

Or is there some editorial issue here?

I'm not sure. When I read this text it appears to say that you should be using the same key for two kinds of messages. Is that correct?

-Ekr

> > > S 4.2.
> > >>       deployments in order to enable it by software
> > configuration update if
> > >>       needed at some point.  A host SHOULD employ only a single
> > server for
> > >>       gathering the candidates for a single HIP association;
> > either one
> > >>       server providing both Control and Data Relay Server
> > functionality, or
> > >>       one Control Relay Server and also Data Relay Server if the
> > >>       functionality is offered by another server.  When the
> > relay service
> > >
> > > How does this interact with mult-layered NAT?>
> >
> > No different from ICE with separated STUN and TURN servers multi-
> > layer
> > NAT scenarios. Should we mention something about the issues related
> > to
> > some specific scenario?
>
> Well, with multi-layered NAT, you actually want a STUN server at each
> level
> so that you minimize hairpinning. But you recommend against that
> here.

good point. This unnecessary constraint has been removed as it was also
requested by Benjamin Kaduk.

> > > S 5.7.
> > >>       | Reserved  | 0        | Reserved for future extensions
> >          |
> > >>       | Preferred | 0 or 1   | Set to 1 for a Locator in R1 if
> > the        |
> > >>       | (P) bit   |          | Responder can use it for the rest
> > of the   |
> > >>       |           |          | base exchange, otherwise set to
> > zero       |
> > >>       | Locator   | Variable | Locator lifetime in seconds
> >           |
> > >>       | Lifetime  |          |
> >           |
> > >
> > > What is the purpose of this? It's not an ICE parameter.
> >
> > In HIP, locators have a maximum lifetime after which they become
> > deprecated (RFC8046). Should add something here?
> Yes

Added a reference:

"Locator lifetime in seconds, see Section 4 in [RFC8046]"

>