Question:
Capsule design team output. Minimal changes to HTTP/3, which was already using capsules and is now joined by . Same content as draft PR, thank you to those who have already reviewed!
Does this actually with a no-op, or are we supposed to discuss that at 115? Otherwise LGTM.
It as a no-op with the exception of one bullet point that we did want to address, that got split out into , which we'll discuss at 115 separately from this PR.
Should the protocol share framing semantics with the HTTP/2 draft so that it is easy/easier to take datagrams or streams and put them on the CONNECT stream? Should it be possible to use that mechanism, or should it instead be forbidden? As much as possible, it would be desirable to have the forwarding logic be fairly uniform across different protocol versions. Right now, we have two almost completely different protocols.
I was discussing this with NAME and NAME What happens when an H3 WT server receives "version independent" WT framing on its CONNECT stream. Since WT over H3 requires H3 datagrams, then there is no need to fold datagrams into the CONNECT stream. There shouldn't be a need to fold streams either, unless you want to defeat QUIC stream limits :) Allowing this would also increase work to implement an H3 only WT client/server: you have to re-implement QUIC over an HTTP byte-stream just in case the peer decides to send you "version independent" WT. Right now I think they are totally different and never the twain shall meet. Proxies can convert between the two versions. If we did that, should we have different upgrade tokens?
Is this issue still relevant now that we have the outcome of HTTP Datagram Design Team?
NAME gentle ping
Actually never mind, this is blocked on the capsule design team - the output of that design team will decide on whether the h2 capsules are allowed in h3 or not
The H3 draft by its nature allows for the parallel processing of multiple WT sessions and also the intermixing of normal H3 request with WT. Server endpoints may wish to negotiate or disable this behavior. Clients can simply choose not to do either kind of pooling if they don't want to. There's already a PR open () with a design idea.
I'd like to propose a different model than the one in : The server sends the maximum WebTransport Session ID, or since 0 is a valid value, it's really the minimum invalid WebTransport Session ID. To indicate WT is not supported, server sends 0. To allow for only 1 session ever, server sends 4, and never updates it. To allow for only 1 session at a time, server sends 4, and updates it by 4 as each session closes/resets. To allow for N parallel sessions, server sends 4 * N. and updates as sessions close/reset. This mirrors H3 PUSH, and requires at least one more frame (MAXWTSESSIONID). Perhaps it would also require CANCELWT_SESSION? A client need only declare that it supports webtransport, and even that could be optional. The server will know if it receives a CONNECT with :protocol=webtransport.
I wanted to have a negotiation mechanism in , but my conclusion after talking with NAME about it was that we should not do negotiation, and servers should just reject extra streams with a 400 (or maybe even a RESET_STREAM) if they ever see more sessions than they expect; meaning it's on the clients to know if they can pool or not.
Though we may want a more specific 4XX error code so the client knows it should retry in a non-pooled connection
That's certainly a lot simpler than session credits ;) The cost of at least an RTT for a client that tries to pool against a server that can't handle it seems somewhat high. I guess it depends what the common client pooling strategies are and how many servers don't support pooling.
NAME since it's looking like the JavaScript API will provide a way to disable pooling, I expect that the scenario of pooling-attempted-but-rejected will be quite rare, so a round trip cost should be acceptable
I'm also considering use cases for WT which are not tied to the JS API.
NAME that's interesting - and those use-cases won't have a similar mechanism to disable pooling? I suspect they'll need a way to get the WT server's hostname somehow, and having config properties attached to that (such as disable_pooling) could be useful?
NAME : the opposite -- the clients may attempt pooling to servers that might or might not support it. You can't tell from a hostname if it supports pooling.
NAME how did the client get the hostname in the first place? I'm suggesting to carry pooling_support next to that.
Actually, let's go back to JS for a second. The people who write JS at Facebook are very unlikely to know if the edge server terminating their connection supports pooling, or that configuration could change over time.
(I appreciate the irony of me saying this as a Googler, but) should the JS people talk to the edge people? I agree that this shouldn't fail, but it being inefficient seems reasonable - these teams should talk if they're trying to reach good performance.
I think my main problem with is that most people who want to disallow pooling want to exclude not only other WebTransport sessions, but also general HTTP traffic. was written with that assumption in mind.
Ok, MAXWTSESSION_ID doesn't handle that case, so it may be an over-engineered solution to the wrong problem.
As I said in the meeting, I don't think that we should have any signals for dedicated connections from either client or server. Yutaka made the point that the client can decide to make a connection dedicated after seeing the server settings. It doesn't need to signal its intent (and signaling would have negative privacy consequences potentially). I agree with this observation. A server needs to support HTTP if we're using HTTP. So pooling with h3 is already a settled matter. If the server doesn't want to answer requests, it can use 406 or 421 or other HTTP mechanisms to tell the client to go away. More generally, the server can just not provide links to that server, such that it might have to respond to GET/OPTIONS/POST/etc. The question then becomes managing resource limits on the server. Having a way to limit the number of WebTransport sessions is a good thing and I believe that will be sufficient for this. Thus, I'm a supporter of option 3: MAXWTSESSIONS or similar.
I agree that we should have limits of how many WT can be active at the same time on a connection. It should also define what happens if the limit is exceeded. Should a client open another QUIC connection to the same server or should it fail? Probably it should be former, but that should also have limits defined (6 parallel QUIC connection, may be too much? HTTP/1.1 have the 6 parallel connection limit).
Chair: discussed at IETF 113, consensus in room to change the WT SETTING to carry the number of concurrent WT sessions allowed on this h3 connection
Note that all of the below works when you swap "server" and "client". I wanted to focus on a poor Javascript client implementation, but it's equally possible to run into these cases with a poor server implementation. Let's say that you have a Http3Transport session that shares a connection with HTTP/3 or another Http3Transport session. The client has limited buffer space and hypothetically advertises MAXDATA of 1MB for the connection. If the server pushes 1MB of unprocessed data over a Http3Transport session, then it will prevent the server from sending data over the connection, including HTTP/3 responses and other Http3Transport sessions. This can occur if the application does not accept all remote-created streams or does not fully read every stream. This will be VERY easy for a developer to mess up. It can also occur if the application can not process data faster than it is received. In my case, the server creates unidirectional streams and pushes a large amount of media over them. The flow control limit would be hit if the Javascript application: Only accepts bidirectional streams (ex. initialization) Does not accept a unidirectional stream (ex. error or teardown) Does not fully read or abort every stream (ex. parsing error) Is not able to parse the media fast enough (ex. underpowered). This is mostly intended behavior, otherwise these "bugs" would cause unbounded memory usage. However, the blast radius is bigger when sharing a connection. In my use-case, hitting the flow control limit would also block any HTTP/3 RPC calls or unrelated traffic on the connection. This introduces more scenarios for the connection to become deadlocked or generally stalled. HTTP/3 implementations use MAXSTREAMS to limit the number of simultaneous requests. This use-case no longer works when sharing a connection with a Http3Transport session, and HTTP/3 implementations must instead return explicit error status codes when this threshold is reached. The same issues with MAXDATA also apply to MAXSTREAMS. A Javascript application that fails to accept or read/abort every stream will consume flow control resources. This can manifest itself in strange ways, such as HTTP/3 being unable to create control streams, or simply being unable to create new request streams.
Thanks for the salient overview, it makes it easier to understand your concerns. My first comment would be that some of these points apply to QuicTransport too. Its just that their made worse by Http3Transport pooling allowing the mashing together of orthogonal protocols with no application-layer oversight. Just as you might interfere with a page load, a browser could easily interfere with your finely crafted application protocol. I would anticipate that, due to different browsers having different HTTP usage patterns, and different pages being composed differently by time, region, etc, one might find that Http3Transport apps subject to pooling would experience inconsistencies and transient issues. You rightly point out that the connection flow control is a shared resource. But the problems described seem to relate to stream flow control and overlooks the different flow control setting afforded by the Transport Parameters. A possible mitigation is to more tightly constrain the initial flow windows of server-initiated streams so that they can't interfere with requests. However, I still think that the notion of pooling together WebTransports in an uncoordinated fashion is going to manifest undesirable properties. The MAX_STREAMS observation is a good one. I think the competition between request streams and client bidirectional streams is going to be hard to resolve.
Yeah, and enforcing any per sort of per-session flow control might get difficult because you can only identify the protocol and session after you receive the first few bytes of each stream. For example, assume a brand new connection (for simplicity only) and you receive a STREAM frame with id=100, offset=16, and size=1000. You don't know yet which protocol or session created this stream or the 25 preceding it. And hopefully you eventually get those first few bytes for each stream...
Chair notes from IETF 112 meeting: this needs more discussion (on the issue or mailing list)
Chair: discussed at 113, consensus in room to: use a setting to limit number of WT sessions (see ) figure out MAXSTREAMS, a way to limit the number of streams within a session abandon MAXDATA as too hard, do not limit amount of data sent within a session (anyone can open a new issue to revisit this discussion if they have a concrete proposal on how to do this) let QUIC take care of MAXSTREAMDATA
Capsule DT is doing all of the above bullet points except the second one, for which I opened . Apologies for the extremely delayed response here, but hearing no objections we are declaring consensus and merging the PRs. David David Schinazi wrote:

8.2. <del> The following entry is added to the "HTTP/3 Settings" registry </del> <ins> The following entries are added to the "HTTP/3 Settings" registry </ins> established by HTTP3: The "SETTINGS_ENABLE_WEBTRANSPORT" parameter indicates that the


Question:
Capsule design team output. Minimal changes to HTTP/3, which was already using capsules and is now joined by . Same content as draft PR, thank you to those who have already reviewed!
Does this actually with a no-op, or are we supposed to discuss that at 115? Otherwise LGTM.
It as a no-op with the exception of one bullet point that we did want to address, that got split out into , which we'll discuss at 115 separately from this PR.
Should the protocol share framing semantics with the HTTP/2 draft so that it is easy/easier to take datagrams or streams and put them on the CONNECT stream? Should it be possible to use that mechanism, or should it instead be forbidden? As much as possible, it would be desirable to have the forwarding logic be fairly uniform across different protocol versions. Right now, we have two almost completely different protocols.
I was discussing this with NAME and NAME What happens when an H3 WT server receives "version independent" WT framing on its CONNECT stream. Since WT over H3 requires H3 datagrams, then there is no need to fold datagrams into the CONNECT stream. There shouldn't be a need to fold streams either, unless you want to defeat QUIC stream limits :) Allowing this would also increase work to implement an H3 only WT client/server: you have to re-implement QUIC over an HTTP byte-stream just in case the peer decides to send you "version independent" WT. Right now I think they are totally different and never the twain shall meet. Proxies can convert between the two versions. If we did that, should we have different upgrade tokens?
Is this issue still relevant now that we have the outcome of HTTP Datagram Design Team?
NAME gentle ping
Actually never mind, this is blocked on the capsule design team - the output of that design team will decide on whether the h2 capsules are allowed in h3 or not
The H3 draft by its nature allows for the parallel processing of multiple WT sessions and also the intermixing of normal H3 request with WT. Server endpoints may wish to negotiate or disable this behavior. Clients can simply choose not to do either kind of pooling if they don't want to. There's already a PR open () with a design idea.
I'd like to propose a different model than the one in : The server sends the maximum WebTransport Session ID, or since 0 is a valid value, it's really the minimum invalid WebTransport Session ID. To indicate WT is not supported, server sends 0. To allow for only 1 session ever, server sends 4, and never updates it. To allow for only 1 session at a time, server sends 4, and updates it by 4 as each session closes/resets. To allow for N parallel sessions, server sends 4 * N. and updates as sessions close/reset. This mirrors H3 PUSH, and requires at least one more frame (MAXWTSESSIONID). Perhaps it would also require CANCELWT_SESSION? A client need only declare that it supports webtransport, and even that could be optional. The server will know if it receives a CONNECT with :protocol=webtransport.
I wanted to have a negotiation mechanism in , but my conclusion after talking with NAME about it was that we should not do negotiation, and servers should just reject extra streams with a 400 (or maybe even a RESET_STREAM) if they ever see more sessions than they expect; meaning it's on the clients to know if they can pool or not.
Though we may want a more specific 4XX error code so the client knows it should retry in a non-pooled connection
That's certainly a lot simpler than session credits ;) The cost of at least an RTT for a client that tries to pool against a server that can't handle it seems somewhat high. I guess it depends what the common client pooling strategies are and how many servers don't support pooling.
NAME since it's looking like the JavaScript API will provide a way to disable pooling, I expect that the scenario of pooling-attempted-but-rejected will be quite rare, so a round trip cost should be acceptable
I'm also considering use cases for WT which are not tied to the JS API.
NAME that's interesting - and those use-cases won't have a similar mechanism to disable pooling? I suspect they'll need a way to get the WT server's hostname somehow, and having config properties attached to that (such as disable_pooling) could be useful?
NAME : the opposite -- the clients may attempt pooling to servers that might or might not support it. You can't tell from a hostname if it supports pooling.
NAME how did the client get the hostname in the first place? I'm suggesting to carry pooling_support next to that.
Actually, let's go back to JS for a second. The people who write JS at Facebook are very unlikely to know if the edge server terminating their connection supports pooling, or that configuration could change over time.
(I appreciate the irony of me saying this as a Googler, but) should the JS people talk to the edge people? I agree that this shouldn't fail, but it being inefficient seems reasonable - these teams should talk if they're trying to reach good performance.
I think my main problem with is that most people who want to disallow pooling want to exclude not only other WebTransport sessions, but also general HTTP traffic. was written with that assumption in mind.
Ok, MAXWTSESSION_ID doesn't handle that case, so it may be an over-engineered solution to the wrong problem.
As I said in the meeting, I don't think that we should have any signals for dedicated connections from either client or server. Yutaka made the point that the client can decide to make a connection dedicated after seeing the server settings. It doesn't need to signal its intent (and signaling would have negative privacy consequences potentially). I agree with this observation. A server needs to support HTTP if we're using HTTP. So pooling with h3 is already a settled matter. If the server doesn't want to answer requests, it can use 406 or 421 or other HTTP mechanisms to tell the client to go away. More generally, the server can just not provide links to that server, such that it might have to respond to GET/OPTIONS/POST/etc. The question then becomes managing resource limits on the server. Having a way to limit the number of WebTransport sessions is a good thing and I believe that will be sufficient for this. Thus, I'm a supporter of option 3: MAXWTSESSIONS or similar.
I agree that we should have limits of how many WT can be active at the same time on a connection. It should also define what happens if the limit is exceeded. Should a client open another QUIC connection to the same server or should it fail? Probably it should be former, but that should also have limits defined (6 parallel QUIC connection, may be too much? HTTP/1.1 have the 6 parallel connection limit).
Chair: discussed at IETF 113, consensus in room to change the WT SETTING to carry the number of concurrent WT sessions allowed on this h3 connection
Note that all of the below works when you swap "server" and "client". I wanted to focus on a poor Javascript client implementation, but it's equally possible to run into these cases with a poor server implementation. Let's say that you have a Http3Transport session that shares a connection with HTTP/3 or another Http3Transport session. The client has limited buffer space and hypothetically advertises MAXDATA of 1MB for the connection. If the server pushes 1MB of unprocessed data over a Http3Transport session, then it will prevent the server from sending data over the connection, including HTTP/3 responses and other Http3Transport sessions. This can occur if the application does not accept all remote-created streams or does not fully read every stream. This will be VERY easy for a developer to mess up. It can also occur if the application can not process data faster than it is received. In my case, the server creates unidirectional streams and pushes a large amount of media over them. The flow control limit would be hit if the Javascript application: Only accepts bidirectional streams (ex. initialization) Does not accept a unidirectional stream (ex. error or teardown) Does not fully read or abort every stream (ex. parsing error) Is not able to parse the media fast enough (ex. underpowered). This is mostly intended behavior, otherwise these "bugs" would cause unbounded memory usage. However, the blast radius is bigger when sharing a connection. In my use-case, hitting the flow control limit would also block any HTTP/3 RPC calls or unrelated traffic on the connection. This introduces more scenarios for the connection to become deadlocked or generally stalled. HTTP/3 implementations use MAXSTREAMS to limit the number of simultaneous requests. This use-case no longer works when sharing a connection with a Http3Transport session, and HTTP/3 implementations must instead return explicit error status codes when this threshold is reached. The same issues with MAXDATA also apply to MAXSTREAMS. A Javascript application that fails to accept or read/abort every stream will consume flow control resources. This can manifest itself in strange ways, such as HTTP/3 being unable to create control streams, or simply being unable to create new request streams.
Thanks for the salient overview, it makes it easier to understand your concerns. My first comment would be that some of these points apply to QuicTransport too. Its just that their made worse by Http3Transport pooling allowing the mashing together of orthogonal protocols with no application-layer oversight. Just as you might interfere with a page load, a browser could easily interfere with your finely crafted application protocol. I would anticipate that, due to different browsers having different HTTP usage patterns, and different pages being composed differently by time, region, etc, one might find that Http3Transport apps subject to pooling would experience inconsistencies and transient issues. You rightly point out that the connection flow control is a shared resource. But the problems described seem to relate to stream flow control and overlooks the different flow control setting afforded by the Transport Parameters. A possible mitigation is to more tightly constrain the initial flow windows of server-initiated streams so that they can't interfere with requests. However, I still think that the notion of pooling together WebTransports in an uncoordinated fashion is going to manifest undesirable properties. The MAX_STREAMS observation is a good one. I think the competition between request streams and client bidirectional streams is going to be hard to resolve.
Yeah, and enforcing any per sort of per-session flow control might get difficult because you can only identify the protocol and session after you receive the first few bytes of each stream. For example, assume a brand new connection (for simplicity only) and you receive a STREAM frame with id=100, offset=16, and size=1000. You don't know yet which protocol or session created this stream or the 25 preceding it. And hopefully you eventually get those first few bytes for each stream...
Chair notes from IETF 112 meeting: this needs more discussion (on the issue or mailing list)
Chair: discussed at 113, consensus in room to: use a setting to limit number of WT sessions (see ) figure out MAXSTREAMS, a way to limit the number of streams within a session abandon MAXDATA as too hard, do not limit amount of data sent within a session (anyone can open a new issue to revisit this discussion if they have a concrete proposal on how to do this) let QUIC take care of MAXSTREAMDATA
Capsule DT is doing all of the above bullet points except the second one, for which I opened . Apologies for the extremely delayed response here, but hearing no objections we are declaring consensus and merging the PRs. David David Schinazi wrote:

