Skip to main content

Telechat Review of draft-ietf-hip-rfc4423-bis-19
review-ietf-hip-rfc4423-bis-19-rtgdir-telechat-frost-2018-03-05-00

Request Review of draft-ietf-hip-rfc4423-bis
Requested revision No specific revision (document currently at 20)
Type Telechat Review
Team Routing Area Directorate (rtgdir)
Deadline 2018-03-05
Requested 2018-02-12
Requested by Alvaro Retana
Authors Robert Moskowitz , Miika Komu
I-D last updated 2018-03-05
Completed reviews Rtgdir Telechat review of -19 by Dan Frost (diff)
Opsdir Last Call review of -19 by Will (Shucheng) LIU (diff)
Genart Last Call review of -18 by Joel M. Halpern (diff)
Secdir Last Call review of -19 by Sean Turner (diff)
Genart Telechat review of -19 by Joel M. Halpern (diff)
Assignment Reviewer Dan Frost
State Completed
Request Telechat review on draft-ietf-hip-rfc4423-bis by Routing Area Directorate Assigned
Reviewed revision 19 (document currently at 20)
Result Has issues
Completed 2018-03-05
review-ietf-hip-rfc4423-bis-19-rtgdir-telechat-frost-2018-03-05-00
Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
‚Äčhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-hip-rfc4423-bis-19
Reviewer: Dan Frost
Review Date: 2017-03-05
Intended Status: Informational

Summary:

I have some minor concerns about this document that I think should be resolved
before publication.

Comments:

This document describes an overall architecture for a proposed "Host Identity"
layer that fits in to the Internet protocol stack between the network and
transport layers. The architecture involves adding a layer of indirection
between the IP and transport layers that allocates globally-significant host
identifiers in the form of cryptographic public keys, and manages
network-layer-independent associations between hosts. This draft is a revision
of RFC 4423, which was originally published in 2006, so the basic architecture
has been around for some time, and seen some limited deployment experience.

The document itself is clearly written, and thorough in addressing the many
issues and concerns raised by such a proposal without being verbose.

There's a lot of valuable protocol design and deployment experience packed into
this architecture and the associated protocol RFCs. At the same time, actual
adoption and deployment of HIP so far appears to have been scarce. I don't find
this surprising. The existing Internet network/transport/application protocol
stack has already become sufficiently complicated that considerable expertise
is required to manage it in all but the simplest of cases. Teams of skilled
engineers routinely spend hours or days troubleshooting operational problems
that crop up within or between the existing layers, and the collection of
extensions, workarounds, identifiers, knobs, and failure cases continues to
grow. Adding a major new layer--and a fairly complicated one at that--right in
the middle of the existing stack seems likely to explode the already
heavily-strained operational complexity budget of production deployments.

Major Issues:

No major issues found.

Minor Issues:

- Section 1

It would be good to clarify early in this section that the Host Identity
namespace is global.

- Section 1, paragraph 4, last sentence

Some grammar problems here.

- Section 3, last paragraph

This paragraph says "Firstly, dynamic readdressing cannot be directly managed."
It's not entirely obvious what this refers to; some elaboration or a reference
would be helpful.

- Sections 5 and 10

These sections contain some discussion of opportunistic mode. The draft would
benefit from some expanded coverage of this subject, such as whether and how a
TOFU approach is expected to apply, and a comparison against the considerations
raised in RFC 7435.

- Infrastructure devices

The draft does not discuss the applicability of HIP to infrastructure devices.
These devices are also hosts, and it's a little surprising that they're never
mentioned as possible HIP users.

- End user experience

I didn't see a discussion of how the experience of an end user using a
HIP-enabled application would differ as compared to the status quo. Is HIP
expected to be completely transparent to end users? Do they need to understand
the significance of public keys? What new kinds of errors might they have to
deal with? Impact to end user usability seems like an important topic for the
architecture to address.

Thanks,
-d