0-RTT TCP Convert Protocol
draft-ietf-tcpm-converters-19

Received changes through RFC Editor sync (created alias RFC 8803, changed abstract to 'This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. A Transport Converter may provide conversion service for one or more TCP extensions. The conversion service is provided by means of the 0-RTT TCP Convert Protocol (Convert).

This protocol provides 0-RTT (Zero Round-Trip Time) conversion service since no extra delay is induced by the protocol compared to connections that are not proxied. Also, the Convert Protocol does not require any encapsulation (no tunnels whatsoever).

This specification assumes an explicit model, where the Transport Converter is explicitly configured on hosts. As a sample applicability use case, this document specifies how the Convert Protocol applies for Multipath TCP.', changed pages to 47, changed standardization level to Experimental, changed state to RFC, added RFC published event at 2020-07-28, changed IESG state to RFC Published)

[Ballot comment]
Thank you for adding the applicability statement; it removes the main sense
of having disparate deployment scenarios one of which is well-defined and the
other of which requires some under-specified actions in order to be secure.

I'm still pretty uneasy about giving such emphasis to the "0-RTT" nature
of this service, and feel that achieving the "0-RTT" nature relies on some
strong assumptions on the nature of the network in which the protocol is
being deployed, so that the 0-RTT nature is not as much an attribute of
the protocol itself as the combination of the protocol and the deployment
scenario.  That said, the document is not describing an internally inconsistent
state, so I cannot justify making this a Discuss-level point any more.

[Ballot comment]
Med and other authors,

Thank you for addressing my previous DISCUSS (kept below for archival purpose), they are now cleared. Most of my COMMENTs were also addressed.

BUT, the new version has a couple of typos in the changed text, e.g., 'relam' rather than 'realm'. It also uses 'Unassigned' rather than the usual 'Reserved', is there any reason?

Finally, I wonder why the 'magic number' has been introduced and while using the RFC number if 'fun' the entropy is not that high.

Anyway, the document can be published in my opinion

Thank you for all the work and the fast reaction

-éric

== OLD DISCUSS ==

-- Section 1.2 --
A trivial one: while the title and the abstract of this document appear as quite generic, the document focus is reduced later in section 1.2 to MPTCP:
  "this
  document specifies how the Convert Protocol applies for Multipath
  TCP.  It is out of scope of this document to provide a comprehensive
  list of all potential conversion services. "
While I do not mind having a focus on MPTCP only, I would strongly suggest to reflect this focus in the title and in the abstract (the current filename is correct).

-- Section 6.2.8 --
I appreciate that this is an experimental document, but, having only 2 occurrences of ICMP in the whole document and no real "how to process" TLV "Destination Unreachable"... and the payload of this TLV having only the code without the offending packet will probably make Path MTU discovery (and other mechanisms) impossible.

While I am not a transport expert, I believe that this aspect needs to be described in this document.

== COMMENTS ==

-- Section 1.2 --
Is the benefit of a transport proxy only for the clients as written in the 1st paragraph? It was probably the case for the original MPTCP proxy but what about other TCP extensions?


-- Section 4.1 --
While the difference "(Internet-facing interface, customer-facing interface)" will probably represent the vast majority of use cases, I wonder whether there will always be a single Internet-facing ? Could probably be 0 or 2 in some use cases... Suggest to remove this part of the text.

-- Section 6.1 --
Please state the usual wording about "unassigned" field: it must be ignored by the receiver.

Adding some explanations on why version 0 is reserved but cannot be used would be welcome.

-- Section 6.2.5 --
Can the "remote peer IP address" be a link-local address ?

== NITS ==

-- Section 1.1 (and possibly others) --
Please use a consistent means of introducing acronyms, cfr URLLC and ATSSS ;-)

-- Section 4.2 ---
The use of "regular TCP packets" makes me wonder whether the authors think that MPTCP uses "irregular TCP packets"... The use of 'regular' seems a little weird here but I am not a native English speaker.

-- Section 4.3 --
The caption below figure 7 ends with "(TCP)" that is not the acronym of "Transport Session Entry". Is it expected ?

[Ballot comment]
It is not very clear whether the WG expects many future version of this protocol. Version compatibility story is not very clear in this document, so the WG should think about it.

[Ballot comment]
I had a similar question as Éric on the handling of ICMP messages and related troubleshooting (specifically I was concerned about the non-Type 1 (Destination Unreachable) messages. I saw the authors responded and I will keep track of the discussion.

[Ballot discuss]
I agree with Roman, and present a somewhat different take on some of the
key aspects of the scoping discussion.

I have pretty fundamental concerns about describing this protocol as a
"0-RTT" service when it both requires strong mutual
authentication/authorization of the communicating endpoints and relies
on the (local) network to provide those properties.  If IP in general
provided the kind of mutual authentication assumed here, the internet
would be a much more secure place!  Unfortunately, it does not and I
think this document does its readers a disservice by transparently
assuming that it does (in the main body of text; the security
considerations do touch on the requisite details).  It would be better
to discuss the proxy protocol separately from the deployment
considerations that allow it to be used without additional set-up in
specific deployment scenarios.

And that's only when considering the client authenticating the server!
Mutual authentication also requires the server to authenticate the
client and be able to make authorization decisions based upon that
authenticated identity.  The deployment model presented here seems to
imply a very tight coupling between the Transport Converter operator and
the network service provider (in order to determine, based on client IP
address, the authenticated client identity and access an authorization
database); this seems to make it incompatible with the stated
possibility of using a third-party Transport Converter.
Additionally, it raises some questions along the lines of
draft-arkko-iab-internet-consolidation and draft-iab-for-the-users.

The sketch of a solution for more open network environments in Section
9.2 is insecure (once a Cookie is generated and sent once, it can be
freely replayed by an attacker during the Cookie lifetime, which defeats
the authorization requirement of the convert protocol).  Either fix it
or remove it entirely.

Please resolve the internal inconsistency in Section 6.2.4 which says
that TCP option Kind 0 MUST NOT appear in the list but then goes on to
say that the list is padded with zeros to a 32-bit boundary.  (There is
no listed requirement that the options are listed in any given order,
which would be needed to assign a boundary between "listed options" and
"padding".)

Why do we need the Cookie TLV at all if the underlying local network
supplies all the authentication and authorization that the protocol
needs?

Section 1.2 says that the Convert Protocol "is an application-layer
protocol which uses a dedicated TCP port number", but the IANA request
in Section 10.1 is for a service name without fixed port number.

[Ballot comment]
Section 1.1

  scheme can be applied independently on clients and servers.  Other
  improvements such as Selective Acknowledgments [RFC2018] or large
  windows [RFC7323] require a new TCP option or to change the semantics
  of some fields in the TCP header.  These modifications must be
  deployed on both clients and servers to be actually used on the
  Internet.  Experience with the latter TCP extensions reveals that
  their deployment can require many years.  Fukuda reports in

Do we want to say "the latter" or "the latter class of"?

  Timestamps.  [ANRW17] describes measurements showing that TCP Fast
  Open (TFO) [RFC7413] is still not widely deployed.

Perhaps people are turned off by its privacy properties or lack
confidence that their data can tolerate replay?  This is not the most
compelling example of a TCP feature that everyone should be using...

  More recently, 5G bonding experimentation has been conducted into
  global range of the incumbent 4G (LTE) connectivity using newly
  devised clients and a Multipath TCP proxy.  Even if the 5G and the 4G
  bonding relying upon Multipath TCP increases the bandwidth, it is as

nit: the grammar is not right here; either "to increase" or "reliance
upon", depending on the intended meaning, I think.

  mobile core.  In order to handle URLLC (Ultra Reliable Low Latency
  Communication) for the next generation mobile network, Multipath TCP
  and its proxy mechanism such as the one used to provide Access
  Traffic Steering, Switching, and Splitting (ATSSS) must be optimized
  to reduce latency [TS23501].

There are a lot of missing steps of reasoning here if we want to claim
that this is a technical fact vs. marketing material.

Section 1.2

  The Convert Protocol provides 0-RTT (Zero Round-Trip Time) conversion
  service since no extra delay is induced by the protocol compared to
  connections that are not proxied.  Particularly, the Convert Protocol
  does not require extra signaling setup delays before making use of
  the conversion service.  The Convert Protocol does not require any

In tightly controlled network environments where MAC can be assumed to
provide sufficient authentication, authorization, and access-control
functionality to meet the security needs of the proxy protocol; this
cannot hold when additional mutual authentication schemes are required,
as envisioned in Section 9.2

  The Transport Converter adheres to the main principles drawn in
  [RFC1919].  In particular, a Transport Converter achieves the

Er, which principles are those?  RFC 1919 is a 35-page document
entitiled "Classical versus Transparent IP proxies" that facially seems
to be a  comparison and not a declaration of guiding principles.

  The main advantage of network-assisted conversion services is that
  they enable new TCP extensions to be used on a subset of the path
  between endpoints, which encourages the deployment of these

If those are the extensions that the conversion-service provider is
interested in.  Are other extensions blocked due to inactivity on the
part of the provider?

Section 2

  destination.  In today's Internet, latency is a important metric and
  various protocols have ben tuned to reduce their latency

nit: s/ben/been/  "Please don't tune me!"

Section 4.1

  A connection can be initiated from both sides of the Transport
  Converter (Internet-facing interface, customer-facing interface).

How does the internet-facing-initiated case work?  Does the client have
to register?

  Transport Converters can be operated by network operators or third
  parties.  Nevertheless, this document focuses on the single

I'm not convinced that the present document actually describes how to
use a third-party-run transport converter in a secure fashion.

  A Client is configured, through means that are outside the scope of
  this document, with the names and/or the addresses of one or more
  Transport Converters and the TCP extensions that they support.  The

Using names rather than addresses adds a "secure DNS" requirement to the
existing assumptions of local-network security.

  connections.  This encourages the deployment of new TCP extensions
  until they are widely supported by servers, in particular.

This document has not yet shown me much to indicate that transparent
converter implementors are more incentivized to implement new TCP
extensions than third-party server operators are.

  Similar to SOCKS, the architecture does not interfere with end-to-end
  TLS connections [RFC8446] between the Client and the Server
  (Figure 3).  In other words, end-to-end TLS is supported in the

Why is TLS specifically noteworthy?  Does this not apply to all
higher-level protocols?

  It is out of scope of this document to elaborate on specific
  considerations related to the use of TLS in the Client-Converter
  connection leg to exchange Convert messages (in addition to the end-
  to-end TLS connection).

Because that can't be done in 0-RTT in the general case?

Section 4.2

  Server, without experiencing an extra delay.  The Transport Converter
  waits until the receipt of the confirmation that the Server agrees to
  establish the connection before confirming it to the Client.

nit: I suggest clarifying the antecedent of "it".

  that SYN.  The Transport Converter receives this SYN because it is,
  for example, on the path between the remote host and the Client or it
  provides address sharing service for the Client.  If the check fails,

Is there a reference for "address sharing service"?

  As discussed in [RFC7413], such change to TCP semantic raises two
  issues.  First, duplicate SYNs can cause problems for some
  applications that rely on TCP.  Second, TCP suffers from SYN flooding

Is it really best to say "some applications" when the onus to prove
replay-safety on a per-protocol basis leads to a need to assume as a
baseline that all protocols are not compatible with TFO until proven
otherwise?

  terminate the downstream connection by using FIN packets.  If the
  downstream connection terminates with the exchange of FIN packets,

Why do we have "RST segment" in the previous paragraph but "FIN packet"
here?

Section 4.3

        * Lifetime is the validity lifetime of the entry as assigned
          by the Converter.

Conceptually a lifetime is a "time to survive relative to a given
reference time".  If the reference time is "now", this lifetime would
need to be continuously updated; if not, don't we need to also store the
reference time?  (Alternately, just store the expiration time and not
the lifetime.)

Section 5.1

Do we want to say anything about (end-to-end?) MPTCP operation with the
Transport Converter in the middle?  Does it need to do anything other
than just pass packets (and maybe swap out addresses)?

Section 5.2

  address, external port number).  The external IP address and external
  port number will be then advertised using an out-of-band mechanism so
  that remote hosts can initiate TCP connections to the Client via the
  Converter.  Note that the external and internal information may be

Advertised by the Transport Converter or the Client?  (We leave it
implicit that the allocated external address/port will be communicated
back to the client by PCP.)

  is found, the Converter silently ignores the message.  If an entry is
  found, the Converter inserts an MP_CAPABLE option and Connect TLV in
  the SYN packet, rewrites the source IP address to one of its IP
  addresses and, eventually, the destination IP address and port number
  in accordance with the information stored in the mapping.  SYN+ACK

Why "eventually"?

  It is out of scope of this document to define specific Convert TLVs
  to manage incoming connections.  These TLVs can be defined in a
  separate document.

It seems a little bit of a bait-and-switch to do so, given that the
discussion of the example in Figure 6 explicitly says "the Tranport
Convert [sic] inserts a TLV message that indicates the source address
and port number of the remote host".

Section 6

  Convert messages may appear only in a SYN, SYN+ACK, or in an ACK that
  is sent shortly after the SYN+ACK.

Can we be more precise about "shortly after the SYN+ACK" (e.g.,
"acknowledging the SYN")?

Section 6.1

Was any consideration given to including a "magic string" in the fixed
header, to provide additional protection against misconfiguration about
whether Convert is to be used on a given connection?

  The Unassigned field MUST be set to zero in this version of the
  protocol.  These bits are available for future use.

But only in a future version, the way this is defined.  (That is, ruling
out using those bits as extension points within version 1.)

Section 6.2.2

  capabilities.  Assuming the Client is authorized to invoke the
  Transport Converter, the latter replies with the Supported TCP
  Extensions TLV (Section 6.2.4).

Just to confirm: based on this design, the Transport Converter currently
has nothing other than the Client IP address to use as input to this
authorization decision?

Section 6.2.5

  We distinguish two types of Connect TLV based on their length: (1)
  the Base Connect TLV has a length of 20 bytes and contains a remote

Which is to say, a Length field containing the value 5.


I'm confused about the default options semantics.  First we say that the
default options are those advertised in the Supported TCP Extensions
TLV, which would seem to imply that the converter doesn't support any
extensions that are not listed there.  But then we go on to say that for
an Extended Connect TLV, the options contained in the TLV are
*additional* options that are *added* to the default set of options ...
but only if the converter supports those options.  But if it supports an
option, wouldn't it already be in the default list, since the default
list is the list of supported options?  The way it's currently worded,
the extended connect TLV seems only useful for specifying precise values
for options that take a value, but not for adding entirely new options.

Section 6.2.6

  by the Server in the SYN+ACK packet.  A Transport Converter MUST
  return this TLV if the Client sent an Extended Connect TLV and the
  connection was accepted by the server.

Is the converter allowed to return this option if a basic connect was
used?  Should the converter always attempt to return this option?

Section 6.2.7

  the Client.  This Cookie can be configured on the Client by means
  that are outside of this document or provided by the Transport
  Converter as follows.

[But not as immediately follows; there's other content in between.]

Section 6.2.8

  An Error TLV can be included in the SYN+ACK or an ACK sent shortly
  after the SYN+ACK.

[same comment about "shortly after"]

      encoded in 8 bits.  The list of supported versions should be
      padded with zeros to end on a 32 bits boundary.

"should be"?  It's a protocol violation to not do something to make it
end on a 32-bit boundary, and putting anything other than zero is liable
to cause the peer to make bad assumptions, so this seems pretty
mandatory to me.

      Upon receipt of this error code, the remote peer (e.g., Client)
      checks whether it supports one of the versions returned by the
      peer.  The highest common supported version MUST be used by the
      remote peer in subsequent exchanges with the peer.

There doesn't seem to be any protection against version downgrade (e.g.,
by MITM) in this exchange.

      To ease troubleshooting, the value field MUST echo the received
      message shifted by one byte to keep to original alignment of the
      message.

