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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux