Specify a Local Endpoint using a local interface name and local port: <ins> As an alternative to specifying an interface name for the Local Endpoint, an application can express more fine-grained preferences using the "Interface Instance or Type" Selection Property, see prop- interface.  However, if the application specifies Selection Properties which are inconsistent with the Local Endpoint, this will result in an error once the application attempts to open a Connection. </ins> Specify a Local Endpoint using a STUN server: Specify a Local Endpoint using a Any-Source Multicast group to join


higher value.  By default, this value is Infinite.  The caller is also able to reset the value to Infinite at any point. <del> 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. </del> <ins> A ListenError occurs either when the Properties and Security Parameters of the Preconnection cannot be fulfilled for listening or cannot be reconciled with the Local Endpoint (and/or Remote Endpoint, if specified), when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. </ins> A Stopped Event occurs after the Listener has stopped listening.


contained within the RendezvousDone<> Event, and is ready to use as soon as it is passed to the application via the Event. <del> An RendezvousError occurs either when the Preconnection cannot be fulfilled for listening, when the Local Endpoint or Remote Endpoint cannot be resolved, when no transport-layer connection can be established to the Remote Endpoint, or when the application is prohibited from rendezvous by policy. </del> <ins> An RendezvousError occurs either when the Properties and Security Parameters of the Preconnection cannot be fulfilled for rendezvous or cannot be reconciled with the Local and/or Remote Endpoints, when the Local Endpoint or Remote Endpoint cannot be resolved, when no transport-layer connection can be established to the Remote Endpoint, or when the application is prohibited from rendezvous by policy. </ins> When using some NAT traversal protocols, e.g., Interactive Connectivity Establishment (ICE) RFC5245, it is expected that the


The Transport Services architecture evolves this general model of interaction, aiming to both modernize the API surface presented to applications by the transport layer and enrich the capabilities of <del> the Transport System implementation.  It combines interfaces for </del> <ins> the Transport Services implementation.  It combines interfaces for </ins> multiple interaction patterns into a unified whole.  By combining name resolution with connection establishment and data transfer in a single API, it allows for more flexible implementations to provide


make use of the data that arrived; the ability to manage dependencies between messages, when the <del> Transport System could decide to not deliver a message, either following packet loss or because it has missed a deadline.  In particular, this can avoid (re-)sending data that relies on a </del> <ins> Transport Services system could decide to not deliver a message, either following packet loss or because it has missed a deadline. In particular, this can avoid (re-)sending data that relies on a </ins> previous transmission that was never received. the ability to automatically assign messages and connections to


Transport Properties: Transport Properties allow the application to express their requirements, prohibitions, and preferences and <del> configure the Transport System.  There are three kinds of </del> <ins> configure the Transport Services system.  There are three kinds of </ins> Transport Properties: Selection Properties (preestablishment) that can only be


Connection Properties: The Connection Properties are used to configure protocol-specific options and control per-connection <del> behavior of the Transport System; for example, a protocol-specific Connection Property can express that if UDP is used, the implementation ought to use checksums.  Note that the presence of such a property does not require that a specific protocol will be used.  In general, these properties do not explicitly determine the selection of paths or protocols, but can be used in this way by an implementation during connection establishment.  Connection Properties are specified on a Preconnection prior to Connection establishment, and can be modified on the Connection later. Changes made to Connection Properties after Connection establishment take effect on a best-effort basis. </del> <ins> behavior of the Transport Services system; for example, a protocol-specific Connection Property can express that if UDP is used, the implementation ought to use checksums.  Note that the presence of such a property does not require that a specific protocol will be used.  In general, these properties do not explicitly determine the selection of paths or protocols, but can be used in this way by an implementation during connection establishment.  Connection Properties are specified on a Preconnection prior to Connection establishment, and can be modified on the Connection later.  Changes made to Connection Properties after Connection establishment take effect on a best- effort basis. </ins> 4.1.3.


Properties when sending.) Abort: The action the application takes on a Connection to <del> indicate a Close and also indicate that the Transport System SHOULD NOT attempt to deliver any outstanding data.  This is intended for immediate termination of a connection, without </del> <ins> indicate a Close and also indicate that the Transport Services system SHOULD NOT attempt to deliver any outstanding data.  This is intended for immediate termination of a connection, without </ins> cleaning up state. 4.2.


protocols are not incorrectly swapped, Transport Services systems SHOULD only automatically generate equivalent Protocol Stacks when the transport security protocols within the stacks are identical. <del> Specifically, a Transport System would consider protocols </del> <ins> Specifically, a Transport Services system would consider protocols </ins> identical only if they are of the same type and version.  For example, the same version of TLS running over two different transport Protocol Stacks are considered equivalent, whereas TLS


protocol state, cached path state, and heuristics, may be shared (e.g. across multiple connections in an application).  This provides efficiency and convenience for the application, since the Transport <del> System implementation can automatically optimize behavior. </del> <ins> Services implementation can automatically optimize behavior. </ins> There are several reasons, however, that an application might want to explicitly isolate some Connections.  These reasons include:


than -1, it sets the minimum protection in protocols that allow limiting the checksum length (e.g.  UDP-Lite). <del> Singular Transmission: when this is true, the application requests to avoid transport-layer segmentation or network-layer fragmentation.  Some transports implement network-layer fragmentation avoidance (Path MTU Discovery) without exposing this functionality to the application; in this case, only transport- layer segmentation should be avoided, by fitting the message into a single transport-layer segment or otherwise failing.  Otherwise, network-layer fragmentation should be avoided--e.g. by requesting the IP Don't Fragment bit to be set in case of UDP(-Lite) and IPv4 (SET_DF in RFC8304). </del> <ins> Singular Transmission: When set, this property limits the message size to the Maximum Message Size Before Fragmentation or Segmentation (see Section 10.1.7 of I-D.ietf-taps-interface). Messages larger than this size generate an error.  Setting this avoids transport-layer segmentation or network-layer fragmentation.  When used with transports running over IP version 4 the Don't Fragment bit will be set to avoid on-path IP fragmentation (RFC8304). </ins> 5.1.2.


actions are alternatives (e.g., whether to initiate a connection or to listen for incoming connections), while others are optional (e.g., setting Connection and Message Properties in Pre-Establishment) or <del> have been omitted for brevity. </del> <ins> have been omitted for brevity and simplicity. </ins> 4.1.1.


