[radext] #77: Section 2

["radext issue tracker" <[e-mail]>]

#77: Section 2

 "Multi-homing" is a layer 3 concept, so "multihomed at layer 2" doesn't
 parse.  RADIUS is an acronym so it is capitalized.  Recommend that this
 section be rewritten as follows:

 2.  Deployment Scenarios

    A common broadband network scenario is illustrated in Figure 1.  It
    is composed of a IP Routing Residential Gateway (RG) or host, a Layer
    2 Access-Node (e.g. a DSLAM), one or more IP Network Access Servers
    (NASes), and an AAA server.  The RG or host are expected to be multi
    homed to both NASes.  Layer 2 Connectivity between the
    host and NAS can be either via PPPoE or IP over Ethernet, and
    established dynamically.

                                                    +-----+
                                    (RADIUS server) | AAA |
                                        ...........>|     |
                                        .           +--+--+
                                        v              ^
                                    +---+---+          .
                                    |  NAS  |          .(RADIUS server)
                                    |       |          .
                                    +---+---+          v
                     +------+           |          +---+---+
      +------+       |  AN  |           |          |  NAS  |
      |  RG/ +-------|      +-----------+----------+       |
      | host |       |      |                      |       |
      +------+ (DSL) +------+      (Ethernet)      +-------+

                               Figure 1

    In this scenario the NASes may embed a DHCPv6 server to handle
    DHCPv6 requests issued by RGs/hosts, as well as acting as a
    router providing Router Advertisements.  The RADIUS server
    authenticates each RG/host and returns to the NAS attributes
    used for authorization and accounting.  These attributes
    can include a host IPv6 address to be configured via DHCPv6;
    the IPv6 address of a DNS server to configured via DHCPv6 or
    router advertisement; the name of a prefix pool to be used
    for DHCPv6 Prefix Delegation; or IPv6 routes to be announced
    to the host.

    The following sub-sections discuss how these uses in more
    detail.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  wdec@…        
     Type:  defect                     |      Status:  new           
 Priority:  major                      |   Milestone:  milestone1    
Component:  ipv6-access                |     Version:  1.0           
 Severity:  In WG Last Call            |    Keywords:                
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/77>
radext <http://tools.ietf.org/radext/>


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

Envelope-to: [e-mail]
Delivery-date: Mon, 28 Feb 2011 03:11:21 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail], [e-mail]
Date: Mon, 28 Feb 2011 03:10:46 -0000
Reply-To: [e-mail]
Subject: [radext] #77: Section 2
Message-ID: <[e-mail]>

#77: Section 2

 "Multi-homing" is a layer 3 concept, so "multihomed at layer 2" doesn't
 parse.  RADIUS is an acronym so it is capitalized.  Recommend that this
 section be rewritten as follows:

 2.  Deployment Scenarios

    A common broadband network scenario is illustrated in Figure 1.  It
    is composed of a IP Routing Residential Gateway (RG) or host, a Layer
    2 Access-Node (e.g. a DSLAM), one or more IP Network Access Servers
    (NASes), and an AAA server.  The RG or host are expected to be multi
    homed to both NASes.  Layer 2 Connectivity between the
    host and NAS can be either via PPPoE or IP over Ethernet, and
    established dynamically.

                                                    +-----+
                                    (RADIUS server) | AAA |
                                        ...........>|     |
                                        .           +--+--+
                                        v              ^
                                    +---+---+          .
                                    |  NAS  |          .(RADIUS server)
                                    |       |          .
                                    +---+---+          v
                     +------+           |          +---+---+
      +------+       |  AN  |           |          |  NAS  |
      |  RG/ +-------|      +-----------+----------+       |
      | host |       |      |                      |       |
      +------+ (DSL) +------+      (Ethernet)      +-------+

                               Figure 1

    In this scenario the NASes may embed a DHCPv6 server to handle
    DHCPv6 requests issued by RGs/hosts, as well as acting as a
    router providing Router Advertisements.  The RADIUS server
    authenticates each RG/host and returns to the NAS attributes
    used for authorization and accounting.  These attributes
    can include a host IPv6 address to be configured via DHCPv6;
    the IPv6 address of a DNS server to configured via DHCPv6 or
    router advertisement; the name of a prefix pool to be used
    for DHCPv6 Prefix Delegation; or IPv6 routes to be announced
    to the host.

    The following sub-sections discuss how these uses in more
    detail.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  wdec@…        
     Type:  defect                     |      Status:  new           
 Priority:  major                      |   Milestone:  milestone1    
Component:  ipv6-access                |     Version:  1.0           
 Severity:  In WG Last Call            |    Keywords:                
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/77>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 28 Feb 2011 02:39:35 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail], [e-mail]
Date: Mon, 28 Feb 2011 02:39:18 -0000
Reply-To: [e-mail]
Subject: [radext] #76: Section 6
Message-ID: <[e-mail]>

#76: Section 6

 IANA should allocate these numbers from the standard RADIUS
    Attributes space using the "IETF Review" policy [RFC5226].

 RFC 3575 governs the allocation of attributes from the standards space,
 not RFC 5226.  Since this document does not Update RFC 3575, this sentence
 can be deleted.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  wdec@…        
     Type:  defect                     |      Status:  new           
 Priority:  major                      |   Milestone:  milestone1    
Component:  ipv6-access                |     Version:  1.0           
 Severity:  In WG Last Call            |    Keywords:                
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/76>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 28 Feb 2011 02:35:49 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail], [e-mail]
Date: Mon, 28 Feb 2011 02:35:30 -0000
Reply-To: [e-mail]
Subject: [radext] #75: Section 3.6
Message-ID: <[e-mail]>

#75: Section 3.6

 This section confuses rather than clarifies the difference in intended
 uses between Framed-IPv6-Address and the Framed-IPv6-Prefix attribute.
 Since this section adds no information that shouldn't already be provided
 elsewhere, it can be deleted.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  wdec@…        
     Type:  defect                     |      Status:  new           
 Priority:  blocker                    |   Milestone:  milestone1    
Component:  ipv6-access                |     Version:  1.0           
 Severity:  In WG Last Call            |    Keywords:                
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/75>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 28 Feb 2011 02:31:16 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail], [e-mail]
Date: Mon, 28 Feb 2011 02:31:00 -0000
Reply-To: [e-mail]
Subject: [radext] #74: Section 3.2
Message-ID: <[e-mail]>

#74: Section 3.2

 This attribute MAY be included multiple times
    in Access-Accept packets, when the intention is for a NAS to announce
    more than one recursive DNS address to an RG/host.

 Where multiple attributes are included is there something implied by the
 order?  For example, are the DNS server addresses supposed to be included
 in the same order to the RA or DHCPv6 packet?

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  wdec@…        
     Type:  defect                     |      Status:  new           
 Priority:  minor                      |   Milestone:  milestone1    
Component:  ipv6-access                |     Version:  1.0           
 Severity:  In WG Last Call            |    Keywords:                
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/74>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 28 Feb 2011 02:29:17 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail], [e-mail]
Date: Mon, 28 Feb 2011 02:28:40 -0000
Reply-To: [e-mail]
Subject: [radext] #73: Section 3.1
Message-ID: <[e-mail]>

#73: Section 3.1

 This Attribute can be used by a DHCPv6 process on the NAS to assign a
    unique IPv6 address to the RG/host, or it can be used for
    a-posteriori validation or announcement of an auto configured address
    to the AAA server.

 Since the Framed-IPv6-Prefix and Framed-Interface-Id attributes are used
 for SLAAC, allowing the Framed-IPv6-Address attribute for this purpose
 will create ambiguity.  My recommendation is to delete, the text after the
 comma.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  wdec@…        
     Type:  defect                     |      Status:  new           
 Priority:  blocker                    |   Milestone:  milestone1    
Component:  ipv6-access                |     Version:  1.0           
 Severity:  In WG Last Call            |    Keywords:                
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/73>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 28 Feb 2011 02:19:46 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail], [e-mail]
Date: Mon, 28 Feb 2011 02:19:24 -0000
Reply-To: [e-mail]
Subject: [radext] #72: Section 2.4
Message-ID: <[e-mail]>

#72: Section 2.4

 This section doesn't clarify the distinction between the Framed-IPv6-Pool
 and the Delegated-IPv6-Prefix-Pool attributes.  Recommendation is that it
 be rewritten as follows:

    DHCPv6 Prefix Delegation [RFC3633] involves a delegating router
    selecting a prefix and delegating it on a temporary basis to a
    requesting router.  The delegating router may implement a number of
    strategies as to how it chooses what prefix is to be delegated to a
    requesting router, one of them being the use of a local named prefix
    pool.  The Delegated-IPv6-Prefix-Pool Attribute allows the RADIUS
    server to convey a prefix pool name to a NAS hosting a DHCPv6-PD
    server and acting as a delegated router.

    Since DHCPv6 Prefix Delegation can conceivably be used on the
    same network as SLAAC, it is possible for the Delegated-IPv6-Prefix-
 Pool
    and Framed-IPv6-Pool attributes to be included within the same
    packet.  To avoid ambiguity in this scenario,
    use of the Delegated-IPv6-Prefix-Pool attribute should be restricted to
    authorization and accounting of prefix pools used in DHCPv6 Prefix
    Delegation and the Framed-IPv6-Pool attribute should be used for
    authorization and accounting of prefix pools used in SLAAC.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  wdec@…        
     Type:  defect                     |      Status:  new           
 Priority:  major                      |   Milestone:  milestone1    
Component:  ipv6-access                |     Version:  1.0           
 Severity:  In WG Last Call            |    Keywords:                
---------------------------------------+------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/radext/trac/ticket/72>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 28 Feb 2011 02:11:18 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail], [e-mail]
Date: Mon, 28 Feb 2011 02:10:52 -0000
Reply-To: [e-mail]
Subject: [radext] #71: Section 2.3 and 3.3
Message-ID: <[e-mail]>

#71: Section 2.3 and 3.3

 RFC 3162 Section 2.5 defines the Framed-IPv6-Route Attribute whose purpose
 is as follows:

       This Attribute provides routing information to be configured for
       the user on the NAS.  It is used in the Access-Accept packet and
       can appear multiple times.

 It would appear that this existing attribute has a similar purpose to the
 Route-IPv6-Information Attribute discussed in Section 2.3 and defined in
 Section 3.3, although the formats are different.

 Rather than explaining the difference between the Framed-IPv6-Prefix
 attribute and the Route-IPv6-Information Attribute in Section 2.3, my
 suggestion is to focus on the difference between the Framed-IPv6-Route
 attribute and the Route-IPv6-Information attribute, if there is in fact a
 difference.

 In general, the only reason to have two attributes with similar purposes
 would be if the attributes might not to be included simultaneously for
 different purposes.  In this particular case, it is not clear to me
 whether this could happen.  For example, would there be a situation where
 one set of routes might be announced via RIPng/OSPFv6 and another set
 would be announced via RA?

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  wdec@…        
     Type:  defect                     |      Status:  new           
 Priority:  major                      |   Milestone:  milestone1    
Component:  ipv6-access                |     Version:  1.0           
 Severity:  In WG Last Call            |    Keywords:                
---------------------------------------+------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/radext/trac/ticket/71>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 28 Feb 2011 01:57:42 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail], [e-mail]
Date: Mon, 28 Feb 2011 01:57:09 -0000
Reply-To: [e-mail]
Subject: [radext] #70: Section 2.1
Message-ID: <[e-mail]>

#70: Section 2.1

 This section leaves some ambiguity about the potential use of the Framed-
 IPv6-Address attribute in accounting related to SLAAC. To clarify the
 situation, my recommendation is to rewrite it as follows:

 2.1 DHCPv6 Address Assignment

    DHCPv6 [RFC3315] provides a mechanism to assign one or more or non-
    temporary IPv6 addresses to hosts.   To provide a DHCPv6 server
    residing on a NAS with one or more IPv6 addresses to be assigned,
    this document specifies the Framed-IPv6-Address Attribute.

    Since DHCPv6 can be deployed on the same network as ICMPv6 stateless
    (SLAAC) [RFC4862], it is possible that the NAS will require
    both stateful and stateless configuration information.  Therefore
    it is possible for the Framed-IPv6-Address, Framed-IPv6-Prefix
    and Framed-Interface-Id attributes [RFC3162] to be included
    within the same packet.  To avoid ambiguity, the Framed-IPv6-Address
 attribute is only used for
    authorization and accounting of DHCPv6-assigned addresses and the
    Framed-IPv6-Prefix and Framed-Interface-Id attributes are used
    for authorization and accounting of addresses assigned via SLAAC.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  wdec@…        
     Type:  defect                     |      Status:  new           
 Priority:  major                      |   Milestone:  milestone1    
Component:  ipv6-access                |     Version:  1.0           
 Severity:  In WG Last Call            |    Keywords:                
---------------------------------------+------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/radext/trac/ticket/70>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 28 Feb 2011 01:27:10 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail], [e-mail]
Date: Mon, 28 Feb 2011 01:25:56 -0000
Reply-To: [e-mail]
Subject: Re: [radext] #61: DNS attribute for IPv4?
Message-ID: <[e-mail]>

#61: DNS attribute for IPv4?


Comment(by bernard_aboba@…):

 There is no IETF defined RADIUS attribute to configure the IPv4 address of
 a DNS server.  However, Ascend did appropriate attributes 135 and 136 for
 the Primary and Secondary DNS server addresses.  See:
 http://www.juniper.net/techpubs/software/erx/junose81/swconfig-
 broadband/html/radius-attributes2.html

 My recommendation is that Section 2.2 be rewritten as follows:

    DHCPv6 provides an option for configuring a host with the IPv6 address
    of a DNS server.  The IPv6 address of a DNS server can also be
    conveyed to the host using ICMPv6 with Router Advertisements, via
    the experimental [RFC5006] option.  To provide the NAS with the
    IPv6 address of a DNS server, this document specifies the
    DNS-Server-IPv6-Address Attribute.

