Subject: [quicwg/base-drafts] Curtail CONNECTION_CLOSE for small Initial (#3292)

From: Martin Thomson <[email-masked]>
Date: Sun, 08 Dec 2019 20:08:34 -0800

This is trickier than I had imagined.  Sending CONNECTION_CLOSE is
probably fine, but it&#39;s harder to do this correctly now.  You can&#39;t just
send an unauthenticated CONNECTION_CLOSE because that might disrupt a
real connection.  So there are two goals in tension:

1. Don&#39;t kill an active connection (attempt) unnecessarily.

2. Provide feedback about errors.

The observation is that an attacker can disrupt connections by eliciting
a CONNECTION_CLOSE, so feedback naturally leads to an exposure to a DoS
attack.  That&#39;s unfortunate, but we have established that we don&#39;t care
about DoS by an on-path attacker prior to handshake completion.
Anything we do here has got to be best effort.

DoS prevention would say that you just discard junk, and that is
probably the right answer.  But we have a number of cases where the
robustness of the system depends on getting feedback.

Either way, we agreed to allow CONNECTION_CLOSE in Initial, so the
exposure exists anyway.  So this contains advice.  Maybe too much
advice, but I thought that I&#39;d see what people thought.

Closes #3269.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Curtail CONNECTION_CLOSE for small Initial

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3292.patch
https://github.com/quicwg/base-drafts/pull/3292.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/3292

---

From: Nick Banks <[email-masked]>
Date: Mon, 09 Dec 2019 07:00:56 -0800

nibanks approved this pull request.

-- 
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/3292#pullrequestreview-328981872

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 09 Dec 2019 07:41:11 -0800

kazuho commented on this pull request.

> @@ -3476,10 +3485,12 @@ Datagrams containing Initial packets MAY exceed 1200 bytes if the client
 believes that the Path Maximum Transmission Unit (PMTU) supports the size that
 it chooses.
 
-A server MAY send a CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION in
-response to an Initial packet it receives from a client if the UDP datagram is
-smaller than 1200 bytes. It MUST NOT send any other frame type in response, or
-otherwise behave as if any part of the offending packet was processed as valid.
+A server that has no existing state for a connection MUST discard an Initial
+packet that is carried in a UDP datagram that is smaller than 1200 bytes.  Other
+packets in the datagram SHOULD also be discarded.  A server MAY send a
+CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION in addition to
+discarding a packet if that does not affect a connection for which the server
+has established state; see {{immediate-close}}.

I am confused by the last sentence. Is it saying that when a server receives a small Initial packet for a connection for which it already has state, the server MAY send a PROTOCOL_VIOLATION, but it must retain the state for that connection? Assuming that is the case, I wonder if there is a value in having such a requirement. I am not sure if there is a case such a behavior helps us mitigate attacks.

-- 
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/3292#pullrequestreview-329012409

---

From: Nick Banks <[email-masked]>
Date: Mon, 09 Dec 2019 07:47:16 -0800

nibanks commented on this pull request.

My understanding was essentially that it's OK for the server to send PROTOCOL_VIOLATION in response to an Initial for which there isn't connection state already (i.e. the first Initial packet for a connection); because that means it couldn't affect a pre-existing connection.

-- 
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/3292#discussion_r355524536

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 09 Dec 2019 07:52:26 -0800

Yeah if we interpret the last sentence that way, I think it would contradict with the "MUST discard" in the first sentence?

-- 
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/3292#discussion_r355527505

---

From: ianswett <[email-masked]>
Date: Mon, 09 Dec 2019 08:56:29 -0800

ianswett commented on this pull request.

LG, some comments

> @@ -2486,7 +2486,16 @@ A client will always know whether the server has Handshake keys
 whether the client has Handshake keys.  Under these circumstances, a server
 SHOULD send a CONNECTION_CLOSE frame in both Handshake and Initial packets
 to ensure that at least one of them is processable by the client.  These
-packets can be coalesced into a single UDP datagram (see {{packet-coalesce}}).
+packets can be coalesced into a single UDP datagram; see {{packet-coalesce}}.

Re-reading this paragraph I realize it needs an update for the new timing of discarding Handshake on the server side, because it means a client may want to send a CONNECTION_CLOSE in both Handshake and 1-RTT.

> @@ -2486,7 +2486,16 @@ A client will always know whether the server has Handshake keys
 whether the client has Handshake keys.  Under these circumstances, a server
 SHOULD send a CONNECTION_CLOSE frame in both Handshake and Initial packets
 to ensure that at least one of them is processable by the client.  These
-packets can be coalesced into a single UDP datagram (see {{packet-coalesce}}).
+packets can be coalesced into a single UDP datagram; see {{packet-coalesce}}.
+
+A CONNECTION_CLOSE frame that is sent in an Initial packet in response to
+unauthenticated information - the content of Initial or Handshake packets
+primarily - might result in denial of service for a legitimate connection.  QUIC
+does not include defensive measures for on-path attacks during the handshake
+(see {{handshake-dos}}). However, at the cost of reducing feedback about errors
+for legitimate peers, some forms of denial of service can be made more difficult
+for an attacker if endpoints discard illegal packets rather than terminating a

Is it worth re-stating that the client address can't change during the handshake, so Initial and Handshake packets from a different address can be immediately discarded?

I didn't realize we had text in here that allowed this.  I think we're better off with always dropping <1200 byte packets, personally, and keeping the MUST you added 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/3292#pullrequestreview-329066507

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 09 Dec 2019 14:16:58 -0800

janaiyengar commented on this pull request.

Editorial comment: break this sentence. Suggestion: "A CONNECTION_CLOSE frame might be sent in an Initial packet or in response to unauthenticated information received in Initial or Handshake packets. Such a response might result in a denial of service for a legitimate connection."

I'm confused here too. What does it mean to not affect the connection if the server just sent out a CONNECTION_CLOSE for it?

I am in agreement with @ianswett : perhaps it's best to recommend dropping the connection and not send anything in response. This is a simple enough error for a client to avoid.

-- 
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/3292#pullrequestreview-329283380

---

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Dec 2019 15:38:39 -0800

martinthomson commented on this pull request.

The problem I'm trying to finesse around here is one where the server gets a partial ClientHello in an Initial.  That is processed and held.  The next packet is a small Initial.  The server should discard that *without* generating a CONNECTION_CLOSE or it will disrupt the in-progress connection establishment.

-- 
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/3292#discussion_r355744776

---

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Dec 2019 15:44:47 -0800

#3293

-- 
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/3292#discussion_r355746544

---

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Dec 2019 15:51:27 -0800

Good idea, but I'll add that elsewhere.

-- 
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/3292#discussion_r355748430

---

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Dec 2019 15:54:37 -0800

@martinthomson pushed 2 commits.

ffa7f98abc53f92a0e98fe927e65cea492736e4c  Add point about off-path packets to handshake DoS section
173d00664bd9c547cd042401621e80bed802e7dc  Reword

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3292/files/6f9f8d7ffca4eed3373bb9f64261f85fd5f76b1a..173d00664bd9c547cd042401621e80bed802e7dc

---

From: ianswett <[email-masked]>
Date: Mon, 09 Dec 2019 16:15:52 -0800

My understanding is that the server should discard that packet because it's not 1200 bytes and it has no state for the connection?

-- 
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/3292#discussion_r355758006

---

From: ianswett <[email-masked]>
Date: Mon, 09 Dec 2019 16:16:11 -0800

thx

-- 
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/3292#discussion_r355758235

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 09 Dec 2019 16:19:10 -0800

@martinthomson Thank you for the clarification.

I think there are three possible behaviors in such a situation:
* immediate-close the connection with PROTOCOL_VIOLATION
* discard the small Initial
* discard the small Initial, send PROTOCOL_VIOLATION, without affecting the connection state

I think that either of the first two makes sense.

However, the third one (which IIUC is what the text suggests) does not. This is because sending PROTOCOL_VIOLATION will instruct the client to discard *its* connection state, regardless of the sender of the small Initial packet being the client or an attacker. There is no point in the server retaining the connection state after sending PROTOCOL_VIOLATION.

Therefore, I think that the advice should be: SHOULD discard, MAY immediate-close.

-- 
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/3292#discussion_r355760171

---

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Dec 2019 16:32:49 -0800

@kazuho, I agree with you about the first two.  The rule I'm proposing is MUST discard, but MAY immediate-close in addition IF that won't affect state the server holds.  Yes, that might affect state the client holds (but the server does not), but that's a risk the server takes.  It's a trade-off about the level of feedback the server wants to provide vs. the risk of DoS that the server has to make.

Are we agreeing violently, but talking about how to phrase the recommendation to not immediate-close?

-- 
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/3292#discussion_r355769506

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 09 Dec 2019 17:12:34 -0800

@martinthomson 
> The rule I'm proposing is MUST discard, but MAY immediate-close in addition IF that won't affect state the server holds.

I think we might have confusion in what "immediate-close" means? My understanding is that "immediate-close" is an action that affects state. It is defined as entering the closing state, then draining state. If the intention is to suggest that a server might send PROTOCOL_VIOLATION without affecting the connection state, then it is confusing to use the term "immediate-close."

That said, what I stated in [my comment right above](https://github.com/quicwg/base-drafts/pull/3292#discussion_r355760171) is that I think a state-*ful* "immediate-close" is fine, but sending PROTOCOL_VIOLATION without affecting connection state does not make sense.

-- 
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/3292#discussion_r355796345

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 09 Dec 2019 17:38:06 -0800

We've now unfortunately lost this comment in the diffs :-/ But that was my confusion too -- sending CONNECTION_CLOSE changes state. I don't understand what it means to send PROTOCOL_VIOLATION without affecting state.

-- 
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/3292#discussion_r355805083

---

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Dec 2019 20:08:43 -0800

Let's see if I can keep this thread alive.  This is sending a packet with a CONNECTION_CLOSE, not an immediate close (I was under the impression that the shorthand was OK here, but it was clearly a mistake).  The goal is to use CONNECTION_CLOSE as a signal only, with the intent of triggering the corresponding logic at the client.  But the server is discarding this packet and so it won't have any connection state.  This won't result in creation or destruction of server state.

-- 
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/3292#discussion_r355835905

---

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Dec 2019 20:11:05 -0800

@martinthomson pushed 1 commit.

a2f06723986f303023c8fcfc8bd9c3a5ddb5368c  Does this help?

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3292/files/173d00664bd9c547cd042401621e80bed802e7dc..a2f06723986f303023c8fcfc8bd9c3a5ddb5368c

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 09 Dec 2019 22:47:39 -0800

> The goal is to use CONNECTION_CLOSE as a signal only, with the intent of triggering the corresponding logic at the client.

I think it is not a bad idea to have a MAY for that.

> But the server is discarding this packet and so it won't have any connection state. This won't result in creation or destruction of server state.

I do not think that the sentences reflect what you think. Quoted below are the last two sentences of this paragraph. It is my understanding that the intention of the last sentence is to clarify the rationale behind the previous sentence, but as you can see from the emphasized text, they are discussing about different conditions.

> _A server MAY send a CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION in addition to discarding a packet if that does not affect **a connection for which the server has previously established state**.  Sending CONNECTION_CLOSE will not affect server state in the same way as an immediate close ({{immediate-close}}) **as the server has no state**, but it will cause any client to terminate a connection attempt._

I think what we actually want to state is something like:  _A server that has no existing state for a connection MUST discard an Initial packet that is carried in a UDP datagram that is smaller than 1200 bytes.  Other packets in that datagram SHOULD also be discarded. In addition to discarding the packet, a server MAY respond with a CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION, without creating state. When a server receives such an Initial packet for which it already has connection state, it MUST either drop that packet or close the connection with error code PROTOCOL_VIOLATION ({{immediate-close}})._

-- 
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/3292#discussion_r355866386

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Dec 2019 15:13:05 -0800

@martinthomson pushed 4 commits.

e8cc9063bd9053b4bc7fb46649500fe8d9520d19  CONNECTION_CLOSE in Handshake too
dd930535c23477ae0251a4f8b5341267f1d7d44b  ...and 1-RTT too
c23f017912428481d583414e1cef97e5d707d542  Merge pull request #3293 from quicwg/close-in-handshake
e99cd67f95601f37b2b6930f28693b7d3a1044aa  Merge branch 'master' into close-small-initial

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3292/files/a2f06723986f303023c8fcfc8bd9c3a5ddb5368c..e99cd67f95601f37b2b6930f28693b7d3a1044aa

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Dec 2019 18:46:08 -0800

f302f3ec69913684ce35c61df7fb0fd9a461e3bf  Stateless immediate close

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3292/files/e99cd67f95601f37b2b6930f28693b7d3a1044aa..f302f3ec69913684ce35c61df7fb0fd9a461e3bf

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 10 Dec 2019 19:22:04 -0800

janaiyengar approved this pull request.

A few editorial suggestions, but this looks good to me now.

> @@ -3479,10 +3498,10 @@ Datagrams containing Initial packets MAY exceed 1200 bytes if the client
 
-A server MAY send a CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION in
-response to an Initial packet it receives from a client if the UDP datagram is
-smaller than 1200 bytes. It MUST NOT send any other frame type in response, or
-otherwise behave as if any part of the offending packet was processed as valid.
+A server MUST discard an Initial packet that is carried in a UDP datagram that
+is smaller than 1200 bytes.  A server MAY also immediately close the connection
+by sending a CONNECTION_CLOSE frame with an error code of PROTOCOL_VIOLATION;
+see {{immediate-close}}.

```suggestion
see {{immediate-close-hs}}.
```

> @@ -2491,6 +2494,22 @@ Handshake and 1-RTT packets prior to confirming the handshake; see Section 4.1.2
 of {{QUIC-TLS}}.  These packets can be coalesced into a single UDP datagram; see
 {{packet-coalesce}}.
 
+A CONNECTION_CLOSE frame might be sent in an Initial packet or in response to

```suggestion
An endpoint might send a CONNECTION_CLOSE frame in an Initial packet or in response to
```

> @@ -2491,6 +2494,22 @@ Handshake and 1-RTT packets prior to confirming the handshake; see Section 4.1.2
 of {{QUIC-TLS}}.  These packets can be coalesced into a single UDP datagram; see
 {{packet-coalesce}}.
 
+A CONNECTION_CLOSE frame might be sent in an Initial packet or in response to
+unauthenticated information received in Initial or Handshake packets.  An

```suggestion
unauthenticated information received in Initial or Handshake packets.
```

> @@ -2491,6 +2494,22 @@ Handshake and 1-RTT packets prior to confirming the handshake; see Section 4.1.2
 of {{QUIC-TLS}}.  These packets can be coalesced into a single UDP datagram; see
 {{packet-coalesce}}.
 
+A CONNECTION_CLOSE frame might be sent in an Initial packet or in response to
+unauthenticated information received in Initial or Handshake packets.  An
+immediate close in response might result in a denial of service for a legitimate

```suggestion
Such an immediate close might expose legitimate connections to a denial of service.
```

> @@ -2491,6 +2494,22 @@ Handshake and 1-RTT packets prior to confirming the handshake; see Section 4.1.2
 of {{QUIC-TLS}}.  These packets can be coalesced into a single UDP datagram; see
 {{packet-coalesce}}.
 
+A CONNECTION_CLOSE frame might be sent in an Initial packet or in response to
+unauthenticated information received in Initial or Handshake packets.  An
+immediate close in response might result in a denial of service for a legitimate
+connection.  QUIC does not include defensive measures for on-path attacks during

```suggestion
QUIC does not include defensive measures for on-path attacks during
```

> @@ -2491,6 +2494,22 @@ Handshake and 1-RTT packets prior to confirming the handshake; see Section 4.1.2
 of {{QUIC-TLS}}.  These packets can be coalesced into a single UDP datagram; see
 {{packet-coalesce}}.
 
+A CONNECTION_CLOSE frame might be sent in an Initial packet or in response to
+unauthenticated information received in Initial or Handshake packets.  An
+immediate close in response might result in a denial of service for a legitimate
+connection.  QUIC does not include defensive measures for on-path attacks during
+the handshake; see {{handshake-dos}}.  However, at the cost of reducing feedback
+about errors for legitimate peers, some forms of denial of service can be made
+more difficult for an attacker if endpoints discard illegal packets rather than
+terminating a connection with CONNECTION_CLOSE.  For this reason, endpoints MAY
+discard packets rather than immediately close if errors are detected in packets
+that lack authentication.
+
+An endpoint that has not established state, such as a server that detects an
+error in an Initial packet, does not enter the closing state.  An endpoint that
+has no state for the connection sends a CONNECTION_CLOSE frame without entering

```suggestion
has no state for the connection does not enter a closing or draining period
```

> @@ -2491,6 +2494,22 @@ Handshake and 1-RTT packets prior to confirming the handshake; see Section 4.1.2
 of {{QUIC-TLS}}.  These packets can be coalesced into a single UDP datagram; see
 {{packet-coalesce}}.
 
+A CONNECTION_CLOSE frame might be sent in an Initial packet or in response to
+unauthenticated information received in Initial or Handshake packets.  An
+immediate close in response might result in a denial of service for a legitimate
+connection.  QUIC does not include defensive measures for on-path attacks during
+the handshake; see {{handshake-dos}}.  However, at the cost of reducing feedback
+about errors for legitimate peers, some forms of denial of service can be made
+more difficult for an attacker if endpoints discard illegal packets rather than
+terminating a connection with CONNECTION_CLOSE.  For this reason, endpoints MAY
+discard packets rather than immediately close if errors are detected in packets
+that lack authentication.
+
+An endpoint that has not established state, such as a server that detects an
+error in an Initial packet, does not enter the closing state.  An endpoint that
+has no state for the connection sends a CONNECTION_CLOSE frame without entering
+a closing or draining period.

```suggestion
on sending a CONNECTION_CLOSE frame.
```

-- 
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/3292#pullrequestreview-330277488

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Dec 2019 19:41:28 -0800

7864bda6e4dd98d9e033ce49be4350d849b7f361  Rewording suggestions

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3292/files/f302f3ec69913684ce35c61df7fb0fd9a461e3bf..7864bda6e4dd98d9e033ce49be4350d849b7f361

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Dec 2019 19:43:41 -0800

47228989491e2cdf3606c5d9745c43fb8aac2afd  Rewrap

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3292/files/7864bda6e4dd98d9e033ce49be4350d849b7f361..47228989491e2cdf3606c5d9745c43fb8aac2afd

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 10 Dec 2019 19:53:23 -0800

kazuho approved this pull request.

LGTM modulo the editorial concerns below.

> @@ -5759,11 +5778,15 @@ During the creation of a connection, QUIC only provides protection against
 attack from off the network path.  All QUIC packets contain proof that the
 recipient saw a preceding packet from its peer.
 
-The first mechanism used is the source and destination connection IDs, which are
-required to match those set by a peer.  Except for an Initial and stateless
-reset packets, an endpoint only accepts packets that include a destination
-connection that matches a connection ID the endpoint previously chose.  This is
-the only protection offered for Version Negotiation packets.
+Addresses cannot change during the handshake, so endpoints can discard packets
+that are received on a different network path.
+
+The source and destination connection IDs are the primary means of protection
+against off-path attack during the handshake.  These are required to match those
+set by a peer.  Except for an Initial and stateless reset packets, an endpoint
+only accepts packets that include a destination connection that matches a

s/a destination connection/a Destination Connection ID/

> @@ -5759,11 +5778,15 @@ During the creation of a connection, QUIC only provides protection against
 attack from off the network path.  All QUIC packets contain proof that the
 recipient saw a preceding packet from its peer.
 
-The first mechanism used is the source and destination connection IDs, which are
-required to match those set by a peer.  Except for an Initial and stateless
-reset packets, an endpoint only accepts packets that include a destination
-connection that matches a connection ID the endpoint previously chose.  This is
-the only protection offered for Version Negotiation packets.
+Addresses cannot change during the handshake, so endpoints can discard packets
+that are received on a different network path.
+
+The source and destination connection IDs are the primary means of protection

s/source and destination connection IDs/Source and Destination Connection IDs/

It is my understanding is that we use CamelCase for these terms.

-- 
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/3292#pullrequestreview-330285308

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Dec 2019 20:00:58 -0800

6971443498f64d31ec7bebeadfe2215e21c4b19a  Refer to fields properly

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3292/files/47228989491e2cdf3606c5d9745c43fb8aac2afd..6971443498f64d31ec7bebeadfe2215e21c4b19a

---

From: Mike Bishop <[email-masked]>
Date: Wed, 11 Dec 2019 09:05:35 -0800

MikeBishop commented on this pull request.

We might have gotten sloppy on the distinction, but I believe in most places we capitalize the field names, but lower-case the concepts.

-- 
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/3292#discussion_r356722309

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Dec 2019 15:44:54 -0800

Yup.  I don't think that we have the concept of a "destination connection ID" separate from the field though, so I am now referring to the fields directly.

-- 
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/3292#discussion_r356894635

---

From: ianswett <[email-masked]>
Date: Thu, 12 Dec 2019 11:22:34 -0800

ianswett approved this pull request.

-- 
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/3292#pullrequestreview-331466532