Subject: [quicwg/base-drafts] Introduce PATH_CHALLENGE and PATH_RESPONSE frames (#1086)

From: janaiyengar <[email-masked]>
Date: Tue, 30 Jan 2018 18:18:06 -0800

Replaces PING with Data and PONG frames with PATH_CHALLENGE and PATH_RESPONSE frames.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1086

-- Commit Summary --

  * Use PATH_CHALLENGE and PATH_RESPONSE frames.

-- File Changes --

    M draft-ietf-quic-transport.md (179)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1086.patch
https://github.com/quicwg/base-drafts/pull/1086.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086

---

From: ianswett <[email-masked]>
Date: Wed, 31 Jan 2018 03:12:42 +0000 (UTC)

ianswett commented on this pull request.

One suggestion, otherwise LGTM

-An endpoint that receives an unsolicited PONG frame - that is, a PONG frame
-containing a payload that is empty MUST generate a connection error of type
-FRAME_ERROR, indicating the PONG frame (that is, 0x10d).  If the content of a
-PONG frame does not match the content of a PING frame previously sent by the
-endpoint, the endpoint MAY generate a connection error of type UNSOLICITED_PONG.
+
+The sender of this frame MUST include at least one octet of data in the Data
+field.
+
+The recipient of this frame MUST generate a PATH_RESPONSE frame
+({{frame-path-response}}) containing the same Data.  An endpoint that receives a
+PATH_CHALLENGE frame containing an empty payload MUST generate a connection
+error of type FRAME_ERROR, indicating the PATH_CHALLENGE frame (that is, 0x0e).
+
+A PATH_CHALLENGE frame MUST NOT elicit acknowledgements; the corresponding

Are we clear on the meaning of elicit here?  We definitely intend for the packet containing the PATH_CHALLENGE frame to be acknowledged.  Given that, I'd be inclined to just consider it a frame we acknowledge and remove this paragraph.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086#pullrequestreview-92795975

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Jan 2018 19:52:27 -0800

martinthomson requested changes on this pull request.

This is definitely a much cleaner design than overloading PING as I did.

> -new address.  Once a PONG frame containing the same payload is received, the
-address is considered to be valid.  The PONG frame can use any path on its
-return.  A PING frame containing 12 randomly generated {{?RFC4086}} octets is
-sufficient to ensure that it is easier to receive the packet than it is to guess
-the value correctly.
-
-If the PING frame is determined to be lost, a new PING frame SHOULD be
-generated.  This PING frame MUST include a new Data field that is similarly
-difficult to guess.
+endpoint validates a remote address by sending a PATH_CHALLENGE frame containing
+a payload that is hard to guess.  This frame MUST be sent in a packet that is
+sent to the new address.  Once a PATH_RESPONSE frame containing the same payload
+is received, the address is considered to be valid.  The PATH_RESPONSE frame can
+use any path on its return.  A PATH_CHALLENGE frame containing 12 randomly
+generated {{?RFC4086}} octets is sufficient to ensure that it is easier to
+receive the packet than it is to guess the value correctly.

I think that we can remove this last sentence now that PATH_CHALLENGE is fixed size.  FWIW, I think that we could drop back to 8 happily.  12 raised some eyebrows, and the handshake uses fewer octets.  That said, 12 means that you could include 8 octets of randomness and a timestamp - or a timestamp and an 8 octet HMAC - so that you don't have to maintain state and you can still measure RTT.

> -generated.  This PING frame MUST include a new Data field that is similarly
-difficult to guess.
+endpoint validates a remote address by sending a PATH_CHALLENGE frame containing
+a payload that is hard to guess.  This frame MUST be sent in a packet that is
+sent to the new address.  Once a PATH_RESPONSE frame containing the same payload
+is received, the address is considered to be valid.  The PATH_RESPONSE frame can
+use any path on its return.  A PATH_CHALLENGE frame containing 12 randomly
+generated {{?RFC4086}} octets is sufficient to ensure that it is easier to
+receive the packet than it is to guess the value correctly.
+
+An endpoint MAY send multiple PATH_CHALLENGE frames to handle packet loss or to
+make additional measurements on a new network path.
+
+An endpoint MUST use fresh random data in every PATH_CHALLENGE frame so that it
+can associate the peer's response with the causative PATH_CHALLENGE,
+additionally helping the endpoint make more accurate path measurements.

Split the last clause here into a new sentence: Using fresh values allows the endpoint to measure the time taken to respond to a challenge.

> +a payload that is hard to guess.  This frame MUST be sent in a packet that is
+sent to the new address.  Once a PATH_RESPONSE frame containing the same payload
+is received, the address is considered to be valid.  The PATH_RESPONSE frame can
+use any path on its return.  A PATH_CHALLENGE frame containing 12 randomly
+generated {{?RFC4086}} octets is sufficient to ensure that it is easier to
+receive the packet than it is to guess the value correctly.
+
+An endpoint MAY send multiple PATH_CHALLENGE frames to handle packet loss or to
+make additional measurements on a new network path.
+
+An endpoint MUST use fresh random data in every PATH_CHALLENGE frame so that it
+can associate the peer's response with the causative PATH_CHALLENGE,
+additionally helping the endpoint make more accurate path measurements.
+
+If the PATH_CHALLENGE frame is determined to be lost, a new PATH_CHALLENGE frame
+SHOULD be generated.  This PATH_CHALLENGE frame MUST include new data that is

Rather than SHOULD here, I think that you need to talk about sending multiple to deal with the potential of loss, but limiting the total time or number of challenges and eventually giving up.

-## PONG Frame {#frame-pong}
+Endpoints can use PATH_CHALLENGE frames (type=0x0e) to check reachability to the
+peer, to verify a new path's PMTU, and for address validation during connection

I think that you should drop the PMTU bit here.  It's the packet size that determines PMTU validity anyway.

-The PONG frame (type=0x0d) is sent in response to a PING frame that contains
-data.  Its format is identical to the PING frame ({{frame-ping}}).
+PATH_CHALLENGE frames contain a variable-length payload.

A fixed size is better.  No chance of messing it up that way.  As I said above, I think that 12 octets is pretty good (that's the size of the STUN transaction ID).

To the above, one octet is of almost no value.  You would need many PATH_RESPONSE frames.

When?  If the secondary value of PATH_CHALLENGE is to be realized, this should be done immediately.  Or are we expecting the ACK frame to include ACK Delay and we expect challengers to use that to correct their view of path delay?  With the potential for the ACK or response to follow a different path, it's hard to know how reliable this will be for measuring path RTT.

I'm with Ian here.  I think that we can treat this frame as normal.  I can see how you might want to exclude PATH_RESPONSE from acknowledgment, but even there I would just let the ACKs flow.

> @@ -3868,6 +3896,11 @@ thanks to all.
 
 Issue and pull request numbers are listed with a leading octothorp.
 
+## Since draft-ietf-quic-transport-09
+
+- Added PATH_CHALLENGE and PATH_RESPONSE frames to replace PING with Data and
+  PONG frame. Changed ACK frame type from 0x0e to 0x0d. (#000)

Can you open an issue for this, so we can track it?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086#pullrequestreview-92798947

---

From: erickinnear <[email-masked]>
Date: Wed, 31 Jan 2018 01:20:34 -0800

erickinnear commented on this pull request.

A few minor nits, but otherwise looks good! 
Thanks for putting this together.

-~~~
- 0                   1                   2                   3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|   Length(8)   |                 Data (*)                    ...
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-~~~
-
-Length:
+The receiver of a PING frame simply need to acknowledge the packet containing

Nit: need -> needs

> @@ -2352,17 +2337,56 @@ Application Error Code:
   {{app-error-codes}}).

+## PATH_CHALLENGE Frame {#frame-path-challenge}

Should these fall after ACK frames in terms of ordering? 

I didn't think that we previously intended a packet containing only a PATH_CHALLENGE frame to be acknowledged, but I think that could make sense. 

Minor question though: 
What if we get a PATH_RESPONSE, but no ACK? Do we then retransmit the PATH_CHALLENGE? 

The previous comment about the packets potentially being sent on (or taking) different paths is interesting, because we could ACK along the current path, but send the PATH_RESPONSE along the same path the PATH_CHALLENGE came in on. This could provide valuable information to the endpoint about the viability of those two paths, although we still end up in the situation of a rapidly failing path causing the ACK to not be delivered, which is not the end of the world. 

If we require the PATH_RESPONSE to be sent on the same path as the PATH_CHALLENGE, do we place any requirements on the ACK? And does such a requirement make sense? 

> +PATH_RESPONSE serves to indicate receipt of the PATH_CHALLENGE.
+
+
+## PATH_RESPONSE Frame {#frame-path-response}
+
+The PATH_RESPONSE frame (type=0x0f) is sent in response to a PATH_CHALLENGE
+frame.  Its format is identical to the PATH_CHALLENGE frame
+({{frame-path-challenge}}).
+
+An endpoint that receives a PATH_RESPONSE frame containing an empty payload MUST
+generate a connection error of type FRAME_ERROR, indicating the PATH_RESPONSE
+frame (that is, 0x0e).  If the content of a PATH_RESPONSE frame does not match
+the content of a PATH_CHALLENGE frame previously sent by the endpoint, the
+endpoint MAY generate a connection error of type UNSOLICITED_PATH_RESPONSE.
+
+A PATH_RESPONSE frame MUST NOT elicit an acknowledgement.

 ## ACK Frame {#frame-ack}

Minor: This is now type `0x0d`

Also, given that we stated that a new transmission of a PATH_CHALLENGE frame due to a lack of a PATH_RESPONSE should include different random data, how does that interact with loss recovery due to ACKs being present/not being present? 

(In other words, I can see an argument for either behavior, but we should make sure that we update below if we change this.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086#pullrequestreview-92846616

---

From: ianswett <[email-masked]>
Date: Wed, 31 Jan 2018 14:56:30 +0000 (UTC)

{{app-error-codes}}).

I don't believe we have specified packet ordering if that's what you're referring to, so I'd prefer not to start now.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086#discussion_r165076567

---

From: ianswett <[email-masked]>
Date: Wed, 31 Jan 2018 16:05:00 +0000 (UTC)

Fixed 8 bytes SGTM.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086#discussion_r165099927

---

From: Nick Banks <[email-masked]>
Date: Wed, 31 Jan 2018 16:45:45 +0000 (UTC)

nibanks commented on this pull request.

Looks pretty good. Just a few comments/questions.

 If validation of the new remote address fails, after allowing enough time for
-possible loss and recovery of packets carrying PING and PONG frames, the
-endpoint MUST terminate the connection.  When setting this timer,
-implementations are cautioned that the new path could have a longer round trip
-time than the original.  The endpoint MUST NOT send a CONNECTION_CLOSE frame in
-this case; it has to assume that the remote peer does not want to receive any
-more packets.
+recovering from possible loss of packets carrying PATH_CHALLENGE and
+PATH_RESPONSE frames, the endpoint MUST terminate the connection.  When setting

Why should the connection be terminated if the response wasn't received? What if the new path was just being interrogated for viability and it just wasn't viable (too much loss, blocked in one direction or got disconnected)? Should that really cause the good path to be killed as well?

+1 for fixed size.

-: An endpoint received a PONG frame that did not correspond to any PING frame
-  that it previously sent.
+: An endpoint received a PATH_RESPONSE frame that did not correspond to any
+  PATH_CHALLENGE frame that it previously sent.

Do we really need to error out if a response if received for a challenge we don't have saved at the moment? What if the sender of the challenge ended up timing out the packet too aggressively and threw away its state for it? If we really need to reliability validate this, how long would the sender of the challenge need to keep this state around then?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086#pullrequestreview-92993313

---

From: erickinnear <[email-masked]>
Date: Wed, 31 Jan 2018 17:16:03 +0000 (UTC)

{{app-error-codes}}).

Ah no, sorry, this is *much* more minor: I'm referring to ordering within the document itself (although that might not be a concern at this point), which no longer matches the table above. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086#discussion_r165123248

---

From: erickinnear <[email-masked]>
Date: Wed, 31 Jan 2018 09:24:32 -0800

This is specific to address validation, I think. 
So, if you're just probing new paths for viability then you're not doing this and it's totally fine to consider those packets lost and move on. 
If you're doing address validation and the remote side cannot prove that it actually owns that address, we need to not send it anything more. 

In practice, this is determined by what role you're playing (are you the one changing addresses or are you the one seeing the remote endpoint change). 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086#discussion_r165125708

---

From: Nick Banks <[email-masked]>
Date: Wed, 31 Jan 2018 17:37:09 +0000 (UTC)

Let's imagine a client is on path A and probes path B with a challenge. The server receives this challenge and then responds with the response and a challenge of its own. Then, for some reason, that packet never makes it (too much loss, blocked in that direction, or client got disconnected). The both sides won't receive their challenge's response. The current spec text indicates both sides would immediately kill the connection on path A now. I am just questioning if that is the best course of action.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086#discussion_r165129336

---

From: MikkelFJ <[email-masked]>
Date: Wed, 31 Jan 2018 17:44:47 +0000 (UTC)

I must be missing something fundamental but ...

What is the real gain of a path challenge compared to just sending a packet on the desired path with an empty ping on a new path and see if an ACK gets through? Is to to enforce the ACK (aka path response) to follow the same path, and if so, I don't see any requirement that the path response is sent on a particular path?

Why must must the challenge be hard to guess if it happens on an encrypted channel? It would seem that the packet number with an auth tag would be sufficient, unless challenges can happen early on stream 0, which I don't think is the intention.

Is there a risk that the recipient is not cooperating, and hence the need for something unguessable? This then leans up against optimitistic ACK attacks.

Could this challenge thing be integrated with PMTU probing, considering that you need that knowledge to use the path, of course starting with the minimum size probe?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086#issuecomment-362012564

---

From: Nick Banks <[email-masked]>
Date: Wed, 31 Jan 2018 17:47:55 +0000 (UTC)

@mikkelfj As I understand it, the challenge response doesn't have to be on a particular path. The reason it needs to be hard to guess is because you are doing source address validation. You are trying to make sure the client isn't trying to dump traffic on some unsuspecting IP. If the client can guess the challenge and reply with the appropriate response on its own path, it could make the server think it does own that other IP, and start sending traffic to it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086#issuecomment-362013562

---

From: MikkelFJ <[email-masked]>
Date: Wed, 31 Jan 2018 09:49:34 -0800

OK, so the fundamental thing I was missing (which dawned after hitting return of course), is that it is not necessarily the client proping for a new path, but the server not trusting the peer to be on the path that it claims to be. So the sending a challenge is already following a return path.

@nibanks explained this while I was writing the above.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086#issuecomment-362014086

---

From: erickinnear <[email-masked]>
Date: Wed, 31 Jan 2018 18:44:26 +0000 (UTC)

This should probably be clarified in the text: I read this as only the server would be performing address validation for this example (since the client isn't seeing the server's address change) and therefore would be the only one required to kill the connection if the client cannot demonstrate that it owns the new address. 

In the scenario you mentioned, the client should be sending additional PATH_CHALLENGES when it doesn't get the response (and I think it's possible and probably a good idea for a server implementation to send a new one as well instead of waiting for the client to retransmit, if it wishes).

