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

Christian Huitema <huitema@microsoft.com> Mon, 08 March 2010 01:54 UTC

Return-Path: <huitema@microsoft.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 422413A67F5 for <tcpm@core3.amsl.com>; Sun, 7 Mar 2010 17:54:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.854
X-Spam-Level:
X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B38QJ+DmBp8K for <tcpm@core3.amsl.com>; Sun, 7 Mar 2010 17:54:07 -0800 (PST)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id C8A553A67E1 for <tcpm@ietf.org>; Sun, 7 Mar 2010 17:54:07 -0800 (PST)
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 7 Mar 2010 17:54:11 -0800
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.0.639.21; Sun, 7 Mar 2010 17:54:12 -0800
Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.84]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Sun, 7 Mar 2010 17:54:10 -0800
From: Christian Huitema <huitema@microsoft.com>
To: "ah@TR-Sys.de" <ah@TR-Sys.de>, "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: [tcpm] IANA TCP options registry ...
Thread-Index: AQHKvk9dWYP69lWE2k+elrNb1QbXp5HnRq+Q
Date: Mon, 8 Mar 2010 01:54:08 +0000
Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA685E89E8@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
References: <201003072316.AAA29042@TR-Sys.de>
In-Reply-To: <201003072316.AAA29042@TR-Sys.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [tcpm] IANA TCP options registry ...
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Mar 2010 01:54:09 -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: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of ah@TR-Sys.de
Sent: Sunday, March 07, 2010 3:17 PM
To: Christian Huitema; tcpm@ietf.org
Subject: Re: [tcpm] IANA TCP options registry ...

[ 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: tcpm-bounces@ietf.org On Behalf Of Fernando Gont
> To: Joe Touch
> Cc: tcpm-chairs@tools.ietf.org; Alfred HÎnes; tcpm@ietf.org
> 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.,
>> internet-history@postel.org ;-)
>
> 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 (iana@iana.org). 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:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+

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.

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm