RE: [AAA-DOCTORS] AAA / RADIUS content indraft-ietf-softwire-hs-framework-l2tpv2
"Bernard Aboba" <Bernard_Aboba@hotmail.com> Wed, 14 January 2009 18:45 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 360EA28C1D2 for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Wed, 14 Jan 2009 10:45:11 -0800 (PST)
X-Quarantine-ID: <PVVAJL62vcrb>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID"
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, J_CHICKENPOX_32=0.6]
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 PVVAJL62vcrb for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Wed, 14 Jan 2009 10:45:10 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CD85B28C1BB for <radext-archive-IeZ9sae2@lists.ietf.org>; Wed, 14 Jan 2009 10:45:09 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-radiusext@ops.ietf.org>) id 1LNAfy-000OTh-9v for radiusext-data0@psg.com; Wed, 14 Jan 2009 18:41:14 +0000
Received: from bay0-omc2-s10.bay0.hotmail.com ([65.54.246.146]) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <bernard_aboba@hotmail.com>) id 1LNAfj-000OSB-8W for radiusext@ops.ietf.org; Wed, 14 Jan 2009 18:41:02 +0000
Received: from hotmail.com ([10.4.31.19]) by bay0-omc2-s10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 10:40:58 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 14 Jan 2009 10:40:58 -0800
Message-ID: <BLU137-DAV9AF6E36CB3321AFB0282193D60@phx.gbl>
Received: from 131.107.0.105 by BLU137-DAV9.phx.gbl with DAV; Wed, 14 Jan 2009 18:40:54 +0000
X-Originating-IP: [131.107.0.105]
X-Originating-Email: [bernard_aboba@hotmail.com]
X-Sender: bernard_aboba@hotmail.com
From: Bernard Aboba <Bernard_Aboba@hotmail.com>
To: 'Dave Nelson' <d.b.nelson@comcast.net>, "'Romascanu, Dan (Dan)'" <dromasca@avaya.com>, aaa-doctors@ietf.org, radiusext@ops.ietf.org
References: <EDC652A26FB23C4EB6384A4584434A04012C0E28@307622ANEX5.global.avaya.com> <B35DAB7F475E4FB88832D945B2165A35@NEWTON603> <EDC652A26FB23C4EB6384A4584434A04012F9F3D@307622ANEX5.global.avaya.com> <C0479961AE354C81B3B4A39CD65498D6@NEWTON603>
In-Reply-To: <C0479961AE354C81B3B4A39CD65498D6@NEWTON603>
Subject: RE: [AAA-DOCTORS] AAA / RADIUS content indraft-ietf-softwire-hs-framework-l2tpv2
Date: Wed, 14 Jan 2009 10:40:52 -0800
Message-ID: <002c01c97677$a060bd10$e1223730$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acl2a3AtDPd3bpScQnKA0qVKoQtAZgAATX+wAAB89nAAAB01gAABhNsw
Content-Language: en-us
X-OriginalArrivalTime: 14 Jan 2009 18:40:58.0534 (UTC) FILETIME=[A43BD460:01C97677]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: <radiusext.ops.ietf.org>
Presently, not all the scenarios described in the document are properly supported by AAA. As a result, the document redefines existing uses of RADIUS standard attributes, as well as suggesting implementation of documents that are currently still Internet Drafts. Section 8 updates several existing RADIUS standards RFCs, including: * RFC 2868, by defining new interpretations of the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes in situations where addressing attributes are not present. * RFC 2865, by defining new interpretations of the Framed-IP-Address and Framed-IP-Netmask attributes. * RFC 2866, by referencing draft-stevant-softwire-accounting, which redefines the format of the NAS-IP-Address attribute (which only supports IPv4 addresses; NAS-IPv6-Address is used to contain IPv6 addresses). Is this really appropriate for a framework document? >From draft-stevant-software-accounting-01.txt: A RADIUS accounting entry, as defined in [RFC2867], also includes the NASIPAddress attribute, which gives the IP address of the NAS used as the softwire endpoint. Based on this information, an operator can decide if this softwire is based on IPv4 or IPv6. In the case of provider only deploying IPv6 over IPv4 and IPv4 over IPv6 softwires, the nature of the traffic reported in the accounting information depends of the address family of NASIPAddress (if NASIPAddress is IPv4, accounted traffic is IPv6, if NASIPAddress is IPv6, accounted traffic is IPv4). However, this solution requires extra checking when building accounting report and obviously does not work in case of IPvX over IPvX softwires. 8.1. Softwire Endpoints 8.1.1. IPv6 Softwires If the RADIUS server includes a Framed-Interface-Id attribute [RFC3162], the Softwire Concentrator must send it to the Softwire Initiator in the Interface-Identifier field of its IPV6CP Configuration Request message. If the Framed-IPv6-Prefix attribute [RFC3162] is included, that prefix must be used in the router advertisements sent to the SI. If Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC must choose a prefix with that pool to send RAs. If none of the attributes above are included but the AAA server returns the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] with the correct address family, these must be used in the IPV6CP Interface-Identifier and for the Router Advertisements. [BA] The above paragraph defines new interpretations of these attributes. 8.1.2. IPv4 Softwires If the Framed-IP-Address attribute [RFC2865] is present, the Softwire Concentrator must provide that address to the Softwire Initiator during IPCP address negotiation. That is, when the Softwire Initiator requests an IP address from the Softwire Concentrator, the address provided should be the Framed-IP-Address. If the Framed-IP-Address attribute is not present and the Tunnel- Client-Endpoint and Tunnel-Server-Endpoint attributes [RFC2868] are present and of the correct address family, these should be used in the IPCP IP-Address configuration option. [BA] The above paragraph defines new interpretations of these attributes. 8.2. Delegated Prefixes 8.2.1. IPv6 Prefixes If the attribute Delegated-IPv6-Prefix [RFC4818] is present in the RADIUS Access-Accept message, it must be used by the Softwire Concentrator for the delegation of the IPv6 prefix. Since the prefix delegation is performed by DHCPv6 and the attribute is linked to a username, the SC must associate the DHCP Unique Identifier (DUID) of a DHCPv6 request to the tunnel it came from and its user. Interaction between RADIUS, PPP and DHCPv6 server may follow the mechanism proposed in [I-D.ietf-dhc-v6-relay-radius]. In this case, during the Softwire authentication phase, PPP collects the RADIUS attributes for the user such as Delegated-IPv6-Prefix. A specific DHCPv6 relay is assigned to the Softwire. The DHCPv6 relay fills in these attributes in the Relay agent RADIUS Attribute Option (RRAO) DHCPv6 option, before forwarding the DHCPv6 requests to the DHCPv6 server. [BA] The above paragraph makes what would appear to be a normative reference to an I-D. 8.2.2. IPv4 Prefixes The combination of the Framed-IP-Address and Framed-IP-Netmask attributes [RFC2865] may be used by the Softwire Concentrator to delegate an IPv4 prefix to the Softwire Initiator. [BA] The above paragraph defines new interpretations of these attributes. -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Dave Nelson Sent: Wednesday, January 14, 2009 9:45 AM To: 'Romascanu, Dan (Dan)'; aaa-doctors@ietf.org; radiusext@ops.ietf.org Subject: RE: [AAA-DOCTORS] AAA / RADIUS content indraft-ietf-softwire-hs-framework-l2tpv2 > See also section 2.5 in the document. 2.5. Authentication, Authorization and Accounting (AAA) L2TPv2 supports optional mutual Control Channel authentication and leverages the optional mutual PPP per-session authentication. L2TPv2 is well integrated with AAA solutions (such as RADIUS) for both authentication and authorization. Most L2TPv2 implementations available in the market support logging of authentication and authorization events. DBN: This paragraph contains an assertion about the integration of existing L2TPv2 implementations with RADIUS implementations. I'm not in a position to validate or refute that assertion from personal knowledge, but it seems reasonable on its face. L2TPv2 integration with RADIUS accounting (RADIUS Accounting extension for tunnel [RFC2867]) allows the collection and reporting of L2TPv2 Softwire usage statistics. DBN: Sure. RADIUS Accounting does support usage statistics reporting for all kinds of provisioned sessions, based on connect time and data transfer. -- 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/> -- 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/>
- AAA / RADIUS content in draft-ietf-softwire-hs-fr… Romascanu, Dan (Dan)
- RE: [AAA-DOCTORS] AAA / RADIUS content indraft-ie… Dave Nelson
- RE: [AAA-DOCTORS] AAA / RADIUS content indraft-ie… Romascanu, Dan (Dan)
- RE: [AAA-DOCTORS] AAA / RADIUS content indraft-ie… Dave Nelson
- RE: [AAA-DOCTORS] AAA / RADIUS content indraft-ie… Romascanu, Dan (Dan)
- RE: [AAA-DOCTORS] AAA / RADIUS content indraft-ie… Bernard Aboba
- RE: [AAA-DOCTORS] AAA / RADIUS content indraft-ie… Dave Nelson
- RFC 5378 Implications Bernard Aboba
- Re: [AAA-DOCTORS] AAA / RADIUS content indraft-ie… Alan DeKok