-- 
---------------------------------------+------------------------------------
 Reporter:  aland@…                    |       Owner:  wdec@…        
     Type:  defect                     |      Status:  new           
 Priority:  minor                      |   Milestone:  milestone1    
Component:  ipv6-access                |     Version:                
 Severity:  In WG Last Call            |    Keywords:                
---------------------------------------+------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/radext/trac/ticket/61#comment:2>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Sun, 27 Feb 2011 09:01:54 +0000
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-radext-radius-extensions-00.txt
Message-ID: <20110227090002.7026.40042.idtracker@localhost>
Date: Sun, 27 Feb 2011 01:00:02 -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           : Remote Authentication Dial In User Service (RADIUS) Protocol Extensions
	Author(s)       : A. DeKok, A. Lior
	Filename        : draft-ietf-radext-radius-extensions-00.txt
	Pages           : 56
	Date            : 2011-02-27

The Remote Authentication Dial In User Service (RADIUS) protocol is
nearing exhaustion of its current 8-bit attribute type space.  In
addition, experience shows a growing need for complex grouping, along
with attributes which can carry more than 253 octets of data.  This
document defines changes to RADIUS which address all of the above
problems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-radius-extensions-00.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-radius-extensions-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--

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


Envelope-to: [e-mail]
Delivery-date: Sat, 26 Feb 2011 21:56:53 +0000
Message-ID: <[e-mail]>
From: Bernard Aboba <[e-mail]>
To: "'radext mailing list'" <[e-mail]>
Subject: Summary of Call for Adoption as a RADEXT WG Work item: draft-dekok-radext-radius-extensions-01.txt
Date: Sat, 26 Feb 2011 13:56:47 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_03F9_01CBD5BD.02691F10"
Thread-Index: AcvWABBBOVZvujRLSVKaHeReNHWqLA==
Content-Language: en-us

------=_NextPart_000_03F9_01CBD5BD.02691F10
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

The Call for Adoption of draft-dekok-radext-radius-extensions-01 has now
concluded:

http://ops.ietf.org/lists/radiusext/2010/msg00692.html

 

Based on the WG response, this document is now adopted as a RADEXT WG work
item, replacing draft-ietf-radext-extended-attributes.

 

Authors:  please submit the document as
draft-ietf-radext-radius-extensions-00.txt ASAP. 


------=_NextPart_000_03F9_01CBD5BD.02691F10
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 12 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 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;}
@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>The Call =
for Adoption of draft-dekok-radext-radius-extensions-01 has now =
concluded:<o:p></o:p></p><p =
class=3DMsoNormal>http://ops.ietf.org/lists/radiusext/2010/msg00692.html<=
o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>Based on the WG response, this document is now adopted =
as a RADEXT WG work item, replacing =
draft-ietf-radext-extended-attributes.<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>Authors:&nbsp; please submit the document as =
draft-ietf-radext-radius-extensions-00.txt ASAP. =
<o:p></o:p></p></div></body></html>
------=_NextPart_000_03F9_01CBD5BD.02691F10--

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


Envelope-to: [e-mail]
Delivery-date: Thu, 24 Feb 2011 12:41:10 +0000
Message-ID: <[e-mail]>
Date: Thu, 24 Feb 2011 13:39:55 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Peter Deacon <[e-mail]>
CC: [e-mail]
Subject: Re: [radext] RDTLS #65 (new): Multiple dtls sessions in a tuple?
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Deacon wrote:
> This is not needed since source port is also replaced with
> RDTLS-Session-ID in the DTLS tracking table.

  Ah, OK.

> When source port is removed the effective ID space per DTLS session is
> the same as RADIUS... ~2^16 (source ports) * 2^8 (Ids)

  OK.

> To simplify somewhat the proposal is just stealing first 4 bytes for
> session selection and sending the rest to the DTLS stack.
> 
> I don't know how it would be classified politically.  In terms of
> Interop whether RADIUS sees DTLS or 4 bytes + DTLS the reaction from
> RADIUS implementations not supporting DTLS I would expect to materially
> be the same.

  Yes.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Wed, 23 Feb 2011 18:11:43 +0000
Date: Wed, 23 Feb 2011 10:10:45 -0800 (Pacific Standard Time)
From: Peter Deacon <[e-mail]>
To: Alan DeKok <[e-mail]>
cc: [e-mail]
Subject: Re: [radext] RDTLS #65 (new): Multiple dtls sessions in a tuple?
Message-ID: <alpine.WNT.2.00.1102230843140.2280@SMURF>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

On Wed, 23 Feb 2011, Alan DeKok wrote:

>> What I propose is allocating two type codes used for all RDTLS requests.

>> RDTLS-Request
>> RDTLS-Response

>> They will be used in a simple 4-byte prefix before the DTLS data by
>> RADIUS clients and servers.

>  If we're doing that, we might as well solve the ID limitation at the
> same time.  Add a 64-bit unique "packet identifier", so that one DTLS
> session can transport more than 256 RADIUS packets at the same time.

This is not needed since source port is also replaced with 
RDTLS-Session-ID in the DTLS tracking table.

When source port is removed the effective ID space per DTLS session is the 
same as RADIUS... ~2^16 (source ports) * 2^8 (Ids)

>  This worries me a little, though.  It involves the creation of a new
> protocol, which is neither RADIUS nor DTLS.  I'm not sure it solves
> enough problems to warrant the extra complexity.

To simplify somewhat the proposal is just stealing first 4 bytes for 
session selection and sending the rest to the DTLS stack.

I don't know how it would be classified politically.  In terms of Interop 
whether RADIUS sees DTLS or 4 bytes + DTLS the reaction from RADIUS 
implementations not supporting DTLS I would expect to materially be the 
same.

regards,
Peter

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


Envelope-to: [e-mail]
Delivery-date: Wed, 23 Feb 2011 14:24:23 +0000
Message-ID: <[e-mail]>
Date: Wed, 23 Feb 2011 15:23:15 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: [radext] RDTLS #67 (new): RADIUS vs RDTLS disambiguation (TLS Alert)
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

radext issue tracker wrote:
>  Until the TLS session is fully established you must be able to accept
>  normal RADIUS packets in the case where client_supports_rdtls is false or
>  someone can spoof a request with the intent to prematurely lock in the use
>  of DTLS.

  Hmm... that's true.

>  In terms of the text this draft should also burn the alert ctype (21) as
>  it may be sent by the client as part of its peer validation before the
>  session is established.

  I'll look into ways to avoid doing that.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Wed, 23 Feb 2011 09:03:33 +0000
Message-ID: <[e-mail]>
Date: Wed, 23 Feb 2011 10:02:32 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Peter Deacon <[e-mail]>
CC: [e-mail]
Subject: Re: [radext] RDTLS #65 (new): Multiple dtls sessions in a tuple?
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Deacon wrote:
> It seems possible one would have the freedom to implement a _server_
> with broadcasting to fill the potholes or even remove source port from
> the tuple while still maintaining 100% interoperability with clients and
> servers following this draft as currently written.  I agree it is not a
> particularly good idea but at least it is workable.

  Yes.

> 1. Stealing type codes is bad form even if we all think noone is using them

  Yes.  It's less bad because the type code being stolen is a *response*
code.  So it shouldn't be sent to servers.

> 2. Multiple DTLS sessions to the same server is an unnecessary waste of
> resources and may lead to unnecessary confusion regarding connection
> state should one but not all sessions under management be disconnected
> without the peers knowledge.

  Quite possibly, yes.  However, the limited ID space is an issue.

> 3. Client must implement strategies to maintain multiple connections if
> they need to effectively deal with the problem of insufficient ID space.

  Yes.  This is the same as today.

> 4. Expecting NATs to maintain long term stateful UDP mappings in sync
> with underlying DTLS session is not something I would want to bet on. 
> Mapping request and response is all RADIUS currently has to do.. It is
> much different than expecting the whole train of all subsequent requests
> to continue to use the same source port...

  If the client is continually sending traffic, it's OK.  The document
suggests a watchdog timer, which means at least one packet every few
tens of seconds.  That *may* be enough to keep the NAT state active.

> 5. Potholes.
> 
> 6. Depending on DTLS packet formatting and content type parameters to
> not change in the future for compatibility with the detection method is
> not ideal.

  Pretty much, yes.

> What I propose is allocating two type codes used for all RDTLS requests.
> 
> RDTLS-Request
> RDTLS-Response
>
> They will be used in a simple 4-byte prefix before the DTLS data by
> RADIUS clients and servers.

  If we're doing that, we might as well solve the ID limitation at the
same time.  Add a 64-bit unique "packet identifier", so that one DTLS
session can transport more than 256 RADIUS packets at the same time.

  This worries me a little, though.  It involves the creation of a new
protocol, which is neither RADIUS nor DTLS.  I'm not sure it solves
enough problems to warrant the extra complexity.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Tue, 22 Feb 2011 20:30:11 +0000
Date: Tue, 22 Feb 2011 12:29:05 -0800 (Pacific Standard Time)
From: Peter Deacon <[e-mail]>
To: Alan DeKok <[e-mail]>
cc: [e-mail]
Subject: Re: [radext] RDTLS #65 (new): Multiple dtls sessions in a tuple?
Message-ID: <alpine.WNT.2.00.1102221050040.2280@SMURF>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Tue, 22 Feb 2011, Alan DeKok wrote:

>> I agree with you it is better not to go there if not absolutely
>> necessary and in this case it may not be but old ports are now
>> potholes... and this scares me.

>> These things should be in the RDTLS draft. It would stink if someone
>> used a "connected" socket and (IMHO naturally) tried to reconnect the
>> TLS channel using the same socket(src port).. and when doing this some
>> servers sometimes did not accept the new connection for some period of
>> time because of this behavior.

>  That is an issue, unfortunately.  The solution is largely to have
> graceful shutdowns, and don't re-use ports.

Some thoughts:

It seems possible one would have the freedom to implement a _server_ with 
broadcasting to fill the potholes or even remove source port from the 
tuple while still maintaining 100% interoperability with clients and 
servers following this draft as currently written.  I agree it is not a 
particularly good idea but at least it is workable.

Here is an alternate proposal to resolve issues and make transport more 
reliable and easier for developers to implement client and server codes.

List of issues:

1. Stealing type codes is bad form even if we all think noone is using them

2. Multiple DTLS sessions to the same server is an unnecessary waste of 
resources and may lead to unnecessary confusion regarding connection state 
should one but not all sessions under management be disconnected without 
the peers knowledge.

3. Client must implement strategies to maintain multiple connections if 
they need to effectively deal with the problem of insufficient ID space.

4. Expecting NATs to maintain long term stateful UDP mappings in sync with 
underlying DTLS session is not something I would want to bet on.  Mapping 
request and response is all RADIUS currently has to do.. It is much 
different than expecting the whole train of all subsequent requests to 
continue to use the same source port...

5. Potholes.

6. Depending on DTLS packet formatting and content type parameters to not 
change in the future for compatibility with the detection method is not 
ideal.

What I propose is allocating two type codes used for all RDTLS requests.

RDTLS-Request
RDTLS-Response

They will be used in a simple 4-byte prefix before the DTLS data by RADIUS 
clients and servers.

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Code      |               RDTLS-Session-ID                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  DTLS ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-

Clients send code RDTLS-Request
Servers send code RDTLS-Response


Clients seeking new connections set RDTLS-Session-ID to 0.

Servers respond setting an internal value corresponding with the session 
table during the DTLS handshake.

Clients subsequently resend RDTLS-Session-ID for all future requests 
against the session.

Clients wishing new session send RDTLS-Session-ID = 0.

The tracking table in 4.1 is changed to replace source port with the 
RDTLS session id.

regards,
Peter

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


Envelope-to: [e-mail]
Delivery-date: Tue, 22 Feb 2011 13:59:45 +0000
Message-ID: <[e-mail]>
Date: Tue, 22 Feb 2011 14:58:36 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Peter Deacon <[e-mail]>
CC: [e-mail]
Subject: Re: [radext] RDTLS #65 (new): Multiple dtls sessions in a tuple?
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Deacon wrote:
> There are no implications.  DTLS does not know or care about the
> underlying transport.  It does not know what "UDP" is.  If the transport
> can't handle app data it does not know about then there are much bigger
> problems because its trivial for anyone to spoof such packets.

  That makes sense.

> I agree with you it is better not to go there if not absolutely
> necessary and in this case it may not be but old ports are now
> potholes... and this scares me.

  Yes.

> These things should be in the RDTLS draft. It would stink if someone
> used a "connected" socket and (IMHO naturally) tried to reconnect the
> TLS channel using the same socket(src port).. and when doing this some
> servers sometimes did not accept the new connection for some period of
> time because of this behavior.

  That is an issue, unfortunately.  The solution is largely to have
graceful shutdowns, and don't re-use ports.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 22:16:23 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail], [e-mail]
Date: Mon, 21 Feb 2011 22:16:11 -0000
Reply-To: [e-mail]
Subject: Re: [radext] ipv6-access #62 (new): Use of "Address"
Message-ID: <[e-mail]>

#62: Use of "Address"

Changes (by bernard_aboba@…):

  * owner:  => wdec@…


-- 
---------------------------------------+------------------------------------
 Reporter:  aland@…                    |       Owner:  wdec@…        
     Type:  defect                     |      Status:  new           
 Priority:  minor                      |   Milestone:  milestone1    
Component:  ipv6-access                |     Version:                
 Severity:  In WG Last Call            |    Keywords:                
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/62#comment:1>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 22:16:00 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail], [e-mail]
Date: Mon, 21 Feb 2011 22:15:47 -0000
Reply-To: [e-mail]
Subject: Re: [radext] ipv6-access #61 (new): DNS attribute for IPv4?
Message-ID: <[e-mail]>

#61: DNS attribute for IPv4?

Changes (by bernard_aboba@…):

  * owner:  => wdec@…


-- 
---------------------------------------+------------------------------------
 Reporter:  aland@…                    |       Owner:  wdec@…        
     Type:  defect                     |      Status:  new           
 Priority:  minor                      |   Milestone:  milestone1    