This document <ins> The "SETTINGS_WEBTRANSPORT_MAX_SESSIONS" parameter indicates that the specified HTTP/3 server is WebTransport-capable and the number of concurrent sessions it is willing to receive. WEBTRANSPORT_MAX_SESSIONS 0x2b603743 0 This document </ins> 8.3. The following entry is added to the "HTTP/3 Frame Type" registry


Question:
Capsule design team output. Minimal changes to HTTP/3, which was already using capsules and is now joined by . Same content as draft PR, thank you to those who have already reviewed!
Does this actually with a no-op, or are we supposed to discuss that at 115? Otherwise LGTM.
It as a no-op with the exception of one bullet point that we did want to address, that got split out into , which we'll discuss at 115 separately from this PR.
Should the protocol share framing semantics with the HTTP/2 draft so that it is easy/easier to take datagrams or streams and put them on the CONNECT stream? Should it be possible to use that mechanism, or should it instead be forbidden? As much as possible, it would be desirable to have the forwarding logic be fairly uniform across different protocol versions. Right now, we have two almost completely different protocols.
I was discussing this with NAME and NAME What happens when an H3 WT server receives "version independent" WT framing on its CONNECT stream. Since WT over H3 requires H3 datagrams, then there is no need to fold datagrams into the CONNECT stream. There shouldn't be a need to fold streams either, unless you want to defeat QUIC stream limits :) Allowing this would also increase work to implement an H3 only WT client/server: you have to re-implement QUIC over an HTTP byte-stream just in case the peer decides to send you "version independent" WT. Right now I think they are totally different and never the twain shall meet. Proxies can convert between the two versions. If we did that, should we have different upgrade tokens?
Is this issue still relevant now that we have the outcome of HTTP Datagram Design Team?
NAME gentle ping
Actually never mind, this is blocked on the capsule design team - the output of that design team will decide on whether the h2 capsules are allowed in h3 or not
The H3 draft by its nature allows for the parallel processing of multiple WT sessions and also the intermixing of normal H3 request with WT. Server endpoints may wish to negotiate or disable this behavior. Clients can simply choose not to do either kind of pooling if they don't want to. There's already a PR open () with a design idea.
I'd like to propose a different model than the one in : The server sends the maximum WebTransport Session ID, or since 0 is a valid value, it's really the minimum invalid WebTransport Session ID. To indicate WT is not supported, server sends 0. To allow for only 1 session ever, server sends 4, and never updates it. To allow for only 1 session at a time, server sends 4, and updates it by 4 as each session closes/resets. To allow for N parallel sessions, server sends 4 * N. and updates as sessions close/reset. This mirrors H3 PUSH, and requires at least one more frame (MAXWTSESSIONID). Perhaps it would also require CANCELWT_SESSION? A client need only declare that it supports webtransport, and even that could be optional. The server will know if it receives a CONNECT with :protocol=webtransport.
I wanted to have a negotiation mechanism in , but my conclusion after talking with NAME about it was that we should not do negotiation, and servers should just reject extra streams with a 400 (or maybe even a RESET_STREAM) if they ever see more sessions than they expect; meaning it's on the clients to know if they can pool or not.
Though we may want a more specific 4XX error code so the client knows it should retry in a non-pooled connection
That's certainly a lot simpler than session credits ;) The cost of at least an RTT for a client that tries to pool against a server that can't handle it seems somewhat high. I guess it depends what the common client pooling strategies are and how many servers don't support pooling.
NAME since it's looking like the JavaScript API will provide a way to disable pooling, I expect that the scenario of pooling-attempted-but-rejected will be quite rare, so a round trip cost should be acceptable
I'm also considering use cases for WT which are not tied to the JS API.
NAME that's interesting - and those use-cases won't have a similar mechanism to disable pooling? I suspect they'll need a way to get the WT server's hostname somehow, and having config properties attached to that (such as disable_pooling) could be useful?
NAME : the opposite -- the clients may attempt pooling to servers that might or might not support it. You can't tell from a hostname if it supports pooling.
NAME how did the client get the hostname in the first place? I'm suggesting to carry pooling_support next to that.
Actually, let's go back to JS for a second. The people who write JS at Facebook are very unlikely to know if the edge server terminating their connection supports pooling, or that configuration could change over time.
(I appreciate the irony of me saying this as a Googler, but) should the JS people talk to the edge people? I agree that this shouldn't fail, but it being inefficient seems reasonable - these teams should talk if they're trying to reach good performance.
I think my main problem with is that most people who want to disallow pooling want to exclude not only other WebTransport sessions, but also general HTTP traffic. was written with that assumption in mind.
Ok, MAXWTSESSION_ID doesn't handle that case, so it may be an over-engineered solution to the wrong problem.
As I said in the meeting, I don't think that we should have any signals for dedicated connections from either client or server. Yutaka made the point that the client can decide to make a connection dedicated after seeing the server settings. It doesn't need to signal its intent (and signaling would have negative privacy consequences potentially). I agree with this observation. A server needs to support HTTP if we're using HTTP. So pooling with h3 is already a settled matter. If the server doesn't want to answer requests, it can use 406 or 421 or other HTTP mechanisms to tell the client to go away. More generally, the server can just not provide links to that server, such that it might have to respond to GET/OPTIONS/POST/etc. The question then becomes managing resource limits on the server. Having a way to limit the number of WebTransport sessions is a good thing and I believe that will be sufficient for this. Thus, I'm a supporter of option 3: MAXWTSESSIONS or similar.
I agree that we should have limits of how many WT can be active at the same time on a connection. It should also define what happens if the limit is exceeded. Should a client open another QUIC connection to the same server or should it fail? Probably it should be former, but that should also have limits defined (6 parallel QUIC connection, may be too much? HTTP/1.1 have the 6 parallel connection limit).
Chair: discussed at IETF 113, consensus in room to change the WT SETTING to carry the number of concurrent WT sessions allowed on this h3 connection
Note that all of the below works when you swap "server" and "client". I wanted to focus on a poor Javascript client implementation, but it's equally possible to run into these cases with a poor server implementation. Let's say that you have a Http3Transport session that shares a connection with HTTP/3 or another Http3Transport session. The client has limited buffer space and hypothetically advertises MAXDATA of 1MB for the connection. If the server pushes 1MB of unprocessed data over a Http3Transport session, then it will prevent the server from sending data over the connection, including HTTP/3 responses and other Http3Transport sessions. This can occur if the application does not accept all remote-created streams or does not fully read every stream. This will be VERY easy for a developer to mess up. It can also occur if the application can not process data faster than it is received. In my case, the server creates unidirectional streams and pushes a large amount of media over them. The flow control limit would be hit if the Javascript application: Only accepts bidirectional streams (ex. initialization) Does not accept a unidirectional stream (ex. error or teardown) Does not fully read or abort every stream (ex. parsing error) Is not able to parse the media fast enough (ex. underpowered). This is mostly intended behavior, otherwise these "bugs" would cause unbounded memory usage. However, the blast radius is bigger when sharing a connection. In my use-case, hitting the flow control limit would also block any HTTP/3 RPC calls or unrelated traffic on the connection. This introduces more scenarios for the connection to become deadlocked or generally stalled. HTTP/3 implementations use MAXSTREAMS to limit the number of simultaneous requests. This use-case no longer works when sharing a connection with a Http3Transport session, and HTTP/3 implementations must instead return explicit error status codes when this threshold is reached. The same issues with MAXDATA also apply to MAXSTREAMS. A Javascript application that fails to accept or read/abort every stream will consume flow control resources. This can manifest itself in strange ways, such as HTTP/3 being unable to create control streams, or simply being unable to create new request streams.
Thanks for the salient overview, it makes it easier to understand your concerns. My first comment would be that some of these points apply to QuicTransport too. Its just that their made worse by Http3Transport pooling allowing the mashing together of orthogonal protocols with no application-layer oversight. Just as you might interfere with a page load, a browser could easily interfere with your finely crafted application protocol. I would anticipate that, due to different browsers having different HTTP usage patterns, and different pages being composed differently by time, region, etc, one might find that Http3Transport apps subject to pooling would experience inconsistencies and transient issues. You rightly point out that the connection flow control is a shared resource. But the problems described seem to relate to stream flow control and overlooks the different flow control setting afforded by the Transport Parameters. A possible mitigation is to more tightly constrain the initial flow windows of server-initiated streams so that they can't interfere with requests. However, I still think that the notion of pooling together WebTransports in an uncoordinated fashion is going to manifest undesirable properties. The MAX_STREAMS observation is a good one. I think the competition between request streams and client bidirectional streams is going to be hard to resolve.
Yeah, and enforcing any per sort of per-session flow control might get difficult because you can only identify the protocol and session after you receive the first few bytes of each stream. For example, assume a brand new connection (for simplicity only) and you receive a STREAM frame with id=100, offset=16, and size=1000. You don't know yet which protocol or session created this stream or the 25 preceding it. And hopefully you eventually get those first few bytes for each stream...
Chair notes from IETF 112 meeting: this needs more discussion (on the issue or mailing list)
Chair: discussed at 113, consensus in room to: use a setting to limit number of WT sessions (see ) figure out MAXSTREAMS, a way to limit the number of streams within a session abandon MAXDATA as too hard, do not limit amount of data sent within a session (anyone can open a new issue to revisit this discussion if they have a concrete proposal on how to do this) let QUIC take care of MAXSTREAMDATA
Capsule DT is doing all of the above bullet points except the second one, for which I opened . Apologies for the extremely delayed response here, but hearing no objections we are declaring consensus and merging the PRs. David David Schinazi wrote:

