Subject: ssh authentication and service authorization questions

From: Bernard Aboba <[email-masked]>
Date: Sun, 28 Nov 2010 11:24:36 -0800

Several ideas come to mind:

1. In step 2, have the RADIUS server return the list of subsystems that the user is authorized to use within the Access-Accept, then go on to step 3. 
However, this won't work if step 3 requires specific authorizations that depend on which subsystem is chosen. 

2. Use an Access-Challenge/Request sequence to keep the conversation going until step 3, so that the subsystem that is being requested
can be made known to the RADIUS server, so that it can return subsystem-specific authorizations in the Access-Accept.  However, delays between
step 2 and step 3 could potentially interact with RADIUS retransmission logic. 

> ----- Forwarded message from Juergen Schoenwaelder <[email-masked]> -----
> 
> Date: Sat, 6 Nov 2010 08:16:51 +0100
> From: Juergen Schoenwaelder <[email-masked]>
> To: [email-masked]
> CC: Martin Bjorklund <[email-masked]>, [email-masked]
> Subject: ssh authentication and service authorization questions
> Message-ID: <[email-masked]>
> 
> [I am resending this since the first message likely has not made it
>  over the list - I can't anything in the archives.]
> 
> Hi,
> 
> in the context of NETCONF, we recently discovered the following issue
> where we would like to have advice from RADIUS experts on how to do
> things correctly. The question concerns SSH service authorization with
> RADIUS. (The same issue also applies to SNMP over SSH.)
> 
> SSH supports the notion of subsystems. In short, SSH goes through the
> following process:
> 
> 1) server authentication and session key establishment
> 2) user authentication (e.g., using passwords)
> 3) creation of channels for specific subsystems (shell, netconf, ...)
> 
> We like to do user authentication and session authorization using
> RADIUS, i.e. we like to ask a RADIUS server to verify the user
> credentials (e.g. password) and to authorize the user to use a
> specific subsystem. Unfortunately, by the time we have to authenticate
> the user (step 2) above), we do not yet know which subsystem will be
> requested (step 3) above).
> 
> We have been considering ways to "guess" the subsystem the user will
> ask for (e.g. by running SSH on a separate port number) but all this
> looks fragile and architecturally very obscure. Since I am sure we are
> not the first ones to run into such an issue, I thought I ask the
> experts to give us advice how RADIUS can help us to achieve what we
> want.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> 
> ----- End forwarded message -----
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 30 Nov 2010 20:59:24 +0100

> Several ideas come to mind:

  Or use Service-Type = Authorize-Only?

  It's intended for CoA, but there's no technical reason it couldn't be
used here.

  i.e.

1,2) Access-Request for initial session (user + password)
     Access-Accept contains State

3)  For each service:

       Access-Request + User-Name + State + Authorize-Only + ...
       ...

  The State attribute ties the later Access-Requests to the first one.
The RADIUS server can authorize individual services, based on their
connection with the initial Access-Request.

  IIRC, this is already being done for WiMAX, for authorizing individual
TCP connections.

  Alan DeKok.

--
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: Bernard Aboba <[email-masked]>
Date: Tue, 30 Nov 2010 15:39:26 -0800

RFC 5607 uses Service-Type=Framed-Management. Presumably that would be used
in exchanges 1,2. 

Section 6.1 states that the Framed-Management-Protocol attribute is used
with Service-Type=Framed-Management However, this isn't known until exchange
3 which will need to use Service-Type=Authorize-Only. 

Maybe the solution is just to clarify the Section 6.1 text?  I see no
inherent reason why a Framed-Management-Protocol attribute couldn't be
included in an Access-Request with Service-Type=Authorize-Only. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alan DeKok
Sent: Tuesday, November 30, 2010 11:59 AM
To: Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: Re: ssh authentication and service authorization questions

  i.e.

3)  For each service:

  Alan DeKok.

Delivery-date: Tue, 30 Nov 2010 23:37:45 +0000
From: Bernard Aboba <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
CC: <[email-masked]>, <[email-masked]>
Subject: RE: ssh authentication and service authorization questions
Date: Tue, 30 Nov 2010 15:39:26 -0800

RFC 5607 uses Service-Type=Framed-Management. Presumably that would be used
in exchanges 1,2. 

Section 6.1 states that the Framed-Management-Protocol attribute is used
with Service-Type=Framed-Management However, this isn't known until exchange
3 which will need to use Service-Type=Authorize-Only. 

Maybe the solution is just to clarify the Section 6.1 text?  I see no
inherent reason why a Framed-Management-Protocol attribute couldn't be
included in an Access-Request with Service-Type=Authorize-Only. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alan DeKok
Sent: Tuesday, November 30, 2010 11:59 AM
To: Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: Re: ssh authentication and service authorization questions

  i.e.

3)  For each service:

  Alan DeKok.

Delivery-date: Tue, 30 Nov 2010 20:00:28 +0000
Date: Tue, 30 Nov 2010 20:59:24 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>,  [email-masked]
Subject: Re: ssh authentication and service authorization questions

  i.e.

3)  For each service:

  Alan DeKok.

Delivery-date: Mon, 29 Nov 2010 13:39:19 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, radext mailing list <[email-masked]>, radext chair <[email-masked]>
Subject: Document Action: 'RADIUS Over TCP' to Experimental RFC (draft-ietf-radext-tcp-transport-09.txt)
Date: Mon, 29 Nov 2010 05:37:04 -0800

The IESG has approved the following document:
- 'RADIUS Over TCP'
  (draft-ietf-radext-tcp-transport-09.txt) as an Experimental RFC

This document is the product of the RADIUS EXTensions Working Group.

The IESG contact persons are Dan Romascanu and Ron Bonica.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-radext-tcp-transport/

Technical Summary

RADIUS has traditionally used UDP as its underlying transport layer, for
reasons described in RFC 2865 Section 2.4. This document defines RADIUS
over TCP, in order to address handling issues related to RADIUS over TLS
(RTLS). It is not intended to define TCP as a transport protocol for
RADIUS in the absence of TLS.

Working Group Summary

This document is part of a set (including the Status-Server and RTLS
specifications) which together define RADIUS over TLS (RTLS).
This document has completed RADEXT WG last call, with the primary
areas of discussion relating to liveness detection and congestion control.

Document Quality

The document has been reviewed by IETF RADEXT WG members.

RADIUS over TCP/TLS has been implemented by multiple vendors,
including RADIATOR and FreeRADIUS. The protocol is currently
deployed by EDUROAM, an educational roaming consortium supporting
more than one million users worldwide. As a result, the document
reflects operational experience.

Personnel

Bernard Aboba is the document shepherd for this document.
Dan Romascanu is the responsible AD.

RFC Editor Note

In the Security COnsiderations section, please insert the following text
between the second and the third paragraph: 

