Subject: New path => new connection ID, right?

From: Martin Thomson <[email-masked]>
Date: Tue, 05 Feb 2019 10:15:13 +1100

I thought that we had agreed that an endpoint that intentionally migrates has to use a new connection ID on the new path.  But I couldn't find any "MUST" in the spec that said that.

On the off chance that this wasn't just a mistake and there was some good reason not to mandate this, I'm bringing the discussion here.

I've opened a design issue:
https://github.com/quicwg/base-drafts/issues/2413

The change I'm proposing is here:
https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a3995236dda960b4cdff49e36f

---

From: Mike Bishop <[email-masked]>
Date: Tue, 5 Feb 2019 00:56:16 +0000

The text is there, but it's perhaps not complete:

As discussed in Section 9.5, each connection ID MUST be used on packets sent from only one local address. An endpoint that migrates away from a local address SHOULD retire all connection IDs used on that address once it no longer plans to use that address.

The gap seems to be that when your peer moves to a new address, there’s no requirement that you not send the same CID to their new address that you used toward their old address.

---

From: David Schinazi <[email-masked]>
Date: Mon, 4 Feb 2019 17:08:09 -0800

If an endpoint intentionally migrates and it has unused connection IDs to
use, it makes sense to mandate it MUST switch to one of the unused
connection IDs.
However, if it has run out of unused connection IDs then I would let the
endpoint decide if it wants to close the connection or migrate with a
previously used connection IDs, as there are use-cases that value
performance over non-linkability. Finally, this cannot be enforced by the
peer since it cannot distinguish intentional migration and unintentional
migration (NAT rebinding), and we discussed in Tokyo that we wanted to
avoid non-enforceable MUSTs.

David

On Mon, Feb 4, 2019 at 4:56 PM Mike Bishop <[email-masked]> wrote:

> As discussed in Section 9.5, each connection ID MUST be used on packets
> sent from only one local address. An endpoint that migrates away from a
> local address SHOULD retire all connection IDs used on that address once it
> no longer plans to use that address.
>
>
>
> The gap seems to be that when your peer moves to a new address, there’s no
> requirement that you not send the same CID to their new address that you
> used toward their old address.
>
>
>
> I thought that we had agreed that an endpoint that intentionally migrates
> has to use a new connection ID on the new path.  But I couldn't find any
> "MUST" in the spec that said that.
>
>
>
> On the off chance that this wasn't just a mistake and there was some good
> reason not to mandate this, I'm bringing the discussion here.
>
>
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 05 Feb 2019 12:34:47 +1100

Based on the feedback from Eric K and Mike, I think that this was just a failing.  I'd rather not re-run the discussion.

This was an argument that was presented last time.  We've heard similar arguments about "not caring" about various privacy properties over time, and it's been very difficult to know who is making the "I don't care" decision.  For that reason, mandating privacy has tended to carry the day.  Given that this is a situation that should not occur, what is the problem with making a new connection?

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 5 Feb 2019 10:36:56 +0900

2019年2月5日(火) 10:08 David Schinazi <[email-masked]>:
>
> If an endpoint intentionally migrates and it has unused connection IDs to use, it makes sense to mandate it MUST switch to one of the unused connection IDs.
> However, if it has run out of unused connection IDs then I would let the endpoint decide if it wants to close the connection or migrate with a previously used connection IDs, as there are use-cases that value performance over non-linkability.

I think I might prefer encouraging endpoints to gracefully close the
connection before it faces a trade-off between performance and
linkability.

Therefore, assuming that we adopt Martin's proposal, I think it would
make sense to recommend an endpoint to send GOAWAY when if it can no
longer issue a new CID for that QUIC connection.

> Finally, this cannot be enforced by the peer since it cannot distinguish intentional migration and unintentional migration (NAT rebinding), and we discussed in Tokyo that we wanted to avoid non-enforceable MUSTs.
>
> David
>

-- 
Kazuho Oku

---

From: David Schinazi <[email-masked]>
Date: Mon, 4 Feb 2019 18:43:12 -0800

At the end of the day, you can make it a MUST, but clients will do what
they please because servers can't enforce it.
But I won't die on this hill, I can live with being declared in the rough
on this one.

David

On Mon, Feb 4, 2019 at 5:37 PM Kazuho Oku <[email-masked]> wrote:

> > If an endpoint intentionally migrates and it has unused connection IDs
> to use, it makes sense to mandate it MUST switch to one of the unused
> connection IDs.
> performance over non-linkability.
>
> > Finally, this cannot be enforced by the peer since it cannot distinguish
> intentional migration and unintentional migration (NAT rebinding), and we
> discussed in Tokyo that we wanted to avoid non-enforceable MUSTs.
> >
> > David
> >
> >> The gap seems to be that when your peer moves to a new address, there’s
> no requirement that you not send the same CID to their new address that you
> >> I thought that we had agreed that an endpoint that intentionally
> migrates has to use a new connection ID on the new path.  But I couldn't
> find any "MUST" in the spec that said that.
> >>
> >>
> >>
> >> On the off chance that this wasn't just a mistake and there was some
> good reason not to mandate this, I'm bringing the discussion here.
> >>
> >>
> >>

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 5 Feb 2019 17:11:50 +0530

