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

From: Sean Turner <[email-masked]>
Date: Tue, 27 Feb 2018 07:06:51 -0800

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?

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?

3. s11.2: Isn’t an additional drawback the need to have a HIP-aware firewall?

---

From: Miika Komu <[email-masked]>
Date: Wed, 28 Feb 2018 17:34:02 +0200

Hi Sean,

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

> necessary?  I.e., is this yet another thing that folks are going to use to not

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?