Re: [Hipsec] Secdir last call review of draft-ietf-hip-rfc4423-bis-19

Sean Turner <> Mon, 05 March 2018 16:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D16E12D964 for <>; Mon, 5 Mar 2018 08:10:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R-KMdykIUubL for <>; Mon, 5 Mar 2018 08:10:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C17112EB22 for <>; Mon, 5 Mar 2018 08:10:13 -0800 (PST)
Received: by with SMTP id f25so21232192qkm.0 for <>; Mon, 05 Mar 2018 08:10:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dImOYBZ/jzpScMePEIT6j9OPCXJZCkHP+8aoV4+mmOA=; b=NAsHFI09AAhiMkD/yG9sIvT8jAV9f1XDTn07ixK6O/UKuFl1kmc45QUxjC6C/tWfBT CmLap8CR6EU2GAl55dwF2ComBJgedixeTBYGOQI0Kq20FdN/MaxK8MfxYlAy7w4YZo/G 1J4sa0w2o1i6dUxsMdDB6yD+mPmzrz+8HV9pQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dImOYBZ/jzpScMePEIT6j9OPCXJZCkHP+8aoV4+mmOA=; b=aPJ7x6CfGdClQjhvvk7AASxAOs2dLt/cAYpUs0ukaetqdaVsKEVgXVXcUCnuJacrLq /SzCvKJ1mnxDUWsxdq85ztyfha+TWRutkKUsga9ocX8Hm7IR6L+5+W2UfE6ZibJY+o4K s/XTCW1IrOu22OHLuHwH4xSdBwc6yMBX8VT/P9xmACdrs7zaAV5UmD/bs/CNU3l8B+a4 Xvt8Jcv6+jr45Vu9ZISrJtuoiDP6bVg7n7nyMchXnS3MgD/oiMdXe9ddszrHhRoe5/eq t1Cc5NhDeQPW38xxME5Zwh4rrYZdBUynltnLMtGEkuConAP98m1EVjOOTAZvd6mg3ujI Cjdg==
X-Gm-Message-State: AElRT7HsSnS7jx9gSvf7uC56/K6uOrsOPskGBBVL1JHWI62nM0mjUD22 YPudZs4wW8SAlIjFv+GIsiZBNL/porw=
X-Google-Smtp-Source: AG47ELtGFy1cgABAgr949wWLtbUmvoAJrgI7CenLy9T1osj+Og3VyGsKqVoRvOoaFIQRD9KmuKPjKQ==
X-Received: by with SMTP id b3mr21615233qke.65.1520266212308; Mon, 05 Mar 2018 08:10:12 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id n29sm9516747qtf.18.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Mar 2018 08:10:11 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Sean Turner <>
In-Reply-To: <>
Date: Mon, 05 Mar 2018 11:10:09 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Miika Komu <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [Hipsec] Secdir last call review of draft-ietf-hip-rfc4423-bis-19
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Mar 2018 16:10:51 -0000

> On Feb 28, 2018, at 10:34, Miika Komu <> wrote:
> Hi Sean,
> On 02/27/2018 05:06 PM, Sean Turner wrote:
>> Reviewer: Sean Turner
>> Review result: Has Nits
>> This is a bis draft of the HIP (Host Identity Protocol) Architecture and
>> because of that I focused on what’s changed (i.e., I reviewed the diffs from
>> It’s still HIP but with a slightly expanded scope; it’s still Informational.
>> 1. s4: The one place where I’ll step out from not looking at the old is a
>> similar-ish recommendation that was in the RF4423:
>>    In this document, the non-cryptographic forms of HI and HIP are
>>    presented to complete the theory of HI, but they should not be
>>    implemented as they could produce worse denial-of-service attacks
>>    than the Internet has without Host Identity.
>> Should the should not be a SHOULD NOT?
> I can change this for sure but the whole document is written without the capitalized terms due to its informal nature... actually, this sentence is a bit moot since non-cryptographic forms of HI are only referenced in the text. I would suggest rephrasing this as follows:
> "In this document, some non-cryptographic forms of HI and HIP are
> referenced, but cryptographic forms should be preferred because they are more secure than their non-cryptographic counterparts."
> Would that work for you?

Yep - works just fine.

>> 2. (none security) s4.4: Is the paragraph about IPv4 vs IPv6 vs LSI really
>> necessary?  I.e., is this yet another thing that folks are going to use to not
>> transition to IPv6?
> I think the draft should discuss IPv4 compatibility because it is part of architecture design.
> Btw, do you mean this paragraph or something else?
>   The interoperability mechanism
>   should not be used to avoid transition to IPv6; the authors firmly
>   believe in IPv6 adoption and encourage developers to port existing
>   IPv4-only applications to use IPv6.  However, some proprietary,
>   closed-source, IPv4-only applications may never see the daylight of
>   IPv6, and the LSI mechanism is suitable for extending the lifetime of
>   such applications even in IPv6-only networks.
> IMHO, the LSIs should be supported mainly for the sake of proprietary, legacy applications which should be supported for backwards compatibility. The next paragraph also mentions a limitation of the LSIs:
> The main disadvantage of an LSI is its local scope.  Applications may
>   violate layering principles and pass LSIs to each other in
>   application-layer protocols.
> Let me know if you would like change or emphasize something?

No - I think after re-reading this the LSI is sufficiently poo-pooed to not be something folks will want to use ;)

>> 3. s11.2: Isn’t an additional drawback the need to have a HIP-aware firewall?
> Good point. It's both a benefit and drawback from the viewpoint of firewalls. s11.1 mentions:
>      [...] First, the use of
>      HITs can potentially halve the size of access control lists
>      because separate rules for IPv4 are not needed [komu-diss].
>      Second, HIT-based configuration rules in HIP-aware middleboxes
>      remain static and independent of topology changes, thus
>      simplifying administrative efforts particularly for mobile
>      environments.
> As a drawback, I could add something like this to s11.2:
> In the current Internet, firewalls are commonly used to control access to various services and devices. Since HIP introduces a new namespace, it is expected that also the HIP namespace would be filtered for unwanted connectivity. While this can be achieved with existing tools directly in the end-hosts, filtering at the middleboxes requires modifications to existing firewall software or new middleboxes [RFC6538].
> How does this sound?