Component:  ipv6-access                |     Version:                
 Severity:  In WG Last Call            |    Keywords:                
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/61#comment:1>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 22:14:29 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail], [e-mail]
Date: Mon, 21 Feb 2011 22:14:18 -0000
Reply-To: [e-mail]
Subject: Re: [radext] radsec #60 (new): Behavior in response to CoA-Request
Message-ID: <[e-mail]>

#60: Behavior in response to CoA-Request

Changes (by bernard_aboba@…):

  * owner:  => stefan.winter@…


-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  stefan.winter@…         
     Type:  defect                     |      Status:  new                     
 Priority:  major                      |   Milestone:  milestone1              
Component:  radsec                     |     Version:  1.0                     
 Severity:  In WG Last Call            |    Keywords:                          
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/60#comment:1>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 22:13:56 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail], [e-mail]
Date: Mon, 21 Feb 2011 22:13:43 -0000
Reply-To: [e-mail]
Subject: Re: [radext] radsec #56 (new): Review
Message-ID: <[e-mail]>

#56: Review

Changes (by bernard_aboba@…):

  * owner:  => stefan.winter@…


-- 
---------------------------------------+------------------------------------
 Reporter:  aland@…                    |       Owner:  stefan.winter@…         
     Type:  defect                     |      Status:  new                     
 Priority:  major                      |   Milestone:  milestone1              
Component:  radsec                     |     Version:  1.0                     
 Severity:  Active WG Document         |    Keywords:                          
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/56#comment:1>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 22:12:33 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail], [e-mail]
Date: Mon, 21 Feb 2011 22:12:21 -0000
Reply-To: [e-mail]
Subject: Re: [radext] RDTLS #65 (new): Multiple dtls sessions in a tuple?
Message-ID: <[e-mail]>

#65: Multiple dtls sessions in a tuple?

Changes (by bernard_aboba@…):

  * owner:  => aland@…


-- 
-------------------------------------+--------------------------------------
 Reporter:  peterd@…                 |       Owner:  aland@…                  
     Type:  enhancement              |      Status:  new                      
 Priority:  trivial                  |   Milestone:  milestone1               
Component:  RDTLS                    |     Version:  1.0                      
 Severity:  Active WG Document       |    Keywords:                           
-------------------------------------+--------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/65#comment:1>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 22:12:08 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail], [e-mail]
Date: Mon, 21 Feb 2011 22:11:56 -0000
Reply-To: [e-mail]
Subject: Re: [radext] RDTLS #66 (new): NAT nits
Message-ID: <[e-mail]>

#66: NAT nits

Changes (by bernard_aboba@…):

  * owner:  => aland@…


-- 
-------------------------------------+--------------------------------------
 Reporter:  peterd@…                 |       Owner:  aland@…                  
     Type:  defect                   |      Status:  new                      
 Priority:  trivial                  |   Milestone:  milestone1               
Component:  RDTLS                    |     Version:  1.0                      
 Severity:  Active WG Document       |    Keywords:                           
-------------------------------------+--------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/66#comment:1>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 22:11:40 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail], [e-mail]
Date: Mon, 21 Feb 2011 22:11:28 -0000
Reply-To: [e-mail]
Subject: Re: [radext] RDTLS #67 (new): RADIUS vs RDTLS disambiguation (TLS Alert)
Message-ID: <[e-mail]>

#67: RADIUS vs RDTLS disambiguation (TLS Alert)

Changes (by bernard_aboba@…):

  * owner:  => aland@…


-- 
-------------------------------------+--------------------------------------
 Reporter:  peterd@…                 |       Owner:  aland@…                  
     Type:  defect                   |      Status:  new                      
 Priority:  minor                    |   Milestone:  milestone1               
Component:  RDTLS                    |     Version:  1.0                      
 Severity:  Active WG Document       |    Keywords:                           
-------------------------------------+--------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/67#comment:1>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 22:11:15 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail], [e-mail]
Date: Mon, 21 Feb 2011 22:10:08 -0000
Reply-To: [e-mail]
Subject: Re: [radext] RDTLS #63 (new): 4.1 session inactivity management
Message-ID: <[e-mail]>

#63: 4.1 session inactivity management

Changes (by bernard_aboba@…):

  * owner:  => aland@…


-- 
-------------------------------------+--------------------------------------
 Reporter:  peterd@…                 |       Owner:  aland@…                  
     Type:  defect                   |      Status:  new                      
 Priority:  major                    |   Milestone:  milestone1               
Component:  RDTLS                    |     Version:  1.0                      
 Severity:  Active WG Document       |    Keywords:                           
-------------------------------------+--------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/63#comment:1>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 22:11:08 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail], [e-mail]
Date: Mon, 21 Feb 2011 22:10:55 -0000
Reply-To: [e-mail]
Subject: Re: [radext] RDTLS #64 (new): 4.1 source port inclusion in the tracking table
Message-ID: <[e-mail]>

#64: 4.1 source port inclusion in the tracking table

Changes (by bernard_aboba@…):

  * owner:  => aland@…


-- 
-------------------------------------+--------------------------------------
 Reporter:  peterd@…                 |       Owner:  aland@…                  
     Type:  defect                   |      Status:  new                      
 Priority:  minor                    |   Milestone:  milestone1               
Component:  RDTLS                    |     Version:  1.0                      
 Severity:  Active WG Document       |    Keywords:                           
-------------------------------------+--------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/64#comment:1>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 11:01:02 +0000
Date: Mon, 21 Feb 2011 03:00:17 -0800 (Pacific Standard Time)
From: Peter Deacon <[e-mail]>
To: Alan DeKok <[e-mail]>
cc: [e-mail]
Subject: Re: [radext] RDTLS #65 (new): Multiple dtls sessions in a tuple?
Message-ID: <alpine.WNT.2.00.1102210233070.2280@SMURF>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Mon, 21 Feb 2011, Alan DeKok wrote:

> Peter Deacon wrote:
>> Isn't this what client hello /w cookies and the secure handshakes are
>> for? Surely these can't be spoofed so easily?!

>  This is assuming you get that far.  My assumption is that maintaining
> multiple DTLS sessions for the same {src ip/port dst ip/port}
> combination is a bad idea.  I do not know the security implications of
> doing it, and I don't think I'm enough of a TLS expert to say.

There are no implications.  DTLS does not know or care about the 
underlying transport.  It does not know what "UDP" is.  If the transport 
can't handle app data it does not know about then there are much bigger 
problems because its trivial for anyone to spoof such packets.

Given a choice I prefer whatever gets characterized as impractical, ugly, 
unacceptable hacks if they translate into operational reduction in 
unreliable behavior and happy customers.

I agree with you it is better not to go there if not absolutely necessary 
and in this case it may not be but old ports are now potholes... and this 
scares me.

These things should be in the RDTLS draft. It would stink if someone used 
a "connected" socket and (IMHO naturally) tried to reconnect the TLS 
channel using the same socket(src port).. and when doing this some servers 
sometimes did not accept the new connection for some period of time 
because of this behavior.

regards,
Peter

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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 10:32:24 +0000
Message-ID: <[e-mail]>
Date: Mon, 21 Feb 2011 11:32:00 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Peter Deacon <[e-mail]>
CC: [e-mail]
Subject: Re: [radext] RDTLS #65 (new): Multiple dtls sessions in a tuple?
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Deacon wrote:
> Isn't this what client hello /w cookies and the secure handshakes are
> for? Surely these can't be spoofed so easily?!

  This is assuming you get that far.  My assumption is that maintaining
multiple DTLS sessions for the same {src ip/port dst ip/port}
combination is a bad idea.  I do not know the security implications of
doing it, and I don't think I'm enough of a TLS expert to say.

> What if the session does not exist anymore and the client tries to
> reestablish or it is behind a NAT and there is unlucky synchronization
> of source ports?

  The client can retry.  The server can discard unused sessions.

  It's imperfect.

> You can have both by broadcasting the datagram to both sessions which is
> why I'm asking what the expected behavior in this instance should be.

  I am *very* wary of doing that.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 10:14:46 +0000
Date: Mon, 21 Feb 2011 02:14:28 -0800 (Pacific Standard Time)
From: Peter Deacon <[e-mail]>
To: Alan DeKok <[e-mail]>
cc: [e-mail]
Subject: Re: [radext] RDTLS #65 (new): Multiple dtls sessions in a tuple?
Message-ID: <alpine.WNT.2.00.1102210208590.2280@SMURF>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Mon, 21 Feb 2011, Alan DeKok wrote:

> Peter Deacon wrote:
>> Now from the same source port and address comes a brand new yet valid
>> request to start yet another session.

>  ... which can be trivially spoofed by anyone.

Isn't this what client hello /w cookies and the secure handshakes are for? 
Surely these can't be spoofed so easily?!

>> But there is already a valid session in the table...  Are you saying the
>> behavior should be to not accept the establishment of the new session?

>  I'm saying that it should prefer to keep an existing session, which
> has recently sent signed packets.

What if the session does not exist anymore and the client tries to 
reestablish or it is behind a NAT and there is unlucky synchronization of 
source ports?

>> I would think the new session would have the same security and spoof
>> protections as the initial (Old-Session-Lives-Here) session since it is
>> doing the same thing it did before?

>  Once the new session is established, yes.  Until it is established,
> no.  The first packet of a new DTLS session has *no* security.

To be clear... the new session would be established only after the full 
DTLS handshake.  Not just on first packet...

>  Allowing new session requests to destroy "live" sessions results in a
> trivial DoS attack.

You can have both by broadcasting the datagram to both sessions which is 
why I'm asking what the expected behavior in this instance should be.

regards,
Peter

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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 10:13:42 +0000
Message-ID: <[e-mail]>
Date: Mon, 21 Feb 2011 11:13:14 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Peter Deacon <[e-mail]>
CC: [e-mail]
Subject: Re: [radext] RDTLS #64 (new): 4.1 source port inclusion in the tracking table
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Deacon wrote:
> 1:100 NAT does not work in RADIUS nor does it work in DTLS so why should
> I care about this ridiculous example?

  I'm not sure what you mean by that.

  RADIUS works quite nicely through a NAT, so long as all of the clients
behind the NAT use the same shared secret.

  DTLS can work through a NAT, where each client has a unique
certificate.  The only requirement is that the mapping of client IP/port
to NAT source port doesn't change for the lifetime of the session.

  I believe that this is how NATs work today.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 10:07:58 +0000
Message-ID: <[e-mail]>
Date: Mon, 21 Feb 2011 11:07:38 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Peter Deacon <[e-mail]>
CC: [e-mail]
Subject: Re: [radext] RDTLS #65 (new): Multiple dtls sessions in a tuple?
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Deacon wrote:
> Now from the same source port and address comes a brand new yet valid
> request to start yet another session.

  ... which can be trivially spoofed by anyone.

> But there is already a valid session in the table...  Are you saying the
> behavior should be to not accept the establishment of the new session?

  I'm saying that it should prefer to keep an existing session, which
has recently sent signed packets.

> I would think the new session would have the same security and spoof
> protections as the initial (Old-Session-Lives-Here) session since it is
> doing the same thing it did before?

  Once the new session is established, yes.  Until it is established,
no.  The first packet of a new DTLS session has *no* security.

  Allowing new session requests to destroy "live" sessions results in a
trivial DoS attack.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 10:00:00 +0000
Date: Mon, 21 Feb 2011 01:59:32 -0800 (Pacific Standard Time)
From: Peter Deacon <[e-mail]>
To: Alan DeKok <[e-mail]>
cc: [e-mail]
Subject: Re: [radext] RDTLS #65 (new): Multiple dtls sessions in a tuple?
Message-ID: <alpine.WNT.2.00.1102210151240.2280@SMURF>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Mon, 21 Feb 2011, Alan DeKok wrote:

> radext issue tracker wrote:
>> #65: Multiple dtls sessions in a tuple?

>>  Section 4.1 does not provide guidance regarding what to do when there is a
>>  new session established against a tuple having an existing session.

>>  Can it maintain multiple sessions and broadcast any subsequent datagrams
>>  or does it automatically trigger discard of the previous session(s)?

>  Session initiation packets have no security or authentication, and can
> this be spoofed.  I think that the new packet should be discarded.

Imagine my table has an entry:

SP  SA          DP   DA          DTLS
333 10.20.30.40 1812 10.0.0.1    Old-Session-Lives-Here

Now from the same source port and address comes a brand new yet 
valid request to start yet another session.

But there is already a valid session in the table...  Are you saying the 
behavior should be to not accept the establishment of the new session?

I would think the new session would have the same security and spoof 
protections as the initial (Old-Session-Lives-Here) session since it is 
doing the same thing it did before?

regards,
Peter

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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 09:51:40 +0000
Date: Mon, 21 Feb 2011 01:51:14 -0800 (Pacific Standard Time)
From: Peter Deacon <[e-mail]>
To: Alan DeKok <[e-mail]>
cc: [e-mail]
Subject: Re: [radext] RDTLS #64 (new): 4.1 source port inclusion in the tracking   table
Message-ID: <alpine.WNT.2.00.1102210136330.2280@SMURF>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Mon, 21 Feb 2011, Alan DeKok wrote:

>  IMHO, that is a very bad idea, and quite likely impossible to
> implement in practice.  If you have two DTLS sessions from a client, and
> packets from more than two different source ports, you'll need to
> somehow inspect the traffic to determine which packet belongs to which
> session.

It is quite easy to implement but I agree with your sentiment.

>>  This approach will cut down on the number of DTLS sessions in a busy
>>  environment and simplify implementations. If you want to support NATs and
>>  the like you still can by broadcasting the packet to all matching DTLS
>>  sessions.

>  Ouch.  With 100 sessions, that means every packet results in 99 failures.
>  I don't think that's a good idea at all.

1:100 NAT does not work in RADIUS nor does it work in DTLS so why should I 
care about this ridiculous example?

If someone is gonzo enough to run a 100 sessions thru a 1:100 NAT then 
they deserve to waste each and every CPU cycle that entails.

Actually if you track the jitter window of the incoming datagram against 
the sequence number for each session you can substantially pair down the 
number of attempts.

