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 rev. 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
Other Reviews Opsdir Last Call review of -19 by Will LIU (diff)
Genart Last Call review of -18 by Joel Halpern (diff)
Secdir Last Call review of -19 by Sean Turner (diff)
Genart Telechat review of -19 by Joel Halpern (diff)
Review State Completed
Reviewer Dan Frost
Review review-ietf-hip-rfc4423-bis-19-rtgdir-telechat-frost-2018-03-05
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/wNRwnOCELE2lvz4Gy_YKy-Bkz0A
Reviewed rev. 19 (document currently at 20)
Review result Has Issues
Draft last updated 2018-03-05
Review completed: 2018-03-05

Review
review-ietf-hip-rfc4423-bis-19-rtgdir-telechat-frost-2018-03-05

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