Re: Migration privacy and NAT rebinding

[Martin Thomson <[e-mail]>]

I don't know how realistic DKG's scenario is.  Most of these systems
aim to provide continuity of addressing because to do otherwise makes
the most common applications break all the time.  That means hiding
the consequences of handovers in the network, likely at great expense.

On Thu, Apr 12, 2018 at 4:34 AM, Christian Huitema <[e-mail]> wrote:
> On 4/11/2018 10:31 AM, Spencer Dawkins at IETF wrote:
>
>> The thing I've wondered most about from threads in this space, is the
>> discussion about preventing linkages due to address changes as a
>> result of NAT rebinding, and what the concerns are, and how bad
>> linking after NAT rebinding would be, or would not be.
>
> That's a good question, and it probably deserves its own thread.
>
> I think we need to consider two kinds of migration: voluntary migration,
> and NAT rebinding. I really want to support privacy for voluntary
> migration. I doubt than we can do better than a best effort for NAT
> rebinding.
>
> An example of voluntary migration is the parking lot scenario, in which
> the client will voluntarily migrate the connection from WiFi to cellular
> as the WiFi signal fades away. The migration is voluntary, as the client
> will actively decide to send packets from a different source address,
> and possibly from a different source port. Involuntary migration happens
> when something change in the network without the client's knowledge, and
> packet start arriving to the server from a different IP and port. The
> canonical example of that is NAT rebinding.
>
> There is no question in my mind that we want to prevent linkability when
> doing voluntary migration, and that means rotating the connection ID and
> breaking PN linkability. But NAT rebinding is another matter. There are
> many big arguments against expanding too much resource to specifically
> increase NAT rebinding privacy:
>
> * Most NAT rebinding happens without the client's knowledge, which
> seriously limit mitigation capability.
>
> * If the connection was using IPv6 instead of IPv4, in theory there
> would be no NAT.
>
> * In the case of residential NAT, only the port changes upon rebinding,
> so linkability is obvious.
>
> * If there is just a short interval between the old and new NAT
> bindings, adversaries can use time based solutions to link the two
> connection.
>
> The proposal in the document is that clients may simulate a voluntary
> migration when going out of quiescence. This seems like a reasonable
> best effort approach. Most NAT rebinding occurs after connections have
> been idle for some time. Since there is a long interval, adversaries
> have a harder time using time stamps for linkability. In case of long
> intervals, carrier grade NAT may have recycled both the address and the
> port. And we need to grease the migration code path in servers and
> clients, so we can just as well do that.
>
> DKG pointed out that NAT rebinding also happens in mobile platforms,
> such as a car roaming between various cells. The car network offers a
> router + NAT service to devices inside the car. The router would be
> getting a new IPv4 address at each new cell, and there would be
> rebinding of any connection between internal devices and outside
> servers. If the QUIC connection survived, the adversaries will be able
> to deduce from traffic observation the successive locations of the
> device. This seems bad. If internal devices new about the connection
> changes, they could use the voluntary mechanisms. DKG argued that we
> should have protection even if the devices don't know about the
> migration, but the only practical solution is to rotate the connection
> ID for every packet -- effectively, encrypt the connection ID. This is
> not what we are debating now. I personally think that the mobile
> platform issue should be solved with some cooperation of the mobile
> router, so the devices can engage in voluntary migration.
>
> -- Christian Huitema
>
>