RE: WGLC comments on draft-ietf-radext-tunnel-type-00.txt

["David B. Nelson" <dnelson@elbrysnetworks.com>]

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