I'm not sure what's meant by this "shifted" language is going to be
clear to all readers.  (Occurs multiple times.)

  o  Not Authorized (32): This error code indicates that the Transport
      Converter refused to create a connection because of a lack of
      authorization (e.g., administratively prohibited, authorization
      failure, invalid Cookie TLV, etc.).  The Value field MUST be set

invalid or missing, IIUC.

  o  Unsupported TCP Option (33): A TCP option that the Client
      requested to advertise to the final Server cannot be safely used.

Why the mismatch between "unsupported" and "cannot be safely used"?

Section 7.6

  types of Connect TLV.  If such a Transport Converter receives a
  Connect TLV with the TCP Fast Open cookie option that does not
  contain a cookie, it MUST add an empty TCP Fast Open cookie option in
  the SYN sent to the remote server.  If such a Transport Converter
  receives a Connect TLV with the TCP Fast Open cookie option that
  contains a cookie, it MUST copy the TCP Fast Open cookie option in
  the SYN sent to the remote server.

Just to check: we don't need to specify any additional behavior for the
response (e.g., to give the client the cookie from the server), since
that falls out naturally from the requirement to send the Extended TCP
Header TLV?

Section 7.7

  A Transport Converter MUST NOT advertise the TCP-AO option (Kind=29)
  in the Supported TCP Extensions TLV.  If a Transport Converter
  receives a Connect TLV that contains the TCP-AO option, it MUST
  reject the establishment of the connection with error code set to
  "Unsupported TCP Option", except if the TCP-AO-NAT option is used.

Perhaps a reminder that, since TCP-AO-NAT is Experimental, such usage is
not currently defined and must be specified by some other document
before it can be used, would be in order?

Section 9

An implementation needs to check that the TLVs are properly framed
within the boundary indicated by the Total Length in the fixed header.

Section 9.1

  processes.  As such, it MUST be protected as a core IP router (e.g.,
  [RFC1812]).

nit: I don't think the grammar is quite right here; maybe "as protected
as" or "protected as if it was".

  This document assumes that all network attachments are managed by the
  same administrative entity.  Therefore, enforcing anti-spoofing
  filters at these network ensures that hosts are not sending traffic
  with spoofed source IP addresses.

Until some network infrastructure equipment gets compromised.  (That is
to say "ensures" may be stronger language than is merited.)

Section 9.2

  The Convert Protocol is intended to be used in managed networks where
  end hosts can be identified by their IP address.

End hosts can always be identified by their IP address in any network
... subject to spoofing.  Perhaps you mean to say "securely identified"?

Section 9.4

I'm confused why we're talking about an illegitimate converter being
possible given that we assume the network is secure.

Section 9.5

  The operator that manages the various network attachments (including
  the Transport Converters) can enforce authentication and
  authorization policies using appropriate mechanisms.  For example, a

I suggest "has various options for enforcing authentication and
authorization policies"; the current language could be misread as saying
that such enforcement is optional.

  o  The network provider may enforce a policy based upon Access
      Control Lists (ACLs), e.g., at a Broadband Network Gateway (BNG)
      to control the hosts that are authorized to communicate with a
      Transport Converter.  These ACLs may be installed as a result of
      RADIUS exchanges, e.g., [I-D.boucadair-radext-tcpm-converter].
      This method does not require any interaction with the Transport
      Converter for authorization matters.

  o  A device that embeds a Transport Converter may also host a RADIUS
      client that will solicit an AAA server to check whether
      connections received from a given source IP address are authorized
      or not [I-D.boucadair-radext-tcpm-converter].

These both seem to require that the network has strong anti-spoofing
protections in place.

Section 11.1

It's not entirely clear that RFC 6978 needs to be normative, given that
we explicitly do *not* include support for that protocol in this
document (shunting non-standards-track tcp option support to other
documents).

Section 11.2

RFC 1919 might be normative if I had a better understanding of what we
wanted from it (see above).

I'm surprised that RFC 2782 isn't normative given that SRV discovery
seems like the only defined way to discover the port number of the
convert service.

[Ballot discuss]
** Deployed without constraints, there would be a number of concerning attacks given this protocol’s design.  Christian Huitema’s SecDir review (thank you!) notes some of them.  Helpfully, this draft presents various restrictive scoping to mitigate these attacks under certain circumstances:

(a) Section 4.1. Transport Converters can be operated by network operators or third parties.  Nevertheless, this document focuses on the single administrative deployment case where the entity offering the connectivity service to a client is also the entity which owns and operates the Transport Converter.

(b) Section 9.1. Furthermore, ingress filtering policies MUST be enforced at the network boundaries [RFC2827].

(c) Section 9.2. The Convert Protocol is intended to be used in managed networks where end hosts can be identified by their IP address.

(d) Section 9.2.  Stronger mutual authentication schemes MUST be defined to use the Convert Protocol in more open network environments.

Unfortunately, the protocol mechanism to operate outside of these bounds is in scope because (a) and (c) include no normative language.  For example, this document doesn’t address converters operated by third parties but it explicitly allows for their possibility with no discussion of the impact.

As this is an experimental document where implementation experience likely is needed for refinement, could a compromise be found with an applicability statement that shrinks the threat model and provide better normative guidance.  For example (paraphrasing):

Applicability statement: Transport Converters MUST only be deployed in a single administrative domain deployment model.  The entity offering the connectivity service to a client MUST also be entity which owns and operates the Transport Converter, with no transit over a third-party network.