10.2. <del> These properties specifies configurations for the User Timeout Option </del> <ins> These properties specify configurations for the User Timeout Option </ins> (UTO), in case TCP becomes the chosen transport protocol. Implementation is optional and of course only sensible if TCP is implemented in the transport system. <del> All of the below parameters are optional (e.g., it is possible to </del> <ins> These TCP-specific properties are included here because the feature "Suggest timeout to the peer" is part of the minimal set of transport services I-D.ietf-taps-minset, where this feature was categorized as "functional".  This means that when an implementation offers this feature, it has to expose an interface to it to the application. Otherwise, the implementation might violate assumptions by the application, which could cause the application to fail. All of the below properties are optional (e.g., it is possible to </ins> specify "User Timeout Enabled" as true, but not specify an Advertised User Timeout value; in this case, the TCP default will be used).


Integer <del> Default: :the TCP default </del> <ins> the TCP default </ins> This time value is advertised via the TCP User Timeout Option (UTO) RFC5482 at the remote endpoint to adapt its own "Timeout for aborting


All data sent with the same MessageContext object will be treated as belonging to the same Message, and will constitute an in-order series <del> until the endOfMessage is marked.  Once the end of the Message is marked, the MessageContext object may be re-used as a new Message with identical parameters. </del> <ins> until the endOfMessage is marked. </ins> 7.7.


Abstract <del> This document describes an abstract programming interface, API, to the transport layer, following the Transport Services Architecture. It supports the asynchronous, atomic transmission of messages over transport protocols and network paths dynamically selected at runtime.  It is intended to replace the traditional BSD sockets API as the common interface to the transport layer, in an environment where endpoints could select from multiple interfaces and potential transport protocols. </del> <ins> This document describes an abstract application programming interface, API, to the transport layer, following the Transport Services Architecture.  It supports the asynchronous, atomic transmission of messages over transport protocols and network paths dynamically selected at runtime.  It is intended to replace the traditional BSD sockets API as the common interface to the transport layer, in an environment where endpoints could select from multiple interfaces and potential transport protocols. </ins> 1.


5.1.1. Lifetime: this should be implemented by removing the Message from <del> its queue of pending Messages after the Lifetime has expired.  A </del> <ins> the queue of pending Messages after the Lifetime has expired.  A </ins> queue of pending Messages within the transport system implementation that have yet to be handed to the Protocol Stack can always support this property, but once a Message has been sent into the send buffer of a protocol, only certain protocols may <del> support de-queueing a message.  For example, TCP cannot remove bytes from its send buffer, while in case of SCTP, such control over the SCTP send buffer can be exercised using the partial reliability extension RFC8303.  When there is no standing queue of Messages within the system, and the Protocol Stack does not support removing a Message from its buffer, this property may be ignored. </del> <ins> support removing a message.  For example, an implementation cannot cannot remove bytes from a TCP send buffer, while it can remove data from a SCTP send buffer using the partial reliability extension RFC8303.  When there is no standing queue of Messages within the system, and the Protocol Stack does not support the removal of a Message from the stack's send buffer, this property may be ignored. </ins> Priority: this represents the ability to prioritize a Message over other Messages.  This can be implemented by the system re-ordering


could choose to send Messages of different Priority on streams of different priority. <del> Ordered: when this is false, it disables the requirement of in- </del> <ins> Ordered: when this is false, this disables the requirement of in- </ins> order-delivery for protocols that support configurable ordering. <del> Safely Replayable: when this is true, it means that the Message </del> <ins> Safely Replayable: when this is true, this means that the Message </ins> can be used by mechanisms that might transfer it multiple times - e.g., as a result of racing multiple transports or as part of TCP Fast Open. <del> Final: when this is true, it means that a transport connection can be closed immediately after its transmission. </del> <ins> Final: when this is true, this means that a transport connection can be closed immediately after transmission of the message. </ins> Corruption Protection Length: when this is set to any value other than -1, it sets the minimum protection in protocols that allow


boundaries to function, each application layer protocol has defined its own framing. <ins> To use a Message Framer, the application adds it to its Preconnection object.  Then, the Message Framer can intercept all calls to Send() or Receive() on a Connection to add Message semantics, in addition to interacting with the setup and teardown of the Connection.  A Framer can start sending data before the application sends data if the framing protocol requires a prefix or handshake (see RFC8229 for an example of such a framing protocol). </ins> Note that while Message Framers add the most value when placed above a protocol that otherwise does not preserve message boundaries, they can also be used with datagram- or message-based protocols.  In these


Enumeration: can take one value of a finite set of values, dependent on the property itself.  The representation is <del> implementation dependent; however, implementations MUST provide a method for the application to determine the entire set of possible values for each property. </del> <ins> implementation dependent. </ins> Preference: can take one of five values (Prohibit, Avoid, Ignore, Prefer, Require) for the level of preference of a given property


7.1.10. <ins> isolateSession Boolean false When set to true, this property will initiate new Connections using as little cached information (such as session tickets or cookies) as possible from previous connections that are not entangled with it. Any state generated by this Connection will only be shared with entangled connections.  Cloned Connections will use saved state from within the Connection Group. Note that this does not guarantee no leakage of information, as implementations may not be able to fully isolate all caches (e.g. RTT estimates).  Note that this property may degrade connection performance. 7.1.11. </ins> The following generic Connection Properties are read-only, i.e. they cannot be changed by an application. <del> 7.1.10.1. </del> <ins> 7.1.11.1. </ins> zeroRttMsgMaxLen


before or during Connection establishment, see also msg- safelyreplayable.  It is given in Bytes. <del> 7.1.10.2. </del> <ins> 7.1.11.2. </ins> singularTransmissionMsgMaxLen


Packet Size (MPS) as described in Datagram PLPMTUD I-D.ietf-tsvwg- datagram-plpmtud. <del> 7.1.10.3. </del> <ins> 7.1.11.3. </ins> sendMsgMaxLen


This property represents the maximum Message size that an application can send. <del> 7.1.10.4. </del> <ins> 7.1.11.4. </ins> recvMsgMaxLen


Handover This property specifies the local policy for transferring data across <del> multiple paths between the same end hosts if Parallel Use of Multiple Paths is not set to Disabled (see multipath-mode).  Possible values are: </del> <ins> multiple paths between the same end hosts if Multipath Transport is not set to Disabled (see multipath-mode).  Possible values are: </ins> The connection ought only to attempt to migrate between different paths when the original path is lost or becomes unusable.  The


When a path change occurs, e.g., when the IP address of an interface changes or a new interface becomes available, the Transport Services <del> implementation is responsible for notifying the application of the change.  The path change may interrupt connectivity on a path for an active connection or provide an opportunity for a transport that supports multipath or migration to adapt to the new paths. </del> <ins> implementation is responsible for notifying the Protocol Instance of the change.  The path change may interrupt connectivity on a path for an active connection or provide an opportunity for a transport that supports multipath or migration to adapt to the new paths.  Note that, from the Transport Services API point of view, migration is considered a part of multipath connectivity; it is just a limiting policy on multipath usage.  If the "multipath" Selection Property is set to "Disabled", migration is disallowed. </ins> For protocols that do not support multipath or migration, the Protocol Instances should be informed of the path change, but should


implementation should not aggressively close connections in these scenarios. <del> If the Protocol Stack includes a transport protocol that also supports multipath connectivity with migration support, the Transport Services implementation should also inform the Protocol Instance of potentially new paths that become permissible based on the Selection Properties passed by the application.  A protocol can then establish new subflows over new paths while an active path is still available or, if migration is supported, also after a break has been detected, and should attempt to tear down subflows over paths that are no longer used.  The Transport Services API provides an interface to set a multipath policy that indicates when and how different paths should </del> <ins> If the Protocol Stack includes a transport protocol that supports multipath connectivity, the Transport Services implementation should also inform the Protocol Instance of potentially new paths that become permissible based on the "multipath" Selection Property and the "multipath-policy" Connection Property choices made by the application.  A protocol can then establish new subflows over new paths while an active path is still available or, if migration is supported, also after a break has been detected, and should attempt to tear down subflows over paths that are no longer used.  The Transport Services API's Connection Property "multipath-policy" allows an application to indicate when and how different paths should </ins> be used.  However, detailed handling of these policies is still <del> implementation-specific.  The decision about when to create a new </del> <ins> implementation-specific.  For example, if the "multipath" Selection Property is set to "active", the decision about when to create a new </ins> path or to announce a new path or set of paths to the remote endpoint, e.g., in the form of additional IP addresses, is <del> implementation-specific or could be be supported by future API extensions.  If the Protocol Stack includes a transport protocol that does not support multipath, but does support migrating between paths, the update to the set of available paths can trigger the connection to be migrated. In case of Pooled Connections pooled-connections, the transport system may add connections over new paths or different protocols to the pool if permissible based on the multipath policy and Selection </del> <ins> implementation-specific.  If the Protocol Stack includes a transport protocol that does not support multipath, but does support migrating between paths, the update to the set of available paths can trigger the connection to be migrated. In case of Pooled Connections pooled-connections, the Transport Services implementation may add connections over new paths to the pool if permissible based on the multipath policy and Selection </ins> Properties.  In case a previously used path becomes unavailable, the transport system may disconnect all connections that require this path, but should not disconnect the pooled connection object exposed


(e.g.  I-D.ietf-httpbis-priority. A Transport Services system gives no guarantees about how its <del> expression of relative priorities will be realized; for example, if a transport stack that only provides a single in-order reliable stream is selected, prioritization information can only be ignored. However, the Transport Services system will seek to ensure that performance of relatively-prioritized connections and messages is not worse with respect to those connections and messages than an equivalent configuration in which all prioritization properties are left at their defaults. </del> <ins> expression of relative priorities will be realized.  However, the Transport Services system will seek to ensure that performance of relatively-prioritized connections and messages is not worse with respect to those connections and messages than an equivalent configuration in which all prioritization properties are left at their defaults. </ins> The Transport Services interface does order Connection Priority over the Priority Message Property.  In the absense of other externalities


Preference <del> Prefer </del> <ins> Ignore </ins> This property specifies whether the application needs or prefers to use a transport protocol that preserves message boundaries.


applications written to a single API to make use of transport protocols in terms of the features they provide. <del> A unified interface to datagram and connection-oriented transports, allowing use of a common API for connection- establishment and closing. </del> <ins> A unified interface to datagram and stream-oriented transports, allowing use of a common API for connection establishment and closing. </ins> Message-orientation, as opposed to stream-orientation, using application-assisted framing and deframing where the underlying


and/or received from a Remote Endpoint (i.e., a logical connection that, depending on the kind of transport, can be bi-directional or unidirectional, and that can use a stream protocol or a datagram <del> protocol).  Connections can be created from Preconnections in three ways: by initiating the Preconnection (i.e., actively opening, as in a client; initiate), through listening on the Preconnection (i.e., passively opening, as in a server listen), or rendezvousing on the Preconnection (i.e., peer to peer establishment; rendezvous). </del> <ins> protocol).  Connections are presented consistently to the application, irrespective of whether the underlying transport is connection-less or connection-oriented.  Connections can be created from Preconnections in three ways: by initiating the Preconnection (i.e., actively opening, as in a client; initiate), through listening on the Preconnection (i.e., passively opening, as in a server listen), or rendezvousing on the Preconnection (i.e., peer to peer establishment; rendezvous). </ins> Once a Connection is established, data can be sent and received on it in the form of Messages.  The interface supports the preservation of


The messageData object provides access to the bytes that were received for this Message, along with the length of the byte array. The messageContext is provided to enable retrieving metadata about <del> the message and referring to the message, e.g., to send replies and map responses to their requests.  See msg-ctx for details. </del> <ins> the message and referring to the message.  The messageContext object ist described in msg-ctx. </ins> See framing for handling Message framing in situations where the Protocol Stack only provides a byte-stream transport.


is Any-source Multicast, and the path selection is based on the outbound route to the group supplied in the Local Endpoint. <ins> There are cases where it is required to open multiple connections for the same address(es).  For example, one Connection might be opened for a multicast group to for a multicast control bus, and another application later opens a separate Connection to the same group to send signals to and/or receive signals from the common bus.  In such cases, the interface needs to explicitly enable re-use of the same set of addresses (equivalent to setting SO_REUSEADDR in the socket API). </ins> UDP Multicast Receive Listeners will deliver new connections once they have received traffic from a new Remote Endpoint.


3. <del> The Transport Services API is the basic common abstract application programming interface to the Transport Services Architecture defined in the TAPS Architecture I-D.ietf-taps-arch. </del> An application primarily interacts with this API through two Objects: Preconnections and Connections.  A Preconnection object (pre- establishment) represents a set of properties and constraints on the


Preconnections are reusable after being used to initiate a Connection.  Hence, for example, after the Connections were closed, <del> the following would be correct: ~~~ //.. carry out adjustments to the Preconnection, if desire Connection := Preconnection.Initiate() ~~~ </del> <ins> the following would be correct: </ins> 3.1.3.


4. Each application using the Transport Services Interface declares its <del> preferences for how the transport service should operate using properties at each stage of the lifetime of a connection using Transport Properties, as defined in I-D.ietf-taps-arch. </del> <ins> preferences for how the transport service should operate.  This is done by using Transport Properties, as defined in I-D.ietf-taps-arch, at each stage of the lifetime of a connection. </ins> Transport Properties are divided into Selection, Connection, and Message Properties.  Selection Properties (see selection-props) can


Namespaces for each of the keywords provided in the IANA protocol numbers registry (see https://www.iana.org/assignments/protocol- <del> numbers/protocol-numbers.xhtml), reformatted where necessary to conform to an implementation's naming conventions, are reserved for Protocol Specific Properties and MUST NOT be used for vendor or implementation-specific properties. </del> <ins> numbers/protocol-numbers.xhtml) are reserved for Protocol Specific Properties and MUST NOT be used for vendor or implementation-specific properties.  Avoid using any of the terms listed as keywords in the protocol numbers registry as any part of a vendor- or implementation- specific property name. </ins> 4.2.


If more than one Remote Endpoint is specified on the Preconnection, then all the Remote Endpoints on the Preconnection SHOULD represent <del> the same host.  For example, the Remote Endpoints might represent </del> <ins> the same service.  For example, the Remote Endpoints might represent </ins> various network interfaces of a host, or a server reflexive address that can be used to reach a host, or a set of hosts that provide equivalent local balanced service.


Full Coverage This property specifies the minimum number of bytes in a received <del> message that need to be covered by a checksum.  A special value of 0 means that a received packet does not need to have a non-zero checksum field.  A receiving endpoint will not forward messages that have less coverage to the application.  The application is responsible for handling any corruption within the non-protected part of the message RFC8085. </del> <ins> message that need to be covered by a checksum.  A receiving endpoint will not forward messages that have less coverage to the application. The application is responsible for handling any corruption within the non-protected part of the message RFC8085.  A special value of 0 means that a received packet may also have a zero checksum field. </ins> 8.1.2.


to a single address over a single interface.  They also present a single stream to the application.  Software layers built upon sockets often propagate this limitation of a single-address single-stream <del> model.  The Transport Services architecture is designed to handle multiple candidate endpoints, protocols, and paths; and support multipath and multistreaming protocols. </del> <ins> model.  The Transport Services architecture is designed: to handle multiple candidate endpoints, protocols, and paths; to support candidate protocol racing to select the most optimal stack in each situation; to support multipath and multistreaming protocols; to provide state caching and application control over it. </ins> Transport Services implementations are meant to be flexible at connection establishment time, considering many different options and <del> trying to select the most optimal combinations (gathering and racing).  This requires applications to provide higher-level endpoints than IP addresses, such as hostnames and URLs, which are used by a Transport Services implementation for resolution, path selection, and racing.  Transport services implementations can further implement fallback mechanisms if connection establishment of one protocol fails or performance is detected to be unsatisfactory. </del> <ins> trying to select the most optimal combinations by racing them and measuring the results (see gathering and racing).  This requires applications to provide higher-level endpoints than IP addresses, such as hostnames and URLs, which are used by a Transport Services implementation for resolution, path selection, and racing.  Transport Services implementations can further implement fallback mechanisms if connection establishment of one protocol fails or performance is detected to be unsatisfactory. Information used in connection establishment (e.g. cryptographic resumption tokens, information about usability of certain protocols on the path, results of racing in previous connections) are cached in the transport services implementation.  Applications have control over whether this information is used for a specific establishment, in order to allow tradeoffs between efficiency and linkability. </ins> Flexibility after connection establishment is also important. Transport protocols that can migrate between multiple network-layer


system can race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. <ins> Whether information from previous racing attempts, or other information cached by the Transport Services implementation about past communications, is used during establishment is under application control.  This allows applications to make tradeoffs between efficiency (through racing) and privacy (via information that might leak from the cache toward an on-path observer).  Some applications have native concepts (e.g. "incognito mode") that align with this functionality. </ins> Applications need to ensure that they use security APIs appropriately.  In cases where applications use an interface to provide sensitive keying material, e.g., access to private keys or


application. In general, any protocol or path used for a connection must conform <del> to all three sources of constraints.  A violation of any of the layers should cause a protocol or path to be considered ineligible for use.  For an example of application preferences leading to constraints, an application may prohibit the use of metered network interfaces for a given Connection to avoid user cost.  Similarly, the system policy at a given time may prohibit the use of such a metered network interface from the application's process.  Lastly, the implementation itself may default to disallowing certain network interfaces unless explicitly requested by the application and allowed by the system. </del> <ins> to all three sources of constraints.  A violation that occurs at any of the policy layers should cause a protocol or path to be considered ineligible for use.  For an example of application preferences leading to constraints, an application may prohibit the use of metered network interfaces for a given Connection to avoid user cost. Similarly, the system policy at a given time may prohibit the use of such a metered network interface from the application's process. Lastly, the implementation itself may default to disallowing certain network interfaces unless explicitly requested by the application and allowed by the system. </ins> It is expected that the database of system policies and the method of looking up these policies will vary across various platforms.  An


certificate directly instead of relying on a referential mechanism such as communicating only a hash and/or URL for the certificate. <del> Any security association protocol MUST use PFS (such as profiles providing PFS). </del> <ins> Any security association protocol MUST provide Forward Secrecy (whether inherently or as part of a profile of the security association protocol). </ins> The degree of security required on every hop of an ACP network needs to be consistent across the network so that there is no designated


6.7.1. <del> An ACP node announces its ability to support IKEv2 as the ACP secure channel protocol in GRASP as "IKEv2". </del> <ins> An ACP node announces its ability to support IPsec, negotiated via IKEv2, as the ACP secure channel protocol in GRASP as the "IKEv2" method for the "AN_ACP" objective. </ins> 6.7.1.1. To run ACP via IPsec natively, no further IANA assignments/ definitions are required. <del> An ACP node that is supporting native IPsec MUST use IPsec security setup via IKEv2 for tunnel mode and IPsec/IKE signaling accordingly for IPv6 payload (e.g.: ESP next header of 41).  It MUST use local and peer link-local IPv6 addresses for encapsulation. Authentication MUST use the ACP domain certificates.  Certificate Encoding MUST support "PKCS #7 wrapped X.509 certificate" (0) (see IKEV2IANA for this and other IANA IKEv2 parameter names used in this text).  If certificate chains are used, all intermediate certificates up to, but not including the locally provisioned trust anchor certificate must be signaled. </del> <ins> The ACP usage of IPsec and IKEv2 mandates a narrow profile of the current standards-track usage guidance for IPsec RFC8221 and IKEv2 RFC8247.  This profile provides for stringent security properties and can exclude deprecated/legacy algorithms because there is no need for interoperability with legacy equipment for ACP channels.  Any such backward compatibility would lead only to increased attack surface and implementation complexity, for no benefit. An ACP node that is supporting native IPsec MUST use IPsec in tunnel mode, negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next Header of 41).  It MUST use local and peer link-local IPv6 addresses for encapsulation.  Manual keying MUST NOT be used (independent of the security weaknesses of manual keying, it is incompatible with an autonomic platform). </ins> IPsec tunnel mode is required because the ACP will route/forward packets received from any other ACP node across the ACP secure


transport mode, it would only be possible to send packets originated by the ACP node itself. <del> IKEv2 authentication MUST use authentication method=1 ("RSA Digital Signature") for ACP certificates with RSA key and methods 9,10,11 for ACP certificates with ECC key according to the keys size/curve. A certificate payload with the ACP certificate MUST be included during IKEv2 authentication to support the ACP domain membership as described in certcheck, because it is using additional elements of the ACP certificates.  ACP peers are expected to have the same set of Trust Anchors (TA), so a certificate path MUST only be included in the signaled payload when the path contains intermediate certificates not in the TA set, such as sub-CAs (see acp-registrars). IPsec MUST support ESP with ENCR_AES_GCM_16 (RFC4106) due to its higher performance over ENCR_AES_CBC.  ACP MUST NOT use any NULL encryption option due to the confidentiality of ACP payload that may not be encrypted by itself (when carrying legacy management protocol traffics as well as hop-by-hop GRASP).  These requirements are based on RFC8221 but limited to the minimum necessary options because there is no need for interoperability with legacy equipment for ACP channels, instead any such backward compatibility would reduce the minimum security or performance required for ACP channels or increase the implementation complexity of the ACP. </del> <ins> ACP IPsec implementations MUST support ESP with ENCR_AES_GCM_16 (RFC4106) due to its higher performance over ENCR_AES_CBC.  ACP MUST NOT use any NULL encryption option due to the confidentiality of ACP payload that may not be encrypted by itself (when carrying legacy management protocol traffics as well as hop-by-hop GRASP).  When using AES encryption, 256-bit keys MUST be used.  AES-GCM is an AEAD cipher mode, so no ESP authentication algorithm requirement is needed. </ins> Once there are updates to RFC8221, these should accordingly be reflected in updates to these ACP requirements, for example if


long as they do not result in a reduction of security over the above MTI requirements.  For example, ESP compression MAY be used. <del> IKEv2 MUST follow RFC8247 as necessary to support the above listed IPsec requirements. </del> <ins> As for ESP (above), for IKEv2, the ENCR_AES_GCM_16 encryption algorithm (with 256-bit keys) MUST be supported.  The IKEv2 PRF_HMAC_SHA2_512 pseudorandom function MUST be supported. IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP) MUST be supported (in addition to 2048-bit MODP).  ECC provides a similar security level to finite-field (MODP) key exchange with a shorter key length, so is generally preferred absent other considerations. IKEv2 authentication MUST use the ACP domain certificates.  The Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be supported (see IKEV2IANA for this and other IANA IKEv2 parameter names used in this text).  If certificate chains are used, all intermediate certificates up to, but not including the locally provisioned trust anchor certificate must be signaled. A certificate payload with the ACP certificate MUST be included during IKEv2 authentication to support the ACP domain membership check as described in certcheck, because it is using additional elements of the ACP certificates.  ACP peers are expected to have the same set of Trust Anchors (TA), so a certificate path MUST only be included in the signaled payload when the path contains intermediate certificates not in the TA set, such as sub-CAs (see acp-registrars). ACP nodes are identified by their ACP address, so the ID_IPv6_ADDR IKEv2 identification payload MUST be used and MUST convey the ACP address.  If the peer's ACP domain certificate includes an ACP address in the domain information, the address in the identification payload must match the address in the certificate (allowing for the presence of virtualization bits in the ACP addressing scheme used). IKEv2 authentication MUST use authentication method 14 ("Digital Signature") for ACP certificates; this authentication method can be used with both RSA and ECDSA certificates, as indicated by a PKIX- style OID. The Digital Signature hash SHA2-512 MUST be supported (in addition to SHA2-256). Once there are updates to RFC8247, these should accordingly be reflected in updates to these ACP requirements, for example if ENCR_AES_GCM_16 was to be superceeded in the future or the key- exchange group recommendations are changed. Additional requirements from RFC8247 MAY be used for ACP channels as long as they do not result in a reduction of security over the above MTI requirements. </ins> 6.7.1.2.


