On Wed, Aug 26, 2015 at 7:07 AM, David Mazieres < [email protected]> wrote:
> Eric Rescorla <[email protected]> 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? I believe that the previous diagram actually has this problem as well but I realized in the meantime that you didn't need B to be NATted to produce the problem, so I decided to simplify. Sorry about the confusion. > > 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. This is the first class: you learn your public IP and communicate it to the other node via a rendezvous service. In fact, it's the "trickle" variant of ICE, which is what WebRTC uses. 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. > > > 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. 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 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. > 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. Yes, but it's not a very strong position. 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 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. 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. 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. -Ekr
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
