Subject: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 8 Aug 2011 09:35:59 +0200

Hi AAA Doctors,

Did any of you review this document? 

Thanks and Regards,

Dan

---

From: Mark Jones <[email-masked]>
Date: Mon, 8 Aug 2011 10:28:35 -0400

I took a quick read of the draft. I don't claim to be a softwire expert but
it was not clear to me why the authors needed a new AVP when the RADIUS
tunnel attributes (RFC2868) could probably be reused here.

Mark

On Mon, Aug 8, 2011 at 3:35 AM, Romascanu, Dan (Dan) <[email-masked]>wrote:

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

---

From: Alan T DeKok <[email-masked]>
Date: Mon, 08 Aug 2011 10:52:08 -0400

> Did any of you review this document? 

  I have minor nit-picks on the format.  The discussion of
type/length/value at the top of page 9 doesn't follow the traditional
RADIUS format.  It's minor, but still..

  On a related note, there's been a surge of interest recently in adding
DHCP attributes to RADIUS.  I registered a PEC a while back to address
the issue.  I created a vnedor-specific dictionary for RADIUS, which is
intended to carry DHCP options:

https://github.com/alandekok/freeradius-server/blob/master/share/dictionary.freedhcp

  The intention is that VSAs with PEC of 34673 are duplicates of the
IANA allocation DHCP options.

  Using this would solve a few issues.  The IETF standard RADIUS space
would feel less pressure, as the VSAs could be used.  All of the other
vendors "ad hoc" ways of carrying DHCP options in RADIUS could be
replaced by using this dictionary.

  If people think it's worth-while, I can submit an individual draft
documenting this practice.  It may not help for this document, but it
will help for future documents.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 8 Aug 2011 11:11:13 -0700

I found a few other issues beyond those Alan mentions below.

Figure 2 shows a RADIUS exchange with no NAS present, or user authentication occurring. 

As noted in RFC 5080 Section 2.1.1 describes the requirements for authorization-only Access-Requests:

   Access-Request packets that contain a Service-Type attribute with the
   value Authorize Only (17) MUST contain a State attribute.  Access-
   Request packets that contain a Service-Type attribute with value Call
   Check (10) SHOULD NOT contain a State attribute.  Any other Access-
   Request packet that performs authorization checks MUST contain a
   State attribute.  This last requirement often means that an Access-
   Accept needs to contain a State attribute, which can then be used in
   a later Access-Request that performs authorization checks.

The document does not describe the contents of the Access-Request in enough detail to understand whether it is compliant with RFC 5080, 2865 or other RADIUS protocol documents.  So either this is a protocol violation, or the exchange described is under-specified.

Section 4.1 describes a NAS sending an Access-Accept to a RADIUS server.   Either this is a typo (e.g. it should say Access-Request) or the authors are making a major change to the RADIUS protocol:

   This attribute MAY be used in Access-Accept packets as a hint to the
   RADIUS server; for example if the NAS is pre-configured with a
   default tunnel name, this name MAY be inserted in the attribute.  The
   RADIUS server MAY ignore the hint sent by the NAS and it MAY assign a
   different AFTR tunnel name.

> Date: Mon, 8 Aug 2011 10:52:08 -0400
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]
> Subject: Re: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04
> 
> the issue.  I created a vendor-specific dictionary for RADIUS, which is

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 8 Aug 2011 11:21:12 -0700

I'd also note that RFC 5176 requires that session identification attributes not be used to request authorization changes.  I am not clear whether the DSLITE-Tunnel-Name Attribute would be classified as a session identification attribute, but RFC 5176 does classify other IPv6-related configuration attributes (e.g. Framed-IPv6-Prefix) as  session-identification attributes which cannot be changed by CoA-Request packets.  The reasoning is that changing a host's address without notifying the host is a bad idea, so that it is better to notify the host first then initiate another Access-Request/Accept sequence than to send a CoA-Request.

   (Note 1) Where NAS or session identification attributes are included
   in Disconnect-Request or CoA-Request packets, they are used for
   identification purposes only.  These attributes MUST NOT be used for
   purposes other than identification (e.g., within CoA-Request packets
   to request authorization changes).

From: [email-masked]
To: [email-masked]; [email-masked]
CC: [email-masked]
Subject: RE: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04
Date: Mon, 8 Aug 2011 11:11:13 -0700

---

From: <[email-masked]>
Date: Tue, 9 Aug 2011 00:22:19 +0200

I reviewed this draft last year and I had the same comment. I even proposed an alternative based on RFC2868 but authors argued that their approach was better... that may be true! J

Lionel

De : [email-masked] [mailto:[email-masked]] De la part de Mark Jones
Envoyé : lundi 8 août 2011 16:29
À : Romascanu, Dan (Dan)
Cc : [email-masked]
Objet : Re: [AAA-DOCTORS] draft-ietf-softwire-dslite-radius-ext-04

