is always associated with exactly one RtpTransceiver.  However, in certain cases where an "m=" section has been rejected, as discussed in sec.subsequent-offers below, that "m=" section will be "recycled" <del> and associated with a new RtpTransceiver with a new mid value. </del>  RtpTransceivers can be created explicitly by the application or implicitly by calling setRemoteDescription with an offer that adds in RFC5888.  For each MediaStream referenced by more than one RtpTransceiver (by passing those MediaStreams as arguments to the addTrack and addTransceiver methods), a group of type "LS" MUST be <del> added that contains the mid values for each RtpTransceiver. </del>  Attributes that SDP permits to be at either the session level or the media level SHOULD generally be at the media level even if they are addTrack/addTransceiver used to create them) or have no MediaStream to reference because they were not created by addTrack/ addTransceiver.  If at least two such RtpTransceivers exist, a group <del> of type "LS" with the mid values of these RtpTransceivers MUST be </del>  added.  Otherwise, the offered "LS" group MUST be ignored and no corresponding group generated in the answer.

Has the following updates: made MID value consistent, 60.2) tagged pseudocode as artwork. artwork is ascii-art. 52) fixed 8843 section xref, 44) updated text in Section 5.2.2 ok, removed comment. 35) fixed xref in Section 5.2.1, 26) updated ICE text in Section 5.1.1 with Justin's proposed text. 4) This change adds normative text, requires AD approval NAME added keywords, 1)
Justin: RFC 5888 defines it as Media Stream Identification, and later uses "Mid Value", but I agree we should probably go with MID/mid values. Justin: MID is not quoted in other RFCs ,I believe. Jean: Thread on the EMAIL mailing list discussing these terms: URL
NAME has this been taken care of yet? I thought an earlier PR addressed this issue.
The summary of the ML discussion [URL] suggests the following formatting changes to 8829: mid value --> MID value "mid" value --> MID value
LGTM
52) [rfced] Throughout: has been converted to as applicable and we set the "type" attribute. Please review and let us know corrections are needed.
This does look quite right. Section 2.5.7 of RFC 7991 makes me think the callflow's should be done with type artwork with type "call-flow" not sourcecode. And the type for the ascii art should be "ascii-art" instead of ""
Should I make a PR or RFC-ED ?
NAME for input
I can see how the callflows in Sections 7.1, 7.2, and 7.3 were labeled pseudocode, since they look more like inputs for a callflow diagram generator (complete with comments), but I'm ok with them being labeled as artwork with type="ascii-art" (the type attribute has evolved to provide info to the output renderers. There's some discussion about it in Section 2.6.7 of this update to RFC 7991: URL)
NAME can you advise here?
I really don't care - I am happy with whatever NAME wants to use
I will convert the call flows labeled with to . is being deprecated. See Section 2.6.7: URL
works for me - thanks
44) [rfced] Sections 5.9, 5.10, 5.11, and 6: RFC 8843 [I-D.ietf-mmusic-sdp-bundle-negotiation] does not have a Section 8.2 or a Section 10.2. We have updated these to refer to 7.2 and 9.2, respectively. Please review. Original: In addition, prepare to demux RTP streams intended for this m= section based on the media formats supported by this m= section, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 10.2. ... For each specified SSRC that is signaled in the m= section, prepare to demux RTP streams intended for this m= section using that SSRC, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 10.2. ... If the answer contains valid bundle groups, discard any ICE components for the m= sections that will be bundled onto the primary ICE components in each bundle, and begin muxing these m= sections accordingly, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.2. ... When bundling, associating incoming RTP/RTCP with the proper m= section is defined in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 10.2.
Need section updates for BUNDLE.
Moving 10.2 to 9.2 looks right to me. However, 8.2 I think should be updated to 7.4.
35) [rfced] Section 5.2.2: We found this RFC Editor Note on : OLD: NEW: Please note that the "OLD" text does not match what we found in the provided draft (i.e., "[RFC5245], Section 4.3., paragraph 3" versus "[I-D.ietf-mmusic-ice-sip-sdp], Section 4.1"): Please review, and let us know if further changes are needed. (Note: "[RFC8839]" and "[RFC8840]" are the RFC numbers assigned to [I-D.ietf-mmusic-ice-sip-sdp] and [I-D.ietf-mmusic-trickle-ice-sip], respectively.) Currently:
Need to verify the references for the current text are correct.
Current text LGTM.
26) [rfced] Section 5.2.1: Please confirm that this citation is correct; we could not see a relationship between Section 14 of RFC 8843 [I-D.ietf-mmusic-sdp-bundle-negotiation] and the RTP header extension. Original: All MID values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per-PeerConnection counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 14.
Need to review latest BUNDLE doc
I think the reference should be to section 15.2 (not 14 ) URL
Agreed. There may be some other citation around MID generation (that suggests starting at 0) that would be even better to reference, if we can find it.
Section 17 of BUNDLE (URL) mentions a per-bundle-group counter. However I tend to think we should just update the ref to what Cullen mentions and close this out.
4) [rfced] Adam Roach previously requested that "All other documents in Cluster 238 that currently reference RFC 5245 should be updated to reference RFC 8445. ... any other references to RFC 5245 that I may have overlooked should also be updated." We believe this document intentionally refers to both RFCs. Please let us know if any updates are needed.
I reviewed this and it seems correct, although S 5.1.1 is a bit confusing when it says that , even though we explicitly allow 5245-ICE in S 3.5.5. NAME thoughts on this?
I think that what we probably want here is something like: NAME any further thoughts? Planning to mark this as editor-ready.
NAME in case he has thoughts on this
Get me back up to speed on all this ... My recollection is this 1) this was widely discussed in th WG and adam was on one end of the fence. 2) the connection performance and RFC8445 is worse than RFC5245 and thus Cisco does not plan to move to RFC8445 until there is a new version that brings it back to 5245 performance. We want it to be OK to use either and specifically we do not want JSEP to require 8445. This is a major and significant change and certainly not something the AD should do in auth48. Is that about right
Just for clarity, this wasn't a unilateral AUTH48 change. The current state of ICE support in the documents is the result of a 55-message, 8-week consultation with the community in the late summer/early fall of 2018. I'd really rather not re-litigate this; but, if that's what needs to happen, then it's a matter of getting NAME or Barry to bring it back to the ART community again rather than the few of us working through it in github (which would be a very opaque and cliquish way to handle things). The proposal that had broad buy-in from the community [1] was around the specific text: Accompanied by the specific note that "RFC 8445 would be a normative reference for both documents, while RFC 5245 would be informative." So, to the crux of this ticket: yes, JSEP would reference both. 8445 normatively, and 5285 informatively. If the contents of this document vary substantively from that community-vetted text I cite above, then you'd definitely need sign-off by the current ART ADs. (Tagging NAME on this statement for her awareness.) _ for details
OK - thanks and I agree.
NAME in the following sentence: You meant RFC 5485 (ICE) instead of 5285 (A General Mechanism for RTP Header Extensions), correct? The document currently lists 8445 (ICE) normatively and 5485 (ICE) informatively. So no change there. It's my understanding that I should change the following: Current (Section 5.1.1, Usage Requirements): ICE, as specified in [RFC8445], MUST be used. Note that the remote endpoint may use a lite implementation; implementations MUST properly handle remote endpoints that do ICE-lite. Proposed (text from NAME with small tweaks): ICE, as specified in [RFC8445], MUST be used. Note that the remote endpoint may use an older version of ICE or ICE Lite; implementations MUST properly handle remote endpoints that use ICE or ICE Lite as specified in [RFC5245].
NAME -- Yep, that is all consistent with my understanding. (And apparently I'm going to carry that 5284/5485 typo around pretty much forever. )
This mostly SGTM. For the specific text, I think we'll need to ensure that the reader is clear that remote endpoints may use RFC 5245 ICE and also ICE Lite (regardless of version). Perhaps something like the following:
That looks good to me and make things very clear
1) [rfced] Please insert any keywords (beyond those that appear in the title) for use on URL
Should probably add webrtc and sdp
agreed. also: negotiation signaling peerconnection api ice rtp offer answer

is always associated with exactly one RtpTransceiver.  However, in certain cases where an "m=" section has been rejected, as discussed in sec.subsequent-offers below, that "m=" section will be "recycled"  <ins> and associated with a new RtpTransceiver with a new MID value. </ins> RtpTransceivers can be created explicitly by the application or implicitly by calling setRemoteDescription with an offer that adds in RFC5888.  For each MediaStream referenced by more than one RtpTransceiver (by passing those MediaStreams as arguments to the addTrack and addTransceiver methods), a group of type "LS" MUST be  <ins> added that contains the MID values for each RtpTransceiver. </ins> Attributes that SDP permits to be at either the session level or the media level SHOULD generally be at the media level even if they are addTrack/addTransceiver used to create them) or have no MediaStream to reference because they were not created by addTrack/ addTransceiver.  If at least two such RtpTransceivers exist, a group  <ins> of type "LS" with the MID values of these RtpTransceivers MUST be </ins> added.  Otherwise, the offered "LS" group MUST be ignored and no corresponding group generated in the answer.


Likewise, the requirements for parameters on templated links are the same as those for a Link header field.  This specification defines additional semantics for the "var-base" parameter on templated links; see below.

Has there been any consideration of allowing a URI Template for the parameter? A particular use case would be for a collection resource that includes links from each item in the collection. If the media type supports fragments, then the item link could be templatized to point from specific locations in the representation. If we had a collection of books represented as an object with an array, and the instance media type allowed JSON Pointers: As an example of links between the full book resource and another resource, so as not to have to fetch the entire book resource if it is not needed, an author link template could be something like this (ignoring the likelihood of multiple authors): I was looking at this I-D in comparison to the (currently tabled) JSON Hyper-Schema project, and I think that anchor templates are the most notable relevant Hyper-Schema feature that is not present here. I would love to be able to use a revived Hyper-Schema as a bridge between a link-template header field and JSON-compatible data.

