Subject: Re: [tcpm] draft-zimmermann-tcpm-undeployed

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 20 Oct 2014 14:38:07 +0300

On 20 Oct 2014, at 13:09, Zimmermann, Alexander <[email-masked]> wrote:

> at the IETF 90 we got some feedback from Yoshifumi and Gorry no the draft (see minutes). We incorporated those feedback in version 01. From our point of view the draft is ready. I would like to know how we proceed w/ the draft? I don’t think that we need to discuss the draft again in Honolulu.

Just wanted to check one thing: isn’t TCPMUX supported by [x]inetd implementations? It’s probably not much used, but there seem to be deployed implementations, so perhaps it isn't correct to call it obsolete? Any opinions?

Also, RFC 6013 strikes as quite recent for a “Historic” document, although I fully agree with its description in the roadmap. (I’m not against the change, just generally wondering why an independent stream RFC is approved with one status, if it is going to be changed to Historic soon after)

- Pasi

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Oct 2014 11:46:09 -0700

On 10/20/2014 4:38 AM, Pasi Sarolahti wrote:
> Just wanted to check one thing: isn’t TCPMUX supported by [x]inetd
> implementations?

It appears so, but that's the server side, depending on the services
listed in inetd.conf. The question is whether any client contacts it and
whether those clients end up connecting.

TCPMUX doesn't handle connections from unknown ports; the client has to
use TCPMUX to send the port in-band before the rest of the user data.

> It’s probably not much used, but there seem to be
> deployed implementations, so perhaps it isn't correct to call it
> obsolete? Any opinions?

I don't think it qualifies for this document. A deeper investigation of
whether there are clients that use this seems needed.

Joe

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Tue, 21 Oct 2014 09:57:47 +0000

> Am 20.10.2014 um 13:38 schrieb Pasi Sarolahti <[email-masked]>:
> 

Making something as obsolete != not deployed in implementation

Please rake a look at https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html

„Moving a document to "Historic" status requires a specific IETF-wide
Last Call and a formal action of the IESG. 

* A document is obsolete when there is a newer version that replaces it. RFC 821
is obsoleted by RFC 2821, which is, in turn, obsoleted by RFC 5321. The technology
that RFC 821 describes — SMTP — is still current technology, but the documentation
of it in RFC 821 is obsolete. 

* A document is labelled Historic when what it describes is no longer considered current:
no longer recommended for use.“

The latter point is exactly what we would like to express: no longer recommended for use

> 
> Also, RFC 6013 strikes as quite recent for a “Historic” document, although I fully agree with its description in the roadmap.

The specification (RFC 6013) is not getting any better if we wait longer.
There is no implementation in the wild available, it doesn’t follow RFC 6994 ,…

> (I’m not against the change, just generally wondering why an independent stream RFC is approved with one status,

Ask IESG. AFAIR Wes was the AD at this time ;-)

Alex

> if it is going to be changed to Historic soon after)
> 
> - Pasi
>

---

From: Pasi Sarolahti <[email-masked]>
Date: Tue, 21 Oct 2014 14:09:27 +0300

> Making something as obsolete != not deployed in implementation

Yep. But the title is "Moving Undeployed TCP Extensions to Historic…” :-)

> The latter point is exactly what we would like to express: no longer recommended for use

So why is it no longer recommended? The IESG statement also calls for explanation for the transition. rfc4614bis explains the case for the other documents pretty well, but the reasons for obsoleting TCPMUX are not given there. (it might not harm if the important explaining sentences from rfc4641bis would be shortly repeated also here for each document)

> There is no implementation in the wild available, it doesn’t follow RFC 6994 ,…

Right, it shouldn’t be hard to argue why the transition needs to be made. (but I still think it would help further evaluation steps if short reasoning was provided here)

- Pasi

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Tue, 21 Oct 2014 11:47:09 +0000

> Am 21.10.2014 um 13:09 schrieb Pasi Sarolahti <[email-masked]>:
> 
> 
> Yep. But the title is „Moving Undeployed TCP Extensions to Historic…” :-)

OK, we should fix that :-)

