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

Miika Komu <miika.komu@ericsson.com> Wed, 28 February 2018 15:34 UTC

Return-Path: <miika.komu@ericsson.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 625DE12EB12 for <secdir@ietfa.amsl.com>; Wed, 28 Feb 2018 07:34:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level:
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable 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 GUFIJT0W2AfT for <secdir@ietfa.amsl.com>; Wed, 28 Feb 2018 07:34:08 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 B9A3812D960 for <secdir@ietf.org>; Wed, 28 Feb 2018 07:34:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519832042; 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=umqc2P2jMbmmF4SvTtMDbEfoqs/3IzA9/Z80YzCIYGU=; b=Lsa9Q+NpCOoZQ2rEaCiCIAdSU0qD4oM+Awjn8vEiFhvxmsZHzYReO4s9sVEmPwlG AFj9vdH6rkBthUurv1IfgRKBEBCIzAkDyVt+e16FeTr3wXuSb3/aw8v7AOCd5aI3 JUJw7qvNUl3nx+hdaCgcyeKkbrJmRYT9QPW6My44H+w=;
X-AuditID: c1b4fb2d-4b1ff70000005540-9b-5a96cbea732a
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A8.77.21824.AEBC69A5; Wed, 28 Feb 2018 16:34:02 +0100 (CET)
Received: from [131.160.51.186] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.352.0; Wed, 28 Feb 2018 16:34:02 +0100
To: Sean Turner <sean@sn3rd.com>, secdir@ietf.org
CC: draft-ietf-hip-rfc4423-bis.all@ietf.org, hipsec@ietf.org, ietf@ietf.org
References: <151974401093.28581.6727583492292312298@ietfa.amsl.com>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <61df7006-3ce9-2929-b58d-af500fa40ea8@ericsson.com>
Date: Wed, 28 Feb 2018 17:34:02 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <151974401093.28581.6727583492292312298@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM2K7h+6r09OiDE5ftLI4d+IYq8XURZOZ LZ5tnM9icWVVI7PFh4UPWRxYPZYs+cnkcfAgYwBTFJdNSmpOZllqkb5dAlfGhE8XmAp+yFY8 XjCXvYHxnngXIyeHhICJxJqPk1m6GLk4hAQOM0o8PnWOCSQhJLCGUeLQE6AEB4ewgKvEianZ IGERAWOJx30zwUqYBYIljs36wgJR7iyxeuZ0sDibgJbEqjvXmUFsfgFJiQ0Nu8FsXgF7ia0d z8DqWQRUJX50/WYDsUUFIiQ6V85ngagRlDg5E2Itp4CLxJJNBhCrLCRmzj/PCGGLS9x6Mh/q BG2JZQtfM4OUCwmoSFw8FjyBUWgWkkGzkHTPQtI9C0n3AkaWVYyixanFxbnpRsZ6qUWZycXF +Xl6eaklmxiBQX9wy2/dHYyrXzseYhTgYFTi4dXfMS1KiDWxrLgy9xCjBAezkgjv6e1AId6U xMqq1KL8+KLSnNTiQ4zSHCxK4rwnPXmjhATSE0tSs1NTC1KLYLJMHJxSDYydxt2z1qwrOSW9 ZMGy/NLW+RMnr9vSGRv6dInXhlqL48VTdW50bFJlPTfLiT9++VLNM6rtu/9pd7+XK6nzjp3n ZF9nWll1/vGlRy079CdKtXnOOHn3mde5SYmuDGFdGzymq+hdTfEtbHJ19/2REHCMq7qW77hJ GmOg9I7/HjPELuy6/zCf202JpTgj0VCLuag4EQA49RhQdgIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/C8HOIRQv_BH__0SSwuUokVSjnW8>
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: Wed, 28 Feb 2018 15:34:09 -0000

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?

> 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?

> 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?