Subject: Re: [tcpm] IANA TCP options registry ...

From: Alfred Hönes <[email-masked]>
Date: Mon, 8 Mar 2010 00:16:39 +0100 (MEZ)

[ resending after error correction ... ]

Christian,
thanks for the interesting information at the end of your message:

> The bubba and skeeter options were reserved by Stev Knowles, then
> working at FTP Software.  The options are parts of an encryption system.
> The documentation for that system was not made publicly available.
> According to Stev, the options were actually deployed and used,
> certainly until 2000, and possibly later.

The latter comes a bit to surprise.
When I sent out my questionaires on TCP options in 2006, I tried
hard to follow all traces of bouncing IANA 'people' references and
emailed many folks.
The most concrete information I could get wrt Skeeter & Bubba was a
3rd-party statement that Stev Knowles did most likely not want to
be reminded of that misfortune, and, although my inquiry had been
forwarded to him, it was unsure whether he would want to respond...
... and so it happened in January 2007.

The only internet-history posting I had found those days (and which
Google still finds as the only one) was (by one "co-conspirator"):
<http://www.postel.org/pipermail/internet-history/2001-November/000071.html>
This does not match very well your alleged report of deployment.

An interesting document supporting the impression of failure
is the Dissertation of Simson L. Garfinkel (MIT, May 2005),
available at <http://simson.net/thesis/>.
Section 6.1 there gives some insight.

  "    ...  The project was abandoned for two reasons.  First, an
   engineer at FTP thought that it would be wasteful to have computers
   calculate large prime numbers for every TCP connection (none of
   those working on the project had any training in cryptography ... ).
   Second, people in the company who understood security critizised the
   solution because it was susceptible to the man-in-the-middle attack.
   Today the Bubba and Skeeter TCP options with the cryptic reference
   to "[Knowles]" in the Internet's list of Assigned Numbers RFCs (e.g.,
   RFC 1700 [RP94]) are the only remnants of the project.
  "

For more, please see  <http://simson.net/thesis/pki2.pdf> .

The factual lack of disclosure of information on the design, until
today, seems to support the assumption of failure and non-deployment.

According to my paper notes (would need to go to backups for more ...),
I had mentioned the difficulty to get information on Skeeter/Bubba,
and the pointer to this dissertation, in my original message in
January 2007, but nobody followed up.

The basic work in 2006/2007 had been done, among other goals, to
get an overview of whether the idea to include _partial_ TCP option
coverage into the proposed successors to the TCP MD5 option made
any sense at all.  It turned out that all TCP options for which
I could get information were strictly end-to-end (as expected)
and needed integrity protection.

When I eventually found the time to compile all results and posted
the "annotated_tcp-parameters.20070216" paper to TCPM, again no
feedback was received.

Since I now see interest in maintaining more reliable information,
about TCP options, the related documentation, and their relevance
in the current Internet, I will endeavor to write up the information
in an I-D (it will need a few updates).
But due to current private&business time restrictions, please be
patient.

Any more information would be welcome, in particular on Option #24.
That was the other 'hard stuff' those days.

For Option #26, I had received enough information from the
registrant, and I hope to not forestall Steve in stating that
the entry in the registry is kept for the historical record
of an academic experiment.

For Option #18 (Trialer Checksum), it would also be interesting
to get more information on its fate.

Some WGs maintain web pages about the related IETF protocols.
One possibility would be to maintain a page on the IETF tools
servers linked to the TCPM WG wiki and/or the WG charter page.

draft-ogud-iana-maintenance-words should be considered as a base
for adding 'status' information to other IANA registries as well.