I agree with your general point, however -- I think we should clarify that the server must not send additional data to the new client's address rather than closing the connection as a whole. Otherwise I can trivially get the server to close your connection just by failing address validation on your behalf. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086#discussion_r165148009

---

From: Mike Bishop <[email-masked]>
Date: Wed, 31 Jan 2018 19:04:56 +0000 (UTC)

MikeBishop commented on this pull request.

Generally fine.

I think the language should be around not considering that path viable.  If that was your only path, that means you'll have to kill the connection, yes.  If you think you still have the old path but you're wrong, you'll discover that via timeout soon enough.

 If validation of the new remote address fails, after allowing enough time for
-possible loss and recovery of packets carrying PING and PONG frames, the
-endpoint MUST terminate the connection.  When setting this timer,
-implementations are cautioned that the new path could have a longer round trip
-time than the original.  The endpoint MUST NOT send a CONNECTION_CLOSE frame in
-this case; it has to assume that the remote peer does not want to receive any
-more packets.
+recovering from possible loss of packets carrying PATH_CHALLENGE and
+PATH_RESPONSE frames, the endpoint MUST terminate the connection.  When setting
+this timer, implementations are cautioned that the new path could have a longer
+round trip time than the original.  The endpoint MUST NOT send a
+CONNECTION_CLOSE frame in this case; it has to assume that the remote peer does
+not want to receive any more packets.

I'd question this piece, too.  Rather than "does not want," the implementation should be assuming that the other side *cannot* receive any more packets on the path being probed.  If you have another path, sending a CONNECTION_CLOSE or even maintaining the connection seems quite reasonable.

> @@ -1619,10 +1627,10 @@ the legitimate copy will be dropped as a duplicate.
 
 After a spurious migration, validation of the source address will fail because
 the entity at the source address does not have the necessary cryptographic keys
-to read or respond to the PING frame that is sent to it, even if it wanted to.
-Such a spurious connection migration could result in the connection being
-dropped when the source address validation fails.  This grants an attacker the
-ability to terminate the connection.
+to read or respond to the PATH_CHALLENGE frame that is sent to it, even if it
+wanted to.  Such a spurious connection migration could result in the connection
+being dropped when the source address validation fails.  This grants an attacker
+the ability to terminate the connection.

How about a recommendation to probe both old and new addresses to guard against this?

   {{app-error-codes}}).

We've already done one reorder of the document to match the table -- we'll probably need to do another as part of the grand editorial pass being discussed in a few months.

The point about PMTU is that you can send multiple PATH_CHALLENGEs on the new path in packets of different sizes and see which ones get through.  However, I'd recommend putting that in a section on probing for PMTU than making an offhand reference here.