WebTransport application error codes. This document. <ins> 8.6. The following entries are added to the "HTTP Capsule Types" registry established by HTTP-DATAGRAM: The "CLOSE_WEBTRANSPORT_SESSION" capsule. 0x2843 CLOSE_WEBTRANSPORT_SESSION permanent This document IETF WebTransport Working Group webtransport@ietf.org [1] None 9.  References 9.1.  URIs [1] mailto:webtransport@ietf.org </ins>


Question:
In URL, it was suggested that 403 status code should be used when Origin verification fails.
Thank you for suggestions! Applied.
Thank you for reviews! If this looks good can someone merge this?
Looking good, thank you! Added a few suggestions to cause it to generate links to the actual sections referenced, even if it makes it a little more repetitive.Approved modulo one small change

set to "webtransport", the HTTP/3 server can check if it has a WebTransport server associated with the specified ":authority" and ":path" values.  If it does not, it SHOULD reply with status code 404 <del> (Section 15.5.4, HTTP).  If it does, it MAY accept the session by replying with a 2xx series status code, as defined in Section 15.3 of HTTP.  The WebTransport server MUST verify the "Origin" header to </del> <ins> (Section 15.5.5 of HTTP).  When the request contains the "Origin" header, the WebTransport server MUST verify the "Origin" header to </ins> ensure that the specified origin is allowed to access the server in <del> question. </del> <ins> question.  If the verification fails, the WebTransport server SHOULD reply with status code 403 (Section 15.5.4 of HTTP).  If all checks pass, the WebTransport server MAY accept the session by replying with a 2xx series status code, as defined in Section 15.3 of HTTP. </ins> From the client's perspective, a WebTransport session is established when the client receives a 2xx response.  From the server's


Question:
Answer to issue
A first sentence says quasi-error-free is usually guarranteed thanks to redundancy, while the following sentence tends to say the opposite. Not very clear.The intro fails to clarify the targets. Among them there is "coding to recover from packet losses" (to avoid confusion with bit-error corrections), but also "coding to improve the usage of radio resource". You should also clarify better what is meant by coding: it's not a content coding (e.g., to compress a video flow) but rather a computation of linear combination of packets. Say since the begining you'll rely on RFC8406 whenever possible. Parts of the text currently in section 3 (1st paragraph) deserve to be moved here.Typo: s/to cope from/to cope with/
We have updated the introduction structure and changed the usage of coding in the whole document. We hope this is better. cf PR and PR
this is cherrypicking, not discussing link/channel FEC (Error) or ACK. the heading should really be 'of network coding schemes'. "to cover cases where where"? At the physical layer, FEC mechanisms can be exploited.-- Erasure or Error? "Based on public information, coding does not seem to be widely used at higher layers." it isn't, and that section can be reduced to just that sentence.
Vincent in item X1, 1st sentence, it suggests QUIC is a video streaming application. Change it.Fig. 2 raises a general question: it refers to upper applications that are by nature on the end-hosts. Everything is imaginable here and this is not specific to a SATCOM system. Why don't you limit yourself to the communication layers + middleware? I'm a bit confused.When you say: "Based on public information, coding does not seem to be widely used at higher layers." I guess you limit yourself to the "packetization UDP/IP + middleware" but do not consider upper applications. It's also confusing.
We think that these comments have been assessed with PR
"However, physical layer reliability mechanisms may not recover transmission losses (e.g. with a mobile user) and layer 2 (or above) re-transmissions induce 500 ms one-way delay with a geostationary satellite" Look, forward error coding (FEC) and link ACKs are complementary on a sliding scale depending on delay/channel quality, and this is talking solely about retransmissions. In fact, link or channel FEC do recover a large number of transmission bit/symbol losses without adding extra delay.
We have clarified this point in PR

the radio resource has been in the core design of SATellite COMmunication (SATCOM) systems.  The trade-off often resided in how much redundancy a system adds to cope from link impairments, without <del> reducing the good-put when the channel quality is high.  There is </del> <ins> reducing the good-put when the channel quality is good.  There is </ins> usually enough redundancy to guarantee a Quasi-Error Free <del> transmission.  However, physical layer reliability mechanisms may not recover transmission losses (e.g. with a mobile user) and layer 2 (or above) re-transmissions induce 500 ms one-way delay with a geostationary satellite.  Further exploiting coding schemes at higher OSI-layers is an opportunity for releasing constraints on the physical layer in such cases and improving the performance of SATCOM systems. </del> <ins> transmission.  The recovery time depends on the encoding block size. Considering for instance geostationary satellite system (GEO), physical or link layers erasure coding mechanisms recover transmission losses within a negligible delay compared to link delay. However, when retransmissions are triggered, this leads to an non- negligible additional delay in particular over GEO link.  Further exploiting coding schemes at application or transport layers is an opportunity for releasing constraints on the physical layer and improving the performance of SATCOM systems. </ins> We have noticed an active research activity on coding and SATCOM in the past.  That being said, not much has actually made it to


Question:
I have no idea what this section means. Virtualised antennas? virtualised reflectors? Good luck with that. chin-nfvrg-cloud-5g-core-structure-yang referring to an expired -00 internet-draft does not add credibility.
MJM : But on the virtualization comment: we had presentations in the group on NFV (network virtualization) with NC for satellites. I am sure that the authors of this work could add to Lloyd’s comments on that section.
We have added a research challenge and changed the title of section in PR . The section aims at identifying research challenge related to the interaction between NC and virtualization (function chaining, buffer management, etc).

A research challenge would be the optimization of the NFV service function chaining, considering a virtualized infrastructure and other SATCOM specific functions, to guarantee an efficient radio usage and <del> easy-to-deploy SATCOM services. </del> <ins> easy-to-deploy SATCOM services.  Moreover, another challenge related to a virtualized SATCOM terminals is the management of limited buffered equipments. </ins> 5.3.


Question:
First sentence, the use of "these techniques" is ambiguous. Which techniques?
Thanks. Updated in PR

5. <del> This document discuses some opportunities to introduce these </del> <ins> This document discuses some opportunities to introduce coding </ins> techniques at a wider scale in satellite telecommunications systems. Even though this document focuses on satellite systems, it is worth


Question:
Reset stream doesn't cease retransmission.
retransmission of WTSTREAM frames on the identified stream. A receiver of WTRESET_STREAM can discard any data that it already received on that stream." This is using TCP and should not talk about ceasing retransmissions.
Very good point! Will clean up

An endpoint uses a frame (type=0x04) to abruptly terminate the sending part of a stream. <del> After sending a , an endpoint ceases transmission and retransmission of frames on the identified stream.  A receiver of can discard any data that it already received on that stream. </del> <ins> After sending a , an endpoint ceases transmission of frames on the identified stream.  A receiver of can discard any data that it already received on that stream. </ins> The frame defines the following fields:


