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]"
>
> >
>