These changes very nicely address my concerns.b You should check with
your chair,and AD before submitting a,revision.
Thank you,
Joel
Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone
-------- Original message --------
From: Miika Komu <miika.komu@xxxxxxxxxxxx>
Date: 2/26/18 06:56 (GMT-05:00)
To: Joel Halpern <jmh@xxxxxxxxxxxxxxx>, gen-art@xxxxxxxx
Cc: draft-ietf-hip-rfc4423-bis.all@xxxxxxxx, hipsec@xxxxxxxx, ietf@xxxxxxxx
Subject: Re: Genart last call review of draft-ietf-hip-rfc4423-bis-18
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?
