Re: [AAA-DOCTORS] AAA / RADIUS content indraft-ietf-softwire-hs-framework-l2tpv2

"Bernard Aboba" <Bernard_Aboba@hotmail.com> Wed, 14 January 2009 18:41 UTC

Return-Path: <aaa-doctors-bounces@ietf.org>
X-Original-To: aaa-doctors-archive@optimus.ietf.org
Delivered-To: ietfarch-aaa-doctors-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9D493A68B2; Wed, 14 Jan 2009 10:41:15 -0800 (PST)
X-Original-To: aaa-doctors@core3.amsl.com
Delivered-To: aaa-doctors@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20AE23A68B2 for <aaa-doctors@core3.amsl.com>; Wed, 14 Jan 2009 10:41:15 -0800 (PST)
X-Quarantine-ID: <EwPkdDyAb701>
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.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=0.010, 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 EwPkdDyAb701 for <aaa-doctors@core3.amsl.com>; Wed, 14 Jan 2009 10:41:13 -0800 (PST)
Received: from bay0-omc2-s41.bay0.hotmail.com (bay0-omc2-s41.bay0.hotmail.com [65.54.246.177]) by core3.amsl.com (Postfix) with ESMTP id 8167E3A6813 for <aaa-doctors@ietf.org>; Wed, 14 Jan 2009 10:41:13 -0800 (PST)
Received: from hotmail.com ([10.4.31.19]) by bay0-omc2-s41.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>
Date: Wed, 14 Jan 2009 10:40:52 -0800
Message-ID: <002c01c97677$a060bd10$e1223730$@com>
MIME-Version: 1.0
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]
Subject: Re: [AAA-DOCTORS] AAA / RADIUS content indraft-ietf-softwire-hs-framework-l2tpv2
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/aaa-doctors>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: aaa-doctors-bounces@ietf.org
Errors-To: aaa-doctors-bounces@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/>

_______________________________________________
AAA-DOCTORS mailing list
AAA-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/aaa-doctors