'Implementors should consult [RTLS] for issues related the security of
RADIUS over TLS, and [RFC5246] for issues related to the security of the
TLS protocol.

Since "bare" TCP does not provide for confidentiality or enable
negotiation of credible ciphersuites, its use is not appropriate for
inter-server communications where strong security is required.  The use of
"bare" TCP transport (i.e., without additional confidentiality and
security) is NOT RECOMMENDED, as there has been little or no operational
experience with it.'

Delivery-date: Sun, 28 Nov 2010 19:25:39 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>, <[email-masked]>
Subject: ssh authentication and service authorization questions
Date: Sun, 28 Nov 2010 11:24:36 -0800

--_2486febf-345c-4a28-9745-5f49422b9751_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

1. In step 2=2C have the RADIUS server return the list of subsystems that t=
he user is authorized to use within the Access-Accept=2C then go on to step=
 3.=20
However=2C this won't work if step 3 requires specific authorizations that =
depend on which subsystem is chosen.=20

2. Use an Access-Challenge/Request sequence to keep the conversation going =
until step 3=2C so that the subsystem that is being requested
can be made known to the RADIUS server=2C so that it can return subsystem-s=
pecific authorizations in the Access-Accept.  However=2C delays between
step 2 and step 3 could potentially interact with RADIUS retransmission log=
ic.=20

> ----- Forwarded message from Juergen Schoenwaelder <j.schoenwaelder@jacob=
s-university.de> -----
>=20
> Date: Sat=2C 6 Nov 2010 08:16:51 +0100
> CC: Martin Bjorklund <[email-masked]>=2C [email-masked]
>=20
>=20
> Hi=2C
>=20
> in the context of NETCONF=2C we recently discovered the following issue
>=20
> SSH supports the notion of subsystems. In short=2C SSH goes through the
> following process:
>=20
> 2) user authentication (e.g.=2C using passwords)
> 3) creation of channels for specific subsystems (shell=2C netconf=2C ...)
>=20
> RADIUS=2C i.e. we like to ask a RADIUS server to verify the user
> specific subsystem. Unfortunately=2C by the time we have to authenticate
> the user (step 2) above)=2C we do not yet know which subsystem will be
>=20
> not the first ones to run into such an issue=2C I thought I ask the
>=20
>=20
> --=20
> Phone: +49 421 200 3587         Campus Ring 1=2C 28759 Bremen=2C Germany
>=20
>=20
> --=20
> Phone: +49 421 200 3587         Campus Ring 1=2C 28759 Bremen=2C Germany
 		 	   		  =

--_2486febf-345c-4a28-9745-5f49422b9751_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style>
</head>
<body class=3D'hmmessage'>
Several ideas come to mind:<br><br>1. In step 2=2C have the RADIUS server r=
eturn the list of subsystems that the user is authorized to use within the =
Access-Accept=2C then go on to step 3. <br>However=2C this won't work if st=
ep 3 requires specific authorizations that depend on which subsystem is cho=
sen. <br><br>2. Use an Access-Challenge/Request sequence to keep the conver=
sation going until step 3=2C so that the subsystem that is being requested<=
br>can be made known to the RADIUS server=2C so that it can return subsyste=
m-specific authorizations in the Access-Accept.&nbsp=3B However=2C delays b=
etween<br>step 2 and step 3 could potentially interact with RADIUS retransm=
ission logic. <br><br><br>&gt=3B ----- Forwarded message from Juergen Schoe=
nwaelder &lt=[email-masked]&gt=3B -----<br>&gt=3B <=
br>&gt=3B Date: Sat=2C 6 Nov 2010 08:16:51 +0100<br>&gt=3B From: Juergen Sc=
hoenwaelder &lt=[email-masked]&gt=3B<br>&gt=3B To: =
[email-masked]<br>&gt=3B CC: Martin Bjorklund &lt=[email-masked]&=
gt=3B=2C [email-masked]<br>&gt=3B Subject: ssh authentication=
 and service authorization questions<br>&gt=3B Message-ID: &lt=3B2010110607=
[email-masked]&gt=3B<br>&gt=3B <br>&gt=3B [I am resending this s=
ince the first message likely has not made it<br>&gt=3B  over the list - I =
can't anything in the archives.]<br>&gt=3B <br>&gt=3B Hi=2C<br>&gt=3B <br>&=
gt=3B in the context of NETCONF=2C we recently discovered the following iss=
ue<br>&gt=3B where we would like to have advice from RADIUS experts on how =
to do<br>&gt=3B things correctly. The question concerns SSH service authori=
zation with<br>&gt=3B RADIUS. (The same issue also applies to SNMP over SSH=
.)<br>&gt=3B <br>&gt=3B SSH supports the notion of subsystems. In short=2C =
SSH goes through the<br>&gt=3B following process:<br>&gt=3B <br>&gt=3B 1) s=
erver authentication and session key establishment<br>&gt=3B 2) user authen=
tication (e.g.=2C using passwords)<br>&gt=3B 3) creation of channels for sp=
ecific subsystems (shell=2C netconf=2C ...)<br>&gt=3B <br>&gt=3B We like to=
 do user authentication and session authorization using<br>&gt=3B RADIUS=2C=
 i.e. we like to ask a RADIUS server to verify the user<br>&gt=3B credentia=
ls (e.g. password) and to authorize the user to use a<br>&gt=3B specific su=
bsystem. Unfortunately=2C by the time we have to authenticate<br>&gt=3B the=
 user (step 2) above)=2C we do not yet know which subsystem will be<br>&gt=
=3B requested (step 3) above).<br>&gt=3B <br>&gt=3B We have been considerin=
g ways to "guess" the subsystem the user will<br>&gt=3B ask for (e.g. by ru=
nning SSH on a separate port number) but all this<br>&gt=3B looks fragile a=
nd architecturally very obscure. Since I am sure we are<br>&gt=3B not the f=
irst ones to run into such an issue=2C I thought I ask the<br>&gt=3B expert=
s to give us advice how RADIUS can help us to achieve what we<br>&gt=3B wan=
t.<br>&gt=3B <br>&gt=3B /js<br>&gt=3B <br>&gt=3B -- <br>&gt=3B Juergen Scho=
enwaelder           Jacobs University Bremen gGmbH<br>&gt=3B Phone: +49 421=
 200 3587         Campus Ring 1=2C 28759 Bremen=2C Germany<br>&gt=3B Fax:  =
 +49 421 200 3103         &lt=3Bhttp://www.jacobs-university.de/&gt=3B<br>&=
gt=3B <br>&gt=3B ----- End forwarded message -----<br>&gt=3B <br>&gt=3B -- =
<br>&gt=3B Juergen Schoenwaelder           Jacobs University Bremen gGmbH<b=
r>&gt=3B Phone: +49 421 200 3587         Campus Ring 1=2C 28759 Bremen=2C G=
ermany<br>&gt=3B Fax:   +49 421 200 3103         &lt=3Bhttp://www.jacobs-un=
iversity.de/&gt=3B<br> 		 	   		  </body>
</html>=

