New connection IDs are mandatory for intentional migration #2414

martinthomson · 2019-02-04T23:12:37Z

Based on #2386, which should merge soon.

Closes #2413.

Co-Authored-By: martinthomson <mt@lowentropy.net>

I could have sworn we agreed to this previously, but I also can't find where we captured it. So here it is. This was originally an editorial factoring of text, but I guess it needs to be a design issue now. Closes #2413.

ianswett · 2019-02-05T07:46:41Z

draft-ietf-quic-transport.md


 Clients MAY move to a new connection ID at any time based on
 implementation-specific concerns.  For example, after a period of network
-inactivity NAT rebinding might occur when the client begins sending data again.
+inactivity, where NAT rebinding might occur when the client begins sending data


Suggested change

inactivity, where NAT rebinding might occur when the client begins sending data

inactivity, NAT rebinding may cause an unintentional change in path when the client begins sending data

janaiyengar · 2019-02-05T09:21:46Z

draft-ietf-quic-transport.md

-that packet numbers cannot be used to correlate activity.  This does not prevent
-other properties of packets, such as timing and size, from being used to
-correlate activity.
+An endpoint MUST use a new connection ID if it initiates connection migration,


I would move the conditional clause to the beginning, otherwise it's not clear what the "This" in the next sentence refers to.

"Unless the peer has selected a zero-length connection ID, an endpoint MUST use ..."

Also, how about adding something about what the endpoint needs to do if it has nothing from the peer? Something like: "If no new connection IDs are available, the endpoint MUST NOT migrate. The endpoint MAY close the connection, but MUST NOT send any packets on a new path with the same connection ID as that used on an earlier path." I can't find any text that says as much. I wonder if this is a new non-editorial issue, since we currently do not have normative text about this (maybe I just can't find it yet).

I've just updated the text below to cover the MUST NOT migrate case (I used "cannot" before).

janaiyengar · 2019-02-05T09:22:46Z

draft-ietf-quic-transport.md

+migrate.  If a peer chooses to receive packets with zero-length connection IDs,
+an endpoint can always migrate.  To ensure that migration is possible and
+packets sent on different paths cannot be correlated, endpoints SHOULD provide
+new connection IDs before peers migrate.


This text is good, but still doesn't have normatives, and I think we should have MUST NOT.

ianswett · 2019-02-05T21:03:31Z

draft-ietf-quic-transport.md

-  changes.
+An endpoint cannot migrate to a new path if it does not have a connection ID to
+use on that path.  An endpoint that exhausts available connection IDs cannot
+migrate.  If a peer chooses to receive packets with zero-length connection IDs,


I think it makes sense to put this 3rd sentence first, and then say, "Otherwise, an endpoint cannot migrate..."

The current text reads in a somewhat self-contradictory way.

janaiyengar · 2019-02-06T05:29:44Z

draft-ietf-quic-transport.md

+connection IDs before peers migrate.
+
+If a peer chooses to receive packets with zero-length connection IDs, an
+endpoint can always migrate - zero-length connection IDs provide no significant


Suggested change

endpoint can always migrate - zero-length connection IDs provide no significant

endpoint can always migrate, since zero-length connection IDs provide no significant

MikeBishop

As noted in #2413, this PR permits something that's currently prohibited intentionally -- migrating with a zero-length CID. Do we have consensus to make that change?

If there's no CID and the packet is coming from an unknown remote address, how does the server know what keys to use to remove packet protection in that case? We've previously said we need to avoid trial decryption, and that seems like the only option if migration is permitted.

mikkelfj · 2019-02-08T09:09:29Z

I think this strikes a good balance. It isn't practical to forbid migration without CID when NAT's do it behind your back, but allowing it for intentional migration would work against networks attempting to move towards safer modes of operation in the future, some which might only make sense if QUIC does indeed require new CID's on migration.

At some point with IPv6, NAT rebinding might be seen the same way as older insecure WLAN standards.

draft-ietf-quic-transport.md

ianswett · 2019-02-08T20:58:41Z

draft-ietf-quic-transport.md

+Endpoints MAY move to a new connection ID at any time.
+
+An endpoint MUST use a new connection ID if it initiates connection migration,
+unless the peer has selected a zero-length connection ID.  Using a new