> So why is it no longer recommended? The IESG statement also calls for explanation for the transition.

See for example this thread: http://www.ietf.org/mail-archive/web/ietf/current/msg81410.html
(or http://marc.info/?t=137611379100002&r=1&w=2)

	Wes: „There are probably security issues“
	Joe: „There are semantics issues to; see draft-touch-tcp-portnames-00 for information“
	Bob Braden: „Indeed, TCPMUX is quite historic… it represents a Road Not Taken“

Another source is: draft-touch-tcpm-sno-02.txt

If Joe, Wes or Bob think now that we should not obsolete TCPMUX, fine by me.
I thought we reflect w/ draft-zimmermann-tcpm-undeployed their (the community)
opinion. 

> rfc4614bis explains the case for the other documents pretty well, but the reasons for obsoleting TCPMUX are not given there. (it might not harm if the important explaining sentences from rfc4641bis would be shortly repeated also here for each document)

I can do that. NP.

Personally, I do not want to submit the draft as an individual draft. Basically due to the fact
that today nobody knows how we can obsolete an RFC which comes out of the independent track.
Could we start a call of adoption on the draft? The stuff we discuss right now are quite minor
and easy to fix. I do not see a showstopper here

> Right, it shouldn’t be hard to argue why the transition needs to be made. (but I still think it would help further evaluation steps if short reasoning was provided here)

Be concrete :-) What do you have in mind?

Alex

---

From: Pasi Sarolahti <[email-masked]>
Date: Tue, 21 Oct 2014 16:32:26 +0300

(Note: this is response to Alex’ mail, but I changed the topic, because there is an important question below)

> I thought we reflect w/ draft-zimmermann-tcpm-undeployed their (the community)

Great, this is basically what I was looking for. So why not shortly summarize the security and semantics issues in the draft, to make things clear?

> and easy to fix. I do not see a showstopper here

Yes, I think we should be able to take this through tcpm fairly quickly, but according to the normal procedure. So the plan would be that unless anyone objects within next couple of weeks, we will adopt this as TCPM document, and will start a WGLC soon after. (This is not to discourage further comments, so please take a look and send comments as usual — although currently there is not much text to comment on… :-)

We don’t need presentation slot in the next meeting, unless you want to, but let’s shortly check the status in the early part of the meeting (no slides required).

So, any opinions for or against adopting this draft as outlined above?

> Be concrete :-) What do you have in mind?

As you say, RFC 6994 specifies how experimental options should be used, so it supersedes the usage in RFC 6013. We also have ongoing work on extending option space that will likely differ from what RFC 6013 has (but we are not quite there yet). The extension mechanism probably also has issues with middleboxes, as recently discussed. (roadmap says that there is no wide deployment, but RFC 6013 is Experimental, so I don’t think wide deployment is even expected. Although probably there is no ongoing experiment either.)

- Pasi

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 21 Oct 2014 09:38:31 -0400

On 10/21/2014 5:57 AM, Zimmermann, Alexander wrote:
>> (I’m not against the change, just generally wondering why an 
>> independent stream RFC is approved with one status,
> 

No, that was Lars and David :).

While there is no burning need to reclassify it, that I can see, I do
think it's sensible to do in light of other progress that this working
group has made with TFO.  As I understand it, TCPCT was largely driven
by DNSSEC and replacing T/TCP (1644), whereas TFO is more web-inspired,
but also can be used to support T/TCP-like use by other applications
and has relatively more "rough consensus and running code" behind it.

-- 
Wes Eddy
MTI Systems

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 21 Oct 2014 09:45:11 -0400

> I thought we reflect w/ draft-zimmermann-tcpm-undeployed their (the community)

Looking at:
1) the IETF mailing list threads on it
2) the handful of issues that it presents in the modern day
3) that it isn't "on by default" in widely used code, and there
   don't seem to be many/any strong use cases or advocations for
   it on the web

It seems to me that it should be historic.  There are better ways
of doing the same thing.

-- 
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Oct 2014 10:44:28 -0700

On 10/21/2014 4:47 AM, Zimmermann, Alexander wrote:
...
> I thought we reflect w/ draft-zimmermann-tcpm-undeployed their (the community)

