RE: WGLC comments on draft-ietf-radext-tunnel-type-00.txt
"David B. Nelson" <dnelson@elbrysnetworks.com> Tue, 25 November 2008 21:58 UTC
Return-Path: <owner-radiusext@ops.ietf.org>
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6973A6AE9 for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Tue, 25 Nov 2008 13:58:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.886
X-Spam-Level:
X-Spam-Status: No, score=-0.886 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 mlOB1Ib-DCZk for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Tue, 25 Nov 2008 13:58:34 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 62C213A6AA7 for <radext-archive-IeZ9sae2@lists.ietf.org>; Tue, 25 Nov 2008 13:58:34 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-radiusext@ops.ietf.org>) id 1L55s3-000Gsg-PT for radiusext-data@psg.com; Tue, 25 Nov 2008 21:54:59 +0000
Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from <dnelson@elbrysnetworks.com>) id 1L55rx-000GqZ-8K for radiusext@ops.ietf.org; Tue, 25 Nov 2008 21:54:57 +0000
Received: (qmail 8425 invoked from network); 25 Nov 2008 16:54:44 -0500
Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 25 Nov 2008 16:54:44 -0500
From: "David B. Nelson" <dnelson@elbrysnetworks.com>
To: radiusext@ops.ietf.org
References: <859E6E0FDB35410682534B311C3C1A60@xpsuperdvd2> <701A6382E4B1B0458FC27DE8F6A477081A29792913@AA-EXMSG-C424.southpacific.corp.microsoft.com> <A02AD68027764107966F6D76A21462DC@NEWTON603> <701A6382E4B1B0458FC27DE8F6A477081A29B7C3FD@AA-EXMSG-C424.southpacific.corp.microsoft.com> <002701c94f2f$d5a66980$80f33c80$@net>
Subject: RE: WGLC comments on draft-ietf-radext-tunnel-type-00.txt
Date: Tue, 25 Nov 2008 16:54:40 -0500
Organization: Elbrys Networks, Inc.
Message-ID: <CAB0AF9DBF0B458C8870EA31BCD4BB51@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <002701c94f2f$d5a66980$80f33c80$@net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Thread-Index: AckSoJZ1a/KplopMRfa5N5aB7a5d3wy4pvJwAAHDgmACWZ7mEAAN2e3AAAew8tA=
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: <radiusext.ops.ietf.org>
Glen Zorn writes... > The title is so vague as to be meaningless: suggest changing to the > extremely unwieldy "A RADIUS Tunnel Type for IP Encapsulating Security > Payload (ESP) in the Tunnel-mode with IKEv2" or some such thing (see > below), w/an appropriate abbreviation for the second & following pages. Agreed. > The document allocates two tunnel types but briefly discusses only one of > them; the other, proprietary to Microsoft Corporation, receives no > attention whatsoever. > This is a > problem because RFC 2868 states that new Tunnel-Type values are to be > assigned using the "IETF Consensus" policy (note that RFC 2868 is > specifically _not_ updated by RFC 3575). RFC 5226 says > > IETF Review - (Formerly called "IETF Consensus" in > [IANA-CONSIDERATIONS]) New values are assigned only through > RFCs that have been shepherded through the IESG as AD- > Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The > intention is that the document and proposed assignment will > be reviewed by the IESG and appropriate IETF WGs (or > experts, if suitable working groups no longer exist) to > ensure that the proposed assignment will not negatively > impact interoperability or otherwise extend IETF protocols > in an inappropriate or damaging manner. > > Given that there is no discussion whatsoever of Microsoft SSTP in this > document, I can't see how anyone could judge from reading it whether the > proposed assignment will "negatively impact interoperability or otherwise > extend IETF protocols in an inappropriate or damaging manner" or not. Well, there is no attempt to standardize SSTP here, just to allow RADIUS to provision it. Given that adding a new value of an integer-type enumerated value attribute is not likely to have any adverse impact on the RADIUS protocol, I see no need for extensive discussion there. One can argue whether SSTP itself is a good or bad thing, but that discussion seems somewhat orthogonal to the issue at hand. > The only reference given for SSTP is to a Microsoft marketing Web site. Well, the MSDN Library is not a marketing site, but rather a technical reference site. Still, I agree that this is not an absolutely stable reference. In a web search I found that SSTP is the subject of a US Patent Application, (summarized below) so there may at some point be a US Patent that could serve as a stable reference. ;-) Title: Secure Tunnel Over HTTPS Connection Document Type and Number: United States Patent Application 20080077788 Kind Code: A1 Abstract: Many secure tunnels require protocols that require special handling, authorization or security certificates, such as L2TP and PPTP. This often eliminates them for use between a corporate or agency network and outside, public networks. A secure socket tunnel protocol (SSTP) adds drivers in both the kernel and user mode to route standard protocol traffic, such as PPP, over a common HTTPS port. In the event of network interruptions, an exchange of a session cookie allows fast reconnection of the underlying HTTPS connection without affecting higher level applications. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/>
- Review of draft-tiwari-radext-tunnel-type-02.txt David B. Nelson
- RE: Review of draft-tiwari-radext-tunnel-type-02.… Bernard Aboba
- Re: Review of draft-tiwari-radext-tunnel-type-02.… Nagesh Vankayala
- RE: Review of draft-tiwari-radext-tunnel-type-02.… Abhishek Tiwari
- RE: Review of draft-tiwari-radext-tunnel-type-02.… Glen Zorn
- RE: Review of draft-tiwari-radext-tunnel-type-02.… Bernard Aboba
- RE: Review of draft-tiwari-radext-tunnel-type-02.… Abhishek Tiwari
- RE: Review of draft-tiwari-radext-tunnel-type-02.… David B. Nelson
- RE: Review of draft-tiwari-radext-tunnel-type-02.… Abhishek Tiwari
- RE: Review of draft-tiwari-radext-tunnel-type-02.… David B. Nelson
- WGLC comments on draft-ietf-radext-tunnel-type-00… Glen Zorn
- RE: WGLC comments on draft-ietf-radext-tunnel-typ… David B. Nelson
- RE: WGLC comments on draft-ietf-radext-tunnel-typ… Glen Zorn
- RE: WGLC comments on draft-ietf-radext-tunnel-typ… Abhishek Tiwari
- Re: WGLC comments on draft-ietf-radext-tunnel-typ… Greg Weber
- Review of draft-tiwari-radext-tunnel-type-02.txt Abhishek Tiwari
- RE: Review of draft-tiwari-radext-tunnel-type-02.… Dave Nelson
- RE: Review of draft-tiwari-radext-tunnel-type-02.… Abhishek Tiwari (NETWORKING)