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

Hi David,

I believe the point is, if you have already broken the tie via out-of-band signal and both endpoints have already decided who will be the opener (host A) and responder (host B), why do you still need to write this information in the tcp-eno option if this information is already known to the host?

Mirja

> Am 27.08.2015 um 07:28 schrieb David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>:
> 
> Eric Rescorla <ekr@rtfm.com> writes:
> 
>> Note: you can't really build a reliable NAT traversal system where you
>> use STUN to learn your public address and then register it because
>> too many NATs have unstable bindings or require you to open pinholes.
>> We tried that and it didn't work which is why ICE is the way it is.
> 
> Can you demonstrate simultaneous open without stable NAT bindings?  I
> don't see how that could work.  But if it can, then a simplified packet
> trace would be super helpful to this discussion.
> 
>>> 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.
>> 
>> OK, I don't understand that. Can you please provide an example of a case
>> where the "b" bit helps that the sides couldn't have already broken the
>> tie via out-of-band signaling.
> 
> I'm not sure I understand your comment.  The "b" bit assumes the
> applications have broken the tie via out-of-band signaling.  It is the
> mechanism that permits you to have encryption when applications break
> the tie.  So no "b" bit means no encryption on simultaneous open, ever.
> 
>> I haven't seen anyone argue that the b bit fails to achieve its goal.
>> 
>> That's precisely what I am arguing with the example above.
> 
> So to be clear, the goal is that if applications can break the tie, the
> "b" bit allows encryption with simultaneous open.  If you believe
> there's a case where simultaneous open will still fail to encrypt, even
> with the "b" bits correctly set, can you break it down on a
> packet-by-packet basis (for the first 4 packets of the connection)?
> Such a four-segment example with two SYNs and two ACKs would really
> advance the debate.
> 
>> I agree with this as well and I agree that #2 is a viable position. The open
>> issue for me is whether the "b" bit actually accomplishes that goal.
> 
> Well, it looks like this:
> 
>    A -> B:  SYN ENO<b=0>
>    B -> A:  SYN ENO<b=1>
>    A -> B:  ACK
>    B -> A:  ACK
> 
> You might argue that applications won't break the tie properly, but I
> don't see why you think the "b" bit wouldn't work if they do.
> 
>>> 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.
>> 
>> This seems like a good proposal. FWIW, the major applications that I know of
>> that use TCP-SO for NAT traversal have their own COMSEC anyway and
>> in fact often treat TCP as if it were UDP.
> 
> Ah... great.  Sounds like progress.  Also, do you mind sharing what
> those major TCP-SO applications are?  It would add some badly needed
> context to this discussion.
> 
> Thanks,
> David
> 
> _______________________________________________
> Tcpinc mailing list
> Tcpinc@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpinc