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
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/6S-J1c4Ayr97n6JtzwW4b4u5mik>
Subject: Re: [Hipsec] Secdir last call review of draft-ietf-hip-rfc4423-bis-19
Precedence: list

Hi Sean,

On 02/27/2018 05:06 PM, Sean Turner wrote:
> Reviewer: Sean Turner
> Review result: Has Nits
>=20
> This is a bis draft of the HIP (Host Identity Protocol) Architecture an=
d
> because of that I focused on what=E2=80=99s changed (i.e., I reviewed t=
he diffs from
> https://www.ietf.org/rfcdiff?url1=3Drfc4423&url2=3Ddraft-ietf-hip-rfc44=
23-bis-18).
> It=E2=80=99s still HIP but with a slightly expanded scope; it=E2=80=99s=
 still Informational.
>=20
> 1. s4: The one place where I=E2=80=99ll step out from not looking at th=
e old is a
> similar-ish recommendation that was in the RF4423:
>=20
>     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.
>=20
> 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=20
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 rea=
lly
> 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=20
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,=20
legacy applications which should be supported for backwards=20
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=E2=80=99t an additional drawback the need to have a HIP-a=
ware firewall?

Good point. It's both a benefit and drawback from the viewpoint of=20
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=20
to various services and devices. Since HIP introduces a new namespace,=20
it is expected that also the HIP namespace would be filtered for=20
unwanted connectivity. While this can be achieved with existing tools=20
directly in the end-hosts, filtering at the middleboxes requires=20
modifications to existing firewall software or new middleboxes [RFC6538].=


How does this sound?