Re: [dhcwg] draft-pruss-dhcp-auth-dsl vs. Internet Architecture -- was: Re: We really mean it this time *FINAL* agenda for dhc WG meeting

"Glen Zorn" <gwz@net-zen.net> Thu, 19 March 2009 18:09 UTC

Return-Path: <gwz@net-zen.net>
X-Original-To: dhcwg@core3.amsl.com
Delivered-To: dhcwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C38ED3A6873 for <dhcwg@core3.amsl.com>; Thu, 19 Mar 2009 11:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.644
X-Spam-Level:
X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[AWL=0.655, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 5RED60cKv6md for <dhcwg@core3.amsl.com>; Thu, 19 Mar 2009 11:09:15 -0700 (PDT)
Received: from smtpauth04.prod.mesa1.secureserver.net (smtpauth04.prod.mesa1.secureserver.net [64.202.165.95]) by core3.amsl.com (Postfix) with SMTP id D78B83A67F3 for <dhcwg@ietf.org>; Thu, 19 Mar 2009 11:09:15 -0700 (PDT)
Received: (qmail 8521 invoked from network); 19 Mar 2009 18:06:34 -0000
Received: from unknown (24.18.235.102) by smtpauth04.prod.mesa1.secureserver.net (64.202.165.95) with ESMTP; 19 Mar 2009 18:06:34 -0000
From: Glen Zorn <gwz@net-zen.net>
To: 'Alfred HÎnes' <ah@tr-sys.de>
References: <200903191124.MAA26754@TR-Sys.de>
In-Reply-To: <200903191124.MAA26754@TR-Sys.de>
Date: Thu, 19 Mar 2009 11:05:44 -0700
Organization: Network Zen
Message-ID: <001f01c9a8bd$52ebf310$f8c3d930$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
thread-index: AcmohZiIDwQV+oIMQx2bPTEFuas1+QALK1KA
Content-Language: en-us
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] draft-pruss-dhcp-auth-dsl vs. Internet Architecture -- was: Re: We really mean it this time *FINAL* agenda for dhc WG meeting
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2009 18:09:16 -0000

Alfred HÎnes [mailto:ah@tr-sys.de] writes:

> Folks,
> may I please recall some of the Architectural Principles
> of the Internet.
> 
> A recent interesting reading is the IAB statement in
> draft-iab-ip-config-11, which will perhaps be out as an RFC
> by the end of this month.

Thank you for bringing this to my attention, Alfred; as usual, the breadth &
scope of your reading amazes me (as well as the fact that you seem to be
able to remain sane despite your exposure to so much hogwash ;-).

> 
> That document contains a section:
> 
>   2.5.  Configuration is Not Access Control
> 
>     Network access authentication and authorization is a distinct
>     problem from Internet host configuration.  Therefore network access
>     authentication and authorization is best handled independently of
>     the Internet and higher layer configuration mechanisms.
> 
>     [...]

This is a very interesting assertion -- appropriately made without
supporting evidence, since there is none -- but I wonder on what planet it
might be true.  Here on Earth there is no case I can think of, from the
highest level (IANA, APNIC, RIPE, etc.) to the lowest (e.g., the DHCP server
in my home router) in which the allocation of one or more IP addresses is
not also the result of an authorization decision.  In fact, even in its most
basic deployments, DHCP has always done both authentication and
authorization: it just does authentication very poorly.

> 
> Further on in that document, the IAB emphasizes that simple and
> general, lightweight mechanisms are needed for IP host configuration,
> and that the number of such mechanisms needs to be very contained;
> the document recognizes DHCP as the major current Internet technology
> to this end.
> 
> Additionally, the IAB draft elaborated on the disadvantages of
> coupling authorization / access control and Internet layer
> configuration within an integrated protocol as it had been done
> in the past in PPP.

There's an awful lot of nonsense written about PPP in that draft; however,
see section 4.1 where the authors write rather wistfully of "DHCP
authentication".

> 
> The Authentication-over-DHCP draft aims at carrying over this concept
> "from PPP to the IP and DHCP layer".
> Carrying over an anti-modular architecture that has been recognized
> as bad should not become a serious candidate of work adopted by any
> IETF WG.
> 
> The Authentication-over-DHCP draft goes one significant step further
> in disavowing basic principles of the Internet Architecture:
> it introduces the misconcept of an "IP-Session" as its fundament.

Actually, the BBF seems to have adopted this (admittedly somewhat vaporous)
concept; our draft simply uses the already adopted idea as part of its
rationale.  In other words, we are not inventing the misconcept, merely
admitting its existence and attempting to give it a more secure foundation
since (as I understand it) the existence of an "IP session" is currently
based purely upon circumstantial evidence.

> IP is a connectionless technology based on per-packet forwarding.
> 
> Looking at the draft, it becomes evident that the model depicted
> in Figure 1 does not fit in the IP subnet model (please see the
> related IAB documents published over the last years!).

Note that the figure is titled "DSL Network Architecture".  Please don't
blame me for that!

> It is painfully unclear where the subnet boundaries are intended
> to be located and whether this draft again tries to introduce the
> nightmare of multi-link subnets.  It looks like the "Access Node"
> architecturally should be an IP router in the "replace PPP by IP"
> model of the draft, but apparently the draft did not recognize
> that -- otherwise it could not say that only the endpoints of the
> access network (CPE/HGW and NAS/BB-POP) need to be concerned
> by the proposal; to my knowledge, the typical DSLAM currently
> operates as a layer-2 switch, not as a router.
> 
> A reasonable model for getting rid of PPPoE in the access network
> in favor of IP, and enhancing its security and robustness seems
> to be introducing an IPv6 Access network as its infrastructure
> and establishing IPsec tunnels between CPE/HGW and NAS.
> Doing so would indeed allow seemless IPv4/IPv6 coexistence and
> a 'session'-based connection model, with a single conceptional
> IP hop between the CPE access router and the NAS; parallel
> IPsec SAs (Child_SAs) controlled by a single IKE_SA would also
> allow to provide differentiated services in parallel (for QoS
> support and other added-value services).

You're preaching to the wrong choir, Alfred: tell the xDSL SPs, but be
warned: I've already tried...

...