Above we say you can't migrate if you use a zero-length connection ID, so I don't understand the purpose of "unless the peer has selected a zero-length connection ID."

Yep, trimmed it down.

ianswett · 2019-02-08T20:59:58Z

draft-ietf-quic-transport.md

-: If both endpoints change connection ID in response to seeing a change in
-  connection ID from their peer, then this can trigger an infinite sequence of
-  changes.
+An endpoint MUST NOT intentionally migrate to a new path if it does not have a


This sentence seems duplicative of the paragraph above starting with "An endpoint MUST use a new connection ID ..."

ianswett

One small suggestion, but I think this LG.

ianswett · 2019-02-11T21:17:36Z

draft-ietf-quic-transport.md

-the same connection on different networks.  Header protection ensures
-that packet numbers cannot be used to correlate activity.  This does not prevent
-other properties of packets, such as timing and size, from being used to
+Endpoints MAY move to a new connection ID at any time.


Nit: move to may not be clear. How about "Endpoints MAY change the Destination Connection ID they send in short header packets at any time." assuming that statement is correct.

draft-ietf-quic-transport.md

erickinnear

Looks like good clarification, just one minor wording comment

erickinnear · 2019-02-12T23:53:01Z

draft-ietf-quic-transport.md

@@ -1853,7 +1853,9 @@ An endpoint also MUST NOT initiate connection migration if the peer sent the
 `disable_migration` transport parameter during the handshake.  An endpoint which
 has sent this transport parameter, but detects that a peer has nonetheless
 migrated to a different network MAY treat this as a connection error of type
-INVALID_MIGRATION.
+INVALID_MIGRATION.  Similarly, an endpoint MUST NOT migrate if its peer supplies


It would probably be worth indicating that this is intentional migration, just to keep everything clear. Elsewhere I think we've said an endpoint must not "initiate" migration, since of course its peer may think it migrated due to a NAT.

larseggert · 2019-02-13T07:18:48Z

This seems to have consensus, tagging as such and reassigning.

mnot · 2019-02-18T05:30:10Z

Removing has-consensus tag as it needs to be canvassed on-list (and attached to an issue, not a PR).

larseggert · 2019-02-18T09:41:34Z

I'm sorry if I misunderstood the new process, but I don't think your PR says that an issue must be discussed on the mailing list? Doesn't it say that the discussion can happen on the list or on the issue?

mnot · 2019-02-19T01:35:48Z

@larseggert discussion can happen in either place, but we've always checked with the list before declaring consensus (which is what has-consensus records). In the currently operative process, that's happening (admittedly sporadically) after the drafts are published.

janaiyengar · 2019-02-19T02:49:16Z

@mnot @larseggert : The associated issue is #2413 and there's been a mailing list discussion. There seems to be some disagreement on what needs to happen next.

Specifically, some folks think this PR is an editorial one, and some want to open up the issue as a design issue for discussion.

mnot · 2019-02-19T06:08:15Z

#2413 is a design issue. If this is just editorial and no one disputes that, you can apply it as that, but it can't close #2413.

martinthomson · 2019-02-19T06:47:48Z

#2413 is only marked design because there is debate, therefore, I conclude that we need chairs to help us. I requested that close to 2 weeks ago.

MikeBishop · 2019-02-25T19:14:23Z

The requirement previously existed, but was accidentally dropped during one of the CID rewrites. The underlying question is whether we had consensus to remove the requirement previously -- if so, then reversing ourselves requires consensus. If not, then it's just fixing an accidental deletion.

ianswett · 2019-02-25T20:26:12Z

If the PR that removed it doesn't have a note about removing it, I'd consider it an accidental deletion(which is what I suspect).

erickinnear · 2019-02-25T21:49:13Z

I thought the overall requirement for changing CIDs was still in the text, so it doesn't seem like the issue is around adding/removing a requirement, but rather the rest of the accompanying text here?
Otherwise, not sure how this isn't entirely editorial, since the main requirement is already in place.

martinthomson and others added 4 commits January 30, 2019 12:25

Remove requirement for reciprocal connection ID change

63e1803

Closes #1795, #2145.

remove redundant word

23014c8

Co-Authored-By: martinthomson <mt@lowentropy.net>

Editorial changes

48002d0

New connection IDs are mandatory for intentional migration

13698cb