the first transport encryption supported in some classes of constrained devices. <ins> An ACP node announces its ability to support DTLS as the ACP secure channel protocol in GRASP as the "DTLS" method for the "AN_ACP" objective. </ins> To run ACP via UDP and DTLS v1.2 RFC6347 a locally assigned UDP port is used that is announced as a parameter in the GRASP AN_ACP objective to candidate neighbors.


Abstract <del> This document defines a YANG RPC and a minimal datastore tree required to retrieve attestation evidence about integrity measurements from a composite device with one or more roots of trust for reporting.  Complementary measurement logs are also provided by the YANG RPC originating from one or more roots of trust of measurement.  The module defined requires at least one TPM 1.2 or TPM 2.0 and corresponding Trusted Software Stack included in the device components of the composite device the YANG server is running on. </del> <ins> This document defines a YANG RPC and a minimal datastore required to retrieve attestation evidence about integrity measurements from a device following the operational context defined in I-D.ietf-rats- tpm-based-network-device-attest.  Complementary measurement logs are also provided by the YANG RPC originating from one or more roots of trust of measurement.  The module defined requires at least one TPM 1.2 or TPM 2.0 and corresponding Trusted Software Stack included in the device components of the composite device the YANG server is running on. </ins> 1. This document is based on the terminology defined in the I-D.ietf- <del> rats-architecture and uses the interaction model and information elements defined in the I-D.birkholz-rats-reference-interaction-model document.  The currently supported hardware security modules (HWM) - sometimes also referred to as an embedded secure element (eSE) - is the Trusted Platform Module (TPM) version 1.2 and 2.0 specified by the Trusted Computing Group (TCG).  One ore more TPMs embedded in the components of a composite device - sometimes also referred to as an aggregate device - are required in order to use the YANG module defined in this document.  A TPM is used as a root of trust for reporting (RTR) in order to retrieve attestation evidence from a composite device (quote primitive operation).  Additionally, it is used as a root of trust for storage (RTS) in order to retain shielded secrets and store system measurements using a folding hash function (extend primitive operation). </del> <ins> rats-architecture and uses the operational context defined in I- D.ietf-rats-tpm-based-network-device-attest as well as the interaction model and information elements defined in I-D.birkholz- rats-reference-interaction-model.  The currently supported hardware security modules (HWM) are the Trusted Platform Module (TPM) TPM1.2 and TPM2.0 specified by the Trusted Computing Group (TCG).  One ore more TPMs embedded in the components of a composite device - sometimes also referred to as an aggregate device - are required in order to use the YANG module defined in this document.  A TPM is used as a root of trust for reporting (RTR) in order to retrieve attestation evidence from a composite device (quote primitive operation).  Additionally, it is used as a root of trust for storage (RTS) in order to retain shielded secrets and store system measurements using a folding hash function (extend primitive operation). </ins> 1.1.