For the Security Considerations: The Convert Protocol is RECOMMENDED to be used in a managed network where end hosts can be identified by their IP address.  If such control is not exerted and there is a more open network environment, a strong mutual authentication scheme MUST be defined to use the Convert Protocol.

** Section 9.1.  Per “Given its function and its location in the network, a Transport Converter has access to the payload of all the packets that it processes.”, it’s a per more than that.  It is in a position to observe all packets, so that’s payload, meta-data and the ability to profile and conduct traffic analysis.  Perhaps something on the order of “Given its function and location in the network, a Transport Convert is in a position to observe all packets, to include payloads and meta-data; and has the ability to profile and conduct traffic analysis of user behavior”.

** Section 9.1.  Per “As such, it MUST be protected as a core IP router (e.g., [RFC1812])”, no disagreement on the need to protect this router.  However, what exact practices are being suggested?  Given the RFC1812, reference, what specific sections apply?

[Ballot comment]
** Section 1.2. Given that Section 4.1. outlines that the architecture consists of clients, converter and servers, the language in the list following “In particular, a Transport Converter achieves the following :” might benefit from consistency (i.e., final target server vs. server; and server vs. converter)

** Section 6.2.5.  Per “Upon reception of an Extended Connect TLV, a Transport Converter first checks whether it supports the TCP Options listed in the 'TCP Options' field.  If not, it returns an error message (Section 6.2.8).”, what error does it return?

** Section 9.1  Per “The Transport Converter is designed to not leak such sensitive information outside a local domain.”, can you clarify what that means.

** Editorially, the guidance in Section 9.2 and 9.5 needs to link  Section 9.2 provide an authentication/authorization solution given a certain topology, and does Section 9.5.

** Editorial Nit
-- Section 2. Typo. s/a important/an important/
-- Section 4.4.1. Typo. s/the the/the/

[Ballot discuss]
Thank you for the work put into this document. It is indeed useful to be able to deploy easily new TCP features.

Nevertheless, please find below two DISCUSSes and some non-blocking COMMENTs (and I would appreciate a response from the authors) and NITS.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

-- Section 1.2 --
A trivial one: while the title and the abstract of this document appear as quite generic, the document focus is reduced later in section 1.2 to MPTCP:
  "this
  document specifies how the Convert Protocol applies for Multipath
  TCP.  It is out of scope of this document to provide a comprehensive
  list of all potential conversion services. "
While I do not mind having a focus on MPTCP only, I would strongly suggest to reflect this focus in the title and in the abstract (the current filename is correct).

-- Section 6.2.8 --
I appreciate that this is an experimental document, but, having only 2 occurrences of ICMP in the whole document and no real "how to process" TLV "Destination Unreachable"... and the payload of this TLV having only the code without the offending packet will probably make Path MTU discovery (and other mechanisms) impossible.

While I am not a transport expert, I believe that this aspect needs to be described in this document.

[Ballot comment]
Here are some COMMENTs
-- Section 1.2 --
Is the benefit of a transport proxy only for the clients as written in the 1st paragraph? It was probably the case for the original MPTCP proxy but what about other TCP extensions?


-- Section 4.1 --
While the difference "(Internet-facing interface, customer-facing interface)" will probably represent the vast majority of use cases, I wonder whether there will always be a single Internet-facing ? Could probably be 0 or 2 in some use cases... Suggest to remove this part of the text.

-- Section 6.1 --
Please state the usual wording about "unassigned" field: it must be ignored by the receiver.

Adding some explanations on why version 0 is reserved but cannot be used would be welcome.

-- Section 6.2.5 --
Can the "remote peer IP address" be a link-local address ?

== NITS ==

-- Section 1.1 (and possibly others) --
Please use a consistent means of introducing acronyms, cfr URLLC and ATSSS ;-)

-- Section 4.2 ---
The use of "regular TCP packets" makes me wonder whether the authors think that MPTCP uses "irregular TCP packets"... The use of 'regular' seems a little weird here but I am not a native English speaker.

-- Section 4.3 --
The caption below figure 7 ends with "(TCP)" that is not the acronym of "Transport Session Entry". Is it expected ?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-tcpm-converters-16. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete.

First, in the Service Name and Transport Protocol Port Number Registry located at:

https://www.iana.org/assignments/service-names-port-numbers/

a single, new service name is to be registered based on the following template:

Service Name: convert
Port Number: N/A
Transport Protocol(s): TCP
Description: 0-RTT TCP Convert Protocol
Assignee: IESG
Contact: IETF Chair
Reference: [ RFC-to-be ]

Second, a new registry page is to be created on the IANA Matrix called the TCP Convert Protocol (Convert) Parameters registry page. The reference for the new registry page will be [ RFC-to-be ].

Third, a new registry is to be created called the Convert Versions registry. The new registry will be located on the registry page created by the second IANA action above. The registry will be managed via IETF Review as defined by RFC 8126.

There are initial registrations in the new registry as follows:

+---------+----------------------------------+-------------+
| Version | Description | Reference |
+---------+----------------------------------+-------------+
| 0 | Reserved by this document |[ RFC-to-be ]|
| 1 | Assigned by this document |[ RFC-to-be ]|
+---------+----------------------------------+-------------+

IANA QUESTION --> Would it perhaps be better if the Descriptions for the two version codes would be "Reserved" and "Assigned by [ RFC-to-be ]" ??

Fourth, a new registry is to be created called the Convert TLVs registry. The new registry will be located on the registry page created by the second IANA action above.