I could have sworn we agreed to this previously, but I also can't find where we captured it. So here it is. This was originally an editorial factoring of text, but I guess it needs to be a design issue now. Closes #2413.

martinthomson added design An issue that affects the design of the protocol; resolution requires consensus. -transport labels Feb 4, 2019

Reword zero-length caveat

d6fe101

ianswett reviewed Feb 5, 2019

View reviewed changes

janaiyengar reviewed Feb 5, 2019

View reviewed changes

Explain more

491d871

martinthomson mentioned this pull request Feb 5, 2019

Remove requirement for reciprocal connection ID change #2386

Merged

ianswett reviewed Feb 5, 2019

View reviewed changes

Editorial changes, stronger MUST

96b9fe8

janaiyengar reviewed Feb 6, 2019

View reviewed changes

janaiyengar approved these changes Feb 6, 2019

View reviewed changes

Editorial fix

7c2660e

MikeBishop requested changes Feb 6, 2019

View reviewed changes

No connection ID = no migration

fb9f690

This was referenced Feb 8, 2019

Don't change CID on peer CID change #2145

Closed

Mandate using a new connection ID on migration #2413

Closed

ianswett reviewed Feb 8, 2019

View reviewed changes

draft-ietf-quic-transport.md Outdated Show resolved Hide resolved

MikeBishop approved these changes Feb 8, 2019

View reviewed changes

ianswett reviewed Feb 8, 2019

View reviewed changes

Remove text, thanks Ian

ac7f381

ianswett approved these changes Feb 11, 2019

View reviewed changes

Ian's suggestion, tweaked

c95b968

ianswett reviewed Feb 11, 2019

View reviewed changes

draft-ietf-quic-transport.md Show resolved Hide resolved

martinthomson assigned mnot and larseggert Feb 12, 2019

erickinnear approved these changes Feb 13, 2019

View reviewed changes

Initiate migration

c13a9f5

larseggert added the has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. label Feb 13, 2019

larseggert assigned martinthomson and janaiyengar and unassigned mnot and larseggert Feb 13, 2019

mnot removed the has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. label Feb 18, 2019

martinthomson merged commit 2575888 into master Mar 11, 2019

martinthomson deleted the new-path-new-cid branch March 11, 2019 22:52

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

New connection IDs are mandatory for intentional migration #2414

New connection IDs are mandatory for intentional migration #2414

martinthomson commented Feb 4, 2019

ianswett Feb 5, 2019

janaiyengar Feb 5, 2019

martinthomson Feb 5, 2019

janaiyengar Feb 5, 2019

ianswett Feb 5, 2019

janaiyengar Feb 6, 2019

MikeBishop left a comment

mikkelfj commented Feb 8, 2019

ianswett Feb 8, 2019

martinthomson Feb 10, 2019

ianswett Feb 8, 2019

ianswett left a comment

ianswett Feb 11, 2019

erickinnear left a comment

erickinnear Feb 12, 2019

larseggert commented Feb 13, 2019

mnot commented Feb 18, 2019

larseggert commented Feb 18, 2019

mnot commented Feb 19, 2019

janaiyengar commented Feb 19, 2019

mnot commented Feb 19, 2019

martinthomson commented Feb 19, 2019

MikeBishop commented Feb 25, 2019

ianswett commented Feb 25, 2019

erickinnear commented Feb 25, 2019

	inactivity, where NAT rebinding might occur when the client begins sending data
	inactivity, NAT rebinding may cause an unintentional change in path when the client begins sending data

	endpoint can always migrate - zero-length connection IDs provide no significant
	endpoint can always migrate, since zero-length connection IDs provide no significant

New connection IDs are mandatory for intentional migration #2414

New connection IDs are mandatory for intentional migration #2414

Conversation

martinthomson commented Feb 4, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MikeBishop left a comment

Choose a reason for hiding this comment

mikkelfj commented Feb 8, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ianswett left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

erickinnear left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

larseggert commented Feb 13, 2019

mnot commented Feb 18, 2019

larseggert commented Feb 18, 2019

mnot commented Feb 19, 2019

janaiyengar commented Feb 19, 2019

mnot commented Feb 19, 2019

martinthomson commented Feb 19, 2019

MikeBishop commented Feb 25, 2019

ianswett commented Feb 25, 2019

erickinnear commented Feb 25, 2019