Question:
As suggested by Éric Vyncke, mention that the new ciphertext record format provides ContentType encryption and per-record padding in both abstract and introduction.
URL Update from Éric re: Section 6
About "-- Section 3 --, DTLS / zero-length CID" "An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello." The "zero-length CID" therefore is mainly used for the very common cases, where only the clients are required to send such a CID, but not the server. Maybe adding a hint to RFC5246 7.4.1.4 will help?
About "-- Section 6 --" Yes, that's still very complex: First, processing the record seems to be easier (less restricted), than use a changed source address for sending data back. Using a changed source address for sending data back to, is not generally solved. There are some special case, e.g., if the data sent back is very small, there is no risk (at least, none has explained one). There may also be some upper-layer mechanisms, which helps out (e.g. for coap). And there is a idea of a general solution , but that will require more time. Because of the required time, the idea was to release this spec without RRC and postpone that general work (see also issue ).
also in the abstract ? Some initial attempt at this in
LGTM Éric Vyncke has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Thank you for the work put into this document. This specification addresses the IPv4-mainly issue of NAT binding and is still required. I am also trusted the security ADs for section 5. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Abstract -- As an important part of this document is the padding, should it be mentioned also in the abstract ? -- Section 3 -- While I am not a DTLS expert, I find this section quite difficult to understand the reasoning behind the specification as little explanations are given about, e.g, what is the motivation of "A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID." -- Section 6 -- I am puzzled by the text: "There is a strategy for ensuring that the new peer address is able to receive and process DTLS records. No such strategy is defined in this specification." Does this mean that there is no way to update the peer IP address ? == NITS == -- Section 1 -- Please expand CID on first use outside of the abstract. -- Section 4 -- Suggest to add a short paragraph as a preamble to figure 3. Currently, it looks like figure 3 belongs to the 'zeros' field description.

during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. <ins> The new ciphertext record format with CID also provides content type encryption and record-layer padding. </ins> 1. The Datagram Transport Layer Security (DTLS) RFC6347 protocol was


Question:
As suggested by Éric Vyncke, mention that the new ciphertext record format provides ContentType encryption and per-record padding in both abstract and introduction.
URL Update from Éric re: Section 6
About "-- Section 3 --, DTLS / zero-length CID" "An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello." The "zero-length CID" therefore is mainly used for the very common cases, where only the clients are required to send such a CID, but not the server. Maybe adding a hint to RFC5246 7.4.1.4 will help?
About "-- Section 6 --" Yes, that's still very complex: First, processing the record seems to be easier (less restricted), than use a changed source address for sending data back. Using a changed source address for sending data back to, is not generally solved. There are some special case, e.g., if the data sent back is very small, there is no risk (at least, none has explained one). There may also be some upper-layer mechanisms, which helps out (e.g. for coap). And there is a idea of a general solution , but that will require more time. Because of the required time, the idea was to release this spec without RRC and postpone that general work (see also issue ).
also in the abstract ? Some initial attempt at this in
LGTM Éric Vyncke has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Thank you for the work put into this document. This specification addresses the IPv4-mainly issue of NAT binding and is still required. I am also trusted the security ADs for section 5. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Abstract -- As an important part of this document is the padding, should it be mentioned also in the abstract ? -- Section 3 -- While I am not a DTLS expert, I find this section quite difficult to understand the reasoning behind the specification as little explanations are given about, e.g, what is the motivation of "A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID." -- Section 6 -- I am puzzled by the text: "There is a strategy for ensuring that the new peer address is able to receive and process DTLS records. No such strategy is defined in this specification." Does this mean that there is no way to update the peer IP address ? == NITS == -- Section 1 -- Please expand CID on first use outside of the abstract. -- Section 4 -- Suggest to add a short paragraph as a preamble to figure 3. Currently, it looks like figure 3 belongs to the 'zeros' field description.

(CID) to the DTLS record layer.  The presence of the CID is negotiated via a DTLS extension. <ins> Adding a CID to the ciphertext record format presents an opportunity to make other changes to the record format.  In keeping with the best practices established by TLS 1.3, the type of the record is encrypted, and a mechanism provided for adding padding to obfuscate the plaintext length. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",


