Hi Adam,
ke, 2018-05-09 kello 22:43 -0700, Adam Roach kirjoitti:
> 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.
nothing prevents from using TURN relays with the native NAT traversal
mode as only the host using TURN relay needs to implement TURN.
> 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.
I think the justification is only related to IPsec keying daemons,
please see below.
> 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.
the protocol that we specify in the document implements only a subset
of ICE and there I belive it should be relatively straighforward to
interop it.
ICE has not been designed with IPsec in mind (see my comments below),
so something else is needed.
> 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?
the userspace diversion is completely unnecessary in the native NAT
traversal draft. HIP control packets have a special
