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

[Miika Komu <[e-mail]>]

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 encoding following
RFC7401 conventions that allows the IPsec kernel module to pass the
non-ESP packets to userspace (i.e. to HIP userspace dameon). ESP
packets do *not* need any diversion.

In the legacy HIP NAT traversal (RFC5770), we have third protocol
(STUN) on the same port and it does not follow RFC7401 conventions
because it was not designed with IPsec in mind. As a result, *all*
packets need to be diverted to an userland daemon in order to separate
the STUN packets from HIP/ESP. All packets means also the data
plane,i.e., ESP data packets...

I spent half a day to find legacy HIP ICE measurements from around 20
master theses and publications. Unfortunately, I did not find exact
match but I would argue that the so called LSI translation has a
similar overhead as parsing the STUN packets. Based on the peer reviwed
publication below, dealing with STUN (or LSI) with userspace daemon and
iptables-queue target has roughly 40 % performance penalty on latency
and 12 % penalty on throughput (with TCP traffic). So the impact on
latency is IMHO unacceptable.

Lirim Osmani, Salman Toor, Miika Komu, Matti J. Kortelainen, Tomas
Lindén, John White,
Rasib Khan, Paula Eerola, Sasu Tarkoma, "Secure Cloud Connectivity for
Scientific Applications",
special issue on Cloud Services Meet Big Data of the IEEE Transactions
on Services Computing, 2015

> >  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.

The extra TURN framing means that there will be extra context switching
at the endpoints because it needs to be handled in the userspace
(=additional latency, lower bandwidth, smaller MTU).

With an ESP relay (as specified in native NAT traversal) you don't need
any framing at all and all the ESP processing can be done as if no
relay was used.

> >  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.

surely, the corner cases are documented in the ICE specification for
new ICE implementations.

> 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.

The technical points are:
1. Using ICE-as-is reduces performance considerably for IPsec keying
protocols
2. TURN infra can still be reused

> 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.

Thanks and looking forward for further comments for you. Please accept
my since apologies for the long delays because I am working on other
things nowadays, and HIP is more of a hobby :)

> =====================================================================
> ======
> 
> 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"

thanks, fixed.

> -------------------------------------------------------------------
> --------
> 
> §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.

done.

> -------------------------------------------------------------------
> --------
> 
> §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.

I believe it's convenient to define the values here for developers.

> -------------------------------------------------------------------
> --------
> 
> 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.

This was already changed during the IESG reviews and now it states:

Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP protocol
but rather encrypted to avoid middlebox tampering.