I agree that want to have MUST for changing CID and MUST NOT for sending
packets with the same CID on multiple paths.  I thought we had agreed on
this in the past, but I could be misremembering.

I understand that the server cannot necessarily tell this from NAT
rebinding, but it is up to the server what it does if it sees an IP/port
change with no accompanying CID change.  Egregious changes in IP might be a
signature for network change (change in /16 address, for instance) and a
server could terminate the connection and respond with a stateless reset if
this happens.  A client that ignores the MUST and uses the same CID across
networks would then risk getting the connection terminated.  I suggest that
we add some discussion about potential server responses to clients that
violate normative expectations.

On Tue, Feb 5, 2019 at 8:13 AM David Schinazi <[email-masked]>
wrote:

>> > However, if it has run out of unused connection IDs then I would let
>> the endpoint decide if it wants to close the connection or migrate with a
>> > Finally, this cannot be enforced by the peer since it cannot
>> distinguish intentional migration and unintentional migration (NAT
>> rebinding), and we discussed in Tokyo that we wanted to avoid
>> non-enforceable MUSTs.
>> >
>> > David
>> >
>> >> As discussed in Section 9.5, each connection ID MUST be used on
>> packets sent from only one local address. An endpoint that migrates away
>> from a local address SHOULD retire all connection IDs used on that address
>> once it no longer plans to use that address.
>> >>
>> >>
>> >>
>> >> The gap seems to be that when your peer moves to a new address,
>> there’s no requirement that you not send the same CID to their new address
>> that you used toward their old address.
>> >>
>> >>
>> >>

---

From: "Lubashev, Igor" <[email-masked]>
Date: Tue, 5 Feb 2019 18:26:30 +0000

*   Egregious changes in IP might be a signature for network change (change in /16 address, for instance) and a server could terminate the connection and respond with a stateless reset if this happens.

The client could be a laptop that is tethered via a phone that is changing providers.  The disconnect would be completely “punitive” (the old path’s CID has already been sent over the new path) and be punishing the client for something it had no control over whatsoever.

  *   Igor

From: Jana Iyengar <[email-masked]>
Sent: Tuesday, February 05, 2019 6:42 AM
To: David Schinazi <[email-masked]>
Cc: [email-masked]; Mike Bishop <[email-masked]>; Martin Thomson <[email-masked]>; Kazuho Oku <[email-masked]>
Subject: Re: New path => new connection ID, right?

I agree that want to have MUST for changing CID and MUST NOT for sending packets with the same CID on multiple paths.  I thought we had agreed on this in the past, but I could be misremembering.

I understand that the server cannot necessarily tell this from NAT rebinding, but it is up to the server what it does if it sees an IP/port change with no accompanying CID change.  Egregious changes in IP might be a signature for network change (change in /16 address, for instance) and a server could terminate the connection and respond with a stateless reset if this happens.  A client that ignores the MUST and uses the same CID across networks would then risk getting the connection terminated.  I suggest that we add some discussion about potential server responses to clients that violate normative expectations.

On Tue, Feb 5, 2019 at 8:13 AM David Schinazi <[email-masked]<mailto:[email-masked]>> wrote:
At the end of the day, you can make it a MUST, but clients will do what they please because servers can't enforce it.
But I won't die on this hill, I can live with being declared in the rough on this one.

David

On Mon, Feb 4, 2019 at 5:37 PM Kazuho Oku <[email-masked]<mailto:[email-masked]>> wrote:

> On Mon, Feb 4, 2019 at 4:56 PM Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> From: QUIC <[email-masked]<mailto:[email-masked]>> On Behalf Of Martin Thomson
>> To: [email-masked]<mailto:[email-masked]>
>> https://github.com/quicwg/base-drafts/issues/2413<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_quicwg_base-2Ddrafts_issues_2413&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=4B8i3O2Q6b6NfZdMIFdsB0SlrcmD50Tc24UFo4xCGiY&s=5lr8cziZfX2A9BWD3L8Zv8i1R3zyJYCizqvBjcOmuys&e=>
>>
>>
>>
>> https://github.com/quicwg/base-drafts/pull/2414/commits/13698cbe311922a3995236dda960b4cdff49e36f<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_quicwg_base-2Ddrafts_pull_2414_commits_13698cbe311922a3995236dda960b4cdff49e36f&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=4B8i3O2Q6b6NfZdMIFdsB0SlrcmD50Tc24UFo4xCGiY&s=R0-jueWgatT5WDkdYQi_JVZFacgy-cAAA4P2uost3jw&e=>
>>
>>

--
Kazuho Oku

---

From: Ted Hardie <[email-masked]>
Date: Tue, 5 Feb 2019 11:28:09 -0800

Hi Igor,

I have a clarifying question on the scenario below.