--_2486febf-345c-4a28-9745-5f49422b9751_--

Delivery-date: Mon, 22 Nov 2010 20:49:38 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, radext mailing list <[email-masked]>, radext chair <[email-masked]>
Subject: Protocol Action: 'RADIUS Design Guidelines' to BCP (draft-ietf-radext-design-19.txt)
Date: Mon, 22 Nov 2010 12:47:38 -0800

The IESG has approved the following document:
- 'RADIUS Design Guidelines'
  (draft-ietf-radext-design-19.txt) as a BCP

This document is the product of the RADIUS EXTensions Working Group.

The IESG contact persons are Dan Romascanu and Ron Bonica.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-radext-design/

Technical Summary

  This document provides guidelines for the design of attributes used
  by the Remote Authentication Dial In User Service (RADIUS) protocol.
  It is expected that these guidelines will prove useful to authors and
  reviewers of future RADIUS attribute specifications, both within the
  IETF as well as other Standards Development Organizations (SDOs). 

Working Group Summary

    There have been 2 WGLCs on the document.  Much of the discussion on
    the document has centered around the design guidelines 
    surrounding complex attributes, as well as the relationship of the
    RADIUS Vendor-Specific Attribute (VSA) and the Standard attribute
    space.  There was also considerable discussion relating to the
    process for review of RADIUS attributes specified by SDOs.  
    Ultimately, a consensus developed behind a model similar to that
    described in [RFC4663].

Document Quality

   This is a BCP aiming to help authors and reviewers of future RADIUS  
   attribute specifications. The RADIUS protocol is widely implemented and
   deployed. The document was extensively discussed in the Working Group
   and underwent two IETF Last Calls. Gonzalo Camarillow reviewed the  
   document for GenART.  

Personnel

   Bernard Aboba is the Document Shepherd, Dan Romascanu is the 
   Responsible Area Director. 

Delivery-date: Mon, 22 Nov 2010 02:12:48 +0000
Date: Mon, 22 Nov 2010 10:10:05 +0800
From: Sheng Jiang <[email-masked]>
Subject: FW: [Softwires] I-D Action:draft-ietf-softwire-6rd-radius-attrib-01.txt
To: [email-masked]
Cc: [email-masked], 'Da-Yong GUO' <[email-masked]>

This is a multi-part message in MIME format.

--Boundary_(ID_oz2WfAEcai2DjHhWd5up6Q)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

The authors have updated this draft according to reviewing from RADEXT work group. All received
comments are addressed. 

Furthre comments and reviewing are welcome.

Best regards,

Dayong & Sheng

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Monday, November 22, 2010 10:00 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Softwires] I-D 
> Action:draft-ietf-softwire-6rd-radius-attrib-01.txt
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Softwires Working Group of the IETF.
> 
> 
> 	Title           : RADIUS Attribute for 6rd
> 	Author(s)       : D. Guo, S. Jiang
> 	Filename        : draft-ietf-softwire-6rd-radius-attrib-01.txt
> 	Pages           : 8
> 	Date            : 2010-11-21
> 
> 6rd is One of the most popular methods to provide both IPv4 
> and IPv6 connectivity services simultaneously during the 
> IPv4/IPv6 co-existing period. The DHCP 6rd option has been 
> defined to configure 6rd CPE. 
> But in many networks, the configuration information may be 
> stored in AAA servers while user configuration is mainly from 
> Broadband Network Gateway (BNG) through DHC protocol. This 
> document defines a RADIUS attribute that carries 6rd 
> configuration information from AAA server to BNG.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-softwire-6rd-ra
> dius-attrib-01.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
> 

--Boundary_(ID_oz2WfAEcai2DjHhWd5up6Q)
Content-type: Message/External-body;
 name=draft-ietf-softwire-6rd-radius-attrib-01.txt
Content-transfer-encoding: 7bit
Content-disposition: attachment;
 filename=draft-ietf-softwire-6rd-radius-attrib-01.txt

Content-Type: text/plain
Content-ID: <[email-masked]>

--Boundary_(ID_oz2WfAEcai2DjHhWd5up6Q)
Content-type: text/plain; name=ATT00097.txt
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename=ATT00097.txt

_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

--Boundary_(ID_oz2WfAEcai2DjHhWd5up6Q)--

Delivery-date: Sun, 21 Nov 2010 09:09:35 +0000
Content-class: urn:content-classes:message
Subject: draft-ietf-radext-design-19 was approved by the IESG
Date: Sun, 21 Nov 2010 10:07:29 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "radext mailing list" <[email-masked]>

In the 11/19 telechat the IESG approved draft-ietf-radext-design-19 as
BCP.=20

Congratulations and thanks to the editors and chairs for the work
invested in this document which went through a long and complicated
road, congratulations to all the people who participated in the
discussions and contributed with their texts and comments for making it
better, and to the whole Working Group for having eventually achieved
this important milestone.=20

Dan