The new registry will have the following assignment procedure (based on RFC8126):

The values in the range 1-127 can be assigned via IETF Review.
The values in the range 128-191 can be assigned via Specification Required.
The values in the range 192-255 are reserved for Private Use.

There are initial registrations in the new registry as follows:

+---------+---------------------------------+-------------+
| Code | Name | Reference |
+---------+---------------------------------+-------------+
| 0 | Reserved |[ RFC-to-be ]|
| 1 | Info TLV |[ RFC-to-be ]|
| 2-9 | Unassigned | |
| 10 | Connect TLV |[ RFC-to-be ]|
| 11-19 | Unassigned | |
| 20 | Extended TCP Header TLV |[ RFC-to-be ]|
| 21 | Supported TCP Extension TLV |[ RFC-to-be ]|
| 22 | Cookie TLV |[ RFC-to-be ]|
| 23-29 | Unassigned | |
| 30 | Error TLV |[ RFC-to-be ]|
| 31-191 | Unassigned | |
| 192-255 | Reserved for Private Use |[ RFC-to-be ]|
+---------+---------------------------------+-------------+

Fifth, a new registry is to be created called the Convert Errors registry. The new registry will be located on the registry page created by the second IANA action above.

A note will be placed on the registry indicating the four types of convert errors as follows:

Note: Four types of conver errors are defined; the following ranges are reserved for each of these types:

o Message validation and processing errors: 0-31
o Client-side errors: 32-63
o Transport Converter-side errors: 64-95
o Errors caused by destination server: 96-127

The new registry will have the following assignment procedure (based on RFC8126):

0-127: Values in this range are assigned via IETF Review.
128-191: Values in this range are assigned via Specification Required.
192-255: Values in this range are reserved for Private Use.

There are initial registrations in the new registry as follows:

+-------+------+-----------------------------+-------------+
| Error | Hex | Description | Reference |
+-------+------+-----------------------------+-------------+
| 0 | 0x00 | Unsupported Version |[ RFC-to-be ]|
| 1 | 0x01 | Malformed Message |[ RFC-to-be ]|
| 2 | 0x02 | Unsupported Message |[ RFC-to-be ]|
| 3 | 0x03 | Missing Cookie |[ RFC-to-be ]|
| 4-31 | | Unassigned | |
| 32 | 0x20 | Not Authorized |[ RFC-to-be ]|
| 33 | 0x21 | Unsupported TCP Option |[ RFC-to-be ]|
| 34-63 | | Unassigned | |
| 64 | 0x40 | Resource Exceeded |[ RFC-to-be ]|
| 65 | 0x41 | Network Failure |[ RFC-to-be ]|
| 66-95 | | Unassigned | |
| 96 | 0x60 | Connection Reset |[ RFC-to-be ]|
| 97 | 0x61 | Destination Unreachable |[ RFC-to-be ]|
| 98-255| | Unassigned | |
+-------+------+-----------------------------+-------------+

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-02-28):

From: The IESG
To: IETF-Announce
CC: tcpm@ietf.org, Michael Scharf , michael.scharf@hs-esslingen.de, ietf@kuehlewind.net, draft-ietf-tcpm-converters@ietf.org, tcpm-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (0-RTT TCP Convert Protocol) to Experimental RFC


The IESG has received a request from the TCP Maintenance and Minor Extensions
WG (tcpm) to consider the following document: - '0-RTT TCP Convert Protocol'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-02-28. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies an application proxy, called Transport
  Converter, to assist the deployment of TCP extensions such as
  Multipath TCP.  A Transport Converter may provide conversion service
  for one or more TCP extensions.  The conversion service is provided
  by means of the TCP Convert Protocol (Convert).

  This protocol provides 0-RTT (Zero Round-Trip Time) conversion
  service since no extra delay is induced by the protocol compared to
  connections that are not proxied.  Also, the Convert Protocol does
  not require any encapsulation (no tunnels, whatsoever).

  This specification assumes an explicit model, where the Transport
  Converter is explicitly configured on hosts.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tcpm-converters/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3616/

1. Summary

The document shepherd is Michael Scharf. The responsible Area Director is Mirja Kuehlewind.

This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. This proxy is designed to avoid inducing extra delay when involved in a network-assisted connection (that is, 0-RTT). This specification assumes an explicit model, where the proxy is explicitly configured on hosts. The proxy can be installed in managed networks by a network operator, for instance to help the deployment of Multipath TCP.

While Multipath TCP is an important use case, the Convert Protocol can actually be used for several TCP extensions. As the protocol is highly related to TCP standards and not specific to Multipath TCP, it was decided to home this document in the TCPM working group. The TCPM working group requests publication as Experimental document because the protocol targets controlled environments in which all network attachments are managed by the same administrative entity.


2. Review and Consensus

TCPM usually deals with end-to-end TCP extensions, not with proxies. A number of active TCPM contributors also participate in the MPTCP working group, and they have been the drivers of most of the TCPM discussions.

The document has been presented and discussed repeatedly in TCPM and as a result the protocol has changed several times. One frequently discussed design choice is whether and how to use TCP Fast Open (TFO). Appendix C explains the rationale for the final solution. There have also been some discussions whether such a proxy is really useful and needed. Some few contributors to the working group were not convinced by the MPTCP use case. During WGLC, Philip Eardley (chair of the MPTCP WG) has performed a comprehensive review, which was subsequently addressed in a number of document updates. The shepherd has reviewed the document before WGLC and verified that all WGLC comments are addressed. In addition to that, several contributors from vendors and network operators have explicitly expressed their support before and during WGLC. It has also been mentioned that the protocol is of interest to 3GPP. In TCPM, there is very strong but not unanimous support for publication as experimental document.

