IETF Logo Mail Archive

Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10

Ted Lemon <Ted.Lemon@nominum.com> Tue, 09 April 2013 16:24 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21C621F8554; Tue, 9 Apr 2013 09:24:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jIWdDm9Ba3i; Tue, 9 Apr 2013 09:24:50 -0700 (PDT)
Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 55F5321F8546; Tue, 9 Apr 2013 09:24:50 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUWRA0iiHQdBD+snbVOf4x7qi6MGftaCC@postini.com; Tue, 09 Apr 2013 09:24:50 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0ED211B889A; Tue, 9 Apr 2013 09:24:50 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 04819190061; Tue, 9 Apr 2013 09:24:50 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 09:24:50 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Jouni Korhonen <jouni.nospam@gmail.com>
Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10
Thread-Index: AQHONCshVSG79PrhReiNj3Ln9NlMtJjM2WGAgAAS14D//5W4wIABnQAAgABL5wCAAA9AgIAAEG6A
Date: Tue, 09 Apr 2013 16:24:49 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B63077513AAEA@mbx-01.win.nominum.com>
References: <CAC8SSWtBMyDgShEDofyUjgcBiQ_ttY_DUbDNHnhhnf531+9XXA@mail.gmail.com> <FB413294-CF61-4AD9-AF26-41EC8A30DF37@gmail.com> <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> <AC349589-AC7B-442B-9CE8-D7343BC44BCC@gmail.com> <5164263E.50402@gmail.com> <450791A9-F1A5-41F5-8EE7-8A69C823CE7A@gmail.com>
In-Reply-To: <450791A9-F1A5-41F5-8EE7-8A69C823CE7A@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <45CF9C5A6925F7429FEC29232C136A05@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<dhcwg@ietf.org>" <dhcwg@ietf.org>, "<radext@ietf.org>" <radext@ietf.org>
Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 09 Apr 2013 16:24:52 -0000

On Apr 9, 2013, at 11:26 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:
> 2) DHCP Server does not understand Z and thus responses to the Relay
>   with DHCP options/values based on X & Y only.

This is an administrative error.

> 3) DHCP Relay receives the response but for it to send a meaningful
>   reply to DHCP Client it would need some DHCP option/value in
>   the reply that reflects the content of the RADIUS attribute Z
>   (that was included into the request sent to Server).

The relay agent _never_ makes any decisions about what to send the client: that decision is made on the server.   Relay agent options can affect how the relay gets the response to the client, but do not affect the content of the response.

As a practical matter, it seems unlikely that a future RADIUS option would affect _how_ the relay agent gets the response back to the client.   So I think this particular scenario is not a problem.

Going back to the administrative error, it's an error because the administration has configured the RADIUS server and relay to support something but neglected to update the DHCP server to support it.   I think this failure mode is worth documenting, but ultimately it's not something that can be addressed in the spec other than as advice to administrators to make sure their DHCP server supports the added functionality they are hoping to get out of RADIUS.

Sorry for my earlier slightly off-base remarks—I have quite a few plates spinning at the moment.

v2.23.0 | Report a Bug | By Email