Repeat tokens in all Initial packets #2089

ianswett · 2018-12-01T21:07:36Z

The client repeats the token in all Initial packets. Also clarifies that the token is sent in Initial in a few spots.

https://www.ietf.org/mail-archive/web/quic/current/msg05071.html

The client repeats the token in all Initial packets. Also clarifies that the token is sent in Initial in a few spots. https://www.ietf.org/mail-archive/web/quic/current/msg05071.html

draft-ietf-quic-transport.md

mikkelfj · 2018-12-01T21:22:50Z

draft-ietf-quic-transport.md

+believes that its point of network attachment has changed since the token was
+last used; that is, if there is a change in its local IP address or network
+interface.  A client needs to start the connection process over if it migrates
+prior to completing the handshake.


Maybe this is getting ahead of other discussions, but a client SHOULD not repeat also because the server MAY reject repeated tokens.

I assume that the text from PR #2064 will be inserted after this paragraph. Again, it is the flip side of the "client SHOULD NOT" clause. Client should not reuse the same token for multiple connections, and servers MAY (or SHOULD?) reject connections that attempt to reuse a token.

@huitema has it right here. We are adding text in #2064 that should help.

mikkelfj · 2018-12-01T21:23:50Z

draft-ietf-quic-transport.md

+SHOULD attempt to validate it, unless it has already completed address
+validation.  If the token is invalid then the server SHOULD proceed as if
+the client did not have a validated address, including potentially sending
+a Retry. If the validation succeeds, the server SHOULD then allow the
 handshake to proceed.


And here text might be placed on server MAY reject repeat tokens?

huitema

I assume that we will process PR #2064 after this one. I am fine with the text, but I would like something said about server behavior. Client recommendations are mostly enforced when breaking them causes servers to reject packets...

huitema · 2018-12-01T23:05:19Z

draft-ietf-quic-transport.md

+
+As long as it is not possible for an attacker to generate a valid token for
+its own address (see {{token-integrity}}) and the client is able to return
+that token, it proves to the server that it received the token.



Define "proves". The token mechanism may be vulnerable to replay attacks.

It only proves that it received it, not when. I think that we can probably defer discussion of the reuse/replay aspects of this.

huitema · 2018-12-01T23:10:05Z

draft-ietf-quic-transport.md

+address validation in a future connection.  The client MUST include the
+token in all Initial packets it sends, unless a Retry replaces the token
+with a newer token. The client MUST NOT use the token provided in a Retry
+for future connections.



Yes, "all Initial packets" is what we want. At least it is not ambiguous. There is however a general problem with such recommendations: they are not enforced unless servers behave that way. I would add something at the end:

with a newer token. The client MUST NOT use the token provided in a Retry for future connections. Servers MAY reject any Initial packet that does not carry the expected token.

I am not sure about the use of the plural in "future connections". Allowing the same token to be reused in multiple connections is potentially dangerous. But that may be work for another PR.

Is the desired action "reject" or "ignore/discard"? I would say either is OK, though I might be inclined more toward the latter (on the basis that spoofing implies DoS).

Yes, discard is fine.

Thanks, updated.

huitema · 2018-12-01T23:13:12Z

draft-ietf-quic-transport.md

+believes that its point of network attachment has changed since the token was
+last used; that is, if there is a change in its local IP address or network
+interface.  A client needs to start the connection process over if it migrates
+prior to completing the handshake.


I assume that the text from PR #2064 will be inserted after this paragraph. Again, it is the flip side of the "client SHOULD NOT" clause. Client should not reuse the same token for multiple connections, and servers MAY (or SHOULD?) reject connections that attempt to reuse a token.

martinthomson

This is fine, pending the small suggested tweaks. Though we need to settle on "reject" vs. "discard" to close this one.

draft-ietf-quic-transport.md

martinthomson · 2018-12-02T02:58:26Z

draft-ietf-quic-transport.md

+
+As long as it is not possible for an attacker to generate a valid token for
+its own address (see {{token-integrity}}) and the client is able to return
+that token, it proves to the server that it received the token.



It only proves that it received it, not when. I think that we can probably defer discussion of the reuse/replay aspects of this.

martinthomson · 2018-12-02T02:59:54Z

draft-ietf-quic-transport.md

+address validation in a future connection.  The client MUST include the
+token in all Initial packets it sends, unless a Retry replaces the token
+with a newer token. The client MUST NOT use the token provided in a Retry
+for future connections.



