Re: [Hipsec] Secdir last call review of draft-ietf-hip-dex-06

Miika Komu <miika.komu@ericsson.com> Wed, 06 March 2019 08:56 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 0753A130ED1 for <hipsec@ietfa.amsl.com>; Wed, 6 Mar 2019 00:56:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=dWdWFXZm; dkim=pass (1024-bit key) header.d=ericsson.com header.b=kHBA5qPn
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 Nak-jzzDV8nb for <hipsec@ietfa.amsl.com>; Wed, 6 Mar 2019 00:56:28 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 79C4A130E2B for <hipsec@ietf.org>; Wed, 6 Mar 2019 00:56:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551862581; x=1554454581; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xJUqlH2jef1uFI/GmaoO8nNdvnWkxP3wOmzWCbkqbec=; b=dWdWFXZmwD94+E085P/oiXdFM3y3YF6/wYRzEpYqket2FGS2dk+0ifMuUFcOGAMV OjajX7/B5Agy+plJ77pWbq4mlujvesyrNNs3nER1UC8PEW9WBpVlxXJiYBWR87ga ijN4cuKNJrG4nPAMfN9RD4cWdaUiZwMvBFc5A2LYuFE=;
X-AuditID: c1b4fb30-fabff7000000355c-25-5c7f8b35b74e
Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 02.98.13660.53B8F7C5; Wed, 6 Mar 2019 09:56:21 +0100 (CET)
Received: from ESESBMR504.ericsson.se (153.88.183.139) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Mar 2019 09:56:21 +0100
Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESBMR504.ericsson.se (153.88.183.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Mar 2019 09:56:21 +0100
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 6 Mar 2019 09:56:20 +0100
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=xJUqlH2jef1uFI/GmaoO8nNdvnWkxP3wOmzWCbkqbec=; b=kHBA5qPnDnFcKI/bQsKXeUJPmK+l/yEQBaAo5QbLbz6COePJReDdqAYs4dBHbbxpfWibEKr4YBTr4V1WBZ5BDBgyltpChVY69L4h3oDdKBWrJJHfn2m5hBXYvgDYilVenPPl5XYhoBBkZNrQuBKPMRj/oiWspUvw0wSsF8mosz8=
Received: from DB6PR0701MB2438.eurprd07.prod.outlook.com (10.168.72.151) by DB6PR0701MB2711.eurprd07.prod.outlook.com (10.169.215.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.11; Wed, 6 Mar 2019 08:56:20 +0000
Received: from DB6PR0701MB2438.eurprd07.prod.outlook.com ([fe80::ac69:ffe9:c4ad:2567]) by DB6PR0701MB2438.eurprd07.prod.outlook.com ([fe80::ac69:ffe9:c4ad:2567%12]) with mapi id 15.20.1686.016; Wed, 6 Mar 2019 08:56:20 +0000
From: Miika Komu <miika.komu@ericsson.com>
To: David Waltermire <david.waltermire@nist.gov>, "secdir@ietf.org" <secdir@ietf.org>
CC: "hipsec@ietf.org" <hipsec@ietf.org>, "draft-ietf-hip-dex.all@ietf.org" <draft-ietf-hip-dex.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: [Hipsec] Secdir last call review of draft-ietf-hip-dex-06
Thread-Index: AQHTrEpTSI+7rWzwMU+YynlMP3PA0qYAnFMA
Date: Wed, 6 Mar 2019 08:56:19 +0000
Message-ID: <b8cb1e30-17a8-80ad-e21d-47bafc0ae780@ericsson.com>
References: <151935130185.22539.7608018209255295739@ietfa.amsl.com>
In-Reply-To: <151935130185.22539.7608018209255295739@ietfa.amsl.com>
Accept-Language: fi-FI, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: HE1PR05CA0373.eurprd05.prod.outlook.com (2603:10a6:7:94::32) To DB6PR0701MB2438.eurprd07.prod.outlook.com (2603:10a6:4:5b::23)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [192.176.1.92]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9818d095-5981-4fc3-415b-08d6a21199b4
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:DB6PR0701MB2711;
x-ms-traffictypediagnostic: DB6PR0701MB2711:
x-ms-exchange-purlcount: 2
x-microsoft-exchange-diagnostics: =?utf-8?B?MTtEQjZQUjA3MDFNQjI3MTE7MjM6b25BU2RzbGFXQWkvMngraG45Wmw1U2dV?= =?utf-8?B?bWhGS05hLzlKL3RZdTFPN3dYTGZvamRhbW43R09xaTNoL3d0TktweCtYUlhk?= =?utf-8?B?eFFlZjBvN2ZYcEhzdWF2OUIzTzliZm5yWHJhaUc2R0gvRTBOWjdpT3M2SmlF?= =?utf-8?B?OVVjbnlISm5qcFNFeW5rME9rSlNYbWFjK0h2RnVBa2I1Um5aWklidEVSMzRF?= =?utf-8?B?VCtiUHg0OVhHb0RiNDVKNm5scnN6T3RjRm12clNkU1MvOHozdEhjUzYxckdP?= =?utf-8?B?TDdRYWg3amRoc1BwVVVvUnVxM0k0eHpEV2FyQ3ZDR1ZNTzdnSC8ya2lsSUlW?= =?utf-8?B?UjJETFpvZlhQZGt6d0RzeVNtTkFBZGFiM3JmUTVKay9rdVJzRng5VlRrQlFR?= =?utf-8?B?SG0vYnN6MkUyb2FIWFZ3R0x4L1Vrc0paVlY2UFArcG9DK2Y4S3g4RmduOVU4?= =?utf-8?B?cEF3cm1WTEZGZUFzRVNQeGtEOXJXS3djVHQ3cEdQdXNsRHdlTWZBalNzdS9l?= =?utf-8?B?SkltdXpHUVNoME1WTE5BMEFzU0tRRS96RGhaUG1zSFlYc0ZoZUNsRTl3cWc1?= =?utf-8?B?dVNTMi9NelUxMnpWZGF5Q3ZYZTZkRmNFT3pONjZ4eDJqakU2dDRQalNLSzBD?= =?utf-8?B?aEE3R0lFUCtNeDlwaU0xNUZBdVhBTUVJaHFqRDNCdXlLZS8xc2xuNTVndWc0?= =?utf-8?B?NDRldy96VzYzSEtsZXdkTFBYbGJRdUg4ejg4SlpRMUlHSkF1NHkyN29JK0xo?= =?utf-8?B?SnNNbDdaVndiVkNCdzJmenMwUWFNbW1GWmM1UjVVTit0MmhVaVBWN3VxcEpW?= =?utf-8?B?OE1nVjM2UkMrR21KRUJNUXpkL0daNXRaTFZTckEweXZIVVNielVrK0hIU2Nm?= =?utf-8?B?ZkhBc3NmZ1lkRTh2MjdvcWJ2MlduUHNsN2Q2cUtmcGMxaTlBNDh0REJIUWN5?= =?utf-8?B?bUpSNElhZkIrRTlDd3JIL3FueWxzclVQQ3dLYjAyN3FkUXIzVEFCOGtCZmRO?= =?utf-8?B?S3N5cW1JeUVzbjZEYVVQaE9ZVXd0bzRXZnRJYzYrWjlNaWcwMWg1Q2FrOHV2?= =?utf-8?B?eUtKeGV0K204bTFDVzBTWFcxZDBRaW5Xc0Ivd2wzSmN3Y2JqZDR3azNmOG5E?= =?utf-8?B?OGRtdE9OT1VPWEZVYUdxcVp0aW9yRDFXZzR2RXVLZUR1ZzByR0J6bTkwZkxi?= =?utf-8?B?VmRLelZ4RUhUYmhnN1dwOWp3cmlxUXhIU01BWmdpZmpVL2dIcU9ZVFZRTURO?= =?utf-8?B?N2llRk91blRER3ZCNFNqMVhqWnBRU1hSQk84MUc0YjFMVVUzYTNpdVQ0YzAy?= =?utf-8?B?QWlmUitmcHhNWGdNQ1pEcll2Q3dDWEZCeXJlakdTc3BqUjk3QXZTeEN1R1Va?= =?utf-8?B?ZDV1djk3Yzc5MkN6TnlpakxkYkQzbXNqVzVXVnNzWnF0dlZIaldiTkovQjFN?= =?utf-8?B?OEZabGhicUlsemZUWFU1SWpNZ0ZFRktBNWNQTjJzdk9uTmEvMGdGTFM5dGMz?= =?utf-8?B?OERPbUdyY0VOaXFpajhWS29VZS9idE1SMElYcy9GS2NxYWhaRmVEUmwxQ1E0?= =?utf-8?B?cUZsSlU5b096NVhPZnMyUWptWEtnVzhybVhvYjViWm45bU50NE83WkptMy9P?= =?utf-8?B?TjhPWnpETDZJT29MRndVNXJ1NlFUNHgrc05pcG5FR0REN1R6VTd6N0hJT0g4?= =?utf-8?B?ejNvU29PZkNZMmpJV1lhaTU1dDdCVUZjaXNGUkNWL1BZUGVxY09GWVA1UGth?= =?utf-8?B?b1F0MTB5ZXdrSHFTVE41bGIva2h5Tk9uUWpXVXdOcmREUkJFV1VYM0x2ZGJw?= =?utf-8?B?MlJkOFJYUnNhcWFHNzFZcHdtVzB4OS9sd0hXWEVqNktUeGk2UmpwQXpSQ0p3?= =?utf-8?Q?Hd/TnnPP1zTivQmdOvmJJinZWeDJl/ou3i?=
x-microsoft-antispam-prvs: <DB6PR0701MB2711DB33F0CB0FCC5690AC79FC730@DB6PR0701MB2711.eurprd07.prod.outlook.com>
x-forefront-prvs: 0968D37274
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(366004)(39860400002)(376002)(346002)(85644002)(199004)(189003)(81156014)(6436002)(71200400001)(6512007)(76176011)(36756003)(97736004)(66066001)(6486002)(2906002)(5660300002)(14444005)(6116002)(3846002)(52116002)(256004)(71190400001)(6306002)(99286004)(68736007)(86362001)(110136005)(6506007)(102836004)(386003)(31696002)(8936002)(53546011)(53936002)(305945005)(316002)(229853002)(6346003)(54906003)(478600001)(486006)(446003)(11346002)(2501003)(476003)(2616005)(7736002)(44832011)(26005)(4326008)(186003)(106356001)(25786009)(966005)(31686004)(105586002)(14454004)(6246003)(81166006)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0701MB2711; H:DB6PR0701MB2438.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=miika.komu@ericsson.com;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: PrKbwUdmvXrJeLm8+zAWHtuIsEef1PY0CS/B1EEfux7xeC9ORCxZGzgAgmlkAbgvKtvSUmyGcdSjBpT2wszhgx7dlAnuBq7xBDqG4sLGfW/qgZYZgJk+Cn5zxAGozgNArvCR5Y7Ug/6uVTveK4uqdo6Pp635Gkoegh3kmcMVuhJoQEzWk6zJWr05GF5XIPb5cZejZ0tVdvIPqYAFMFbdsQ5PxjFe1mumoTwKhcOUx7rQL3VFUoqnZEe/ZH8LDppp6li+94s2BK6OkpmgAue621AnNoH7YiIJTk3aalsT5WWW1VbWeBO20azgJnnFxrqzWAmz5NeRZxYexbN4R5N4fZGdzeyZGhY8UF/kDaBGTKgr1+0vFaiYkOYEN6t9TK1HZmTNoOTrqwLLkE5mRV6RUZZpWOQq41iFQ9ObsjfmMus=
Content-Type: text/plain; charset="utf-8"
Content-ID: <9ABC0562EE854049AC80F5D2FD2B27F9@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9818d095-5981-4fc3-415b-08d6a21199b4
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2019 08:56:19.9417 (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-Transport-CrossTenantHeadersStamped: DB6PR0701MB2711
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHfd733fZuNHhcigdFyyGEVmrDYkVUkpQW2vqklJFL33Repm3T 1D54ISy80MJWTZfLKyVCXvFCmQ0LBopopnmJNS8TMdG8IJJabq9F337/8z//55wDD02KKjnu tEKpYVRKebKYK6D0Ue33jh4vyokO7M3zkTYV73ClY/rPSKqrKiWltiYjJV2utFLnOKE1NZtE 6Ih5myMjrglOxzHJigxGFXAmRpCgbzyUtpOcaXo/yM1FzxMLEZ8GHARLxnGqEAloEe5F8Fvb TLBiHUHXu0H0T1i+j+851QR8m8rl2QWFtSRYFoa5rPOUgNXHWyQrbAi+Fq8S9jFc7Af1k6Ok nV1wJLQXzzriJH6EoHvYTNmN/fgCzA3nc9imi9C6rUcsS6Dn1ZzjIQr7gK6ki2tnIT4Lg6Vr jqwIn4e+5ZHdLE3zcQgUGBznIewJr1t2HHNJ7AbjM0aCPRtDzdsBkmVXmJ/e4dj3AaxDMKWt 22s6Av2jM4jlg7A1NMVl2ROGjEV79XAwV42QbHgCwYp2nWdfwh6+P+HF9rjDxvRPHtszK4L+ zXIOa6TCSu0AoUWSsv8WLNuNk9gX3nQFsOVQ+FJt4LHsDU+KrA4WYmcw62eol4hTj1zVjPpW SrxE4s+oFLFqdarSX8lomtHux/nQ+iuwA83PBZsQppF4n/Bufk60iCPPUGelmBDQpNhFqM/b LQnj5FnZjCr1pio9mVGbkAdNid2EWyLnaBGOl2uYJIZJY1R/XYLmu+ciH9+elkWNV7zllNMJ 7yuFP154zOgaGivqo5bqalOLjE5jQSc7esLCfakDk8oI29WIxIKQzDsNWZFWz4wxQ4gwVrby rPNTiSW9XNY9r0Up1hsTgphLbdlhix87uWtJSQUby5O29cOXHwoeTLY5WQwVTq59VZu62z7B 1/kKWdvQgphSJ8iP+ZEqtfwPZYb3szQDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/8II9eQMns_dVp6W3LFt1eq0L2eY>
Subject: Re: [Hipsec] Secdir last call review of draft-ietf-hip-dex-06
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, 06 Mar 2019 08:56:30 -0000

Hi David,

I am stepping in and helping the authors to finish the draft as agreed 
with the authors and HIP WG chair. I am not actively working on the 
topic, so I have very limited time for this but I have earlier 
background in HIP. Please let me know if the following comments and 
edits address your concerns?

On 2/23/18 04:01, David Waltermire wrote:
> Reviewer: David Waltermire
> Review result: Has Issues
> 
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area directors.
>   Document editors and WG chairs should treat these comments just like any other
> last call comments.
> 
> The summary of the review is Ready with issues.
> 
> In general this document is clearly-written and well-organized. It was a fun
> read overall.
> 
> I have the following concerns with the draft:
> -----------------------------------------------------------
> 
> Section 2.1:
> 
> You should use text from RFC8174 to indicate that lowercase versions of the
> keywords are not normative.
> 
> Something like the following would work:
> 
>     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>     "OPTIONAL" in this document are to be interpreted as described in BCP
>     14 [RFC2119] [RFC8174] when, and only when, they appear in all
>     capitals, as shown here.

fixed.

> Section 4.1.3.1:
> 
> "it can be long-lived with no need for rekeying" Small is open to
> interpretation. It would be useful to include some guidance on the expected
> amount of data to be exchanged before rekeying would be needed, or why this is
> a practical impossibility.

rekeying is subject to local policies, but a hard limit exists. I added 
the following sentence:

At the latest, the system MUST initiate
rekeying when its incoming ESP sequence counter is going to overflow,
and he system MUST NOT replace its keying material until the rekeying
packet exchange successfully completes as described in section 6.8 in
[RFC7402].

> Section 5.3.2 and 5.3.3:
> 
> In the paragraph on TRANSPORT_FORMAT_LIST, it would be good to document the
> specific ESP parameter value to be used from:
> https://www.iana.org/assignments/hip-parameters/hip-parameters.xml#transport-modes.
> This will remove any ambiguity.

I changed the sentence referring to the parameter value to be more specific:

The different format types are DEFAULT, ESP and ESP-TCP as explained in 
Section 3.1 in [RFC6261].

The actual choice(s) depend on local policy, I don't think we should 
mandate a specific one here.

> Section 6.6:
> 
> In items #5 and #6, what is "an acceptable time span"? Some guidance here would
> be helpful. I believe this is discussed earlier in the draft. Perhaps a
> reference back may provide some clarity?

this extension builds on RFC7401 which does give any explicit time 
values either:

https://tools.ietf.org/html/rfc7401#section-6.8

So I am a bit hesitant to add explicit timeouts here.

> Section 6.9:
> 
> In #1, under what circumstances would the NOTIFY packet not be dropped
> silently? Why is this not a MUST? Some explanation would be useful here. In
> general, many of the SHOULDs in the section 6 subsections, could use further
> justification.

good point, I changed the explicitly mentioned SHOULD to MUST.

Some of SHOULDs in section 6 are inherited from RFC7401. I would like to 
go through all of the SHOULDs in section 6 but it will delay the already 
delayed process for this draft. If we change some of the SHOULDs to 
MUSTs, I believe we need also WG concensus. So, as a quick resolution I 
just added the following note to section 6 intro:

It should be noted that many of the packet processing rules are denoted 
here with "SHOULD" but may be updated to "MUST" when further 
implementation experience provides better guidance.

...which I believe reflects the current reality.

> Section 8:
> 
> What is "a reasonable delta time"? Some guidance here would be useful.

good catch. The situation is actually related to sending of I1 packets, 
so I would actually change the time delta to a packet counter similarly 
as in RFC7401:

As an adversary could also send such an ICMP
packet in a man-in-the-middle attack with the aim to prevent the HIP
DEX handshake from completing, the Initiator SHOULD NOT react to an
ICMP message before retransmission counter reaches I1_RETRIES_MAX in
its state machine (see Table 3 in [RFC7401]).

> Section 9 (Security Considerations):
> 
> "The puzzle mechanism using CMAC may need further study regarding the level of
> difficulty." Study of what? Is the concern here that the impact on constrained
> devices at a higher level of difficulty is not well understood? Or is this
> concern around identifying best practices around raising the difficulty under
> specific conditions? A sentence or two on this would be helpful for the reader
> to better understand the issue.

It means finding puzzle values that don't exhaust computational 
resources with sensors. I changed the sentence to:

"The puzzle mechanism using CMAC may need further study regarding the

level of difficulty in order to establish best practices with current

generation of constrained devices."

> I don't see a mention of the non-protected Host Identity issue from section 1.1
> here.

I added an extra bullet:

Contrary to HIPv2, HIP DEX does not provide for end-point
anonymity for the Initiator or Responder.  Thus, any signaling
that indicates such anonymity should be ignored as explained in
Section 1.1.

> With regards to the 4th bullet, the text in section 3 should be referenced
> regarding HIT collisions. (nit)-> Referencing back to the relevant sections for
> the other bullets may also be useful.

Done!

>>From section 5.3.1, I don't see a mention of the issues around dealing with I1
> storms addressed here.

Added:

    Section 5.3.1 mentions that implementations need to be able to handle
    storms of I1 packets.  Contrary to HIPv2, R1 packets cannot be pre-
    computated in HIP DEX and also the state machine does not include an
    "R1_SENT" state (that would enable caching of R1 packets).
    Therefore, an implementation has to cache information (e.g., at least
    the HITs) from incoming I1 packets and rate control the incoming I1
    packets to avoid unnecessary packet processing during I1 packet
    storms.

> Section 10:
> 
> It can be useful for IANA to reference the specific registry by name and URL in
> the IANA considerations. It can also be useful to include the actual table in
> the IANA considerations section. These are embedded in section 5 in the current
> document. Suggest moving these tables to the IANA consideration section.

I think it would break the flow of the text. Instead, I double checked 
that all new parameters are listed in the IANA section and replicated 
the type values there.

> I found the following nits in the draft:
> -------------------------------------------------
> 
> Section 1.1:
> 
> In the text "any signaling that indicates such anonymity should be ignored" it
> would be useful to provide an example of such signaling.

good point, I modified the description as follows:

...and any signaling (i.e., HOST_ID parameter contained with an 
ENCRYPTED parameter) that...

> /may carry data payload/may carry a data payload/

fixed

> The packets are referred to as 1st, 2nd, 3rd, and 4th here, and as I1, R1, I2,
> and R2 in section 4. Consider use a consistent naming approach throughout this
> document to improve clarity.

Agreed, fixed.

> Section 1.2:
> 
> Section 8 is not included in this summary. Suggest adding a sentence about it.
>
> (nit) Section 10 is not linked as well.

thanks, fixed.

> Section 2:
> 
> /Terms and Definitions/Terms, Notation, and Definitions/

fixed

> Section 3:
> 
> "other methods are used to map the data packets to the corresponding HIs" What
> are these other methods? What if ESP is not used and the SPI is not an option?

I added to the end of this paragraph:

When other user data packet formats are used, the
corresponding extensions need to define a replacement for the
ESP_TRANSFORM [RFC7402] parameter along with associated semantics,
but this procedure is outside the scope of this document.

> Section 4.1.2.3:
> 
> In the diagram, I think there is a missing arrow between I2-SENT and R2-SENT.
> Please double check. Also, this diagram is far from simple. Maybe name this
> section "HIP State Diagram"?

There is an arrow from I2-SENT to R2-SENT and the state diagram is 
identical to RFC7401. I would prefer to keep the title the same as in 
RFC7401, "Simplified State Diagram", although I agree it is not so simple :)

> Section 4.1.3.2:
> 
> "Even though this input" Please clarify the "this" indefinite article.

fixed (...the concatenated input...)

> Section 4.1.4:
> 
> /This will limit state/Using non-volatile storage will limit state/
> 
> This section should reference section 6.11, since some of the content is
> duplicated there.

thanks, fixed as suggested

> Section 5.2.3:
> 
> /It is defined in/The HOST_ID parameter is defined in/

thanks, fixed

> Section 5.2.5:
> 
> /at least 64 bit/at least 64 bits/
> 
> Update the reference "#I and the puzzle solution #J (see [RFC7401])" to point
> to section 4.1.2 in RFC7401.

done

> Section 5.3.2:
> 
> The discussion of difficulty K touches on a local policy issue that is
> discussed in section 7. It could be useful to reference section 7 from here.
> 
> Update "(see [RFC7401])" to point to section 4.1.2 in RFC7401.
> 
> /based on which it chose the ECDH/based on which the Responder chose the ECDH/

fixed both of these.

Thanks for insightful and very technically detailed comments! Please let 
me know if this discussion resolves your concerns.