Likewise, the requirements for parameters on templated links are the same as those for a Link header field. <ins> However, the "anchor" parameter MAY contain a URI Template.  For example: Here, the link to the author for a particular book in a list of books can be found by following the link template. </ins> This specification defines additional semantics for the "var-base" parameter on templated links; see below.


For example: indicates that a resource with the relation type <del> "https://example.org/rel/user" can be found by interpolating the </del>  "username" variable into the template given. The target for the link (as defined in WEB-LINKING) is the result of For example: indicates that a resource with the relation type <del> "https://example.org/rel/widget" can be found by interpolating the </del>  "https://example.org/vars/widget_id" variable into the template given.

"interpolate" feels very odd. Other choices would be "expanding" or "substituting". I am not picky about the exact choice, but the current terminology seems odd.
The URI Template RFC uses 'expand', so that seems most appropriate.

For example: indicates that a resource with the relation type  <ins> "https://example.org/rel/user" can be found by expanding the </ins> "username" variable into the template given. The target for the link (as defined in WEB-LINKING) is the result of For example: indicates that a resource with the relation type  <ins> "https://example.org/rel/widget" can be found by expanding the </ins> "https://example.org/vars/widget_id" variable into the template given.


This document format is identical to the payload of the HTTP "Link" header field as defined in Section 3 of RFC8288, more specifically by <del> its ABNF production rule for "Link" and subsequent ones. </del>  The assigned media type for this format is "application/linkset". "application/linkset" documents will depend on which URI is used as context.  4.2. This document format uses JSON RFC8259 as the syntax to represent a links. The value of the internationalized target attribute is an array <del> that contains one or more JSON objects.  The name of the first member of such JSON object is "value" and its value is the actual content (in its unescaped version) of the internationalized target </del>  attribute, i.e. the value of the attribute from which the encoding <del> and language information are removed.  The name of the optional second member of such JSON object is "language" and its value is the language tag RFC5646 for the language in which the attribute content is conveyed. </del>  The following example illustrates how the "title*" target attribute defined by RFC8288 is represented in a link target object. 7.2.  Open Journal Systems (OJS) is an open-source software for the management of peer-reviewed academic journals, and is created by the Public Knowledge Project (PKP), released under the GNU General Public

Clarifications regarding application/linkset In order to address URL, added wording (1) to clarify the distinction between application/linkset and application/link-format defined in RFC6690) and (2) to indicate that encoding of application/linkset is UTF-8. This includes addition of appropriate references. Value for internationalized target attributes must be unordered In order to address URL Changed the language to remove the suggestion that the JSON objects used in the array for inernationalized target attributes required ordering of members. A JSON object is defined as unordered collection of zero or more name/value pairs and as such suggesting ordering is inappropriate. Use example including 'anchor' with a fragment In order to address URL : Updated the application/linkset example with one link that has a URI with fragment as anchor. Added Implementation Status section Added a section about the FAIR Signposting Profile (see URL) community specification that promotes the use of Linkset.
looks good to me. thanks for the edits and feel free to merge, NAME
In the mail thread discussing the perceived overlap between application/linkset defined in the I-D and application/link-format defined in RFC6690, NAME suggests .
Proposal to address with
hi NAME I think we addressed this issue, so probably it can be closed.
I'll close this one. I invited you to be an admin on this repo so you can close the others ;)
Copied from URL; here's the comments: From NAME I think using one of the examples with an anchor including a fragment can diversify (at least visibly) what's possible - this is of course beside the definition of stating (or referring to RFC 8288) as to what an anchor value may be. So like the copyright example in URL which refers to a particular part of the document, the following example is about the correction section in the document made by an author: (or whatever example is more clear using #) From NAME sorry for leaving this open for so long. if you think this is somehow is essential, could you maybe explain why? otherwise we think that of course this can be done, but we're not quite sure why would have to point it out specifically. From NAME As said, using diverse examples can (indirectly) help the reader. It is an editorial call. From NAME i'll leave it up to NAME to add examples if he feels the need. if not, let's close this one. it is the last open issue! yay!
Proposal to address with
hi NAME NAME I think we addressed this issue, so probably it can be closed.
Copied from URL ; here's the comments. raised by NAME at URL In draft-wilde-linkset-07 , "Section 4.2.4.2. Internationalized Target Attributes" seems to indicate that the order of attributes of JSON objects representing the value of an internationalized target attribute is significant:
Proposal to address with
hi NAME NAME I think we addressed this issue, so probably it can be closed. In draft-wilde-linkset-07 , "Section 4.2.4.2. Internationalized Target Attributes" seems to indicate that the order of attributes of JSON objects representing the value of an internationalized target attribute is significant: The use of "first" and "second" here seems to imply that a value of this form does not conform to the specification: { "language": "de", "value": "nachstes Kapitel" } because the attributes are in the wrong order. Is it the intention that this be considered wrong? That might be problematic because some popular JSON handling mechanisms make it difficult or impossible for developers to control the order in which attributes are emitted. If the use of "first" and "second" here isn't meant to impose an ordering requirement, it might be worth considering rewording this. But if there is an ordering requirement, it might be good to make that clearer. Ian Griffiths URL
we looked at CoRE at the very beginning of the linkset work. CoRE does look similar (and it is), but we decided that the approach wasn't matching our needs. Perhaps some of that can make it into the draft. Sure, I'll start it next week.

This document format is identical to the payload of the HTTP "Link" header field as defined in Section 3 of RFC8288, more specifically by  <ins> its ABNF production rule for "Link" and subsequent ones.  Whereas the HTTP "Link" Header field depends on HTTP and hence on RFC0822 for its encoding, the format specified here is encoded as UTF-8 RFC3629. </ins> The assigned media type for this format is "application/linkset". "application/linkset" documents will depend on which URI is used as context. <ins> It should be noted that the "application/linkset" format specified here is different than the "application/link-format" format specified in RFC6690 in that the former fully matches the payload of the HTTP "Link" header as defined in Section 3 of RFC8288, whereas the latter introduces constraints on that definition to meet requirements for Constrained RESTful Environments. </ins> 4.2. This document format uses JSON RFC8259 as the syntax to represent a links. The value of the internationalized target attribute is an array  <ins> that contains one or more JSON objects.  The name of one member of such JSON object is "value" and its value is the actual content (in its unescaped version) of the internationalized target </ins> attribute, i.e. the value of the attribute from which the encoding  <ins> and language information are removed.  The name of another, optional, member of such JSON object is "language" and its value is the language tag RFC5646 for the language in which the attribute content is conveyed. </ins> The following example illustrates how the "title*" target attribute defined by RFC8288 is represented in a link target object. 7.2. <ins> The FAIR Signposting Profile is a community specification aimed at improving machine navigation of scholarly objects on the web through the use of typed web links pointing at e.g.  web resources that are part of a specific object, persistent identifiers for the object and its authors, license information pertaining to the object.  The specification encourages the use of Linksets and initial implementations are ongoing, for example, for the open source Dataverse data repository platform that was initiated by Harvard University and is meanwhile used by research institutions, worldwide. 7.3. </ins> Open Journal Systems (OJS) is an open-source software for the management of peer-reviewed academic journals, and is created by the Public Knowledge Project (PKP), released under the GNU General Public


These client-generated CIDs might not conform to the expectations of the routing algorithm and therefore not be routable by the load <del> balancer.  Those that are not routable are "non-compliant DCIDs" and receive similar treatment regardless of why they're non-compliant: </del>  The config rotation bits (config-rotation) may not correspond to an active configuration.  Note: a packet with a DCID that indicates 5-tuple routing (see config-failover) is always <del> compliant. </del>  The DCID might not be long enough for the decoder to process. The extracted server mapping might not correspond to an active server. <del> All other DCIDs are compliant. </del>  <del> Load balancers MUST forward packets with compliant DCIDs to a server </del>  in accordance with the chosen routing algorithm. <del> Load balancers SHOULD drop short header packets with non-compliant </del>  DCIDs. <del> The routing of long headers with non-compliant DCIDs depends on the </del>  server ID allocation strategy, described in sid-allocation.  However, the load balancer MUST NOT drop these packets, with one exception. <del> Load balancers MAY drop packets with long headers and non-compliant </del>  DCIDs if and only if it knows that the encoded QUIC version does not <del> allow a non- compliant DCID in a packet with that signature.  For </del>  example, a load balancer can safely drop a QUIC version 1 Handshake <del> packet with a non-compliant DCID, as a version 1 Handshake packet sent to a QUIC-LB compliant server will always have a server- generated compliant CID.  The prohibition against dropping packets with long headers remains for unknown QUIC versions. </del>  Furthermore, while the load balancer function MUST NOT drop packets, the device might implement other security policies, outside the scope of this specification, that might force a drop. <del> Servers that receive packets with noncompliant CIDs MUST use the available mechanisms to induce the client to use a compliant CID in future packets.  In QUIC version 1, this requires using a compliant </del>  CID in the Source CID field of server-generated long headers. 4.2. There are conditions described below where a load balancer routes a <del> packet using an "arbitrary algorithm."  It can choose any algorithm, </del>  without coordination with the servers, but the algorithm SHOULD be deterministic over short time scales so that related packets go to the same server.  The design of this algorithm SHOULD consider the version-invariant properties of QUIC described in QUIC-INVARIANTS to maximize its robustness to future versions of QUIC. <del> An arbitrary algorithm MUST NOT make the routing behavior dependent on any bits in the first octet of the QUIC packet header, except the </del>  first bit, which indicates a long header.  All other bits are QUIC version-dependent and intermediaries SHOULD NOT base their design on version-specific templates. <del> For example, one arbitrary algorithm might convert a non-compliant DCID to an integer and divided by the number of servers, with the modulus used to forward the packet.  The number of servers is usually </del>  consistent on the time scale of a QUIC connection handshake.  Another might simply hash the address/port 4-tuple.  See also version- invariance. A QUIC-LB configuration MAY significantly over-provision the server ID space (i.e., provide far more codepoints than there are servers) to increase the probability that a randomly generated Destination <del> Connection ID is non- compliant. </del>  Conceptually, each configuration has its own set of server ID allocations, though two static configurations with identical server In the static allocation method, the configuration agent assigns at least one server ID to each server. <del> When forwarding a packet with a long header and non-compliant DCID, load balancers MUST forward packets with long headers and non- compliant DCIDs using an arbitrary algorithm as specified in arbitrary-algorithm. </del>  4.3.2. Note that when the load balancer's table for a configuration is empty, all incoming DCIDs corresponding to that configuration are <del> non-compliant by definition. </del>  <del> The handling of a non-compliant long-header packet depends on the reason for non-compliance.  The load balancer MUST applyt this logic: </del>  If the config rotation bits do not match a known configuration, <del> the load balancer routes the packet using an arbitrary algorithm (see arbitrary-algorithm). </del>  If there is a matching configuration, but the CID is not long enough to apply the algorithm, the load balancer skips the first octets, up to the server ID length.  If this server ID matches a known server ID for that configuration, it forwards the packet accordingly and takes no further action.  If it does not match, it <del> routes using an arbitrary algorithm and adds the new server ID to </del>  that server's table entry. <del> If the sole reason for non-compliance is that the server ID is not </del>  in the load balancer's table, the load balancer routes the packet <del> with an arbitrary algorithm.  It adds the decoded server ID to table entry for the server the algorithm chooses and forwards the packet accordingly. </del>  4.3.2.3. The Block Cipher CID Algorithm, by using a full 16 octets of plaintext and a 128-bit cipher, provides higher cryptographic <del> protection and detection of non-compliant connection IDs.  However, it also requires connection IDs of at least 17 octets, increasing </del>  overhead of client-to-server packets. 5.3.1. connection attempts using any new QUIC versions that begin connections with a short header. <del> If a Retry Service is integrated with a QUIC-LB compliant load </del>  balancer, it can verify that the Destination Connection ID is <del> compliant, and only admit non-Initial packets with compliant DCIDs.  As the Connection ID encoding is invariant across QUIC versions, the Retry Service can do this for all short headers. </del>  Nothing in this section prevents Retry Services from making basic syntax correctness checks on packets with QUIC versions that it understands (e.g., enforcing the Initial Packet datagram size minimum <del> in version 1) and dropping packets that are not compliant with the </del>  QUIC specification. 7.2. The maximum Connection ID length could be below the minimum necessary for one or more encoding algorithms. <del> non-compliant provides guidance about how load balancers should handle non-compliant DCIDs.  This guidance, and the implementation of an algorithm to handle these DCIDs, rests on some assumptions: </del>  Incoming short headers do not contain DCIDs that are client- generated. use with minimal risk of version- dependence. If these assumptions are invalid, this specification is likely to <del> lead to loss of packets that contain non-compliant DCIDs, and in extreme cases connection failure. </del>  Some load balancers might inspect elements of the Server Name Indication (SNI) extension in the TLS Client Hello to make a routing

and
I'd suggest 'Fallback' or another word than arbitrary. A definition of Arbitrary is: "Based on random choice or personal whim, rather than any reason or system." In fact, there are sensible constraints on this algorithm to ensure routing works correctly for non-compliant CIDs and connections don't fail.
Agreed.
In PR I suggested non-routable, though I realize non-conformant may also be an option. The sentence which caused me to suggest non-routable is: URL I'm happy to write a PR if others find non-compliant potentially confusing as well.
I like it. Let's go with it.
Thanks, this is a lot easier to read for me.

These client-generated CIDs might not conform to the expectations of the routing algorithm and therefore not be routable by the load  <ins> balancer.  Those that are not routable are "unroutable DCIDs" and receive similar treatment regardless of why they're unroutable: </ins> The config rotation bits (config-rotation) may not correspond to an active configuration.  Note: a packet with a DCID that indicates 5-tuple routing (see config-failover) is always  <ins> routable. </ins> The DCID might not be long enough for the decoder to process. The extracted server mapping might not correspond to an active server.  <ins> All other DCIDs are routable. </ins>  <ins> Load balancers MUST forward packets with routable DCIDs to a server </ins> in accordance with the chosen routing algorithm.  <ins> Load balancers SHOULD drop short header packets with unroutable </ins> DCIDs.  <ins> The routing of long headers with unroutable DCIDs depends on the </ins> server ID allocation strategy, described in sid-allocation.  However, the load balancer MUST NOT drop these packets, with one exception.  <ins> Load balancers MAY drop packets with long headers and unroutable </ins> DCIDs if and only if it knows that the encoded QUIC version does not  <ins> allow an unroutable DCID in a packet with that signature.  For </ins> example, a load balancer can safely drop a QUIC version 1 Handshake  <ins> packet with an unroutable DCID, as a version 1 Handshake packet sent to a QUIC-LB routable server will always have a server-generated routable CID.  The prohibition against dropping packets with long headers remains for unknown QUIC versions. </ins> Furthermore, while the load balancer function MUST NOT drop packets, the device might implement other security policies, outside the scope of this specification, that might force a drop.  <ins> Servers that receive packets with unroutable CIDs MUST use the available mechanisms to induce the client to use a routable CID in future packets.  In QUIC version 1, this requires using a routable </ins> CID in the Source CID field of server-generated long headers. 4.2. There are conditions described below where a load balancer routes a  <ins> packet using a "fallback algorithm."  It can choose any algorithm, </ins> without coordination with the servers, but the algorithm SHOULD be deterministic over short time scales so that related packets go to the same server.  The design of this algorithm SHOULD consider the version-invariant properties of QUIC described in QUIC-INVARIANTS to maximize its robustness to future versions of QUIC.  <ins> A fallback algorithm MUST NOT make the routing behavior dependent on any bits in the first octet of the QUIC packet header, except the </ins> first bit, which indicates a long header.  All other bits are QUIC version-dependent and intermediaries SHOULD NOT base their design on version-specific templates.  <ins> For example, one fallback algorithm might convert a unroutable DCID to an integer and divided by the number of servers, with the modulus used to forward the packet.  The number of servers is usually </ins> consistent on the time scale of a QUIC connection handshake.  Another might simply hash the address/port 4-tuple.  See also version- invariance. A QUIC-LB configuration MAY significantly over-provision the server ID space (i.e., provide far more codepoints than there are servers) to increase the probability that a randomly generated Destination  <ins> Connection ID is unroutable. </ins> Conceptually, each configuration has its own set of server ID allocations, though two static configurations with identical server In the static allocation method, the configuration agent assigns at least one server ID to each server.  <ins> When forwarding a packet with a long header and unroutable DCID, load balancers MUST forward packets with long headers and unroutable DCIDs using an fallback algorithm as specified in fallback-algorithm. </ins> 4.3.2. Note that when the load balancer's table for a configuration is empty, all incoming DCIDs corresponding to that configuration are  <ins> unroutable by definition. </ins>  <ins> The handling of an unroutable long-header packet depends on the reason for unroutability.  The load balancer MUST applyt this logic: </ins> If the config rotation bits do not match a known configuration,  <ins> the load balancer routes the packet using a fallback algorithm (see fallback-algorithm). </ins> If there is a matching configuration, but the CID is not long enough to apply the algorithm, the load balancer skips the first octets, up to the server ID length.  If this server ID matches a known server ID for that configuration, it forwards the packet accordingly and takes no further action.  If it does not match, it  <ins> routes using a fallback algorithm and adds the new server ID to </ins> that server's table entry.  <ins> If the sole reason for unroutability is that the server ID is not </ins> in the load balancer's table, the load balancer routes the packet  <ins> with a fallback algorithm.  It adds the decoded server ID to table entry for the server the algorithm chooses and forwards the packet accordingly. </ins> 4.3.2.3. The Block Cipher CID Algorithm, by using a full 16 octets of plaintext and a 128-bit cipher, provides higher cryptographic  <ins> protection and detection of unroutable connection IDs.  However, it also requires connection IDs of at least 17 octets, increasing </ins> overhead of client-to-server packets. 5.3.1. connection attempts using any new QUIC versions that begin connections with a short header.  <ins> If a Retry Service is integrated with a QUIC-LB routable load </ins> balancer, it can verify that the Destination Connection ID is  <ins> routable, and only admit non-Initial packets with routable DCIDs. As the Connection ID encoding is invariant across QUIC versions, the Retry Service can do this for all short headers. </ins> Nothing in this section prevents Retry Services from making basic syntax correctness checks on packets with QUIC versions that it understands (e.g., enforcing the Initial Packet datagram size minimum  <ins> in version 1) and dropping packets that are not routable with the </ins> QUIC specification. 7.2. The maximum Connection ID length could be below the minimum necessary for one or more encoding algorithms.  <ins> unroutable provides guidance about how load balancers should handle unroutable DCIDs.  This guidance, and the implementation of an algorithm to handle these DCIDs, rests on some assumptions: </ins> Incoming short headers do not contain DCIDs that are client- generated. use with minimal risk of version- dependence. If these assumptions are invalid, this specification is likely to  <ins> lead to loss of packets that contain unroutable DCIDs, and in extreme cases connection failure. </ins> Some load balancers might inspect elements of the Server Name Indication (SNI) extension in the TLS Client Hello to make a routing


To avoid this, the configuration agent SHOULD issue QUIC-LB configurations to mutually distrustful servers that have different <del> keys for encryption algorithms.  The load balancers can distinguish these configurations by external IP address, or by assigning different values to the config rotation bits (config-rotation).  Note that either solution has a privacy impact; see multiple-configs. These techniques are not necessary for the plaintext algorithm, as it does not attempt to conceal the server ID. </del>  11.5.

Sec 11.4 recommends either separating mistrustful servers by IP, or assigning them different config rotation bits. The text is not adequate. Separating by IP address undermines the privacy value of ECHO & DoH (see the MAPRG IETF 110 talk) Any sub-IP routing has to be SNI-switched; if ECHO is operating, the load balancer must be a "client-facing server" in the ECHO architecture (draft-ietf-tls-esni Sec 3.1). Doing SNI switching as an ECHO server and then just encoding the result in the config rotation bits leaks the information they're trying to conceal. It might be worth it to fix up the "arbitrary algorithm" text to consider possible SNI switching. As we migrate towards ECHO and DoH, maybe the best we can do is give all tenants on an IP the same config and try to obscure their co-tenancy as much as possible.

To avoid this, the configuration agent SHOULD issue QUIC-LB configurations to mutually distrustful servers that have different  <ins> keys for encryption algorithms.  In many cases, the load balancers can distinguish these configurations by external IP address. However, assigning multiple entities to an IP address is complimentary with concealing DNS requests (e.g., DoH RFC8484) and the TLS Server Name Indicator (SNI) (I-D.ietf-tls-esni) to obscure the ultimate destination of traffic.  While the load balancer's fallback algorithm (fallback-algorithm) can use the SNI to make a routing decision on the first packet, there are three ways to route subsequent packets: all co-tenants can use the same QUIC-LB configuration, leaking the server mapping to each other as described above; co-tenants can be issued one of up to three configurations distinguished by the config rotation bits (config-rotation), exposing information about the target domain to the entire network; or tenants can use 4-tuple routing in their CIDs (in which case they SHOULD disable migration in their connections), which neutralizes the value of QUIC-LB but preserves privacy. When configuring QUIC-LB, administrators must evaluate the privacy tradeoff considering the relative value of each of these properties, given the trust model between tenants, the presence of methods to obscure the domain name, and value of address migration in the tenant use cases. As the plaintext algorithm makes no attempt to conceal the server mapping, these deployments SHOULD simply use a common configuration. </ins> 11.5.


address validation. The 96 bit unique token number is set to a random value using a <del> cryptography- grade random number generator. </del>  The token key identifier and the corresponding AEAD key and AEAD IV are provisioned by the configuration agent. The input plaintext for the AEAD is the token body.  The output ciphertext of the AEAD is transmitted in place of the token body. <del> The AEAD Checksum is computed as part of the AEAD encryption process, and is verified during decryption. </del>  7.3.2. no token. The service SHOULD decrypt incoming tokens.  The service SHOULD drop <del> packets with unknown key sequence, or an AEAD checksum that does not match the expected value.  (By construction, the AEAD checksum will only match if the client IP Address also matches.) </del>  <del> If the token checksum passes, and the ODCIL and RSCIL fields are both zero, then this is a NEW_TOKEN token generated by the server. </del>  Processing of NEW_TOKEN tokens is subtly different from Retry tokens, as described below.

detail info: fix a typo. change AEAD checksum to AEAD ICV(defined in rfc4106)
Hi martin: is not a standard name of AEAD verification message, which should be , see section 6 of rfc4106

address validation. The 96 bit unique token number is set to a random value using a  <ins> cryptography-grade random number generator. </ins> The token key identifier and the corresponding AEAD key and AEAD IV are provisioned by the configuration agent. The input plaintext for the AEAD is the token body.  The output ciphertext of the AEAD is transmitted in place of the token body.  <ins> The AEAD Integrity Check Value(ICV), defined in Section 6 of RFC4106, is computed as part of the AEAD encryption process, and is verified during decryption. </ins> 7.3.2. no token. The service SHOULD decrypt incoming tokens.  The service SHOULD drop  <ins> packets with unknown key sequence, or an AEAD ICV that does not match the expected value.  (By construction, the AEAD ICV will only match if the client IP Address also matches.) </ins>  <ins> If the token verification passes, and the ODCIL and RSCIL fields are both zero, then this is a NEW_TOKEN token generated by the server. </ins> Processing of NEW_TOKEN tokens is subtly different from Retry tokens, as described below.


The tokens are protected using AES128-GCM as follows: <del> The token key and IV are retrieved using the Key Sequence. </del>  <del> The nonce, N, is formed by combining the IV with the 96 bit unique token number.  The 96 bits of the unique token number are left- padded with zeros to the size of the IV.  The exclusive OR of the padded unique token number and the IV forms the AEAD nonce. </del>  The associated data is a formatted as a pseudo header by combining the cleartext part of the token with the IP address of the client. The Shared-State Retry Service defined in shared-state-retry describes the format of retry tokens or new tokens protected and encrypted using AES128-GCM.  Each token includes a 96 bit randomly <del> generated unique token number, and an 8 bit identifier of the AES-GCM encryption key.  There are three important security considerations for these tokens: </del>  An attacker that obtains a copy of the encryption key will be able to decrypt and forge tokens.

Made the changes to merge this.
Hi martin: The defination of and brought me a great confusion when I implement the share-state retry service. Though finally I got what the draft want to express, I still suggest we should give more information about them According to section 1.5 of rfc5084: According to section 3.4 of rfc5116 I guess that in current draft is the define in rfc5116, is just a random value(or a incrementing number) to generate . If I were true, please consider my PR for my suggestion.
Additional, it's no need to make the length of (current draft define) variable, just 96 bit is sufficient. Current aes-128-gcm related cipher suites all use this value
We can also add some illustration of , draft use in other place

The tokens are protected using AES128-GCM as follows:  <ins> The Key Sequence is the 8 bit identifier to retrieve the token key and IV. </ins>  <ins> The AEAD IV, is a 96 bit data which produced by implementer's custom AEAD IV derivation function. The AEAD nonce, N, is formed by combining the AEAD IV with the 96 bit unique token number.  The 96 bits of the unique token number are left-padded with zeros to the size of the IV.  The exclusive OR of the padded unique token number and the AEAD IV forms the AEAD nonce. </ins> The associated data is a formatted as a pseudo header by combining the cleartext part of the token with the IP address of the client. The Shared-State Retry Service defined in shared-state-retry describes the format of retry tokens or new tokens protected and encrypted using AES128-GCM.  Each token includes a 96 bit randomly  <ins> generated unique token number, and an 8 bit identifier used to get the AES-GCM encryption context.  The AES-GCM encryption context contains a 128 bit key and an AEAD IV.  There are three important security considerations for these tokens: </ins> An attacker that obtains a copy of the encryption key will be able to decrypt and forge tokens.


these allocations time out and are freed for reuse by servers that have recently joined the pool.  5. Encryption in the algorithms below uses the AES-128-ECB cipher. 5.1. The Plaintext CID Algorithm makes no attempt to obscure the mapping <del> of connections to servers, significantly increasing linkability.  The format is depicted in the figure below. </del>  5.1.1. For static SID allocation, the server ID length is limited to 16 <del> octets.  There are no parameters specific to this algorithm. </del>  5.1.2. When a server needs a new connection ID, it encodes one of its assigned server IDs in consecutive octets beginning with the second. <del> All other bits in the connection ID, except for the first octet, MAY be set to any other value.  These other bits SHOULD appear random to observers. </del> 5.2. pool, and determines a server ID length (in octets) sufficiently large to encode all server IDs, including potential future servers. <del> The configuration agent also selects a nonce length and an 16-octet AES-ECB key to use for connection ID decryption.  The nonce length MUST be at least 8 octets and no more than 16 octets.  The nonce length and server ID length MUST sum to 19 or fewer octets, but SHOULD sum to 15 or fewer to allow space for server use. </del>  5.2.2. 5.3.1. <del> If server IDs are statically allocated, the server ID length MUST be no more than 12 octets, to provide servers adequate entropy to generate unique CIDs. </del>  The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption. 5.3.3. <del> When generating a routable connection ID, the server MUST choose a connection ID length between 17 and 20 octets.  The server writes its server ID into the server ID octets and arbitrary bits into the remaining bits.  These arbitrary bits MAY encode additional information, and MUST differ between connection IDs.  Bits in the eighteenth, nineteenth, and twentieth octets SHOULD appear essentially random to observers.  The first octet is reserved as described in first-octet. The server then encrypts the second through seventeenth octets using the 128-bit AES-ECB cipher. </del>  6. server ID allocation method, and the relevant parameters for that algorithm. <del> All algorithms require a server ID length.  If server IDs are statically allocated, the load balancer MUST receive the full table of mappings, and each server must receive its assigned SID(s), from the configuration agent. For Stream Cipher CID Routing, the servers and load balancer also MUST have a common understanding of the key and nonce length. </del>  <del> For Block Cipher CID Routing, the servers and load balancer also MUST have a common understanding of the key. </del>  Note that server IDs are opaque bytes, not integers, so there is no notion of network order or host order.

Writing it, I'm not sure that this makes anything conceptually clearer, but I'm open to merging it.
The clear text stream cipher and block cipher formats are specified as: I think that this difference is not necessary. In the block cipher format, the first bytes are effectively used as a nonce: using the same value and the same server ID would result in the same initial 16 bytes, with exactly the same privacy effect as failing to properly initialize the nonce in the stream-cipher case. I wish we could unify these two formats, to: With just three parameters: The scope of encryption would be 0 bytes for the clear text format, 16 bytes for the block cipher format, and a value greater than server-ID length and lower than the length of the CID for the stream cipher format. This will of course require that the first bytes of the server-use field act as a nonce. Alternately, we could have: Which achieves the same unification result, but is maybe a bit more explicit.
I think this would simplify things, yes. Though it might be worth it to separate the server-use bit into a nonce and server-use, since one has uniqueness constraints and one doesn't.
Thinking of that a bit more, it is possible to further simplify. In the case of the stream cipher, the "nonce" part cannot be more than 16 bytes long. This means that the nonce will include: All of the "server-use" bytes if the are fewer than 16 such bytes The initial 16 bytes of the "server use" field if there are more With that, for all schemes we will require just two parameters, the length of the SID and the length of the CID. This simplifies configuration and APIs. At that point, the "nonce" requirement is not particularly onerous. There is already an operational requirement that CID as a whole be unique -- conflicting values would lead to packets delivered to the wrong context. If we use "all the bytes" then the server-use field is effectively a nonce. The requirement only applies to the cases where the server use field is larger than 16 bytes. We can mention it, the same way we should mention it for the block cipher. There is a small technical weakness, because the uniqueness of the CID could also result from the randomness of the first byte. This could be fixed by using the first byte in the encryption passes: use first-byte + server ID when encrypting the nonce if the server ID is fewer than 16 bytes. (Is there really a use case for a 16 bytes server ID? Would 15 bytes be sufficient?)
I like how this is developing. I should clarify that the "CID length" is actually the minimum length of the CID -- that's all the LB will look at. The server can pad it out to 20B but that's not relevant to the algorithm. Regarding the first byte: if using length-self-encoding, there will be little or not entropy there. I don't think the case for a 16B SID is compelling.

these allocations time out and are freed for reuse by servers that have recently joined the pool. <ins> 4.4. All connection IDs use the following format: Each configuration specifies the length of the Server ID and Nonce fields, with limits defined for each algorithm. The Server ID is assigned to each server in accordance with sid- allocation.  Dynamically allocated SIDs are limited to seven octets or fewer.  Statically allocated ones have different limits for each algorithm. The Nonce is selected by the server when it generates a CID.  As the name implies, a server MUST use a nonce no more than once when generating a CID for a given server ID and unique set of configuration parameters.  Limits on the length of the nonce are different for each algorithm. The First Octet, Server ID, and Nonce comprise the minimum length Connection ID for any given algorithm.  The load balancer need not know the full connection ID length to successfully process a packet, given that it is of minimum size. The For Server Use field has any value and length chosen by the server, within the connection ID length limits in the operative QUIC version.  It SHOULD appear random and SHOULD NOT link two connection IDs to the same connection, or indicate they originate from the same server. </ins> 5. Encryption in the algorithms below uses the AES-128-ECB cipher. 5.1. The Plaintext CID Algorithm makes no attempt to obscure the mapping  <ins> of connections to servers, significantly increasing linkability. </ins> 5.1.1. For static SID allocation, the server ID length is limited to 16  <ins> octets.  The nonce length MUST be zero. </ins> 5.1.2. When a server needs a new connection ID, it encodes one of its assigned server IDs in consecutive octets beginning with the second.  5.2. pool, and determines a server ID length (in octets) sufficiently large to encode all server IDs, including potential future servers.  <ins> The nonce length MUST be no fewer than 8 and no more than 16 octets. The server ID length and nonce length MUST sum to 19 or fewer octets, and SHOULD sum to 15 or fewer octets to allow space for server use. </ins> 5.2.2. 5.3.1.  <ins> The server ID length MUST be no more than 12 octets.  The server ID length and nonce length MUST sum to exactly 16 octets. </ins> The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption. 5.3.3.  <ins> The server encrypts both its server ID and a nonce in 16-octet block with the configured AES-ECB key. </ins> 6. server ID allocation method, and the relevant parameters for that algorithm.  <ins> All algorithm configurations can have a server ID length, nonce length, and key.  However, for Plaintext CID, the key is not used and the nonce length is always zero.  For Block Cipher CID, the nonce length is directly computed from the server ID length. </ins>  <ins> If server IDs are statically allocated, the load balancer MUST receive the full table of mappings, and each server must receive its assigned SID(s), from the configuration agent. </ins> Note that server IDs are opaque bytes, not integers, so there is no notion of network order or host order.


the server, but authenticated later in the token.  The Retry Service SHOULD reject any token in which the value is less than 8. <del> RSCIL: The retry source connection ID length. </del> Original Destination Connection ID: This also in cleartext and authenticated later. <del> Retry Source Connection ID: This also in cleartext and authenticated later. Opaque Data: This data MUST contain encrypted information that allows the retry service to validate the client's IP address, in accordance with the QUIC specification.  It MUST also provide a cryptographically secure means to validate the integrity of the entire token. </del>  Upon receipt of an Initial packet with a token that begins with '0', the retry service MUST validate the token in accordance with the QUIC processed in accordance with the QUIC specification.  If a server receives an Initial Packet with the first bit to '0', it is a Retry token and the server MUST NOT attempt to validate it.  Instead, it <del> MUST assume the address is validated and MUST extract the Original Destination Connection ID and Retry Source Connection ID, assuming the format described in nss-service-requirements. </del>  7.3. server or retry service, MUST use the following format, which includes:  A 96 bit unique token number transmitted in clear text, but protected as part of the AEAD associated data. <del> An 8 bit token key identifier. A token body, encoding the Original Destination Connection ID, the Retry Source Connection ID, and the Timestamp, optionally followed by server specific Opaque Data. </del>  The token protection uses an 128 bit representation of the source IP address from the triggering Initial packet.  The client IP address is <del> 16 octets.  If an IPv4 address, the last 12 octets are zeroes. </del>  If there is a Network Address Translator (NAT) in the server infrastructure that changes the client IP, the Retry Service MUST The token body has the following fields:  ODCIL: The original destination connection ID length.  Tokens in <del> NEW_TOKEN frames MUST set this field to zero. </del>  <del> RSCIL: The retry source connection ID length.  Tokens in NEW_TOKEN frames MUST set this field to zero. </del>  Port: The Source Port of the UDP datagram that triggered the Retry packet.  This field MUST be present if and only if the ODCIL is greater than zero.  This field is therefore always absent in tokens in NEW_TOKEN frames. <del> Original Destination Connection ID: The server or Retry Service copies this from the field in the client Initial packet. Retry Source Connection ID: The server or Retry service copies this from the Source Connection ID of the Retry packet. Timestamp: The Timestamp is a 64-bit integer, in network order, that expresses the expiration time of the token as a number of seconds in POSIX time (see Sec.  4.16 of TIME_T). </del> Opaque Data: The server may use this field to encode additional information, such as congestion window, RTT, or MTU.  The Retry Service MUST have zero-length opaque data. The tokens are protected using AES128-GCM as follows: <del> The Key Sequence is the 8 bit identifier to retrieve the token key </del>  and IV. The AEAD IV, is a 96 bit data which produced by implementer's The associated data is a formatted as a pseudo header by combining the cleartext part of the token with the IP address of the client.  The input plaintext for the AEAD is the token body.  The output ciphertext of the AEAD is transmitted in place of the token body. 7.3.3. In inactive mode, the Retry service forwards all packets without <del> further inspection or processing. </del>  Retry services MUST NOT issue Retry packets except where explicitly allowed below, to avoid sending a Retry packet in response to a Retry token. <del> When in active mode, the service MUST generate Retry tokens with the format described above when it receives a client Initial packet with no token. </del>  <del> The service SHOULD decrypt incoming tokens.  The service SHOULD drop packets with unknown key sequence, or an AEAD ICV that does not match the expected value.  (By construction, the AEAD ICV will only match if the client IP Address also matches.) </del>  <del> If the token verification passes, and the ODCIL and RSCIL fields are both zero, then this is a NEW_TOKEN token generated by the server. Processing of NEW_TOKEN tokens is subtly different from Retry tokens, as described below. </del>  <del> The service SHOULD drop a packet containing a token where the ODCIL is greater than zero and less than the minimum number of octets for a client-generated CID (8 in QUIC version 1).  The service also SHOULD drop a packet containing a token where the ODCIL is zero and RSCIL is nonzero. </del>  <del> If the Timestamp of a token points to time in the past, the token has expired; however, in order to allow for clock skew, it SHOULD NOT consider tokens to be expired if the Timestamp encodes a few seconds in the past.  An active Retry service SHOULD drop packets with expired tokens.  If a NEW_TOKEN token, the service MUST generate a Retry packet in response.  It MUST NOT generate a Retry packet in response to an expired Retry token. </del>  <del> If a Retry token, the service SHOULD drop packets where the port number encoded in the token does not match the source port in the encapsulating UDP header. </del>  <del> All other packets SHOULD be forwarded to the server. </del>  7.3.4. <del> When issuing Retry or NEW_TOKEN tokens, the server MUST include the client IP address in the authenticated data as specified in token- protection-with-aead.  The ODCIL and RSCIL fields are zero for NEW_TOKEN tokens, making them easily distinguishable from Retry tokens. </del>  The server MUST validate all tokens that arrive in Initial packets, <del> as they may have bypassed the Retry service. </del>  <del> For Retry tokens that follow the format above, servers SHOULD use the timestamp field to apply its expiration limits for tokens.  This need not be precisely synchronized with the retry service.  However, servers MAY allow retry tokens marked as being a few seconds in the past, due to possible clock synchronization issues. </del>  <del> After decrypting the token, the server uses the corresponding fields to populate the original_destination_connection_id transport parameter, with a length equal to ODCIL, and the retry_source_connection_id transport parameter, with length equal to RSCIL. </del>  For QUIC versions the service does not support, the server MAY use any token format. <del> As discussed in RFC9000, a server MUST NOT send a Retry packet in response to an Initial packet that contains a retry token. </del> 8. QUIC-LB requires common configuration to synchronize understanding of

Takes the RSCID out of the token body because the server can catch mismatches with the DCID if it's used as associated data.
I have read URL but still don't understand why we need to include it again in token. I'd thought that that server or retry service can read it from the Initial packet (invariant long header packet). What happen if they are different? Which one server should take to initiate the connection?
I recommend Section 7.3 of RFC 9000 to understand this: "The values provided by a peer for these transport parameters MUST match the values that an endpoint used in the Destination and Source Connection ID fields of Initial packets that it sent (and received, for servers). Endpoints MUST validate that received transport parameters match received connection ID values." The connection IDs in Retry and Initial packets are not effectively authenticated unless they are included in transport parameters, which are included in key computation. If the server doesn't have a trustworthy record of the CID it picked (this token), it has no way of confirming that the Retry's SCID wasn't modified in flight.
yeah, I get that server needs to verify SCID in Retry packet. I still do not get why we need to include Retry SCID again in the token.
How would it verify the SCID was unchanged if it wasn't in the token?
I think it'd be authenticated by including in the associated data, i.e
Hmm, this is a clever proposal. I'll reopen to reconsider properly.
Trying to wrap my head around this. The server wants to verify that the RSCID is correct, so the current solution is to copy that in the token. If the client messes up, the server compares the value in the token to the value sent by the client. Yes, putting that in the pseudo header will mostly work. If the client does not use the specified RSCID, the token will just not decode. But there are two potential issues: 1) Debugging is harder. For example, there will not be any way to differentiate between wrong RSCID and wrong IP 2) If the token came as "NEW TOKEN", there is no RSCID specified. There will need to be a special case for constructing the pseudo header, but that means exposing the difference between Retry Token and New Token in clear text. In any case, we would need additional text for the New Token case.
Christian, good point on (2). The NSS Token already distinguishes the types in cleartext, so perhaps that's not such a big deal. But yes, we'd need to take a bit from the key sequence to indicate the token type.
I filed , please take a look.