Delivery-date: Thu, 18 Nov 2010 02:22:16 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: FW: [IANA #407397] General Request for Assignments (radius-types) 
Date: Wed, 17 Nov 2010 21:23:14 -0500

------=_NextPart_000_0063_01CB869D.A5E951B0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Any reason why a new value of Acct-Terminate-Cause shouldn't be assigned =
as requested below?

-----Original Message-----
From: Amanda Baber via RT [mailto:[email-masked]]=20
Sent: Wednesday, November 17, 2010 2:45 PM
Cc: [email-masked]
Subject: [IANA #407397] General Request for Assignments (radius-types)=20

Hi,

Can you review this request for an Acct-Terminate-Cause value? The =
applicant's supporting document is attached.

Thanks,

Amanda Baber
IANA

=3D=3D=3D

Hi Amanda,

Thank you for your quick response.  Please assign the next available =
number.
Attached our contribution to the IEEE 802.16p standard, which explains =
the overall requirements and flows for power outage requirement that =
includes the AAA extension for Acct-Terminate-Cause.

Please let me know if you need any additional details.

Thanks,
Ram

-----Original Message-----
From: Amanda Baber via RT [mailto:[email-masked]]
Sent: Tuesday, November 16, 2010 6:14 PM
To: Ramprasad Golla
Subject: [IANA #407397] General Request for Assignments (radius-types)=20

Dear Ramprasad Golla,

Value 19 has already been defined in the Acct-Terminate-Cause registry.
Please see

http://www.iana.org/assignments/radius-types/radius-types.xhtml

Per RFC 3575 (which updates RFC 2865), registration requests must be =
approved by an IESG-designated expert. Do you have a specification or =
any other kind of supporting documentation we can send to the expert for =
review?

Thanks,

Amanda Baber
IANA

On Mon Nov 15 20:30:20 2010, [email-masked] wrote:
> Contact Name :
> Ramprasad Golla
>=20
> Contact Email :
> [email-masked]
>=20
> Type of Assignment :
> IETF RFC 2866 in section 5.10 defines the attribute Acct-Terminate-
>    Cause to indicate how the session is terminated.  The value filed
>    for Acct-Terminate-Cause is four octets and currently has 18 causes
>    defined.  We need to extend this cause to indicate session
>    termination due to power failure. =20
> Please register, 19 as =E2=80=9CLost
>    Power=E2=80=9D cause for Acct-Terminate-Cause
>=20
>=20
> Registry :
> Protocol registry, especially related to AAA (RADIUS) standards IETF
>    RFC 2866
>=20
> Description :
> In machine to machine networks, status of power outage is very
>    important.  Currently, AAA session termination cause does not
>    include Lost Power as a cause.  Without this explicit cause, it is
>    not possible to deterministically identify the communication outage
>    due to power outage.
>=20
> Additional Info :
> IETF RFC 2866 for AAA (RADIUS)
>=20

------=_NextPart_000_0063_01CB869D.A5E951B0
Content-Type: application/msword; name="C80216p-10_0005.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="C80216p-10_0005.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAA5QAAAAAAAAAA
EAAA5wAAAAEAAAD+////AAAAAOMAAADkAAAA////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

------=_NextPart_000_0063_01CB869D.A5E951B0--

Delivery-date: Wed, 17 Nov 2010 03:03:00 +0000
Date: Wed, 17 Nov 2010 11:00:01 +0800
From: Sheng Jiang <[email-masked]>
Subject: RE: Reviewing is needed, FW: New Version Notification for draft-ietf-softwire-6rd-radius-attrib-00
To: 'Alan DeKok' <[email-masked]>
Cc: 'Bernard Aboba' <[email-masked]>, [email-masked], [email-masked]

Hi, Alan,

"IPv6-6rd-Configuration" sounds good for us. We will use it in the next version.

Thanks and best regards,

Sheng

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Tuesday, November 16, 2010 6:29 PM
> To: Sheng Jiang
> Cc: 'Bernard Aboba'; [email-masked]; [email-masked]
> Subject: Re: Reviewing is needed, FW: New Version 
> Notification for draft-ietf-softwire-6rd-radius-attrib-00
> 
> Sheng Jiang wrote:
> > Thanks so much for your valuable comments. Most of them are 
> addressed 
> > in the next version. A couple of explanation is below.
> > 
> > We rename the attribute "6rd-Configuration". 6rd is a term 
> for "IPv6 rapid deployment mechanism".
> > It cannot be replaced by other name.
> 
>   That makes no sense.  The name has *no* impact on the 
> protocol.  It could be named "XYZ-Foo", and still have the 
> same functionality.
> 
>   The name *does* have impact on administrators of RADIUS 
> systems, and implementors of RADIUS specifications.  Using a 
> name that follows existing RADIUS naming practices is a good 
> idea.  The above name does
> *not* follow existing RADIUS naming practices.
> 
>   Again, using a name such as "IPv6-RD-Configuration", or 
> "IPv6-6rd-Configuration" *would* follow existing RADIUS 
> naming practices, with no loss of functionality or clarity.
> 
> > We have edited the length description like below, hope it is ok.
> > 
> > "20 + n*4 (the length of the entire attribute in octets; n 
> stands the 
> > number of BR IPv4 addresses, minimum n is 1)."
> 
>   That's fine.
> 
>   Alan DeKok.

Delivery-date: Tue, 16 Nov 2010 10:29:40 +0000
Date: Tue, 16 Nov 2010 11:29:09 +0100
From: Alan DeKok <[email-masked]>
To: Sheng Jiang <[email-masked]>
CC: 'Bernard Aboba' <[email-masked]>, [email-masked],  [email-masked]
Subject: Re: Reviewing is needed, FW: New Version Notification for draft-ietf-softwire-6rd-radius-attrib-00

Sheng Jiang wrote:
> Thanks so much for your valuable comments. Most of them are addressed in the next version. A couple
> of explanation is below. 
> 
> We rename the attribute "6rd-Configuration". 6rd is a term for "IPv6 rapid deployment mechanism".
> It cannot be replaced by other name.

  That makes no sense.  The name has *no* impact on the protocol.  It
could be named "XYZ-Foo", and still have the same functionality.

  The name *does* have impact on administrators of RADIUS systems, and
implementors of RADIUS specifications.  Using a name that follows
existing RADIUS naming practices is a good idea.  The above name does
*not* follow existing RADIUS naming practices.

  Again, using a name such as "IPv6-RD-Configuration", or
"IPv6-6rd-Configuration" *would* follow existing RADIUS naming
practices, with no loss of functionality or clarity.

> We have edited the length description like below, hope it is ok.
> 
> "20 + n*4 (the length of the entire attribute in octets; n stands the number of BR IPv4 addresses,
> minimum n is 1)."

  That's fine.

  Alan DeKok.

Delivery-date: Tue, 16 Nov 2010 09:34:56 +0000
Date: Tue, 16 Nov 2010 17:33:43 +0800
From: Sheng Jiang <[email-masked]>
Subject: RE: Reviewing is needed, FW: New Version Notification for draft-ietf-softwire-6rd-radius-attrib-00
To: 'Alan DeKok' <[email-masked]>
Cc: 'Bernard Aboba' <[email-masked]>, [email-masked], [email-masked]

Hi, Alan,

Thanks so much for your valuable comments. Most of them are addressed in the next version. A couple
of explanation is below. 

We rename the attribute "6rd-Configuration". 6rd is a term for "IPv6 rapid deployment mechanism".
It cannot be replaced by other name.

We have edited the length description like below, hope it is ok.

"20 + n*4 (the length of the entire attribute in octets; n stands the number of BR IPv4 addresses,
minimum n is 1)."

Many thanks and best regards,

