[Hipsec] Adam Roach's Abstain on draft-ietf-hip-native-nat-traversal-28: (with COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-hip-native-nat-traversal-28: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I share Ben's concerns about the disjointedness of this document's
specification, and am likewise abstaining. My reasons for abstaining are
deeper than Ben's, however.

I recognize that the effort put into this document is substantial, and that
the recommendations I make are unlikely to be taken at this point in time,
but I believe that the HIP ecosystem would be far better served by an "RFC
5570 bis" approach rather than a modified form of ICE recast using HIP
messages. Among other reasons: several companies already offer
geographically-distributed hosted TURN solutions, largely due to the relative
popularity of WebRTC. HIP will have to reach a similar level of popularity
before HIP-specific relay nodes are similarly commercially available.  Using
ICE as-is would allow HIP to use those services that are available today.

As a further concern, I worry that this pattern may end up replicated in other
protocols. For example, although ICE was initially developed with RTP/RTCP in
mind, it was not implemented as a series of extensions to RTP or RTCP;
instead, it is its own protocol, intended to be re-used in other contexts. I
would not like to see, e.g., ICE-like extensions to the QUIC protocol to enable
its use in peer-to-peer situations; I would certainly hope that such an effort
would use ICE as currently defined.

Given that the headline rationale offered in this document is that
"Implementing a full ICE/STUN/TURN protocol stack as specified in Legacy
ICE-HIP results in a considerable amount of effort and code which could be
avoided by re-using and extending HIP messages and state machines for the same
purpose," this document puts forth an implication that all protocols could
benefit from similar not-quite-ICE-but-almost-ICE extensions. I believe
this implication is harmful. I also believe this analysis overlooks the
availability of multiple existing, open-source, already-debugged, and
"compatible with commercial use" ICE implementations.

It is not clear that the four additional reasons offered in Appendix B are
sufficient to justify the design. Taken in turn:

>  For example, ICE is meant for application-layer protocols, whereas HIP
>  operates at layer 3.5 between transport and network layers.

This doesn't have practical effect: ICE is designed to work with generic UDP
packet flows, subject only to the ability to demultiplex STUN from such
packets.

>  This is particularly problematic because the implementations employ IPsec
>  ESP as their data plane: demultiplexing of incoming ESP, HIP and TURN
>  messages required capturing of all UDP packets destined to port 10500 to
>  the userspace, thus causing additional software complexity and an
>  unnecessary latency/throughput bottleneck for the dataplane performance.

This doesn't seem like a foregone consequence. If you're using user-space HIP
implementations, this user-space diversion is already necessary. If you're
using kernel-space HIP implementations, it seems a modest step to add minimal
STUN demultiplexing to the kernel implementation that is already performing
ESP/HIP demultiplexing.  It's possible that I'm misunderstanding some subtle
aspect of the way these protocols interact with each other, but isn't this
described performance impact simply the result of specific implementation
design decisions rather than inherent to the design of RFC 5570's mechanism?

>  Also, relaying of ESP packets via TURN relays was not
>  considered that simple because TURN relays require adding and
>  removing extra TURN framing for the relayed packets.

While it's been a while since I've looked at network kernel code, my
recollection is that implementation of the POSIX "sendmsg()" system call
generally maintains scatter/gather buffers all the way down the stack until
such bytes are copied from system memory to the network hardware. Stripping
such headers on receipt can be accomplished with simple pointer arithmetic.
It's not clear what aspect of the system "simple" is intended to refer to, but
both implementation and performance impacts should be immeasurably small when
implemented in this way, unless I'm missing something.

>  Finally, the developers of the two Legacy ICE-HIP implementations concluded
>  that "effort needed for integrating an ICE library into a HIP
>  implementation turned out to be quite a bit higher that initially
>  estimated.  Also, the amount of extra code (some 10 kLoC) needed for all
>  the new parsers, state machines, etc., is quite high and by re-using the
>  HIP code one should be able to do with much less.  This should result in
>  smaller binary size, less bugs, and easier debugging.".

Such size is not inherent in the implementation of ICE: for example, the ICE
stack used by Firefox is 2.2 kLoC in size (if you ignore the ~1.2 kLoC of
boilerplate copyright notice). Having seen the debugging of an ICE stack
up-close-and-personal, I'm pretty comfortable saying that the effort to
integrate a working stack has to be orders of magnitude less than implementing
even the simplified ICE procedures defined in this document correctly. There
are a lot of surprising corner cases that don't really turn up until you get
into production.

For the foregoing reasons, it is my conclusion that publication of this
document is harmful for HIP and is harmful as a precedent that other protocols
may mistakenly emulate. I believe that a restructuring of the document to more
clearly explain why HIP chose this path while other protocols should not would
limit some of these concerns. However, I do not believe that the fundamental
flaw -- a partial respecification of ICE for the cited reasons --  can be
fixed. I do not support publication of a document describing this mechanism,
and encourage the working group to withdraw the document from consideration
for publication.

To be clear: despite the length and detail of my preceding objections, I
recognize that I may be off in the weeds. I am happy to be corrected about
any of the assertions I make above, up to and including corrections that make my
conclusion incorrect. I will further note that this is not a blocking ballot
position, and that, procedurally, the document can be published despite my
misgivings.

===========================================================================

I have included some additional comments below.

---------------------------------------------------------------------------

§1:

>  As one solution, the HIP experiment report [RFC6538] mentions that
>  Teredo based NAT traversal for HIP and related ESP traffic (with
>  double tunneling overhead).

This isn't a sentence. Perhaps remove "that"?

Also: "Teredo-based"

---------------------------------------------------------------------------

§4.6:

>  The connectivity checks follow the ICE methodology [MMUSIC-ICE], but
>  UDP encapsulated HIP control messages are used instead of ICE
>  messages.  Only normal nomination MUST be used for the connectivity
>  checks, i.e., aggressive nomination MUST NOT be employed.

The cited document does not describe aggressive nomination, and deprecates its
use. Consider removing the mention of aggressive nomination in this document.

---------------------------------------------------------------------------

§5.4:

>    The following NAT traversal mode IDs are defined:
>
>        ID name            Value
>        RESERVED             0
>        UDP-ENCAPSULATION    1
>        ICE-STUN-UDP         2
>        ICE-HIP-UDP          3

This should probably point to the IANA table rather than replicating a snapshot
of its contents.

---------------------------------------------------------------------------

Appendix B:

>  o  Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP
>     protocol in order to avoid middlebox tampering.

This bullet should explain why such obfuscation is unnecessary.