Re: [Hipsec] Benjamin Kaduk's No Objection on draft-ietf-hip-native-nat-traversal-31: (with COMMENT)

Miika Komu <miika.komu@ericsson.com> Mon, 27 July 2020 20:19 UTC

Return-Path: <miika.komu@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 E410B3A0BA3; Mon, 27 Jul 2020 13:19:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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 fVZCRnNXvBdY; Mon, 27 Jul 2020 13:19:12 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150078.outbound.protection.outlook.com [40.107.15.78]) (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 C71AE3A0B9F; Mon, 27 Jul 2020 13:19:08 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a9TmE7469usoS43wWwXRaIuTJB7cFk3qZq6I96G49QBHmaI6n8EzQZMzlYFi9hsdsw3wGG4pn0UbA2LfRnvFYtlSOdHe04WHrdhbC0/MtgVVddiIey6oUS9cLtrMnOCxNvZXSgJDAfV8cwDwJOVVsPBZxmj9+ZGpmBsqIyjbH4ANdlRvbrd58Tn/ri7B24yo+P4Mhh8PdLU+f2Cuno/NfwCozwm2JdlMccFRdV3tJNhktTxShjNieZFaGPADiR+/jacuP2+oIDtPqD6T/uI7jXYiwZTMzNTqoOKayZyO70UuWUq3Ooj7hFLXqHygoJhBYbNz5W/MEGCR2rq1jyaakA==
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=8/yzzuzxMISwkCtFl0QsNgTaPYfIUtUap+Rpw78h56k=; b=lfrT3/lWSJimyuis8ZyZ5+64AqD2R8rvMcpqlk0U/BSPFkuDCDbI80m/C0qg0WOx2Ih4lux19XoZ9LhFQfPerqCrBwbhaEIhIICuLWtHG0DDUWulzSxSnzehxWQ9uoK7WkCgGZPKW68+hy4QtR25ILScn6gefX+RxA5GeTwr40xQsgvsm0o5kLASpqtWtkimQVQzMZGktE3a3YGI2tVOhylt3KDYQHFNJjg+LJy+t6miqsx943FOS7xZKt0WdOGhLGpl5/BrIdDxgsZiJSg0fh4Anhv+6VMyeZhSUEUxQFF1QZqMWhwjcF/yLeto9MEGKqFmCBAB7I8zyC+/186Msg==
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=8/yzzuzxMISwkCtFl0QsNgTaPYfIUtUap+Rpw78h56k=; b=Z3b0TLWdwpXy36RezDOqIRpA+b7xkB+FKeIZbPA+muwd1h/mqXL7cC9Mwv7Out2JS0gi2ILkDco0iUKHCVGdSunGcnjqjPmtORGpjAuWVYzuJJbFqZ80BC3zzavpfBYUe/2BV3n+nUgGPZwLKOGHCZJlLZLA7FkpyLSS7/WroAs=
Received: from AM0PR07MB5235.eurprd07.prod.outlook.com (2603:10a6:208:ec::21) by AM4PR07MB3057.eurprd07.prod.outlook.com (2603:10a6:205:3::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.10; Mon, 27 Jul 2020 20:19:06 +0000
Received: from AM0PR07MB5235.eurprd07.prod.outlook.com ([fe80::544:6c2a:1347:f524]) by AM0PR07MB5235.eurprd07.prod.outlook.com ([fe80::544:6c2a:1347:f524%3]) with mapi id 15.20.3239.015; Mon, 27 Jul 2020 20:19:06 +0000
From: Miika Komu <miika.komu@ericsson.com>
To: "iesg@ietf.org" <iesg@ietf.org>, "kaduk@mit.edu" <kaduk@mit.edu>
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>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "hipsec@ietf.org" <hipsec@ietf.org>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-hip-native-nat-traversal-31: (with COMMENT)
Thread-Index: AQHWWxD2ud1I5Am/70Wdjkbfv6U4Oqkb8EGA
Date: Mon, 27 Jul 2020 20:19:06 +0000
Message-ID: <4e39f395593069598f4bb9de2ba61d8a53e2fa09.camel@ericsson.com>
References: <159486313728.32101.12876601376848387572@ietfa.amsl.com>
In-Reply-To: <159486313728.32101.12876601376848387572@ietfa.amsl.com>
Accept-Language: fi-FI, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [37.130.188.48]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b8b345d3-1635-4212-015f-08d8326a501a
x-ms-traffictypediagnostic: AM4PR07MB3057:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <AM4PR07MB3057FBF88AB80472AEEEB0B2FC720@AM4PR07MB3057.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 2I4Wt686JPX+3+Zr3JKHCdS5skn1WeBsK544ed4noDDOVROeQdXjYRWS2OeYMKus+MZjowEj1Nvf+NFWYRNHXlV7KtBxZxV8dA+lEyof0SR5mMjp2h4TmZSwunWP1SNivNIgL57lJP8Cj8UXoMvFwuE6ygzpQCDobdjwVJQ+cMo3MvurXOGInT2awAVjZCwmVJy+/YK64lkTnbXT4Xp+aQlzBbDyc9e+CH3rI/tYcqY5z0p+dUpfvWnW3URhmwaQpSmQJFU2Vco8S8w1hErQonbKeXagnt2m0Xll4mwfFgIvgG7eGsON1dqmtdMlKyIBApfjfBUzVLzld5j1kAimJ8eXujuIf2PqGIB1A8fS5NCJuLRK5xFXt/LD4Uh8e3FDTvpR0PUMnoIlLL7psZTgUxAFywo9VBJjXCFyGl92/TW4K4uh6N7YaVPXME2cx//KupVSPeqXNvA7XGGrb0xYaw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB5235.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(396003)(346002)(366004)(376002)(66446008)(66946007)(6486002)(66556008)(64756008)(26005)(86362001)(66476007)(8676002)(186003)(2906002)(110136005)(91956017)(478600001)(4326008)(83380400001)(6506007)(76116006)(44832011)(5660300002)(2616005)(71200400001)(8936002)(36756003)(966005)(54906003)(316002)(6512007)(99106002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: TPGMoN3OkkRU2Oa5QKpyl/A93S9v9zoASL9G0WgpdpiwRQHbMvRKos+g2T6OzUPqUsnx7UPAcClfJeGm/HL25ecfUzSYi41l9ZP0Jy7Cbos9Cwj3gRDWZsmGAa0H0ExMpjATlJB3saY/PWhANIW0yOe7zoOVyg858Upy43n2YEChGPsaHTrsrEm7IWrkgNk+CHSKgKJgyITeuXaxeMl+CLWz3hbHDyfiApGZPaSyTKjXg8AeTXom34YR+hpZpXwjElv5Q5ZW6R8GMRlC29JHq9GFHucHMy4rwmhnYmSUB0XcarvZNZeK13bddEWjrI2EgVmWOJzRLvJwuwSLu+P3lZDUH/LGo148VkD4O3qCVI/SnnPX0yz9oJXoJ8LldhPTdeKcSra/JbXcK0WXgCCKJZt8OXzh7+09y/ggmUHEa3c+nefeB9zPYEVCJwIgLy2G6n22UM8KHV5sujiTT3l+3ib4/pS6i6QUk117gLp2lCFTWIFkCSr2PrDMzNiS63TrVqLJLT5mNqa4N1sJl3cvjuWB5wqny1HeTdgcrBeFort95MY89xQj+tyQGw0V8Y0r1nSzZeTRaWGzjovJJm4d83vjUNNoPC7YJxd21+SXRdxzAwjwi7SJILokV+oCrznQRxrREuMS4pYrklKlUSMw/w==
Content-Type: text/plain; charset="utf-8"
Content-ID: <DD0F3B7436A63A4C9619953748A13822@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB5235.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b8b345d3-1635-4212-015f-08d8326a501a
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2020 20:19:06.4349 (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: 7XvfMVJ2wUWhhOuTe6POdRSoKyIV13Z2z/DVEL6d4aK1Dw8lntQe7I/GcGGoEzkGYapc/Qx2w3tZNaBAEQi2nA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3057
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/AqQ2n36BsjsG9MzvMc2uAx24nHE>
Subject: Re: [Hipsec] Benjamin Kaduk's No Objection on draft-ietf-hip-native-nat-traversal-31: (with 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: Mon, 27 Jul 2020 20:19:15 -0000

Hi Benjamin,

ke, 2020-07-15 kello 18:32 -0700, Benjamin Kaduk via Datatracker
kirjoitti:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-hip-native-nat-traversal-31: No Objection
> 
> 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/
> 
> 
> 
> -------------------------------------------------------------------
> ---
> COMMENT:
> -------------------------------------------------------------------
> ---
> 
> Thanks for addressing the potential "cross-message" attack on the
> HMAC
> contents of RELAY_HMAC/RVS_HMAC by prohibiting the Control Relay
> Server
> from offering the rendezvous services.

I actually wasn't so happy with my original coarse-grained solution for
cross-message attacks, so I wrote a more fine-grained one. My reasoning
is that I think reserving one public IP for RVS and another one for
Relay is maybe too much. So, the solution in draft-ietf-hip-native-nat-
traversal-32 is as follows (in a nutshell):

* Relay server can offer both RVS and Relay service but allows the
  client to pick only one.
* The server sends a registration error (new IANA type) if client tries
to picks the two services.

I also included some reasoning for the security mechanism. To avoid
bloating the existing section, I moved all text regarding to the cross-
message attack under Security Considerations in section 6.8.  Cross-
Protocol Attacks:


https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-32#section-6.8

> I think in order for the
> protection against the attack to be complete, though, we need to say
> that a HIP peer attempting to reach a Control Relay Server MUST
> reject
> any messages appearing to originate from that server, that contain an
> RVS_HMAC parameter.  That is, the current text will keep honest
> actors
> from generating the bad situation, but we also want to protect
> ourselves
> against accepting input from a bad actor attempting to cause the bad
> situation.

I added text regarding to your bad "bad actor" suggestion. This
required also a new notify type to that the client will send when it
receives RVS_HMAC in the wrong context. This text is also in section
6.8.

> Thank you as well for addressing all of my other comments on the -30.
> They seem generally satisfactory, and my apologies for not responding
> to
> them sooner.

no worries, thanks for the very detailed review!

> I just have two remaining remarks:
> 
> Section 1
> 
>    tunneling overhead).  Another solution is specified in [RFC5770],
>    which will be referred to "Legacy ICE-HIP" in this document.  The
> 
> nit: s/to/to as/

thanks, fixed

> Section 4.6.2
> 
>    [RFC7401] section 5.3.5 states that UPDATE packets have to include
>    either a SEQ or ACK parameter (but can include both).  According
> to
>    the RFC, each SEQ parameter should be acknowledged separately.  In
> 
> I don't see anything to support "acknowledged separately"; on the
> contrary, I see "A host MAY choose to acknowledge more than one
> UPDATE
> packet at a time; e.g., the ACK parameter may contain the last two
> SEQ
> values received, for resilience against packet loss."  Perhaps the
> intent was "each SEQ parameter needs to be explicitly acknowledged"?

"...in the context of this document" - good catch. I revised the text
as follows:

In the connectivity check procedure specified in Section 4.6.1, each
SEQ parameter should be acknowledged separately.