Question:
Based on URL
Thanks!
Martin wrote: URL LGTM. I would strike ", if these privacy properties are important in a given deployment" from the acknowledgments section (which is an odd place for the accompanying statement. I would add an explicit note about the lack of CID update making this unsuitable for mobility scenarios. That's a common use case for this sort of mechanism, but this design lacks any defense against linkability. >

With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further <del> privacy concerns. </del> <ins> privacy concerns.  The lack of a CID update mechanism makes this extension unsuitable for mobility scenarios where correlation must be considered. </ins> Importantly, the sequence number makes it possible for a passive attacker to correlate packets across CID changes.  Thus, even if a


Question:
We incorrectly put a normative reference on the RRC draft in the DTLS 1.2 CID draft.
I lost somehow the track on that RRC and the discussion around it. The referred document mentions: and I would assume, that a on-path adversary could black hole traffic in both directions, even without CID. Not only message sent to a peer could be dropped, it would also be easy to drop a message sent back from that peer (at least, if the route back is on the same path). I would also assume, that a on-path adversary, which is able to change the source address, would also be able to change the destination address. So a simple traffic redirect will also be possible even without CID. In my opinion, the only threat left, which is caused by the usage of a CID, would be a DDoS attack using amplified traffic towards third party. For that it seems to be most important to throttle the traffic by limiting the number and size of messages until the address is verified. Though such a DDoS will be naturally less efficient, because the adversary has to wait for messages to change the sources-address, throttling would make it even more unattractive.

Connection Identifiers for DTLS 1.2 <del> draft-ietf-tls-dtls-connection-id-07 </del> <ins> draft-ietf-tls-dtls-connection-id-latest </ins> Abstract


Question: This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

1. <del> The Datagram Transport Layer Security (DTLS) protocol was designed for securing connection-less transports, like UDP.  DTLS, like TLS, starts with a handshake, which can be computationally demanding (particularly when public key cryptography is used).  After a successful handshake, symmetric key cryptography is used to apply </del> <ins> The Datagram Transport Layer Security (DTLS) RFC6347 protocol was designed for securing connection-less transports, like UDP.  DTLS, like TLS, starts with a handshake, which can be computationally demanding (particularly when public key cryptography is used).  After a successful handshake, symmetric key cryptography is used to apply </ins> data origin authentication, integrity and confidentiality protection. This two-step approach allows endpoints to amortize the cost of the initial handshake across subsequent application data protection. Ideally, the second phase where application data is protected lasts <del> over a longer period of time since the established keys will only need to be updated once the key lifetime expires. </del> <ins> over a long period of time since the established keys will only need to be updated once the key lifetime expires. </ins> <del> In the current version of DTLS, the IP address and port of the peer </del> <ins> In DTLS as specified in RFC 6347, the IP address and port of the peer </ins> are used to identify the DTLS association.  Unfortunately, in some cases, such as NAT rebinding, these values are insufficient.  This is a particular issue in the Internet of Things when devices enter


Question: This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

an endpoint to use a globally constant length for such connection identifiers.  This can in turn ease parsing and connection lookup, for example by having the length in question be a compile-time <del> constant.  Implementations, which want to use variable-length CIDs, are responsible for constructing the CID in such a way that its length can be determined on reception.  Such implementations must still be able to send CIDs of different length to other parties. Note that there is no CID length information included in the record itself. </del> <ins> constant.  Such implementations MUST still be able to send CIDs of different length to other parties.  Implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception.  Note that there is no CID length information included in the record itself. </ins> In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session only.  There is no dedicated "CID update" message that allows new


Question: This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

record is found in DTLSInnerPlaintext.real_type after decryption. The CID value, cid_length bytes long, as agreed at the time the <del> extension has been negotiated. </del> <ins> extension has been negotiated.  Recall that (as discussed previously) each peer chooses the CID value it will receive and use to identify the connection, so an implementation can choose to always recieve CIDs of a fixed length.  If, however, an implementation chooses to receive different lengths of CID, the assigned CID values must be self-delineating since there is no other mechanism available to determine what connection (and thus, what CID length) is in use. </ins> The encrypted form of the serialized DTLSInnerPlaintext structure.


Question: This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

5. Several types of ciphers have been defined for use with TLS and DTLS <del> and the MAC calculation for those ciphers differs slightly. </del> <ins> and the MAC calculations for those ciphers differ slightly. </ins> <del> This specification modifies the MAC calculation defined in RFC6347 and RFC7366 as well as the definition of the additional data used with AEAD ciphers provided in RFC6347 for records with content type </del> <ins> This specification modifies the MAC calculation as defined in RFC6347 and RFC7366, as well as the definition of the additional data used with AEAD ciphers provided in RFC6347, for records with content type </ins> tls12_cid.  The modified algorithm MUST NOT be applied to records that do not carry a CID, i.e., records with content type other than tls12_cid.


Question: This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

The following fields are defined in this document; all other fields are as defined in the cited documents. <del> Value of the negotiated CID. </del> <ins> Value of the negotiated CID (variable length). </ins> 1 byte field indicating the length of the negotiated CID. <del> The length (in bytes) of the serialised DTLSInnerPlaintext. </del> <ins> The length (in bytes) of the serialised DTLSInnerPlaintext (two- byte integer). </ins> The length MUST NOT exceed 2^14. Note "+" denotes concatenation.


Question: This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

The above is necessary to protect against attacks that use datagrams with spoofed addresses or replayed datagrams to trigger attacks. <del> Note that there is no requirement to use of the anti-replay window </del> <ins> Note that there is no requirement for use of the anti-replay window </ins> mechanism defined in Section 4.1.2.6 of DTLS 1.2.  Both solutions, <del> the "anti-replay window" or "newer algorithm" will prevent address </del> <ins> the "anti-replay window" or "newer" algorithm, will prevent address </ins> updates from replay attacks while the latter will only apply to peer address updates and the former applies to any application layer traffic. <ins> Note that datagrams that pass the DTLS cryptographic verification procedures but do not trigger a change of peer address are still valid DTLS records and are still to be passed to the application. </ins> Application protocols that implement protection against these attacks depend on being aware of changes in peer addresses so that they can engage the necessary mechanisms.  When delivered such an event, an application layer-specific address validation mechanism can be <del> triggered, for example one that is based on successful exchange of </del> <ins> triggered, for example one that is based on successful exchange of a </ins> minimal amount of ping-pong traffic with the peer.  Alternatively, an DTLS-specific mechanism may be used, as described in I-D.tschofenig- tls-dtls-rrc.


Question: This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

dtls-example2 shows an example exchange where a CID is used uni- directionally from the client to the server.  To indicate that a <del> zero-length CID we use the term 'connection_id=empty'. </del> <ins> zero-length CID is present in the "connection_id" extension we use the notation 'connection_id=empty'. </ins> Note: In the example exchange the CID is included in the record layer once encryption is enabled.  In DTLS 1.2 only one handshake message is encrypted, namely the Finished message.  Since the example shows <del> how to use the CID for payloads sent from the client to the server only the record layer payloads containing the Finished messages include a CID.  Application data payloads sent from the client to the server contain a CID in this example as well. </del> <ins> how to use the CID for payloads sent from the client to the server, only the record layer payloads containing the Finished message or application data include a CID. </ins> 8.


Question: This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

details about record padding can be found in Section 5.4 and Appendix E.3 of RFC 8446. <del> Finally, endpoints can use the CID to attach arbitrary metadata to each record they receive.  This may be used as a mechanism to communicate per-connection information to on-path observers.  There is no straightforward way to address this concern with CIDs that contain arbitrary values.  Implementations concerned about this aspects SHOULD refuse to use CIDs. </del> <ins> Finally, endpoints can use the CID to attach arbitrary per-connection metadata to each record they receive on a given connection.  This may be used as a mechanism to communicate per-connection information to on-path observers.  There is no straightforward way to address this concern with CIDs that contain arbitrary values.  Implementations concerned about this aspect SHOULD refuse to use CIDs. </ins> 9.


Question: This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

asymmetry of request/response message sizes. Additionally, an attacker able to observe the data traffic exchanged <del> between two DTLS peers is able to replay datagrams with modified IP address/port numbers. </del> <ins> between two DTLS peers is able to modify IP address/port numbers. When the optional DTLS replay detection is not in use, such an attacker can also replay the observed packets, and the multiple copies of each packet can have different IP address/port numbers as well. </ins> The topic of peer address updates is discussed in peer-address- update.


Question: This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

"ExtensionType Values" registry, defined in RFC5246, for connection_id(TBD1) as described in the table below.  IANA is requested to add an extra column to the TLS ExtensionType Values <del> registry to indicate whether an extension is only applicable to DTLS. </del> <ins> registry to indicate whether an extension is only applicable to DTLS and to include this document as an additional reference for the registry. </ins> Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document <del> describes an extension for DTLS 1.2 only; it is not to TLS (1.3). The DTLS 1.3 functionality is described in I-D.ietf-tls-dtls13. </del> <ins> describes the behavior of this extension for DTLS 1.2 only; it is not applicable to TLS, and its usage for DTLS 1.3 is described in I- D.ietf-tls-dtls13. </ins> IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType Registry".  The tls12_cid ContentType is only applicable to DTLS 1.2.


Question:
and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.

confidence to the receiving peer that the sending peer is reachable at the indicated address and port. <ins> Note however that, irrespective of CID, if RRC has been successfully negotiated by the peers, path validation can be used at any time by either endpoint.  For instance, an endpoint might use RRC to check that a peer is still in possession of its address after a period of quiescence. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",


Question:
and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.

I-D.ietf-tls-dtls13.  The presentation language used in this document is described in Section 4 of RFC8446. <ins> This document reuses the definition of "anti-amplification limit" from RFC9000 to mean three times the amount of data received from an unvalidated address.  This includes all DTLS records originating from that source address, excluding discarded ones. </ins> 3. The use of RRC is negotiated via the "rrc" DTLS-only extension.  On


Question:
and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.

The "return_routability_check" message MUST be authenticated and encrypted using the currently active security context. <del> The receiver that observes the peer's address and or port update MUST </del> <ins> 5. The receiver that observes the peer's address or port update MUST </ins> stop sending any buffered application data (or limit the data sent to <del> a TBD threshold) and initiate the return routability check that proceeds as follows: </del> <ins> the unvalidated address to the anti-amplification limit) and initiate the return routability check that proceeds as follows: </ins> <del> A cookie is placed in a "return_routability_check" message of type path_challenge; </del> <ins> An unpredictable cookie is placed in a "return_routability_check" message of type path_challenge; </ins> <del> The message is sent to the observed new address and a timeout T is started; </del> <ins> The message is sent to the observed new address and a timer T (see timer-choice) is started; </ins> The peer endpoint, after successfully verifying the received <del> "return_routability_check" message echoes the cookie value in a "return_routability_check" message of type path_response; </del> <ins> "return_routability_check" message responds by echoing the cookie value in a "return_routability_check" message of type path_response; </ins> When the initiator receives and verifies the "return_routability_check" message contains the sent cookie, it


Question:
and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.

After this point, any pending send operation is resumed to the bound peer address. <del> 5. </del> <ins> path-challenge-reqs and path-response-reqs contain the requirements for the initiator and responder roles, broken down per protocol phase. 5.1. The initiator MAY send multiple "return_routability_check" messages of type path_challenge to cater for packet loss on the probed path. Each path_challenge SHOULD go into different transport packets. (Note that the DTLS implementation may not have control over the packetization done by the transport layer.) The transmission of subsequent path_challenge messages SHOULD be paced to decrease the chance of loss. Each path_challenge message MUST contain random data. The initiator MAY use padding using the record padding mechanism available in DTLS 1.3 (and in DTLS 1.2, when CID is enabled on the sending direction) up to the anti-amplification limit to probe if the path MTU (PMTU) for the new path is still acceptable. 5.2. The responder MUST NOT delay sending an elicited path_response message. The responder MUST send exactly one path_response messages for each received path_request. The responder MUST send the path_response on the network path where the corresponding path_challenge has been received, so that validation succeeds only if the path is functional in both directions. The initiator MUST NOT enforce this behaviour The initiator MUST silently discard any invalid path_response it receives. Note that RRC does not cater for PMTU discovery on the reverse path. If the responder wants to do PMTU discovery using RRC, it should initiate a new path validation procedure. 5.3. When setting T, implementations are cautioned that the new path could have a longer round-trip time (RTT) than the original. In settings where there is external information about the RTT of the active path, implementations SHOULD use T = 3xRTT. If an implementation has no way to obtain information regarding the RTT of the active path, a value of 1s SHOULD be used. Profiles for specific deployment environments - for example, constrained networks I-D.ietf-uta-tls13-iot-profile - MAY specify a different, more suitable value. 6. </ins> The example TLS 1.3 handshake shown in fig-handshake shows a client and a server negotiating the support for CID and for the RRC


Question:
and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.

However, the server wants to test the reachability of the client at his new IP address. <del> 6. </del> <ins> 7. </ins> Note that the return routability checks do not protect against flooding of third-parties if the attacker is on-path, as the attacker


Question:
and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.

those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity. <del> 7. </del> <ins> 8. </ins> IANA is requested to allocate an entry to the TLS "ContentType" registry, for the "return_routability_check(TBD2)" defined in this


Question:
and
For example, allow multiple outstanding path_challenge messages to cater for potential packet loss.
We want to limit the application data sent to a reasonable threshold while we run the RRC.
RFC 9000, section 8 "address validation" (second paragraph, last line): 3 times the amount of data received.
Here is the text: Address Validation Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attacks is verifying that a peer is able to receive packets at the transport address that it claims. Therefore, after receiving packets from an address that is not yet validated, an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address. This limit on the size of responses is known as the anti-amplification limit.

"rrc" extension to the "TLS ExtensionType Values" registry as described in tbl-ext. <del> 8. </del> <ins> 9. </ins> Issues against this document are tracked at https://github.com/tlswg/ dtls-rrc/issues <del> 9. </del> <ins> 10. </ins> We would like to thank Achim Kraus, Hanno Becker, Hanno Boeck, Manuel Pegourie-Gonnard, Mohit Sahni and Rich Salz for their input to this