Sheng + Dayong

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Tuesday, November 16, 2010 4:51 PM
> To: Sheng Jiang
> Cc: 'Bernard Aboba'; [email-masked]; [email-masked]
> Subject: Re: Reviewing is needed, FW: New Version 
> Notification for draft-ietf-softwire-6rd-radius-attrib-00
> 
> Sheng Jiang wrote:
> > Thanks, Bernard. We were aware the Design Guidelines 
> document. We have 
> > followed the guidelines, also refer to exist radius RFCs. We still 
> > like to get reviews by RADIUS experts in case, we have 
> missed any thing.
> 
>   Editorial:
> 
> * Section 3
> 
>    The below Figure 1 illustrates how the RADIUS protocol and DHCP are
>    cooperated to provide users/hosts with 6rd configuration.
>    ...
> 
>   English nit: "are cooperated" is not correct English.  I 
> suggest replacing that phrase with the word "cooperate".
> 
>   Other minor grammatical issues are seen through the 
> document, but do not affect readability.
> 
> 
> * Section 4.1
> 
>   ...
> 4.1. 6rd Attribute
>   ...
> 
>   The attribute needs to be given a unique name, as is done 
> with the attributes in RFC 2865, etc.  See Section 5.1, 5.2, 
> and following of RFC 2865.
> 
>   I suggest a name like "IPv6-RD-Configuration".  Other names 
> are possible.
> 
> 
> * Section 4.1
> 
>       ...
>       Type        TBD
>       ...
> 
>   The fields should be described in a similar manner to previous RFCs:
> 
> 	FIELD
> 
> 	   DESCRIPTION
> 
>   Also, the "Type" field should use the name of the 
> attribute.  See RFC
> 2865 Section 5.1 for an example.
> 
> 
> * Section 4.1
>       ...
>       Length       the length of the DHCP option in octets (22 octets
>                      with one BR IPv4 address).
>        ...
> 
>   It is not a DHCP option.  I suggest deleting that entire sentence.
> 
>   The length should be given in the same manner as the previous RFCs:
> 
>    Length
> 
>       >= 22
> 
> 
> 
> * Section 4.1
> 
>        ...
>        6rdBRIPv4Address    One or more IPv4 addresses of the 
> 6rd Border
>                      Relay(s) for a given 6rd domain.
>        ...
> 
>   It would be good to not that there is a limit on the number 
> of IPv4 addresses.  The maximum RADIUS Attribute length of 
> 255 octets results in a limit of 59 IPv4 addresses.  While 
> this may not be a limitation in practice, it should be noted 
> in the document.
> 
> 
> 
> * Section 4.2
> 
>    Request Accept Reject Challenge Accounting  #  Attribute
>                                     Request
>     0+      0+     0      0         0+        TBD  6rd
> 
> 
>   Again, giving the attribute a useful name is critical.  
> "6rd" is not an acceptable name.
> 
> 
> 
> * Section 7
> 
>    This document requires the assignment of two new RADIUS Attribute
>    ...
> 
>   The document defines only one attribute.  Other text in 
> this section talks about attributeS, also.
> 
> 
> 
>   The attribute uses a non-standard format, without 
> explaining why this format was chosen.  The Guidelines 
> document (Section 1.3, third
> paragraph) suggests such explanations.  Some possible text is:
> 
>   The specification requires that multiple IPv4 addresses are 
> associated
>   strongly with one IPv6 prefix.  Given that RADIUS currently 
> has no recommended way of grouping multiple attributes, the 
> current design appears to be a reasonable compromise.
> 
>   If there was a TLV data type in RADIUS, these attributes 
> would best be placed inside of an encapsulating TLV.
> 
>   Alan DeKok.
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

Delivery-date: Tue, 16 Nov 2010 08:51:24 +0000
Date: Tue, 16 Nov 2010 09:50:52 +0100
From: Alan DeKok <[email-masked]>
To: Sheng Jiang <[email-masked]>
CC: 'Bernard Aboba' <[email-masked]>, [email-masked],  [email-masked]
Subject: Re: Reviewing is needed, FW: New Version Notification for draft-ietf-softwire-6rd-radius-attrib-00

Sheng Jiang wrote:
> Thanks, Bernard. We were aware the Design Guidelines document. We have followed the guidelines,
> also refer to exist radius RFCs. We still like to get reviews by RADIUS experts in case, we have
> missed any thing.

  Editorial:

* Section 3

   The below Figure 1 illustrates how the RADIUS protocol and DHCP are
   cooperated to provide users/hosts with 6rd configuration.
   ...

  English nit: "are cooperated" is not correct English.  I suggest
replacing that phrase with the word "cooperate".

  Other minor grammatical issues are seen through the document, but do
not affect readability.

* Section 4.1

  ...
4.1. 6rd Attribute
  ...

  The attribute needs to be given a unique name, as is done with the
attributes in RFC 2865, etc.  See Section 5.1, 5.2, and following of RFC
2865.

  I suggest a name like "IPv6-RD-Configuration".  Other names are possible.

* Section 4.1

      ...
      Type        TBD
      ...

  The fields should be described in a similar manner to previous RFCs:

	FIELD

	   DESCRIPTION

  Also, the "Type" field should use the name of the attribute.  See RFC
2865 Section 5.1 for an example.

* Section 4.1
      ...
      Length       the length of the DHCP option in octets (22 octets
                     with one BR IPv4 address).
       ...

  It is not a DHCP option.  I suggest deleting that entire sentence.

  The length should be given in the same manner as the previous RFCs:

   Length

      >= 22

* Section 4.1

       ...
       6rdBRIPv4Address    One or more IPv4 addresses of the 6rd Border
                     Relay(s) for a given 6rd domain.
       ...

  It would be good to not that there is a limit on the number of IPv4
addresses.  The maximum RADIUS Attribute length of 255 octets results in
a limit of 59 IPv4 addresses.  While this may not be a limitation in
practice, it should be noted in the document.

* Section 4.2

   Request Accept Reject Challenge Accounting  #  Attribute
                                    Request
    0+      0+     0      0         0+        TBD  6rd

  Again, giving the attribute a useful name is critical.  "6rd" is not
an acceptable name.

* Section 7

   This document requires the assignment of two new RADIUS Attribute
   ...

  The document defines only one attribute.  Other text in this section
talks about attributeS, also.

  The attribute uses a non-standard format, without explaining why this
format was chosen.  The Guidelines document (Section 1.3, third
paragraph) suggests such explanations.  Some possible text is:

  The specification requires that multiple IPv4 addresses are associated
  strongly with one IPv6 prefix.  Given that RADIUS currently has no
recommended way of grouping multiple attributes, the current design
appears to be a reasonable compromise.

  If there was a TLV data type in RADIUS, these attributes would best be
placed inside of an encapsulating TLV.

  Alan DeKok.

Delivery-date: Tue, 16 Nov 2010 07:53:37 +0000
Date: Tue, 16 Nov 2010 15:52:35 +0800
From: Sheng Jiang <[email-masked]>
Subject: RE: Reviewing is needed, FW: New Version Notification for draft-ietf-softwire-6rd-radius-attrib-00
To: 'Bernard Aboba' <[email-masked]>, [email-masked], [email-masked]

Thanks, Bernard. We were aware the Design Guidelines document. We have followed the guidelines,
also refer to exist radius RFCs. We still like to get reviews by RADIUS experts in case, we have
missed any thing.

Regards,

