Subject: [AAA-DOCTORS] AAA / RADIUS content in draft-ietf-softwire-hs-framework-l2tpv2

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 14 Jan 2009 18:13:37 +0100

The Softwire Hub & Spoke Deployment Framework with L2TPv2 I-D
http://www.ietf.org/internet-drafts/draft-ietf-softwire-hs-framework-l2t
pv2-10.txt is on the agenda of the IESG telechat tomorrow for approval
as a Proposed Standard. This document has a couple of sections (4.3,
9.1) that refer to AAA and RADIUS. Can somebody please have a look to
the content of these sections? 

Thanks and Regards,

Dan
_______________________________________________
AAA-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/aaa-doctors

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 14 Jan 2009 12:33:08 -0500

Dan Romascanu writes...

> Can somebody please have a look to the content of these sections?

4.3.  Authentication Authorization Accounting

   RFC 2865   "Remote Authentication Dial In User Service (RADIUS)"
              [RFC2865].

DBN: Current document.  Updated by RFC2868, RFC3575, RFC5080.

   RFC 2867   "RADIUS Accounting Modifications for Tunnel Protocol
              Support" [RFC2867].

DBN: Current document.

   RFC 2868   "RADIUS Attributes for Tunnel Protocol Support" [RFC2868].

DBN: Current document.

   RFC 3162   "RADIUS and IPv6" [RFC3162].

DBN: Current document.

DBN: I can't attest that this list of references is necessary and sufficient
to the requirements of Softwires, however. 

9.1.  RADIUS Accounting

   RADIUS Accounting for L2TP and PPP are documented (see Section 4.3).

   When deploying Softwire solutions, operators may experience
   difficulties to differentiate the address family of the traffic
   reported in accounting information from RADIUS.  This problem and
   some potential solutions are described in
   [I-D.stevant-softwire-accounting].

DBN: I have not reviewed the referenced I-D, but it's quite likely that a
lack of (standardized) RADIUS attributes capable of representing address
families might inhibit the straightforward application of RADIUS Accounting.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 14 Jan 2009 18:36:31 +0100

See also section 2.5 in the document. 

Dan

> -----Original Message-----
> From: Dave Nelson [mailto:[email-masked]] 
> Sent: Wednesday, January 14, 2009 7:33 PM
> To: Romascanu, Dan (Dan); [email-masked]; [email-masked]
> Subject: RE: [AAA-DOCTORS] AAA / RADIUS content 
> indraft-ietf-softwire-hs-framework-l2tpv2
> 
> Dan Romascanu writes...
> 
> DBN: I can't attest that this list of references is necessary 
> and sufficient to the requirements of Softwires, however. 
> 
> 
> 9.1.  RADIUS Accounting
> 
> DBN: I have not reviewed the referenced I-D, but it's quite 
> likely that a lack of (standardized) RADIUS attributes 
> capable of representing address families might inhibit the 
> straightforward application of RADIUS Accounting.
> 
> 
> 
>

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 14 Jan 2009 12:44:57 -0500

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 14 Jan 2009 19:19:08 +0100

Actually the whole section 8 is about 'Considerations about RADIUS
Integration' so this needs review.. 

Dan

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 14 Jan 2009 10:40:52 -0800

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Dave Nelson
Sent: Wednesday, January 14, 2009 9:45 AM
To: 'Romascanu, Dan (Dan)'; [email-masked]; [email-masked]
Subject: RE: [AAA-DOCTORS] AAA / RADIUS content
indraft-ietf-softwire-hs-framework-l2tpv2

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 14 Jan 2009 13:53:44 -0500

> Integration' so this needs review.

Sorry, it would have behooved me to read the document rather than simply
checking the sections you called out.  Too much multi-tasking today.  It
looks like Bernard has covered this section in his post.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 25 Jan 2009 18:22:40 +0100

> Integration' so this needs review.. 

  I agree with Bernard here.  The document isn't in good shape, and the
I-D's it references require drastic changes to the RADIUS protocol.

  Alan DeKok.