Question:
I am OK with this change. There are no normative changes in there because the normative text segment is only moved to a different paragraph.
I was referring to this added clause: "alternately it MAY report PMTU estimates minus the estimated expansion from the transport layer and DTLS record framing."
What is awkward here is that this is phrased as normative requirements on an API. Maybe worded as advice "an application that uses DTLS might need information from DTLS to allow it to estimate the PMTU; DTLS could report a PMTU estimate less any DTLS overheads, or it can report those overheads and allow the application to perform its own estimation"
There has historically been API language here, so I think we should keep it and just adjust it as here.
This one probably needs consensus given new normative language.

upper layer protocol MUST NOT write any record that exceeds the maximum record size of 2^14 bytes. <ins> The DTLS record layer SHOULD also allow the upper layer protocol to discover the amount of record expansion expected by the DTLS processing; alternately it MAY report PMTU estimates minus the estimated expansion from the transport layer and DTLS record framing. </ins> Note that DTLS does not defend against spoofed ICMP messages; implementations SHOULD ignore any such messages that indicate PMTUs below the IPv4 and IPv6 minimums of 576 and 1280 bytes respectively <del> The DTLS record layer SHOULD allow the upper layer protocol to discover the amount of record expansion expected by the DTLS processing. If there is a transport protocol indication (either via ICMP or via a refusal to send the datagram as in Section 14 of RFC4340), then the DTLS record layer MUST inform the upper layer protocol of the error. </del> <ins> If there is a transport protocol indication that the PMTU was exceeded (either via ICMP or via a refusal to send the datagram as in Section 14 of RFC4340), then the DTLS record layer MUST inform the upper layer protocol of the error. </ins> The DTLS record layer SHOULD NOT interfere with upper layer protocols performing PMTU discovery, whether via RFC1191 or RFC4821 mechanisms.


Question:
I am OK with this change. There are no normative changes in there because the normative text segment is only moved to a different paragraph.
I was referring to this added clause: "alternately it MAY report PMTU estimates minus the estimated expansion from the transport layer and DTLS record framing."
What is awkward here is that this is phrased as normative requirements on an API. Maybe worded as advice "an application that uses DTLS might need information from DTLS to allow it to estimate the PMTU; DTLS could report a PMTU estimate less any DTLS overheads, or it can report those overheads and allow the application to perform its own estimation"
There has historically been API language here, so I think we should keep it and just adjust it as here.
This one probably needs consensus given new normative language.

DTLS implementations SHOULD follow the following rules: If the DTLS record layer informs the DTLS handshake layer that a <del> message is too big, it SHOULD immediately attempt to fragment it, using any existing information about the PMTU. </del> <ins> message is too big, the handshake layer SHOULD immediately attempt to fragment the message, using any existing information about the PMTU. </ins> If repeated retransmissions do not result in a response, and the PMTU is unknown, subsequent retransmissions SHOULD back off to a


Question:
You don't want to age out before you get epoch 3 because otherwise you might be dropping when you have handshake packets.
For my understanding: what is the harm of keeping the 0-RTT keys around till the end of the handshake?
"Yes, the goal is to encourage people not to keep 0-RTT keys too long, because they might not have PCS. The replay risk is essentially a non-issue, except to the extent that it might already have been replayed."

EndOfEarlyData is not necessary to determine when the early data is complete, and because DTLS is lossy, attackers can trivially mount the deletion attacks that EndOfEarlyData prevents in TLS.  Servers <del> SHOULD aggressively age out the epoch 1 keys upon receiving the first epoch 2 record and SHOULD NOT accept epoch 1 data after the first epoch 3 record is received.  (See dtls-epoch for the definitions of each epoch.) </del> <ins> SHOULD NOT accept records from epoch 1 indefinitely once they are able to process records from epoch 3.  Though reordering of IP packets can result in records from epoch 1 arriving after records from epoch 3, this is not likely to persist for very long relative to the round trip time.  Servers could discard epoch 1 keys after the first epoch 3 data arrives, or retain keys for processing epoch 1 data for a short period.  is received.  (See dtls-epoch for the definitions of each epoch.) </ins> 5.6.


Question:
It's possible to negotiate the CID extension but that you want to receive an empty CID (this is how you get asymmetrical CID lengths). The current text says: CID. If an implementation receives these messages when CIDs were not negotiated, it MUST abort the connection with an unexpected_message alert. But does this mean that (for instance) you can negotiate receiving an empty CID and then switch to a non-empty? I am tempted to say "no" as I recall QUIC did.
Doing what QUIC did seems prudent ... and if I didn't know what QUIC did I think I would also lean towards disallowing switching between empty and non-empty on a live connection.

provided.  Endpoints MUST NOT have more than one NewConnectionId message outstanding. <del> If the client and server have negotiated use of the "connection_id" extension, either side can request a new CID using the RequestConnectionId message.  In general, implementations SHOULD use a new CID whenever sending on a new path, and SHOULD request new CIDs for this purpose if path changes are anticipated. </del> <ins> Implementations which either did not negotiate the "connection_id" extension or which have negotiated receiving an empty CID MUST NOT send NewConnectionId.  Implementations MUST NOT send RequestConnectionId when sending an empty connection ID. Implementations which detect a violation of these rules MUST terminate the connection with an "unexpected_message" alert. Implementations SHOULD use a new CID whenever sending on a new path, and SHOULD request new CIDs for this purpose if path changes are anticipated. </ins> The number of CIDs desired.


Question:
Thanks for this document -- badly needed and easy to read. Thanks also to Bernard Adoba for his recent tsvart review. I support his comments. COMMENTS: Sec 2. It might be useful to introduce the term "epoch" in the glossary, for those who read this front to back. Sec 4.2.3: "The encrypted sequence number is computed by XORing the leading bytes of the Mask with the sequence number. Decryption is accomplished by the same process." The text is unclear if the XOR is applied to the expanded sequence number or merely the 1-2 octets on the wire. I presume it's the latter, but this should be clarified. Sec 4.2.3: It's implied here that the snkey rotates with the epoch. As this is different from QUIC, it's probably worth spelling out. Sec 5.1 is a bit vague about the amplification limit; why not at least RECOMMEND 3, as we've converged on this elsewhere? Sec 5.1. Reading between the lines, it's clear that the cookie can't be used as address verification across connections in the way that a NEWTOKEN token is. It would be good to spell this out for clients -- use the resumption token or whatever instead. Sec 7.2 "As noted above, the receipt of any record responding to a given flight MUST be taken as an implicit acknowledgement for the entire flight." I think this should be s/entire flight/entire previous flight? Sec 7.2 "Upon receipt of an ACK that leaves it with only some messages from a flight having been acknowledged an implementation SHOULD retransmit the unacknowledged messages or fragments." This language appears inconsistent with Figure 12, where Record 1 has not been acknowledged but is also not retransmitted. It appears there is an implied handling of empty ACKs that isn't written down anywhere in Sec 7.2 Sec 9. Should there be any flow control limits on newconnectionid? Or should receivers be free to simply drop CIDs they can't handle? It might be good to specify. Finally, a really weird one. Reading this document and references to connection ID prompted to me to think how QUIC-LB could apply to DTLS. The result is here: URL Please note the rather unfortunate third-to-last paragraph. I'm happy to take the answer that this use case doesn't matter, since I made it up today. But if it does, it would be very helpful if (1) DTLS 1.3 clients MUST include a connectionid extension in their ClientHello, even if zero length, and/or (2) this draft updated 4.1.4 of 8446 to allow the server to include connectionid in HelloRetryRequest even if the client didn't offer it. Thoughts? NITS: s/select(HandshakeType)/select(msg_type). Though with pseudocode your mileage may vary as to what's clearer. s/consitute/constitute Sec 5.7 In table 1, why include one ACK in the diagram but not the other? It's clear from the note, but the figure is a weird omission.
Addressed in URL

endpoint: Either the client or server of the connection. <ins> epoch: one set of cryptographic keys used for encryption and decryption. </ins> handshake: An initial negotiation between client and server that establishes the parameters of the connection.


