Re: [tcpm] IANA TCP options registry ...
"Scheffenegger, Richard" <rs@netapp.com> Thu, 01 April 2010 05:46 UTC
Return-Path: <rs@netapp.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 E015A3A6920 for <tcpm@core3.amsl.com>; Wed, 31 Mar 2010 22:46:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.969
X-Spam-Level:
X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_61=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 TWlPLrTsEgdc for <tcpm@core3.amsl.com>; Wed, 31 Mar 2010 22:46:42 -0700 (PDT)
Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 77DFB3A67EC for <tcpm@ietf.org>; Wed, 31 Mar 2010 22:46:41 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.51,346,1267430400"; d="scan'208";a="137790559"
Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 31 Mar 2010 22:47:11 -0700
Received: from ldcrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o315lBbo018735; Wed, 31 Mar 2010 22:47:11 -0700 (PDT)
Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 06:47:11 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 01 Apr 2010 06:47:09 +0100
Message-ID: <5FDC413D5FA246468C200652D63E627A08144911@LDCMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <201003072316.AAA29042@TR-Sys.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] IANA TCP options registry ...
Thread-Index: Acq+TVm5lvjWiOC+S96pFvaCqEQ/ggTENy8w
References: <201003072316.AAA29042@TR-Sys.de>
From: "Scheffenegger, Richard" <rs@netapp.com>
To: Alfred HÎnes <ah@TR-Sys.de>, tcpm@ietf.org
X-OriginalArrivalTime: 01 Apr 2010 05:47:11.0850 (UTC) FILETIME=[C65B8CA0:01CAD15E]
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: Thu, 01 Apr 2010 05:46:44 -0000
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 > -----Original Message----- > From: Alfred HÎnes [mailto:ah@TR-Sys.de] > Sent: Montag, 8. März 2010 00:17 > To: huitema@microsoft.com; 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-Novembe > r/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 >
- Re: [tcpm] IANA TCP options registry ... Scheffenegger, Richard
- Re: [tcpm] IANA TCP options registry ... Alfred Hönes
- Re: [tcpm] IANA TCP options registry ... Alfred Hönes
- Re: [tcpm] IANA TCP options registry ... Christian Huitema
- Re: [tcpm] IANA TCP options registry ... Joe Touch
- Re: [tcpm] IANA TCP options registry ... William Allen Simpson
- Re: [tcpm] IANA TCP options registry ... policy a… William Allen Simpson
- Re: [tcpm] IANA TCP options registry ... Lars Eggert
- Re: [tcpm] IANA TCP options registry ... Alexander Zimmermann
- Re: [tcpm] IANA TCP options registry ... policy a… Alfred Hönes
- Re: [tcpm] IANA TCP options registry ... William Allen Simpson
- Re: [tcpm] IANA TCP options registry ... policy a… Scheffenegger, Richard
- Re: [tcpm] IANA TCP options registry ... policy a… L.Wood
- Re: [tcpm] IANA TCP options registry ... Lars Eggert
- Re: [tcpm] IANA TCP options registry ... Lars Eggert
- Re: [tcpm] IANA TCP options registry ... policy a… Lars Eggert
- Re: [tcpm] IANA TCP options registry ... Alfred Hönes
- Re: [tcpm] IANA TCP options registry ... William Allen Simpson
- Re: [tcpm] IANA TCP options registry ... William Allen Simpson
- [tcpm] IANA TCP options registry ... RFC Editor
- Re: [tcpm] IANA TCP options registry ... policy a… Lars Eggert