The previous text says that the PATH_RESPONSE can be sent on any path, so currently we don't.

I think we should always acknowledge all packets.  I wouldn't be upset about including PATH_CHALLENGE/PATH_RESPONSE along with ACK in the context of "packets containing only ACKs don't trigger the sending of a ACK immediately, but are included the next time an ACK is generated."

+
+

Not minor -- you can create chaos doing this.  Ask me how I know.  😉

Defining the error code doesn't create a mandate to enforce and send it.  Implementations that know they have accounting for every PATH_CHALLENGE they've ever sent (e.g. because they've never sent any) can enforce this, while implementations which have discarded state can let an unknown PATH_RESPONSE pass without comment.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086#pullrequestreview-93038951

---

From: janaiyengar <[email-masked]>
Date: Wed, 31 Jan 2018 20:26:23 +0000 (UTC)

janaiyengar commented on this pull request.

I'll change the text, but the point here was that an ACK frame is basically useless for acknowledging receipt of a PATH_CHALLENGE frame. The entire point of this frame is to require an echo of the random bytes from the peer... if an ACK were adequate, a PING frame is enough. I don't think it matters whether the peer acks the frame or not, since the endpoint shouldn't use the received ACK as an acknowledgment. This problem exists with PING+Data as well, it just isn't stated. 

I'll change this text.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086#discussion_r165176627

---

From: janaiyengar <[email-masked]>
Date: Thu, 01 Feb 2018 01:27:19 +0000 (UTC)

High-level point: The goal of this PR is to replace PING+Data with new frames, to avoid overloaded semantics. I'd like to not fix migration bugs here, since I'd like to fix them in a separate PR (upcoming).

I don't have an opinion on size at all. I'll make it 8 bytes to avoid confusion... also because I don't think stateless operation is much of a benefit here.

-difficult to guess.

Done.

This text is the same as previous, with PING+Data. I intend to change this in the PR that addresses other migration concerns, but not here.

The strategy that I'd like to suggest is to go back to the last best path. That said, this text is the same as it was previously with PING+Data and I'd like to not change migration behavior. I'd like to change this behavior but in a different PR that fixes migration. This PR simply replaces PING+Data / PONG with new frames.

Agreed, again not changing text here for what the draft currently states, since I'd like to simply get rid of PING+Data for now. This will change with fixing the rest of migration.

   {{app-error-codes}}).