2.2.1. This YANG module imports modules from RFC6991, RFC8348, I-D.ietf- <del> netconf-crypto-types, ietf-asymmetric-algs.yang. </del> <ins> netconf-keystore, ietf-tcg-algs.yang. </ins> <del> 2.3. </del> <ins> 2.2.1.1. This module supports the following types of attestation event logs: <ima>, <bios>, and <netequip_boot>. 2.2.1.2. <tpm12-challenge-response-attestation> - Allows a Verifier to request a quote of PCRs from a TPM1.2 compliant cryptoprocessor.  When one or more <certificate-name> is not provided, all TPM1.2 compliant cryptoprocessors will respond. <tpm20-challenge-response-attestation> - Allows a Verifier to request a quote of PCRs from a TPM2.0 compliant cryptoprocessor.  When one or more <certificate-name> is not provided, all TPM2.0 compliant cryptoprocessors will respond. <log-retrieval> - Allows a Verifier to acquire the evidence which was extended into specific PCRs. 2.2.1.3. container <rats-support-structures> - This exists when there are more than one TPM for a particular Attester.  This allows each specific TPM to identify on which <compute-node> it belongs. container <tpms> - Provides configuration and operational details for each supported TPM, including the tpm-firmware-version, PCRs which may be quoted, certificates which are associated with that TPM, and the current operational status.  Of note is the certificates which are associated with that TPM.  As a certificate is associated with a single Attestation key, knowledge of the certificate allows a specific TPM to be identified. container <attester-supported-algos> - Identifies which TCG algorithms are available for use the Attesting platform.  This allows an operator to limit algorithms available for use by RPCs to just a desired set from the universe of all allowed by TCG. 2.2.1.4. 2.2.2. </ins> Cryptographic algorithm types were initially included within -v14 NETCONF's iana-crypto-types.yang.  Unfortunately all this content including the algorithms needed here failed to make the -v15 used <del> WGLC.  Therefore a modified version of this draft is included here. Perhaps someone will steward this list as a separate draft. </del> <ins> WGLC.  As a result this document has encoded the TCG Algorithm definitions of TCG-Algos, revision 1.32.  By including this full table as a separate YANG file within this document, it is possible for other YANG models to leverage the contents of this model. 2.2.2.1. There are two types of features supported <TPM12> and <TPM20>. Support for either of these features indicates that a cryptoprocessor supporting the corresponding type of TCG API is present on an Attester.  Most commonly, only one type of cryptoprocessor will be available on an Attester. 2.2.2.2. There are three types of identities in this model. The first are the cryptographic functions supportable by a TPM algorithm, these include: <asymmetric>, <symmetric>, <hash>, <signing>, <anonymous_signing>, <encryption_mode>, <method>, and <object_type>.  The definitions of each of these are in Table 2 of TCG-Algos. The second are API specifications for tpms: <tpm12> and <tpm2>. The third are specific algorithm types.  Each algorithm type defines what cryptographic functions may be supported, and on which type of API specification.  It is not required that an implementation of a specific TPM will support all algorithm types.  The contents of each specific algorithm mirrors what is in Table 3 of TCG-Algos. 2.2.2.3. Note that not all cryptographic functions are required for use by ietf-tpm-remote-attestation.yang.  However the full definition of Table 3 of TCG-Algos will allow use by additional YANG specifications. </ins> 3. This document will include requests to IANA: <del> To be defined yet. </del> <ins> To be defined yet.  But keeping up with changes to ietf-tcg-algs.yang will be necessary. </ins> 4. <del> There are always some. </del> <ins> The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF RFC6241 or RESTCONF RFC8040.  The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) RFC6242.  The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS RFC5246. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default).  These data nodes may be considered sensitive or vulnerable in some network environments.  Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations.  These are the subtrees and data nodes and their sensitivity/vulnerability: Container: </rats-support-structures/attester-supported-algos> <tpm12-asymmetric-signing>, <tpm12-hash>, <tpm20-asymmetric- signing>, and <tpm20-hash> all could be populated with algorithms which are not supported by the underlying physical TPM installed by the equipment vendor. Container: </rats-support-structures/tpms> <tpm-name> - Although shown as 'rw', it is system generated <tpm20-pcr-bank> - It is possible to configure PCRs for extraction which are not being extended by system software.  This could unnecessarily use TPM resources. <certificates> - It is possible to provision a certificate which does not correspond to a Attestation Identity Key (AIK) within the TPM. RPC: <tpm12-challenge-response-attestation> - Need to verify that the certificate is for an active AIK. RPC: <tpm20-challenge-response-attestation> - Need to verify that the certificate is for an active AIK. RPC: <log-retrieval> - Pulling lots of logs can chew up system resources. </ins> 5. <ins> Changes from version 02 to version 03: moved to tcg-algs cleaned up model to eliminate sources of errors removed key establishment RPC added lots of XPATH which must all be scrubbed still Descriptive text added on model contents. </ins> Changes from version 01 to version 02: Extracted Crypto-types into a separate YANG file


1. Bootstrapping Remote Secure Key Infrastructures BRSKI specifies <del> automated bootstrapping of an Autonomic Control Plane.  BRSKI Section 2.7 describes how a pledge "MAY contact a well-known URI of a cloud registrar if a local registrar cannot be discovered or if the pledge's target use cases do not include a local registrar". </del> <ins> automated network onboarding of devices, referred to as pledges, within an Autonomic Control Plane or other managed network infrastructure.  BRSKI Section 2.7 describes how a pledge "MAY contact a well-known URI of a cloud registrar if a local registrar cannot be discovered or if the pledge's target use cases do not include a local registrar". </ins> This document further specifies use of a BRSKI cloud registrar and clarifies operations that are not sufficiently specified in BRSKI.