the server, but authenticated later in the token.  The Retry Service SHOULD reject any token in which the value is less than 8.  Original Destination Connection ID: This also in cleartext and authenticated later.  <ins> Opaque Data: This data contains the information necessary to authenticate the Retry token in accordance with the QUIC specification.  A straightforward implementation would encode the Retry Source Connection ID, client IP address, and a timestamp in the Opaque Data.  A more space-efficient implementation would use the Retry Source Connection ID and Client IP as associated data in an encryption operation, and encode only the timestamp and the authentication tag in the Opaque Data.  If the Initial Packet has altered the Connection ID or source IP address, authentication of the token will fail. </ins> Upon receipt of an Initial packet with a token that begins with '0', the retry service MUST validate the token in accordance with the QUIC processed in accordance with the QUIC specification.  If a server receives an Initial Packet with the first bit to '0', it is a Retry token and the server MUST NOT attempt to validate it.  Instead, it  <ins> MUST assume the address is validated, MUST include the packet's Destination Connection ID in a Retry Source Connection ID transport parameter, and MUST extract the Original Destination Connection ID from the token cleartext for use in the transport parameter of the same name. </ins> 7.3. server or retry service, MUST use the following format, which includes: <ins> A 1 bit token type identifier. A 7 bit token key identifier. </ins> A 96 bit unique token number transmitted in clear text, but protected as part of the AEAD associated data.  <ins> A token body, encoding the Original Destination Connection ID and the Timestamp, optionally followed by server specific Opaque Data. </ins> The token protection uses an 128 bit representation of the source IP address from the triggering Initial packet.  The client IP address is  <ins> 16 octets.  If an IPv4 address, the last 12 octets are zeroes.  It also uses the Source Connection ID of the Retry packet, which will cause an authentication failure if it differs from the Destination Connection ID of the packet bearing the token. </ins> If there is a Network Address Translator (NAT) in the server infrastructure that changes the client IP, the Retry Service MUST The token body has the following fields: <ins> Timestamp: The Timestamp is a 64-bit integer, in network order, that expresses the expiration time of the token as a number of seconds in POSIX time (see Sec.  4.16 of TIME_T). </ins> ODCIL: The original destination connection ID length.  Tokens in  <ins> NEW_TOKEN frames do not have this field. </ins>  <ins> Original Destination Connection ID: The server or Retry Service copies this from the field in the client Initial packet.  Tokens in NEW_TOKEN frames do not have this field. </ins> Port: The Source Port of the UDP datagram that triggered the Retry packet.  This field MUST be present if and only if the ODCIL is greater than zero.  This field is therefore always absent in tokens in NEW_TOKEN frames.  Opaque Data: The server may use this field to encode additional information, such as congestion window, RTT, or MTU.  The Retry Service MUST have zero-length opaque data. The tokens are protected using AES128-GCM as follows:  <ins> The Key Sequence is the 7 bit identifier to retrieve the token key </ins> and IV. The AEAD IV, is a 96 bit data which produced by implementer's The associated data is a formatted as a pseudo header by combining the cleartext part of the token with the IP address of the client. <ins> The format of the pseudoheader depends on whether the Token Type bit is '1' (a NEW_TOKEN token) or '0' (a Retry token). RSCIL: The Retry Source Connection ID Length in octets.  This field is only present when the Token Type is '0'. Retry Source Connection ID: To create a Retry Token, populate this field with the Source Connection ID the Retry packet will use.  To validate a Retry token, populate it with the Destination Connection ID of the Initial packet that carries the token.  This field is only present when the Token Type is '0'. </ins> The input plaintext for the AEAD is the token body.  The output ciphertext of the AEAD is transmitted in place of the token body. 7.3.3. In inactive mode, the Retry service forwards all packets without  <ins> further inspection or processing.  The rest of this section only applies to a service in active mode. </ins> Retry services MUST NOT issue Retry packets except where explicitly allowed below, to avoid sending a Retry packet in response to a Retry token.  <ins> The service MUST generate Retry tokens with the format described above when it receives a client Initial packet with no token. If there is a token of either type, the service MUST attempt to decrypt it. To decrypt a packet, the service checks the Token Type and constructs a pseudoheader with the appropriate format for that type, using the bearing packet's Destination Connection ID to populate the Retry Source Connection ID field, if any. </ins>  <ins> A token is invalid if: </ins>  <ins> it uses unknown key sequence, </ins>  <ins> the AEAD ICV does not match the expected value (By construction, it will only match if the client IP Address, and any Retry Source Connection ID, also matches), </ins>  <ins> the ODCIL, if present, is invalid for a client-generated CID (less than 8 or more than 20 in QUIC version 1), </ins>  <ins> the Timestamp of a token points to time in the past (however, in order to allow for clock skew, it SHOULD NOT consider tokens to be expired if the Timestamp encodes a few seconds in the past), or </ins>  <ins> the port number, if present, does not match the source port in the encapsulating UDP header. Packets with valid tokens MUST be forwarded to the server. The service MUST drop packets with invalid tokens.  If the token is of type '1' (NEW_TOKEN), it MUST respond with a Retry packet.  If of type '0', it MUST NOT respond with a Retry packet. </ins> 7.3.4.  <ins> The server MAY issue Retry or NEW_TOKEN tokens in accordance with RFC9000.  When doing so, it MUST follow the format above. </ins> The server MUST validate all tokens that arrive in Initial packets,  <ins> as they may have bypassed the Retry service.  It determines validity using the procedure in ss-service. </ins>  <ins> If a valid Retry token, the server populates the original_destination_connection_id transport parameter using the corresponding token field.  It populates the retry_source_connection_id transport parameter with the Destination Connection ID of the packet bearing the token. </ins>  <ins> In all other respects, the server processes both valid and invalid tokens in accordance with RFC9000. </ins> For QUIC versions the service does not support, the server MAY use any token format.  8. QUIC-LB requires common configuration to synchronize understanding of