On Tue, Feb 5, 2019 at 10:28 AM Lubashev, Igor <[email-masked]> wrote:

>
>    - Egregious changes in IP might be a signature for network change
>    (change in /16 address, for instance) and a server could terminate the
>    connection and respond with a stateless reset if this happens.
>
>
>
> The client could be a laptop that is tethered via a phone that is changing
> providers.  The disconnect would be completely “punitive” (the old path’s
> CID has already been sent over the new path) and be punishing the client
> for something it had no control over whatsoever.
>
>
>

In this scenario, what is your view of where the IP address changes are
taking place?

I agree that the device connected to a phone (e.g. by a mobile hotspot)
will not generally have a view of the change in upstream path.  If that
phone is using something like mobile IP or a VPN to have a consistent
external address, then I also don't see why this path change would trigger
any change in CID.  But if the phone/hotspot's IP address changes during
this from one provider's set of addresses to another, this is functionally
re-homing.  In that case, isn't there already a high risk that the traffic
will end up at a different back end because of the IP change?

Thanks for sharing your thoughts on this,

Ted

>
>    - Igor
>
>
>
> *From:* Jana Iyengar <[email-masked]>
> *Sent:* Tuesday, February 05, 2019 6:42 AM
> *To:* David Schinazi <[email-masked]>
> *Cc:* [email-masked]; Mike Bishop <[email-masked]>; Martin Thomson <
> [email-masked]>; Kazuho Oku <[email-masked]>
> *Subject:* Re: New path => new connection ID, right?
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_quicwg_base-2Ddrafts_issues_2413&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=4B8i3O2Q6b6NfZdMIFdsB0SlrcmD50Tc24UFo4xCGiY&s=5lr8cziZfX2A9BWD3L8Zv8i1R3zyJYCizqvBjcOmuys&e=>
> >>
> >>
> >>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_quicwg_base-2Ddrafts_pull_2414_commits_13698cbe311922a3995236dda960b4cdff49e36f&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=4B8i3O2Q6b6NfZdMIFdsB0SlrcmD50Tc24UFo4xCGiY&s=R0-jueWgatT5WDkdYQi_JVZFacgy-cAAA4P2uost3jw&e=>
> >>
> >>
>
>
>
> --
> Kazuho Oku
>
>

---

From: "Lubashev, Igor" <[email-masked]>
Date: Tue, 5 Feb 2019 21:33:38 +0000

*   But if the phone/hotspot's IP address changes during this from one provider's set of addresses to another, this is functionally re-homing.  In that case, isn't there already a high risk that the traffic will end up at a different back end because of the IP change?

Yes, this is the scenario – the phone (or your car’s uplink, if connected to an in-car wifi) has switched to a different provider.

This is no different than a usual cell<->wifi migration case from the routing perspective, and the purpose of server-generated connection ID on client-to-server packets is to facilitate routing to the correct backend.  For example, if the packet arrives at a different anycast pop, the identify of the original pop is encoded in the connection ID, and the packet can be tunneled to that pop (or directly to the correct backend within the same or a different pop).

  *   Igor

From: Ted Hardie <[email-masked]>
Sent: Tuesday, February 05, 2019 2:28 PM
To: Lubashev, Igor <[email-masked]>
Cc: Jana Iyengar <[email-masked]>; David Schinazi <[email-masked]>; [email-masked]; Mike Bishop <[email-masked]>; Martin Thomson <[email-masked]>; Kazuho Oku <[email-masked]>
Subject: Re: New path => new connection ID, right?

Hi Igor,

On Tue, Feb 5, 2019 at 10:28 AM Lubashev, Igor <[email-masked]<mailto:[email-masked]>> wrote:

In this scenario, what is your view of where the IP address changes are taking place?

I agree that the device connected to a phone (e.g. by a mobile hotspot) will not generally have a view of the change in upstream path.  If that phone is using something like mobile IP or a VPN to have a consistent external address, then I also don't see why this path change would trigger any change in CID.  But if the phone/hotspot's IP address changes during this from one provider's set of addresses to another, this is functionally re-homing.  In that case, isn't there already a high risk that the traffic will end up at a different back end because of the IP change?

Ted

  *   Igor

From: Jana Iyengar <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, February 05, 2019 6:42 AM
To: David Schinazi <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Mike Bishop <[email-masked]<mailto:[email-masked]>>; Martin Thomson <[email-masked]<mailto:[email-masked]>>; Kazuho Oku <[email-masked]<mailto:[email-masked]>>
Subject: Re: New path => new connection ID, right?

David

--
Kazuho Oku

---

From: Christian Huitema <[email-masked]>
Date: Tue, 5 Feb 2019 11:55:49 -1000