logically separate entities.  The two functions could of course be integrated into a single service. <del> TWO CHOICES: 1.  Cloud Registrar redirects to Owner Registrar 2. Cloud Registrar returns VOUCHER pinning Owner Register. </del> <ins> There are two different mechanisms for a cloud registrar to handle voucher requests: 1. the Cloud Registrar redirects the request to Owner Registrar for handling 2. the Cloud Registrar returns a voucher pinning the Owner Register and includes additional bootstrapping information embedded in the voucher Both mechanisms are described in detail later in this document. </ins> 2.1.


<del> CAPPORT Architecture </del> <ins> Captive Portal Architecture </ins> draft-ietf-capport-architecture-08 Abstract <del> This document describes a CAPPORT architecture.  DHCP or Router Advertisements, an optional signaling protocol, and an HTTP API are used to provide the solution.  The role of Provisioning Domains (PvDs) is described. </del> <ins> This document describes a captive portal architecture.  DHCP or Router Advertisements, an optional signaling protocol, and an HTTP API are used to provide the solution.  The role of Provisioning Domains (PvDs) is described. </ins> 1.


2.2.1. A standard for providing a portal URI using DHCP or Router <del> Advertisements is described in RFC7710bis.  The CAPPORT architecture expects this URI to indicate the API described in section_api. </del> <ins> Advertisements is described in RFC7710bis.  The captive portal architecture expects this URI to indicate the API described in section_api. </ins> 2.2.2.


A side-benefit of the architecture described in this document is that devices without user interfaces are able to identify parameters of <del> captivity.  However, this document does not yet describe a mechanism for such devices to escape captivity. </del> <ins> captivity.  However, this document does not describe a mechanism for such devices to negotiate for unrestricted network access.  A future document could provide a solution to devices without user interfaces. This document focuses on devices with user interfaces. </ins> The architecture uses the following mechanisms:


section_capport_enforcement, until site-specific requirements have been met. <del> At this time we consider only devices with web browsers, with web </del> <ins> This document only considers devices with web browsers, with web </ins> applications being the means of satisfying Captive Portal Conditions. <del> An example interactive User Equipment is a smart phone. </del> <ins> An example of such User Equipment is a smart phone. </ins> The User Equipment:


A Captive Portal API needs to present information to clients that is unique to that client.  To do this, some systems use information from the context of a request, such as the source address, to identify the <del> UE. </del> <ins> User Equipment. </ins> Using information from context rather than information from the URI allows the same URI to be used for different clients.  However, it also means that the resource is unable to provide relevant <del> information if the UE makes a request using a different network path. This might happen when UE has multiple network interfaces.  It might also happen if the address of the API provided by DNS depends on where the query originates (as in split DNS RFC8499). </del> <ins> information if the User Equipment makes a request using a different network path.  This might happen when User Equipment has multiple network interfaces.  It might also happen if the address of the API provided by DNS depends on where the query originates (as in split DNS RFC8499). </ins> Accessing the API MAY depend on contextual information.  However, the <del> URIs provided in the API SHOULD be unique to the UE and not dependent on contextual information to function correctly. Though a URI might still correctly resolve when the UE makes the request from a different network, it is possible that some functions could be limited to when the UE makes requests using the captive network.  For example, payment options could be absent or a warning could be displayed to indicate the payment is not for the current connection. </del> <ins> URIs provided in the API SHOULD be unique to the User Equipment and not dependent on contextual information to function correctly. Though a URI might still correctly resolve when the User Equipment makes the request from a different network, it is possible that some functions could be limited to when the User Equipment makes requests using the captive network.  For example, payment options could be absent or a warning could be displayed to indicate the payment is not for the current connection. </ins> URIs could include some means of identifying the User Equipment in the URIs.  However, including unauthenticated User Equipment


Captive Portal Signaling Protocol: Also known as Signaling Protocol. The protocol for communicating Captive Portal Signals. <ins> Captive Portal Session: Also referred to simply as the "session", a Captive Portal Session is the association for a particular User Equipment that starts when it interacts with the Captive Portal and gains open access to the network, and ends when the User Equipment moves back into the original captive state.  The Captive Network maintains the state of each active Session, and can limit Sessions based on a length of time or a number of bytes used.  The Session is associated with a particular User Equipment using the User Equipment's identifier (see ue_identity). </ins> 2. 2.1.


Architecture RFC7556 provides some discussion on authenticating an operator. <del> Given that a user chooses to visit a Captive Portal URI, the URI location SHOULD be securely provided to the user's device.  E.g., the DHCPv6 AUTH option can sign this information. </del> <ins> The user makes an informed choice to visit and trust the Captive Portal URI.  Since the network provides Captive Portal URI to the user equipment, the network SHOULD do so securely so that the user's trust in the network can extend to their trust of the Captive Portal URI.  E.g., the DHCPv6 AUTH option can sign this information. </ins> If a user decides to incorrectly trust an attacking network, they might be convinced to visit an attacking web page and unwittingly


This document describes an architecture for implementing captive portals while addressing most of the problems arising for current captive portal mechanisms.  The architecture is guided by these <del> principles: </del> <ins> requirements: </ins> A side-benefit of the architecture described in this document is that devices without user interfaces are able to identify parameters of


The authors thank Benjamin Kaduk for providing the content related to TLS certificate validation of the API server. <ins> The authors thank Michael Richardson for providing wording requiring DNSSEC and TLS to operate without the user adding exceptions. </ins> The authors thank various individuals for their feedback on the mailing list and during the IETF98 hackathon: David Bird, Erik Kline, Alexis La Goulette, Alex Roscoe, Darshak Thakore, and Vincent van


The API MUST ensure the integrity of this information, as well as its confidentiality. <ins> An attacker with access to this information might be able to masquerade as a specific User Equipment when interacting with the API, which could then allow them to masquerade as that User Equipment when interacting with the User Portal.  This could give them the ability to determine whether the User Equipment has accessed the portal, or deny the User Equipment service by ending their session using mechanisms provided by the User Portal, or consume that User Equipment's quota.  An attacker with the ability to modify the information could deny service to the User Equipment, or cause them to appear as a different User Equipment. </ins> 7.4. If a Signaling Protocol is implemented, it may be possible for any


2.5. <del> User Equipment may send traffic to hosts blocked by the captive network prior to the Enforcement device granting it access.  The Enforcement Device rightly blocks or resets these requests.  However, in the absence of a signal from the Enforcement Device or interaction with the API server, the User Equipment can only guess at whether it is captive.  Consequently, allowing the Enforcement Device to explicitly signal to the User Equipment that the traffic is being blocked may improve the user's experience. An Enforcement Device may also want to notify the User Equipment of a pending expiry of its access to the external network, so providing the Enforcement Device the ability to preemptively signal may be desirable. A specific Captive Portal Signaling Protocol is out of scope for this document.  However, in order to ensure that future protocols fit into the architecture, requirements for a Captive Portal Signaling Protocol follow: The Captive Portal Signaling Protocol does not provide any means of indicating that the network prevents access to some destinations. The intent is to rely on the Captive Portal API and the web portal to which it points to communicate local network policies. The Captive Portal Enforcement function MAY send Captive Portal Signals when User Equipment that has not satisfied the Captive Portal Conditions attempts to send traffic to the network.  These signals MUST be rate-limited to a configurable rate. The signals MUST NOT be sent to the destinations/peers that the User Equipment is restricted from accessing.  The indications are only to be sent to the User Equipment. </del> <ins> When User Equipment first connects to a network, or when there are changes in status, the Enforcement Device could generate a signal toward the User Equipment.  This signal indicates that the User Equipment might need to contact the API Server to receive updated information.  For instance, this signal might be generated when the end of a session is imminent, or when network access was denied. An Enforcement Device MUST rate-limit any signal generated in response to these conditions.  See section_signal_risks for a discussion of risks related to a Captive Portal Signal. </ins> 2.6.


7.5. <del> The Signal could inform the User Equipment that it is being held captive.  There is no requirement that the User Equipment do something about this.  Devices MAY permit users to disable automatic reaction to captive-portal indications for privacy reasons.  However, there would be the trade-off that the user doesn't get notified when network access is restricted.  Hence, end-user devices MAY allow users to manually control captive portal interactions, possibly on the granularity of Provisioning Domains. </del> <ins> The Captive Portal Signal could inform the User Equipment that it is being held captive.  There is no requirement that the User Equipment do something about this.  Devices MAY permit users to disable automatic reaction to Captive Portal Signals indications for privacy reasons.  However, there would be the trade-off that the user doesn't get notified when network access is restricted.  Hence, end-user devices MAY allow users to manually control captive portal interactions, possibly on the granularity of Provisioning Domains. </ins>


information, expiry time, method of providing credentials, security token for validating ICMP messages. <del> This document does not specify the details of the API. </del> <ins> The API MUST use TLS for privacy and server authentication.  The implementation of the API MUST ensure both privacy and integrity of any information provided by or required by it. </ins> <del> The CAPPORT API MUST support TLS for privacy and server authentication. </del> <ins> This document does not specify the details of the API. </ins> 2.4.