pool, and determines a server ID length (in octets) sufficiently large to encode all server IDs, including potential future servers. <del> The nonce length MUST be no fewer than 8 and no more than 16 octets. </del>  The server ID length and nonce length MUST sum to 19 or fewer octets, and SHOULD sum to 15 or fewer octets to allow space for server use. DCIDs over the life of a connection, it is a sufficient means of avoiding an Oracle without additional measures.  11.6. The Stream Cipher and Block Cipher algorithms need to generate different cipher text for each generated Connection ID instance to <del> protect the Server ID.  To do so, at least four octets of the Block Cipher CID and at least eight octets of the Stream Cipher CID are </del>  reserved for a nonce that, if used only once, will result in unique cipher text for each Connection ID.

After a lot of thinking about nonce reuse, I added somewhat related text about stateless reset token key management.
Way back in , NAME said that his three-pass algorithm meant that But we never really did that: the nonce is in the range 8..16 octets, which is inherited from the original single-pass algorithm. NAME asked if we could shorten the minimum nonce to 32 bits to reduce overall CID length; if it were, we could support 2^24 servers with an 8-byte CID! This is compelling and we should definitely shorten the nonce to some value. But 32 bits means you need to roll over the keys for every 4 billion CIDs a server issues; given that some QUIC implementations are quite profligate issuing CIDs, is that enough? Even another byte would get us to a trillion CIDs while supporting up to 2^16 servers in 8 octets. On the other hand, the config agent can always pick a longer nonce length if the key lifetime is too short. This is how much we want to allow people to do something potentially dumb, so it's a good spot for discussion.
I think some flexibility and discussion of the pros and cons here would be very useful. I think 32 bits is a reasonable min for our use cases, but maybe there's a reason that would cause issues I'm not aware of? We are not profligate issuers of connection IDs and I think we just issue one extra one at any given point in time.
NAME wrote: "This is compelling and we should definitely shorten the nonce to some value. But 32 bits means you need to roll over the keys for every 4 billion CIDs a server issues; given that some QUIC implementations are quite profligate issuing CIDs, is that enough?" Short answer: yes. Assume a server handles 2,048 connections per second, and allocates 16 CID per connection. That leaves 17 bits, 128K connections, 64K seconds, about 18 hours. Long answer: to make that really work, you need a good rollover mechanism. Something like, if the load balancer observes that one server has rolled over, it triggers rollover for all other servers in the pool.
Most connections need 1 or 2 CIDs, so I think the practical bounds are higher. Also, 2048 connections isn't that much, but 2048 per second is quite a bit based on my experience.
So I wonder if there's an attack that continually changes the DCID it uses, which will cause some servers to issue way more CIDs than usual, thus forcing a rollover inside the normal key management cycle. Two countermeasures: servers SHOULD limit CID issuance to a sensible limit, and (as NAME says) do a good rollover mechanism.
NAME on a separate note, are there security implications for (noncelen < sidlen)? I can't see any, but you would know better than I.
Perhaps I'm over-thinking this, because I'm not sure nonce re-use actually matters here. Assuming that a single server isn't using multiple server IDs, we are essentially encrypting the same plaintext over and over again. So even if the nonce is re-used, that is only amounting to the exact same CID being issued again (modulo random bits in the server use field or where the length would go). While this isn't great, as long as it's not done in the same connection, it doesn't provide any useful information to the observer to correlate clients. If the observer is positioned to see all CIDs in use for the server pool, then over long time scales it may observer that two CIDs match, which for QUIC-LB means they were issued by the same server. Thanks to the config rotation bits, it can likely infer that the keys haven't rotated. But that has very little to do with correlating clients, which is the whole point of the document. A server that rolls over its connection IDs is going to have to generate new Stateless Reset keys, but this is a totally local operation. Am I not thinking about this correctly?
Encryption performs a bijection from the space of tuples to the space of numbers of size nbsid*nbnonce. I don't see a particular risk in having noncelen smaller or larger than sid_len. There is a risk in densely using the space of encrypted numbers. look at the decryption size. If an adversary picks a number at random, that number will decrypt to . The shorter the ID, the denser your utilization of the space, the larger the likelihood that the randomly picked "s" will correspond to a valid server, and thus the adversary's message hitting a server instead of being dropped at the LB. Same goes for the nonce, the adversary has more chances to get lucky if the space of nonces is densely used. But then, decryption will fail and the message will be ignored. So the main issue I see is that randomly creating SID might yield slightly more effective resource-consumption attacks.
Put another way, maybe Sec 11.6 is wrong for QUIC-LB: URL
The attacker will not be able to directly correlate cid values and servers. Changing one bit in the nonce statistically changes half the bits in the encrypted sid+nonce.
Thanks, can we change to a 32 bit nonce and add some more text about the risks and trade-offs of shorter vs longer nonces? I feel someone else might be better at the risks/trade-offs bit, but I'll write a PR to change the value.
I already have one to go up on monday
SG, I'll drop mine then. martinduke NAME wrote:
On the issue of nonce reuse: I toyed with idea of being permissive about this, but for the record here's why there's a problem: At the extreme, say a server uses an independent nonce counter for each of its connections, so the encrypted bits follow a predictable pattern for CIDs 1..n issued over the life of the connection. First, if the plaintext bits (first octet and server-use) are the same, we can't demultiplex connections, and everyone will have everyone else's stateless reset tokens. So at a minimum, the server has to keep the overall CID unique. But even it's unique, if the encrypted bits follow this pattern, then a client connected to that server can identify other clients linked to that server.
Let's do this.LG. The intent is to reduce the minimum nonce length for both Stream and Block ciphers, correct?LGTM