On 2/5/2019 11:33 AM, Lubashev, Igor wrote:
>
>   * But if the phone/hotspot's IP address changes during this from one
>     provider's set of addresses to another, this is functionally
>     re-homing.  In that case, isn't there already a high risk that the
>     traffic will end up at a different back end because of the IP change?
>
>  
>
> Yes, this is the scenario – the phone (or your car’s uplink, if
> connected to an in-car wifi) has switched to a different provider.
>
>  
>
> This is no different than a usual cell<->wifi migration case from the
> routing perspective, and the purpose of server-generated connection ID
> on client-to-server packets is to facilitate routing to the correct
> backend.  For example, if the packet arrives at a different anycast
> pop, the identify of the original pop is encoded in the connection ID,
> and the packet can be tunneled to that pop (or directly to the correct
> backend within the same or a different pop).
>
>  
>
>   * Igor
>

Igor, in the scenario that you describe, a TCP connection would break --
since TCP connections are identified by the 5-tuple. So I don't think
users would be surprised if a QUIC connection broke too. But at least
for IPv6, there is a simple fix. The phone typically sends router
advertisements for the new prefix when it gets a new IPv6 connection.
The laptop will notice that and configure a new IPv6 address. If the
QUIC stack subscribes to the system's "change of address" event, it can
initiate a voluntary migration.

-- Christian Huitema

---

From: Ted Hardie <[email-masked]>
Date: Tue, 5 Feb 2019 14:41:00 -0800

On Tue, Feb 5, 2019 at 1:33 PM Lubashev, Igor <[email-masked]> wrote:

>
>    - But if the phone/hotspot's IP address changes during this from one
>    provider's set of addresses to another, this is functionally re-homing.  In
>    that case, isn't there already a high risk that the traffic will end up at
>    a different back end because of the IP change?
>
>
>
> Yes, this is the scenario – the phone (or your car’s uplink, if connected
> to an in-car wifi) has switched to a different provider.
>
>
>
> routing perspective, and the purpose of server-generated connection ID on
> client-to-server packets is to facilitate routing to the correct backend.
>

I disagree that these are the same.  In the common case for cell<-->wifi
migration the connected device is aware of the interface change.  Because
the connected device is now serving as a forwarder for the packets of
others, the tethered device cannot detect the sort of interface change.
It's a path change to the tethered device, not an interface change.
Christian has pointed out a way to use v6 RA to indicate that rehoming has
occurred and to signal that to the tethered device.  This isn't as
straightforward in a v4 NAT situation, unfortunately.

For example, if the packet arrives at a different anycast pop, the identify
> of the original pop is encoded in the connection ID, and the packet can be
> tunneled to that pop (or directly to the correct backend within the same or
> a different pop).
>
>
This will still work if it uses a previous assigned but unused CID, if it
has detected migration.

And I think that's the key issue here; the tethered device has no way to
detect migration, and so no local trigger for a CID change.  That means
that there is no way to truly prevent CID migration here within QUIC,  only
to limit the time it is in place.  Having the server terminate and firing
off 0-RTT is one way to limit that timing, but we have to acknowledge that
it is at best a mitigation.  The only other option I see offhand would be
to suggest that the connected forwarder terminate the links to induce
something like a DHCPRELEASE and RENEW, but this seems slow,  fragile, and
unlikely to deploy.

Ted

>
>
>    - Igor
>
>
>
> *From:* Ted Hardie <[email-masked]>
> *Sent:* Tuesday, February 05, 2019 2:28 PM
> *To:* Lubashev, Igor <[email-masked]>
> *Cc:* Jana Iyengar <[email-masked]>; David Schinazi <
> [email-masked]>; [email-masked]; Mike Bishop <
> [email-masked]>; Martin Thomson <[email-masked]>; Kazuho Oku <
> [email-masked]>

---

From: "Lubashev, Igor" <[email-masked]>
Date: Tue, 5 Feb 2019 23:12:24 +0000

*   I disagree that these are the same

I understood the question to be about routing packets from a new IP address to the original backend.  The migration of the tethering device is the same as the migration of the client from the routing perspective within the destination network (which may be comprised of multiple anycast pops).

  *   That means that there is no way to truly prevent CID migration here within QUIC,  only to limit the time it is in place.

The purpose of this “MUST terminate the connection” proposal was to improve privacy. There is little to be gained by cutting off the connection, once even a single packet has exposed the original CID to the new path.  It’s not like multiple packets provide a stronger linkability signal than a just one packet.  We may wish to “punish” buggy implementations to induce their vendors to do better, but the client implementation cannot do any better in this case.

  *   The only other option I see offhand would be to suggest that the connected forwarder terminate the links to induce something like a DHCPRELEASE and RENEW, but this seems slow,  fragile, and unlikely to deploy.

Right.  This network attachment change notification would be a subject to a different draft in a different WG, and its deployment would be slow.

  *   Igor

Sent: Tuesday, February 05, 2019 5:41 PM
Importance: High

On Tue, Feb 5, 2019 at 1:33 PM Lubashev, Igor <[email-masked]<mailto:[email-masked]>> wrote:

This is no different than a usual cell<->wifi migration case from the routing perspective, and the purpose of server-generated connection ID on client-to-server packets is to facilitate routing to the correct backend.