5.2. The solution described here assumes that when the User Equipment <del> needs to trust the API server, server authentication will be utilized using TLS mechanisms. </del> <ins> needs to trust the API server, server authentication will be performed using TLS mechanisms. </ins> 5.3. <ins> The solution described here requires that the API be secured using TLS.  This is required to allow the user equipment and API server to exchange secrets which can be used to validate future interactions. The API must ensure the integrity of this information, as well as its confidentiality. 5.4. </ins> It is possible for any user on the Internet to send ICMP packets in an attempt to cause the receiving equipment to go to the captive portal.  This has been considered and addressed in the following


Even when redirected, the User Equipment securely authenticates with API servers. <del> 5.4. </del> <ins> 5.5. </ins> The ICMP messaging informs the User Equipment that it is being held captive.  There is no requirement that the User Equipment do


3. <ins> Multiple components in the architecture interact with both the User Equipment and each other.  Since the User Equipment is the focus of these interactions, the components must be able to both identify the user equipment from their interactions with it, and be able to agree on the identify of the user equipment when interacting with each other. The methods by which the components interact restrict the type of information that may be used as an identifying charactertics.  This section discusses the identifying charactersitics. 3.1. An Identifier is a chatacteristic of the User Equipment used by the components of a Captive Portal to uniquely determine which specific User Equipment is interacting with them.  An Identifier MAY be a field contained in packets sent by the User Equipment to the External Network.  Or, an Identifier MAY be an ephemeral property not contained in packets destined for the External Network, but instead correlated with such information through knowledge available to the different components. 3.2. The set of possible identifiers is quite large.  However, in order to be considered a good identifer, an identifier SHOULD meet the following criteria.  Note that the optimal identifier will likely change depending on the positino of the components in the network as well as the information available to them.  An identifier SHOULD: Uniquely Identify the User Equipment Be Hard to Spoof Be Visible to the API Be Visible to the Enforcement Device 3.2.1. In order to uniquely identify the User Equipment, at most one user equipment interacting with the other components of the Captive Portal MUST have a given value of the identifier. Over time, the user equipment identified by the value MAY change. Allowing the identified device to change over time ensures that the space of possible identifying vallues need not be overly large. Independent Captive Portals MAY use the same identifying value to identify different User Equipment.  Allowing indendent captive portals to reuse identifying values allows the identifier to be a property of the local network, expanding the space of possible identifiers. 3.2.2. A good identifier does not lend itself to being easily spoofed.  At no time should it be simple or straightforward for one User Equipment to pretend to be another User Equipment, regardless of whether both are active at the same time.  This property is particularly important when the user equipment is extended externally to devices such as billing systems, or where the identity of the User Equipment could imply liability. 3.2.3. Since the API will need to perform operations which rely on the identify of the user equipment, such as query whether it is captive, the API needs to be able to relate requests to the User Equipment making the request. 3.2.4. The Enforcement Device will decide on a per packet basis whether it should be permitted to communicate with the external network.  Since this decision depends on which User Equipment sent the packet, the Enforcement Device requires that it be able to map the packet to its concept of the User Equipment. 3.3. To evaluate whether an identifer is appropriate, one should consider every recommended property from the perspective of interactions among the components in the architecture.  When comparing identifiers, choose the one which best satifies all of the recommended properties. The architecture does not provide an exact measure of how well an identifier satisfies a given property; care should be taken in performing the evaluation. 3.4. This section provides some examples of identifiers, along with some evaluation of whether they are good identifiers.  The list of identifiers is not exhaustive.  Other identifiers may be used.  An important point to note is that whether the identifiers are good depends heavily on the capabilities of the components and where in the network the components exist. 3.4.1. The physical interface by which the User Equipment is attached to the network can be used to identify the User Equipment.  This identifier has the property of being extremely difficult to spoof: the User Equipment is unaware of the property; one User Equipment cannot manipulate its interactions to appear as though it is another. Further, if only a single User Equipment is attatched to a given physical interface, then the identifier will be unique.  If multiple User Equipment is attached to the network on the same physical interface, then this property is not appropriate. Another consideration related to uniqueness of the User Equipment is that if the attached User Equipment changes, both the API server and the Enforcement Device must invalidate their state related to the User Equipment. The Enforcement Device needs to be aware of the physical interface, which constrains the environment: it must either be part of the device providing physical access (e.g., implemented in firmware), or packets traversing the network must be extended to include information about the source physical interface (e.g.  a tunnel). The API server faces a similar problem, implying that it should co- exist with the Enforcement Device, or that the enforcement device should extend requests to it with the identifying information. 3.4.2. A natural identifier to consider is the IP address of the User Equipment.  At any given time, no device on the network can have the same IP address without causing the network to malfunction, so it is appropriate from the perspective of uniqueness. However, it may be possible to spoof the IP address, particularly for malicious reasons where proper functioning of the network is not necessary for the malicious actor.  Consequently, any solution using the IP address should proactively try to prevent spoofing of the IP address.  Similarily, if the mapping of IP address to User Equipment is changed, the components of the architecture must remove or update their mapping to prevent spoofing.  Demonstrations of return routeability, such as that required for TCP connection establishment, might be sufficient defense against spoofing, though this might not be sufficient in networks that use broadcast media (such as some wireless networks). Since the IP address may traverse multiple segments of the network, more flexibility is afforded to the Enforcement Device and the API server: they simply must exist on a segment of the network where the IP address is still unique.  However, consider that a NAT may be deployed between the User Equipment and the Enforcement Device.  In such cases, it is possible for the components to still uniquely identify the device if they are aware of the port mapping. In some situtations, the User Equipment may have multiple IP addresses, while still satisfying all of the recommended properties. This raises some challenges to the components of the network.  For example, if the user equipment tries to access the network with multiple IP addresses, should the enforcement device and API server treat each IP address as a unique User Equipment, or should it tie the multiple addresses together into one view of the subscriber?  An implementation MAY do either.  Attention should be paid to IPv6 and the fact that it is expected for a device to have multiple IPv6 addresses on a single link.  In such cases, idenfication could be performed by subnet, such as the /64 to which the IP belongs. 4. </ins> This section aims to improve understanding by describing a possible workflow of solutions adhering to the architecture. <del> 3.1. </del> <ins> 4.1. </ins> This section describes a possible work-flow when User Equipment initially joins a Captive Network.


The User Equipment accesses the network until conditions Expire. <del> 3.2. </del> <ins> 4.2. </ins> This section describes a possible work-flow when conditions expire and the user visits the portal again (e.g., low quota, or time


The User Equipment accesses the external network. <del> 4. </del> <ins> 5. </ins> This memo includes no request to IANA. <del> 5. </del> <ins> 6. </ins> <del> 5.1. </del> <ins> 6.1. </ins> When joining a network, some trust is placed in the network operator. This is usually considered to be a decision by a user on the basis of


provide credentials to an attacker.  Browsers can authenticate servers but cannot detect cleverly misspelled domains, for example. <del> 5.2. </del> <ins> 6.2. </ins> The solution described here assumes that when the User Equipment needs to trust the API server, server authentication will be performed using TLS mechanisms. <del> 5.3. </del> <ins> 6.3. </ins> The solution described here requires that the API be secured using TLS.  This is required to allow the user equipment and API server to


The API must ensure the integrity of this information, as well as its confidentiality. <del> 5.4. </del> <ins> 6.4. </ins> It is possible for any user on the Internet to send ICMP packets in an attempt to cause the receiving equipment to go to the captive


Even when redirected, the User Equipment securely authenticates with API servers. <del> 5.5. </del> <ins> 6.5. </ins> The ICMP messaging informs the User Equipment that it is being held captive.  There is no requirement that the User Equipment do


2.2. <del> Both the client and the server MUST send a Capabilities and Settings message (CSM see csm) as its first message on the connection.  This message establishes the initial settings and capabilities for the endpoint such as maximum message size or support for block-wise transfers.  The absence of options in the CSM indicates that base values are assumed. To avoid unnecessary latency, a client MAY send additional messages without waiting to receive the server CSM; however, it is important to note that the server CSM might advertise capabilities that impact how a client is expected to communicate with the server.  For example, the server CSM could advertise a Max-Message-Size option (see max-message-size) that is smaller than the base value (1152). Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort). 2.3. </del> The CoAP message format defined in RFC7252, as shown in CoAP-Header, relies on the datagram transport (UDP, or DTLS over UDP) for keeping the individual messages separate and for providing length


The semantics of the other CoAP header fields are left unchanged. <del> 2.4. </del> <ins> 2.3. Once a connection is established, both the client and the server MUST send a Capabilities and Settings message (CSM see csm) as its first message on the connection.  This message establishes the initial settings and capabilities for the endpoint such as maximum message size or support for block-wise transfers.  The absence of options in the CSM indicates that base values are assumed. To avoid unnecessary latency, a client MAY send additional messages without waiting to receive the server CSM; however, it is important to note that the server CSM might advertise capabilities that impact how a client is expected to communicate with the server.  For example, the server CSM could advertise a Max-Message-Size option (see max-message-size) that is smaller than the base value (1152). Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort). </ins> CoAP requests and responses are exchanged asynchronously over the TCP/TLS connection.  A CoAP client can send multiple requests without


Retransmission and deduplication of messages is provided by the TCP/ TLS protocol. <ins> 2.4. Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient.  This provides a basic keep-alive function that can refresh NAT bindings. If a client does not receive any response for some time after sending a CoAP request (or, similarly, when a client observes a resource and it does not receive any notification for some time), it can send a CoAP Ping Signaling message (sec-ping) to test the connection and verify that the server is responsive. </ins> 3. <ins> CoAP over WebSockets is intentionally similar to CoAP over TCP; therefore, this section only specifies the differences between the transports. </ins> CoAP over WebSockets can be used in a number of configurations.  The most basic configuration is a CoAP client retrieving or updating a <del> CoAP resource located at a CoAP server that exposes a WebSocket </del> <ins> CoAP resource located on a CoAP server that exposes a WebSocket </ins> endpoint (arch-1).  The CoAP client acts as the WebSocket client, establishes a WebSocket connection, and sends a CoAP request, to which the CoAP server returns a CoAP response.  The WebSocket


