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

[Sean Turner <[e-mail]>]

> On Feb 28, 2018, at 10:34, Miika Komu <[e-mail]> 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