There is at least one known implementation: Tessares has an open-sourced a library (https://github.com/Tessares/libconvert) and a closed-source Hybrid Access Gateway (HAG) that uses this library directly to act as an MPTCP Converter. Korea Telekom (KT) has reported to TCPM the results of a PoC using these implementations (see https://tessares.pr.co/181810-kt-tessares-successfully-test-5g-low-latency-multi-radio-access-technology-in-a-commercial-5g-network). Other vendors have also expressed interest, but there is no publicly known second implementation.


3. Intellectual Property

Each author has confirmed conformance with BCP 78/79.

There is an IPR disclosure related to the document: https://datatracker.ietf.org/ipr/3616/

The TCPM working group is aware of the IPR disclosure and the chairs have explicitly informed the working group about the IPR. Also, there has been an earlier disclosure (https://datatracker.ietf.org/ipr/2726/drafts) on a predecessor document, which was originally discussed in the MPTCP WG. There have been no comments or concerns in TCPM regarding the IPR.

The document describes an experimental protocol that is currently mostly of interest to MPTCP deployments in controlled environments. It is possible that the TCPM working group would be more concerned about IPR for a standards-track RFC.


4. Other Points

The document requests a TCP port number and creates IANA registries for protocol parameters. There has been some discussion on the allocation policy for the registry ("IETF review" required), but no controversy. The TCPM working group only seldom deals with new IANA registries and there may not be much expertise regarding details.

1. Summary

The document shepherd is Michael Scharf. The responsible Area Director is Mirja Kuehlewind.

This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. This proxy is designed to avoid inducing extra delay when involved in a network-assisted connection (that is, 0-RTT). This specification assumes an explicit model, where the proxy is explicitly configured on hosts. The proxy can be installed in managed networks by a network operator, for instance to help the deployment of Multipath TCP.

While Multipath TCP is an important use case, the Convert Protocol can actually be used for several TCP extensions. As the protocol is highly related to TCP standards and not specific to Multipath TCP, it was decided to home this document in the TCPM working group. The TCPM working group requests publication as Experimental document because the protocol targets controlled environments in which all network attachments are managed by the same administrative entity.


2. Review and Consensus

TCPM usually deals with end-to-end TCP extensions, not with proxies. A number of active TCPM contributors also participate in the MPTCP working group, and they have been the drivers of most of the TCPM discussions.

The document has been presented and discussed repeatedly in TCPM and as a result the protocol has changed several times. One frequently discussed design choice is whether and how to use TCP Fast Open (TFO). Appendix C explains the rationale for the final solution. There have also been some discussions whether such a proxy is really useful and needed. Some few contributors to the working group were not convinced by the MPTCP use case. During WGLC, Philip Eardley (chair of the MPTCP WG) has performed a comprehensive review, which was subsequently addressed in a number of document updates. The shepherd has reviewed the document before WGLC and verified that all WGLC comments are addressed. In addition to that, several contributors from vendors and network operators have explicitly expressed their support before and during WGLC. It has also been mentioned that the protocol is of interest to 3GPP. In TCPM, there is very strong but not unanimous support for publication as experimental document.

There is at least one known implementation: Tessares has an open-sourced a library (https://github.com/Tessares/libconvert) and a closed-source Hybrid Access Gateway (HAG) that uses this library directly to act as an MPTCP Converter. Korea Telekom (KT) has reported to TCPM the results of a PoC using these implementations (see https://tessares.pr.co/181810-kt-tessares-successfully-test-5g-low-latency-multi-radio-access-technology-in-a-commercial-5g-network). Other vendors have also expressed interest, but there is no publicly known second implementation.


3. Intellectual Property

Each author has confirmed conformance with BCP 78/79.

There is an IPR disclosure related to the document: https://datatracker.ietf.org/ipr/3616/

The TCPM working group is aware of the IPR disclosure and the chairs have explicitly informed the working group about the IPR. Also, there has been an earlier disclosure (https://datatracker.ietf.org/ipr/2726/drafts) on a predecessor document, which was originally discussed in the MPTCP WG. There have been no comments or concerns in TCPM regarding the IPR.

The document describes an experimental protocol that is currently mostly of interest to MPTCP deployments in controlled environments. It is possible that the TCPM working group would be more concerned about IPR for a standards-track RFC.


4. Other Points

The document requests a TCP port number and creates IANA registries for protocol parameters. There has been some discussion on the allocation policy for the registry ("IETF review" required), but no controversy. The TCPM working group only seldom deals with new IANA registries and there may not be much expertise regarding details.

1. Summary

The document shepherd is Michael Scharf. The responsible Area Director is Mirja Kuehlewind.

This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. This proxy is designed to avoid inducing extra delay when involved in a network-assisted connection (that is, 0-RTT). This specification assumes an explicit model, where the proxy is explicitly configured on hosts. The proxy can be installed in managed networks by a network operator, for instance to help the deployment of Multipath TCP.

While Multipath TCP is an important use case, the Convert Protocol can actually be used for several TCP extensions. As the protocol is highly related to TCP standards and not specific to Multipath TCP, it was decided to home this document in the TCPM working group. The TCPM working group requests publication as Experimental document because the protocol targets controlled environments in which all network attachments are managed by the same administrative entity.


2. Review and Consensus

TCPM usually deals with end-to-end TCP extensions, not with proxies. A number of active TCPM contributors also participate in the MPTCP working group, and they have been the drivers of most of the TCPM discussions.

The document has been presented and discussed repeatedly in TCPM and as a result the protocol has changed several times. One frequently discussed design choice is whether and how to use TCP Fast Open (TFO). Appendix C explains the rationale for the final solution. There have also been some discussions whether such a proxy is really useful and needed. Some few contributors to the working group were not convinced by the MPTCP use case. During WGLC, Philip Eardley (chair of the MPTCP WG) has performed a comprehensive review, which was subsequently addressed in a number of document updates. The shepherd has reviewed the document before WGLC and verified that all WGLC comments are addressed. In addition to that, several contributors from vendors and network operators have explicitly expressed their support before and during WGLC. It has also been mentioned that the protocol is of interest to 3GPP. In TCPM, there is very strong but not unanimous support for publication as experimental document.

There is at least one known implementation: Tessares has an open-sourced a library (https://github.com/Tessares/libconvert) and a closed-source Hybrid Access Gateway (HAG) that uses this library directly to act as an MPTCP Converter. Korea Telekom (KT) has reported to TCPM the results of a PoC using these implementations (see https://tessares.pr.co/181810-kt-tessares-successfully-test-5g-low-latency-multi-radio-access-technology-in-a-commercial-5g-network). Other vendors have also expressed interest, but there is no publicly known second implementation.


3. Intellectual Property

Each author has confirmed conformance with BCP 78/79.

There is an IPR disclosure related to the document: https://datatracker.ietf.org/ipr/3616/

The TCPM working group is aware of the IPR disclosure and the chairs have explicitly informed the working group about the IPR. Also, there has been an earlier disclosure (https://datatracker.ietf.org/ipr/2726/drafts) on a predecessor document, which was originally discussed in the MPTCP WG. There have been no comments or concerns in TCPM regarding the IPR.

The document describes an experimental protocol that is currently mostly of interest to MPTCP deployments in controlled environments. It is possible that the TCPM working group would be more concerned about IPR for a standards-track RFC.


4. Other Points

The document requests a TCP port number and creates IANA registries for protocol parameters. There has been some discussion on the allocation policy for the registry ("IETF review" required), but no controversy. The TCPM working group only seldom deals with new IANA registries and there may not be much expertise regarding details.

1. Summary

The document shepherd is Michael Scharf. The responsible Area Director is Mirja Kuehlewind.

This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. This proxy is designed to avoid inducing extra delay when involved in a network-assisted connection (that is, 0-RTT). This specification assumes an explicit model, where the proxy is explicitly configured on hosts. The proxy can be installed in managed networks by a network operator, for instance to help the deployment of Multipath TCP.

While Multipath TCP is an important use case, the Convert Protocol can actually be used for several TCP extensions. As the protocol is highly related to TCP standards and not specific to Multipath TCP, it was decided to home this document in the TCPM working group. The TCPM working group requests publication as Experimental document because the protocol targets controlled environments in which all network attachments are managed by the same administrative entity.


2. Review and Consensus

TCPM usually deals with end-to-end TCP extensions, not with proxies. A number of active TCPM contributors also participate in the MPTCP working group, and they have been the drivers of most of the TCPM discussions.

The document has been presented and discussed repeatedly in TCPM and as a result the protocol has changed several times. One frequently discussed design choice is whether and how to use TCP Fast Open (TFO). Appendix C explains the rationale for the final solution. During WGLC, Philip Eardley (chair of the MPTCP WG) has performed a comprehensive review, which was subsequently addressed in a number of document updates. The shepherd has reviewed the document before WGLC and verified that all WGLC comments are addressed. In addition to that, several contributors from vendors and network operators have explicitly expressed their support before and during WGLC. It has also been mentioned that the protocol is of interest to 3GPP. In TCPM, there is unanimous support for publication as experimental document.

There is at least one known implementation: Tessares has an open-sourced a library (https://github.com/Tessares/libconvert) and a closed-source Hybrid Access Gateway (HAG) that uses this library directly to act as an MPTCP Converter. Korea Telekom (KT) has reported to TCPM the results of a PoC using these implementations (see https://tessares.pr.co/181810-kt-tessares-successfully-test-5g-low-latency-multi-radio-access-technology-in-a-commercial-5g-network). Other vendors have also expressed interest, but there is no publicly known second implementation.


3. Intellectual Property

Each author has confirmed conformance with BCP 78/79.

There is an IPR disclosure related to the document: https://datatracker.ietf.org/ipr/3616/

The TCPM working group is aware of the IPR disclosure and the chairs have explicitly informed the working group about the IPR. Also, there has also been an earlier disclosure (https://datatracker.ietf.org/ipr/2726/drafts) on a predecessor document, which was originally discussed in the MPTCP WG. There have been no comments or concerns in TCPM regarding the IPR.

The document describes an experimental protocol that is currently mostly of interest to MPTCP deployments in controlled environments. It is possible that the TCPM working group would be more concerned about IPR for a standards-track RFC.


4. Other Points

The document requests a TCP port number and creates IANA registries for protocol parameters. There has been some discussion on the allocation policy for the registry ("IETF review" required), but no controversy. The TCPM working group only seldomly deals with new IANA registries and there may not be much expertise regarding details.