Further configurations are possible, including those where a WebSocket connection is established through an HTTP proxy. <del> CoAP over WebSockets is intentionally very similar to CoAP over UDP. Therefore, instead of presenting CoAP over WebSockets as a new protocol, this document specifies it as a series of deltas from RFC7252. </del> 3.1. Before CoAP requests and responses are exchanged, a WebSocket


frames as specified in Sections 5 and 6 of RFC6455. The message format shown in ws-message-format is the same as the CoAP <del> over TCP message format (see tcp-message-format) with one restriction.  The Length (Len) field MUST be set to zero because the WebSockets frame contains the length. </del> <ins> over TCP message format (see tcp-message-format) with one change. The Length (Len) field MUST be set to zero because the WebSockets frame contains the length. </ins> <del> The CoAP over TCP message format eliminates the Version field defined in CoAP over UDP.  If CoAP version negotiation is required in the future, CoAP over WebSockets can address the requirement by the definition of a new subprotocol identifier that is negotiated during the opening handshake. </del> <ins> As with CoAP over TCP, the message format for CoAP over Websockets eliminates the Version field defined in CoAP over UDP.  If CoAP version negotiation is required in the future, CoAP over WebSockets can address the requirement by the definition of a new subprotocol identifier that is negotiated during the opening handshake. </ins> Requests and response messages can be fragmented as specified in Section 5.4 of RFC6455, though typically they are sent unfragmented


requests and responses can be transferred in a block-wise fashion as defined in RFC7959. <del> Empty messages (Code 0.00) MUST be ignored by the recipient (see also sec-ping). </del> 3.3. <ins> As with CoAP over TCP, both the client and the server MUST send a Capabilities and Settings message (CSM see csm) as its first message on the WebSocket connection. </ins> CoAP requests and responses are exchanged asynchronously over the WebSocket connection.  A CoAP client can send multiple requests without waiting for a response and the CoAP server can return


The connection is bi-directional, so requests can be sent both by the entity that established the connection and the remote host. <del> Retransmission and deduplication of messages is provided by the WebSocket protocol.  CoAP over WebSockets therefore does not make a distinction between Confirmable or Non-Confirmable messages, and does not provide Acknowledgement or Reset messages. </del> <ins> As with CoAP over TCP, retransmission and deduplication of messages is provided by the WebSocket protocol.  CoAP over WebSockets therefore does not make a distinction between Confirmable or Non- Confirmable messages, and does not provide Acknowledgement or Reset messages. </ins> 3.4. <del> When a client does not receive any response for some time after sending a CoAP request (or, similarly, when a client observes a resource and it does not receive any notification for some time), the connection between the WebSocket client and the WebSocket server may be lost or temporarily disrupted without the client being aware of it. To check the health of the WebSocket connection (and thereby of all active requests, if any), a client can send a CoAP Ping Signaling message (sec-ping).  WebSocket Ping and unsolicited Pong frames as specified in Section 5.5 of RFC6455 SHOULD NOT be used to ensure that redundant maintenance traffic is not transmitted. There is no way to retransmit a request without creating a new one. Re-registering interest in a resource is permitted, but entirely unnecessary. 3.5. The WebSocket connection is closed as specified in Section 7 of RFC6455. All requests for which the CoAP client has not received a response yet are cancelled when the connection is closed. </del> <ins> As with CoAP over TCP, the client can test the health of the CoAP over WebSocket connection by sending a CoAP Ping Signaling message (sec-ping).  WebSocket Ping and unsolicited Pong frames (Section 5.5 of RFC6455) SHOULD NOT be used to ensure that redundant maintenance traffic is not transmitted. </ins> 4.


4.4. <del> In CoAP over TCP, Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient.  This provides a basic keep-alive function that can refresh NAT bindings.  In contrast, Ping and Pong messages are a bidirectional exchange. </del> <ins> In CoAP over reliable transports, Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient.  This provides a basic keep-alive function.  In contrast, Ping and Pong messages are a bidirectional exchange. </ins> Upon receipt of a Ping message, a single Pong message is returned with the identical token.  As with all Signaling messages, the


"authority" as defined in Section 3.2 of RFC3986. The Alternative-Address Option is a repeatable option as defined in <del> Section 5.4.5 of RFC7252. </del> <ins> Section 5.4.5 of RFC7252.  When multiple occurrences of the option are included, the peer can choose any of the alternative transport addresses. </ins> The elective Hold-Off Option indicates that the server is requesting that the peer not reconnect to it for the number of seconds given in


The syntax for the URI schemes in this section are specified using Augmented Backus-Naur Form (ABNF) RFC5234.  The definitions of <del> "host", "port", "path-abempty", and "query" are adopted from RFC3986. </del> <ins> "host", "port", "path-abempty", "query", and "fragment" are adopted from RFC3986. </ins> Section 8 (Multicast CoAP) in RFC7252 is not applicable to these schemes.


Capability and Settings messages are used for two purposes: <del> Capability options advertise the capabilities of the sender to the recipient. </del> <ins> Each capability option advertises one capability of the sender to the recipient. </ins> Setting options indicate a setting that will be applied by the sender.


2.3. <ins> Both the client and the server MUST send a Capability and Settings message (CSM see csm) as its first message on the connection.  This message establishes the initial settings and capabilities for the endpoint such as maximum message size or support for block-wise transfers.  The absence of options in the CSM indicates that base values are assumed. Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort). 2.4. </ins> The CoAP message format defined in RFC7252, as shown in CoAP-Header, relies on the datagram transport (UDP, or DTLS over UDP) for keeping the individual messages separate and for providing length


The semantics of the other CoAP header fields are left unchanged. <del> 2.4. </del> <ins> 2.5. </ins> CoAP requests and responses are exchanged asynchronously over the TCP/TLS connection.  A CoAP client can send multiple requests without


Setting options indicate a setting that will be applied by the sender. <del> Most CSM Options are useful mainly as initial messages in the connection. </del> <ins> A Capability and Settings message MUST be sent by both endpoints at the start of the connection and MAY be sent at any other time by either endpoint over the lifetime of the connection. </ins> Both capability and settings options are cumulative.  A Capability and Settings message does not invalidate a previously sent capability


Base values are listed below for CSM Options.  These are the values for the Capability and Setting before any Capability and Settings <del> messages sends a modified value. </del> <ins> messages send a modified value. </ins> These are not default values for the option as defined in Section 5.4.4 in RFC7252.  A default value would mean that an empty


1.1. <del> The terminology from RFC7252 and STD94 applies.  Readers are also expected to be familiar with the terminology from RFC7807. </del> <ins> The terminology from RFC7252, STD94, and RFC8610 applies; in particular CBOR diagnostic notation is defined in STD94 and RFC8610. Readers are also expected to be familiar with the terminology from RFC7807. </ins> In this document, the structure of data is specified in CDDL RFC8610 RFC9165.


be dereferenced in the normal course of handling problem details (i.e., outside diagnostic/debugging procedures involving humans). <del> An example of a custom extension using a URI as "custom-problem- detail-entries" key is shown in fig-example-custom-with-uri. </del> <ins> fig-example-custom-with-uri shows an example (in CBOR diagnostic notation) of a custom extension using a (made-up) URI as "custom- problem-detail-entries" key. </ins> Obviously, an SDO like 3GPP can also easily register such a custom problem detail entry to receive a more efficient unsigned integer <del> key; the same example but using a registered unsigned int as "custom- problem-detail-entries" key is shown in fig-example-custom-with-uint. </del> <ins> key; fig-example-custom-with-uint shows how the same example would look like using a (made-up) registered unsigned int as "custom- problem-detail-entries" key: </ins> In summary, the keys for the maps used inside Custom Problem Detail entries are defined specifically to the identifier of that Custom


calculation of the counter signature can be computed.  Details on computing counter signatures are found in counter_signature. <del> This parameter provides the time the content was created.  For signatures and recipient structures, this would be the time that the signature or recipient key object was created.  For content structures, this would be the time that the content was created. The unsigned integer value is the number of seconds, excluding leap seconds; after midnight UTC, January 1, 1970. </del> <ins> This parameter provides the time the content cryptographic operation is performed.  For signatures and recipient structures, this would be the time that the signature or recipient key object was created.  For content structures, this would be the time that the content structure was created.  The unsigned integer value is the number of seconds, excluding leap seconds; after midnight UTC, January 1, 1970.  The field is primarily intended to be to be used for countersignatures, however it can additionally be used for replay detection as well. </ins> The CDDL fragment that represents the set of headers defined in this section is given below.  Each of the headers is tagged as optional


1.3. There currently is no standard CBOR grammar available for use by <del> specifications.  In this document, we use a modified version of the CBOR data definition language (CDDL) defined in I-D.greevenbosch- appsawg-cbor-cddl.  The differences between the defined grammar and the one we used are mostly self explanatory.  The biggest difference being the addition of the choice operator '|'.  Additionally, note the use of the null value which is used to occupy a location in an array but to mark that the element is not present. </del> <ins> specifications.  In this document, we use the grammar defined in the CBOR data definition language (CDDL) I-D.greevenbosch-appsawg-cbor- cddl. </ins> 2.


contains the information about the plain text or encryption process that is to be integrity protected.  The field is encoded <del> in CBOR as a 'bstr' if present and the value 'null' if there is no </del> <ins> in CBOR as a 'bstr' if present and the value 'nil' if there is no </ins> data.  The contents of the protected field is a CBOR map of the protected data names and values.  The map is CBOR encoded before placing it into the bstr.  Only values associated with the current


