Re: [dhcwg] draft-pruss-dhcp-auth-dsl vs. Internet Architecture

Alfred Hönes <ah@tr-sys.de> Thu, 19 March 2009 23:35 UTC

Return-Path: <A.Hoenes@tr-sys.de>
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 D94963A6AF9 for <dhcwg@core3.amsl.com>; Thu, 19 Mar 2009 16:35:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.647
X-Spam-Level: *
X-Spam-Status: No, score=1.647 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 oFri7YvBWDli for <dhcwg@core3.amsl.com>; Thu, 19 Mar 2009 16:35:45 -0700 (PDT)
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id E04AF28C178 for <dhcwg@ietf.org>; Thu, 19 Mar 2009 16:35:43 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA041035670; Fri, 20 Mar 2009 00:34:30 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id AAA27465; Fri, 20 Mar 2009 00:34:28 +0100 (MEZ)
From: Alfred Hönes <ah@tr-sys.de>
Message-Id: <200903192334.AAA27465@TR-Sys.de>
To: sarikaya@ieee.org, gwz@net-zen.net
Date: Fri, 20 Mar 2009 00:34:28 +0100
In-Reply-To: <453915.10829.qm@web111406.mail.gq1.yahoo.com> from Behcet Sarikaya at Mar "19, " 2009 "02:25:17" pm
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 8bit
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] draft-pruss-dhcp-auth-dsl vs. Internet Architecture
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 23:35:45 -0000

At 19 Mar 2009 14:25:17 -0700 (PDT) Behcet Sarikaya wrote:

> The IAB draft draft-iab-ip-config-11 does take a position in this
> debate and it recommends 802.1X for controlling access to a link.

Yes, it takes position, but that happens in application of the
"separation principle" there: Perform link access authentication /
authorization at Layer 2, and perform IP host configuration via DHCP.


> The draft does not say that DHCP should not be used for
> authentication.
> In fact it does mention DHCP authentication in several places.
> 
> Regards,
> 
> Behcet

Attention!

Regarding "DHCP Athentication", draft-iab-ip-config-11 refers to
RFC 3118, the main objective of which is /message/ authentication
(a.k.a. message integrity protection) and protection of the client
against spoofed/rogue DHCP servers, and these also are the main
goals of the built-in DHCPv6 security.
(... And note that draft-iab-ip-config-11 observes:
     However, DHCP authentication is not widely implemented for
     either DHCPv4 or DHCPv6.
)

However, draft-pruss-dhcp-auth-dsl attempts to address a very
different problem -- from its Abstract:

    This document defines DHCP extensions that provide for
    end-user authentication ...
    ^^^^^^^^^^^^^^^^^^^^^^^

Actually, the goal is service /authorization/ through an AAA
infrastructure 'behind' the NAS.

At first glance, it looks like the vastly extensible framework defined
in RFC 3119 could be leveraged for this aim, in a much less intrusive
manner to the DHCP protocol than draft-pruss-dhcp-auth-dsl does.

But please keep in mind that doing so would still not address
the basic IP architectural issues, IP subnet (broadcast domain)
model, delineation between layer 2 functions and IP routing, etc.


Another note on the problem space:
In DSL deployments, the 'first mile' (i.e. wired telephone network)
should make authentication of the subscriber trivial for the DSLAM
-- the telephony service over the same line doesn't use end-user
authentication either!  So the problem here is one of the split-
provider model typically enforced by regulation:
provisioning the ISP of the subscriber at the "(Physical) Access
Provider" components within the access network, and carrying the
identity information of the subscriber over to his ISP.



Glen Zorn Wrote:

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

I do not intend to undertake that effort alone!

In line with Jari Arkkos posting today, I would like to encourage
the whole DHCP community in the IETF, and perhaps other parties
in the INT Area as well, to evaluate the proposal with respect to
fundamental architectural questions (and not immediately at the
technical detail level), and then provide much more heavy-weight
and sound 'preaches' to the originating SDO.


Kind regards,
  Alfred.

-- 

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