Done

Removed.

We should require PATH_RESPONSE to be sent to the same address as the PATH_CHALLENGE, though I'm open to arguments as to why not. That said, I'm not fixing migration bugs in this PR, just changing the PING+Data frame.

+
+

yup, this would not be happy. fixed.

 

Yes, good point. Filed #1091.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086#pullrequestreview-93128881

---

From: janaiyengar <[email-masked]>
Date: Thu, 01 Feb 2018 01:28:05 +0000 (UTC)

@janaiyengar pushed 1 commit.

9cc0cab  responses to comments

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086/files/d14922c84ec6d399b76c9d44b8c1d149357130b0..9cc0cabb6ad9f36c72ed605a6318f9e177efa2a2

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jan 2018 17:29:35 -0800

martinthomson commented on this pull request.

You can still do stateless in 8 bytes, I guess.  It's just a weaker authenticator.  (I think that stateless is a good strategy actually.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086#discussion_r165238319

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jan 2018 17:36:58 -0800

martinthomson approved this pull request.

Yes, let's just keep this constrained to replacement as much as possible.

I think that it would be better to keep the special handling to a minimum.  It is easier to generate a PATH_RESPONSE and send on any path than require use of the same path.  That limits the special logic to the entity that is probing.  I'm happy to keep this simple - you ACK these frames as normal and you generate the response where ever and whenever it is easiest to do so.