Sheng

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Tuesday, November 16, 2010 12:15 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Reviewing is needed, FW: New Version 
> Notification for draft-ietf-softwire-6rd-radius-attrib-00
> 
> The RADIUS Design Guidelines document specifies guidelines 
> for the design of RADIUS attributes as well as compatibility 
> with the RADIUS protocol:
> http://tools.ietf.org/html/draft-ietf-radext-design
> 
> Please have a look at the document.  In particular, it is 
> expected that prior to requesting review, that documents will 
> have examined their compatibility with the checklist 
> contained in Appendix A. 
> 
> > Date: Tue, 16 Nov 2010 08:56:30 +0800
> > From: [email-masked]
> > Subject: Reviewing is needed, FW: New Version Notification for 
> > draft-ietf-softwire-6rd-radius-attrib-00
> > To: [email-masked]; [email-masked]
> > 
> > Hi, Radext WG,
> > 
> > The softwire WG has juest approved a WG document, 
> > draft-ietf-softwire-6rd-radius-attrib, which defines a 
> RADIUS attribute that carries 6rd configuration information 
> from AAA server to BNG.
> > 
> > We would like to get reviewing from Radext WG to make sure the 
> > compatibility between this draft and RADIUS protocol. Any 
> comments are welcome.
> > 
> > Many thanks and best regards,
> > 
> > Sheng
> > 
> > > -----Original Message-----
> > > From: IETF I-D Submission Tool [mailto:[email-masked]]
> > > Sent: Tuesday, November 16, 2010 2:26 AM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: New Version Notification for 
> > > draft-ietf-softwire-6rd-radius-attrib-00
> > > 
> > > 
> > > A new version of I-D,
> > > draft-ietf-softwire-6rd-radius-attrib-00.txt has been 
> successfully 
> > > submitted by Sheng Jiang and posted to the IETF repository.
> > > 
> > > Filename: draft-ietf-softwire-6rd-radius-attrib
> > > Revision: 00
> > > Title: RADIUS Attribute for 6rd
> > > Creation_date: 2010-11-15
> > > WG ID: softwire
> > > Number_of_pages: 8
> > > 
> > > Abstract:
> > > 6rd is One of the most popular methods to provide both 
> IPv4 and IPv6 
> > > connectivity services simultaneously during the
> > > IPv4/IPv6 co-existing period. The DHCP 6rd option has 
> been defined 
> > > to configure 6rd CPE.
> > > But in many networks, the configuration information may 
> be stored in 
> > > AAA servers while user configuration is mainly from Broadband 
> > > Network Gateway (BNG) through DHC protocol. This document 
> defines a 
> > > RADIUS attribute that carries 6rd configuration 
> information from AAA 
> > > server to BNG.
> > > 
> > > 
> > > 
> > > 
> > > The IETF Secretariat.
> > > 
> > > 
> > 
> > 
> > --

Delivery-date: Tue, 16 Nov 2010 04:15:48 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>, "[email-masked]" <[email-masked]>, <[email-masked]>
Subject: RE: Reviewing is needed, FW: New Version Notification for draft-ietf-softwire-6rd-radius-attrib-00
Date: Mon, 15 Nov 2010 20:14:53 -0800

--_9362cc24-c2f1-4b04-b6db-d27e555b7295_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The RADIUS Design Guidelines document specifies guidelines for the design o=
f RADIUS attributes as well
as compatibility with the RADIUS protocol:
http://tools.ietf.org/html/draft-ietf-radext-design

Please have a look at the document.  In particular=2C it is expected that p=
rior to requesting review=2C that documents=20
will have examined their compatibility with the checklist contained in Appe=
ndix A.=20

> Date: Tue=2C 16 Nov 2010 08:56:30 +0800
> From: [email-masked]
> Subject: Reviewing is needed=2C FW: New Version Notification for draft-ie=
tf-softwire-6rd-radius-attrib-00
> To: [email-masked]=3B [email-masked]
>=20
> Hi=2C Radext WG=2C
>=20
> The softwire WG has juest approved a WG document=2C draft-ietf-softwire-6=
rd-radius-attrib=2C which
> defines a RADIUS attribute that carries 6rd configuration information fro=
m AAA server to BNG.
>=20
> We would like to get reviewing from Radext WG to make sure the compatibil=
ity between this draft and
> RADIUS protocol. Any comments are welcome.
>=20
> Many thanks and best regards=2C
>=20
> Sheng
>=20
> > -----Original Message-----
> > From: IETF I-D Submission Tool [mailto:[email-masked]]=20
> > Sent: Tuesday=2C November 16=2C 2010 2:26 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: New Version Notification for=20
> > draft-ietf-softwire-6rd-radius-attrib-00
> >=20
> >=20
> > A new version of I-D=2C=20
> > draft-ietf-softwire-6rd-radius-attrib-00.txt has been=20
> > successfully submitted by Sheng Jiang and posted to the IETF=20
> > repository.
> >=20
> > Filename:	 draft-ietf-softwire-6rd-radius-attrib
> > Revision:	 00
> > Title:		 RADIUS Attribute for 6rd
> > Creation_date:	 2010-11-15
> > WG ID:		 softwire
> > Number_of_pages: 8
> >=20
> > Abstract:
> > 6rd is One of the most popular methods to provide both IPv4=20
> > and IPv6 connectivity services simultaneously during the=20
> > IPv4/IPv6 co-existing period. The DHCP 6rd option has been=20
> > defined to configure 6rd CPE.=20
> > But in many networks=2C the configuration information may be=20
> > stored in AAA servers while user configuration is mainly from=20
> > Broadband Network Gateway (BNG) through DHC protocol. This=20
> > document defines a RADIUS attribute that carries 6rd=20
> > configuration information from AAA server to BNG.
> >                                                              =20
> >                    =20
> >=20
> >=20
> > The IETF Secretariat.
> >=20
> >=20
>=20
>=20
> --
 		 	   		  =

--_9362cc24-c2f1-4b04-b6db-d27e555b7295_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style>
</head>
<body class=3D'hmmessage'>
The RADIUS Design Guidelines document specifies guidelines for the design o=
f RADIUS attributes as well<br>as compatibility with the RADIUS protocol:<b=
r>http://tools.ietf.org/html/draft-ietf-radext-design<br><br>Please have a =
look at the document.&nbsp=3B In particular=2C it is expected that prior to=
 requesting review=2C that documents <br>will have examined their compatibi=
