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, 1 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: =?iso-8859-1?Q?Alfred_H=CEnes?= <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
>