I disagree that these are the same.  In the common case for cell<-->wifi migration the connected device is aware of the interface change.  Because the connected device is now serving as a forwarder for the packets of others, the tethered device cannot detect the sort of interface change.  It's a path change to the tethered device, not an interface change.  Christian has pointed out a way to use v6 RA to indicate that rehoming has occurred and to signal that to the tethered device.  This isn't as straightforward in a v4 NAT situation, unfortunately.

For example, if the packet arrives at a different anycast pop, the identify of the original pop is encoded in the connection ID, and the packet can be tunneled to that pop (or directly to the correct backend within the same or a different pop).

This will still work if it uses a previous assigned but unused CID, if it has detected migration.

And I think that's the key issue here; the tethered device has no way to detect migration, and so no local trigger for a CID change.  That means that there is no way to truly prevent CID migration here within QUIC,  only to limit the time it is in place.  Having the server terminate and firing off 0-RTT is one way to limit that timing, but we have to acknowledge that it is at best a mitigation.  The only other option I see offhand would be to suggest that the connected forwarder terminate the links to induce something like a DHCPRELEASE and RENEW, but this seems slow,  fragile, and unlikely to deploy.

Ted

  *   Igor

From: Ted Hardie <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, February 05, 2019 2:28 PM
To: Lubashev, Igor <[email-masked]<mailto:[email-masked]>>
Cc: Jana Iyengar <[email-masked]<mailto:[email-masked]>>; David Schinazi <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Mike Bishop <[email-masked]<mailto:[email-masked]>>; Martin Thomson <[email-masked]<mailto:[email-masked]>>; Kazuho Oku <[email-masked]<mailto:[email-masked]>>
Subject: Re: New path => new connection ID, right?

Hi Igor,

Ted

  *   Igor

David

--
Kazuho Oku

---

From: Roberto Peon <[email-masked]>
Date: Tue, 5 Feb 2019 23:52:49 +0000

Two points:

  1.  A poorly implemented client can leak CIDs along other paths “intentionally”. Providing a direct signal on this is likely to raise awareness. That said, I don’t much care because:
  2.  Is this really important? Will the protocol fail our users in some interesting way without changing this?

-=R

From: QUIC <[email-masked]> on behalf of "Lubashev, Igor" <[email-masked]>
Date: Tuesday, February 5, 2019 at 3:13 PM
To: Ted Hardie <[email-masked]>
Cc: Jana Iyengar <[email-masked]>, Mike Bishop <[email-masked]>, David Schinazi <[email-masked]>, "[email-masked]" <[email-masked]>, Martin Thomson <[email-masked]>, Kazuho Oku <[email-masked]>
Subject: RE: New path => new connection ID, right?

  *   Igor

Ted

  *   Igor

Hi Igor,

Ted

  *   Igor

David

--
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 6 Feb 2019 00:37:22 -0800

I share these concerns about linkability but the reality is that

1) that in many cases it is not practical to enforce
2) humans have learned to sequence DNA

So it is insufficient to change shortly after the fact and it is
problematic to kill a connection on a violation.
Even if todays mobile network tend to keep a fixed IP address that is a
weak assumption.

Privacy really needs to be dealt with at the network routing level in a
chicken and egg fashion.
Consider a network like Tor that will attempt to switch IP address
repeatedly if it gets a chance to do so. If QUIC just drops connections
this defeats those efforts. OTOH if QUIC just publishes tracking cookies
via CID’s this also defeats the purpose.

So, for now, I think the best we can do is to encourage to change CID’s
immediately and disallow cases where it is obviously possible to avoid.
Then look to the next generation of protocols and a longer timeline.

Mikkel

On 6 February 2019 at 00.53.36, Roberto Peon ([email-masked]) wrote:

Two points:

   1. A poorly implemented client can leak CIDs along other paths
   “intentionally”. Providing a direct signal on this is likely to raise
   awareness. That said, I don’t much care because:
   2. Is this really important? Will the protocol fail our users in some
   interesting way without changing this?

-=R

*From: *QUIC <[email-masked]> on behalf of "Lubashev, Igor" <
[email-masked]>
*Date: *Tuesday, February 5, 2019 at 3:13 PM
*To: *Ted Hardie <[email-masked]>
*Cc: *Jana Iyengar <[email-masked]>, Mike Bishop <[email-masked]>,
David Schinazi <[email-masked]>, "[email-masked]" <[email-masked]>,
Martin Thomson <[email-masked]>, Kazuho Oku <[email-masked]>
*Subject: *RE: New path => new connection ID, right?

   - I disagree that these are the same

I understood the question to be about routing packets from a new IP address
to the original backend.  The migration of the tethering device is the same
as the migration of the client *from the routing perspective* within the
destination network (which may be comprised of multiple anycast pops).

   - That means that there is no way to truly prevent CID migration here
   within QUIC,  only to limit the time it is in place.