I took a quick read of the draft. I don't claim to be a softwire expert but it was not clear to me why the authors needed a new AVP when the RADIUS tunnel attributes (RFC2868) could probably be reused here.

Mark

On Mon, Aug 8, 2011 at 3:35 AM, Romascanu, Dan (Dan) <[email-masked]> wrote:

Hi AAA Doctors,

Thanks and Regards,

Dan

Subject: RE: Comment on draft-maglione-softwire-dslite-radius-ext
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Wed, 4 Aug 2010 14:37:51 +0200

Hi Lionel,
    Thanks for putting together an alternative way to address this scenario. The difference I see comparing the two methods is that in your proposal you just have one single attribute, the Tunnel-Server-Endpoint that can contain either the tunnel name or the tunnel address, while
in our draft we wanted to keep a 1 to 1 mapping between the RADIUS attributes and the already specified DHCPv6 options (OPTION_DS_LITE_ADDR and OPTION_DS_LITE_NAME). For this reason we prefer having two separate attributes one for the DSLite tunnel name (DS-Lite-Tunnel-Name) and the other for the DSLite tunnel address (DS-Lite-Tunnel-Addr).

Best regards,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: giovedì 29 luglio 2010 16.57
To: [email-masked]
Cc: [email-masked]; Maglione Roberta; [email-masked]; [email-masked]
Subject: RE: Comment on draft-maglione-softwire-dslite-radius-ext

Here is an example of what could be the content of tyhe draft describing the use of the Tunnel attributes for DS-Lite Tunneling.
This is based on the draft published by Alain and Roberta as well as the RFC 2868.

This kind of approach would avoid having to define a new set of attributes.
Please comment the idea based on the following draft attempt!

BR,

Lionel

***********************

Title: Use of RADIUS Tunnel Attributes for Dual-Stack Lite

Abstract

   This document describes the use of the set of RADIUS attributes defined in the RFC 2868 to support
   establishment of Dual-Stack Lite tunnel.

1. Motivation

   Dual-Stack Lite [I-D.ietf-softwire-dual-stack-lite] is a solution to
   offer both IPv4 and IPv6 connectivity to customers which are
   addressed only with an IPv6 prefix (no IPv4 address is assigned to
   the attachment device).  One of its key components is an IPv4-over-
   IPv6 tunnel, but a DS-Lite Basic Bridging BroadBand (B4) will not
   know if the network it is attached to offers Dual-Stack Lite support,
   and if it did, would not know the remote end of the tunnel to
   establish a connection.

   To inform the B4 of the AFTR's location, either an IPv6 address or
   Fully Qualified Domain Name (FQDN) may be used.  Once this
   information is conveyed, the presence of the configuration indicating
   the AFTR's location also informs a host to initiate Dual-Stack Lite
   (DS-Lite) service and become a Softwire Initiator.

   The draft draft-ietf-softwire-ds-lite-tunnel-option
   [I-D.ietf-softwire-ds-lite-tunnel-option] specifies two DHCPv6
   options which are meant to be used by a Dual-Stack Lite client (Basic
   Bridging BroadBand element, B4) to discover its Address Family
   Transition Router (AFTR) address.  In order to be able to populate
   such options the DHCPv6 Server must be pre-provisioned with the
   Address Family Transition Router (AFTR) address or name.

   In Broadband environments, customer profile may be managed by AAA
   servers, together with user Authentication, Authorization, and
   Accounting (AAA).  RADIUS protocol [RFC2865] is usually used by AAA
   Servers to communicate with network elements.
   [I-D.ietf-radext-ipv6-access] describes a typical broadband network
   scenario in which the Network Access Server (NAS) acts as the access
   gateway for the users (hosts or CPEs) and the NAS embeds a DHCPv6
   Server function that allows it to locally handle any DHCPv6 requests
   issued by the clients.

   Since the DS-Lite AFTR information can be stored as tunneling information
   in AAA servers and the client configuration is mainly provided through
   DHC protocol running between the NAS and the requesting clients, this
   document aims at describing the use of the RADIUS tunnel attributes
   defined in RFC 2868 for carrying the DS-Lite tunnel information (DS-Lite
   Tunnel Name and DS-Lite Tunnel Address), this information being populated in
   in DHCPv6 options already specified in [I-D.ietf-softwire-ds-lite-tunnel-option].

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The terms DS-Lite Basic Bridging BroadBand element (B4) and the DS-
   Lite Address Family Transition Router element (AFTR) are defined in
   [I-D.ietf-softwire-dual-stack-lite].