would apply to multiple recipient structures. contains information about the plain text that is not integrity <del> protected.  If there are no field, then the value 'null' is used. </del> <ins> protected.  If there are no field, then the value 'nil' is used. </ins> Only values associated with the current cipher text are to be placed in this location even if the value would apply to multiple recipient structures. contains the initialization vector (IV), or it's equivalent, if one is needed by the encryption algorithm.  If there is no IV, <del> then the value 'null' is used. </del> <ins> then the value 'nil' is used. </ins> contains additional authenticated data (aad) supplied by the application.  This field contains information about the plain text data that is authenticated, but not encrypted.  If the application <del> does not provide this data, the value 'null' is used. </del> <ins> does not provide this data, the value 'nil' is used. </ins> contains the encrypted plain text.  If the cipherText is to be transported independently of the control information about the <del> encryption process (i.e. detached content) then the value 'null' is encoded here. </del> <ins> encryption process (i.e. detached content) then the value 'nil' is encoded here. </ins> contains the recipient information.  The field can have one of three data types:


recipients can be encoded either this way or as a single array element. <del> A 'null' value if there are no recipients. </del> <ins> A 'nil' value if there are no recipients. </ins> 4.1.


4.1.1. In direct encryption mode, a shared secret between the sender and the <del> recipient is used as the CEK.  For direct encryption mode, no recipient structure is built.  All of the information about the key is placed in either the protected or unprotected fields at the content level.  When direct encryption mode is used, it MUST be the only mode used on the message.  It is a massive security leak to have both direct encryption and a different key management mode on the same message. </del> <ins> recipient is used as the CEK.  When direct encryption mode is used, it MUST be the only mode used on the message.  It is a massive security leak to have both direct encryption and a different key management mode on the same message. </ins> For JOSE, direct encryption key management is the only key management method allowed for doing MAC-ed messages.  In COSE, all of the key


The COSE_encrypt structure for the recipient is organized as follows: The 'protected', 'iv', 'aad', 'ciphertext' and 'recipients' fields <del> MUST be null. </del> <ins> MUST be nil. </ins> At a minimum, the 'unprotected' field SHOULD contain the 'alg' parameter as well as a parameter identifying the shared secret.


The COSE_encrypt structure for the recipient is organized as follows: <del> The 'protected', 'aad', and 'recipients' fields MUST be null. </del> <ins> The 'protected', 'aad', and 'recipients' fields MUST be nil. </ins> The plain text to be encrypted is the key from next layer down (usually the content layer).


4.1.4. Direct Key Agreement derives the CEK from the shared secret computed <del> by the key agreement operation.  For Direct Key Agreement, no recipient structure is built.  All of the information about the key and key agreement process is placed in either the 'protected' or 'unprotected' fields at the content level. </del> <ins> by the key agreement operation. </ins> When direct key agreement mode is used, it SHOULD be the only mode used on the message.  This method creates the CEK directly and that


The COSE_encrypt structure for the recipient is organized as follows: <del> The 'protected', 'aad', and 'iv' fields all use the 'null' value. </del> <ins> The 'protected', 'aad', and 'iv' fields all use the 'nil' value. </ins> At a minimum, the 'unprotected' field SHOULD contain the 'alg' parameter as well as a parameter identifying the asymmetric key.


The COSE_encrypt structure for the recipient is organized as follows: <del> The 'protected', 'aad', and 'iv' fields all use the 'null' value. </del> <ins> The 'protected', 'aad', and 'iv' fields all use the 'nil' value. </ins> The plain text to be encrypted is the key from next layer down (usually the content layer).


The following values are used for L: <del> limits messages to 2^16 bytes in length.  The nonce length is 13 bytes allowing for 2^(13*8) possible values of the nonce without repeating. </del> <ins> limits messages to 2^16 bytes (64Kbyte) in length.  This sufficently long for messages in the constrainted world.  The nonce length is 13 bytes allowing for 2^(13*8) possible values of the nonce without repeating. </ins> limits messages to 2^64 byes in length.  The nonce length is 7 bytes allowing for 2^56 possible values of the nonce without


7. Security considerations for DetNet are described in detail in I- <del> D.ietf-detnet-security.  This section considers exclusively security considerations which are specific to the DetNet data plane. </del> <ins> D.ietf-detnet-security.  General security considerations are described in I-D.ietf-detnet-architecture.  This section considers exclusively security considerations which are specific to the DetNet IP data plane. </ins> Security aspects which are unique to DetNet are those whose aim is to provide the specific quality of service aspects of DetNet, which are


and bounded end-to-end delivery latency. The primary considerations for the data plane is to maintain <del> confidentiality of data traversing the DetNet network, application flows can be protected through whatever means is provided by the underlying technology.  For example, encryption may be used, such as that provided by IPSec RFC4301 for IP flows and by MACSec IEEE802.1AE-2018 for Ethernet (Layer-2) flows. DetNet flows are identified on a per-flow basis, which may provide attackers with additional information about the data flows (when compared to networks that do not include per-flow identification). This is an inherent property of DetNet which has security implications that should be considered when determining if DetNet is a suitable technology for any given use case. To provide uninterrupted availability of the DetNet quality of service, provisions can be made against DOS attacks and delay attacks.  To protect against DOS attacks, excess traffic due to malicious or malfunctioning devices can be prevented or mitigated, for example through the use of traffic admission control applied at the input of a DetNet domain.  To prevent DetNet packets from being delayed by an entityexternal to a DetNet domain, DetNet technology definition can allow for the mitigation of Man-In-The-Middle attacks, for example through use of authentication and authorization of devices within the DetNet domain. Because DetNet mechanisms or applications that rely on DetNet can make heavy use of methods that require precise time synchronization, the accuracy, availability, and integrity of time synchronization is of critical importance.  Extensive discussion of this topic can be found in RFC7384. </del> <ins> integrity of data and delivery of the associated DetNet service traversing the DetNet network.  Application flows can be protected through whatever means is provided by the underlying technology.  For example, encryption may be used, such as that provided by IPSec RFC4301 for IP flows and/or by an underlying sub-net using MACSec IEEE802.1AE-2018 for IP over Ethernet (Layer-2) flows. From a data plane perspective this document does not add or modify any header information. At the management and control level DetNet flows are identified on a per-flow basis, which may provide controller plane attackers with additional information about the data flows (when compared to controller planes that do not include per-flow identification).  This is an inherent property of DetNet which has security implications that should be considered when determining if DetNet is a suitable technology for any given use case. To provide uninterrupted availability of the DetNet service, provisions can be made against DOS attacks and delay attacks.  To protect against DOS attacks, excess traffic due to malicious or malfunctioning devices can be prevented or mitigated, for example through the use of existing mechanism such as policing and shaping applied at the input of a DetNet domain.  To prevent DetNet packets from being delayed by an entity external to a DetNet domain, DetNet technology definition can allow for the mitigation of Man-In-The- Middle attacks, for example through use of authentication and authorization of devices within the DetNet domain. </ins> 8.


The "Deprecation" response header field describes the deprecation of the resource identified with the response it occurred within (see <del> Section 3.1.4.1 of HTTP).  It conveys either the deprecation date, which may be in the future (the resource context will be deprecated at that date) or in the past (the resource context has been deprecated at that date), or it simply flags the resource context as being deprecated. </del> <ins> Section 3.1.4.1 of HTTP).  It conveys the deprecation date, which may be in the future (the resource context will be deprecated at that date) or in the past (the resource context has been deprecated at that date). </ins> Servers MUST NOT include more than one "Deprecation" header field in the same response. <del> The date, if present, is the date when the resource was or will be deprecated.  It is in the form of an IMF-fixdate timestamp. </del> <ins> The date is the date when the resource was or will be deprecated.  It is in the form of an IMF-fixdate timestamp. </ins> The following example shows that the resource context has been deprecated on Sunday, November 11, 2018 at 23:59:59 GMT: The deprecation date can be in the future.  This means that the <del> resource will be deprecated at the given date in future. If the deprecation date is not known, the header field can carry the simple string "true", indicating that the resource context is deprecated, without indicating when that happened: </del> <ins> resource will be deprecated at the indicated date in the future. </ins> 2.2.


10. <del> The first example shows a deprecation header field without date information: The second example shows a deprecation header with date information </del> <ins> The first example shows a deprecation header with date information </ins> and a link to the successor version: <del> The third example shows a deprecation header field with links for the successor version and for the API's deprecation policy.  In addition, it shows the sunset date for the deprecated resource: </del> <ins> The second example shows a deprecation header field with links for the successor version and for the API's deprecation policy.  In addition, it shows the sunset date for the deprecated resource: </ins>


unsigned CNAME records that may have been synthesized in the response from a DNS resolver. <del> The subsequent RRsets MUST contain the full sequence of DNS records needed to authenticate the TLSA record set from the server's trust anchor.  Typically this means a sequence of DNSKEY and DS RRsets that cover all zones from the target zone containing the TLSA record set to the trust anchor zone. </del> <ins> The subsequent RRsets MUST contain the full set of DNS records needed to authenticate the TLSA record set from the server's trust anchor. Typically this means a set of DNSKEY and DS RRsets that cover all zones from the target zone containing the TLSA record set to the trust anchor zone.  The TLS client should be prepared to receive this set of RRsets in any order. </ins> Names that are aliased via CNAME and/or DNAME records may involve multiple branches of the DNS tree.  In this case, the authentication


for encrypted DNS protocols when the name of an encrypted resolver is known.  This mechanism is designed to be limited to cases where unencrypted resolvers and their designated resolvers are operated by <del> the same entity. </del> <ins> the same entity or cooperating entities. </ins> 1.