The purpose of this “MUST terminate the connection” proposal was to improve
privacy. There is little to be gained by cutting off the connection, once
even a single packet has exposed the original CID to the new path.  It’s
not like multiple packets provide a stronger linkability signal than a just
one packet.  We may wish to “punish” buggy implementations to induce their
vendors to do better, but the client implementation cannot do any better in
this case.

   - The only other option I see offhand would be to suggest that the
   connected forwarder terminate the links to induce something like a
   DHCPRELEASE and RENEW, but this seems slow,  fragile, and unlikely to
   deploy.

Right.  This network attachment change notification would be a subject to a
different draft in a different WG, and its deployment would be slow.

   - Igor

*From:* Ted Hardie <[email-masked]>
*Sent:* Tuesday, February 05, 2019 5:41 PM
*To:* Lubashev, Igor <[email-masked]>
*Cc:* Jana Iyengar <[email-masked]>; David Schinazi <
[email-masked]>; [email-masked]; Mike Bishop <[email-masked]>;
Martin Thomson <[email-masked]>; Kazuho Oku <[email-masked]>
*Subject:* Re: New path => new connection ID, right?
*Importance:* High

Ted

   - Igor

*From:* Ted Hardie <[email-masked]>
*Sent:* Tuesday, February 05, 2019 2:28 PM
*To:* Lubashev, Igor <[email-masked]>
*Cc:* Jana Iyengar <[email-masked]>; David Schinazi <
[email-masked]>; [email-masked]; Mike Bishop <[email-masked]>;
Martin Thomson <[email-masked]>; Kazuho Oku <[email-masked]>
*Subject:* Re: New path => new connection ID, right?

Hi Igor,

Ted

   - Igor

David

-- 
Kazuho Oku

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 6 Feb 2019 10:20:26 -0600

So, just checking, as an individual with no hats ...

> Then look to the next generation of protocols and a longer timeline.

I saw Ted's reference to using a new CID that had been assigned on the old
connection, but never used on the old connection. Does that still go to the
wrong backend (potentially)?

Do people agree how perfect non-linkability has to be? I think that
translates into "do people agree whether sending at least one packet with
the old CID on the new connection is fatal"?

(Sliding my outgoing AD hat on for this last part)

I am intrigued by the possibility that privacy might start to be as much of
a consideration at the network level as it has been for the past few years
at the transport level. The BOF request cutoff for IETF 104 is this coming
Friday. Is that too little time to request a non-working group forming BOF
about this for Prague? If it's too little time, but people would like to
spend time talking about that, please let me know while I can still approve
room requests for side meetings :-)

Thanks,

Spencer

> Martin Thomson <[email-masked] <mt@lowentropy..net>>, Kazuho Oku <
> [email-masked]>
> I understood the question to be about routing packets from a new IP
> address to the original backend.  The migration of the tethering device is
> the same as the migration of the client *from the routing perspective*
> within the destination network (which may be comprised of multiple anycast
> pops).
>
>
>
> The purpose of this “MUST terminate the connection” proposal was to
> improve privacy. There is little to be gained by cutting off the
> connection, once even a single packet has exposed the original CID to the
> new path.  It’s not like multiple packets provide a stronger linkability
> signal than a just one packet.  We may wish to “punish” buggy
> implementations to induce their vendors to do better, but the client
> implementation cannot do any better in this case.
>
>
>
> Right.  This network attachment change notification would be a subject to
> a different draft in a different WG, and its deployment would be slow.
>
>
>
>    - Igor
>
>
>
>
>
> For example, if the packet arrives at a different anycast pop, the
> identify of the original pop is encoded in the connection ID, and the
> packet can be tunneled to that pop (or directly to the correct backend
> within the same or a different pop).
>
>
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 6 Feb 2019 09:44:15 -0800

On 6 February 2019 at 17.20.40, Spencer Dawkins at IETF (
[email-masked]) wrote:

If it is not unencrypted on the wire on the old path, it could AFAIK not go
wrong wrt. security. If a CID is constructed for a specific path, then
routing could go wrong, but should not because we don’t issue CID’s per
path, at least not in V1. This means any route to the endpoint must be able
to deal with any CID (I believe I asked the same question a long time ago).
I could see this change in a future version with multi-path and/or if
enough deployment experience shows that there is a need. It would be much
more complex to maintain CID’s then. It already causes some trouble.

I think this depends entirely on the threat model.

If someone has limited capacity to sample traffic then on average it may
not be a problem. But if you are serious, and you have access, all you need
to do is to make a fingerprint of each source and destination connection ID
pair and store it in a bucket with some correlation, e.g. everyone
accessing example.com. Then you can use techniques similar to DNA
sequencing to strand to together all movement, even if you do not store
perfect information at full precision. Here data collection needs to be
fast small and simple, but sequent mining can be done with massive
resources when you know what you are looking for.

Such tracking is not just NSA vs. average Joe. It can also be a concern for
military personnel in the field. More simplistic, fitness trackers have
been used in the past to spot secret deployments via social network maps,
and selfies posted on FaceBook with embedded exif GPS coordinates have also
not helped. Even without broadcasting GPS coordinates, if communication
happens over radio links where the enemy can tap into the core protocol
data below the encryption layer, it can start to piece together a picture
of deployments.

