Hi Joel,
thanks for the nice review! My suggested changes for HIP architecture
document are below (in "diff" format).
On 02/18/2018 07:33 AM, Joel Halpern wrote:
Reviewer: Joel Halpern
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-hip-rfc4423-bis-18
Reviewer: Joel Halpern
Review Date: 2018-02-17
IETF LC End Date: 2018-02-26
IESG Telechat date: Not scheduled for a telechat
Summary: This document is ready for publication as an Informational RFCs.
The following comments may be useful for the authors to consider.
Major issues: N/A
Minor issues:
In the table in section 2.2 (Terms specific to this and other HIP
documents) the Host Identity Hash is defined as "The cryptographic hash
used in creating the Host Identity Tag from the Host Identity." I am
pretty sure the last word should be Identifier, not Identity,, which
matches the meanings and the usage in the following term.
agreed. Suggested change:
Host Identity Hash The cryptographic hash used
- in creating the Host Identity Tag from the Host Identity.
+ in creating the Host Identity Tag from the Host Identifier.
(I will move the definition of Host Identifier earlier so that the
terms appear in chronological order)
In section 4.1 second paragraph, it seems odd to refer to the
public-private key pair as the structure of the abstract Host Identity.
Given that the earlier text refers to the Public key as the Host
Identifier, I am not sure how you want to refer to the public/private key
pair. But I do not think it "is" the structure of the Host Identity.
Agree. Suggested rephrasing:
- The only completely defined structure of the Host Identity
- is that of a public/private key pair. In this case, the Host
- Identity is referred to by its public component, the public
+ An identity is based on public-private key cryptography in HIP.
+ The Host Identity is referred to by its public component, the
public
key.
In the section 4.4 discussion of locally scoped identifier (LSI), it
appears that applications need to be modified to use this. Reading between
the lines of the stack architecture, the actual advantage of using HIP with
LSIs is that the application changes can be restricted to whatever
indication is to be used that the stack is to use HIP, rather than changing
the places that use sockaddrs, etc. But this is not clearly stated here.
yes, you are correct. I would suggest the following changes to make this
more clear:
A Host Identity Tag is a 128-bit representation for a Host
- Identity. It is created from an HIH,
- an IPv6 prefix [RFC7343] and a hash identifier.
+ Identity. Due to its size, it is suitable to be used in the
existing sockets API in
+ the place of IPv6 addresses (e.g. in sockaddr_in6 structure,
sin6_addr member) without modifying applications.
+ It is created from an HIH, an IPv6 prefix [RFC7343]
+ and a hash identifier.
...and the following:
An LSI is a 32-bit localized representation for a Host
- Identity. The purpose of an LSI is to facilitate using Host
+ Identity. Due to its size, it is suitable to be used in the
existing sockets API in
+ the place of IPv4 addresses (e.g. in sockaddr_in structure,
sin_addr member) without modifying applications.
+ The purpose of an LSI is to facilitate using Host
Identities in existing APIs for IPv4-based
- applications. Besides facilitating HIP-based connectivity for
+ applications.
+ LSIs are never transmitted on the wire; when an application
+ sends data using a pair of LSIs, the HIP layer (or sockets
+ handler) translates the LSIs to the corresponding HITs, and
+ vice versa for receiving of data.
+ Besides facilitating HIP-based connectivity for
legacy IPv4 applications, the LSIs are beneficial in two other
scenarios [RFC6538].
@@ -712,6 +721,14 @@
to facilitate backward compatibility with existing networking
APIs and stacks.</t>
In section 5.1 paragraph 3, the text talks about a connecting client not
specifying a responder identifier (HIP Opportunistic mode) in order to
enable load balancing. I think the text would be helped by an example of
how an initiator might know to do this, rather than just not using HIP.
Also, it would be good if the text was explicit as to whether or not there
was a way to support load balancing / multi servers without either using a
shared identity or sacrificing security by using Opportunistic HIP.
agreed, the description of this was quite short. Would the following
clarify your concerns?
+ At the server side, utilizing DNS is a better alternative than a
+ shared Host Identity to implement load balancing. A single FQDN
entry can be configured
+ to refer to multiple Host Identities. Each of the FQDN entries
+ can be associated with the related locators, or a single
+ shared locator in the case the servers are using the same HIP
rendezvous server
+ or HIP relay server.
+
Instead of duplicating identities, HIP opportunistic mode
can be employed, where the initiator leaves out the identifier
of the responder when initiating the key exchange and learns
@@ -731,14 +766,21 @@
it upon the completion of the exchange. The tradeoffs are
related to lowered security guarantees, but a benefit of the
approach is to avoid publishing of Host Identifiers in any
- directories [komu-leap]. The approach could also be used
- for load balancing purposes at the HIP layer because the
- identity of the responder can be decided dynamically during
- the key exchange. Thus, the approach has
- the potential to be used as a HIP-layer "anycast", either
- directly between two hosts or indirectly through the
- rendezvous service [komu-diss].
+ directories [komu-leap]. Since many public
+ servers already employ DNS as their directory, opportunistic mode
+ may be more suitable for, e.g, peer-to-peer connectivity.
+ HIP opportunistic mode could be utilized in association
+ with HIP rendezvous servers or HIP relay servers
+ [komu-diss]. In such a scenario, the Initiator sends
+ an I1 message with a wildcard destination HIT to the locator of a HIP
+ rendezvous/relay server. When the receiving rendezvous/relay server is
+ serving multiple registered Responders, the server can choose
+ the ultimate destination HIT, thus acting as a HIP based load
+ balancer. However, this approach is still experimental and
+ requires further investigation.
+
(I can also remove the last paragraph if it is still unclear)
Given that section 5 is titled "New Stack Architecture", I think it would
be helpful if the section were explicit as to where the HIP logic lives
relative to the IP and UDP/TCP portions of the host stack. This would help
the reader have the right model for interpreting section 6.2 and 8.1.
I would suggest to add a new paragraph in the end of the section to
clarify this:
+ HIP layer is logically located at layer 3.5, between the
+ transport and network layers, in the networking stack. It acts
+ as shim layer for transport data utilizing LSIs or HITs, but
+ leaves other data intact. HIP layer translates between the two
+ forms of HIP identifiers originating from the transport layer
+ into routable IPv4/IPv6 addresses for the network layer, and
+ vice versa for the reverse direction.
Nits/editorial comments:
Section 4.2 third sentence "It is possible to for ..." should be "It is
possible for ..."
Good catch, will fix this too.
Joel, should I go ahead and submit a new version (bis-19) of the document?