> +~~~
+ 0                   1                   2                   3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                                                               |
++                            Data (8)                           +
+|                                                               |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+~~~
+
+Data:
+
+: This 8-byte field contains arbitrary data.
+
+A PATH_CHALLENGE frame containing at least 8 randomly generated {{?RFC4086}}

I think that we're making this too hard.  Can we just say hard to guess?  How they are generated can be left to the challenger.  (If TCP is our benchmark, then 32 bits of entropy is probably enough.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086#pullrequestreview-93143629

---

From: janaiyengar <[email-masked]>
Date: Wed, 31 Jan 2018 17:51:47 -0800

b96bd5d  not rtt, response time

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086/files/9cc0cabb6ad9f36c72ed605a6318f9e177efa2a2..b96bd5dbe9a4d43133df592819dedeaa2d083f6c

---

From: janaiyengar <[email-masked]>
Date: Thu, 01 Feb 2018 02:05:13 +0000 (UTC)

5c3c0d6  hard to guess

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086/files/b96bd5dbe9a4d43133df592819dedeaa2d083f6c..5c3c0d6e32c1178260d46b09f125095824d0bd8f

---

From: janaiyengar <[email-masked]>
Date: Thu, 01 Feb 2018 02:08:01 +0000 (UTC)

+ 0                   1                   2                   3

SGTM. I kept futzing around with saying the right thing, and it's probably adequate to say "hard to guess". Done.

Again, not for this PR, but the idea would be to demonstrate two way reachability using PATH_CHALLENGE and PATH_RESPONSE. Otherwise, you may end up in a situation where, for instance, UDP packets are blocked on one direction, but migration happens anyways since PATH_RESPONSE was sent from an address which didn't block UDP packets.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086#discussion_r165242122

---

From: janaiyengar <[email-masked]>
Date: Thu, 01 Feb 2018 02:12:51 +0000 (UTC)

4c470d8  fix broken refs

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1086/files/5c3c0d6e32c1178260d46b09f125095824d0bd8f..4c470d89681c8bd961c2bc85647049fcb4e4b160