>
> -----Original Message-----
> From: [email-masked] On Behalf Of Fernando Gont
> To: Joe Touch
> Cc: [email-masked]; Alfred Hönes; [email-masked]
> Sent: Friday, March 05, 2010 2:51 PM
> Subject: Re: [tcpm] IANA TCP options registry
>
> Hi, Joe,
>
>>> The IANA TCP options registry
>>> (http://www.iana.org/assignments/tcp-parameters/) lacks of valuable
>>> information. e.g., you need to figure out by yourself what the "Bubba"
>>> option is (or what it is used for), and missing references (e.g., for
>>> options #20 through #23 are missing).
>>
>> Some of that information might be solicited found elsewhere, e.g.,
>> [email-masked] ;-)
>
> Yes, but other than that, one should be able to know if the option was
> ever deployed, whether it's obsolete, etc.
>
> e.g., if I wanted to design a firewall policy, I might need that
> information.
>
>
>>> What'd be the procedure to have Alfred's registry replace the current
>>> one? (i.e., have most/all of the information there make it into the
>>> "official" IANA registry).
>>
>> Ask IANA ([email-masked]). I don't think this really requires any
>> particular policy stuff - some of that info isn't there because it just
>> wasn't known when the page was created.
>
> Ok. I've just e-mailed them. Let's see what happens.

Early in 2007, IANA received a request to update references.
In 2008, I received a (kinda broadcast) message that they had lost
record of many requests, and the recipients should please submit
their requests again.  That wasn't very encouraging, and after
already having spent a lot of time before (in vain) for getting
other registries fixed that contain(ed) material obviously
contradicting the referenced RFCs, I didn't.  :-)

> Thanks!
> Kind regards,
> --
> Fernando Gont

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

P.S.:
  I'd appreciate if the DNS servers in Redmont would stop to
  blackhole DNS queries from the random source port numbers (!=53)
  that our NAT/Firewall access router inserts in (query) packets
  originating on our local recursive DNS resolver, so that messages
  could be delivered using normal, DNS-based mail routing.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 8 Mar 2010 01:54:08 +0000

Note that the idea behind these two options is actually quite interesting. The design appeared to be, do a Diffie-Hellman exchange as part of TCP synchronization, and then use the key to protect the TCP data. There is a possibility of man-in-the-middle attack, but that can be mitigated by end-to-end authentication, especially if the end-to-end authentication is seeded with the TCP session key.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, March 07, 2010 3:17 PM
To: Christian Huitema; [email-masked]
Subject: Re: [tcpm] IANA TCP options registry ...

Christian,

> Cc: [email-masked]; Alfred HÎnes; [email-masked]

> Kind regards,

Kind regards,
  Alfred HÎnes.

-- 

P.S.:

_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Mon, 08 Mar 2010 10:34:28 -0800

Alfred,

Alfred ? wrote:
...
> for adding 'status' information to other IANA registries as well.

This document confuses IANA with a compliance organization.

IANA maintains registries, and provides information on the status of
those registrations where used to maintain the registry.

A compliance site may be useful, but I don't think it's in IANA's
charter. *Some* of the words in this doc may be useful, but need to come
out of some assessment of a standard - it's not possible to look at
individual components of a standard and make these decisions.

The two questions that result are:
	- who makes the assessments in the doc?
	- where is that info maintained?

We have had docs that occasionally provide roadmaps in a general sense,
but this is much deeper into what a compliance organization would
recommend for implementations, and seems out of scope for even the
IETF, AFAICT.	

Joe

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 1 Apr 2010 06:47:09 +0100

Hi Alfred et al,

Out of curiousity, does anyone know about the to-be assigned option number(s ?) for RFC 5690 (AckCC http://tools.ietf.org/html/rfc5690).

Are there two option numbers proposed for that RFC, or will a single option (with the length field being the necessary denominator between AckCC control permitted and AckCC Ratio) suffice?

Best regards,

Richard Scheffenegger
Field Escalation Engineer
NetApp Global Support 
NetApp
+43 1 3676811 3146 Office (2143 3146 - internal)
+43 676 654 3146 Mobile
www.netapp.com 
Franz-Klein-Gasse 5
1190 Wien 

> From: Alfred HÎnes [mailto:[email-masked]] 
> Sent: Montag, 8. März 2010 00:17
> To: [email-masked]; [email-masked]
> When I sent out my questionaires on TCP options in 2006, I 
> tried hard to follow all traces of bouncing IANA 'people' 
> references and emailed many folks.
> The most concrete information I could get wrt Skeeter & Bubba 
> was a 3rd-party statement that Stev Knowles did most likely 
> not want to be reminded of that misfortune, and, although my 
> inquiry had been forwarded to him, it was unsure whether he 
> would want to respond...
> The only internet-history posting I had found those days (and 
> which Google still finds as the only one) was (by one 
> "co-conspirator"):
> The factual lack of disclosure of information on the design, 
> until today, seems to support the assumption of failure and 
> non-deployment.
> 
> 
> According to my paper notes (would need to go to backups for 
> more ...), I had mentioned the difficulty to get information 
> on Skeeter/Bubba, and the pointer to this dissertation, in my 
> original message in January 2007, but nobody followed up.
> 
> 
> The basic work in 2006/2007 had been done, among other goals, 
> to get an overview of whether the idea to include _partial_ 
> TCP option coverage into the proposed successors to the TCP 
> MD5 option made any sense at all.  It turned out that all TCP 
> options for which I could get information were strictly 
> end-to-end (as expected) and needed integrity protection.
> 
> When I eventually found the time to compile all results and 
> posted the "annotated_tcp-parameters.20070216" paper to TCPM, 
> again no feedback was received.
> 
> Since I now see interest in maintaining more reliable 
> information, about TCP options, the related documentation, 
> and their relevance in the current Internet, I will endeavor 
> to write up the information in an I-D (it will need a few updates).
> But due to current private&business time restrictions, please 
> be patient.
> 
> For Option #18 (Trialer Checksum), it would also be 
> interesting to get more information on its fate.
> 
> 
> draft-ogud-iana-maintenance-words should be considered as a 
> base for adding 'status' information to other IANA registries as well.
> 
> 
> >
> >>> option is (or what it is used for), and missing references (e.g., 
> >>> for options #20 through #23 are missing).
> >>
> >>> What'd be the procedure to have Alfred's registry replace the 
> >>> current one? (i.e., have most/all of the information 
> there make it 
> >>> into the "official" IANA registry).
> >>
> >> particular policy stuff - some of that info isn't there because it 
> >> just wasn't known when the page was created.
> >
> In 2008, I received a (kinda broadcast) message that they had 
> lost record of many requests, and the recipients should 
> please submit their requests again.  That wasn't very 
> encouraging, and after already having spent a lot of time 
> before (in vain) for getting other registries fixed that 
> contain(ed) material obviously contradicting the referenced 
> RFCs, I didn't.  :-)
> 
> >
> > Thanks!
> >
> > Kind regards,
> > --
> > Fernando Gont
> 
> 
> Kind regards,
>   Alfred HÎnes.
> 
> -- 
>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 1 Apr 2010 09:26:16 +0300

Hi,

On 2010-4-1, at 8:47, Scheffenegger, Richard wrote:
> Out of curiousity, does anyone know about the to-be assigned option number(s ?) for RFC 5690 (AckCChttp://tools.ietf.org/html/rfc5690).
> 

Section 10 is pretty clear, in that RFC5690 is for limited experimentation only at this time and hence no separate option numbers will be assigned. Experimenters are supposed to use the normal TCP option numbers set aside for general experimentation (253/254) when playing with this proposal:

   No IANA action is needed at this time.  If this document was advanced
   as Experimental or Proposed Standard, then IANA would allocate the
   option numbers for the two TCP options, the ACK Congestion Control
   Permitted option, and the ACK Ratio option.  In such a case, the
   following two lines would be added to the TCP Option Numbers registry
   (maintained by IANA -- http://www.iana.org):

        Kind   Length   Meaning                             Reference
        ----   ------   ---------------------------------   -----------
        TBD1       2    ACK Congestion Control Permitted    [RFCXXXX]
        TBD2       3    ACK Ratio                           [RFCXXXX]

   In the absence of TCP option numbers allocated by IANA, experimenters
   may use the TCP Option Numbers set aside for Experimentation in RFC
   4727 [RFC4727].  As stressed in Section 1 of RFC 3692 [RFC3692], the
   TCP Option Numbers in the experimental range are intended for
   experimentation and testing and not for wide or general deployments;
   these option numbers could be in use by other experimentors for other
   purposes.

Lars