If you look into mesh networks that could be used in disaster areas, you
could also have a massive change in routing hops with a network similar to
IP, but different. Here same states might be interested in certain
dissidents moving with the flow (good/bad depends on the point of view).
QUIC could be layered on top of such networks, and here tracking could also
be interesting simply by listening in on radio.

That said, there are endless other ways to piece together information, not
least via timing and traffic patterns, so I am not convinced that the
efforts to hide migration are truly worthwhile given how difficult it is to
get right, at least not with the current underlying networks.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 6 Feb 2019 12:07:08 -0600

Hi, Mikkel,

Thanks for the speedy reply. A couple of points inline.

On Wed, Feb 6, 2019 at 11:44 AM Mikkel Fahnøe Jørgensen <[email-masked]>
wrote:

> If it is not unencrypted on the wire on the old path, it could AFAIK not
> go wrong wrt. security. If a CID is constructed for a specific path, then
Thanks - that was my understanding, but I'm not an expert here.

> I think this depends entirely on the threat model.
Yeah, that's what I'm afraid of. Not surprising.

> resources when you know what you are looking for.
Only because you mentioned DNA sequencing a couple of times, I thought
you'd enjoy looking at
https://www.theatlantic.com/science/archive/2017/08/these-scientists-took-over-a-computer-by-encoding-malware-in-dna/536361/
...

People ARE creative, aren't we?

> Such tracking is not just NSA vs. average Joe. It can also be a concern
> for military personnel in the field. More simplistic, fitness trackers have
Right. That's why I'm interested in hearing whether doing something so that
the current underlying networks don't have the same helpful-to-monitoring
attributes in a decade or two, is interesting to people. :-)

Spencer

---

From: Roberto Peon <[email-masked]>
Date: Wed, 6 Feb 2019 18:18:53 +0000

One could imagine (i.e. theorize) a network fabric which uses point-to-point flow control for hops where congestion occurs coupled with point-to-point re-xmissions with fair-queuing (a host can mostly only congest itself) which would allow for data to be sent into the network at a constant rate regardless of how much application data one needed to send.

In such cases (you can freely send bytes without causing congestion to others) you’d eliminate the need for the endpoints to constrain the sending rate… which would imply reducing or eliminating the efficacy of traffic analysis based on size/timing.

As a reminder, although I believe it is possible and desirable, such networks are not widely deployed AFAICT, and so this likely remains theoretical (but it is a very fun thing to think about).

If such networks were widely deployed, then linkability would become a more pressing privacy concern as it would be the  thing that provided attackers with the most information.
-=R

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wednesday, February 6, 2019 at 9:44 AM
To: Spencer Dawkins at IETF <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Jana Iyengar <[email-masked]>, Mike Bishop <[email-masked]>, Ted Hardie <[email-masked]>, David Schinazi <[email-masked]>, Martin Thomson <[email-masked]>, Kazuho Oku <[email-masked]>, "Lubashev, Igor" <[email-masked]>, Roberto Peon <[email-masked]>
Subject: Re: New path => new connection ID, right?

On 6 February 2019 at 17.20.40, Spencer Dawkins at IETF ([email-masked]<mailto:[email-masked]>) wrote:
I saw Ted's reference to using a new CID that had been assigned on the old connection, but never used on the old connection. Does that still go to the wrong backend (potentially)?

If it is not unencrypted on the wire on the old path, it could AFAIK not go wrong wrt. security. If a CID is constructed for a specific path, then routing could go wrong, but should not because we don’t issue CID’s per path, at least not in V1. This means any route to the endpoint must be able to deal with any CID (I believe I asked the same question a long time ago). I could see this change in a future version with multi-path and/or if enough deployment experience shows that there is a need. It would be much more complex to maintain CID’s then. It already causes some trouble.

Do people agree how perfect non-linkability has to be? I think that translates into "do people agree whether sending at least one packet with the old CID on the new connection is fatal"?

If someone has limited capacity to sample traffic then on average it may not be a problem. But if you are serious, and you have access, all you need to do is to make a fingerprint of each source and destination connection ID pair and store it in a bucket with some correlation, e.g. everyone accessing example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=5fa1TpKi7wvScJ_lOmtrdMURXXLnj6zvufjI7kia3OA&s=c6T4ntQm3BIOrDD31TL1Ax_ZLewG5Swl0fRvbANwaoE&e=>. Then you can use techniques similar to DNA sequencing to strand to together all movement, even if you do not store perfect information at full precision. Here data collection needs to be fast small and simple, but sequent mining can be done with massive resources when you know what you are looking for.

Such tracking is not just NSA vs. average Joe. It can also be a concern for military personnel in the field. More simplistic, fitness trackers have been used in the past to spot secret deployments via social network maps, and selfies posted on FaceBook with embedded exif GPS coordinates have also not helped. Even without broadcasting GPS coordinates, if communication happens over radio links where the enemy can tap into the core protocol data below the encryption layer, it can start to piece together a picture of deployments.

