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/>