Question:
Thanks for this document -- badly needed and easy to read. Thanks also to Bernard Adoba for his recent tsvart review. I support his comments. COMMENTS: Sec 2. It might be useful to introduce the term "epoch" in the glossary, for those who read this front to back. Sec 4.2.3: "The encrypted sequence number is computed by XORing the leading bytes of the Mask with the sequence number. Decryption is accomplished by the same process." The text is unclear if the XOR is applied to the expanded sequence number or merely the 1-2 octets on the wire. I presume it's the latter, but this should be clarified. Sec 4.2.3: It's implied here that the snkey rotates with the epoch. As this is different from QUIC, it's probably worth spelling out. Sec 5.1 is a bit vague about the amplification limit; why not at least RECOMMEND 3, as we've converged on this elsewhere? Sec 5.1. Reading between the lines, it's clear that the cookie can't be used as address verification across connections in the way that a NEWTOKEN token is. It would be good to spell this out for clients -- use the resumption token or whatever instead. Sec 7.2 "As noted above, the receipt of any record responding to a given flight MUST be taken as an implicit acknowledgement for the entire flight." I think this should be s/entire flight/entire previous flight? Sec 7.2 "Upon receipt of an ACK that leaves it with only some messages from a flight having been acknowledged an implementation SHOULD retransmit the unacknowledged messages or fragments." This language appears inconsistent with Figure 12, where Record 1 has not been acknowledged but is also not retransmitted. It appears there is an implied handling of empty ACKs that isn't written down anywhere in Sec 7.2 Sec 9. Should there be any flow control limits on newconnectionid? Or should receivers be free to simply drop CIDs they can't handle? It might be good to specify. Finally, a really weird one. Reading this document and references to connection ID prompted to me to think how QUIC-LB could apply to DTLS. The result is here: URL Please note the rather unfortunate third-to-last paragraph. I'm happy to take the answer that this use case doesn't matter, since I made it up today. But if it does, it would be very helpful if (1) DTLS 1.3 clients MUST include a connectionid extension in their ClientHello, even if zero length, and/or (2) this draft updated 4.1.4 of 8446 to allow the server to include connectionid in HelloRetryRequest even if the client didn't offer it. Thoughts? NITS: s/select(HandshakeType)/select(msg_type). Though with pseudocode your mileage may vary as to what's clearer. s/consitute/constitute Sec 5.7 In table 1, why include one ACK in the diagram but not the other? It's clear from the note, but the figure is a weird omission.
Addressed in URL

MSL: Maximum Segment Lifetime <del> The reader is assumed to be familiar with the TLS 1.3 specification. As in TLS 1.3 the HelloRetryRequest has the same format as a ServerHello message but for convenience we use the term HelloRetryRequest throughout this document as if it were a distinct message. </del> <ins> The reader is assumed to be familiar with TLS13.  As in TLS 1.3, the HelloRetryRequest has the same format as a ServerHello message, but for convenience we use the term HelloRetryRequest throughout this document as if it were a distinct message. </ins> The reader is also assumed to be familiar with I-D.ietf-tls-dtls- connection-id as this document applies the CID functionality to DTLS


Question:
Thanks for this document -- badly needed and easy to read. Thanks also to Bernard Adoba for his recent tsvart review. I support his comments. COMMENTS: Sec 2. It might be useful to introduce the term "epoch" in the glossary, for those who read this front to back. Sec 4.2.3: "The encrypted sequence number is computed by XORing the leading bytes of the Mask with the sequence number. Decryption is accomplished by the same process." The text is unclear if the XOR is applied to the expanded sequence number or merely the 1-2 octets on the wire. I presume it's the latter, but this should be clarified. Sec 4.2.3: It's implied here that the snkey rotates with the epoch. As this is different from QUIC, it's probably worth spelling out. Sec 5.1 is a bit vague about the amplification limit; why not at least RECOMMEND 3, as we've converged on this elsewhere? Sec 5.1. Reading between the lines, it's clear that the cookie can't be used as address verification across connections in the way that a NEWTOKEN token is. It would be good to spell this out for clients -- use the resumption token or whatever instead. Sec 7.2 "As noted above, the receipt of any record responding to a given flight MUST be taken as an implicit acknowledgement for the entire flight." I think this should be s/entire flight/entire previous flight? Sec 7.2 "Upon receipt of an ACK that leaves it with only some messages from a flight having been acknowledged an implementation SHOULD retransmit the unacknowledged messages or fragments." This language appears inconsistent with Figure 12, where Record 1 has not been acknowledged but is also not retransmitted. It appears there is an implied handling of empty ACKs that isn't written down anywhere in Sec 7.2 Sec 9. Should there be any flow control limits on newconnectionid? Or should receivers be free to simply drop CIDs they can't handle? It might be good to specify. Finally, a really weird one. Reading this document and references to connection ID prompted to me to think how QUIC-LB could apply to DTLS. The result is here: URL Please note the rather unfortunate third-to-last paragraph. I'm happy to take the answer that this use case doesn't matter, since I made it up today. But if it does, it would be very helpful if (1) DTLS 1.3 clients MUST include a connectionid extension in their ClientHello, even if zero length, and/or (2) this draft updated 4.1.4 of 8446 to allow the server to include connectionid in HelloRetryRequest even if the client didn't offer it. Thoughts? NITS: s/select(HandshakeType)/select(msg_type). Though with pseudocode your mileage may vary as to what's clearer. s/consitute/constitute Sec 5.7 In table 1, why include one ACK in the diagram but not the other? It's clear from the note, but the figure is a weird omission.
Addressed in URL

The sn_key is computed as follows: [sender] denotes the sending side.  The Secret value to be used is <del> described in Section 7.3 of TLS13. </del> <ins> described in Section 7.3 of TLS13.  Note that a new key is used for each epoch: because the epoch is in the clear, this does not result in ambiguity. </ins> The encrypted sequence number is computed by XORing the leading bytes <del> of the Mask with the sequence number.  Decryption is accomplished by the same process. </del> <ins> of the Mask with the on-the-wire representation of the sequence number.  Decryption is accomplished by the same process. </ins> This procedure requires the ciphertext length be at least 16 bytes. Receivers MUST reject shorter records as if they had failed


Question:
Thanks for this document -- badly needed and easy to read. Thanks also to Bernard Adoba for his recent tsvart review. I support his comments. COMMENTS: Sec 2. It might be useful to introduce the term "epoch" in the glossary, for those who read this front to back. Sec 4.2.3: "The encrypted sequence number is computed by XORing the leading bytes of the Mask with the sequence number. Decryption is accomplished by the same process." The text is unclear if the XOR is applied to the expanded sequence number or merely the 1-2 octets on the wire. I presume it's the latter, but this should be clarified. Sec 4.2.3: It's implied here that the snkey rotates with the epoch. As this is different from QUIC, it's probably worth spelling out. Sec 5.1 is a bit vague about the amplification limit; why not at least RECOMMEND 3, as we've converged on this elsewhere? Sec 5.1. Reading between the lines, it's clear that the cookie can't be used as address verification across connections in the way that a NEWTOKEN token is. It would be good to spell this out for clients -- use the resumption token or whatever instead. Sec 7.2 "As noted above, the receipt of any record responding to a given flight MUST be taken as an implicit acknowledgement for the entire flight." I think this should be s/entire flight/entire previous flight? Sec 7.2 "Upon receipt of an ACK that leaves it with only some messages from a flight having been acknowledged an implementation SHOULD retransmit the unacknowledged messages or fragments." This language appears inconsistent with Figure 12, where Record 1 has not been acknowledged but is also not retransmitted. It appears there is an implied handling of empty ACKs that isn't written down anywhere in Sec 7.2 Sec 9. Should there be any flow control limits on newconnectionid? Or should receivers be free to simply drop CIDs they can't handle? It might be good to specify. Finally, a really weird one. Reading this document and references to connection ID prompted to me to think how QUIC-LB could apply to DTLS. The result is here: URL Please note the rather unfortunate third-to-last paragraph. I'm happy to take the answer that this use case doesn't matter, since I made it up today. But if it does, it would be very helpful if (1) DTLS 1.3 clients MUST include a connectionid extension in their ClientHello, even if zero length, and/or (2) this draft updated 4.1.4 of 8446 to allow the server to include connectionid in HelloRetryRequest even if the client didn't offer it. Thoughts? NITS: s/select(HandshakeType)/select(msg_type). Though with pseudocode your mileage may vary as to what's clearer. s/consitute/constitute Sec 5.7 In table 1, why include one ACK in the diagram but not the other? It's clear from the note, but the figure is a weird omission.
Addressed in URL

configured not to perform a cookie exchange.  The default SHOULD be that the exchange is performed, however.  In addition, the server MAY choose not to do a cookie exchange when a session is resumed or, more <del> generically, when the DTLS handshake uses a PSK-based key exchange. Servers which process 0-RTT requests and send 0.5-RTT responses without a cookie exchange risk being used in an amplification attack if the size of outgoing messages greatly exceeds the size of those that are received.  A server SHOULD limit the amount of data it sends toward a client address before it verifies that the client is able to receive data at that address.  A client address is valid after a cookie exchange or handshake completion.  A server MAY apply a higher limit based on heuristics, such as if the client uses the same IP address as the connection on which the cookie was created.  Clients MUST be prepared to do a cookie exchange with every handshake. </del> <ins> generically, when the DTLS handshake uses a PSK-based key exchange and the IP address matches one associated with the PSK.  Servers which process 0-RTT requests and send 0.5-RTT responses without a cookie exchange risk being used in an amplification attack if the size of outgoing messages greatly exceeds the size of those that are received.  A server SHOULD limit the amount of data it sends toward a client address to three times the amount of data sent by the client before it verifies that the client is able to receive data at that address.  A client address is valid after a cookie exchange or handshake completion.  Clients MUST be prepared to do a cookie exchange with every handshake.  Note that cookies are only valid for the existing handshake and cannot be stored for future handshakes. </ins> If a server receives a ClientHello with an invalid cookie, it MUST terminate the handshake with an "illegal_parameter" alert.  This