Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

[David Mazieres <[e-mail]>]

Eric Rescorla <[e-mail]> writes:

>> > As you say elsewhere, this is common in cases of NAT penetration and
>> > generally in NAT penetration cases you don't know your IP address
>> > with certainty. For instance, say we have two devices with apparent
>> > addresses:
>> >
>> > A: 10.0.0.1 (host),  198.51.100.1 (srflx)
>> > B: 10.0.0.2 (host),  192.0.2.1 (srflx).
>> >
>> > Which one has the lower IP address?
>>
>> Well, assuming the RFC5737 addresses are publicly routable, obviously B
>> has a lower IP address.
>>
>
> OK, that was what I was expecting you to say, but unfortunately the
> situation
> isn't always so simple. Consider what happens from A's perspective if
> he is doing trickle ICE and assume for simplicity that B is non-NATed so
> he just has the 192.0.2.1 address.

I'm afraid I'm having a hard time following your example.  I didn't
state it, but I was assuming that the RFC1918 addresses were private.
What does it mean to say B is non-NATted in the above diagram?  Are you
saying that you agree with my analysis of the previous diagram and are
now introducing a new example in a different format, or is your point
that there's some sort of "gotcha" with the previous diagram?

> A        Signaling        B        STUN
>
> STUN Check ------------------------->
> Host Cand ---->
>               Host Cand -->
>               <-- Candidate
> <--- Candidate
> SYN -------------------------------->   X
> <---------------------- STUN Response
>
> At the point when A sends his first SYN (labelled X) he knows his host
> address
> (10.0.0.2) and B's srflx (192.0.2.1) so he thinks his address is lower.
> However,
> after he gets the STUN response from the server, he learns his srflx and
> that it's higher than B's (note: in ICE you do only one check from both
> the srflx and the host candidates).

I previously gave three scenarios where tie-breaking works, and said
that the IP-address-based technique works when "The applications use
STUN to learn their public IP address and NAT type and communicate this
to the other node or register it with a public rendezvous service."
That doesn't seem to be what is happening in your diagram.

> There may be some way to resolve this, but it's not clear to me that in
> general
> it will be possible, and it's not clear to me in any case how the "b" bit
> helps.

If you remove the b bit from TCP-ENO, there will be pairs of hosts that
can communicate via simultaneously opened TCP connections that cannot
use TCP-level encryption.  The goal of the b bit is to ensure that, with
appropriate application involvement, it is always possible for
applications to use encryption where they can communicate.  The goal is
*not* to guarantee that this will happen transparently.

I haven't seen anyone argue that the b bit fails to achieve its goal.
Rather, some people seem to be arguing that this is the wrong goal, that
in fact TCP-ENO should work with unmodified applications in simultaneous
open.  In fact, there are four reasonable goals the WG could shoot for:

 1. Simultaneous open never gets encryption (but still works).

 2. Simultaneous open gets encryption only if modified applications
    indicate their intention to use simultaneous open AND do the work of
    breaking the tie (this is the current TCP-ENO position).

 3. Simultaneous open gets encryption only if modified applications
    indicate their intention to use simultaneous open (this it the
    current TCP-use-TLS position).

 4. Simultaneous open gets encryption with unmodified applications.

My current (not very strong) position is #2.  Given that you wrote
TCP-use-TLS, I assume your position is #3.  Frankly, there's very little
difference between those two positions.  The distinction is also
orthogonal to everything else in our drafts.  TCP-use-TLS could easily
be modified to have a "b" bit, while TCP-ENO could easily just adopt
TCP-use-TLS's tie-breaker mechanism.  I'd be happy to adopt position #3
if a clear working group consensus formed around that goal.  Switching
between #2 and #3 would require relatively minor changes to either
draft, so uncertainty around the goal shouldn't be a reason to delay
adoption of a draft.

That said, I'd be far more concerned with #4 for either TCP-ENO or
TCP-use-TLS.  It's not that we can't achieve goal #4 if the working
group expresses a strong preference for it.  It's just that doing so
will inflict carnage on both of our drafts in the form of increased
option space usage for non-simultaneous open and/or complex, rarely-used
code paths in implementations (such as extra timers not linked to
sequence numbers, etc.).

So before we embrace goal #4, it would be nice to get a bit more data
about how simultaneous open is used in practice.  In particular, if
people are working from a mental model like:

    A->B: SYN
    B->A: SYN
    A->B: ACK
    B->A: ACK

Then that may be too simplistic.  On the open Internet, unless you are
very lucky with timing, two concurrent connects would actually look like
this:

    A->B: SYN
    B->A: RST
    B->A: SYN
    A->B: RST

So that's not good.  Of course, you don't need simultaneous open on the
open Internet; you only need it with a NAT at both ends.  So the actual
picture in practice looks more like the following:

    A->B: SYN   [A's NAT opens port, B's NAT drops packet]
    B->A: SYN
    A->B: ACK   (or does A retransmit its SYN?)
    B->A: ACK

In fact, in this situation, I'm not sure any of the drafts work, unless
A retransmits the SYN.  But if it retransmits the SYN after receiving
the other side's SYN, maybe that could be used to break the tie.  And if
it doesn't retransmit the SYN, does B fail to learn A's tie-breaker?

In short, *if* the working group decides to target goal #4, someone
needs to go out and do the work of characterizing actual uses of
simultaneous open with actual middleboxes.  Regardless of which draft
the WG adopts, we shouldn't waste 6 bytes of option space and/or
hundreds of lines of implementation code on something we don't know is
necessary and don't even know for sure will work.

Since TCPINC has been around for over a year and neither of the two main
candidate drafts has yet attempted goal #4, perhaps we should say that
fully-transparent encryption with simultaneous open is not a high enough
priority to delay TCPINC progress.  If some subdelegation wants to
investigate the problem in parallel and report back with some data,
there's no reason the WG couldn't later move to accommodate the results.

David