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>
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/1lJfdB3nCrsSftpLw_SogCRg5Y4>
Subject: Re: [Hipsec] Secdir last call review of draft-ietf-hip-rfc4423-bis-19
Precedence: list


> On Feb 28, 2018, at 10:34, Miika Komu <miika.komu@ericsson.com> wrote:
>=20
> Hi Sean,
>=20
> 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=E2=80=99s changed (i.e., I reviewed =
the diffs from
>> =
https://www.ietf.org/rfcdiff?url1=3Drfc4423&url2=3Ddraft-ietf-hip-rfc4423-=
bis-18).
>> It=E2=80=99s still HIP but with a slightly expanded scope; it=E2=80=99s=
 still Informational.
>> 1. s4: The one place where I=E2=80=99ll 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?
>=20
> 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:
>=20
> "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."
>=20
> 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?
>=20
> I think the draft should discuss IPv4 compatibility because it is part =
of architecture design.
>=20
> Btw, do you mean this paragraph or something else?
>=20
>   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.
>=20
> 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:
>=20
> 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.
>=20
> 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=E2=80=99t an additional drawback the need to have a =
HIP-aware firewall?
>=20
> Good point. It's both a benefit and drawback from the viewpoint of =
firewalls. s11.1 mentions:
>=20
>      [...] 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.
>=20
> As a drawback, I could add something like this to s11.2:
>=20
> 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].
>=20
> How does this sound?

wfm

Cheers,

spt