lity with the checklist contained in Appendix A. <br><br>&gt=3B Date: Tue=
=2C 16 Nov 2010 08:56:30 +0800<br>&gt=3B From: [email-masked]<br>&gt=
=3B Subject: Reviewing is needed=2C FW: New Version Notification for draft-=
ietf-softwire-6rd-radius-attrib-00<br>&gt=3B To: [email-masked]=3B =
[email-masked]<br>&gt=3B <br>&gt=3B Hi=2C Radext WG=2C<br>&gt=3B <br>&g=
t=3B The softwire WG has juest approved a WG document=2C draft-ietf-softwir=
e-6rd-radius-attrib=2C which<br>&gt=3B defines a RADIUS attribute that carr=
ies 6rd configuration information from AAA server to BNG.<br>&gt=3B <br>&gt=
=3B We would like to get reviewing from Radext WG to make sure the compatib=
ility between this draft and<br>&gt=3B RADIUS protocol. Any comments are we=
lcome.<br>&gt=3B <br>&gt=3B Many thanks and best regards=2C<br>&gt=3B <br>&=
gt=3B Sheng<br>&gt=3B <br>&gt=3B &gt=3B -----Original Message-----<br>&gt=
=3B &gt=3B From: IETF I-D Submission Tool [mailto:[email-masked]] <b=
r>&gt=3B &gt=3B Sent: Tuesday=2C November 16=2C 2010 2:26 AM<br>&gt=3B &gt=
=3B To: [email-masked]<br>&gt=3B &gt=3B Cc: [email-masked]<br>&gt=
=3B &gt=3B Subject: New Version Notification for <br>&gt=3B &gt=3B draft-ie=
tf-softwire-6rd-radius-attrib-00<br>&gt=3B &gt=3B <br>&gt=3B &gt=3B <br>&gt=
=3B &gt=3B A new version of I-D=2C <br>&gt=3B &gt=3B draft-ietf-softwire-6r=
d-radius-attrib-00.txt has been <br>&gt=3B &gt=3B successfully submitted by=
 Sheng Jiang and posted to the IETF <br>&gt=3B &gt=3B repository.<br>&gt=3B=
 &gt=3B <br>&gt=3B &gt=3B Filename:	 draft-ietf-softwire-6rd-radius-attrib<=
br>&gt=3B &gt=3B Revision:	 00<br>&gt=3B &gt=3B Title:		 RADIUS Attribute f=
or 6rd<br>&gt=3B &gt=3B Creation_date:	 2010-11-15<br>&gt=3B &gt=3B WG ID:	=
	 softwire<br>&gt=3B &gt=3B Number_of_pages: 8<br>&gt=3B &gt=3B <br>&gt=3B =
&gt=3B Abstract:<br>&gt=3B &gt=3B 6rd is One of the most popular methods to=
 provide both IPv4 <br>&gt=3B &gt=3B and IPv6 connectivity services simulta=
neously during the <br>&gt=3B &gt=3B IPv4/IPv6 co-existing period. The DHCP=
 6rd option has been <br>&gt=3B &gt=3B defined to configure 6rd CPE. <br>&g=
t=3B &gt=3B But in many networks=2C the configuration information may be <b=
r>&gt=3B &gt=3B stored in AAA servers while user configuration is mainly fr=
om <br>&gt=3B &gt=3B Broadband Network Gateway (BNG) through DHC protocol. =
This <br>&gt=3B &gt=3B document defines a RADIUS attribute that carries 6rd=
 <br>&gt=3B &gt=3B configuration information from AAA server to BNG.<br>&gt=
=3B &gt=3B                                                               <b=
r>&gt=3B &gt=3B                     <br>&gt=3B &gt=3B <br>&gt=3B &gt=3B <br=
>&gt=3B &gt=3B The IETF Secretariat.<br>&gt=3B &gt=3B <br>&gt=3B &gt=3B <br=
>&gt=3B <br>&gt=3B <br>&gt=3B --<br>&gt=3B to unsubscribe send a message to=
 [email-masked] with<br>&gt=3B the word 'unsubscribe' in a =
single line as the message text body.<br>&gt=3B archive: &lt=3Bhttp://psg.c=
om/lists/radiusext/&gt=3B<br> 		 	   		  </body>
</html>=

--_9362cc24-c2f1-4b04-b6db-d27e555b7295_--

Delivery-date: Tue, 16 Nov 2010 00:57:41 +0000
Date: Tue, 16 Nov 2010 08:56:30 +0800
From: Sheng Jiang <[email-masked]>
Subject: Reviewing is needed, FW: New Version Notification for draft-ietf-softwire-6rd-radius-attrib-00
To: [email-masked], 'Softwires list' <[email-masked]>

Hi, Radext WG,

The softwire WG has juest approved a WG document, draft-ietf-softwire-6rd-radius-attrib, which
defines a RADIUS attribute that carries 6rd configuration information from AAA server to BNG.

We would like to get reviewing from Radext WG to make sure the compatibility between this draft and
RADIUS protocol. Any comments are welcome.

Many thanks and best regards,

Sheng

> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:[email-masked]] 
> Sent: Tuesday, November 16, 2010 2:26 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: New Version Notification for 
> draft-ietf-softwire-6rd-radius-attrib-00
> 
> 
> A new version of I-D, 
> draft-ietf-softwire-6rd-radius-attrib-00.txt has been 
> successfully submitted by Sheng Jiang and posted to the IETF 
> repository.
> 
> Filename:	 draft-ietf-softwire-6rd-radius-attrib
> Revision:	 00
> Title:		 RADIUS Attribute for 6rd
> Creation_date:	 2010-11-15
> WG ID:		 softwire
> Number_of_pages: 8
> 
> Abstract:
> 6rd is One of the most popular methods to provide both IPv4 
> and IPv6 connectivity services simultaneously during the 
> IPv4/IPv6 co-existing period. The DHCP 6rd option has been 
> defined to configure 6rd CPE. 
> But in many networks, the configuration information may be 
> stored in AAA servers while user configuration is mainly from 
> Broadband Network Gateway (BNG) through DHC protocol. This 
> document defines a RADIUS attribute that carries 6rd 
> configuration information from AAA server to BNG.
>                                                               
>                     
> 
> 
> The IETF Secretariat.
> 
> 

Delivery-date: Thu, 11 Nov 2010 18:45:53 +0000
Date: Thu, 11 Nov 2010 19:47:43 +0100
From: Stefan Winter <[email-masked]>
To: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: call for slides

This is a multi-part message in MIME format.
--------------060607010007050803020704
Content-Type: multipart/alternative;
 boundary="------------010400040603060304010406"

--------------010400040603060304010406
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

attached are the slides for RADIUS/TLS and Dynamic Discovery. I'll be 
ready on Skype from approx 0900 onwards (stefan.winter.78).

Greetings,

Stefan Winter

Am 10.11.10 22:45, schrieb Sanchez, Mauricio (HP Networking):
>
> If you are presenting tomorrow, please send me your slides in the next 
> 12 hours or so.
>
> Cheers,
>
> MS
>

--------------010400040603060304010406
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Hi,<br>
    <br>
    attached are the slides for RADIUS/TLS and Dynamic Discovery. I'll
    be ready on Skype from approx 0900 onwards (stefan.winter.78).<br>
    <br>
    Greetings,<br>
    <br>
    Stefan Winter<br>
    <br>
    Am 10.11.10 22:45, schrieb Sanchez, Mauricio (HP Networking):
    <blockquote