3. DS-Lite Configuration with RADIUS and DHCPv6

   The Figure 1 illustrates how the RADIUS protocol and DHCPv6 work
   together to accomplish DS-Lite configuration on the B4 element.

         B4                        NAS                           AAA
         |                          |                          Server
         |                          |                             |
         |                          |                             |
         |                          |-----Access Request -------->|
         |                          |                             |
         |                          |<----Access Accept           |
         |                          |    (Tunnel-Type,            |
         |                          |     Tunnel-Medium-Type ,    |
         |                          |     Tunnel-Server-Endpoint) |
         |                          |                             |
         |------DHCPv6 Request----->|                             |
         |  (DS-Lite tunnel Option) |                             |
         |                          |                             |
         |<-----DHCPv6 Reply--------|                             |
         | (DS-Lite tunnel option)  |                             |

                   DHCPv6                         RADIUS

                 Figure 1: RADIUS and DHCPv6 Message Flow

   The Network Access Server (NAS) operates as a client of RADIUS and as
   DHCP Server for DHC protocol.  The NAS initially sends a RADIUS
   Access Request message to the RADIUS server, requesting
   authentication.  Once the RADIUS server receives the request, it
   validates the sending client and if the request is approved, the AAA
   server replies with an Access Accept message including a list of
   attributes that describe the parameters to be used for
   this session.  This list may also contain the RADIUS Tunnel attributes
   Tunnel-Type, Tunnel-Medium-Type and Tunnel-Server-Endpoint (and
   Tunnel-Preference if multiple tunnels information are provided).
   These attirbutes are used to provide the NAS with AFTR Tunnel IPv6
   Address and/or the AFTR Tunnel Name.  When the NAS receives a
   DHCPv6 client request containing the DS-Lite tunnel Options, the NAS
   shall use the address and/or name returned in the RADIUS
   Tunnel-Server-Endpoint attribute to populate the
   DHCPv6 OPTION_DS_LITE_ADDR option in the DHCPv6 reply message.

3. Use of the RADIUS Tunnel Attributes

   This section describes the RADIUS attributes defined in RFC 2868 and
   used to provide a NAS  with DS-Lite tunnel information. The use of these
   attributes shall follow the recommendations given in the RFC 2868.
   Any other attirbutes defined in RFC 2868 SHOULD NOT be used.

3.1. Tunnel-Type

   The Tunnel-Type Attribute (64) [RFC 2868] SHALL be used to indicate the type
   of tunnel to be used. This document defines a new value of tunnel type
   to be populated in the Value field of the Tunnel-Type attribute for DS-Lite
   Tunneling information.

   Value   Name
   TBD1    DS-Lite Tunneling

3.2. Tunnel-Medium-Type

   The Tunnel-Medium-Type Attribute (65) SHALL be used to indicate IPv6
   (value 2) as transport medium for DS-Lite Tunnel.

3.4. Tunnel-Server-Endpoint

    The Tunnel-Server-Endpoint attribute ((67) SHALL be used to provide
    either the FQDN of the AFTR Tunnel or a text representation of the
    IPv6 address in either the preferred or alternate form [17].

    If the The Tunnel-Type Attribute (64) indicates the tunnet type "DS-Lite
    Tunneling" (value TBD1), at least one Tunnel-Server-Endpoint attribute
    MUST be provided by the RADIUS server and at least two if the IPv6 address
    and the FQDN of the  AFTR Tunnel are both provided.

3.8. Tunnel-Preference

   If more than one set of DS-Lite tunneling attributes is returned by the
   RADIUS server to the NAS, this Attribute MAY be included in each
   set to indicate the relative preference assigned to each tunnel.

4. Table of Attributes

   The following table provides a guide to which of the above attributes
   may be found in which kinds of packets, and in what quantity.

Request Accept Reject Challenge Acct-Request #  Attribute
0+      0+     0      0         0-1          64 Tunnel-Type
0+      0+     0      0         0-1          65 Tunnel-Medium-Type
0+      0+     0      0         0-1          67 Tunnel-Server-Endpoint
0+      0+     0      0         0            83 Tunnel-Preference

   The following table defines the meaning of the above table entries.

0 This attribute MUST NOT be present in packet.

0+    Zero or more instances of this attribute MAY be present in packet.
0-1   Zero or one instance of this attribute MAY be present in packet.

5. Security Considerations

   TBD.

6. IANA Considerations

   This document defines a new value of tunnel type to be assigned by the IANA.

   Value   Name
   TBD1    DS-Lite Tunneling

7. References

________________________________

        De : MORAND Lionel RD-CORE-ISS
        Envoyé : mercredi 28 juillet 2010 10:31
        À : 'radext mailing list'
        Objet : Comment on draft-maglione-softwire-dslite-radius-ext

        Following my comment during the meeting, about (re-)using an existing attribute to convey tunnel info for DS-Lite, what about re-using attributes defined in RFC 2868 ???

        It should be straightforward to create a new type for DS-Lite.

        BR,

        Lionel

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.