Eric Rescorla <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