If you look into mesh networks that could be used in disaster areas, you could also have a massive change in routing hops with a network similar to IP, but different. Here same states might be interested in certain dissidents moving with the flow (good/bad depends on the point of view). QUIC could be layered on top of such networks, and here tracking could also be interesting simply by listening in on radio.

That said, there are endless other ways to piece together information, not least via timing and traffic patterns, so I am not convinced that the efforts to hide migration are truly worthwhile given how difficult it is to get right, at least not with the current underlying networks.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 08 Feb 2019 13:46:21 +1100

In an attempt to close the loop, I've updated https://github.com/quicwg/base-drafts/pull/2414

The controversial bits are apparently:

* if you intentionally move to a new path, then you have to use a connection ID that hasn't been used on any other path

* if you don't have a new connection ID (which also includes zero-length connection IDs in the latest change), then you can't use a new path

I believe that both are editorial changes, but the volume of discussion on the thread indicates that some people would like to see the issue reopened.  In the interests of forward progress, I would like the chairs to make an assessment.

Note that this PR doesn't include the fix to https://github.com/quicwg/base-drafts/issues/2342, which reviewers will no doubt trip over in the process of reviewing this change.

---

From: Ian Swett <[email-masked]>
Date: Fri, 8 Feb 2019 11:22:53 -0500

It also adds "Similarly, an endpoint MUST NOT migrate if its peer supplies
a zero-length connection ID".

In a P2P use case where there's only one connection, this precludes
migration in a case where it would otherwise work, so I don't see adding
this restriction as being helpful.

On Thu, Feb 7, 2019 at 9:46 PM Martin Thomson <[email-masked]> wrote:

> In an attempt to close the loop, I've updated
> https://github.com/quicwg/base-drafts/pull/2414
>
> * if you intentionally move to a new path, then you have to use a
> connection ID that hasn't been used on any other path
>
> * if you don't have a new connection ID (which also includes zero-length
> connection IDs in the latest change), then you can't use a new path
>
> I believe that both are editorial changes, but the volume of discussion on
> the thread indicates that some people would like to see the issue
> reopened.  In the interests of forward progress, I would like the chairs to
> make an assessment.
>
> Note that this PR doesn't include the fix to
> https://github.com/quicwg/base-drafts/issues/2342, which reviewers will
> no doubt trip over in the process of reviewing this change.
>

---

From: Mike Bishop <[email-masked]>
Date: Fri, 8 Feb 2019 18:38:22 +0000

That’s not a change – the requirement is already in the spec:
An endpoint whose peer has selected a zero-length connection ID MUST continue to use a zero-length connection ID for the lifetime of the connection and MUST NOT send packets from any other local address.

If we want to change this restriction, let’s discuss that as a separate issue, please.  (I’m not in favor of changing it, because in the general case it requires trial decryption.  You’re correct that in the special case of using a unique local port per connection there might be some leeway.)

From: QUIC <[email-masked]> On Behalf Of Ian Swett
Sent: Friday, February 8, 2019 8:23 AM
To: Martin Thomson <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: New path => new connection ID, right?

It also adds "Similarly, an endpoint MUST NOT migrate if its peer supplies a zero-length connection ID".

In a P2P use case where there's only one connection, this precludes migration in a case where it would otherwise work, so I don't see adding this restriction as being helpful.

On Thu, Feb 7, 2019 at 9:46 PM Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
In an attempt to close the loop, I've updated https://github.com/quicwg/base-drafts/pull/2414

---

From: Ian Swett <[email-masked]>
Date: Fri, 8 Feb 2019 14:20:48 -0500

Thanks Mike, I was unaware of that restriction.  Issue filed.

https://github.com/quicwg/base-drafts/issues/2441

On Fri, Feb 8, 2019 at 1:38 PM Mike Bishop <[email-masked]> wrote:

> An endpoint whose peer has selected a zero-length connection ID MUST
> continue to use a zero-length connection ID for the lifetime of the
> connection and MUST NOT send packets from any other local address.
>
>
>
> If we want to change this restriction, let’s discuss that as a separate
> issue, please.  (I’m not in favor of changing it, because in the general
> case it requires trial decryption.  You’re correct that in the special case
> of using a unique local port per connection there might be some leeway.)
>
>
>
> *From:* QUIC <[email-masked]> *On Behalf Of * Ian Swett
> *Sent:* Friday, February 8, 2019 8:23 AM
> *To:* Martin Thomson <[email-masked]>
> *Cc:* IETF QUIC WG <[email-masked]>

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 18 Feb 2019 18:54:54 -0800

Attempting to bring this discussion back to the PR in question. As noted by
ekinnear
<https://github.com/quicwg/base-drafts/issues/2413#issuecomment-460457572>,
the PR that Martin has proposed is an editorial fix. I would suggest that
if anyone who wants to change behavior from PR #2414
<https://github.com/quicwg/base-drafts/pull/2414> should open a new issue.

Is anyone arguing that PR 2414
<https://github.com/quicwg/base-drafts/pull/2414> is not editorial?

- jana