regards,
Peter

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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 09:44:11 +0000
Message-ID: <[e-mail]>
Date: Mon, 21 Feb 2011 10:43:50 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: [radext] RDTLS #67 (new): RADIUS vs RDTLS disambiguation (TLS Alert)
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

radext issue tracker wrote:
>  Until the TLS session is fully established you must be able to accept
>  normal RADIUS packets in the case where client_supports_rdtls is false or
>  someone can spoof a request with the intent to prematurely lock in the use
>  of DTLS.

  Yes.  My thoughts are that RADIUS packets received *during* DTLS
session initiation should cause the DTLS session to be discarded, but
*only* when:

 - src/dst ip/port are all the same as the DTLS session
 - RADIUS packet is signed correctly

  The idea is that sane clients will not send DTLS + RADIUS from the
same source IP/port.

>  In terms of the text this draft should also burn the alert ctype (21) as
>  it may be sent by the client as part of its peer validation before the
>  session is established.

  Only if the client is sending RADIUS and DTLS from the same source
IP/port.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 09:33:59 +0000
Message-ID: <[e-mail]>
Date: Mon, 21 Feb 2011 10:33:49 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: [radext] RDTLS #65 (new): Multiple dtls sessions in a tuple?
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

radext issue tracker wrote:
> #65: Multiple dtls sessions in a tuple?
> 
>  Section 4.1 does not provide guidance regarding what to do when there is a
>  new session established against a tuple having an existing session.
> 
>  Can it maintain multiple sessions and broadcast any subsequent datagrams
>  or does it automatically trigger discard of the previous session(s)?

  Session initiation packets have no security or authentication, and can
this be spoofed.  I think that the new packet should be discarded.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 09:33:34 +0000
Message-ID: <[e-mail]>
Date: Mon, 21 Feb 2011 10:32:52 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: [radext] RDTLS #64 (new): 4.1 source port inclusion in the tracking table
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

radext issue tracker wrote:
>  Throughout the document it is recommended clients use connected socket
>  options... Now what happens when a client tries to send a new Access-
>  Request message using a different source port over a DTLS session that was
>  already established?

  Then the packet is discarded.  The DTLS sessions are keyed by (src
ip/port, dst ip/port).  It is by definition impossible to send packets
for one DTLS session from two different source ports.

>  If this is the intention it should be made clear clients can't switch
>  their source ports unless they also open a new DTLS session.  Client
>  implementors (most of us:) tend to gloss over server specific areas and
>  may not realize the implication.

  Hmm... OK.

>  If true and this is really the intention what stops clients from
>  originating packets from different processes per sec 3 above?

  Nothing.

>  My recommendation is to remove the source port from the tracking table key
>  and just allow DTLS session to be client specific so any source port can
>  be used as we do traditionally to get around the ID limit mess.

  IMHO, that is a very bad idea, and quite likely impossible to
implement in practice.  If you have two DTLS sessions from a client, and
packets from more than two different source ports, you'll need to
somehow inspect the traffic to determine which packet belongs to which
session.

>  This approach will cut down on the number of DTLS sessions in a busy
>  environment and simplify implementations. If you want to support NATs and
>  the like you still can by broadcasting the packet to all matching DTLS
>  sessions.

  Ouch.  With 100 sessions, that means every packet results in 99 failures.

  I don't think that's a good idea at all.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 08:39:20 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail]
Date: Mon, 21 Feb 2011 08:39:05 -0000
Reply-To: [e-mail]
Subject: [radext] RDTLS #67 (new): RADIUS vs RDTLS disambiguation (TLS Alert)
Message-ID: <[e-mail]>

#67: RADIUS vs RDTLS disambiguation (TLS Alert)

 ''3.1 "As a result, protocol disambiguation is straightforward.  If the
 first byte of the packet has value 22, it is a DTLS packet, and is a DTLS
 connection initiation request.  Otherwise, it is a RADIUS"''


 {{{
 5.
 "
          P = receive_packet_from_network()
          D = lookup_dtls_session(T, P)

          if (D || client_supports_rdtls(P)) {
             R = process_dtls_packet(D, P)
             if (R) {
                process_radius_packet(R)
             }

          } else if (first_octet_of_packet_is_22(P)) {
             process_dtls_clienthello(P)

          } else {
             process_radius_packet(P)
          }"
 }}}

 Until the TLS session is fully established you must be able to accept
 normal RADIUS packets in the case where client_supports_rdtls is false or
 someone can spoof a request with the intent to prematurely lock in the use
 of DTLS.

 In terms of the text this draft should also burn the alert ctype (21) as
 it may be sent by the client as part of its peer validation before the
 session is established.

-- 
-------------------------------------+--------------------------------------
 Reporter:  peterd@…                 |       Owner:            
     Type:  defect                   |      Status:  new       
 Priority:  minor                    |   Milestone:  milestone1
Component:  RDTLS                    |     Version:  1.0       
 Severity:  Active WG Document       |    Keywords:            
-------------------------------------+--------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/67>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 08:37:25 +0000
Message-ID: <[e-mail]>
Date: Mon, 21 Feb 2011 09:37:05 +0100
From: Stefan Winter <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: [e-mail]
CC: radext issue tracker <[e-mail]>, [e-mail]
Subject: Re: [radext] RDTLS #66 (new): NAT nits
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3C94E8709E1A7593503AA54A"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3C94E8709E1A7593503AA54A
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

> #66: NAT nits
>
>  ''8.2. "Network Address Translation (NAT) is fundamentally incompatibl=
e
>  with RADIUS.  RADIUS uses the source IP address to determine the share=
d
>  secret for the client, and NAT hides many clients behind one source IP=

>  address."''
>
>  There are no problems with full cone or ALGs acting as proxies.

Is that really true if DynAuth is concerned? A DynAuth packet needs to
reach the actual NAS. If there is >1 NAS behind any form of NAT, how
would the NAT ALG proxy figure out how to forward to which NAS?

Greetings,

Stefan Winter

>  Recommend:
>
>  Some forms of Network Address Translation (NAT) are incompatible with
>  RADIUS....
>


--=20
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education=
 Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]



--------------enig3C94E8709E1A7593503AA54A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1iJDEACgkQ+jm90f8eFWZOjwCcD9PxwgzUihw9Ed1buvJWmf/+
tgYAnjnn3TFzuEe6+k/rN6XtuTKab0dp
=wxl+
-----END PGP SIGNATURE-----

--------------enig3C94E8709E1A7593503AA54A--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 08:27:19 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail]
Date: Mon, 21 Feb 2011 08:27:06 -0000
Reply-To: [e-mail]
Subject: [radext] RDTLS #66 (new): NAT nits
Message-ID: <[e-mail]>

#66: NAT nits

 ''8.2. "Network Address Translation (NAT) is fundamentally incompatible
 with RADIUS.  RADIUS uses the source IP address to determine the shared
 secret for the client, and NAT hides many clients behind one source IP
 address."''

 There are no problems with full cone or ALGs acting as proxies.

 Recommend:

 Some forms of Network Address Translation (NAT) are incompatible with
 RADIUS....

-- 
-------------------------------------+--------------------------------------
 Reporter:  peterd@…                 |       Owner:            
     Type:  defect                   |      Status:  new       
 Priority:  trivial                  |   Milestone:  milestone1
Component:  RDTLS                    |     Version:  1.0       
 Severity:  Active WG Document       |    Keywords:            
-------------------------------------+--------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/66>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 08:24:33 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail]
Date: Mon, 21 Feb 2011 08:24:16 -0000
Reply-To: [e-mail]
Subject: [radext] RDTLS #65 (new): Multiple dtls sessions in a tuple?
Message-ID: <[e-mail]>

#65: Multiple dtls sessions in a tuple?

 Section 4.1 does not provide guidance regarding what to do when there is a
 new session established against a tuple having an existing session.

 Can it maintain multiple sessions and broadcast any subsequent datagrams
 or does it automatically trigger discard of the previous session(s)?

-- 
-------------------------------------+--------------------------------------
 Reporter:  peterd@…                 |       Owner:            
     Type:  enhancement              |      Status:  new       
 Priority:  trivial                  |   Milestone:  milestone1
Component:  RDTLS                    |     Version:  1.0       
 Severity:  Active WG Document       |    Keywords:            
-------------------------------------+--------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/65>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 08:22:42 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail]
Date: Mon, 21 Feb 2011 08:22:21 -0000
Reply-To: [e-mail]
Subject: [radext] RDTLS #64 (new): 4.1 source port inclusion in the tracking table
Message-ID: <[e-mail]>

#64: 4.1 source port inclusion in the tracking table

 ''4.1. "An RADIUS/DTLS server MUST maintain a table that tracks ongoing
 DTLS sessions based on a key composed of the following 4-tuple:''

       * source IP address
       * source port
       * destination IP address
       * destination port"

 ''3.
 "Clients can no longer have multiple independent RADIUS implementations or
 processes that originate packets.  We RECOMMEND that RADIUS/DTLS clients
 implement a local RADIUS proxy that arbitrates all RADIUS traffic."''

 I am confused with how this tracking is supposed to work.

 Throughout the document it is recommended clients use connected socket
 options... Now what happens when a client tries to send a new Access-
 Request message using a different source port over a DTLS session that was
 already established?

 Judging by keys of the table such a request would be discarded since there
 is no known session in the table matching key.

 If this is the intention it should be made clear clients can't switch
 their source ports unless they also open a new DTLS session.  Client
 implementors (most of us:) tend to gloss over server specific areas and
 may not realize the implication.

 If true and this is really the intention what stops clients from
 originating packets from different processes per sec 3 above?

 My recommendation is to remove the source port from the tracking table key
 and just allow DTLS session to be client specific so any source port can
 be used as we do traditionally to get around the ID limit mess.

 This approach will cut down on the number of DTLS sessions in a busy
 environment and simplify implementations. If you want to support NATs and
 the like you still can by broadcasting the packet to all matching DTLS
 sessions.

-- 
-------------------------------------+--------------------------------------
 Reporter:  peterd@…                 |       Owner:            
     Type:  defect                   |      Status:  new       
 Priority:  minor                    |   Milestone:  milestone1
Component:  RDTLS                    |     Version:  1.0       
 Severity:  Active WG Document       |    Keywords:            
-------------------------------------+--------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/64>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Mon, 21 Feb 2011 08:09:50 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "radext issue tracker" <[e-mail]>
Cc: [e-mail]
Auto-Submitted: auto-generated
To: [e-mail]
Date: Mon, 21 Feb 2011 08:08:37 -0000
Reply-To: [e-mail]
Subject: [radext] RDTLS #63 (new): 4.1 session inactivity management
Message-ID: <[e-mail]>

#63: 4.1 session inactivity management

 ''"4.1 ... When a session
 has not been used for a period of time, the server SHOULD pro-
 actively close it, and delete the DTLS session from the tracking
 table. The server MAY cache the TLS session parameters, in
 order to provide for fast session resumption.

 This session lifetime SHOULD be exposed as configurable setting.  It
 SHOULD NOT be set to less than 60 seconds, and SHOULD NOT be set to
 more than 600 seconds (10 minutes).  The minimum value useful value
 for this timer is determined by the application-layer watchdog
 mechanism defined in the following section."''

 s/lifetime/inactivity timeout/
 Lifetime implies static start point.

 Connections on server should be reasonably maintained for long haul (days)
 as there is no rapid method for clients to detect a session closed by the
 server.

 Closure alerts are unreliable and status beats are optional.  Every effort
 should be made to reduce the possibility of datagrams sent by a client
 being silently discarded on the servers DTLS stack.

 I prefer an algorithm where Established connections are maintained as long
 as possible.  Rather than refusing to create new records recommend oldest
 unused subject to a minimum threshold applicable only while there is
 pressure on the state table with between 60 and 600 seconds minimum before
 refusing new connections.

 ''"RADIUS/DTLS servers SHOULD also keep track of the total number of
 sessions in the tracking table, and refuse to create new sessions
 when a large number are already being tracked.  As system
 capabilities vary widely, we can only recommend that this number
 SHOULD be exposed as a configurable setting."''

 Possible replacement text:

 This session inactivity timeout SHOULD be exposed as a configurable
 setting.  Under normal conditions sessions inactive for a duration of
 several hours to days should be disconnected.

 Should the total number of sessions in the tracking table exceed an
 administrative threshold the session inactive for the longest period of
 time should be closed to make room for new sessions.  The server should
 enforce a minimum threshold of between 60 to 600 seconds of inactivity
 below which old sessions are no longer
 disconnected to make room for new sessions on a resource constrained
 server.  In this event new sessions are refused.

-- 
-------------------------------------+--------------------------------------
 Reporter:  peterd@…                 |       Owner:            
     Type:  defect                   |      Status:  new       
 Priority:  major                    |   Milestone:  milestone1
Component:  RDTLS                    |     Version:  1.0       
 Severity:  Active WG Document       |    Keywords:            
-------------------------------------+--------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/63>
radext <http://tools.ietf.org/radext/>


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


Envelope-to: [e-mail]
Delivery-date: Wed, 16 Feb 2011 13:15:11 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=8j9Mp8qSgGFEK27WOWM7DeHpSkPxIZFUrYBku9kUUyI=; b=cx4zlVMggZoX4g2OD4euFI2tWGUvEXOvBpOZQ/yWZBtlFeYBLSvaVhktNl+pz8V2j5 WWMryW94H4yUeK1nJS+3EC0WJf8qU5Q/NhlDgLQubT6CIkNFKZyJABCHicTtBAAE5hFc JfGBTraNmzfpkccIhlKBjM+nnjyS1G/0YjxKs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=H7U5G/pwpprz0CMFWHbHwqoPwlLVFvQ0cz1Sn5PvM7nYiEIefUhsDDCQKuboTvNuhY k2ZROPT6J+h6WXIBZ9uRRX7/HRlhtcRabQrVEZSBXQUQ9gOViOrK4cYPGcgSCCUQea6I BwRbhq1oz77bUp0TkHChfQrT8UW1NkwijHEuo=
Subject: Re: Call for Adoption as a RADEXT WG Work item: draft-dekok-radext-radius-extensions-01.txt
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen <[e-mail]>
Date: Wed, 16 Feb 2011 15:14:15 +0200
Cc: "[e-mail]" <[e-mail]>
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
To: Bernard Aboba <[e-mail]>

