> On 25 Mar 2019, at 19:38, Hubert Kario <hka...@redhat.com> wrote: > > On Monday, 25 March 2019 19:31:24 CET Yoav Nir wrote: >>> 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/> >>>> <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. > > I already gave you an example of situation where that's not the case. > > You can have a router with two Internet links that routes the connections to > a > different ISP either based on a round-robin fashion or as a fallback when a > connection dies. > > Neither of which would be visible to the device connected to a WiFi behind > such a router. The client in the context of this I-D.
True. As far as NAT detection, the answer would be the same — such a client is behind NAT regardless of which Internet link the router chooses, so keepalives are necessary anyway. For the other use cases, I’m not so sure. If a client has two “real” IP addresses, what is it supposed to do about identifying ASNs? Deciding whether to reuse connections to DNS is directly related to the presence of a NAT, so it’s the same as NAT detection.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
