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

Sean Turner <sean@sn3rd.com> Mon, 05 March 2018 16:10 UTC

Return-Path: <sean@sn3rd.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AF212D964 for <secdir@ietfa.amsl.com>; Mon, 5 Mar 2018 08:10:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 uxsfC-S5GQL6 for <secdir@ietfa.amsl.com>; Mon, 5 Mar 2018 08:10:47 -0800 (PST)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 3450D12EB20 for <secdir@ietf.org>; Mon, 5 Mar 2018 08:10:13 -0800 (PST)
Received: by mail-qk0-x235.google.com with SMTP id s188so21198529qkb.2 for <secdir@ietf.org>; Mon, 05 Mar 2018 08:10:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; 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; d=1e100.net; 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=JfGmvRCsjz65idBDOx2KW985tLskO1X8lWgge7P0Ae1FQZLs1rAAY57Cjgr7xA96Wc tYur/ZqjLtp1SE0sB4oziNnrRfuSAgqjkJkUCbTohXWT4/6f9330c51tACNSdDJoDpo8 dQQzgaaNggVLuNswkAm0chHKJjOD4182u5G81KYryW/oaiy7UGuWnBDbgWX+pbICesgq us9m5OcHDmwhXShoKpD+ePZSJtknHAHCWSnzIA52uyUjiPim2TEewFHYT1JiWGEWhUai bgmD1ViPFesfeXei313++Nk67PMqn5TLmYjZnaD0C8M8Og7VC5rk5gArKr2bJYGZ+5XU J3zg==
X-Gm-Message-State: AElRT7GK/rec8RHY4mbI1X6oGeZwifwER38mQy/QYzTgcWJ7iEKPstu1 VpP8BZpny3upmZs2G4qEcmyJhg==
X-Google-Smtp-Source: AG47ELtGFy1cgABAgr949wWLtbUmvoAJrgI7CenLy9T1osj+Og3VyGsKqVoRvOoaFIQRD9KmuKPjKQ==
X-Received: by 10.55.153.3 with SMTP id b3mr21615233qke.65.1520266212308; Mon, 05 Mar 2018 08:10:12 -0800 (PST)
Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id n29sm9516747qtf.18.2018.03.05.08.10.10 (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 <sean@sn3rd.com>
In-Reply-To: <61df7006-3ce9-2929-b58d-af500fa40ea8@ericsson.com>
Date: Mon, 5 Mar 2018 11:10:09 -0500
Cc: secdir@ietf.org, draft-ietf-hip-rfc4423-bis.all@ietf.org, hipsec@ietf.org, ietf@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A424A8D2-DC71-4793-8FF3-BADBF7CA8E05@sn3rd.com>
References: <151974401093.28581.6727583492292312298@ietfa.amsl.com> <61df7006-3ce9-2929-b58d-af500fa40ea8@ericsson.com>
To: Miika Komu <miika.komu@ericsson.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/50BsyAxDiAfKeB1JYia6TWjOnM0>
Subject: Re: [secdir] Secdir last call review of draft-ietf-hip-rfc4423-bis-19
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Mar 2018 16:10:49 -0000

> On Feb 28, 2018, at 10:34, Miika Komu <miika.komu@ericsson.com>; 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
>> https://www.ietf.org/rfcdiff?url1=rfc4423&url2=draft-ietf-hip-rfc4423-bis-18).
>> 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?

wfm

Cheers,

spt