cite="mid:[email-masked]"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="Microsoft Word 14 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal">If you are presenting tomorrow, please send
          me your slides in the next 12 hours or so. <o:p></o:p></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        <p class="MsoNormal">Cheers,<o:p></o:p></p>
        <p class="MsoNormal">MS<span style="font-size: 10pt;
            font-family: &quot;Verdana&quot;,&quot;sans-serif&quot;;"><o:p></o:p></span></p>
        <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------010400040603060304010406--

--------------060607010007050803020704
Content-Type: application/pdf;
 name="ietf-79-radius-dyndisc.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="ietf-79-radius-dyndisc.pdf"

--------------060607010007050803020704
Content-Type: application/pdf;
 name="ietf-79-radius-tls.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="ietf-79-radius-tls.pdf"

--------------060607010007050803020704--

Delivery-date: Wed, 10 Nov 2010 21:47:56 +0000
From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 10 Nov 2010 21:45:09 +0000
Subject: call for slides 
Accept-Language: en-US
acceptlanguage: en-US

------=_NextPart_000_00B4_01CB8163.99FB9BE0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_00B5_01CB8163.99FB9BE0"

------=_NextPart_001_00B5_01CB8163.99FB9BE0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

If you are presenting tomorrow, please send me your slides in the next 12
hours or so. 

Cheers,

MS

------=_NextPart_001_00B5_01CB8163.99FB9BE0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META =
HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>If you are =
presenting tomorrow, please send me your slides in the next 12 hours or =
so. <o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>Cheers,<o:p></o:p></p><p class=3DMsoNormal>MS<span =
style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p></o:p>=
</span></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></body></html>
------=_NextPart_001_00B5_01CB8163.99FB9BE0--

------=_NextPart_000_00B4_01CB8163.99FB9BE0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

------=_NextPart_000_00B4_01CB8163.99FB9BE0--

Delivery-date: Tue, 09 Nov 2010 22:08:52 +0000
From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 9 Nov 2010 22:06:58 +0000
Subject: RE: Remote Presentation Arrangements for IETF 79
Accept-Language: en-US
acceptlanguage: en-US

------=_NextPart_000_004B_01CB809D.7B8E1140
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_004C_01CB809D.7B8E3850"

------=_NextPart_001_004C_01CB809D.7B8E3850
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Second call for Skype account information, if you are presenting remotely. 

Thank you,

Mauricio 

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bernard Aboba
Sent: Monday, November 01, 2010 1:36 AM
To: [email-masked]
Subject: Remote Presentation Arrangements for IETF 79

Since many of the participants will not be attending IETF 79 (including
myself), the RADEXT WG meeting will include support for remote presentation.

We are looking at a combination of WebEx (for remote slide presentation) and
Skype (for audio). 

If you are listed on the agenda to present and will not be attending the
Beijing meeting in person, please send your Skype account to myself and
Mauricio.   

------=_NextPart_001_004C_01CB809D.7B8E3850
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META =
HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Second call for Skype account information, if =
you are presenting remotely. <o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span style=3D'color:#1F497D'>Thank =
you,<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'color:#1F497D'>Mauricio <o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div =
style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'><p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
[email-masked] [mailto:[email-masked]] <b>On =
Behalf Of </b>Bernard Aboba<br><b>Sent:</b> Monday, November 01, 2010 =
1:36 AM<br><b>To:</b> [email-masked]<br><b>Subject:</b> Remote =
Presentation Arrangements for IETF =
79<o:p></o:p></span></p></div></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Since many =
of the participants will not be attending IETF 79 (including myself), =
the RADEXT WG meeting will include support for remote presentation. =
<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>We are looking at a combination of WebEx (for remote =
slide presentation) and Skype (for audio). <o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>If you are =
listed on the agenda to present and will not be attending the Beijing =
meeting in person, please send your Skype account to myself and =
Mauricio.&nbsp; &nbsp;<o:p></o:p></p></div></body></html>
------=_NextPart_001_004C_01CB809D.7B8E3850--

------=_NextPart_000_004B_01CB809D.7B8E1140
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

------=_NextPart_000_004B_01CB809D.7B8E1140--

Delivery-date: Tue, 09 Nov 2010 22:08:16 +0000
From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 9 Nov 2010 22:05:29 +0000
Subject: RADEXT WG Agenda for IETF 79 - Take Two
Accept-Language: en-US
acceptlanguage: en-US

RADEXT WG IETF 79 Agenda

Chairs:
Bernard Aboba <bernard_aboba at hotmail.com>
Mauricio Sanchez <mauricio.sanchez at hp.com>

Jabber room:  radext at jabber.ietf.org (Please join)

Friday November 12, 2010

0900 - 1130

Emerald Room

 0900-0920 Preliminaries (20 minutes)
 Blue sheets, Note takers, Jabber scribe
 Agenda Bash
 Document status

 0920-0930 Hot Errata (10 minutes)

 Documents completing last IETF Call (20 minutes)
 0930-0940: RADIUS over TCP, Alan DeKok (10 minutes)
 http://tools.ietf.org/html/draft-ietf-radext-tcp

 0940-0950: Design Guidelines, Alan DeKok (10 minutes)
 http://tools.ietf.org/html/draft-ietf-radext-design/

 WG Work Items (50 minutes)
 0950-1010: RADIUS over TLS, Stefan Winter (20 minutes)
 http://tools.ietf.org/html/draft-ietf-radext-radsec

 1010-1030: Dynamic Peer Discovery, Stefan Winter (20 minutes)
 http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

 1030-1040: RADIUS over DTLS, Alan DeKok or Stefan W. (10 min)
 http://tools.ietf.org/html/draft-ietf-radext-dtls

Individual Submissions (30 minutes)
1040-1110:  Extended Attributes, Alan DeKok (30 minutes)
http://tools.ietf.org/html/draft-ietf-radext-extended-attributes
Discussion and Wrap-up (20 minutes)

1110-1120 Discussion (10 minutes)

1120-1130 Next Steps: WG Chairs & AD (10 minutes)

Delivery-date: Tue, 09 Nov 2010 02:18:13 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-design-19.txt
Date: Mon, 08 Nov 2010 18:15:40 -0800

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : RADIUS Design Guidelines
	Author(s)       : G. Weber, A. DeKok
	Filename        : draft-ietf-radext-design-19.txt
	Pages           : 38
	Date            : 2010-11-08

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-19.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-radext-design-19.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Delivery-date: Mon, 08 Nov 2010 19:46:24 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-design-19.txt
Date: Mon, 08 Nov 2010 11:45:01 -0800

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : RADIUS Design Guidelines
	Author(s)       : G. Weber, A. DeKok
	Filename        : draft-ietf-radext-design-19.txt
	Pages           : 38
	Date            : 2010-11-08

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-19.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-design-19.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--