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?
