< draft-ietf-tcpm-converters-07.txt   draft-ietf-tcpm-converters-08.txt >
TCPM Working Group O. Bonaventure, Ed. TCPM Working Group O. Bonaventure, Ed.
Internet-Draft Tessares Internet-Draft Tessares
Intended status: Experimental M. Boucadair, Ed. Intended status: Experimental M. Boucadair, Ed.
Expires: December 13, 2019 Orange Expires: December 20, 2019 Orange
S. Gundavelli S. Gundavelli
Cisco Cisco
S. Seo S. Seo
Korea Telecom Korea Telecom
B. Hesmans B. Hesmans
Tessares Tessares
June 11, 2019 June 18, 2019
0-RTT TCP Convert Protocol 0-RTT TCP Convert Protocol
draft-ietf-tcpm-converters-07 draft-ietf-tcpm-converters-08
Abstract Abstract
This document specifies an application proxy, called Transport This document specifies an application proxy, called Transport
Converter, to assist the deployment of TCP extensions such as Converter, to assist the deployment of TCP extensions such as
Multipath TCP. This proxy is designed to avoid inducing extra delay Multipath TCP. This proxy is designed to avoid inducing extra delay
when involved in a network-assisted connection (that is, 0-RTT). when involved in a network-assisted connection (that is, 0-RTT).
This specification assumes an explicit model, where the proxy is This specification assumes an explicit model, where the proxy is
explicitly configured on hosts. explicitly configured on hosts.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 13, 2019. This Internet-Draft will expire on December 20, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Functional Elements . . . . . . . . . . . . . . . . . . . 6 3.1. Functional Elements . . . . . . . . . . . . . . . . . . . 6
3.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 8 3.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 8
3.3. Sample Examples of Outgoing Converter-Assisted Multipath 3.3. Sample Examples of Outgoing Converter-Assisted Multipath
TCP Connections . . . . . . . . . . . . . . . . . . . . . 11 TCP Connections . . . . . . . . . . . . . . . . . . . . . 11
3.4. Sample Example of Incoming Converter-Assisted Multipath 3.4. Sample Example of Incoming Converter-Assisted Multipath
TCP Connection . . . . . . . . . . . . . . . . . . . . . 12 TCP Connection . . . . . . . . . . . . . . . . . . . . . 13
4. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 13 4. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 14
4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 13 4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 14
4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 14 4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 15
4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 15 4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 16
4.2.3. The Info TLV . . . . . . . . . . . . . . . . . . . . 16 4.2.3. The Info TLV . . . . . . . . . . . . . . . . . . . . 17
4.2.4. Supported TCP Extensions TLV . . . . . . . . . . . . 16 4.2.4. Supported TCP Extensions TLV . . . . . . . . . . . . 17
4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 17 4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 18
4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 19 4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 20
4.2.7. The Cookie TLV . . . . . . . . . . . . . . . . . . . 19 4.2.7. The Cookie TLV . . . . . . . . . . . . . . . . . . . 20
4.2.8. Error TLV . . . . . . . . . . . . . . . . . . . . . . 20 4.2.8. Error TLV . . . . . . . . . . . . . . . . . . . . . . 21
5. Compatibility of Specific TCP Options with the Conversion 5. Compatibility of Specific TCP Options with the Conversion
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 23 5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 24
5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 24 5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 25
5.3. Selective Acknowledgements . . . . . . . . . . . . . . . 24 5.3. Selective Acknowledgements . . . . . . . . . . . . . . . 25
5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 25 5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 26
5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 25 5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 26
5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 25 5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 26
5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 26 5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 27
5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 26 5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 27
6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 26 6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 27 7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 28
7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 28 7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 29
7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 29 7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 30
7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 29 7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 30
7.5. Multipath TCP-specific Considerations . . . . . . . . . . 29 7.5. Multipath TCP-specific Considerations . . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8.1. Convert Service Port Number . . . . . . . . . . . . . . . 30 8.1. Convert Service Port Number . . . . . . . . . . . . . . . 31
8.2. The Convert Protocol (Convert) Parameters . . . . . . . . 30 8.2. The Convert Protocol (Convert) Parameters . . . . . . . . 31
8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 30 8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 31
8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 31 8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 32
8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 31 8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 32
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 33 9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 34
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 34 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 35
11. Example Socket API Changes to Support the 0-RTT Convert 11. Example Socket API Changes to Support the 0-RTT Convert
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.1. Active Open (Client Side) . . . . . . . . . . . . . . . 35 11.1. Active Open (Client Side) . . . . . . . . . . . . . . . 36
11.2. Passive Open (Converter Side) . . . . . . . . . . . . . 36 11.2. Passive Open (Converter Side) . . . . . . . . . . . . . 37
12. Differences with SOCKSv5 . . . . . . . . . . . . . . . . . . 37 12. Differences with SOCKSv5 . . . . . . . . . . . . . . . . . . 38
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
13.1. Normative References . . . . . . . . . . . . . . . . . . 39 13.1. Normative References . . . . . . . . . . . . . . . . . . 40
13.2. Informative References . . . . . . . . . . . . . . . . . 41 13.2. Informative References . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
Transport protocols like TCP evolve regularly [RFC7414]. TCP has Transport protocols like TCP evolve regularly [RFC7414]. TCP has
been improved in different ways. Some improvements such as changing been improved in different ways. Some improvements such as changing
the initial window size [RFC6928] or modifying the congestion control the initial window size [RFC6928] or modifying the congestion control
scheme can be applied independently on clients and servers. Other scheme can be applied independently on clients and servers. Other
improvements such as Selective Acknowledgements [RFC2018] or large improvements such as Selective Acknowledgements [RFC2018] or large
windows [RFC7323] require a new TCP option or to change the semantics windows [RFC7323] require a new TCP option or to change the semantics
of some fields in the TCP header. These modifications must be of some fields in the TCP header. These modifications must be
skipping to change at page 4, line 26 skipping to change at page 4, line 26
extensions on both a wide range of clients and servers remains extensions on both a wide range of clients and servers remains
difficult. difficult.
More recently, experimentation of 5G bonding, which has very scarce More recently, experimentation of 5G bonding, which has very scarce
coverage, has been conducted into global range of the incumbent 4G coverage, has been conducted into global range of the incumbent 4G
(LTE) connectivity in newly devised clients using Multipath TCP (LTE) connectivity in newly devised clients using Multipath TCP
proxy. Even if the 5G and the 4G bonding by using Multipath TCP proxy. Even if the 5G and the 4G bonding by using Multipath TCP
increases the bandwidth, it is as well crucial to minimize latency increases the bandwidth, it is as well crucial to minimize latency
for all the way between endhosts regardless of whether intermediate for all the way between endhosts regardless of whether intermediate
nodes are inside or outside of the mobile core. In order to handle nodes are inside or outside of the mobile core. In order to handle
uRLLC (Ultra-Reliable Low-Latency Communication) for the next URLLC (Ultra Reliable Low Latency Communication) for the next
generation mobile network, Multipath TCP and its proxy mechanism such generation mobile network, Multipath TCP and its proxy mechanism such
as the one used to provide Access Taffic Steering, Switching, and as the one used to provide Access Traffic Steering, Switching, and
Splitting (ATSSS) must be optimised to reduce latency. Splitting (ATSSS) must be optimised to reduce latency [TS23501].
This document specifies an application proxy, called Transport This document specifies an application proxy, called Transport
Converter. A Transport Converter is a function that is installed by Converter. A Transport Converter is a function that is installed by
a network operator to aid the deployment of TCP extensions and to a network operator to aid the deployment of TCP extensions and to
provide the benefits of such extensions to clients. A Transport provide the benefits of such extensions to clients. A Transport
Converter may provide conversion service for one or more TCP Converter may provide conversion service for one or more TCP
extensions. Which TCP extensions are eligible to the conversion extensions. Which TCP extensions are eligible to the conversion
service is deployment-specific. The conversion service is provided service is deployment-specific. The conversion service is provided
by means of the 0-RTT TCP Convert Protocol (Convert), that is an by means of the 0-RTT TCP Convert Protocol (Convert), that is an
application-layer protocol which uses TCP port number TBA application-layer protocol which uses TCP port number TBA
skipping to change at page 9, line 31 skipping to change at page 9, line 31
o the downstream connection is between the Transport Converter and o the downstream connection is between the Transport Converter and
the Server. the Server.
Any user data received by the Transport Converter over the upstream Any user data received by the Transport Converter over the upstream
(or downstream) connection is relayed over the downstream (or (or downstream) connection is relayed over the downstream (or
upstream) connection. In particular, if the initial SYN message upstream) connection. In particular, if the initial SYN message
contains data in its payload (e.g., [RFC7413]), that data MUST be contains data in its payload (e.g., [RFC7413]), that data MUST be
placed right after the Convert TLVs when generating the relayed SYN. placed right after the Convert TLVs when generating the relayed SYN.
The Converter associates a lifetime with state entries used to bind
an upstream connection with its downstream connection.
Figure 5 illustrates the establishment of an outbound TCP connection Figure 5 illustrates the establishment of an outbound TCP connection
by a Client through a Transport Converter. The information shown by a Client through a Transport Converter. The information shown
between brackets denotes Convert Protocol messages described in between brackets denotes Convert Protocol messages described in
Section 4. Section 4.
Transport Transport
Client Converter Server Client Converter Server
| | | | | |
|SYN [->Server:port]| SYN | |SYN [->Server:port]| SYN |
|------------------>|--------------------->| |------------------>|--------------------->|
skipping to change at page 10, line 44 skipping to change at page 10, line 49
specification follows an approach similar to TCP Fast Open [RFC7413] specification follows an approach similar to TCP Fast Open [RFC7413]
and thus removes the constraint by allowing data in SYN packets to be and thus removes the constraint by allowing data in SYN packets to be
delivered to the Transport Converter application. delivered to the Transport Converter application.
As discussed in [RFC7413], such change to TCP semantic raises two As discussed in [RFC7413], such change to TCP semantic raises two
issues. First, duplicate SYNs can cause problems for some issues. First, duplicate SYNs can cause problems for some
applications that rely on TCP. Second, TCP suffers from SYN flooding applications that rely on TCP. Second, TCP suffers from SYN flooding
attacks [RFC4987]. TFO solves these two problems for applications attacks [RFC4987]. TFO solves these two problems for applications
that can tolerate replays by using the TCP Fast Open option that that can tolerate replays by using the TCP Fast Open option that
includes a cookie. However, the utilization of this option consumes includes a cookie. However, the utilization of this option consumes
space in the limited TCP extended header. Furthermore, there are space in the limited TCP header. Furthermore, there are situations,
situations, as noted in Section 7.3 of [RFC7413] where it is possible as noted in Section 7.3 of [RFC7413] where it is possible to accept
to accept the payload of SYN packets without creating additional the payload of SYN packets without creating additional security risks
security risks such as a network where addresses cannot be spoofed such as a network where addresses cannot be spoofed and the Transport
and the Transport Converter only serves a set of hosts that are Converter only serves a set of hosts that are identified by these
identified by these addresses. addresses.
For these reasons, this specification does not mandate the use of the For these reasons, this specification does not mandate the use of the
TCP Fast Open option when the Client sends a connection establishment TCP Fast Open option when the Client sends a connection establishment
packet towards a Transport Converter. The Convert protocol includes packet towards a Transport Converter. The Convert protocol includes
an optional Cookie TLV that provides similar protection as the TCP an optional Cookie TLV that provides similar protection as the TCP
Fast Open option without consuming space in the extended TCP header. Fast Open option without consuming space in the extended TCP header.
If the downstream (or upstream) connection fails for some reason
(excessive retransmissions, reception of a RST segment, etc.), then
the Converter should force the teardown of the upstream (or
downstream) connection.
The same reasoning applies when the upstream connection ends. In
this case, the Converter should also terminate the downstream
connection by using FIN segments. If the downstream connection
terminates with the exchange of FIN segments, the Converter should
initiate a graceful termination of the upstream connection.
3.3. Sample Examples of Outgoing Converter-Assisted Multipath TCP 3.3. Sample Examples of Outgoing Converter-Assisted Multipath TCP
Connections Connections
As an example, let us consider how the Convert protocol can help the As an example, let us consider how the Convert protocol can help the
deployment of Multipath TCP. We assume that both the Client and the deployment of Multipath TCP. We assume that both the Client and the
Transport Converter support Multipath TCP, but consider two different Transport Converter support Multipath TCP, but consider two different
cases depending on whether the Server supports Multipath TCP or not. cases depending on whether the Server supports Multipath TCP or not.
As a reminder, a Multipath TCP connection is created by placing the As a reminder, a Multipath TCP connection is created by placing the
MP_CAPABLE (MPC) option in the SYN sent by the Client. MP_CAPABLE (MPC) option in the SYN sent by the Client.
skipping to change at page 12, line 5 skipping to change at page 12, line 33
The Client tries to initiate a Multipath TCP connection by sending a The Client tries to initiate a Multipath TCP connection by sending a
SYN with the MP_CAPABLE option (MPC in Figure 6). The SYN includes SYN with the MP_CAPABLE option (MPC in Figure 6). The SYN includes
the address and port number of the target Server, that are extracted the address and port number of the target Server, that are extracted
and used by the Transport Converter to initiate a Multipath TCP and used by the Transport Converter to initiate a Multipath TCP
connection towards this Server. Since the Server does not support connection towards this Server. Since the Server does not support
Multipath TCP, it replies with a SYN+ACK that does not contain the Multipath TCP, it replies with a SYN+ACK that does not contain the
MP_CAPABLE option. The Transport Converter notes that the connection MP_CAPABLE option. The Transport Converter notes that the connection
with the Server does not support Multipath TCP and returns the with the Server does not support Multipath TCP and returns the
extended TCP header received from the Server to the Client. extended TCP header received from the Server to the Client.
Note that, if the TCP connection fails for some reason, the Converter
tears down the Multipath TCP connection by transmitting a
MP_FASTCLOSE. Likewise, if the Multipath TCP connection ends with
the transmission of DATA_FINs, the Converter terminates the TCP
connection by using FIN segments.
Figure 7 considers a Server that supports Multipath TCP. In this Figure 7 considers a Server that supports Multipath TCP. In this
case, it replies to the SYN sent by the Transport Converter with the case, it replies to the SYN sent by the Transport Converter with the
MP_CAPABLE option. Upon reception of this SYN+ACK, the Transport MP_CAPABLE option. Upon reception of this SYN+ACK, the Transport
Converter confirms the establishment of the connection to the Client Converter confirms the establishment of the connection to the Client
and indicates to the Client that the Server supports Multipath TCP. and indicates to the Client that the Server supports Multipath TCP.
With this information, the Client has discovered that the Server With this information, the Client has discovered that the Server
supports Multipath TCP natively. This will enable the Client to supports Multipath TCP natively. This will enable the Client to
bypass the Transport Converter for the subsequent Multipath TCP bypass the Transport Converter for the subsequent Multipath TCP
connections that it will initiate towards this Server. connections that it will initiate towards this Server.
skipping to change at page 23, line 52 skipping to change at page 24, line 52
In this section, we discuss how several standard track TCP options In this section, we discuss how several standard track TCP options
can be supported through the Convert protocol. The non-standard can be supported through the Convert protocol. The non-standard
track options and the experimental options will be discussed in other track options and the experimental options will be discussed in other
documents. documents.
5.1. Base TCP Options 5.1. Base TCP Options
Three TCP options were initially defined in [RFC0793]: End-of-Option Three TCP options were initially defined in [RFC0793]: End-of-Option
List (Kind=0), No-Operation (Kind=1) and Maximum Segment Size List (Kind=0), No-Operation (Kind=1) and Maximum Segment Size
(Kind=2). The first two options are mainly used to pad the TCP (Kind=2). The first two options are mainly used to pad the TCP
extended header. There is no reason for a client to request a header. There is no reason for a client to request a Transport
Transport Converter to specifically send these options towards the Converter to specifically send these options towards the final
final destination. destination.
The Maximum Segment Size option (Kind=2) is used by a host to The Maximum Segment Size option (Kind=2) is used by a host to
indicate the largest segment that it can receive over each indicate the largest segment that it can receive over each
connection. This value is function of the stack that terminates the connection. This value is function of the stack that terminates the
TCP connection. There is no reason for a Client to request a TCP connection. There is no reason for a Client to request a
Transport Converter to advertise a specific MSS value to a remote Transport Converter to advertise a specific MSS value to a remote
server. server.
A Transport Converter MUST ignore options with Kind=0, 1 or 2 if they A Transport Converter MUST ignore options with Kind=0, 1 or 2 if they
appear in a Connect TLV. It MUST NOT announce them in a Supported appear in a Connect TLV. It MUST NOT announce them in a Supported
skipping to change at page 35, line 35 skipping to change at page 36, line 35
o 07: o 07:
* Update the text about supplying data in SYNs to make it clear * Update the text about supplying data in SYNs to make it clear
that a constraint defined in RFC793 is relaxed folloiwng the that a constraint defined in RFC793 is relaxed folloiwng the
same rationale as in RFC7413. same rationale as in RFC7413.
* Nits * Nits
* Added Appendix A on example Socket API changes * Added Appendix A on example Socket API changes
o 08:
* Added short discusion on the termination of connections
11. Example Socket API Changes to Support the 0-RTT Convert Protocol 11. Example Socket API Changes to Support the 0-RTT Convert Protocol
11.1. Active Open (Client Side) 11.1. Active Open (Client Side)
On the client side, the support of the 0-RTT Converter protocol does On the client side, the support of the 0-RTT Converter protocol does
not require any other changes than those identified in Appendix A of not require any other changes than those identified in Appendix A of
[RFC7413]. Those modifications are already supported by multiple TCP [RFC7413]. Those modifications are already supported by multiple TCP
stacks. stacks.
As an example, on Linux, a client can send the 0-RTT Convert message As an example, on Linux, a client can send the 0-RTT Convert message
skipping to change at page 44, line 30 skipping to change at page 45, line 30
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, [RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
Q., and E. Smith, "Cryptographic Protection of TCP Streams Q., and E. Smith, "Cryptographic Protection of TCP Streams
(tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019,
<https://www.rfc-editor.org/info/rfc8548>. <https://www.rfc-editor.org/info/rfc8548>.
[TS23501] 3GPP (3rd Generation Partnership Project), ., "Technical
Specification Group Services and System Aspects; System
Architecture for the 5G System; Stage 2 (Release 16)",
2019, <https://www.3gpp.org/ftp/Specs/
archive/23_series/23.501/>.
Authors' Addresses Authors' Addresses
Olivier Bonaventure (editor) Olivier Bonaventure (editor)
Tessares Tessares
Email: Olivier.Bonaventure@tessares.net Email: Olivier.Bonaventure@tessares.net
Mohamed Boucadair (editor) Mohamed Boucadair (editor)
Orange Orange
 End of changes. 16 change blocks. 
62 lines changed or deleted 92 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/