> On 25 Mar 2019, at 19:23, Hubert Kario <hka...@redhat.com> wrote: > > On Monday, 25 March 2019 14:58:29 CET Yoav Nir wrote: >> Yeah, so this looks very much like the IKE mechanism (the draft even says >> so) >> >> In IKE the reason for this is to detect NAT because IPsec does not traverse >> NAT. We need to detect the NAT so as to choose an IPsec variant that >> traverses NAT. If the server (or IKE Responder) lies, you might use the >> NAT Traversing method when it’s not required, or if the server is really >> good at lying, you might not use NAT Traversal when you should. >> >> With the proposed TLS extension, I would like to see a better analysis for >> what happens if the server lies. What happens if the client uses the >> answer to do geolocation? We can easily take this to a “gay kid in Uganda” >> scenario. >> >> But I think the more interesting question is why do it at this layer? Why >> not use some web service such as the API version of >> https://www.whatismyip.com <https://www.whatismyip.com/> >> <https://www.whatismyip.com/ <https://www.whatismyip.com/>> ? The answer is >> a >> property of the device, not to the socket. We might as well have the >> device figure this out. > > how is it property of device? at best, it's a property of a LAN. And a LAN > may > have multiple Internet uplinks, every other connection may end up with a > different IP (albeit from a small pool), so a public IP of any particular > connection does not reliably indicate public IP of subsequent connections.
It’s perhaps a property of the device at the current connection configuration. Pretty much any consumer device will have a preferred network where the default route is. Any phone with a metered and a non-metered connection will prefer the non-metered connection, and PCs will use the link where the default route is. It is a reasonable approximation to assume that the web service connection to whatismyip will follow the same path as your other TLS connection. Servers may have more complicated routing tables, where the “regular” TLS connection might be using a dedicated link while the connection to whatismyip is going to the “Internet”. I don’t think this is the scenario that this draft is working on. An interesting twist even for consumer devices may be where one of the two connections chooses IPv4 while the other chooses IPv6. In that case, they might end up on different links if, for example, the metered connection offers IPv6 while the non-metered connection does not, or vice versa. Yoav
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
