> On Feb 28, 2018, at 10:34, Miika Komu <miika.komu@xxxxxxxxxxxx> 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