pool, and determines a server ID length (in octets) sufficiently large to encode all server IDs, including potential future servers.  <ins> The nonce length MUST be no fewer than 4 and no more than 16 octets. </ins> The server ID length and nonce length MUST sum to 19 or fewer octets, and SHOULD sum to 15 or fewer octets to allow space for server use. DCIDs over the life of a connection, it is a sufficient means of avoiding an Oracle without additional measures. <ins> Note also that when a server starts using a new QUIC-LB config rotation codepoint, new CIDs might not be unique with respect to previous configurations that occupied that codepoint, and therefore different clients may have observed the same CID and stateless reset token.  A straightforward method of managing stateless reset keys is to maintain a separate key for each config rotation codepoint, and replace each key when the configuration for that codepoint changes. Thus, a server transitions from one config to another, it will be able to generate correct tokens for connections using either type of CID. </ins> 11.6. The Stream Cipher and Block Cipher algorithms need to generate different cipher text for each generated Connection ID instance to  <ins> protect the Server ID.  To do so, at least four octets of the CID are </ins> reserved for a nonce that, if used only once, will result in unique cipher text for each Connection ID.


MUST NOT reject tokens because they lack opaque data and therefore the packet number.  7.3.1. On the wire, the token is presented as:

Secure ciphers are much more important for Shared State Retry than for the load balancer stuff and Initial Encryption. Therefore, some crypto agility to allow this mechanism to adapt as ciphers deprecate would be good. The key sequence can also imply a cipher, so we'll add that to the data model. Some fields will vary length based on the cipher. We should also make it so everyone MUST support AES128-GCM.