Is the desired action "reject" or "ignore/discard"? I would say either is OK, though I might be inclined more toward the latter (on the basis that spoofing implies DoS).

martinthomson · 2018-12-02T03:01:33Z

draft-ietf-quic-transport.md

+believes that its point of network attachment has changed since the token was
+last used; that is, if there is a change in its local IP address or network
+interface.  A client needs to start the connection process over if it migrates
+prior to completing the handshake.


@huitema has it right here. We are adding text in #2064 that should help.

martinthomson · 2018-12-02T03:01:44Z

draft-ietf-quic-transport.md

+SHOULD attempt to validate it, unless it has already completed address
+validation.  If the token is invalid then the server SHOULD proceed as if
+the client did not have a validated address, including potentially sending
+a Retry. If the validation succeeds, the server SHOULD then allow the
 handshake to proceed.


Co-Authored-By: ianswett <ianswett@users.noreply.github.com>

mikkelfj · 2018-12-03T20:25:38Z

draft-ietf-quic-transport.md

-can either abort the connection or permit it to proceed.
+token MUST be repeated by the client in all Initial packets it sends after it
+receives the Retry packet.  In response to receiving a token in an Initial
+packet, a server can either abort the connection or permit it to proceed.



Isn't there a third option to ignore a packet rather then abort or permit to proceed?

What's the 3rd option?

The third option is to "drop/ignore". The mentioned options are "abort" and "proceed", but proceed implies the packet is processed.

SG, changed from receiving to processing, because otherwise I think this sentence is not really correct.

Christian/Martin's suggestion

martinthomson · 2018-12-04T21:13:13Z

@ianswett, does this fix an issue?

ianswett · 2018-12-04T21:52:20Z

The only issue I'm aware of is the thread I linked to.

Repeat tokens in all Initial packets

e8277d1

The client repeats the token in all Initial packets. Also clarifies that the token is sent in Initial in a few spots. https://www.ietf.org/mail-archive/web/quic/current/msg05071.html

ianswett requested review from huitema and martinthomson December 1, 2018 21:07

mikkelfj reviewed Dec 1, 2018

View reviewed changes

huitema reviewed Dec 1, 2018

View reviewed changes

martinthomson reviewed Dec 2, 2018

View reviewed changes

martinthomson and others added 2 commits December 2, 2018 14:32

Update draft-ietf-quic-transport.md

c3206b4

Co-Authored-By: ianswett <ianswett@users.noreply.github.com>

Rewrap

ce9e08e

mikkelfj reviewed Dec 3, 2018

View reviewed changes

ianswett added 2 commits December 3, 2018 21:15

Update draft-ietf-quic-transport.md

1c3b5a2

Christian/Martin's suggestion

Update draft-ietf-quic-transport.md

18774ce

martinthomson merged commit fc92ac6 into master Dec 4, 2018

martinthomson deleted the ianswett-repeat-tokens branch December 4, 2018 21:13

martinthomson added design An issue that affects the design of the protocol; resolution requires consensus. -transport labels Dec 13, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Repeat tokens in all Initial packets #2089

Repeat tokens in all Initial packets #2089

ianswett commented Dec 1, 2018

mikkelfj Dec 1, 2018

huitema Dec 1, 2018

martinthomson Dec 2, 2018

mikkelfj Dec 1, 2018

martinthomson Dec 2, 2018

huitema left a comment

huitema Dec 1, 2018

martinthomson Dec 2, 2018

huitema Dec 1, 2018

martinthomson Dec 2, 2018

huitema Dec 2, 2018

ianswett Dec 4, 2018

huitema Dec 1, 2018

martinthomson left a comment

martinthomson Dec 2, 2018

martinthomson Dec 2, 2018

martinthomson Dec 2, 2018

martinthomson Dec 2, 2018

mikkelfj Dec 3, 2018

ianswett Dec 4, 2018

mikkelfj Dec 4, 2018

ianswett Dec 4, 2018

martinthomson commented Dec 4, 2018

ianswett commented Dec 4, 2018

Repeat tokens in all Initial packets #2089

Repeat tokens in all Initial packets #2089

Conversation

ianswett commented Dec 1, 2018

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

huitema left a 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

martinthomson left a 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

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

martinthomson commented Dec 4, 2018

ianswett commented Dec 4, 2018