interacting with the captive portal is out of scope of this document. [ This document is being collaborated on in Github at: <del> https://github.com/wkumari/draft-ekwk-capport-rfc7710bis.  The most recent version of the document, open issues, etc should all be available here.  The authors (gratefully) accept pull requests.  Text in square brackets will be removed before publication. ] </del> <ins> https://github.com/capport-wg/7710bis.  The most recent version of the document, open issues, etc should all be available here.  The authors (gratefully) accept pull requests.  Text in square brackets will be removed before publication. ] </ins> 1.


If the URIs learned via more than one option described in option are not all identical, this condition should be logged for the device <del> owner or administrator.  URI precedence in this situation is not specified by this document. </del> <ins> owner or administrator.  Implementations can select their own precedence order. </ins> 4.


credentials, etc.  By handing out a URI using which is protected with TLS, the captive portal operator can attempt to reassure the user that the captive portal is not malicious. <del> Operating systems should conduct all interactions with the API in a sand-boxed environment and with a configuration that minimizes tracking risks. </del>


but not the requested action. The client cannot always know a priori if an Authorized Resource <del> Request will succeed.  If the client repeatedly gets error responses containing AS Creation Hints (cf.  Section 5.1.2 of I-D.ietf-ace- oauth-authz as response to its requests, it SHOULD request a new access token from the authorization server in order to continue communication with the resource server. </del> <ins> Request will succeed.  It must check the validity of its keying material before sending a request or processing a response.  If the client repeatedly gets error responses containing AS Creation Hints (cf.  Section 5.1.2 of I-D.ietf-ace-oauth-authz as response to its requests, it SHOULD request a new access token from the authorization server in order to continue communication with the resource server. </ins> Unauthorized requests that have been received over a DTLS session SHOULD be treated as non-fatal by the RS, i.e., the DTLS session


if the token is later transferred over an insecure connection (e.g. when it is sent to the authz-info endpoint). <del> Developers MUST ensure that the ephemeral credentials (i.e., the private key or the session key) are not leaked to third parties.  An adversary in possession of the ephemeral credentials bound to the access token will be able to impersonate the client.  Be aware that this is a real risk with many constrained environments, since adversaries can often easily get physical access to the devices and therefore use phyical extraction techniques to gain access to memory contents.  This risk can also be mitigated to some extent by making sure that keys are refreshed more frequently. </del> <ins> Care must by taken by developers to prevent leakage of the PoP credentials (i.e., the private key or the symmetric key).  An adversary in possession of the PoP credentials bound to the access token will be able to impersonate the client.  Be aware that this is a real risk with many constrained environments, since adversaries may get physical access to the devices and can therefore use phyical extraction techniques to gain access to memory contents.  This risk can be mitigated to some extent by making sure that keys are refreshed frequently, by using software isolation techniques and by using hardware security. </ins> 6.3.


9. <del> There are tradeoffs inherent in a sender sending an ACK_FREQUENCY frame to the receiver.  As such it is recommended that implementers experiment with different strategies and find those which best suit their applications and congestion controllers.  There are, however, noteworthy considerations when devising strategies for sending ACK_FREQUENCY frames. </del> <ins> This section provides some guidance on a sender's choice of acknowledgment frequency and discusses some additional considerations.  Implementers can select an appropriate strategy to meet the needs of their applications and congestion controllers. </ins> 9.1. <del> A sender relies on receipt of acknowledgements to determine the amount of data in flight and to detect losses, e.g. when packets experience reordering, see QUIC-RECOVERY.  Consequently, how often a receiver sends acknowledgments determines how long it takes for losses to be detected at the sender. </del> <ins> A sender needs to be responsive to notifications of congestion, such as a packet loss or an ECN CE marking.  Also, window-based congestion controllers that strictly adhere to packet conservation, such as the one defined in QUIC-RECOVERY, rely on receipt of acknowledgments to send additional data into the network, and will suffer degraded performance if acknowledgments are delayed excessively. To enable a sender to respond to potential network congestion, a sender SHOULD cause a receiver to send an acknowledgement at least once per RTT if there are unacknowledged ack-eliciting packets in flight.  A sender can accomplish this by sending an IMMEDIATE_ACK frame once per round-trip time (RTT), or it can set the Ack-Eliciting Threshold and Request Max Ack Delay values to be no more than a congestion window and an estimated RTT, respectively. </ins> 9.2. <del> Many congestion control algorithms have a startup mechanism during the beginning phases of a connection.  It is typical that in this period the congestion controller will quickly increase the amount of data in the network until it is signalled to stop.  While the mechanism used to achieve this increase varies, acknowledgments by the peer are generally critical during this phase to drive the congestion controller's machinery.  A sender can send ACK_FREQUENCY frames while its congestion controller is in this state, ensuring that the receiver will send acknowledgments at a rate which is optimal for the the sender's congestion controller. </del> <ins> Receiving an acknowledgement can allow a sender to release new packets into the network.  If a sender is designed to rely on the timing of peer acknowledgments ("ACK clock"), delaying acknowledgments can cause undesirable bursts of data into the network.  A sender MUST limit such bursts.  In keeping with Section 7.7 of QUIC-RECOVERY, a sender can either employ pacing or cause a receiver to send an acknowledgement for at least each initial congestion window of received data. </ins> 9.3. <del> Congestion controllers that are purely window-based and strictly adherent to packet conservation, such as the one defined in QUIC- RECOVERY, rely on receipt of acknowledgments to move the congestion window forward and send additional data into the network.  Such controllers will suffer degraded performance if acknowledgments are delayed excessively.  Similarly, if these controllers rely on the timing of peer acknowledgments (an "ACK clock"), delaying acknowledgments will cause undesirable bursts of data into the network. </del> <ins> Acknowledgements are fundamental to reliability in QUIC. Consequently, delaying or reducing the frequency of acknowledgments can cause loss detection at the sender to be delayed. A QUIC sender detects loss using packet thresholds on receiving an acknowledgement (Section 6.1.1 of QUIC-RECOVERY); delaying the acknowledgement therefore delays this method of detecting losses. Reducing acknowledgement frequency reduces the number of RTT samples that a sender receives (Section 5 of QUIC-RECOVERY), making a sender's RTT estimate less responsive to changes in the path's RTT. As a result, any mechanisms that rely on an accurate RTT estimate, such as time-threshold loss detection (Section 6.1.2 of QUIC- RECOVERY) or Probe Timeout (Section 6.2 of QUIC-RECOVERY), will be less responsive to changes in the path's RTT, resulting in either delayed or unnecessary packet transmissions. To limit these consequences of reduced acknowledgement frequency, a sender SHOULD cause a receiver to send an acknowledgement at least once per RTT if there are unacknowledged ack-eliciting packets in flight.  A sender can accomplish this by sending an IMMEDIATE_ACK frame once per round-trip time (RTT), or it can set the Ack-Eliciting Threshold and Request Max Ack Delay values to be no more than a congestion window and an estimated RTT, respectively. A sender might use timers to detect loss of PMTUD probe packets.  A sender SHOULD bundle an IMMEDIATE_ACK frame with any PTMUD probes to avoid triggering such timers. </ins> 9.4.


connection SHOULD update and send a new ACK_FREQUENCY frame immediately upon confirmation of connection migration. <del> 9.5. A sender might use timers to detect loss of PMTUD probe packets.  A sender SHOULD bundle an IMMEDIATE_ACK frame with any PTMUD probes to avoid triggering such timers. </del> 10. TBD.


6.3. <del> For performance reasons, an endpoint can receive incoming packets from the underlying platform in a batch of multiple packets.  This batch can contain enough packets to cause multiple acknowledgements to be sent. </del> To avoid sending multiple acknowledgements in rapid succession, an endpoint can process all packets in a batch before determining whether to send an ACK frame in response, as stated in Section 13.2.2


number of acknowledgments allows connection throughput to scale much further. <del> Unfortunately, there are undesirable consequences to simply reducing the acknowledgement frequency, especially to an arbitrary fixed value, as follows: A sender relies on receipt of acknowledgements to determine the amount of data in flight and to detect losses, see QUIC-RECOVERY. Consequently, how often a receiver sends acknowledgments dictates how long it takes for losses to be detected at the sender. Starting a connection up quickly without inducing excess queue is important for latency reduction, for both short and long flows. The sender often needs more frequent acknowledgments during this phase. Congestion controllers that are purely window based and strictly adherent to packet conservation, such as the one defined in QUIC- RECOVERY, rely on receipt of acknowledgments to move the congestion window forward and release additional data.  Such controllers suffer performance penalties when acknowledgements are not sent frequently enough.  On the other hand, for long-running flows, congestion controllers that are not window-based, such as BBR, can perform well with very few acknowledgements per RTT. New sender startup mechanisms will need a way for the sender to increase the frequency of acknowledgements when fine-grained feedback is required. </del> <ins> As discussed in implementation, there are undesirable consequences to congestion control and loss recovery if a receiver uniltaerally reduces the acknowledgment frequency.  Consequently, a sender needs the ability to express its constraints on the acknowledgement frequency to maximize congestion controller performance. </ins> QUIC-TRANSPORT currently specifies a simple delayed acknowledgement mechanism that a receiver can use: send an acknowledgement for every


8. <del> TBD. </del> <ins> There are tradeoffs inherent in a sender sending an ACK_FREQUENCY frame to the receiver.  As such it is recommended that implementers experiment with different strategies and find those which best suit their applications and congestion controllers.  There are, however, noteworthy considerations when devising strategies for sending ACK_FREQUENCY frames. 8.1. A sender relies on receipt of acknowledgements to determine the amount of data in flight and to detect losses, e.g. when packets experience reordering, see QUIC-RECOVERY.  Consequently, how often a receiver sends acknowledgments determines how long it takes for losses to be detected at the sender. 8.2. Many congestion control algorithms have a startup mechanism during the beginning phases of a connection.  It is typical that in this period the congestion controller will quickly increase the amount of data in the network until it is signalled to stop.  While the mechanism used to achieve this increase varies, acknowledgments by the peer are generally critical during this phase to drive the congestion controller's machinery.  A sender can send ACK_FREQUENCY frames while its congestion controller is in this state, ensuring that the receiver will send acknowledgments at a rate which is optimal for the the sender's congestion controller. 8.3. Congestion controllers that are purely window-based and strictly adherent to packet conservation, such as the one defined in QUIC- RECOVERY, rely on receipt of acknowledgments to move the congestion window forward and send additional data into the network.  Such controllers will suffer degraded performance if acknowledgments are delayed excessively.  Similarly, if these controllers rely on the timing of peer acknowledgments (an "ACK clock"), delaying acknowledgments will cause undesirable bursts of data into the network. </ins> 9. TBD. <ins> 10. TBD. </ins>


receivers to ignore obsolete frames, see multiple-frames. A variable-length integer representing the maximum number of ack- <del> eliciting packets after which the receiver sends an acknowledgement.  A value of 1 will result in an acknowledgement being sent for every ack-eliciting packet received.  A value of 0 is invalid.  Receipt of an invalid value MUST be treated as a connection error of type FRAME_ENCODING_ERROR.  If an endpoint receives an ACK-eliciting threshold value that is larger than the maximum value it can represent, the endpoint MUST use the largest representable value instead. </del> <ins> eliciting packets the recipient of this frame can receive before sending an immediate acknowledgment.  A value of 0 will result in an immediate acknowledgement whenever an ack-eliciting packet received.  If an endpoint receives an ACK-eliciting threshold value that is larger than the maximum value it can represent, the endpoint MUST use the largest representable value instead. </ins> A variable-length integer representing the value to which the endpoint requests the peer update its "max_ack_delay"


Every time an acknowledgement is sent, bundled or otherwise, all counters and timers related to delaying of acknowledgments are reset. <ins> The receiver of an ACK_FREQUENCY frame can continue to process multiple available packets before determining whether to send an ACK frame in response, as stated in Section 13.2.2 of QUIC-TRANSPORT. </ins> 6.1. As specified in Section 13.2.1 of QUIC-TRANSPORT, endpoints are


6. <ins> The IMMEDIATE_ACK Frame is a frame which causes the peer to send a packet containing an ACK frame immediately, similar to the receipt of Initial and Handshake packets during the QUIC handshake. Receivers of the IMMEDIATE_ACK frame MAY choose to delay sending the ACK if the vast majority of received packets contain an IMMEDIATE_ACK or the receiver is under heavy load.  Senders MAY include multiple IMMEDIATE_ACK frames in a single QUIC packet, but the behavior is identical to a single IMMEDIATE_ACK frame. 7. </ins> Prior to receiving an ACK_FREQUENCY frame, endpoints send acknowledgements as specified in Section 13.2.1 of QUIC-TRANSPORT.


multiple available packets before determining whether to send an ACK frame in response, as stated in Section 13.2.2 of QUIC-TRANSPORT. <del> 6.1. </del> <ins> 7.1. </ins> As specified in Section 13.2.1 of QUIC-TRANSPORT, endpoints are expected to send an acknowledgement immediately on receiving a


instead continues to use the peer's "Ack-Eliciting Threshold" and "max_ack_delay" thresholds for sending acknowledgements. <del> 6.2. </del> <ins> 7.2. </ins> As specified in Section 13.2.1 of QUIC-TRANSPORT, an endpoint SHOULD immediately acknowledge packets marked with the ECN Congestion Experienced (CE) codepoint in the IP header.  Doing so reduces the peer's response time to congestion events. <del> 6.3. </del> <ins> 7.3. </ins> For performance reasons, an endpoint can receive incoming packets from the underlying platform in a batch of multiple packets.  This


whether a threshold has been met and an acknowledgement is to be sent in response. <del> 7. </del> <ins> 8. </ins> On sending an update to the peer's "max_ack_delay", an endpoint can use this new value in later computations of its Probe Timeout (PTO)


optimization requires some care in implementation, since it can cause premature PTOs under packet loss when "ignore_order" is enabled. <del> 8. </del> <ins> 9. </ins> There are tradeoffs inherent in a sender sending an ACK_FREQUENCY frame to the receiver.  As such it is recommended that implementers


noteworthy considerations when devising strategies for sending ACK_FREQUENCY frames. <del> 8.1. </del> <ins> 9.1. </ins> A sender relies on receipt of acknowledgements to determine the amount of data in flight and to detect losses, e.g. when packets


receiver sends acknowledgments determines how long it takes for losses to be detected at the sender. <del> 8.2. </del> <ins> 9.2. </ins> Many congestion control algorithms have a startup mechanism during the beginning phases of a connection.  It is typical that in this


that the receiver will send acknowledgments at a rate which is optimal for the the sender's congestion controller. <del> 8.3. </del> <ins> 9.3. </ins> Congestion controllers that are purely window-based and strictly adherent to packet conservation, such as the one defined in QUIC-


acknowledgments will cause undesirable bursts of data into the network. <del> 9. </del> <ins> 10. </ins> TBD. <del> 10. </del> <ins> 11. </ins> TBD. <del> 11.  References </del> <ins> 12.  References </ins> <del> 11.1.  URIs </del> <ins> 12.1.  URIs </ins> [1] https://mailarchive.ietf.org/arch/search/?email_list=quic


Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at <del> https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. Source code and issues list for this draft can be found at https://github.com/quicwg/ack-frequency [2]. </del> <ins> <https://mailarchive.ietf.org/arch/search/?email_list=quic>.  Source code and issues list for this draft can be found at <https://github.com/quicwg/ack-frequency>. </ins> <del> Working Group information can be found at https://github.com/quicwg [3]; </del> <ins> Working Group information can be found at <https://github.com/ quicwg>. </ins> 1.


11. TBD. <del> 12.  References 12.1.  URIs [1] https://mailarchive.ietf.org/arch/search/?email_list=quic [2] https://github.com/quicwg/ack-frequency [3] https://github.com/quicwg </del>


QUIC-TRANSPORT currently specifies a simple delayed acknowledgement mechanism that a receiver can use: send an acknowledgement for every <del> other packet, and for every packet when reordering is observed.  This simple mechanism does not allow a sender to signal its constraints. This extension provides a mechanism to solve this problem. </del> <ins> other packet, and for every packet that is received out of order (Section 13.2.1 of QUIC-TRANSPORT).  This simple mechanism does not allow a sender to signal its constraints.  This extension provides a mechanism to solve this problem. </ins> 3.


A 1-bit field representing a boolean truth value.  This field is set to "true" by an endpoint that does not wish to receive an <del> immediate acknowledgement when the peer observes reordering (reordering).  0 represents 'false' and 1 represents 'true'. </del> <ins> immediate acknowledgement when the peer receives a packet out of order (out-of-order). 0 represents 'false' and 1 represents 'true'. </ins> A 1-bit field representing a boolean truth value.  This field is set to "true" by an endpoint that does not wish to receive an immediate acknowledgement when the peer receives CE-marked packets <del> (reordering).  0 represents 'false' and 1 represents 'true'. </del> <ins> (out-of-order).  0 represents 'false' and 1 represents 'true'. </ins> ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission if an ACK_FREQUENCY frame with a larger


Since the last acknowledgement was sent, "max_ack_delay" amount of time has passed. <del> reordering, congestion, and batch describe exceptions to this </del> <ins> out-of-order, congestion, and batch describe exceptions to this </ins> strategy. An endpoint is expected to bundle acknowledgements when possible.


Different challenges allow the server to obtain proof of different aspects of control over an identifier.  In some challenges, like HTTP and TLS SNI, the client directly proves its ability to do certain <del> things related to the identifier.  In the Proof of Possession challenge, the client proves historical control of the identifier, by reference to a prior authorization transaction or certificate. The choice of which challenges to offer to a client under which circumstances is a matter of server policy.  A CA may choose different sets of challenges depending on whether it has interacted with a domain before, and how.  For example: New domain with no known certificates: Domain Validation (HTTP or TLS SNI) Domain for which known certs exist from other CAs: DV + Proof of Possession of previous CA-signed key Domain with a cert from this CA, lost account key: DV + PoP of ACME-certified Subject key Domain with a cert from this CA, all keys and recovery mechanisms lost: Out of band proof of authority for the domain </del> <ins> things related to the identifier.  The choice of which challenges to offer to a client under which circumstances is a matter of server policy. </ins> The identifier validation challenges described in this section all relate to validation of domain names.  If ACME is extended in the


7.4. <del> The Proof of Possession challenge verifies that a client possesses a private key corresponding to a server-specified public key, as demonstrated by its ability to sign with that key.  This challenge is meant to be used when the server knows of a public key that is already associated with the identifier being claimed, and wishes for new authorizations to be authorized by the holder of the corresponding private key.  For DNS identifiers, for example, this can help guard against domain hijacking. This method is useful if a server policy calls for issuing a certificate only to an entity that already possesses the subject private key of a particular prior related certificate (perhaps issued by a different CA).  It may also help enable other kinds of server policy that are related to authenticating a client's identity using digital signatures. This challenge proceeds in much the same way as the proof of possession of the authorized key pair in the main ACME flow (challenge + authorizationRequest).  The server provides a nonce and the client signs over the nonce.  The main difference is that rather than signing with the private key of the key pair being authorized, the client signs with a private key specified by the server.  The server can specify which key pair(s) are acceptable directly (by indicating a public key), or by asking for the key corresponding to a certificate. The server provides the following fields as part of the challenge: The string "proof-of-possession-01" An array of certificates, in base64url-encoded DER format, that contain acceptable public keys. In response to this challenge, the client uses the private key corresponding to one of the acceptable public keys to sign a JWS object including data related to the challenge.  The validation object covered by the signature has the following fields: The string "proof-of-possession" A list of identifiers for which the holder of the prior key authorizes the new key The client's account public key This JWS is NOT REQUIRED to have a "nonce" header parameter (as with the JWS objects that carry ACME request objects).  This allows proof- of-possession response objects to be computed off-line.  For example, as part of a domain transfer, the new domain owner might require the old domain owner to sign a proof-of-possession validation object, so that the new domain owner can present that in an ACME transaction later. The validation JWS MUST contain a "jwk" header parameter indicating the public key under which the server should verify the JWS. The client's response includes the server-provided nonce, together with a signature over that nonce by one of the private keys requested by the server. The string "proof-of-possession" The validation JWS To validate a proof-of-possession challenge, the server performs the following steps: Verify that the public key in the "jwk" header of the "authorization" JWS corresponds to one of the certificates in the "certs" field of the challenge Verify the "authorization" JWS using the key indicated in its "jwk" header Decode the payload of the JWS as UTF-8 encoded JSON Verify that there are exactly three fields in the decoded object, and that: * The "type" field is set to "proof-of-possession" * The "identifier" field contains the identifier for which authorization is being validated * The "accountKey" field matches the account key for which the challenge was issued If all of the above verifications succeed, then the validation is successful.  Otherwise, the validation fails. 7.5. </del> When the identifier being validated is a domain name, the client can prove control of that domain by provisioning a resource record under it.  The DNS challenge requires the client to provision a TXT record


DNS: The MAC covers the account key, and the MAC key is derived from an ECDH public key signed with the account private key. <del> Proof of possession of a prior key: The signature by the prior key covers the account public key. </del> The association of challenges to identifiers is typically done by requiring the client to perform some action that only someone who effectively controls the identifier can perform.  For the challenges


DNS: Provision DNS resource records for the domain <del> Proof of possession of a prior key: Sign using the private key specified by the server </del> There are several ways that these assumptions can be violated, both by misconfiguration and by attack.  For example, on a web server that allows non-administrative users to write to .well-known, any user can


process, by performing normal ACME transactions and providing a validation response for his own account key.  The risks due to hosting providers noted above are a particular case.  For identifiers <del> where the server already has some credential associated with the domain this attack can be prevented by requiring the client to complete a proof-of-possession challenge. </del> <ins> where the server already has some public key associated with the domain this attack can be prevented by requiring the client to prove control of the corresponding private key. </ins> 10.3.


any web server that is accessible to the ACME server, even if it is not accessible to the ACME client. <del> The risk of SSRF through this channel is limited by the fact that the attacker can only control the domain of the URL, not the path. Nonetheless, in order to further limit the SSRF risk, ACME server operators should ensure that validation queries can only be sent to servers on the public Internet, and not, say, web services within the server operator's internal network.  Since the attacker could make requests to these public servers himself, he can't gain anything extra through an SSRF attack on ACME aside from a layer of anonymization. </del> <ins> It might seem that the risk of SSRF through this channel is limited by the fact that the attacker can only control the domain of the URL, not the path.  However, if the attacker first sets the domain to one they control, then they can send the server an HTTP redirect (e.g., a 302 response) which will cause the server to query an arbitrary URI. In order to further limit the SSRF risk, ACME server operators should ensure that validation queries can only be sent to servers on the public Internet, and not, say, web services within the server operator's internal network.  Since the attacker could make requests to these public servers himself, he can't gain anything extra through an SSRF attack on ACME aside from a layer of anonymization. </ins> 9.5.


The JWK representation of the new key <del> Both of these thumbprints MUST be computed as specified in RFC7638, using the SHA-256 digest.  The values in the "oldKey" and "newKey" fields MUST be the base64url encodings of the thumbprints. </del> The client then encapsulates the key-change object in a JWS, signed with the client's current account key (i.e., the key matching the "oldKey" value).


MUST be the exact string provided in the Location header field in response to the new-registration request that created the account. <del> The JWK representation of the original key (i.e., the client's current account key) </del> The JWK representation of the new key The client then encapsulates the key-change object in a JWS, signed


Check that the "account" field of the key-change object contains the URL for the registration matching the old key <del> Check that the "oldKey" field of the key-change object contains the current account key. </del> Check that the "newKey" field of the key-change object contains the key used to sign the inner JWS.


6.3.2. <ins> The server MAY require a value to be present for the "external- account-binding" field.  This can be used to an ACME account with an existing account in a non-ACME system, such as a CA customer database. To enable ACME account binding, a CA needs to provision the ACME client with a MAC key and a key identifier.  The key identifier MUST be an ASCII string.  The MAC key SHOULD be provided in base64url- encoded form, to maximize compatibility between provisioning systems and ACME clients. The ACME client then computes a binding JWS to indicate the external account's approval of the ACME account key.  The payload of this JWS is the account key being registered, in JWK form.  The protected header of the JWS MUST meet the following criteria: The "alg" field MUST indicate a MAC-based algorithm The "kid" field MUST contain the key identifier provided by the CA The "nonce" field MUST NOT be present The "url" field MUST be set to the same value as the outer JWS The "signature" field of the JWS will contain the MAC value computed with the MAC key provided by the CA. When a CA receives a new-registration request containing an "external-account-binding" field, it must decide whether or not to verify the binding.  If the CA does not verify the binding, then it MUST NOT reflect the "external-account-binding" field in the resulting account object (if any).  To verify the account binding, the CA MUST take the following steps: Verify that the value of the field is a well-formed JWS Verify that the JWS protected meets the above criteria Retrieve the MAC key corresponding to the key identifier in the "kid" field Verify that the MAC on the JWS verifies using that MAC key Verify that the payload of the JWS represents the same key as was used to verify the outer JWS (i.e., the "jwk" field of the outer JWS) If all of these checks pass and the CA creates a new account, then the CA may consider the new account associated with the external account corresponding to the MAC key, and MUST reflect value of the "external-account-binding" field in the resulting account object.  If any of these checks fail, then the CA MUST reject the new- registration request. 6.3.3. </ins> A client may wish to change the public key that is associated with a account in order to recover from a key compromise or proactively mitigate the impact of an unnoticed key compromise.


responds with an error status code and a problem document describing the error. <del> 6.3.3. </del> <ins> 6.3.4. </ins> A client may deactivate an account by posting a signed update to the server with a status field of "deactivated."  Clients may wish to do


attacker from guessing it.  It MUST NOT contain any characters outside the URL-safe Base64 alphabet. <del> Number of tls-sni-01 iterations </del> A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and <del> the client's account key.  The client first computes the SHA-256 digest Z0 of the UTF8-encoded key authorization, and encodes Z0 in UTF-8 lower-case hexadecimal form.  The client then generates iterated hash values Z1...Z(n-1) as follows: The client generates a self-signed certificate for each iteration of Zi with a single subjectAlternativeName extension dNSName that is "<Zi[0:32]>.<Zi[32:64]>.acme.invalid", where "Zi[0:32]" and "Zi[32:64]" represent the first 32 and last 32 characters of the hex- encoded value, respectively (following the notation used in Python). The client then configures the TLS server at the domain such that when a handshake is initiated with the Server Name Indication extension set to "<Zi[0:32]>.<Zi[32:64]>.acme.invalid", the corresponding generated certificate is presented. </del> <ins> the client's account key.  The client computes the SHA-256 digest Z of the UTF8-encoded key authorization, and encodes Z in UTF-8 lower- case hexadecimal form. The client generates a self-signed certificate for with a single subjectAlternativeName extension dNSName that is "<Z[0:32]>.<Z[32:64]>.acme.invalid", where "Z[0:32]" and "Z[32:64]" represent the first 32 and last 32 characters of the hex-encoded value, respectively (following the notation used in Python).  The client then configures the TLS server at the domain such that when a handshake is initiated with the Server Name Indication extension set to "<Z[0:32]>.<Z[32:64]>.acme.invalid", the corresponding generated certificate is presented. </ins> The response to the TLS SNI challenge simply acknowledges that the client is ready to fulfill this challenge.


Given a Challenge/Response pair, the ACME server verifies the client's control of the domain by verifying that the TLS server was <del> configured appropriately. Choose a subset of the N iterations to check, according to local policy. </del> <ins> configured appropriately, using these steps: </ins> <del> For each iteration, compute the Zi-value from the key authorization in the same way as the client. </del> <ins> Compute the Z-value from the key authorization in the same way as the client. </ins> Open a TLS connection to the domain name being validated on the requested port, presenting the value <del> "<Zi[0:32]>.<Zi[32:64]>.acme.invalid" in the SNI field (where the </del> <ins> "<Z[0:32]>.<Z[32:64]>.acme.invalid" in the SNI field (where the </ins> comparison is case-insensitive). Verify that the certificate contains a subjectAltName extension


no other dNSName entries of the form "*.acme.invalid" are present in the subjectAltName extension. <del> It is RECOMMENDED that the ACME server verify a random subset of the N iterations with an appropriate sized to ensure that an attacker who can provision certs for a default virtual host, but not for arbitrary simultaneous virtual hosts, cannot pass the challenge.  For instance, testing a subset of 5 of N=25 domains ensures that such an attacker has only a one in 25/5 chance of success if they post certs Zn in random succession.  (This probability is enforced by the requirement that each certificate have only one Zi value.) </del> It is RECOMMENDED that the ACME server validation TLS connections from multiple vantage points to reduce the risk of DNS hijacking attacks.


This registry lists field names that are defined for use in ACME order objects.  Fields marked as "client configurable" may be <del> included in a new-account request. </del> <ins> included in a new-order request. </ins> Template:


Each ACME function is accomplished by the client sending a sequence of HTTPS requests to the server, carrying JSON messages RFC7159.  Use <del> of HTTPS is REQUIRED.  Clients SHOULD support HTTP public key pinning RFC7469, and servers SHOULD emit pinning headers.  Each subsection of certificate-management below describes the message formats used by the function and the order in which messages are sent. </del> <ins> of HTTPS is REQUIRED.  Each subsection of certificate-management below describes the message formats used by the function and the order in which messages are sent. </ins> In most HTTPS transactions used by ACME, the ACME client is the HTTPS client and the ACME server is the HTTPS server.  The ACME server acts


As noted above, DNS forgery attacks against the ACME server can result in the server making incorrect decisions about domain control <del> and thus mis-issuing certificates.  Servers SHOULD verify DNSSEC when it is available for a domain.  When DNSSEC is not available, servers SHOULD perform DNS queries over TCP, which provides better resistance to some forgery attacks than DNS over UDP. </del> <ins> and thus mis-issuing certificates.  Servers SHOULD perform DNS queries over TCP, which provides better resistance to some forgery attacks than DNS over UDP. An ACME-based CA will often need to make DNS queries, e.g., to validate control of DNS names.  Because the security of such validations ultimately depends on the authenticity of DNS data, every possible precaution should be taken to secure DNS queries done by the CA.  It is therefore RECOMMENDED that ACME-based CAs make all DNS queries via DNSSEC-validating stub or recursive resolvers.  This provides additional protection to domains which choose to make use of DNSSEC. An ACME-based CA must use only a resolver if it trusts the resolver and every component of the network route by which it is accessed.  It is therefore RECOMMENDED that ACME-based CAs operate their own DNSSEC-validating resolvers within their trusted network and use these resolvers both for both CAA record lookups and all record lookups in furtherance of a challenge scheme (A, AAAA, TXT, etc.). </ins> 10.2.


the namespace used for the TLS-based challenge (the "acme.invalid" namespace for "tls-sni-02"). <del> 10.3. An ACME-based CA will often need to make DNS queries, e.g., to validate control of DNS names.  Because the security of such validations ultimately depends on the authenticity of DNS data, every possible precaution should be taken to secure DNS queries done by the CA.  It is therefore RECOMMENDED that ACME-based CAs make all DNS queries via DNSSEC-validating stub or recursive resolvers.  This provides additional protection to domains which choose to make use of DNSSEC. An ACME-based CA must use only a resolver if it trusts the resolver and every component of the network route by which it is accessed.  It is therefore RECOMMENDED that ACME-based CAs operate their own DNSSEC-validating resolvers within their trusted network and use these resolvers both for both CAA record lookups and all record lookups in furtherance of a challenge scheme (A, AAAA, TXT, etc.). </del> 11.  References 11.1.  URIs


other certificate management functions, such as certificate revocation. <del> DISCLAIMER: This is a work in progress draft of ACME and has not yet had a thorough security analysis. </del> RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for this draft is maintained in GitHub.  Suggested changes should be submitted as pull requests at https://github.com/ietf-wg-acme/acme


7.3.5. The server MAY require a value to be present for the "external- <del> account-binding" field.  This can be used to an ACME account with an existing account in a non-ACME system, such as a CA customer database. </del> <ins> account-binding" field.  This can be used to associate an ACME account with an existing account in a non-ACME system, such as a CA customer database. </ins> To enable ACME account binding, a CA needs to provision the ACME client with a MAC key and a key identifier.  The key identifier MUST


In some cases, a CA running an ACME server might have a completely external, non-ACME process for authorizing a client to issue for an <del> identifier.  In these case, the CA should provision its ACME server </del> <ins> identifier.  In these cases, the CA should provision its ACME server </ins> with authorization objects corresponding to these authorizations and reflect them as already valid in any orders submitted by the client.


the "challenges" dictionary. The client sends these updates back to the server in the form of a <del> JSON object with the response fields required by the challenge type, carried in a POST request to the challenge URL (not authorization URL) once it is ready for the server to attempt validation. </del> <ins> JSON object with contents as specified by the challenge type, carried in a POST request to the challenge URL (not authorization URL) once it is ready for the server to attempt validation. </ins> For example, if the client were to respond to the "http-01" challenge in the above authorization, it would send the following request: The server updates the authorization document by updating its <del> representation of the challenge with the response fields provided by </del> <ins> representation of the challenge with the response object provided by </ins> the client.  The server MUST ignore any fields in the response object that are not specified as response fields for this type of challenge. The server provides a 200 (OK) response with the updated challenge


Clients SHOULD NOT respond to challenges until they believe that the server's queries will succeed.  If a server's initial validation <del> query fails, the server SHOULD retry the query after some time. While the server is still trying, the status of the challenge remains "pending"; it is only marked "invalid" once the server has given up. </del> <ins> query fails, the server SHOULD retry the query after some time, in order to account for delay in setting up responses such as DNS records or HTTP resources.  The precise retry schedule is up to the server, but server operators should keep in mind the operational scenarios that the schedule is trying to accommodate.  Given that retries are intended to address things like propagation delays in HTTP or DNS provisioning, there should not usually be any reason to retry more often than every 5 or 10 seconds.  While the server is still trying, the status of the challenge remains "pending"; it is only marked "invalid" once the server has given up. </ins> The server MUST provide information about its retry state to the client via the "errors" field in the challenge and the Retry-After


for a human user to navigate to.  If the user chooses to complete this challenge (by visiting the website and completing its instructions), the client indicates this by sending a simple <del> acknowledgement response to the server. The string "oob-01" </del> <ins> acknowledgement response to the server.  The payload of this response is an empty JSON object ("{}", or "e30" base64url-encoded). </ins> On receiving a response, the server MUST verify that the value of the "type" field is "oob-01".  Otherwise, the steps the server takes to


according to this encoding, then the verifier MUST reject the JWS as malformed. <del> 5.6. Certain elements of the protocol will require the establishment of a shared secret between the client and the server, in such a way that an entity observing the ACME protocol cannot derive the secret.  In these cases, we use a simple ECDH key exchange, based on the system used by CMS RFC5753: Inputs: Client-generated key pair Server-generated key pair Length of the shared secret to be derived Label Perform the ECDH primitive operation to obtain Z (Section 3.3.1 of SEC1) Select a hash algorithm according to the curve being used: For "P-256", use SHA-256 For "P-384", use SHA-384 For "P-521", use SHA-512 Derive the shared secret value using the KDF in Section 3.6.1 of SEC1 using Z and the selected hash algorithm, and with the UTF-8 encoding of the label as the SharedInfo value In cases where the length of the derived secret is shorter than the output length of the chosen hash algorithm, the KDF referenced above reduces to a single hash invocation.  The shared secret is equal to the leftmost octets of the following: </del> 6. In this section, we describe the certificate management functions


registration, to allow a client to retrieve the "new-authorization" and "terms-of-service" URI <del> 6.3.1. If the client wishes to establish a secret key with the server that it can use to recover this account later (a "recovery key"), then it must perform a simple key agreement protocol as part of the new- registration transaction.  The client and server perform an ECDH exchange through the new-registration transaction (using the technique in key-agreement), and the result is the recovery key. To request a recovery key, the client includes a "recoveryKey" field in its new-registration request.  The value of this field is a JSON object. The client's ECDH public key The length of the derived secret, in octets. In the client's request, this object contains a JWK for a random ECDH public key generated by the client and the client-selected length value.  Clients need to choose length values that balance security and usability.  On the one hand, a longer secret makes it more difficult for an attacker to recover the secret when it is used for recovery (see mac-based-recovery).  On the other hand, clients may wish to make the recovery key short enough for a user to easily write it down. The server MUST validate that the elliptic curve ("crv") and length value chosen by the client are acceptable, and that it is otherwise willing to create a recovery key.  If not, then it MUST reject the new-registration request. If the server agrees to create a recovery key, then it generates its own random ECDH key pair and combines it with the client's public key as described in key-agreement above, using the label "recovery".  The derived secret value is the recovery key.  The server then returns to the client the ECDH key that it generated.  The server MUST generate a fresh key pair for every transaction. The server's ECDH public key On receiving the server's response, the client can compute the recovery key by combining the server's public key together with the private key corresponding to the public key that it sent to the server. Clients may refresh the recovery key associated with a registration by sending a POST request with a new recoveryKey object.  If the server agrees to refresh the recovery key, then it responds in the same way as to a new registration request that asks for a recovery key. </del> 6.4. Once a client has created an account with an ACME server, it is


storage provider, and give the encryption key to the user as a recovery value. <del> 6.4.1. With MAC-based recovery, the client proves to the server that it holds a secret value established in the initial registration transaction.  The client requests MAC-based recovery by sending a MAC over the new account key, using the recovery key from the initial registration. The string "mac" The URI for the registration to be recovered. A JSON-formatted JWS object using an HMAC algorithm, whose payload is the JWK representation of the public key of the new account key pair. On receiving such a request the server MUST verify that: The base registration has a recovery key associated with it The "alg" value in the "mac" JWS represents a MAC algorithm The "mac" JWS is valid according to the validation rules in RFC7515, using the recovery key as the MAC key The JWK in the payload represents the new account key (i.e. the key used to verify the ACME message) If those conditions are met, and the recovery request is otherwise acceptable to the server, then the recovery process has succeeded. The server creates a new registration resource based on the base registration and the new account key, and returns it on a 201 (Created) response, together with a Location header indicating a URI for the new registration.  If the recovery request is unsuccessful, the server returns an error response, such as 403 (Forbidden). 6.4.2. In the contact-based recovery process, the client requests that the server send a message to one of the contact URIs registered for the account.  That message indicates some action that the server requires the client's user to perform, e.g., clicking a link in an email.  If the user successfully completes the server's required actions, then the server will bind the account to the new account key. </del> <ins> The client requests recovery by asking that the server send a message to one of the contact URIs registered for the account.  That message indicates some action that the server requires the client's user to perform, e.g., clicking a link in an email.  If the user successfully completes the server's required actions, then the server will bind the account to the new account key. </ins> (Note that this process is almost entirely out of band with respect to ACME.  ACME only allows the client to initiate the process, and the server to indicate the result.) <del> To initiate contact-based recovery, the client sends a POST request to the server's recover-registration URI, with a body specifying which registration is to be recovered.  The body of the request MUST be signed by the client's new account key pair. </del> <ins> To initiate recovery, the client sends a POST request to the server's recover-registration URI, with a body specifying which registration is to be recovered.  The body of the request MUST be signed by the client's new account key pair. </ins> The string "contact" The URI for the registration to be recovered. <del> If the server agrees to attempt contact-based recovery, then it creates a new registration resource containing a stub registration object.  The stub registration has the client's new account key and contacts, but no authorizations or certificates associated.  The server returns the stub contact in a 201 (Created) response, along with a Location header field indicating the URI for the new registration resource (which will be the registration URI if the recovery succeeds). </del> <ins> If the server agrees to attempt recovery, then it creates a new registration resource containing a stub registration object.  The stub registration has the client's new account key and contacts, but no authorizations or certificates associated.  The server returns the stub contact in a 201 (Created) response, along with a Location header field indicating the URI for the new registration resource (which will be the registration URI if the recovery succeeds). </ins> After recovery has been initiated, the server follows its chosen recovery process, out-of-band to ACME.  While the recovery process is


is the only one that can choose the new account key that receives the capabilities held by the account being recovered. <del> MAC-based recovery can be performed if the attacker knows the account key and registration URI for the account being recovered.  Both of these are difficult to obtain for a network attacker, because ACME uses HTTPS, though if the recovery key and registration URI are sufficiently predictable, the attacker might be able to guess them. An ACME MitM can see the registration URI, but still has to guess the recovery key, since neither the ECDH in the provisioning phase nor HMAC in the recovery phase will reveal it to him. ACME clients can thus mitigate problems with MAC-based recovery by using long recovery keys.  ACME servers should enforce a minimum recovery key length, and impose rate limits on recovery to limit an attacker's ability to test different guesses about the recovery key. Contact-based recovery uses both the ACME channel and the contact channel.  The provisioning process is only visible to an ACME MitM, and even then, the MitM can only observe the contact information provided.  If the ACME attacker does not also have access to the contact channel, there is no risk. The security of the contact-based recovery process is entirely dependent on the security of the contact channel.  The details of this will depend on the specific out-of-band technique used by the server.  For example: </del> <ins> Account recovery uses both the ACME channel and the contact channel. The provisioning process is only visible to an ACME MitM, and even then, the MitM can only observe the contact information provided.  If the ACME attacker does not also have access to the contact channel, there is no risk. The security of the recovery process is entirely dependent on the security of the contact channel.  The details of this will depend on the specific out-of-band technique used by the server.  For example: </ins> If the server requires a user to click a link in a message sent to a contact address, then the contact channel will need to ensure


In practice, many contact channels that can be used to reach many clients do not provide strong assurances of the types noted above. <del> In designing and deploying contact-based recovery schemes, ACME servers operators will need to find an appropriate balance between using contact channels that can reach many clients and using contact- based recovery schemes that achieve an appropriate level of risk using those contact channels. </del> <ins> In designing and deploying recovery schemes, ACME servers operators will need to find an appropriate balance between using contact channels that can reach many clients and using contact-based recovery schemes that achieve an appropriate level of risk using those contact channels. </ins> 9.4.


certificate. If the revocation succeeds, the server responds with status code 200 <del> (OK).  If the revocation fails, the server returns an error. </del> <ins> (OK).  If the revocation fails, the server returns an error.  For example, if the certificate has already been revoked the server returns an error response with status code 400 (Bad Request) and type "urn:ietf:params:acme:error:alreadyRevoked". </ins> 8.


configuring their TLS implementations.  ACME servers that support TLS 1.3 MAY allow clients to send early data (0-RTT).  This is safe because the ACME protocol itself includes anti-replay protections <del> (see replay-protection). </del> <ins> (see replay-protection) in all cases where they are required.  For this reason, there are no restrictions on what ACME data can be carried in 0-RTT. </ins> ACME clients MUST send a User-Agent header field, in accordance with RFC7231.  This header field SHOULD include the name and version of


"status" field. For pending authorizations, the challenges that the client can <del> fulfill in order to prove possession of the identifier.  For final authorizations (in the "valid" or "invalid" state), the challenges that were used.  Each array entry is an object with parameters required to validate the challenge.  A client should attempt to fulfill one of these challenges, and a server should consider any one of the challenges sufficient to make the authorization valid. </del> <ins> fulfill in order to prove possession of the identifier.  For valid authorizations, the challenge that was validated.  For invalid authorizations, the challenge that was attempted and failed.  Each array entry is an object with parameters required to validate the challenge.  A client should attempt to fulfill one of these challenges, and a server should consider any one of the challenges sufficient to make the authorization valid. </ins> For authorizations created as a result of a newOrder request containing a DNS identifier with a value that contained a wildcard


Authorization objects are created in the "pending" state.  If one of the challenges listed in the authorization transitions to the "valid" state, then the authorization also changes to the "valid" state.  If <del> there is an error while the authorization is still pending, then the </del> <ins> the client attempts to fulfill a challenge and fails, or if there is an error while the authorization is still pending, then the </ins> authorization transitions to the "invalid" state.  Once the authorization is in the valid state, it can expire ("expired"), be deactivated by the client ("deactivated", see deactivating-an-


can't obtain illegitimate authorization by acting as an ACME client (legitimately, in terms of the protocol). <ins> ACME does not protect against other types of abuse by a MitM on the ACME channel.  For example, such an attacker could send a bogus "badSignatureAlgorithm" error response to downgrade a client to the lowest-quality signature algorithm that the server supports.  A MitM that is present on all connections (such as a CDN), can cause denial- of-service conditions in a variety of ways. </ins> 10.2. ACME allows anyone to request challenges for an identifier by


9.1. A file of this type contains one or more certificates encoded with <del> the PEM textual encoding, according to RFC 7468 RFC7468.  In order to provide easy interoperation with TLS, the first certificate MUST be an end-entity certificate.  Each following certificate SHOULD directly certify the one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that represents a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </del> <ins> the PEM textual encoding, according to RFC 7468 RFC7468.  The textual encoding of certificates in this file MUST use the strict encoding and MUST NOT include explanatory text.  The ABNF for this format is as follows, where "stricttextualmsg" and "eol" are as defined in Section 3 of RFC 7468: In order to provide easy interoperation with TLS, the first certificate MUST be an end-entity certificate.  Each following certificate SHOULD directly certify the one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that represents a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </ins> The "Media Types" registry should be updated with the following additional value:


anchors.  Clients can fetch these alternates and use their own heuristics to decide which is optimal. <del> An ACME client MAY attempt to fetch the certificate with a GET request.  If the server does not allow GET requests for certificate resources, then it will return an error as described in post-as-get. On receiving such an error, the client SHOULD fall back to a POST-as- GET request. </del> A certificate resource represents a single, immutable certificate. If the client wishes to obtain a renewed certificate, the client initiates a new order process to request one.


with an array of supported "alg" values.  See errors for more details on the structure of error responses. <ins> If the server supports the signature algorithm "alg" but either does not support or chooses to reject the public key "jwk", then the server MUST return an error with status code 400 (Bad Request) and type "urn:ietf:params:acme:error:badPublicKey".  The problem document detail SHOULD describe the reason for rejecting the public key; some example reasons are: "alg" is "RS256" but the modulus "n" is too small (e.g., 512-bit) "alg" is "ES256" but "jwk" does not contain a valid P-256 public key "alg" is "EdDSA" and "crv" is "Ed448", but the server only supports "EdDSA" with "Ed25519" the corresponding private key is known to have been compromised </ins> Because client requests in ACME carry JWS objects in the Flattened JSON Serialization, they must have the Content-Type header field set to "application/jose+json".  If a request does not meet this


process can be represented and performed by Internet protocols with no out-of-band human intervention. <del> When an operator deploys a current HTTPS server, it generally prompts him to generate a self-signed certificate.  When an operator deploys an ACME-compatible web server, the experience would be something like this: </del> <ins> When deploying a current HTTPS server, an operator generally gets a prompt to generate a self-signed certificate.  When an operator deploys an ACME-compatible web server, the experience would be something like this: </ins> The ACME client prompts the operator for the intended domain name(s) that the web server is to stand for.


certificate was issued, and one with relation "author" to indicate the registration under which this certificate was issued. <del> The server MAY include an Expires header as a hint to the client about when to renew the certificate.  (Of course, the real expiration of the certificate is controlled by the notAfter time in the certificate itself.) </del> If the CA participates in Certificate Transparency (CT) RFC6962, then they may want to provide the client with a Signed Certificate Timestamp (SCT) that can be used to prove that a certificate was


for a certificate using a Link relation header field with relation "ct-sct". <del> A certificate resource always represents the most recent certificate issued for the name/key binding expressed in the CSR.  If the CA allows a certificate to be renewed, then it publishes renewed versions of the certificate through the same certificate URI. Clients retrieve renewed versions of the certificate using a GET query to the certificate URI, which the server should then return in a 200 (OK) response.  The server SHOULD provide a stable URI for each specific certificate in the Content-Location header field, as shown above.  Requests to stable certificate URIs MUST always result in the same certificate. To avoid unnecessary renewals, the CA may choose not to issue a renewed certificate until it receives such a request (if it even allows renewal at all).  In such cases, if the CA requires some time to generate the new certificate, the CA MUST return a 202 (Accepted) response, with a Retry-After header field that indicates when the new certificate will be available.  The CA MAY include the current (non- renewed) certificate as the body of the response. Likewise, in order to prevent unnecessary renewal due to queries by parties other than the account key holder, certificate URIs should be structured as capability URLs W3C.WD-capability-urls-20140218. From the client's perspective, there is no difference between a certificate URI that allows renewal and one that does not.  If the client wishes to obtain a renewed certificate, and a GET request to the certificate URI does not yield one, then the client may initiate a new-certificate transaction to request one. </del> <ins> A certificate resource represents a single, immutable certificate. If the client wishes to obtain a renewed certificate, the client initiates a new-certificate transaction to request one. Because certificate resources are immutable once issuance is complete, the server MAY enable the caching of the resource by adding Expires and Cache-Control headers specifying a point in time in the distant future.  These headers have no relation to the certificate's period of validity. </ins> 6.6.


In addition, the client MAY advise the server at which IP the challenge is provisioned: <del> An IPv4 or IPv6 address which, if given, MUST be included in the set of IP addresses to which the domain name resolves.  If given, the server will connect to that specific IP address instead of arbitrarily choosing an IP from the set of A and AAAA records to which the domain name resolves.  If the field is given but equal to ""peer"", the server MUST treat the field as if it contained the IP address from which the response was received. </del> <ins> An IPv4 or IPv6 address which, in dotted decimal form or RFC4291 form, respectively.  If given, this address MUST be included in the set of IP addresses to which the domain name resolves.  If given, the server SHOULD connect to that specific IP address instead of arbitrarily choosing an IP from the set of A and AAAA records to which the domain name resolves. </ins> On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the


IANA is requested to register the following Service Names: <ins> 7.5. The IANA is requested to list the name "masa" in the MUD extensions registry defined in I-D.ietf-opsawg-mud.  Its use is documented in mud-extension. </ins> 8. 8.1.


"Connection Priority" on one Connection does not change it on the other Connections in the same Connection Group. <ins> The optional "connectionProperties" parameter allows passing Transport Properties that control the behavior of the underlying stream or connection to be created, e.g., protocol-specific properties to request specific stream IDs for SCTP or QUIC. </ins> Message Properties set on a Connection also apply only to that Connection.


Data Unit: Datagram The Transport Services API mappings for UDP-Lite are identical to <del> UDP.  Properties that require checksum coverage are not supported by UDP-Lite, such as "msgChecksumLen", "fullChecksumSend", "recvChecksumLen", and "fullChecksumRecv". </del> <ins> UDP.  In addition, UDP-Lite supports the "msgChecksumLen" and "recvChecksumLen" Properties that allow an application to specify the minimum number of bytes in a message that need to be covered by a checksum. </ins> 10.5.


of efficiency.  This is not a strict requirement.  The default is to not have this option. <del> Notification of special errors (excessive retransmissions, ICMP error message arrival): This boolean property specifies whether an application considers it useful to be informed in case sent data was retransmitted more often than a certain threshold, or when an ICMP error message arrives.  This property applies to Connections and Connection Groups.  This is not a strict requirement.  The default is to have this option. </del> <ins> Notification of excessive retransmissions: This boolean property specifies whether an application considers it useful to be informed in case sent data was retransmitted more often than a certain threshold.  This property applies to Connections and Connection Groups.  This is not a strict requirement.  The default is to have this option. Notification of ICMP error message arrival: This boolean property specifies whether an application considers it useful to be informed when an ICMP error message arrives.  This property applies to Connections and Connection Groups.  This is not a strict requirement.  The default is to have this option. </ins> Control checksum coverage on sending or receiving: This boolean property specifies whether the application considers it useful to


Remote Endpoint and the Local Endpoint, such as IP addresses resolved from a DNS hostname. <ins> 4.2.3. While some transports expose a byte stream abstraction, most higher level protocols impose some structure onto that byte stream.  That is, the higher level protocol operates in terms of messages, protocol data units (PDUs), rather than using unstructured sequences of bytes, with each message being processed in turn.  Protocols are specified in terms of state machines acting on semantic messages, with parsing the byte stream into messages being a necessary annoyance, rather than a semantic concern.  Accordingly, the Transport Services architecture exposes messages as the primary abstraction.  Protocols that deal only in byte streams, such as TCP, represent their data in each direction as a single, long message.  When framing protocols are placed on top of byte streams, the messages used in the API represent the framed messages within the stream. Providing a message-based abstraction also provides: the ability to associate deadlines with messages, for transports that care about timing; the ability to provide control of reliability, choosing what messages to retransmit in the event of packet loss, and how best to make use of the data that arrived; the ability to manage dependencies between messages, when some messages may not be delivered due to either packet loss or missing a deadline, in particular the ability to avoid (re-)sending data that relies on a previous transmission that was never received. All require explicit message boundaries, and application-level framing of messages, to be effective.  Once a message is passed to the transport, it can not be cancelled or paused, but prioritization as well as lifetime and retransmission management will provide the protocol stack with all needed information to send the messages as quickly as possible without blocking transmission unnecessarily.  The transport services architecture facilitates this by handling messages, with known identity (sequence numbers, in the simple case), lifetimes, niceness, and antecedents. Transport protocols such as SCTP provide a message-oriented API that has similar features to those we describe.  Other transports, such as TCP, do not.  To support a message oriented API, while still being compatible with stream-based transport protocols, implementations of the transport services architecture should provide APIs for framing and de-framing messages.  That is, we push message framing down into the transport services API, allowing applications to send and receive complete messages.  This is backwards compatible with existing protocols and APIs, since the wire format of messages does not change, but gives the protocol stack additional information to allow it to make better use of modern transport services. </ins> 5. RFC-EDITOR: Please remove this section before publication.


Boolean <del> If true, it specifies that a Message should be delivered to the other side after the previous Message which was passed to the same Connection via the Send Action.  If false, the Message may be delivered out of order.  This property is used for protocols that support preservation of data ordering, see prop-ordering, but allow out-of-order delivery for certain messages. </del> <ins> If true, it specifies that the receiver-side transport protocol stack only deliver the Message to the receiving application after the previous ordered Message which was passed to the same Connection via the Send Action, when such a Message exists.  If false, the Message may be delivered to the receiving application out of order.  This property is used for protocols that support preservation of data ordering, see prop-ordering, but allow out-of-order delivery for certain messages. </ins> 7.3.4.


This property specifies that a message should be sent in such a way that the transport protocol ensures all data is received on the other side without corruption.  Changing the 'Reliable Data Transfer' <del> property on Messages is only possible if the transport protocol supports partial reliability (see prop-partially-reliable). Therefore, for protocols that always transfer data reliably, this property is always true and for protocols that always transfer data unreliably, this property is always false.  Changing it may generate an error. </del> <ins> property on Messages is only possible if the Connection supports reliability.  When this is not the case, changing it will generate an error. </ins> 7.3.8.


Preconnection, Connection (read only) <del> This property specifies whether the application wishes to use a </del> <ins> This property specifies whether the application needs to use a </ins> transport protocol that ensures that all data is received on the other side without corruption.  This also entails being notified when a Connection is closed or aborted.  The default is to enable Reliable


12.3.22. <ins> [TODO: Discuss: should we remove this?  Whether we need this or the other depends on how we want to implement multi-streaming.  We don't need both, so we should make a decision.] </ins> Integer Message Property - see msg-niceness. Note that this property is not a per-message override of the connection Niceness - see conn-niceness.  Both Niceness properties <del> may interact, but can be used indepentendly and be realized by </del> <ins> may interact, but can be used independently and be realized by </ins> different mechanisms. 12.3.23.


as an asynchronous interface, they generally use a try-and-fail model.  If the application wants to read, but data has not yet been received from the peer, the call to read will fail.  The application <del> then waits for a notification to indicate when it can try again. </del> <ins> then waits and can try again later. </ins> All interaction with a Transport Services system is expected to be asynchronous, and use an event-driven model unlike sockets events.


5.2.10. <ins> This property specifies whether an application considers it useful to transfer data across multiple paths between the same end hosts. Generally, in most cases, this will improve performance (e.g., achieve greater throughput).  One possible side-effect is increased jitter, which may be problematic for delay-sensitive applications. The recommended default is to have this option. 5.2.11. </ins> This property specifies whether an application wants to use the connection for sending and/or receiving data.  Possible values are:


connections are not supported by the transport protocol, the system should fall back to bidirectional transport. <ins> 5.2.12. This property specifies how long to wait before aborting a Connection during establishment. </ins> 5.3. Most security parameters, e.g., TLS ciphersuites, local identity and


7.6. For application-layer protocols where the Connection initiator also <del> sends the first message, the InitiateWithIdempotentSend() action combines Connection initiation with a first Message sent, provided that message is idempotent. </del> <ins> sends the first message, the InitiateWithSend() action combines Connection initiation with a first Message sent. </ins> Without a message context (as in send-basic): With a message context (as in message-props): <del> The message passed to InitiateWithIdempotentSend() is, as suggested by the name, considered to be idempotent (see msg-idempotent) regardless of declared message properties or defaults.  If protocol stacks supporting 0-RTT establishment with idempotent data are available on the Preconnection, then 0-RTT establishment may be used with the given message when establishing candidate connections.  For a non-idemponent initial message, or when the selected stack(s) do not support 0-RTT establishment, InitiateWithIdempotentSend is identical to Initiate() followed by Send(). </del> <ins> Whenever possible, a messageContext should be provided to declare the message passed to InitiateWithSend as idempotent.  This allows the transport system to make use of 0-RTT establishment in case this is supported by the available protocol stacks.  When the selected stack(s) do not support transmitting data upon connection establishment, InitiateWithSend is identical to Initiate() followed by Send(). </ins> Neither partial sends nor send batching are supported by <del> InitiateWithIdempotentSend(). </del> <ins> InitiateWithSend(). </ins> <del> The Events that may be sent after InitiateWithIdempotentSend() are equivalent to those that would be sent by an invocation of Initate() followed immediately by an invocation of Send(), with the caveat that a send failure that occurs because the Connection could not be established will not result in a SendError separate from the InitiateError signaling the failure of Connection establishment. </del> <ins> The Events that may be sent after InitiateWithSend() are equivalent to those that would be sent by an invocation of Initate() followed immediately by an invocation of Send(), with the caveat that a send failure that occurs because the Connection could not be established will not result in a SendError separate from the InitiateError signaling the failure of Connection establishment. </ins> 7.7.


9.1.6. <del> Integer This property specifies how long to wait before aborting a Connection during establishment, or before deciding that a Connection has failed after establishment.  It is given in seconds. </del> <ins> This property specifies how long to wait before deciding that a Connection has failed after establishment. </ins> 9.1.7.


Abort terminates a Connection without delivering remaining data: <del> A ConnectionError can inform the application that the other side has aborted the Connection; however, there is no guarantee that an Abort will indeed be signaled. </del> <ins> A ConnectionError informs the application that data to could not be delivered after a timeout, or the other side has aborted the Connection; however, there is no guarantee that an Abort will indeed be signaled. </ins> 11.


events: Ready<> occurs when a Connection created with Initiate() or <del> InitiateWithIdempotentData() transitions to Established state. </del> <ins> InitiateWithSend() transitions to Established state. </ins> ConnectionReceived<> occurs when a Connection created with Listen() transitions to Established state.


Selection properties are represented as preferences, which can have one of five preference levels: <ins> In addition, the pseudo-level "Default" can be used to reset the property to the default level used by the implementation.  This level will never show up when queuing the value of a preference - the effective preference must be returned instead. </ins> Internally, the transport system will first exclude all protocols and paths that match a Prohibit, then exclude all protocols and paths that do not match a Require, then sort candidates according to


Passive open is the Action of waiting for Connections from remote endpoints, commonly used by servers in client-server interactions. <del> Passive open is supported by this interface through the Listen Action: </del> <ins> Passive open is supported by this interface through the Listen Action and returns a Listener object: </ins> Before calling Listen, the caller must have initialized the Preconnection during the pre-establishment phase with a Local Endpoint specifier, as well as all properties necessary for Protocol Stack selection.  A Remote Endpoint may optionally be specified, to <del> constrain what Connections are accepted.  The Listen() Action consumes the Preconnection.  Once Listen() has been called, no further properties may be added to the Preconnection, and no subsequent establishment call may be made on the Preconnection. </del> <ins> constrain what Connections are accepted.  The Listen() Action returns a Listener object.  Once Listen() has been called, properties added to the Preconnection have no effect on the Listener and the Preconnection can be disposed of or reused. </ins> Listening continues until the global context shuts down, or until the <del> Stop action is performed on the same Preconnection: </del> <ins> Stop action is performed on the Listener object: </ins> <del> After Stop() is called, the preconnection can be disposed of. </del> <ins> After Stop() is called, the Listener can be disposed of. </ins> The ConnectionReceived Event occurs when a Remote Endpoint has <del> established a transport-layer connection to this Preconnection (for </del> <ins> established a transport-layer connection to this Listener (for </ins> Connection-oriented transport protocols), or when the first Message has been received from the Remote Endpoint (for Connectionless protocols), causing a new Connection to be created.  The resulting


ready to use as soon as it is passed to the application via the event. <del> A ListenError occurs either when the Preconnection cannot be fulfilled for listening, when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. </del> <ins> A ListenError occurs either when the Properties of the Preconnection cannot be fulfilled for listening, when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. </ins> <del> A Stopped event occurs after the Preconnection has stopped listening. </del> <ins> A Stopped event occurs after the Listener has stopped listening. </ins> 6.3.


6.4. <del> Groups of Connections can be created using the Clone Action: </del> <ins> Entangled Connections can be created using the Clone Action: </ins> Calling Clone on a Connection yields a group of two Connections: the parent Connection on which Clone was called, and the resulting cloned


on.  Connections in a Connection Group share all Protocol Properties that are not applicable to a Message. <ins> In addition, incoming entangled Connections can be received by creating a Listener on an existing connection: </ins> Changing one of these Protocol Properties on one Connection in the group changes it for all others.  Per-Message Protocol Properties, however, are not entangled.  For example, changing "Timeout for


9. <ins> Each protocol that can run as part of a Transport Services implementation defines both its API mapping as well as implementation details. API mappings for a protocol apply most to Connections in which the given protocol is the "top" of the Protocol Stack.  For example, the mapping of the "Send" function for TCP applies to Connections in which the application directly sends over TCP.  If HTTP/2 is used on top of TCP, the HTTP/2 mappings take precendence. Each protocol has a notion of Connectedness.  Possible values for Connectedness are: Unconnected.  Unconnected protocols do not establish explicit state between endpoints, and do not perform a handshake during Connection establishment. Connected.  Connected protocols establish state between endpoints, and perform a handshake during Connection establishment.  The handshake may be 0-RTT to send data or resume a session, but bidirectional traffic is required to confirm connectedness. Multiplexing Connected.  Multiplexing Connected protocols share properties with Connected protocols, but also explictly support opening multiple application-level flows.  This means that they can support cloning new Connection objects without a new explicit handshake. Protocols also define a notion of Data Unit.  Possible values for Data Unit are: Byte-stream.  Byte-stream protocols do not define any Message boundaries of their own apart from the end of a stream in each direction. Datagram.  Datagram protocols define Message boundaries at the same level of transmission, such that only complete (not partial) Messages are supported. Message.  Message protocols support Message boundaries that can be sent and received either as complete or partial Messages.  Maximum Message lengths can be defined, and Messages can be partially reliable. </ins> 9.1. <del> Connection lifetime for TCP translates fairly simply into the the abstraction presented to an application.  When the TCP three-way handshake is complete, its layer of the Protocol Stack can be considered Ready (established).  This event will cause racing of Protocol Stack options to complete if TCP is the top-level protocol, at which point the application can be notified that the Connection is Ready to send and receive. If the application sends a Close, that can translate to a graceful termination of the TCP connection, which is performed by sending a FIN to the remote endpoint.  If the application sends an Abort, then the TCP state can be closed abruptly, leading to a RST being sent to the peer. Without a layer of framing (a top-level protocol in the established Protocol Stack that preserves message boundaries, or an application- supplied deframer) on top of TCP, the receiver side of the transport system implementation can only treat the incoming stream of bytes as a single Message, terminated by a FIN when the Remote Endpoint closes the Connection. </del> <ins> Connectedness: Connected Data Unit: Byte-stream API mappings for TCP are as follows: TCP connections between two hosts map directly to Connection objects. Calling "Initiate" on a TCP Connection causes it to reserve a local port, and send a SYN to the Remote Endpoint. Early idempotent data is sent on a TCP Connection in the SYN, as TCP Fast Open data. A TCP Connection is ready once the three-way handshake is complete. TCP can throw various errors during connection setup. Specifically, it is important to handle a RST being sent by the peer during the handshake. Once established, TCP throws errors whenever the connection is disconnected, such as due to receive a RST from the peer; or hitting a TCP retransmission timeout. Calling "Listen" for TCP binds a local port and prepares it to receive inbound SYN packets from peers. TCP Listeners will deliver new connections once they have replied to an inbound SYN with a SYN-ACK. Calling "Clone" on a TCP Connection creates a new Connection with equivalent parameters.  The two Connections are otherwise independent. TCP does not on its own preserve Message boundaries.  Calling "Send" on a TCP connection lays out the bytes on the TCP send stream without any other delineation.  Any Message marked as Final will cause TCP to send a FIN once the Message has been completely written. TCP delivers a stream of bytes without any Message delineation. All data delivered in the "Received" or "ReceivedPartial" event will be part of a single stream-wide Message that is marked Final (unless a MessageFramer is used).  EndOfMessage will be delivered when the TCP Connection has received a FIN from the peer. Calling "Close" on a TCP Connection indicates that the Connection should be gracefully closed by sending a FIN to the peer and waiting for a FIN-ACK before delivering the "Closed" event. Calling "Abort" on a TCP Connection indicates that the Connection should be immediately closed by sending a RST to the peer. </ins> 9.2. <del> UDP as a direct transport does not provide any handshake or connectivity state, so the notion of the transport protocol becoming Ready or established is degenerate.  Once the system has validated that there is a route on which to send and receive UDP datagrams, the protocol is considered Ready.  Similarly, a Close or Abort has no meaning to the on-the-wire protocol, but simply leads to the local state being torn down. </del> <ins> Connectedness: Unconnected </ins> <del> When sending and receiving messages over UDP, each Message should correspond to a single UDP datagram.  The Message can contain metadata about the packet, such as the ECN bits applied to the packet. </del> <ins> Data Unit: Datagram </ins> <del> 9.3. </del> <ins> API mappings for UDP are as follows: </ins> <del> To support sender-side stream schedulers (which are implemented on the sender side), a receiver-side Transport System should always support message interleaving RFC8260. </del> <ins> UDP connections represent a pair of specific IP addresses and ports on two hosts. </ins> <del> SCTP messages can be very large.  To allow the reception of large messages in pieces, a "partial flag" can be used to inform a (native SCTP) receiving application that a message is incomplete.  After receiving the "partial flag", this application would know that the next receive calls will only deliver remaining parts of the same message (i.e., no messages or partial messages will arrive on other streams until the message is complete) (see Section 8.1.20 in RFC6458).  The "partial flag" can therefore facilitate the implementation of the receiver buffer in the receiving application, at the cost of limiting multiplexing and temporarily creating head- of-line blocking delay at the receiver. </del> <ins> Calling "Initiate" on a UDP Connection causes it to reserve a local port, but does not generate any traffic. </ins> <del> When a Transport System transfers a Message, it seems natural to map the Message object to SCTP messages in order to support properties such as "Ordered" or "Lifetime" (which maps onto partially reliable delivery with a SCTP_PR_SCTP_TTL policy RFC6458).  However, since multiplexing of Connections onto SCTP streams may happen, and would be hidden from the application, the Transport System requires a per- stream receiver buffer anyway, so this potential benefit is lost and the "partial flag" becomes unnecessary for the system. </del> <ins> Early data on a UDP Connection does not have any special meaning. The data is sent whenever the Connection is Ready. </ins> <del> The problem of long messages either requiring large receiver-side buffers or getting in the way of multiplexing is addressed by message interleaving RFC8260, which is yet another reason why a receivers- side transport system supporting SCTP should implement this mechanism. </del> <ins> A UDP Connection is ready once the system has reserved a local port and has a path to send to the Remote Endpoint. </ins> <del> 9.4. </del> <ins> UDP Connections can only generate errors on initiation due to port conflicts on the local system. Once in use, UDP throws errors upon receiving ICMP notifications indicating failures in the network. Calling "Listen" for UDP binds a local port and prepares it to receive inbound UDP datagrams from peers. UDP Listeners will deliver new connections once they have received traffic from a new Remote Endpoint. Calling "Clone" on a UDP Connection creates a new Connection with equivalent parameters.  The two Connections are otherwise independent. Calling "Send" on a UDP connection sends the data as the payload of a complete UDP datagram.  Marking Messages as Final does not change anything in the datagram's contents. UDP only delivers complete Messages to "Received", each of which represents a single datagram received in a UDP packet. Calling "Close" on a UDP Connection releases the local port reservation. Calling "Abort" on a UDP Connection is identical to calling "Close". 9.3. </ins> The mapping of a TLS stream abstraction into the application is <del> equivalent to the contract provided by TCP (see tcp).  The Ready state should be determined by the completion of the TLS handshake, which involves potentially several more round trips beyond the TCP handshake.  The application should not be notified that the Connection is Ready until TLS is established. </del> <ins> equivalent to the contract provided by TCP (see tcp), and builds upon many of the actions of TCP connections. Connectedness: Connected Data Unit: Byte-stream Connection objects represent a single TLS connection running over a TCP connection between two hosts. Calling "Initiate" on a TLS Connection causes it to first initiate a TCP connection.  Once the TCP protocol is Ready, the TLS handshake will be performed as a client (starting by sending a "client_hello", and so on). Early idempotent data is supported by TLS 1.3, and sends encrypted application data in the first TLS message when performing session resumption.  For older versions of TLS, or if a session is not being resumed, the initial data will be delayed until the TLS handshake is complete.  TCP Fast Option can also be enabled automatically. A TLS Connection is ready once the underlying TCP connection is Ready, and TLS handshake is also complete and keys have been established to encrypt application data. In addition to TCP initiation errors, TLS can generate errors during its handshake.  Examples of error include a failure of the peer to successfully authenticate, the peer rejecting the local authentication, or a failure to match versions or algorithms. TLS connections will generate TCP errors, or errors due to failures to rekey or decrypt received messages. Calling "Listen" for TLS listens on TCP, and sets up received connections to perform server-side TLS handshakes. TLS Listeners will deliver new connections once they have successfully completed both TCP and TLS handshakes. As with TCP, calling "Clone" on a TLS Connection creates a new Connection with equivalent parameters.  The two Connections are otherwise independent. Like TCP, TLS does not preserve message boundaries.  Although application data is framed natively in TLS, there is not a general guarantee that these TLS messages represent semantically meaningful application stream boundaries.  Rather, sending data on a TLS Connection only guarantees that the application data will be transmitted in an encrypted form.  Marking Messages as Final causes a "close_notify" to be generated once the data has been written. Like TCP, TLS delivers a stream of bytes without any Message delineation.  The data is decrypted prior to being delivered to the application.  If a "close_notify" is received, the stream-wide Message will be delivered with EndOfMessage set. Calling "Close" on a TLS Connection indicates that the Connection should be gracefully closed by sending a "close_notify" to the peer and waiting for a corresponding "close_notify" before delivering the "Closed" event. Calling "Abort" on a TCP Connection indicates that the Connection should be immediately closed by sending a "close_notify", optionally preceded by "user_canceled", to the peer. Implementations do not need to wait to receive "close_notify" before delivering the "Closed" event. 9.4. DTLS follows the same behavior as TLS (tls), with the notable exception of not inheriting behavior directly from TCP.  Differences from TLS are detailed below, and all cases not explicitly mentioned should be considered the same as TLS. Connectedness: Connected Data Unit: Datagram Connection objects represent a single DTLS connection running over a set of UDP ports between two hosts. Calling "Initiate" on a DTLS Connection causes it reserve a UDP local port, and begin sending handshake messages to the peer over UDP.  These messages are reliable, and will be automatically retransmitted. A DTLS Connection is ready once the TLS handshake is complete and keys have been established to encrypt application data. Sending over DTLS does preserve message boundaries in the same way that UDP datagrams do.  Marking a Message as Final does send a "close_notify" like TLS. Receiving over DTLS delivers one decrypted Message for each received DTLS datagram.  If a "close_notify" is received, a Message will be delivered that is marked as Final. </ins> 9.5.


Message representing the body, and the Headers being provided in Message metadata. <ins> Connectedness: Multiplexing Connected Data Unit: Message Connection objects represent a flow of HTTP messages between a client and a server, which may be an HTTP/1.1 connection over TCP, or a single stream in an HTTP/2 connection. Calling "Initiate" on an HTTP connection intiates a TCP or TLS connection as a client. Calling "Clone" on an HTTP Connection opens a new stream on an existing HTTP/2 connection when possible.  If the underlying version does not support multiplexed streams, calling "Clone" simply creates a new parallel connection. When an application sends an HTTP Message, it is expected to provide HTTP header values as a MessageContext in a canonical form, along with any associated HTTP message body as the Message data.  The HTTP header values are encoded in the specific version format upon sending. HTTP Connections deliver Messages in which HTTP header values attached to MessageContexts, and HTTP bodies in Message data. Calling "Close" on an HTTP Connection will only close the underlying TLS or TCP connection if the HTTP version does not support multiplexing.  For HTTP/2, for example, closing the connection only closes a specific stream. </ins> 9.6. QUIC provides a multi-streaming interface to an encrypted transport.


Closing a single QUIC stream, presented to the application as a Connection, does not imply closing the underlying QUIC connection itself.  Rather, the implementation may choose to close the QUIC <del> connection once all streams have been closed (possibly after some </del> <ins> connection once all streams have been closed (often after some </ins> timeout), or after an individual stream Connection sends an Abort. <del> Messages over a direct QUIC stream should be represented similarly to the TCP stream (one Message per direction, see tcp), unless a framing mapping is used on top of QUIC. </del> <ins> Connectedness: Multiplexing Connected Data Unit: Stream Connection objects represent a single QUIC stream on a QUIC connection. </ins> 9.7.


over the streams can be represented similarly to the TCP stream (one Message per direction, see tcp). <ins> Connectedness: Multiplexing Connected Data Unit: Stream Connection objects represent a single HTTP/2 stream on a HTTP/2 connection. 9.8. To support sender-side stream schedulers (which are implemented on the sender side), a receiver-side Transport System should always support message interleaving RFC8260. SCTP messages can be very large.  To allow the reception of large messages in pieces, a "partial flag" can be used to inform a (native SCTP) receiving application that a message is incomplete.  After receiving the "partial flag", this application would know that the next receive calls will only deliver remaining parts of the same message (i.e., no messages or partial messages will arrive on other streams until the message is complete) (see Section 8.1.20 in RFC6458).  The "partial flag" can therefore facilitate the implementation of the receiver buffer in the receiving application, at the cost of limiting multiplexing and temporarily creating head- of-line blocking delay at the receiver. When a Transport System transfers a Message, it seems natural to map the Message object to SCTP messages in order to support properties such as "Ordered" or "Lifetime" (which maps onto partially reliable delivery with a SCTP_PR_SCTP_TTL policy RFC6458).  However, since multiplexing of Connections onto SCTP streams may happen, and would be hidden from the application, the Transport System requires a per- stream receiver buffer anyway, so this potential benefit is lost and the "partial flag" becomes unnecessary for the system. The problem of long messages either requiring large receiver-side buffers or getting in the way of multiplexing is addressed by message interleaving RFC8260, which is yet another reason why a receivers- side transport system supporting SCTP should implement this mechanism. </ins> 10. RFC-EDITOR: Please remove this section before publication.


to force early binding when required, for example with some Network Address Translator (NAT) traversal protocols (see rendezvous). <ins> Specifying a multicast group address on the Local Endpoint will indicate to the transport system that the resulting connection will be used to receive multicast messages.  The Remote Endpoint can be used to filter by specific senders.  This will restrict the application to establishing the Preconnection by calling Listen(). The accepted Connections are receive-only. Similarly, specifying a multicast group address on the Remote Endpoint will indicate that the resulting connection will be used to send multicast messages. </ins> 5.2. A Preconnection Object holds properties reflecting the application's


Integer (non-negative with -1 as special value) <del> full coverage </del> <ins> -1 (full coverage) </ins> This property specifies the minimum length of the section of the Message, starting from byte 0, that the application requires to be


to specify options for simple integrity protection via checksums.  A value of 0 means that no checksum is required, and -1 means that the entire Message is protected by a checksum.  Only full coverage is <del> guaranteed, any other requests are advisory. </del> <ins> guaranteed, any other requests are advisory, meaning that full coverage is applied anyway. </ins> 7.4.7.