Re: [Hipsec] Iotdir last call review of draft-ietf-hip-dex-11

Robert Moskowitz <rgm@labs.htt-consult.com> Mon, 27 January 2020 18:36 UTC

Return-Path: <rgm@labs.htt-consult.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 DA1173A08F8; Mon, 27 Jan 2020 10:36:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no
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 aorQ_v87upJl; Mon, 27 Jan 2020 10:36:01 -0800 (PST)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 074403A00DF; Mon, 27 Jan 2020 10:34:22 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id DE80962162; Mon, 27 Jan 2020 12:15:24 -0500 (EST)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 39HGCAiCFSV5; Mon, 27 Jan 2020 12:15:18 -0500 (EST)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 421E262135; Mon, 27 Jan 2020 12:15:16 -0500 (EST)
To: Michael Richardson <mcr+ietf@sandelman.ca>, Iot-dir@ietf.org
Cc: last-call@ietf.org, draft-ietf-hip-dex.all@ietf.org, hipsec@ietf.org
References: <157466392692.32744.2341419042914872690@ietfa.amsl.com>
From: Robert Moskowitz <rgm@labs.htt-consult.com>
Message-ID: <904e10e8-36eb-46d2-8ed0-1d734076f982@labs.htt-consult.com>
Date: Mon, 27 Jan 2020 12:15:08 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <157466392692.32744.2341419042914872690@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: base64
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/NEK4ZoPKMsSwP7M8F_7bDb6F-WU>
Subject: Re: [Hipsec] Iotdir last call review of draft-ietf-hip-dex-11
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 Jan 2020 18:36:10 -0000

I do not see anything in this comment that is directly actionable, but 
will provide some comments here.

On 11/25/19 1:38 AM, Michael Richardson via Datatracker wrote:
> Reviewer: Michael Richardson
> Review result: Ready
>
> I am the assigned IoT-Directorate reviewer for 1draft-ietf-hip-dex
> I reviewed the -11 version.
>
> I did not identify any technical problems or gaps.
> The introduction tells that I won't understand this without a good
> understanding of RFC7401 (HIPv2).  I went ahead anyway, given that I did know
> HIPv1 (RFC5201) and IKEv2.
>
> While it is clear that I could not implement without knowing 7401, I did find
> that I could understand most of the goals, the compromises that were made to
> reduce the complexity for constrained environments.  I did go back and read
> 7401 in the end to fill in a few gaps.
>
> Particularly I really needed to understand RFC7343 HITs of the new type, and
> I did not manage to understand that part.  I observe that a new ECDH type of
> HIT is defined, but I did understand how these values would be
> exchanged/stored or looked up.

Sec 7 HIP Policies:

    All HIP DEX implementations SHOULD provide for an Access Control List
    (ACL), representing for which hosts they accept HIP diet exchanges,
    and the preferred transport format and local lifetimes. Wildcarding
    SHOULD be supported for such ACLs.

There may be other approaches used, but ACLs is a SHOULD.

> I would appreciate a use case or two which has been sufficiently built-out so
> that I can see the whole picture. If ECDH HITs come from DNS (via AAAA
> records) for instance, then I'd appreciate an understanding if/how the
> constrained device is able to leverage DNSSEC.
> In particular, I'd like to know what kind of applications are ruled out by
> lack of PFS, and if a kind of PFS can be restored by rotating HITs in DNS.

A new Applicability section should help on this.

>
> Would this document play well with draft-ietf-ipsecme-implicit-iv?
>
> I am unclear if the diet nature of DEX is more about:
>    (1) constrained/challenged networks
>    (2) constrained/slow CPUs
>    (3) systems with very minimal amounts of flash

Mostly 2 (see new Applicability section), then 1, and only slightly 3.

> (1) networks have often very small packet sizes, and I would appreciate
> understanding the total frame sise of each I1/R1/I2/R2, and any impact that
> fragment assembly might have on the statelessness of the I1/R1 exchange.

Somewhere there are some notes that Rene and I did on minimal packet 
size.  We were over the 140 bytes of SMS for the smallest R2 packets, 
but everything COULD be done under 200 bytes.  Challenge is that 
variability in parameters can result in larger packets, so any claim in 
the document would only be on the smallest possible size, not the 
maximum let alone the likely size.

>
> I know that HIP has be profiled for use in 802.15.9, and I assume that HIP
> DEX is even better, but the lack of PFS might be a show stopper.

See the new Applicability section coming in dex-12.txt

> (2) slow/sleepy CPUs are not going away, but the amount of available flash on
> rather cheap, small and sleepy devices is now in the multiple megabytes, so
> it is unclear if further code simplications are worthwhile.

It is possible that no more slow CPUs will be shipped, but I doubt that.

>
> My questions should not stop the document from advancing.
>
>

Thank you, Micheal.