I support the adoption.

- Jouni


On Feb 8, 2011, at 7:24 PM, Bernard Aboba wrote:

> As was discussed at the last RADEXT Interim meeting and at IETF 79, =
the document "Extended RADIUS Attributes"  =
(http://tools.ietf.org/html/draft-ietf-radext-extended-attributes) =
expired in November 2010, and interest among RADIUS client and server =
implementers appears to be lagging.=20
>=20
> An alternate approach has therefore been proposed by Alan DeKok and =
Avi Lior.=20
>=20
> To determine whether to adopt this alternative approach, we are now =
doing a Call for Adoption of the document "RADIUS Extensions" as a =
RADEXT WG work item.  The document is available for inspection here:
> http://www.ietf.org/id/draft-dekok-radext-radius-extensions-01.txt
>=20
> Please read the document, and respond to this Call for Adoption by =
February 23, 2011, indicating whether you favor adoption of the "RADIUS =
Extensions" document (implying deprecation of the 'Extended RADIUS =
Attributes" document), or not. =20
>=20
>=20


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


Envelope-to: [e-mail]
Delivery-date: Wed, 16 Feb 2011 11:01:22 +0000
Message-ID: <[e-mail]>
Date: Wed, 16 Feb 2011 12:00:37 +0100
From: Klaas Wierenga <[e-mail]>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Call for Adoption as a RADEXT WG Work item:  draft-dekok-radext-radius-extensions-01.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 2/8/11 6:24 PM, Bernard Aboba wrote:

I support adoption.

Klaas

> As was discussed at the last RADEXT Interim meeting and at IETF 79, the
> document "Extended RADIUS Attributes"
> (http://tools.ietf.org/html/draft-ietf-radext-extended-attributes)
> expired in November 2010, and interest among RADIUS client and server
> implementers appears to be lagging.
>
> An alternate approach has therefore been proposed by Alan DeKok and Avi
> Lior.
>
> To determine whether to adopt this alternative approach, we are now
> doing a Call for Adoption of the document "RADIUS Extensions" as a
> RADEXT WG work item. The document is available for inspection here:
> http://www.ietf.org/id/draft-dekok-radext-radius-extensions-01.txt
>
> Please read the document, and respond to this Call for Adoption by
> February 23, 2011, indicating whether you favor adoption of the "RADIUS
> Extensions" document (implying deprecation of the 'Extended RADIUS
> Attributes" document), or not.
>
>


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


Envelope-to: [e-mail]
Delivery-date: Wed, 16 Feb 2011 10:29:09 +0000
Message-ID: <[e-mail]>
Date: Wed, 16 Feb 2011 11:28:03 +0100
From: [e-mail]
To: Bernard Aboba <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: Call for Adoption as a RADEXT WG Work item: draft-dekok-radext-radius-extensions-01.txt
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4)

Hi,

I support adoption of the document as a WG item.

Greetings,

Stefan Winter

----- Nachricht von [e-mail] ---------
      Datum: Tue, 8 Feb 2011 09:24:42 -0800
        Von: Bernard Aboba <[e-mail]>
    Betreff: Call for Adoption as a RADEXT WG Work item:  
draft-dekok-radext-radius-extensions-01.txt
         An: "[e-mail]" <[e-mail]>


>
> As was discussed at the last RADEXT Interim meeting and at IETF 79,  
> the document "Extended RADIUS Attributes"   
> (http://tools.ietf.org/html/draft-ietf-radext-extended-attributes)  
> expired in November 2010, and interest among RADIUS client and  
> server implementers appears to be lagging.
>
> An alternate approach has therefore been proposed by Alan DeKok and Avi Lior.
>
> To determine whether to adopt this alternative approach, we are now  
> doing a Call for Adoption of the document "RADIUS Extensions" as a  
> RADEXT WG work item.  The document is available for inspection here:
> http://www.ietf.org/id/draft-dekok-radext-radius-extensions-01.txt
>
> Please read the document, and respond to this Call for Adoption by  
> February 23, 2011, indicating whether you favor adoption of the  
> "RADIUS Extensions" document (implying deprecation of the 'Extended  
> RADIUS Attributes" document), or not.
>
>
>


----- Ende der Nachricht von [e-mail] -----




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


Envelope-to: [e-mail]
Delivery-date: Sun, 13 Feb 2011 16:15:30 +0000
Message-ID: <[e-mail]>
From: Bernard Aboba <[e-mail]>
To: "'Romascanu, Dan \(Dan\)'" <[e-mail]>, "'radext mailing list'" <[e-mail]>
Subject: RE: [Technical Errata Reported] RFC2868 (2714)
Date: Sun, 13 Feb 2011 08:14:35 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcvLRaqfSjVV4EMoTail60RhnrPvFQAINengAAyhkcA=
Content-Language: en-us

IMHO, this should be "verified". 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Romascanu, Dan (Dan)
Sent: Sunday, February 13, 2011 2:13 AM
To: radext mailing list
Subject: FW: [Technical Errata Reported] RFC2868 (2714)

 Hi,

Please address the issue raised in this errata. 

Thanks and Regards,

Dan


-----Original Message-----
From: RFC Errata System [mailto:[e-mail]] 
Sent: Sunday, February 13, 2011 8:17 AM
To: [e-mail]; [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; Romascanu, Dan (Dan);
[e-mail]
Cc: [e-mail]; [e-mail]
Subject: [Technical Errata Reported] RFC2868 (2714)


The following errata report has been submitted for RFC2868, "RADIUS
Attributes for Tunnel Protocol Support".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=2868&eid=2714

--------------------------------------
Type: Technical
Reported by: Wang Haojian <[e-mail]>

Section: 3.10

Original Text
-------------
3.10.  Tunnel-Server-Auth-ID



   Description



      This Attribute specifies the name used by the tunnel terminator

      during the authentication phase of tunnel establishment.  The

      Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the

      ^^^^^^^^^^^^^^^^^^^^^

Corrected Text
--------------
3.10.  Tunnel-Server-Auth-ID



   Description



      This Attribute specifies the name used by the tunnel terminator

      during the authentication phase of tunnel establishment.  The

      Tunnel-Server-Auth-ID Attribute MAY be included (as a hint to the

Notes
-----
Maybe here should be the "Tunnel-Server-Auth-ID"

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please use
"Reply All" to discuss whether it should be verified or rejected. When a
decision is reached, the verifying party (IESG) can log in to change the
status and edit the report, if necessary. 

--------------------------------------
RFC2868 (draft-ietf-radius-tunnel-auth-09)
--------------------------------------
Title               : RADIUS Attributes for Tunnel Protocol Support
Publication Date    : June 2000
Author(s)           : G. Zorn, D. Leifer, A. Rubens, J. Shriver, M.
Holdrege, I. Goyret
Category            : INFORMATIONAL
Source              : Remote Authentication Dial-In User Service
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

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


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


Envelope-to: [e-mail]
Delivery-date: Sun, 13 Feb 2011 10:14:46 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: FW: [Technical Errata Reported] RFC2868 (2714)
Date: Sun, 13 Feb 2011 11:12:57 +0100
Message-ID: <[e-mail]>
Thread-Topic: [Technical Errata Reported] RFC2868 (2714)
Thread-Index: AcvLRaqfSjVV4EMoTail60RhnrPvFQAINeng
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "radext mailing list" <[e-mail]>

 Hi,

Please address the issue raised in this errata.=20

Thanks and Regards,

Dan


-----Original Message-----
From: RFC Errata System [mailto:[e-mail]]=20
Sent: Sunday, February 13, 2011 8:17 AM
To: [e-mail]; [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; Romascanu, Dan (Dan);
[e-mail]
Cc: [e-mail]; [e-mail]
Subject: [Technical Errata Reported] RFC2868 (2714)


The following errata report has been submitted for RFC2868, "RADIUS
Attributes for Tunnel Protocol Support".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D2868&eid=3D2714

--------------------------------------
Type: Technical
Reported by: Wang Haojian <[e-mail]>

Section: 3.10

Original Text
-------------
3.10.  Tunnel-Server-Auth-ID



   Description



      This Attribute specifies the name used by the tunnel terminator

      during the authentication phase of tunnel establishment.  The

      Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the

      ^^^^^^^^^^^^^^^^^^^^^

Corrected Text
--------------
3.10.  Tunnel-Server-Auth-ID



   Description



      This Attribute specifies the name used by the tunnel terminator

      during the authentication phase of tunnel establishment.  The

      Tunnel-Server-Auth-ID Attribute MAY be included (as a hint to the

Notes
-----
Maybe here should be the "Tunnel-Server-Auth-ID"

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please use
"Reply All" to discuss whether it should be verified or rejected. When a
decision is reached, the verifying party (IESG) can log in to change the
status and edit the report, if necessary.=20

--------------------------------------
RFC2868 (draft-ietf-radius-tunnel-auth-09)
--------------------------------------
Title               : RADIUS Attributes for Tunnel Protocol Support
Publication Date    : June 2000
Author(s)           : G. Zorn, D. Leifer, A. Rubens, J. Shriver, M.
Holdrege, I. Goyret
Category            : INFORMATIONAL
Source              : Remote Authentication Dial-In User Service
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

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


Envelope-to: [e-mail]
Delivery-date: Sat, 12 Feb 2011 19:24:50 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_73bac9af-fdaf-4a3e-af4e-34a32d196294_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Minutes of RADEXT meeting at IETF 79
Date: Sat, 12 Feb 2011 11:23:28 -0800
MIME-Version: 1.0

--_73bac9af-fdaf-4a3e-af4e-34a32d196294_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable





RADEXT WG Minutes
IETF 79
Beijing=2C China=20
Friday=2C November 12=2C 2010
Meeting start 9:00AM CST

Chairs:  Bernard Aboba <[e-mail]>
Mauricio Sanchez <[e-mail]>

Agenda
0900 - 0920:  Preliminaries
*Blue Sheets=2C Note takers=2C Jabber Scribe
*Agenda bash=2C Document Status

1.    Mauricio reviewed the agenda. No suggested changes.
-    Jabber scribe: Dan Romascanu
-    Note taker: Nancy Cam-Winget

2.    Mauricio reviewed the document status=2C see https://datatracker.ietf=
.org/wg/radext/ .

0920 - 0930  Hot Errata=2C WG Chairs (10 minutes)
- Discussion of issue 1469 (RFC 2865) and issue 753 (RFC 4282)=20
o Dan Romanascu asks whether status should really be changed?  Per guidelin=
e review rules=2C this is what seems to be an appropriate resolution. Dan b=
elieves that it may be misleading.
o Dan states=94verified means that it has been verified=2C accepted and enf=
orced=94 which is typically for errata that need small fixes with technical=
 meaning. =93held for doc=94 means that the errata is not enforced but disc=
ussion is deferred until the document is updated=3B is this what we really =
want?  Chair says =93no=94=2C but want to acknowledge that the issue does e=
xist.=20
o Dan asks if intent is to =93enforce=94 vs. =93hidden until doc is revised=
=94? Chair believes the latter=2C so from procedural view=2C take lodge rec=
ommendation with AD (Dan). =20
o Bernard comments why =93held for verify=94=2C the error was intentional. =
we do not want it enforced.  Dan clarifies that 1469 should be =93held=94 v=
s =93verify=94=2C 753 should be changed from verify to =93rejected=94 asks =
Bernard to confirm.  Bernard confirms on 753 and 1469 should stay =93verify=
=94.  Dan takes note to update status of these docs.=20

-Discussion of issues 2507 and 2508 of RFC 5597
o More editorial comments came in around =93access-accept=94 misleading not=
e (2507) and typo in mention of =93server=94 should be =93client=94 (2508).=
  Status is to keep them as =93held for document update=94.=20
o Alan comments that someone should be reading this well before final publi=
cation.


0930 - 0940 RADIUS over TCP=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-tcp
- One change (issue 59) to fix issue=2C believes there=92s nothing left to =
resolve in the document.  Removes reference to CoA.
- Should be ready to go and get it reviewed again.  Bernard asks if it shou=
ld go to IESG discussion? Mauricio believes group signed off on document. D=
an suggests can go to the next step. Bernard believes Ralph may not believe=
 issue is addressed.  Alan mentions that Ralph had reviewed and had not add=
ed any other comment.  If more comments come=2C Alan can respond to them.  =
Dan suggests to make sure loop with Ralph is closed as Bernard believes iss=
ue is not closed (according to Ralph).

0940 - 0950 Design Guidelines=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-design/
-Cleared open issues=2C review from Lionel Morand=2C clarifications and gra=
mmar fixes reports=3B new version -19 released on Mon.
-Current timeframe for reviews (theoretically it=92s a bit late but will tr=
y to put it on next week=92s agenda with good chance of it being deferred t=
ill the 1st week of Dec).


0950 - 1010 RADIUS over TLS=2C Stefan Winter (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec
- No new rev as issues 59 (CoA) and 60 need discussion.
- Should all traffic run on a port or should 3 diff ports be used (session =
acct=2C CoA=2C etc).  Q1: 1812=2C 1813=2C 3799 or 2083 for all though all e=
xisting implementations do 2083.  Suggests that there are merits to using 3=
 diff ports=2C but would like to solicit feedback of 1 vs 3 ports.
- If there are 3 diff ports=2C which should they be: new or resued 1812=2C =
1813 and 3799? Cleaner to take separate ports but usurps IANA real estate=
=2C reuse of ports puts us at whim of TLS (1st byte will need to be differe=
nt).
- Next steps: poll and consensus of 1 vs. 3 ports=2C new ports vs. multiple=
x.
- Comment from Alan: for existing radius (radsec admins should talk to each=
 other so can work today but) should not rely on this in the future.  Not s=
ure if it should be part of Radius over TLS doc. There may need to be other=
 interdependent docs that show how to use radius packets with tls.  Difficu=
lt to say what=92s better.
- Stefan comments that then 3 ports may be better.
- Bernard comments that radius/dtls discovers the use of udp=2C so if its t=
cp should this be an issue?
- Alan if radius over tcp over ipsec=2C that should be valid. Question is i=
t is an admin config issue or have the protocol figure it out?
- Stefan comments that tcp should be considered so demultiplexing may be ap=
propriate.
- Bernard asks what is in the first byte of tls?
- Alan says it=92s a tls handshake byte and believes it would not change as=
 things like https may break.  Can ask the tls folks=2C but doubts that pac=
kets like start tls would change too much.
- Mauricio agrees that we could potentially make it a constant.
- Suggestion is to ask Eric Rescorla/Joe Salowey and TLS experts to confirm=
 this.
- Bernard states that feedback from implementers will also be key.
- Stefan suggests reuse of existing.
- Bernard agrees that yes=2C with multiplexing. If vendors are willing to d=
o this then we can go this route=2C otherwise we=92ll have to take a differ=
ent approach.

1010 - 1030 Dynamic Peer Discovery=2C Stefan Winter (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery
- No new rev as discussion on port/packet type needs discussion. Dependency=
 on the ports used (1 vs 3)
- Would need 3 labels: auth=2C acct=2C dynauth if 3 ports chosen.
- Could look like S-naptrs (radius.tls=2C radacct.tls=2C raddynauth.tls).
- Mauricio says as there=92s dependency on previous draft=2C we should hold=
 off until decisions on prev draft are made.  This will be in holding patte=
rn until confirmation on prev draft decisions are made

1030 - 1040 RADIUS over DTLS=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dtls
- No major changes done. Issues of doc is that it is really a diff of the  =
RADIUS over TLS document. So rather than rewrite=2C it docs what applies or=
 how it is different.
- Open issues: need to re-sync with RTLS draft.  Make sense to reuse same p=
ort but would like review from Stig Venaas (radsecproxy).
- Bernard asks Alan whether implementers are in agreement on port implement=
ation?
- Alan says no=85in looking at RADIUS over TLS source code=2C they are trea=
ted separately.  The goal for freeradius is that it should accept radius an=
d tls on the same port.

1040 - 1110 Extended Attributes=2C Alan DeKok (30 minutes)
http://tools.ietf.org/html/draft-ietf-radext-extended-attributes
History: Need more attributes as 256 is too limited=2C the grouping is not =
adequate (RFC 2868 not sufficient).
- Previous WG discussion was that diameter attrs were too complex.  The exi=
sting draft for  extended attrs had some traction but realization was that =
they didn=92t actually work so prev authors dropped it as they don=92t beli=
eve its relevant.  At last IETF=2C Stefan and Alan whiteboarded (and then A=
vi joined) to put this doc together.
- New TLV: adds one byte to call it the =93extended type=94: 4 attrs from t=
he reserved space . Need to name new attributes and grouping defining a TLV=
 data type already in WiMax=2C 3Gpp2 and other sdo=92s/vendors=3B while not=
 as powerful in diameter=2C it is leveraging existing code (e.g. proven use=
fulness in radius).
- TLV data type reuses radius format (e.g. TLV).imposes a nest in TLV withi=
n TLV=2C can be nested to arbitrary depth and limited by the length field (=
sum of TLV lengths must add up to the encapsulated length)=3B though anythi=
ng beyond depth 5 can become confusing.
- TLV naming: IANA to track=2C leverage same dotted notation (e.g. 241.1.2 =
=3D Radius attr 241 of type =93ext-attr=94=2C extend attr 1=2C data type =
=93tlv=94=2C tlv 2=2C data type =93integer=94).
- Use of long attributes definitions includes a new flag (1 octet).
- Suggestion is to make =91flag=92 be compatible with wimax. More details t=
o be sorted with by Alan and Avi=85.not sure that extra 7 bits would be use=
d for anything.
- Extending vsa space 24{1-6}.26 are VSAs and allows for more to be support=
ed.
- Motivation: believes that a solution is needed w/in 2-3 yrs.
- Stefan asks why not have flag in these attributes? Alan responds that hal=
f of the defined attrs are <20 bytes=2C so having a flag for them=2C best g=
uess is that they would be < 20bytes and having a flag for each of them wou=
ld not be efficient.
- Stefan asks how may deployments have gone the =93simple=94 string  mechan=
ism as they were no longer =93attributes=94.  Alan mentions audit was not p=
erfect=2C but its easy to strip out something =93small=94 and looking at th=
e rest=3B though indiv class attributes only about 20 require 253 octects=
=2C including wimax that defines attrs that carry tlv=92s. the tlv=92s tend=
 to be generic filter rules that can be nested and carry a substantial amou=
nt of data within one attribute.  So believes there=92s not great demand th=
at require more than 253 bytes of data and most are defined by rfc 5907 (no=
t sure of #?) and those tend to include certs. The rest seem to be small. A=
nd even those are allocated rarely (e.g. once every 2-3yrs)=85giving us abi=
lity to have a simpler format.
- 2 interop implementations for this already: basic support in freeradius (=
no long attrs yet)=2C client support in IEA software.=20
- Todo: define VSA data type (easier than repeating attr definition)=2C mor=
e guideline recommendations=2C more examples and clarifications.
- Bernard asks if guidelines need to be covered in this draft or if a diffe=
rent doc may be needed?  Alan says its a good question=2C some guidelines w=
ould be good to show applicability on some of this=2C but it may be OK to k=
eep them high level in this doc.
- Bernard asks if Alan envisions carrying over some of the guidelines from =
the guidelines doc to this one.  Alan: yes.
- Bernard asks if vendors are ok with new VSA type?  Alan says no=2C though=
 idea is to use something similar to RFC 2865 (4byte vendor ID).so most peo=
ple have followed TLV fmt per rfc=2C some have not.given some attr have len=
gth attached=2C for compatibility rfc 2865 are typically encapsulated in a =
vendor specific attr though its not been done by all vendors.
- Stefan asks if proposed attrs been hijacked yet? Alan mentions as the new=
 vsa=92s are in context of extended attrs=2C believes that those attrs have=
 been hijacked by vendors and doc discusses this and how proxies can help d=
etect these. Eduroam did an audit to show that most proxies were ok=2C but =
a few were not=3B so doc makes suggestions on what to do (.e.g take existin=
g hijacked defns and discard them. Take old equipment and deprecate them)
- Chairs believes this is important work item and want to poll from the WG =
to see about making this an official WG item.  Do you feel this is a WG tha=
t would be willing to review?
- 2 respond yes. None one responds negatively
- Bernard and Stefan in jabber also support this
- Chairs will take this to mail list for final consensus call


1110 - 1130 Discussion and Wrap-up=2C WG Chairs & AD (20 minutes)
- Many things on the pipelines=2C requests group review of existing=20
- Last Call on IPv6 attrs will be opened up
- Dan has nothing to add but would like to see more reviews and contributor=
s

 		 	   		  =

--_73bac9af-fdaf-4a3e-af4e-34a32d196294_
Content-Type: text/html; charset="Windows-1252"
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'>


<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style>
RADEXT WG Minutes<br>IETF 79<br>Beijing=2C China <br>Friday=2C November 12=
=2C 2010<br>Meeting start 9:00AM CST<br><br>Chairs:&nbsp=3B Bernard Aboba &=
lt=[e-mail]&gt=3B<br>Mauricio Sanchez &lt=3Bmauricio.san=
[e-mail]&gt=3B<br><br>Agenda<br>0900 - 0920:&nbsp=3B Preliminaries<br>*B=
lue Sheets=2C Note takers=2C Jabber Scribe<br>*Agenda bash=2C Document Stat=
us<br><br>1.&nbsp=3B&nbsp=3B &nbsp=3BMauricio reviewed the agenda. No sugge=
sted changes.<br>-&nbsp=3B&nbsp=3B &nbsp=3BJabber scribe: Dan Romascanu<br>=
-&nbsp=3B&nbsp=3B &nbsp=3BNote taker: Nancy Cam-Winget<br><br>2.&nbsp=3B&nb=
sp=3B &nbsp=3BMauricio reviewed the document status=2C see https://datatrac=
ker.ietf.org/wg/radext/ .<br><br>0920 - 0930&nbsp=3B Hot Errata=2C WG Chair=
s (10 minutes)<br>- Discussion of issue 1469 (RFC 2865) and issue 753 (RFC =
4282) <br>o Dan Romanascu asks whether status should really be changed?&nbs=
p=3B Per guideline review rules=2C this is what seems to be an appropriate =
resolution. Dan believes that it may be misleading.<br>o Dan states=94verif=
ied means that it has been verified=2C accepted and enforced=94 which is ty=
pically for errata that need small fixes with technical meaning. =93held fo=
r doc=94 means that the errata is not enforced but discussion is deferred u=
ntil the document is updated=3B is this what we really want?&nbsp=3B Chair =
says =93no=94=2C but want to acknowledge that the issue does exist. <br>o D=
an asks if intent is to =93enforce=94 vs. =93hidden until doc is revised=94=
? Chair believes the latter=2C so from procedural view=2C take lodge recomm=
endation with AD (Dan). &nbsp=3B<br>o Bernard comments why =93held for veri=
fy=94=2C the error was intentional. we do not want it enforced.&nbsp=3B Dan=
 clarifies that 1469 should be =93held=94 vs =93verify=94=2C 753 should be =
changed from verify to =93rejected=94 asks Bernard to confirm.&nbsp=3B Bern=
ard confirms on 753 and 1469 should stay =93verify=94.&nbsp=3B Dan takes no=
te to update status of these docs. <br><br>-Discussion of issues 2507 and 2=
508 of RFC 5597<br>o More editorial comments came in around =93access-accep=
t=94 misleading note (2507) and typo in mention of =93server=94 should be =
=93client=94 (2508).&nbsp=3B Status is to keep them as =93held for document=
 update=94. <br>o Alan comments that someone should be reading this well be=
fore final publication.<br><br><br>0930 - 0940 RADIUS over TCP=2C Alan DeKo=
k (10 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-tcp<br>- One=
 change (issue 59) to fix issue=2C believes there=92s nothing left to resol=
ve in the document.&nbsp=3B Removes reference to CoA.<br>- Should be ready =
to go and get it reviewed again.&nbsp=3B Bernard asks if it should go to IE=
SG discussion? Mauricio believes group signed off on document. Dan suggests=
 can go to the next step. Bernard believes Ralph may not believe issue is a=
ddressed.&nbsp=3B Alan mentions that Ralph had reviewed and had not added a=
ny other comment.&nbsp=3B If more comments come=2C Alan can respond to them=
.&nbsp=3B Dan suggests to make sure loop with Ralph is closed as Bernard be=
lieves issue is not closed (according to Ralph).<br><br>0940 - 0950 Design =
Guidelines=2C Alan DeKok (10 minutes)<br>http://tools.ietf.org/html/draft-i=
etf-radext-design/<br>-Cleared open issues=2C review from Lionel Morand=2C =
clarifications and grammar fixes reports=3B new version -19 released on Mon=
.<br>-Current timeframe for reviews (theoretically it=92s a bit late but wi=
ll try to put it on next week=92s agenda with good chance of it being defer=
red till the 1st week of Dec).<br><br><br>0950 - 1010 RADIUS over TLS=2C St=
efan Winter (20 minutes)<br>http://tools.ietf.org/html/draft-ietf-radext-ra=
dsec<br>- No new rev as issues 59 (CoA) and 60 need discussion.<br>- Should=
 all traffic run on a port or should 3 diff ports be used (session acct=2C =
CoA=2C etc).&nbsp=3B Q1: 1812=2C 1813=2C 3799 or 2083 for all though all ex=
isting implementations do 2083.&nbsp=3B Suggests that there are merits to u=
sing 3 diff ports=2C but would like to solicit feedback of 1 vs 3 ports.<br=
>- If there are 3 diff ports=2C which should they be: new or resued 1812=2C=
 1813 and 3799? Cleaner to take separate ports but usurps IANA real estate=
=2C reuse of ports puts us at whim of TLS (1st byte will need to be differe=
nt).<br>- Next steps: poll and consensus of 1 vs. 3 ports=2C new ports vs. =
multiplex.<br>- Comment from Alan: for existing radius (radsec admins shoul=
d talk to each other so can work today but) should not rely on this in the =
future.&nbsp=3B Not sure if it should be part of Radius over TLS doc. There=
 may need to be other interdependent docs that show how to use radius packe=
ts with tls.&nbsp=3B Difficult to say what=92s better.<br>- Stefan comments=
 that then 3 ports may be better.<br>- Bernard comments that radius/dtls di=
scovers the use of udp=2C so if its tcp should this be an issue?<br>- Alan =
if radius over tcp over ipsec=2C that should be valid. Question is it is an=
 admin config issue or have the protocol figure it out?<br>- Stefan comment=
s that tcp should be considered so demultiplexing may be appropriate.<br>- =
Bernard asks what is in the first byte of tls?<br>- Alan says it=92s a tls =
handshake byte and believes it would not change as things like https may br=
eak.&nbsp=3B Can ask the tls folks=2C but doubts that packets like start tl=
s would change too much.<br>- Mauricio agrees that we could potentially mak=
e it a constant.<br>- Suggestion is to ask Eric Rescorla/Joe Salowey and TL=
S experts to confirm this.<br>- Bernard states that feedback from implement=
ers will also be key.<br>- Stefan suggests reuse of existing.<br>- Bernard =
agrees that yes=2C with multiplexing. If vendors are willing to do this the=
n we can go this route=2C otherwise we=92ll have to take a different approa=
ch.<br><br>1010 - 1030 Dynamic Peer Discovery=2C Stefan Winter (20 minutes)=
<br>http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery<br>- No =
new rev as discussion on port/packet type needs discussion. Dependency on t=
he ports used (1 vs 3)<br>- Would need 3 labels: auth=2C acct=2C dynauth if=
 3 ports chosen.<br>- Could look like S-naptrs (radius.tls=2C radacct.tls=
=2C raddynauth.tls).<br>- Mauricio says as there=92s dependency on previous=
 draft=2C we should hold off until decisions on prev draft are made.&nbsp=
=3B This will be in holding pattern until confirmation on prev draft decisi=
ons are made<br><br>1030 - 1040 RADIUS over DTLS=2C Alan DeKok (10 minutes)=
<br>http://tools.ietf.org/html/draft-ietf-radext-dtls<br>- No major changes=
 done. Issues of doc is that it is really a diff of the&nbsp=3B RADIUS over=
 TLS document. So rather than rewrite=2C it docs what applies or how it is =
different.<br>- Open issues: need to re-sync with RTLS draft.&nbsp=3B Make =
sense to reuse same port but would like review from Stig Venaas (radsecprox=
y).<br>- Bernard asks Alan whether implementers are in agreement on port im=
plementation?<br>- Alan says no=85in looking at RADIUS over TLS source code=
=2C they are treated separately.&nbsp=3B The goal for freeradius is that it=
 should accept radius and tls on the same port.<br><br>1040 - 1110 Extended=
 Attributes=2C Alan DeKok (30 minutes)<br>http://tools.ietf.org/html/draft-=
ietf-radext-extended-attributes<br>History: Need more attributes as 256 is =
too limited=2C the grouping is not adequate (RFC 2868 not sufficient).<br>-=
 Previous WG discussion was that diameter attrs were too complex.&nbsp=3B T=
he existing draft for&nbsp=3B extended attrs had some traction but realizat=
ion was that they didn=92t actually work so prev authors dropped it as they=
 don=92t believe its relevant.&nbsp=3B At last IETF=2C Stefan and Alan whit=
eboarded (and then Avi joined) to put this doc together.<br>- New TLV: adds=
 one byte to call it the =93extended type=94: 4 attrs from the reserved spa=
ce . Need to name new attributes and grouping defining a TLV data type alre=
ady in WiMax=2C 3Gpp2 and other sdo=92s/vendors=3B while not as powerful in=
 diameter=2C it is leveraging existing code (e.g. proven usefulness in radi=
us).<br>- TLV data type reuses radius format (e.g. TLV).imposes a nest in T=
LV within TLV=2C can be nested to arbitrary depth and limited by the length=
 field (sum of TLV lengths must add up to the encapsulated length)=3B thoug=
h anything beyond depth 5 can become confusing.<br>- TLV naming: IANA to tr=
ack=2C leverage same dotted notation (e.g. 241.1.2 =3D Radius attr 241 of t=
ype =93ext-attr=94=2C extend attr 1=2C data type =93tlv=94=2C tlv 2=2C data=
 type =93integer=94).<br>- Use of long attributes definitions includes a ne=
w flag (1 octet).<br>- Suggestion is to make =91flag=92 be compatible with =
wimax. More details to be sorted with by Alan and Avi=85.not sure that extr=
a 7 bits would be used for anything.<br>- Extending vsa space 24{1-6}.26 ar=
e VSAs and allows for more to be supported.<br>- Motivation: believes that =
a solution is needed w/in 2-3 yrs.<br>- Stefan asks why not have flag in th=
ese attributes? Alan responds that half of the defined attrs are &lt=3B20 b=
ytes=2C so having a flag for them=2C best guess is that they would be &lt=
=3B 20bytes and having a flag for each of them would not be efficient.<br>-=
 Stefan asks how may deployments have gone the =93simple=94 string&nbsp=3B =
mechanism as they were no longer =93attributes=94.&nbsp=3B Alan mentions au=
dit was not perfect=2C but its easy to strip out something =93small=94 and =
looking at the rest=3B though indiv class attributes only about 20 require =
253 octects=2C including wimax that defines attrs that carry tlv=92s. the t=
lv=92s tend to be generic filter rules that can be nested and carry a subst=
antial amount of data within one attribute.&nbsp=3B So believes there=92s n=
ot great demand that require more than 253 bytes of data and most are defin=
ed by rfc 5907 (not sure of #?) and those tend to include certs. The rest s=
eem to be small. And even those are allocated rarely (e.g. once every 2-3yr=
s)=85giving us ability to have a simpler format.<br>- 2 interop implementat=
ions for this already: basic support in freeradius (no long attrs yet)=2C c=
lient support in IEA software. <br>- Todo: define VSA data type (easier tha=
n repeating attr definition)=2C more guideline recommendations=2C more exam=
ples and clarifications.<br>- Bernard asks if guidelines need to be covered=
 in this draft or if a different doc may be needed?&nbsp=3B Alan says its a=
 good question=2C some guidelines would be good to show applicability on so=
me of this=2C but it may be OK to keep them high level in this doc.<br>- Be=
rnard asks if Alan envisions carrying over some of the guidelines from the =
guidelines doc to this one.&nbsp=3B Alan: yes.<br>- Bernard asks if vendors=
 are ok with new VSA type?&nbsp=3B Alan says no=2C though idea is to use so=
mething similar to RFC 2865 (4byte vendor ID).so most people have followed =
TLV fmt per rfc=2C some have not.given some attr have length attached=2C fo=
r compatibility rfc 2865 are typically encapsulated in a vendor specific at=
tr though its not been done by all vendors.<br>- Stefan asks if proposed at=
trs been hijacked yet? Alan mentions as the new vsa=92s are in context of e=
xtended attrs=2C believes that those attrs have been hijacked by vendors an=
d doc discusses this and how proxies can help detect these. Eduroam did an =
audit to show that most proxies were ok=2C but a few were not=3B so doc mak=
es suggestions on what to do (.e.g take existing hijacked defns and discard=
 them. Take old equipment and deprecate them)<br>- Chairs believes this is =
important work item and want to poll from the WG to see about making this a=
n official WG item.&nbsp=3B Do you feel this is a WG that would be willing =
to review?<br>- 2 respond yes. None one responds negatively<br>- Bernard an=
d Stefan in jabber also support this<br>- Chairs will take this to mail lis=
t for final consensus call<br><br><br>1110 - 1130 Discussion and Wrap-up=2C=
 WG Chairs &amp=3B AD (20 minutes)<br>- Many things on the pipelines=2C req=
uests group review of existing <br>- Last Call on IPv6 attrs will be opened=
 up<br>- Dan has nothing to add but would like to see more reviews and cont=
ributors<br><br> 		 	   		  </body>
</html>=

--_73bac9af-fdaf-4a3e-af4e-34a32d196294_--

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


Envelope-to: [e-mail]
Delivery-date: Sat, 12 Feb 2011 08:00:31 +0000
Message-ID: <[e-mail]>
Date: Sat, 12 Feb 2011 08:59:26 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: [e-mail]
Subject: Re: FW: [IANA #409959] General Request for Assignments
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> *3. Why should we just allocate a generic WiMAX NAS-Port and let
> additional data be included in a WiMAX Forum VSA? *

  I'm of two minds about this.  Subclassing the NAS-Port-Type by
requiring SDOs to add their own "WiMAX-NAS-Port-Type" attribute seems
inefficient.

  That being said, there's already a WiMAX-Transport-Type attribute
define.  So adding WiMAX-NAS-Port-Type might not be out of the realm of
possibility.

  Still, there are nearly 2^32 unallocated values for NAS-Port-Type.  I
think the only reason not to assign these values is for consistency, not
efficiency.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Fri, 11 Feb 2011 21:48:00 +0000
Message-ID: <[e-mail]>
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Subject: FW: [IANA #409959] General Request for Assignments 
Date: Fri, 11 Feb 2011 13:48:34 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0125_01CBC9F2.609AD6E0"
Thread-Index: AcvKKnuFvDBzh52hb02pVwGrCc/hAAACn0Fw
Content-Language: en-us

------=_NextPart_000_0125_01CBC9F2.609AD6E0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Can someone answer the following questions?

1. What is different between WiMAX WiFi and normal IEEE 802.11?  We already
have a number of IEEE 802.11 NAS-Port-types allocated and have proposed
additional data for this. 

2. Why do DHCP and a location service need NAS-Port-Type values?  

3. Why should we just allocate a generic WiMAX NAS-Port and let additional
data be included in a WiMAX Forum VSA? 


On Fri Nov 26 15:45:24 2010, [e-mail] wrote:
> Contact Name :
> Avi Lior
> 
> Contact Email :
> [e-mail]
> 
> Type of Assignment :
> Seeing new Nas-Port-Type values as follows:
> TBD for WIMAX-3GPP-PRIF:
>    WiMAX Pre-Release 8 IWK Function
> TBD for WIMAX-WIFI-IWK:  WiMAX
>    WIFI Interworking
> TBD for WIMAX-SFF: Signaling Forwarding Function
>    for LTE/3GPP2.
> TBD for WIMAX-HA-LMA:  WiMAX HA and or LMA
>    function.
> TBD for WIMAX-DHCP : WIMAX DCHP service
> TBD for WIMAX-
>    LBS  : WiMAX location based service
> TBD for WIMAX-WVS : WiMAX
>    voice service
> 
> Registry :
> NAS-Port-Type (attribute 61) from RADIUS Type Registry
> 
> Description :
> These assignments will allow the RADIUS server to determine the
>    service context of the access-request.  For example whether the
>    RADIUS message is coming from a Signalling Forwarding Function(SFF)
>    or WiMAX voice function etc.
> 
> Additional Info :
> Reference specifications are avaialble from WiMAX Forum at the
>    following site:
> http://www.wimaxforum.org/
> 




------=_NextPart_000_0125_01CBC9F2.609AD6E0
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:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" =
xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" =
xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" =
xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" =
xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" =
xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig=
nature" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" =
xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/=
" =
xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub=
lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" =
xmlns:st=3D"&#1;" 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 12 =
(filtered medium)"><title>[IANA #409959] General Request for Assignments =
</title><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@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:12.0pt;
	font-family:"Times New Roman","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-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 =
style=3D'margin-bottom:12.0pt'><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:#1F497D=
'>Can someone answer the following =
questions?<o:p></o:p></span></b></p><p class=3DMsoNormal =
style=3D'margin-bottom:12.0pt'><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:#1F497D=
'>1. What is different between WiMAX WiFi and normal IEEE 802.11?&nbsp; =
We already have a number of IEEE 802.11 NAS-Port-types allocated and =
have proposed additional data for this. <o:p></o:p></span></b></p><p =
class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:#1F497D=
'>2. Why do DHCP and a location service need NAS-Port-Type values?&nbsp; =
<o:p></o:p></span></b></p><p class=3DMsoNormal =
style=3D'margin-bottom:12.0pt'><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:#1F497D=
'>3. Why should we just allocate a generic WiMAX NAS-Port and let =
additional data be included in a WiMAX Forum VSA? =
<o:p></o:p></span></b></p><p class=3DMsoNormal =
style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>On Fri =
Nov 26 15:45:24 2010, <a =
href=3D"[e-mail]">[e-mail]</a> =
wrote:<br>&gt; Contact Name :<br>&gt; Avi Lior<br>&gt; <br>&gt; Contact =
Email :<br>&gt; <a =
href=3D"[e-mail]">[e-mail]</a><br>&gt=
; <br>&gt; Type of Assignment :<br>&gt; Seeing new Nas-Port-Type values =
as follows:<br>&gt; TBD for WIMAX-3GPP-PRIF:<br>&gt; =
&nbsp;&nbsp;&nbsp;WiMAX Pre-Release 8 IWK Function<br>&gt; TBD for =
WIMAX-WIFI-IWK: &nbsp;WiMAX<br>&gt; &nbsp;&nbsp;&nbsp;WIFI =
Interworking<br>&gt; TBD for WIMAX-SFF: Signaling Forwarding =
Function<br>&gt; &nbsp;&nbsp;&nbsp;for LTE/3GPP2.<br>&gt; TBD for =
WIMAX-HA-LMA: &nbsp;WiMAX HA and or LMA<br>&gt; =
&nbsp;&nbsp;&nbsp;function.<br>&gt; TBD for WIMAX-DHCP : WIMAX DCHP =
service<br>&gt; TBD for WIMAX-<br>&gt; &nbsp;&nbsp;&nbsp;LBS &nbsp;: =
WiMAX location based service<br>&gt; TBD for WIMAX-WVS : WiMAX<br>&gt; =
&nbsp;&nbsp;&nbsp;voice service<br>&gt; <br>&gt; Registry :<br>&gt; =
NAS-Port-Type (attribute 61) from RADIUS Type Registry<br>&gt; <br>&gt; =
Description :<br>&gt; These assignments will allow the RADIUS server to =
determine the<br>&gt; &nbsp;&nbsp;&nbsp;service context of the =
access-request. &nbsp;For example whether the<br>&gt; =
&nbsp;&nbsp;&nbsp;RADIUS message is coming from a Signalling Forwarding =
Function(SFF)<br>&gt; &nbsp;&nbsp;&nbsp;or WiMAX voice function =
etc.<br>&gt; <br>&gt; Additional Info :<br>&gt; Reference specifications =
are avaialble from WiMAX Forum at the<br>&gt; =
&nbsp;&nbsp;&nbsp;following site:<br>&gt; <a =
href=3D"http://www.wimaxforum.org/">http://www.wimaxforum.org/</a><br>&gt=
; <br><br></span><o:p></o:p></p></div></body></html>
------=_NextPart_000_0125_01CBC9F2.609AD6E0--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 11 Feb 2011 18:25:34 +0000
Message-ID: <[e-mail]>
From: Bernard Aboba <[e-mail]>
To: "'Peter Deacon'" <[e-mail]>, <[e-mail]>
Subject: RE: Call for Adoption as a RADEXT WG Work item:    draft-dekok-radext-radius-extensions-01.txt
Date: Fri, 11 Feb 2011 10:26:30 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AcvKFrl5OGWB2N1/QQSGP+TipgpR3AAAmQJQ
Content-Language: en-us

So do I <individual hat on>.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] =
On
Behalf Of Peter Deacon
Sent: Friday, February 11, 2011 10:05 AM
To: [e-mail]
Subject: Re: Call for Adoption as a RADEXT WG Work item:
draft-dekok-radext-radius-extensions-01.txt

On Tue, 8 Feb 2011, Bernard Aboba wrote:

> An alternate approach has therefore been proposed by Alan DeKok and =
Avi
Lior.

> To determine whether to adopt this alternative approach, we are now =
doing
a Call
> for Adoption of the document "RADIUS Extensions" as a RADEXT WG work
item.=A0 The
> document is available for inspection here:
> http://www.ietf.org/id/draft-dekok-radext-radius-extensions-01.txt

> Please read the document, and respond to this Call for Adoption by=20
> February 23, 2011, indicating whether you favor adoption of the =
"RADIUS=20
> Extensions" document (implying deprecation of the 'Extended RADIUS=20
> Attributes" document), or not.

I favor adoption.

~P


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


Envelope-to: [e-mail]
Delivery-date: Fri, 11 Feb 2011 18:06:16 +0000
Date: Fri, 11 Feb 2011 10:04:44 -0800 (Pacific Standard Time)
From: Peter Deacon <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Re: Call for Adoption as a RADEXT WG Work item:    draft-dekok-radext-radius-extensions-01.txt
Message-ID: <alpine.WNT.2.00.1102081058570.5948@SMURF>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="433244096-30403-1297191836=:5948"
Content-ID: <alpine.WNT.2.00.1102110959250.2280@SMURF>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--433244096-30403-1297191836=:5948
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; FORMAT=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.WNT.2.00.1102110959251.2280@SMURF>

On Tue, 8 Feb 2011, Bernard Aboba wrote:

> An alternate approach has therefore been proposed by Alan DeKok and Avi Lior.

> To determine whether to adopt this alternative approach, we are now doing a Call
> for Adoption of the document "RADIUS Extensions" as a RADEXT WG work item.  The
> document is available for inspection here:
> http://www.ietf.org/id/draft-dekok-radext-radius-extensions-01.txt

> Please read the document, and respond to this Call for Adoption by 
> February 23, 2011, indicating whether you favor adoption of the "RADIUS 
> Extensions" document (implying deprecation of the 'Extended RADIUS 
> Attributes" document), or not.

I favor adoption.

~P
--433244096-30403-1297191836=:5948--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 08 Feb 2011 17:25:10 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_88cc60b7-bc67-4521-8c32-9fd98dab7e73_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Call for Adoption as a RADEXT WG Work item: draft-dekok-radext-radius-extensions-01.txt
Date: Tue, 8 Feb 2011 09:24:42 -0800
MIME-Version: 1.0

--_88cc60b7-bc67-4521-8c32-9fd98dab7e73_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


As was discussed at the last RADEXT Interim meeting and at IETF 79=2C the d=
ocument "Extended RADIUS Attributes"  (http://tools.ietf.org/html/draft-iet=
f-radext-extended-attributes) expired in November 2010=2C and interest amon=
g RADIUS client and server implementers appears to be lagging.=20

An alternate approach has therefore been proposed by Alan DeKok and Avi Lio=
r.=20

To determine whether to adopt this alternative approach=2C we are now doing=
 a Call for Adoption of the document "RADIUS Extensions" as a RADEXT WG wor=
k item.  The document is available for inspection here:
http://www.ietf.org/id/draft-dekok-radext-radius-extensions-01.txt

Please read the document=2C and respond to this Call for Adoption by Februa=
ry 23=2C 2011=2C indicating whether you favor adoption of the "RADIUS Exten=
sions" document (implying deprecation of the 'Extended RADIUS Attributes" d=
ocument)=2C or not. =20


 		 	   		  =

--_88cc60b7-bc67-4521-8c32-9fd98dab7e73_
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'>
As was discussed at the last RADEXT Interim meeting and at IETF 79=2C the d=
ocument "Extended RADIUS Attributes"&nbsp=3B (http://tools.ietf.org/html/dr=
aft-ietf-radext-extended-attributes) expired in November 2010=2C and intere=
st among RADIUS client and server implementers appears to be lagging. <br><=
br>An alternate approach has therefore been proposed by Alan DeKok and Avi =
Lior. <br><br>To determine whether to adopt this alternative approach=2C we=
 are now doing a Call for Adoption of the document "RADIUS Extensions" as a=
 RADEXT WG work item.&nbsp=3B The document is available for inspection here=
:<br>http://www.ietf.org/id/draft-dekok-radext-radius-extensions-01.txt<br>=
<br>Please read the document=2C and respond to this Call for Adoption by Fe=
bruary 23=2C 2011=2C indicating whether you favor adoption of the "RADIUS E=
xtensions" document (implying deprecation of the 'Extended RADIUS Attribute=
s" document)=2C or not.&nbsp=3B <br><br><br> 		 	   		  </body>
</html>=

--_88cc60b7-bc67-4521-8c32-9fd98dab7e73_--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 08 Feb 2011 16:58:04 +0000
Message-ID: <[e-mail]>
Date: Tue, 08 Feb 2011 17:57:15 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: 'radext mailing list' <[e-mail]>
Subject: [Fwd: New Version Notification for          draft-dekok-radext-radius-extensions-01]
Content-Type: multipart/mixed; boundary="------------080104000905030105090403"

This is a multi-part message in MIME format.
--------------080104000905030105090403
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

  A new version has been submitted.  The changes are large, but are
limited to exposition of previously documented ideas.

--------------080104000905030105090403
Content-Type: message/rfc822;
 name="New Version Notification for          draft-dekok-radext-radius-extensions-01.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename*0="New Version Notification for          draft-dekok-radext-rad";
 filename*1="ius-extensions-01.eml"

X-Account-Key: account3
X-Mozilla-Keys:                                                                                 
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32])
	by liberty.deployingradius.com (Postfix) with ESMTP id D953E12340CD
	for <[e-mail]>; Tue,  8 Feb 2011 17:54:35 +0100 (CET)
Received: by core3.amsl.com (Postfix, from userid 30)
	id CCB2F3A679F; Tue,  8 Feb 2011 08:54:27 -0800 (PST)
From: IETF I-D Submission Tool <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: New Version Notification for 
         draft-dekok-radext-radius-extensions-01 
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue,  8 Feb 2011 08:54:27 -0800 (PST)


A new version of I-D, draft-dekok-radext-radius-extensions-01.txt has been successfully submitted by Alan DeKok and posted to the IETF repository.

Filename:	 draft-dekok-radext-radius-extensions
Revision:	 01
Title:		 Remote Authentication Dial In User Service (RADIUS) Protocol Extensions
Creation_date:	 2011-02-08
WG ID:		 Independent Submission
Number_of_pages: 56

Abstract:
The Remote Authentication Dial In User Service (RADIUS) protocol is
nearing exhaustion of its current 8-bit attribute type space.  In
addition, experience shows a growing need for complex grouping, along
with attributes which can carry more than 253 octets of data.  This
document defines changes to RADIUS which address all of the above
problems.
                                                                                  


The IETF Secretariat.





--------------080104000905030105090403--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 08 Feb 2011 14:31:31 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_32d734e0-de0d-44e3-a065-89b7c28c9bd5_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Request for Review:  DTLS as a Transport Layer for RADIUS
Date: Tue, 8 Feb 2011 06:30:22 -0800
MIME-Version: 1.0

--_32d734e0-de0d-44e3-a065-89b7c28c9bd5_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


This is a request for additional review of "DTLS as a Transport Layer for R=
ADIUS".  The document may be found here:
http://tools.ietf.org/html/draft-ietf-radext-dtls

The "Request for Review" will last until February 22=2C 2011.=20

RADEXT WG Participants are encouraged to read the document and post issues =
in the TRAC database (see below for details on how to do this) or on the RA=
DEXT WG mailing list.=20

Currently there is one open ticket against this document:
http://trac.tools.ietf.org/wg/radext/trac/ticket/15

When all the open issues from this "Request for Review" are addressed=2C th=
e document will go to WG last call.=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
1.       To submit an issue in TRAC=2C you first need to login to the RADEX=
T WG site on the tools server:  http://tools.ietf.org/wg/radext/trac/login=
=20

2.       If you don=92t already have a login ID=2C you can obtain one by na=
vigating to this site:   http://trac.tools.ietf.org/newlogin

3.       Once you have obtained an account=2C and have logged in=2C you can=
 file an issue by navigating to the  ticket entry form: http://trac.tools.i=
etf.org/wg/radext/trac/newticket

4.       When opening an issue:

a.     =20
 The Type: field should be set to =93defect=94 for an issue with the curren=
t
 document text=2C or =93enhancement=94 for a proposed addition of=20
functionality (such as an additional requirement).=20
b.      The=20
Priority: field is set based on the severity of the Issue.   For=20
example=2C editorial issues are typically =93minor=94 or =93trivial=94.=20
c.       The Milestone: field should be set to milestone1 (useless=2C I kno=
w).=20
d.      The Component: field should be set to the document you are filing t=
he issue on. =20
e.      The Version: field should be set to =931.0=94.=20
f.      =20
 The Severity: field should be set to based on the status of the=20
document (e.g. =93In WG Last Call=94 for a document in WG last call)
g.        The Keywords: and CC: fields can be left blank unless inspiration=
 seizes you.=20
h.      The Assign To: field is generally filled in with the email address =
of the editor.=20

5.     =20
 Typically it won=92t be necessary to enclose a file with the ticket=2C but=
=20
if you need to=2C select =93I have files to attach to this ticket=94.=20

6.     =20
 If you want to preview your Issue=2C click on the =93Preview=94 button.  W=
hen
 you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but=
ton.=20

7.       If you want to update an issue=2C go to the "View Tickets" page: h=
ttp://trac.tools.ietf.org/wg/radext/trac/report/1  Click on the ticket # yo=
u want to update=2C and then modify the ticket fields as required=20

 		 	   		  =

--_32d734e0-de0d-44e3-a065-89b7c28c9bd5_
Content-Type: text/html; charset="Windows-1252"
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'>
This is a request for additional review of "DTLS as a Transport Layer for R=
ADIUS".&nbsp=3B The document may be found here:<br>http://tools.ietf.org/ht=
ml/draft-ietf-radext-dtls<br><br>The "Request for Review" will last until F=
ebruary 22=2C 2011. <br><br>RADEXT WG Participants are encouraged to read t=
he document and post issues in the TRAC database (see below for details on =
how to do this) or on the RADEXT WG mailing list. <br><br>Currently there i=
s one open ticket against this document:<br>http://trac.tools.ietf.org/wg/r=
adext/trac/ticket/15<br><br>When all the open issues from this "Request for=
 Review" are addressed=2C the document will go to WG last call. <br><br>=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br><p class=3D"MsoNormal" =
style=3D"margin-bottom: 12pt=3B"><span style=3D"font-size: 10pt=3B font-fam=
ily: &quot=3BVerdana&quot=3B=2C&quot=3Bsans-serif&quot=3B=3B">1.&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B To submit an issue in TRAC=2C you fir=
st need to login to the RADEXT WG site on the tools server:&nbsp=3B <a rel=
=3D"nofollow" href=3D"http://tools.ietf.org/wg/radext/trac/login">http://to=
ols.ietf.org/wg/radext/trac/login</a> <br><br>2.&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B If you don=92t already have a login ID=2C you can obt=
ain one by navigating to this site:&nbsp=3B&nbsp=3B <a rel=3D"nofollow" hre=
f=3D"http://trac.tools.ietf.org/newlogin">http://trac.tools.ietf.org/newlog=
in</a><br><br>3.&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Once you h=
ave obtained an account=2C and have logged in=2C you can file an issue by n=
avigating to the&nbsp=3B ticket entry form: <a rel=3D"nofollow" href=3D"htt=
p://trac.tools.ietf.org/wg/radext/trac/newticket">http://trac.tools.ietf.or=
g/wg/radext/trac/newticket</a><br><br>4.&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B When opening an issue:<br><br>a.&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B
 The Type: field should be set to =93defect=94 for an issue with the curren=
t
 document text=2C or =93enhancement=94 for a proposed addition of=20
functionality (such as an additional requirement). <br>b.&nbsp=3B&nbsp=3B&n=
bsp=3B&nbsp=3B&nbsp=3B The=20
Priority: field is set based on the severity of the Issue.&nbsp=3B&nbsp=3B =
For=20
example=2C editorial issues are typically =93minor=94 or =93trivial=94. <br=
>c.&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B The Milestone: field sh=
ould be set to milestone1 (useless=2C I know). <br>d.&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B The Component: field should be set to the document you =
are filing the issue on.&nbsp=3B <br>e.&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbs=
p=3B The Version: field should be set to =931.0=94. <br>f.&nbsp=3B&nbsp=3B&=
nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B
 The Severity: field should be set to based on the status of the=20
document (e.g. =93In WG Last Call=94 for a document in WG last call)<br>g.&=
nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B The Keywords: and C=
C: fields can be left blank unless inspiration seizes you. <br>h.&nbsp=3B&n=
bsp=3B&nbsp=3B&nbsp=3B&nbsp=3B The Assign To: field is generally filled in =
with the email address of the editor. <br><br>5.&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B
 Typically it won=92t be necessary to enclose a file with the ticket=2C but=
=20
if you need to=2C select =93I have files to attach to this ticket=94. <br><=
br>6.&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B
 If you want to preview your Issue=2C click on the =93Preview=94 button.&nb=
sp=3B When
 you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but=
ton. <br><br>7.&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B If you want=
 to update an issue=2C go to the "View Tickets" page: <a rel=3D"nofollow" h=
ref=3D"http://trac.tools.ietf.org/wg/radext/trac/report/1">http://trac.tool=
s.ietf.org/wg/radext/trac/report/1</a>&nbsp=3B Click on the ticket # you wa=
nt to update=2C and then modify the ticket fields as required</span><span s=
tyle=3D"font-size: 11pt=3B font-family: &quot=3BCalibri&quot=3B=2C&quot=3Bs=
ans-serif&quot=3B=3B"></span></p><p class=3D"MsoNormal">&nbsp=3B</p><br><br=
> 		 	   		  </body>
</html>=

--_32d734e0-de0d-44e3-a065-89b7c28c9bd5_--

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