It's a huge hole in any sort of firewall, not to mention numerous
specific attacks. I support obsoleting it, but the reason needs to be
clear - severity of vulnerability and lack of deployed clients, NOT lack
of deployed servers with this capability.

I.e., although (x)inetd understands incoming requests, unmodified user
applications can't simply change to port 1 and work; they need to send
the actual service name as user data, and I don't know of any that do that.

Joe

---

From: John Leslie <[email-masked]>
Date: Wed, 22 Oct 2014 11:36:45 -0400

Pasi Sarolahti <[email-masked]> wrote:
> 
> Yes, I think we should be able to take this through tcpm fairly quickly,
> but according to the normal procedure. So the plan would be that unless
> anyone objects within next couple of weeks, we will adopt this as TCPM
> document, and will start a WGLC soon after. (This is not to discourage
> further comments, so please take a look and send comments as usual ?
> although currently there is not much text to comment on? :-)
>...

   The draft proposes quite a number of status changes:
] 
]    The RFC Editor is requested to change the status of the following
] RFCs to Historic [RFC2026]:
] 
] o  [RFC0675] on "Specification of Internet Transmission Control
]    Program"
] 
] o  [RFC0721] on "Out-of-Band Control Signals in a Host-to-Host
]    Protocol"

   These seem _very_ Historic...

] o  [RFC0879] on "TCP Maximum Segment Size and Related Topics"

   This one seems to have been replaced by RFC 6691.

] o  [RFC1078] on "TCP port service Multiplexer (TCPMUX)"

   This 1988 document seems pretty Historic.

] o  [RFC6013] on "TCP Cookie Transactions"

   This 2011 document defined an Experimental use of option 254. IMHO
it deserves a separate writeup, either explaining the experiment results
or clearly stating the results are unknown.

   (Three years "should" be long enough for an Experiment; but we have
so many cases that have dragged on even longer.)

] The RFC Editor is requested to change the status of the following
] RFCs to Informational [RFC2026]:

    All of these are currently Status "UNKNOWN". I'm not clear on why
we want to upgrade them to "Informational". They seem to me to be
closer to "Historic"...

] o  [RFC0813] on "Window and Acknowledgement Strategy in TCP"

   1982, Status UNKNOWN...
 
] o  [RFC0814] on "Name, addresses, ports, and routes"

   1982, Status UNKNOWN...

] o  [RFC0816] on "Fault Isolation and Recovery

   1982, Status UNKNOWN...

] o  [RFC0817] on "Modularity and efficiency in protocol
]    implementation"

   1982, Status UNKNOWN...

] o  [RFC0872] on "TCP-on-a-LAN"

   1982, Status UNKNOWN...
 
] o  [RFC0896] on "Congestion Control in IP/TCP Internetworks"

   1984, Status UNKNOWN...
 
] o  [RFC0964] on "Some problems with the specification of the Military
]     Standard Transmission Control Protocol"

   1985, Status UNKNOWN...
 
--
John Leslie <[email-masked]>

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Thu, 23 Oct 2014 08:10:29 +0000

Hi John,

thanks you for looking into the draft.
Comments inline.

> Am 22.10.2014 um 17:36 schrieb John Leslie <[email-masked]>:
> 

Yes, right, but RFC 6691 only updates RFC 879. It doesn’t obsolete it.

> or clearly stating the results are unknown.

It doesn’t exist any results (AFAIK). The reference implementation was
under Linux, but Christoph Paasch removed the code a while ago from the
Kernel. Today, w/ TFO and EDO we have other (and better solutions) in place.
I don’t see the need for separate writeup. Why we cannot include the writeup
in draft-zimmermann-tcpm-undeployed? Another possibility is that EDO
obsolete RFC6013. Fine by me. In that case I push the work to Joe ;-)

> closer to „Historic"...

The reason is that bascially the algorithms in all these RFCs are
today in use. RFC0813 - RFC0817 are part of RFC1122.

>   1985, Status UNKNOWN…

I need to look in RFC 964 again. Maybe we can obsolete this one.