MUST NOT reject tokens because they lack opaque data and therefore the packet number. <ins> Shared-state Retry Services use the AES-128-ECB cipher.  Future standards could add new algorithms that use other ciphers to provide cryptographic agility in accordance with RFC7696.  Retry Service and server implementations SHOULD be extensible to support new algorithms. </ins> 7.3.1. On the wire, the token is presented as:


NEW_CONNECTION_ID frames with new values. A load balancer that sees a connection ID with config rotation bits <del> set to '11' MUST revert to 5-tuple routing. </del>  3.3. All connection IDs use the following format: Each configuration specifies the length of the Server ID and Nonce <del> fields, with limits defined for each algorithm. </del>  The Server ID is assigned to each server in accordance with sid- allocation.  Dynamically allocated SIDs are limited to seven octets or fewer.  Statically allocated ones have different limits for each algorithm.  The Nonce is selected by the server when it generates a CID.  As the name implies, a server MUST use a nonce no more than once when generating a CID for a given server ID and unique set of <del> configuration parameters.  Limits on the length of the nonce are different for each algorithm. </del>  <del> The First Octet, Server ID, and Nonce comprise the minimum length Connection ID for any given algorithm.  The load balancer need not know the full connection ID length to successfully process a packet, given that it is of minimum size. </del>  <del> The For Server Use field has any value and length chosen by the server, within the connection ID length limits in the operative QUIC version.  It SHOULD appear random and SHOULD NOT link two connection IDs to the same connection, or indicate they originate from the same server. </del>  5. 5.1.1. <del> For static SID allocation, the server ID length is limited to 16 octets.  The nonce length MUST be zero. </del>  5.1.2. On each incoming packet, the load balancer extracts consecutive octets, beginning with the second octet.  These bytes represent the <del> server ID. </del>  5.1.3. <del> The server chooses how many octets to reserve for its own use, which MUST be at least one octet. </del> When a server needs a new connection ID, it encodes one of its <del> assigned server IDs in consecutive octets beginning with the second. </del>  5.2. 5.2.1. <del> The configuration agent assigns a server ID to every server in its pool, and determines a server ID length (in octets) sufficiently large to encode all server IDs, including potential future servers. The nonce length MUST be no fewer than 4 and no more than 16 octets. </del>  <del> The server ID length and nonce length MUST sum to 19 or fewer octets, and SHOULD sum to 15 or fewer octets to allow space for server use. </del>  5.2.2. When generating a routable connection ID, the server writes arbitrary bits into its nonce octets, and its provided server ID into the <del> server ID octets.  Servers MAY opt to have a longer connection ID beyond the nonce and server ID.  The additional bits MAY encode additional information, but SHOULD appear essentially random to observers. If the decrypted nonce bits increase monotonically, that guarantees that nonces are not reused between connection IDs from the same server. </del>  The server encrypts the server ID using exactly the algorithm as described in stream-cipher-load-balancer-actions, performing the 5.3.1. <del> The server ID length MUST be no more than 12 octets.  The server ID length and nonce length MUST sum to exactly 16 octets. </del>  The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption. octet to obtain the config rotation bits.  It then decrypts the subsequent 16 octets using AES-ECB decryption and the chosen key. <del> The decrypted plaintext contains the server id and opaque server data in that order.  The load balancer uses the server ID octets for routing. </del>  5.3.3. <del> The server encrypts both its server ID and a nonce in 16-octet block with the configured AES-ECB key. </del>  6. algorithm. All algorithm configurations can have a server ID length, nonce <del> length, and key.  However, for Plaintext CID, the key is not used and the nonce length is always zero.  For Block Cipher CID, the nonce length is directly computed from the server ID length. </del>  If server IDs are statically allocated, the load balancer MUST receive the full table of mappings, and each server must receive its 11.6.  The Stream Cipher and Block Cipher algorithms need to generate different cipher text for each generated Connection ID instance to protect the Server ID.  To do so, at least four octets of the CID are zero.  Whether or not it implements this method, the server MUST NOT reuse a nonce until it switches to a configuration with new keys. <del> Configuration agents SHOULD implement an out-of-band method to discover when servers are in danger of exhausting their nonce space, and SHOULD respond by issuing a new configuration.  A server that has exhausted its nonces MUST either switch to a different configuration, or if none exists, use the 4-tuple routing config rotation codepoint. </del>  11.7.

the server no longer has discretion to lengthen the CID. Also, the algorithms are more aligned so there has to be less unique text associated with each algorithm.
In any given deployment, the server use length should be consistent. The load balancer doesn't strictly need to know what it is, but obviously not doing this will lead to observable correlations.
As we've generalized the concept of a nonce, we should abolish the concept of "server use" and make it all a nonce. If the servers need to use the same length to prevent linkability, best to make it part of the configuration.

