Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)
Eric Rescorla <ekr@rtfm.com> Wed, 19 February 2020 21:21 UTC
Return-Path: <ekr@rtfm.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 54691120837 for <hipsec@ietfa.amsl.com>; Wed, 19 Feb 2020 13:21:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 uGK3_FeDZBV9 for <hipsec@ietfa.amsl.com>; Wed, 19 Feb 2020 13:21:39 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F4E120128 for <hipsec@ietf.org>; Wed, 19 Feb 2020 13:21:38 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id q8so1894039ljj.11 for <hipsec@ietf.org>; Wed, 19 Feb 2020 13:21:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KuX16sd1sDFbzoO9RPuHMoVmwHtTObjnOBH0f48sRFA=; b=SkpQYUa9105y46KFb8M25vjctffApefwmmvVNWUV5YIHiJfixM70cG51vMagOkqcQc 09fKQp1l6xCtYQNZyANa6/GQp96WgKPr4bEbFcYas1eRqpuzknnMzUBAF0s9WfmOsf37 ht8nlHj+vT/uOb2LE04CMo7NanMJjUM4PJe9u0n3eYJIhx0HBo6yl8/NLF/CayPkOuwq Xa5x0og3fA4p4NNF+0J5cqXv4CdngS5KO0Z7BwCu8i9pCxFwYsaK5Y/VznaYMBVf+q9u XHZauHDDziDxl+xC6khZfU7k1eh2VevHdklkgrn6bbcituMQZX1L1l9cQ+hSVSLWmJJu swKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KuX16sd1sDFbzoO9RPuHMoVmwHtTObjnOBH0f48sRFA=; b=G8Ug8myndMN+whS6qjtNONP85hBJUAttMLUSW7Pps9w9XxklDjwTch3Yn3Vfx8KXgu Eq+bSk1M6w2S5yqZC4qyZxfwGgF2UZ/zRlCyLBgP/EGzTX+ShLrPVHPWqjFPoIowRy9q gcvm3FROSE10OWy6neM53By9zcE6ooGWhgV/v1C0wklikpdZ5TR8KWIAGeEFvfXH1tOW wRbcVMmaNj/1vCc6rQyTfqrGoG9xlFjMtCpyREJNrjd4J9ZvmjqdcEfTMsLp/4gouVrF ZPWsPHrLmfk9CA4mqZb6IEcyvQEJkSNdO8MuG+5JfgvWYW4CCrdB3O4oRRK/j5C6JN5Y Hirg==
X-Gm-Message-State: APjAAAU2+9Eknl8mgNYXDdVpXu/sEVt01xR0YsdI8+N0P2qLiHSaZ9OS Zc5agwuR16mdWImnKLHMgBHbqLZLhh0hi+8rM0eDZA==
X-Google-Smtp-Source: APXvYqxfjOf/i5GKTpKuT/NSLs4zkacY2Z22giy3a2GevxDicCR6hfpjjzniN8qUF5ZUBAAfvLBQULo0WYvTWoyFl04=
X-Received: by 2002:a2e:9b12:: with SMTP id u18mr17058201lji.274.1582147296668; Wed, 19 Feb 2020 13:21:36 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <47c0cdb7980fa6b9d85d71de926d24ea50a90930.camel@ericsson.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 19 Feb 2020 13:20:59 -0800
Message-ID: <CABcZeBOVzKyd1Q6uYi66AFEazhW5OSOwYMBnUqGvjHRk4+0DtA@mail.gmail.com>
To: Miika Komu <miika.komu@ericsson.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>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "hipsec@ietf.org" <hipsec@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000099ce82059ef45fdd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/CXw-MXsPL5SpWWB7BJKRjb1VI1g>
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: Wed, 19 Feb 2020 21:21:43 -0000
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> 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> > > 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 > > > > 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/ > > > > > > > > > > > > > > > > --------------------------------------------------------------- > > > ------- > > > > DISCUSS: > > > > --------------------------------------------------------------- > > > ------- > > > > > > > > Rich version of this review at: > > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3099 > > > > > > > > > > > > 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 > > > > > > 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]" > > > >
- [Hipsec] Eric Rescorla's Discuss on draft-ietf-hi… Eric Rescorla
- Re: [Hipsec] Eric Rescorla's Discuss on draft-iet… Christer Holmberg
- Re: [Hipsec] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [Hipsec] Eric Rescorla's Discuss on draft-iet… Christer Holmberg
- Re: [Hipsec] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [Hipsec] Eric Rescorla's Discuss on draft-iet… Christer Holmberg
- Re: [Hipsec] Eric Rescorla's Discuss on draft-iet… Miika Komu
- Re: [Hipsec] Eric Rescorla's Discuss on draft-iet… Miika Komu
- Re: [Hipsec] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [Hipsec] Eric Rescorla's Discuss on draft-iet… Miika Komu
- Re: [Hipsec] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [Hipsec] Eric Rescorla's Discuss on draft-iet… Miika Komu
- Re: [Hipsec] Eric Rescorla's Discuss on draft-iet… Gonzalo Camarillo
- Re: [Hipsec] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [Hipsec] Eric Rescorla's Discuss on draft-iet… Miika Komu
- Re: [Hipsec] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [Hipsec] Eric Rescorla's Discuss on draft-iet… Miika Komu
- Re: [Hipsec] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [Hipsec] Eric Rescorla's Discuss on draft-iet… Miika Komu
- Re: [Hipsec] Eric Rescorla's Discuss on draft-iet… Eric Rescorla