NEW_CONNECTION_ID frames with new values. A load balancer that sees a connection ID with config rotation bits  <ins> set to '11' MUST revert to 5-tuple routing.  These connection IDs may be of any length; however, see cid-entropy for limits on this length. </ins> 3.3. All connection IDs use the following format: Each configuration specifies the length of the Server ID and Nonce  <ins> fields, with limits defined for each algorithm.  When using a given configuration, the server MUST generate CIDs of length equal to the lengths of these three fields. </ins> The Server ID is assigned to each server in accordance with sid- allocation.  Dynamically allocated SIDs are limited to seven octets or fewer.  Statically allocated ones have different limits for each algorithm. <ins> The configuration agent assigns a server ID to every server in its pool, and determines a server ID length (in octets) sufficiently large to encode all server IDs, including potential future servers. </ins> The Nonce is selected by the server when it generates a CID.  As the name implies, a server MUST use a nonce no more than once when generating a CID for a given server ID and unique set of  <ins> configuration parameters. </ins>  <ins> The nonce length MUST be at least 4 octets.  Additional limits on its length are different for each algorithm.  See cid-entropy for limits on nonce generation. </ins>  <ins> As QUIC version 1 limits connection IDs to 20 octets, the server ID and nonce lengths MUST sum to 19 octets or less. </ins> 5. 5.1.1.  <ins> See cid-format. </ins> 5.1.2. On each incoming packet, the load balancer extracts consecutive octets, beginning with the second octet.  These bytes represent the  <ins> server ID.  It ignores the nonce. </ins> 5.1.3.  When a server needs a new connection ID, it encodes one of its  <ins> assigned server IDs in consecutive octets beginning with the second and chooses a nonce.  This nonce MUST appear to be random (see cid- entropy). </ins> 5.2. 5.2.1.  <ins> The nonce length MUST be no fewer than 4 octets. </ins>  <ins> The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption. </ins> 5.2.2. When generating a routable connection ID, the server writes arbitrary bits into its nonce octets, and its provided server ID into the  <ins> server ID octets.  See cid-entropy for nonce generation considerations. </ins> The server encrypts the server ID using exactly the algorithm as described in stream-cipher-load-balancer-actions, performing the 5.3.1.  <ins> The server ID length MUST be no more than 12 octets.  The nonce and server ID MUST sum to at least 16 octets. </ins> The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption. octet to obtain the config rotation bits.  It then decrypts the subsequent 16 octets using AES-ECB decryption and the chosen key.  <ins> The first octets of the plaintext contains the server id. </ins> 5.3.3.  <ins> The server encrypts both its server ID and enough octets in a nonce to form a 16-octet block using the configured AES-ECB key.  Note that any remaining octets in the nonce are transmitted as plaintext, and should consider the constraints in cid-entropy. </ins> 6. algorithm. All algorithm configurations can have a server ID length, nonce  <ins> length, and key.  However, for Plaintext CID, there is no key. </ins> If server IDs are statically allocated, the load balancer MUST receive the full table of mappings, and each server must receive its 11.6. <ins> If a server ever reuses a nonce in generating a CID for a given configuration, it risks exposing sensitive information.  Given the same server ID, the CID will be identical (aside from a possible difference in the first octet).  This can risk exposure of the QUIC- LB key.  If two clients receive the same connection ID, they also have each other's stateless reset token unless that key has changed in the interim. </ins> The Stream Cipher and Block Cipher algorithms need to generate different cipher text for each generated Connection ID instance to protect the Server ID.  To do so, at least four octets of the CID are zero.  Whether or not it implements this method, the server MUST NOT reuse a nonce until it switches to a configuration with new keys.  <ins> Both the Plaintext CID and Block Cipher CID algorithms send parts of their nonce in plaintext.  Servers MUST generate nonces so that the plaintext portion appears to be random.  Observable correlations between plaintext nonces would provide trivial linkability between individual connections, rather than just to a common server. For any algorithm, configuration agents SHOULD implement an out-of- band method to discover when servers are in danger of exhausting their nonce space, and SHOULD respond by issuing a new configuration. A server that has exhausted its nonces MUST either switch to a different configuration, or if none exists, use the 4-tuple routing config rotation codepoint. When sizing a nonce that is to be randomly generated, the configuration agent SHOULD consider that a server generating a N-bit nonce will create a duplicate about every 2^(N/2) attempts, and therefore compare the expected rate at which servers will generate CIDs with the lifetime of a configuration. </ins> 11.7.


7.  Some network architectures may have multiple tiers of low-state load balancers, where a first tier of devices makes a routing decision to the next tier, and so on until packets reach the server.  Although numbers of load-balancing tiers, as the maximum server ID space is quite large.  8. QUIC-LB is intended to prevent linkability.  Attacks would therefore

Intended to
Some text on how a server cluster might support moving of connections from one server instance to another would be useful. The current design might permit portability under certain conditions, but there are things that might need to be considered, such as the way in stateless resets are generated.
Are you referring to load balancing already existing connections to a new server? Are you envisioning the first server issuing new CIDs (that point to the new server) and setting Retire Prior To to retire the old CIDs so that future traffic redirect to the new server? How do you imagine the rest of the connection state would get moved?
This applies to cases where clusters are rebalanced, where instances go down and others are expected to pick up the slack, and all similar cases. In some cases this requires an unspecified mechanism for transferring state between instances. In others, the instance might remain constant but the identifiers used might need to rotate. This is likely addressed by using Retire Prior To as you say. Text on that would help.
Good idea, it wouldn't hurt to have a short non-normative section on this.
Seems fine.

7. <ins> This section discusses considerations for some deployment scenarios not implied by the specification above. 7.1. </ins> Some network architectures may have multiple tiers of low-state load balancers, where a first tier of devices makes a routing decision to the next tier, and so on until packets reach the server.  Although numbers of load-balancing tiers, as the maximum server ID space is quite large. <ins> 7.2. Some deployments may transparently move a connection from one server to another.  The means of transferring connection state between servers is out of scope of this document. To support a handover, a server involved in the transition could issue CIDs that map to the new server via a NEW_CONNECTION_ID frame, and retire CIDs associated with the new server using the "Retire Prior To" field in that frame. Alternately, if the old server is going offline, the load balancer could simply map its server ID to the new server's address. </ins> 8. QUIC-LB is intended to prevent linkability.  Attacks would therefore


5.2. <del> The Stream Cipher CID algorithm provides cryptographic protection at the cost of additional per-packet processing at the load balancer to decrypt every incoming connection ID. </del>  5.2.1. considerations. The server encrypts the server ID using exactly the algorithm as <del> described in stream-cipher-load-balancer-actions, performing the </del>  three passes in reverse order. 5.3. <del> The Block Cipher CID Algorithm, by using a full 16 octets of plaintext and a 128-bit cipher, provides higher cryptographic protection and detection of unroutable connection IDs.  However, it also requires connection IDs of at least 17 octets, increasing overhead of client-to-server packets. </del>  5.3.1. map to the same server.  It could then apply analytical techniques to try to obtain the server encoding. <del> The Stream and Block Cipher CID algorithms provide robust protection against any sort of linkage.  The Plaintext CID algorithm makes no attempt to protect this encoding. </del>  Were this analysis to obtain the server encoding, then on-path observers might apply this analysis to correlating different client have each other's stateless reset token unless that key has changed in the interim. <del> The Stream Cipher and Block Cipher algorithms need to generate </del>  different cipher text for each generated Connection ID instance to protect the Server ID.  To do so, at least four octets of the CID are reserved for a nonce that, if used only once, will result in unique zero.  Whether or not it implements this method, the server MUST NOT reuse a nonce until it switches to a configuration with new keys. <del> Both the Plaintext CID and Block Cipher CID algorithms send parts of their nonce in plaintext.  Servers MUST generate nonces so that the plaintext portion appears to be random.  Observable correlations </del>  between plaintext nonces would provide trivial linkability between individual connections, rather than just to a common server.

Some have noted that "Stream Cipher" is now a misnomer. So this PR renames them.

5.2.  <ins> The Encrypted Short CID algorithm provides cryptographic protection at the cost of additional per-packet processing at the load balancer to decrypt every incoming connection ID, unless the load balancer maintains state for the routing information of any given 4-tuple. </ins> 5.2.1. considerations. The server encrypts the server ID using exactly the algorithm as  <ins> described in encrypted-short-load-balancer-actions, performing the </ins> three passes in reverse order. 5.3.  <ins> The Encrypted Long CID Algorithm, by using a full 16 octets of plaintext and a 128-bit cipher, protects the server ID with a single encryption pass.  However, it also requires connection IDs of at least 17 octets, increasing overhead of client-to-server packets. </ins> 5.3.1. map to the same server.  It could then apply analytical techniques to try to obtain the server encoding.  <ins> The Encrypted CID algorithms provide robust protection against any sort of linkage.  The Plaintext CID algorithm makes no attempt to protect this encoding. </ins> Were this analysis to obtain the server encoding, then on-path observers might apply this analysis to correlating different client have each other's stateless reset token unless that key has changed in the interim.  <ins> The Encrypted Short and Encrypted Long algorithms need to generate </ins> different cipher text for each generated Connection ID instance to protect the Server ID.  To do so, at least four octets of the CID are reserved for a nonce that, if used only once, will result in unique zero.  Whether or not it implements this method, the server MUST NOT reuse a nonce until it switches to a configuration with new keys.  <ins> Both the Plaintext CID and Encrypted Long CID algorithms send parts of their nonce in plaintext.  Servers MUST generate nonces so that the plaintext portion appears to be random.  Observable correlations </ins> between plaintext nonces would provide trivial linkability between individual connections, rather than just to a common server.