Envelope-to: radiusext-data@psg.com
Delivery-date: Sat, 30 Jun 2007 15:20:45 +0000
Message-ID: <BAY117-W65992B724AE5C3379F974930F0@phx.gbl>
Content-Type: multipart/alternative; boundary="_32aaaad7-8b63-4730-b12b-34f2f67cf518_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: "David B. Nelson" <dnelson@elbrysnetworks.com>, <radiusext@ops.ietf.org>
Subject: RE: New version of RADIUS WLAN document
Date: Sat, 30 Jun 2007 08:19:42 -0700
MIME-Version: 1.0

--_32aaaad7-8b63-4730-b12b-34f2f67cf518_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


It is the same type as Called-Station-Id, which is defined as type "String"=
 in RFC 2865, Section 5.30. > From: dnelson@elbrysnetworks.com> To: radiuse=
xt@ops.ietf.org> Subject: RE: New version of RADIUS WLAN document> Date: Fr=
i, 29 Jun 2007 13:54:17 -0400> > Is Allowed-Called-Station-ID a RADIUS Stri=
ng type or Text type?  From the> description, it sound like it's Text.> > >=
 --> to unsubscribe send a message to radiusext-request@ops.ietf.org with> =
the word 'unsubscribe' in a single line as the message text body.> archive:=
 <http://psg.com/lists/radiusext/>=

--_32aaaad7-8b63-4730-b12b-34f2f67cf518_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
It is the same type as Called-Station-Id, which is defined as type "String"=
 in RFC 2865, Section 5.30. <br><br>&gt; From: dnelson@elbrysnetworks.com<b=
r>&gt; To: radiusext@ops.ietf.org<br>&gt; Subject: RE: New version of RADIU=
S WLAN document<br>&gt; Date: Fri, 29 Jun 2007 13:54:17 -0400<br>&gt; <br>&=
gt; Is Allowed-Called-Station-ID a RADIUS String type or Text type?  From t=
he<br>&gt; description, it sound like it's Text.<br>&gt; <br>&gt; <br>&gt; =
--<br>&gt; to unsubscribe send a message to radiusext-request@ops.ietf.org =
with<br>&gt; the word 'unsubscribe' in a single line as the message text bo=
dy.<br>&gt; archive: &lt;http://psg.com/lists/radiusext/&gt;<br></body>
</html>=

--_32aaaad7-8b63-4730-b12b-34f2f67cf518_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Fri, 29 Jun 2007 17:56:46 +0000
From: "David B. Nelson" <dnelson@elbrysnetworks.com>
To: <radiusext@ops.ietf.org>
Subject: RE: New version of RADIUS WLAN document
Date: Fri, 29 Jun 2007 13:54:17 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <005101c7ba76$8330f700$5d1216ac@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: Ace5HKRL58S2V8qbTsi4AtNK52IstQBPy7+g

Is Allowed-Called-Station-ID a RADIUS String type or Text type?  From the
description, it sound like it's Text.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Fri, 29 Jun 2007 10:17:51 +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: PRELIMINARY Agenda and Package for July 5, 2007 Telechat 
Date: Fri, 29 Jun 2007 12:16:40 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A0419D781@307622ANEX5.global.avaya.com>
Thread-Topic: PRELIMINARY Agenda and Package for July 5, 2007 Telechat 
Thread-Index: Ace51bGZD3VD9TOARX+lQsp8kJaqbgAYHqBg
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: <ops-area@ietf.org>, "Ops-Nm" <ops-nm@ietf.org>, "Aaa-Doctors (E-mail)" <aaa-doctors@ops.ietf.org>, <mib-doctors@ietf.org>, <ipfix@ietf.org>, <radiusext@ops.ietf.org>

Please find below the preliminary agenda for the 7/5 IESG telechat.
Please forward to me all comments and concerns until Wednesday 7/4 COB.=20

Thanks and Regards,

Dan



2.1 WG Submissions
2.1.1 New Item
  o draft-ietf-ipfix-biflow-05.txt
    Bidirectional Flow Export using IPFIX (Proposed Standard) - 1 of 3=20
    Note: Nevil Brownlee is the proto-shepherd=20
    Token: Dan Romascanu
  o draft-ietf-radext-rfc4590bis-01.txt
    RADIUS Extension for Digest Authentication (Proposed Standard) - 2
of
3=20
    Note: A revised version of non-normative Section 6 (Examples) will
be

    provided in order to fix problems detected during the Last Call.=20
    Token: Dan Romascanu
  o draft-ietf-radext-fixes-04.txt
    Common Remote Authentication Dial In User Service (RADIUS)
Implementation=20
    Issues and Suggested Fixes (Proposed Standard) - 3 of 3=20
    Token: Dan Romascanu

2.1.2 Returning Item
  o draft-ietf-dhc-server-override-04.txt
    DHCP Server Identifier Override Suboption (Proposed Standard) - 1 of
2
=20
    Note: Bringing this document back to agenda, hopefully with the past
issue=20
    solved=20
    Token: Jari Arkko
  o draft-ietf-midcom-mib-09.txt
    Definitions of Managed Objects for Middlebox Communication (Proposed

    Standard) - 2 of 2=20
    Note: Needs positions from the new people.. SEC-DIR Reviewer: Radia
Perlman=20
    (Radia.Perlman@sun.com). WG Shephard Melinda Shore.=20
    Token: Magnus Westerlund


2.2 Individual Submissions
2.2.1 New Item
  o draft-williams-on-channel-binding-02.txt
    On the Use of Channel Bindings to Secure Channels (Proposed
Standard)
- 1=20
    of 2=20
    Token: Sam Hartman
  o draft-mcgrew-auth-enc-02.txt
    An Interface and Algorithms for Authenticated Encryption (Proposed=20
    Standard) - 2 of 2=20
    Token: Tim Polk

2.2.2 Returning Item
NONE

3. Document Actions

3.1 WG Submissions
	Reviews should focus on these questions: "Is this document a
reasonable
	contribution to the area of Internet engineering which it
covers? If
	not, what changes would make it so?"

3.1.1 New Item
NONE
3.1.2 Returning Item
NONE

3.2 Individual Submissions Via AD
	Reviews should focus on these questions: "Is this document a
reasonable
	contribution to the area of Internet engineering which it
covers? If
	not, what changes would make it so?"

3.2.1 New Item
  o draft-martin-ibcs-04.txt
    Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve=20
    Implementations of the BF and BB1 Cryptosystems (Informational) - 1
of
2=20
    Token: Tim Polk
  o draft-mrose-apex-historic-02.txt
    Reclassification of the APEX RFCs to Historic (Informational) - 2 of
2
=20
    Token: Chris Newman

=20

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Fri, 29 Jun 2007 06:14:08 +0000
From: Stefan Winter <stefan.winter@restena.lu>
Organization: Fondation RESTENA
Subject: Internet Draft: RadSec - RADIUS over TCP+TLS
Date: Fri, 29 Jun 2007 08:13:18 +0200
User-Agent: KMail/1.9.6
MIME-Version: 1.0
Content-Disposition: inline
To: radiusext@ops.ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <200706290813.19044.stefan.winter@restena.lu>

Hello!

My name is Stefan Winter of the Luxembourg Research and Education Network.
Together with Stig Venaas (Norwegian REN) and Mike McCauley from Open Syste=
ms=20
Consultants (creators of the Radiator RADIUS server) I have created an=20
internet draft describing two implementations of a transport profile for=20
RADIUS that transports the RADIUS payload over a TCP+TLS link.

The draft was submitted yesterday; it will soon be available here:=20
http://www.ietf.org/internet-drafts/draft-winter-radsec-00.txt

Before that, it can be downloaded from
http://www.eduroam.lu/files/draft-winter-radsec-00.txt

The reason for writing this draft is that two implementations of this=20
transport profile exist (OSC's Radiator and Stig's radsecproxy) and have be=
en=20
proven to interoperate. The Research and Education Networks in Europe opera=
te=20
an international Wireless LAN roaming infrastructure, and we see the need t=
o=20
improve the RADIUS proxy chain both security-wise and reliability-wise.=20
RadSec is a solution to most of our specific problems with RADIUS that show=
ed=20
up over time in the proxy hierarchy (including, but not limited to the prob=
lem=20
of not knowing how to react when downstream proxies are unresponsive, as=20
discussed on this list recently). A description the problems we faced, of=20
both implementations and the roaming infrastructure ("eduroam") is containe=
d=20
in the draft, along with a short explanation why Diameter is not an option=
=20
for us at this time.

Taking a look at this wg's charter, it is crystal clear that the draft is n=
ot=20
going to be a work item since the charter explicitly excludes work on new=20
transport profiles and security mechanisms. So this draft is meant as an=20
independent submission, with the goal of making the document an Information=
al=20
RFC, since it describes existing interoperable software and the information=
=20
therein may be beneficial for the internet community. Still, this wg is=20
probably the largest gathering of RADIUS experts around the globe, and I=20
invite any interested individuals to give feedback on the draft, it will be=
=20
highly appreciated.

Thanks for listening,

Stefan Winter

=2D-=20
Stefan WINTER

Stiftung RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education Na=
tionale et de=20
la Recherche
Ingenieur Forschung & Entwicklung

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
E-Mail: stefan.winter@restena.lu =C2=A0 =C2=A0 Tel.:  =C2=A0 =C2=A0+352 424=
409-1
http://www.restena.lu =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0  =C2=A0 Fax=
: =C2=A0 =C2=A0 =C2=A0+352 422473

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Fri, 29 Jun 2007 03:46:27 +0000
Message-ID: <467DB62F00108E54@n034.sc1.he.tucows.com> (added by postmaster@bouncemessage.net)
Date: Thu, 28 Jun 2007 23:36:09 -0400
To: <radiusext@ops.ietf.org>
From: David Mitton <david@mitton.com>
Subject: Re: New version of RADIUS WLAN document
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Just to start with,

         I think this document should reference RFC 3580 somewhere in 
the abstract and introduction and
give more information on the positioning between the two.

         This new document seems to be about roaming selection and
key assignment and not about the basic issues addressed in 3580.

Nothing in the title gives that hint. You only find out when you get 
to the details of the definition of an attribute string content.

Dave.


On 6/27/2007 08:33 PM, Bernard Aboba wrote:
>The RADIUS WLAN attributes document has been revised, based on 
>feedback from IEEE 802.11.  Once it is posted, it will be available 
>for inspection here:
><http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-04.txt>http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-04.txt
>
>Before then, it is available here:
><http://www.drizzle.com/~aboba/RADEXT/draft-aboba-radext-wlan-04.txt>http://www.drizzle.com/~aboba/RADEXT/draft-aboba-radext-wlan-04.txt
>
>Comments welcome.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Thu, 28 Jun 2007 11:31:03 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: AW: Proposed Resolution to Issue 230:  RFC 4590bis Last Call Comments
Date: Thu, 28 Jun 2007 13:29:58 +0200
Message-Id: <1E4CCB2441C5C0409AD8A929482A09F31BB7B8@S4DE9JSAAIG.ost.t-com.de>
Thread-Topic: Proposed Resolution to Issue 230:  RFC 4590bis Last Call Comments
Thread-Index: Ace5IobaBlfEpIvgSd21lj0lv/qV6QANehfQ
From: "Beck01, Wolfgang" <BeckW@t-systems.com>
To: <bernard_aboba@hotmail.com>, <radiusext@ops.ietf.org>

I agree with the resolution proposed by Bernard.

Bernard, I'll send you a corrected version of the examples.

The values in the examples were created with a Python script, using =
'secret' as
secret. Here is the script (I don't know any more where I stole the =
HMAC_MD5
part):

"""
HTTP digest authentication

usage: from digauth import *
       digest(p5, '12345678', 'secret')
"""

import md5
import array

def h(x):
    m =3D md5.new(x)
    return m.digest().encode('hex')

def kd(secret, data):
    return h(secret + ':' + data)

class Params:
    pass

#
# returns Authorization response and Authentication-Info response
#
def digest(p, username, password):
    if p.algorithm =3D=3D 'MD5' or p.algorithm =3D=3D None:
	a1 =3D username + ':' + p.realm + ':' + password
    elif p.algorithm =3D=3D 'MD5-sess':
	a1 =3D h(username + ':' + p.realm + ':' + password) \
	    + ':' + p.nonce \
	    + ':' + p.cnonce
    else:
	a1 =3D ''
    if p.qop =3D=3D 'auth' or p.qop =3D=3D 'auth-int':
	if p.qop =3D=3D 'auth':
	    a2 =3D p.method +':' + p.uri
	    a2s =3D ':' + p.uri
	elif p.qop =3D=3D 'auth-int':
	    a2 =3D p.method + ':' + p.uri + h(p.body)
	    a2s =3D ':' + p.uri + h(p.body)
	else:
	    a2 =3D ''
	    a2s =3D ''
	   =20
	return ( kd(h(a1), \
	          p.nonce \
	    + ':' + p.nc \
	    + ':' + p.cnonce \
	    + ':' + p.qop \
	    + ':' + h(a2)), \
	    kd(h(a1), \
	          p.nonce \
	    + ':' + p.nc \
	    + ':' + p.cnonce \
	    + ':' + p.qop \
	    + ':' + h(a2s)))
    elif p.qop =3D=3D None:
	a2 =3D p.method +':' + p.uri
	a2s =3D ':' + p.uri
	return ( kd( h(a1), p.nonce + ':' + h(a2) ), \
		kd (h(a1), p.nonce + ':' + h(a2s) ) )

class HMAC_MD5:
    # keyed MD5 message authentication
    def __init__(self, key):
	if len(key) > 64:
	    key =3D md5.new(key).digest()
	ipad =3D array.array("B", [0x36] * 64)
	opad =3D array.array("B", [0x5C] * 64)
	for i in range(len(key)):
	    ipad[i] =3D ipad[i] ^ ord(key[i])
	    opad[i] =3D opad[i] ^ ord(key[i])
	self.ipad =3D md5.md5(ipad.tostring())
	self.opad =3D md5.md5(opad.tostring())
    def digest(self, data):
	ipad =3D self.ipad.copy()
	opad =3D self.opad.copy()
	ipad.update(data)
	opad.update(ipad.digest())
	return opad.digest()

#
# RfC 4590bis, example 1
# user =3D '12345678' password =3D 'secret'
#
# digest(p5, '12345678', 'secret')
#
p5 =3D Params()
p5.algorithm =3D 'MD5'
p5.qop =3D 'auth'
p5.method =3D 'INVITE'
p5.uri =3D 'sip:97226491335@example.com'
p5.realm =3D 'example.com'
p5.nonce =3D '3bada1a0'
p5.cnonce =3D '56593a78'
p5.nc =3D '00000001'

#
# RfC 4590bis, example 2
# user =3D '12345678' password =3D 'secret'
#
# digest(p6, '12345678', 'secret')
#
p6 =3D Params()
p6.algorithm =3D 'MD5'
p6.qop =3D 'auth'
p6.method =3D 'GET'
p6.uri =3D '/index.html'
p6.realm =3D 'example.com'
p6.nonce =3D '3bada1a0'
p6.cnonce =3D '56593a78'
p6.nc =3D '00000001'

-----Urspr=FCngliche Nachricht-----
Von: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20
Gesendet: Donnerstag, 28. Juni 2007 03:20
An: radiusext@ops.ietf.org
Betreff: Proposed Resolution to Issue 230: RFC 4590bis Last Call =
Comments


=20
Issue 230 (RFC 4590bis Last Call Comments) is enclosed below.=20
=20
The length of the Digest-Nonce-Count attribute has to include the Type =
and Length fields, so that it is indeed 10, not 8.=20
=20
Here is what RFC 2617 Section 3.2.2 says about nonce-count:
=20
   nonce-count
     This MUST be specified if a qop directive is sent (see above), and
     MUST NOT be specified if the server did not send a qop directive in
     the WWW-Authenticate header field.  The nc-value is the hexadecimal
     count of the number of requests (including the current request)
     that the client has sent with the nonce value in this request.  For
     example, in the first request sent in response to a given nonce
     value, the client sends "nc=3D00000001".  The purpose of this
     directive is to allow the server to detect request replays by
     maintaining its own copy of this count - if the same nc-value is
     seen twice, then the request is a replay.   See the description
     below of the construction of the request-digest value.

So all the examples (not just the first) in Section 6 do indeed appear =
to be illegal.=20
=20
Also, the examples should supply the password so as to allow for =
verification of the calculations. =20
=20
Handling of internationalization within RADIUS is covered in RFC 4282, =
so that I don't believe that this draft needs to reinvent that wheel.=20
=20
=20

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Thu, 28 Jun 2007 01:20:10 +0000
Message-ID: <BAY117-W640C08665C0E499A7D6ED93090@phx.gbl>
Content-Type: multipart/alternative; boundary="_3fa43b0f-3028-47da-9604-8cf551a27fd6_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <radiusext@ops.ietf.org>
Subject: Proposed Resolution to Issue 230:  RFC 4590bis Last Call Comments
Date: Wed, 27 Jun 2007 18:19:43 -0700
MIME-Version: 1.0

--_3fa43b0f-3028-47da-9604-8cf551a27fd6_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


=20
Issue 230 (RFC 4590bis Last Call Comments) is enclosed below.=20
=20
The length of the Digest-Nonce-Count attribute has to include the Type and =
Length fields, so that it is indeed 10, not 8.=20
=20
Here is what RFC 2617 Section 3.2.2 says about nonce-count:
=20
   nonce-count     This MUST be specified if a qop directive is sent (see a=
bove), and     MUST NOT be specified if the server did not send a qop direc=
tive in     the WWW-Authenticate header field.  The nc-value is the hexadec=
imal     count of the number of requests (including the current request)   =
  that the client has sent with the nonce value in this request.  For     e=
xample, in the first request sent in response to a given nonce     value, t=
he client sends "nc=3D00000001".  The purpose of this     directive is to a=
llow the server to detect request replays by     maintaining its own copy o=
f this count - if the same nc-value is     seen twice, then the request is =
a replay.   See the description     below of the construction of the reques=
t-digest value.
So all the examples (not just the first) in Section 6 do indeed appear to b=
e illegal.=20
=20
Also, the examples should supply the password so as to allow for verificati=
on of the calculations. =20
=20
Handling of internationalization within RADIUS is covered in RFC 4282, so t=
hat I don't believe that this draft needs to reinvent that wheel.=20
=20
=20
Issue 230: RFC 4590bis Last Call CommentsSubmitter name: Frank Ellermann Su=
bmitter email address:  Date first submitted: May 18, 2007Reference: http:/=
/ops.ietf.org/lists/radiusext/2007/msg00287.htmlDocument: RFC 4590bis-01Com=
ment type: TechnicalPriority: SSection: VariousRationale/Explanation of iss=
ue:
=20
Hi, this draft might be also interesting for the 2831bis (SASL) and2617bis =
(HTTP-AUTH) folks.  From a quick read I found that the I-Dpicked the "keep =
backslash as is" approach between client and proxy,trimming \\ and \" only =
at the RADIUS server.The other DIGEST-MD5 parameters are as always confusin=
g, I don't seeanything related to SASLprep in the draft (it's based on 2617=
).  Itmentions 2069 backwards compatibility based on the absence of "QoP",I=
'm not sure if that's correct for "md5-sess" without "QoP".The draft says t=
hat the length of NC is 10, shouldn't that be 8 ?The first example has no C=
NONCE and no NC, my script claims that thisis a fatal error for qop=3Dauth,=
 isn't it ?  RFC 2617 says that it MUSTbe sent for a non-empty qop.The pass=
word for the 4590 examples isn't shown, therefore I'm unableto check them, =
even after adjusting the code to treat qop=3Dauth withoutCNONCE as 2069 fal=
lback.  Should I treat CNONCE as empty and make upan NC 00000001 ?Without S=
ASLprep the draft IMO needs some "I18N considerations" aboutnon-ASCII user =
names and passwords as mandated by BCP 18 (RFC 2277).
Proposed Resolution: Discuss=

--_3fa43b0f-3028-47da-9604-8cf551a27fd6_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
&nbsp;<BR>
Issue 230 (RFC 4590bis Last Call Comments) is enclosed below. <BR>
&nbsp;<BR>
The length of the Digest-Nonce-Count attribute has to include the Type and =
Length fields, so that it is indeed 10, not 8. <BR>
&nbsp;<BR>
Here is what RFC 2617 Section 3.2.2 says about nonce-count:<BR>
&nbsp;<BR>
&nbsp;&nbsp; nonce-count<BR>&nbsp;&nbsp;&nbsp;&nbsp; This MUST be specified=
 if a qop directive is sent (see above), and<BR>&nbsp;&nbsp;&nbsp;&nbsp; MU=
ST NOT be specified if the server did not send a qop directive in<BR>&nbsp;=
&nbsp;&nbsp;&nbsp; the WWW-Authenticate header field.&nbsp; The nc-value is=
 the hexadecimal<BR>&nbsp;&nbsp;&nbsp;&nbsp; count of the number of request=
s (including the current request)<BR>&nbsp;&nbsp;&nbsp;&nbsp; that the clie=
nt has sent with the nonce value in this request.&nbsp; For<BR>&nbsp;&nbsp;=
&nbsp;&nbsp; example, in the first request sent in response to a given nonc=
e<BR>&nbsp;&nbsp;&nbsp;&nbsp; value, the client sends "nc=3D00000001".&nbsp=
; The purpose of this<BR>&nbsp;&nbsp;&nbsp;&nbsp; directive is to allow the=
 server to detect request replays by<BR>&nbsp;&nbsp;&nbsp;&nbsp; maintainin=
g its own copy of this count - if the same nc-value is<BR>&nbsp;&nbsp;&nbsp=
;&nbsp; seen twice, then the request is a replay.&nbsp;&nbsp; See the descr=
iption<BR>&nbsp;&nbsp;&nbsp;&nbsp; below of the construction of the request=
-digest value.<BR><BR>
So&nbsp;all the&nbsp;examples (not just the first)&nbsp;in Section 6 do ind=
eed appear to be&nbsp;illegal. <BR>
&nbsp;<BR>
Also, the examples&nbsp;should supply&nbsp;the password so as to allow&nbsp=
;for verification of the calculations. &nbsp;<BR>
&nbsp;<BR>
Handling of internationalization within RADIUS is covered in RFC 4282, so t=
hat I don't believe that this draft needs to reinvent that wheel. <BR>
&nbsp;<BR>
&nbsp;<BR>
<B><A name=3D"Issue 230"></A>Issue 230: RFC 4590bis Last Call Comments<BR><=
/B>Submitter name: Frank Ellermann <BR>Submitter email address:&nbsp; <BR>D=
ate first submitted: May 18, 2007<BR>Reference: <A href=3D"http://ops.ietf.=
org/lists/radiusext/2007/msg00287.html"><U><FONT color=3D#0066cc>http://ops=
.ietf.org/lists/radiusext/2007/msg00287.html</FONT></U></A><BR>Document: RF=
C 4590bis-01<BR>Comment type: Technical<BR>Priority: S<BR>Section: Various<=
BR>Rationale/Explanation of issue:<BR>
&nbsp;<BR>
Hi, this draft might be also interesting for the 2831bis (SASL) and<BR>2617=
bis (HTTP-AUTH) folks.&nbsp; From a quick read I found that the I-D<BR>pick=
ed the "keep backslash as is" approach between client and proxy,<BR>trimmin=
g \\ and \" only at the RADIUS server.<BR><BR>The other DIGEST-MD5 paramete=
rs are as always confusing, I don't see<BR>anything related to SASLprep in =
the draft (it's based on 2617).&nbsp; It<BR>mentions 2069 backwards compati=
bility based on the absence of "QoP",<BR>I'm not sure if that's correct for=
 "md5-sess" without "QoP".<BR><BR>The draft says that the length of NC is 1=
0, shouldn't that be 8 ?<BR><BR>The first example has no CNONCE and no NC, =
my script claims that this<BR>is a fatal error for qop=3Dauth, isn't it ?&n=
bsp; RFC 2617 says that it MUST<BR>be sent for a non-empty qop.<BR><BR>The =
password for the 4590 examples isn't shown, therefore I'm unable<BR>to chec=
k them, even after adjusting the code to treat qop=3Dauth without<BR>CNONCE=
 as 2069 fallback.&nbsp; Should I treat CNONCE as empty and make up<BR>an N=
C 00000001 ?<BR><BR>Without SASLprep the draft IMO needs some "I18N conside=
rations" about<BR>non-ASCII user names and passwords as mandated by BCP 18 =
(RFC 2277).<BR>
<TT><I><STRONG>Proposed Resolution: </STRONG></I><STRONG><I>Discuss</I></ST=
RONG></TT><BR></body>
</html>=

--_3fa43b0f-3028-47da-9604-8cf551a27fd6_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Thu, 28 Jun 2007 00:35:51 +0000
Message-ID: <BAY117-W11D1B46550A9C2F590832393090@phx.gbl>
Content-Type: multipart/alternative; boundary="_de188002-88f0-4e1c-9c9c-5ba703f34a7f_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <radiusext@ops.ietf.org>
Subject: Conclusion of RADEXT WG last call on RFC 3576bis
Date: Wed, 27 Jun 2007 17:35:33 -0700
MIME-Version: 1.0

--_de188002-88f0-4e1c-9c9c-5ba703f34a7f_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


The RADEXT WG last call on RFC 3576bis-08 has concluded.=20
=20
No comments were received, and there are no open issues with respect to thi=
s document.=20
=20
If there are remaining changes to be made prior to requesting IESG publicat=
ion of RFC 3576bis as an Informational RFC, please speak up NOW.  =

--_de188002-88f0-4e1c-9c9c-5ba703f34a7f_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
The RADEXT WG last call on RFC 3576bis-08 has concluded. <BR>
&nbsp;<BR>
No comments were received, and there are no open issues with respect to thi=
s document. <BR>
&nbsp;<BR>
If there are remaining changes to be made prior to requesting IESG publicat=
ion of RFC 3576bis as an Informational RFC, please speak up NOW.&nbsp; <BR>=
</body>
</html>=

--_de188002-88f0-4e1c-9c9c-5ba703f34a7f_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Thu, 28 Jun 2007 00:34:55 +0000
Message-ID: <BAY117-W717F440291BEB1E41CC9D93090@phx.gbl>
Content-Type: multipart/alternative; boundary="_fca386b0-13fe-45f5-bc04-cbb979953eab_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <radiusext@ops.ietf.org>
Subject: New version of RADIUS WLAN document
Date: Wed, 27 Jun 2007 17:33:01 -0700
MIME-Version: 1.0

--_fca386b0-13fe-45f5-bc04-cbb979953eab_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


The RADIUS WLAN attributes document has been revised, based on feedback fro=
m IEEE 802.11.  Once it is posted, it will be available for inspection here=
:
http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-04.txt
=20
Before then, it is available here:
http://www.drizzle.com/~aboba/RADEXT/draft-aboba-radext-wlan-04.txt
=20
Comments welcome. =

--_fca386b0-13fe-45f5-bc04-cbb979953eab_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
The RADIUS WLAN attributes document has been revised, based on feedback fro=
m IEEE 802.11.&nbsp; Once it is posted, it will be available for inspection=
 here:<BR>
<A href=3D"http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-04.t=
xt">http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-04.txt</A><=
BR>
&nbsp;<BR>
Before then, it is available here:<BR>
<A href=3D"http://www.drizzle.com/~aboba/RADEXT/draft-aboba-radext-wlan-04.=
txt">http://www.drizzle.com/~aboba/RADEXT/draft-aboba-radext-wlan-04.txt</A=
><BR>
&nbsp;<BR>
Comments welcome. <BR></body>
</html>=

--_fca386b0-13fe-45f5-bc04-cbb979953eab_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Wed, 27 Jun 2007 08:04:39 +0000
Message-ID: <468219E1.7010004@nitros9.org>
Date: Wed, 27 Jun 2007 10:03:45 +0200
From: Alan DeKok <aland@nitros9.org>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To:  radiusext@ops.ietf.org
Subject: Re: I-D ACTION:draft-ietf-radext-fixes-04.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Internet-Drafts@ietf.org wrote:
> 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		: Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes
> 	Author(s)	: D. Nelson, A. DeKok
> 	Filename	: draft-ietf-radext-fixes-04.txt

  This version was submitted as a result of changes made during expert
review.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Tue, 26 Jun 2007 22:51:24 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: radiusext@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-radext-fixes-04.txt 
Message-Id: <E1I3JrG-0001Q1-3P@stiedprstage1.ietf.org>
Date: Tue, 26 Jun 2007 18:50:02 -0400

--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		: Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes
	Author(s)	: D. Nelson, A. DeKok
	Filename	: draft-ietf-radext-fixes-04.txt
	Pages		: 23
	Date		: 2007-6-26
	
This document describes common issues seen in RADIUS implementations
   and suggests some fixes.  Where applicable, ambiguities and errors in
   previous RADIUS specifications are clarified.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-radext-fixes-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-fixes-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2007-6-26165123.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-fixes-04.txt

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

Content-Type: text/plain
Content-ID:	<2007-6-26165123.I-D@ietf.org>

--OtherAccess--

--NextPart--


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Tue, 19 Jun 2007 20:12:16 +0000
From: "David B. Nelson" <dnelson@elbrysnetworks.com>
To: <radiusext@ops.ietf.org>
Subject: RE: NAS-Port-Type and sub-types?
Date: Tue, 19 Jun 2007 16:10:09 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <006001c7b2ad$d60cadf0$5d1216ac@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-index: Aceyo61I92+UDjKKTOqE8HvhGhM0FQACa8VQ

> We have talked about how the backend authentication server 
> may need to handle authorization differently depending on details
> of the EAP lower layer.

So when you suggest a new attribute to encode this information, maybe a
better name would be EAP-Lower-Layer?  EAP-Medium sound like it might have
something to do with the type of link layer, which is not really the case.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Tue, 19 Jun 2007 18:58:00 +0000
Message-ID: <BAY117-W9640E85F6F871419D74B493120@phx.gbl>
Content-Type: multipart/alternative; boundary="_33be9c01-00d4-42fa-ad2e-7f76505b3e7c_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: "David B. Nelson" <dnelson@elbrysnetworks.com>, <radiusext@ops.ietf.org>
Subject: RE: NAS-Port-Type and sub-types?
Date: Tue, 19 Jun 2007 11:57:25 -0700
MIME-Version: 1.0

--_33be9c01-00d4-42fa-ad2e-7f76505b3e7c_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> Is there really an issue related to EAP?  Or is it more an issue of NAS> =
functionality / capability? While there may be a one-to-one mapping of EAP>=
 methods to access functions, it is not clear to me that such mappings woul=
d> always pertain.
>
> Are you attempting to signal device functionality (end node vs. mesh poin=
t)> or signal the use of a particular EAP method?
=20
We have talked about how the backend authentication server may need to hand=
le
authorization differently depending on details of the EAP lower layer.  11s=
 is one
example;  IEEE 802.1X/11i pre-authentication is another one.=20
=20
Both of these examples involve features of the EAP lower layer.  However,
they don't relate to the link per se (e.g. negotiated ciphersuite)
or to generic NAS capability description (whether the NAS supports 11a/b/g/=
n).=20
They also don't relate to the use of a particular EAP method, which is can
already be included in Access-Request packets (RFC 2548).=20
=20
 =

--_33be9c01-00d4-42fa-ad2e-7f76505b3e7c_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
&gt; Is there really an issue related to EAP?&nbsp; Or is it more an issue =
of NAS<BR>&gt; functionality / capability? While there may be a one-to-one =
mapping of EAP<BR>&gt; methods to access functions, it is not clear to me t=
hat such mappings would<BR>&gt; always pertain.<BR>
&gt;<BR>
&gt; Are you attempting to signal device functionality (end node vs. mesh p=
oint)<BR>&gt; or signal the use of a particular EAP method?<BR>
&nbsp;<BR>
We have talked about how the backend authentication server may need to hand=
le<BR>
authorization differently depending on details of the EAP lower layer.&nbsp=
; 11s is one<BR>
example;&nbsp; IEEE 802.1X/11i pre-authentication is another one. <BR>
&nbsp;<BR>
Both of these examples involve features of the EAP lower layer.&nbsp; Howev=
er,<BR>
they don't relate to the link per se (e.g. negotiated ciphersuite)<BR>
or to generic NAS capability description (whether the NAS supports 11a/b/g/=
n). <BR>
They also don't relate to the use of a particular EAP method, which is can<=
BR>
already be included in Access-Request packets (RFC 2548). <BR>
&nbsp;<BR>
&nbsp;<BR></body>
</html>=

--_33be9c01-00d4-42fa-ad2e-7f76505b3e7c_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Tue, 19 Jun 2007 17:50:11 +0000
From: "David B. Nelson" <dnelson@elbrysnetworks.com>
To: <radiusext@ops.ietf.org>
Subject: RE: NAS-Port-Type and sub-types?
Date: Tue, 19 Jun 2007 13:48:19 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <005001c7b29a$05ad0000$5d1216ac@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-index: AceymOWXFUfBVOSlTVaFaaQU9LHXVwAAEdIQ

Bernard Aboba writes...

> > Are you thinking that there should be a distinct
> > NAS-Port-Type for Wireless Mesh Point?
>
> I think not, because the port type for 11s would still be IEEE 802.11.

Well, that's true.  We do need to be careful about over-loading
NAS-Port-Type with information other than the media technology.

> One possibility is to define an "EAP-Medium" Attribute that =
would=A0provide
> information on=A0the EAP lower layer, such as:

Is there really an issue related to EAP?  Or is it more an issue of NAS
functionality / capability?  While there may be a one-to-one mapping of =
EAP
methods to access functions, it is not clear to me that such mappings =
would
always pertain.

Are you attempting to signal device functionality (end node vs. mesh =
point)
or signal the use of a particular EAP method?



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Tue, 19 Jun 2007 17:41:17 +0000
Message-ID: <BAY117-W1650555D931DDFF4B732D093120@phx.gbl>
Content-Type: multipart/alternative; boundary="_f3be5e43-88b1-4151-a53a-b68f9b3b26bf_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: "David B. Nelson" <dnelson@elbrysnetworks.com>, <radiusext@ops.ietf.org>
Subject: RE: NAS-Port-Type and sub-types?
Date: Tue, 19 Jun 2007 10:40:14 -0700
MIME-Version: 1.0

--_f3be5e43-88b1-4151-a53a-b68f9b3b26bf_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> That's a good example. Are you thinking that there should be a distinct> =
NAS-Port-Type for Wireless Mesh Point?
I think not, because the port type for 11s would still be IEEE 802.11. =20
=20
One possibility is to define an "EAP-Medium" Attribute that would provide i=
nformation on the EAP lower layer, such as:
=20
      1 -  Wired IEEE 802.1X Version 1 (2001)      2 -  Wired IEEE 802.1X V=
ersion 2 (2004)      3 -  WPA      4 -  WPA2 (non pre-authentication)      =
5 -  WPA2: IEEE 802.1X pre-authentication      6 -  IEEE 802.11r      7 -  =
IEEE 802.11s      8 -  IEEE 802.11af      9 -  IEEE 802.16e      10 - IKEv2=
      11 - PPP      12 - PANA=

--_f3be5e43-88b1-4151-a53a-b68f9b3b26bf_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
<BR>&gt; That's a good example. Are you thinking that there should be a dis=
tinct<BR>&gt; NAS-Port-Type for Wireless Mesh Point?<BR><BR>
I think not, because the port type for 11s would still be IEEE 802.11.&nbsp=
; <BR>
&nbsp;<BR>
One possibility is to define an "EAP-Medium" Attribute that would&nbsp;prov=
ide information on&nbsp;the EAP lower layer, such as:<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1 -&nbsp; Wired IEEE 802.1X Version 1 (2001)=
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2 -&nbsp; Wired IEEE 802.1X Version 2 (2=
004)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 -&nbsp; WPA<BR>&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; 4 -&nbsp; WPA2 (non pre-authentication)<BR>&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; 5 -&nbsp; WPA2: IEEE 802.1X pre-authentication<BR>&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; 6 -&nbsp; IEEE 802.11r<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 7=
 -&nbsp; IEEE 802.11s<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 8 -&nbsp; IEEE 802.=
11af<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 9 -&nbsp; IEEE 802.16e<BR>&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; 10 - IKEv2<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 11 - PPP<=
BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12 - PANA<BR><BR></body>
</html>=

--_f3be5e43-88b1-4151-a53a-b68f9b3b26bf_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Tue, 19 Jun 2007 14:25:18 +0000
From: "David B. Nelson" <dnelson@elbrysnetworks.com>
To: <radiusext@ops.ietf.org>
Subject: RE: NAS-Port-Type and sub-types?
Date: Tue, 19 Jun 2007 10:22:39 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <004901c7b27d$4abb8d50$5d1216ac@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-index: Acex/7JUKu81qZhcRha1wkqxZVijBwAfUd5A

Bernard Aboba writes...
=20
> I think it does matter, in the case of 11s vs. 11i, for
> example.=A0 There is=A0difference between authorizing a user
> to join a mesh network as a Mesh Point, and authorizing a
> user to join the network as=A0a Station.

That's a good example.  Are you thinking that there should be a distinct
NAS-Port-Type for Wireless Mesh Point?
=20


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 18 Jun 2007 23:24:13 +0000
Message-ID: <BAY117-W15068E647A6B584E19489293130@phx.gbl>
Content-Type: multipart/alternative; boundary="_a807c73d-ca80-41af-b4b6-f6f0848df36a_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: "David B. Nelson" <dnelson@elbrysnetworks.com>, <radiusext@ops.ietf.org>
Subject: RE: NAS-Port-Type and sub-types?
Date: Mon, 18 Jun 2007 16:23:36 -0700
MIME-Version: 1.0

--_a807c73d-ca80-41af-b4b6-f6f0848df36a_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> This goes back to the "network selection" problem, and the discussion of>=
 using NAS-Port-Type for that purpose. If all RADIUS ever sees from these> =
technologies is EAP traffic, does it matter? If we are to add new> authenti=
cation methods to RADIUS, as we did with Digest Auth, then it may> matter.
I think it does matter, in the case of 11s vs. 11i, for example.  There is =
 difference between
authorizing a user to join a mesh network as a Mesh Point, and authorizing =
a user to join
the network as a Station.  The set of users authorized to act as a Mesh Poi=
nt may be quite=20
small compared to those authorized to act as a station.  So if the user wer=
e associating
as a Mesh Point, their authorization might be rejected, but if they were as=
sociating for
11i or 11r, they might be authorized. =

--_a807c73d-ca80-41af-b4b6-f6f0848df36a_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
<BR>&gt; This goes back to the "network selection" problem, and the discuss=
ion of<BR>&gt; using NAS-Port-Type for that purpose. If all RADIUS ever see=
s from these<BR>&gt; technologies is EAP traffic, does it matter? If we are=
 to add new<BR>&gt; authentication methods to RADIUS, as we did with Digest=
 Auth, then it may<BR>&gt; matter.<BR><BR>
I think it does matter, in the case of 11s vs. 11i, for example.&nbsp; Ther=
e is&nbsp; difference between<BR>
authorizing a user to join a mesh network as a Mesh Point, and authorizing =
a user to join<BR>
the network as&nbsp;a Station.&nbsp; The set of users authorized to act as =
a Mesh Point may be quite <BR>
small compared to those authorized to act as a station.&nbsp; So if the use=
r were associating<BR>
as a Mesh Point, their authorization might be rejected, but if they were as=
sociating for<BR>
11i or 11r, they might be authorized. <BR></body>
</html>=

--_a807c73d-ca80-41af-b4b6-f6f0848df36a_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 18 Jun 2007 18:47:57 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Submission cut-off dates before Chicago
Date: Mon, 18 Jun 2007 20:46:26 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A04121F94@307622ANEX5.global.avaya.com>
Thread-Topic: Submission cut-off dates before Chicago
Thread-Index: Acex2PmEtxbDklB8TrC3YaXjv/x7Yw==
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: <ops-area@ietf.org>, <opsawg@ietf.org>, "Netconf (E-mail)" <netconf@ops.ietf.org>, <ngo@ietf.org>, <meta-model@ietf.org>, <mib2rdml@ietf.org>, <ipfix@ietf.org>, <radiusext@ops.ietf.org>

Working Group and BOF Chairs and Contributors,

Please note the submission dates for Internet-Drafts before Chicago.=20

July 2, Monday - Internet Draft Cut-off for initial document (-00)
submission by 09:00 ET (13:00 UTC/GMT)
July 9, Monday - Internet Draft final submission cut-off by 09:00 ET
(13:00 UTC/GMT)

Dan




=20

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 18 Jun 2007 15:19:03 +0000
From: "David B. Nelson" <dnelson@elbrysnetworks.com>
To: <radiusext@ops.ietf.org>
Subject: RE: NAS-Port-Type and sub-types? 
Date: Mon, 18 Jun 2007 11:16:37 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <001801c7b1bb$a9fb7c20$5d1216ac@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-index: AcexYokxH0Y2Oe+WTqCSTho0gl9F8AAVu+Mg

Bernard Aboba writes...
=A0
> a. What is a NAS-Port-Type anyway?=A0 My understanding is=20
> that this attribute is mostly used to enable the RADIUS=20
> server to execute link-specific policy (e.g. If=20
> NAS-Port-Type=3D"IEEE 802.11" Then Profile =3D 802.11-Profile).
> So my answer is that it represents link type information=20
> that a RADIUS server administrator will find useful.

It may also be useful in accounting messages, if the provider is billing =
at
different rates for different "speeds and feeds".=20
=A0
> b. What is the appropriate granularity for NAS-Port-Type?
> In some cases, values are more granular than a link type=20
> (e.g. 3 values for ISDN), in others a single value applies=20
> to multiple link technologies (e.g. Wireless -- Other).

There are two answers.  One answer is based on the granularity needed to
apply the correct policy.  The second answer is based on the granularity
needed for accurate billing.  Of course, these answers are likely to =
vary
from operator to operator.

> c. How should we=A0handle=A0new IEEE 802 technologies going forward?
>=A0IEEE 802 is not only creating new link technologies (e.g. IEEE=20
> 802.16, 802.20, etc.) they are also developing new authentication
> schemes within those technologies (e.g. IEEE 802.11r, IEEE 802.1af,
> etc.).=A0=A0 So how does a NAS indicate that=A0an Access-Request is =
for=20
> IEEE 802.11s or IEEE 802.11r rather than just IEEE 802.11, or IEEE
> 802.1af, rather than IEEE 802.3/IEEE 802.1X-2004?=A0 Allocating a=20
> NAS-Port-Type value does not seem like a good fit for that kind of=20
> differentiation.=20
=A0
This goes back to the "network selection" problem, and the discussion of
using NAS-Port-Type for that purpose.  If all RADIUS ever sees from =
these
technologies is EAP traffic, does it matter?  If we are to add new
authentication methods to RADIUS, as we did with Digest Auth, then it =
may
matter.

Glen Kramer writes...

> It's not clear what the NAS port number would be. The protocol=20
> defines a port value as a 32-bit field. This isn't big enough=20
> for a MAC address. But since the logical links are virtual and=20
> dynamically assigned, it doesn't make lots of sense to me to=20
> report a link as either "link index 12" or "LLID 13".

NAS-Port makes sense for RAS Servers and Switches; things with "ports".  =
It
doesn=92t work for shared media (e.g. Ethernet or EPON); things with =
"taps".

Frank Effenberger writes...
=20
> Bottom-line - it appears that they have been handing out these
> values with very little care for doing a clean job. I'm not
> sure what use this information is even put to...=20
>=20
> You might mention that observation, and ask for some more=20
> clarification.

It might be a service to the Internet community to provide some guidance
these assignments.  I say guidance, because I don't think there can be
hard-and-fast rules.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 18 Jun 2007 04:33:22 +0000
Message-ID: <BAY117-W15009CC5632643EE8679E793130@phx.gbl>
Content-Type: multipart/alternative; boundary="_e5948c01-2c84-4686-b964-11df20fad8d6_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <radiusext@ops.ietf.org>
Subject: NAS-Port-Type and sub-types? 
Date: Sun, 17 Jun 2007 21:32:22 -0700
MIME-Version: 1.0

--_e5948c01-2c84-4686-b964-11df20fad8d6_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


=20
As a result of the IANA allocation request for a NAS-Port-Type for XPON (wh=
ich was approved, based on the RADEXT mailing list discussion), we got some=
 feedback from IEEE 802, enclosed below.=20
=20
Some questions raised by the feedback include:
=20
a. What is a NAS-Port-Type anyway?  My understanding is that this attribute=
 is mostly used to enable the RADIUS server to execute link-specific policy=
 (e.g. If NAS-Port-Type=3D"IEEE 802.11" Then Profile =3D 802.11-Profile).  =
So my answer is that it represents link type information that a RADIUS serv=
er administrator will find useful.=20
=20
b. What is the appropriate granularity for NAS-Port-Type?  In some cases, v=
alues are more granular than a link type (e.g. 3 values for ISDN), in other=
s a single value applies to multiple link technologies (e.g. Wireless -- Ot=
her).
=20
c. How should we handle new IEEE 802 technologies going forward?  IEEE 802 =
is not only creating new link technologies (e.g. IEEE 802.16, 802.20, etc.)=
 they are also developing new authentication schemes within those technolog=
ies (e.g. IEEE 802.11r, IEEE 802.1af, etc.).   So how does a NAS indicate t=
hat an Access-Request is for IEEE 802.11s or IEEE 802.11r rather than just =
IEEE 802.11, or IEEE 802.1af, rather than IEEE 802.3/IEEE 802.1X-2004?  All=
ocating a NAS-Port-Type value does not seem like a good fit for that kind o=
f differentiation.=20
=20
> -----Original Message-----> From: Glen Kramer [mailto:glen.kramer@teknovu=
s.com] > Sent: Wednesday, June 13, 2007 5:04 PM> To: Pat Thaler> Cc: Congdo=
n, Paul T (ProCurve); Grow, Bob; David Law; Steve Carlson;> Wael Diab> Subj=
ect: RE: [802.1 - 2683] FW: [IANA #85318] request a new> NAS-Port-Type for =
XPON> > Pat,> > Is this a formal liaison request? .3av focuses on PHY and I=
 am not sure> we have the right expertise in our group to answer this. I th=
ink MacSec> may be a better place to get a meaningful response.> > Unoffici=
ally, I asked an engineer in my company for his opinion. Here it> is:> > **=
*> This field isn't really a functional part of the protocol. It's just> ma=
nagement information. In a RADIUS access request, there is a "port> type" f=
ield that says "I'm a DSL port" or "I'm a cable port" or "I'm a> PON port".=
 This has nothing to do with the actual authentication, and> I'm not even s=
ure why a RADIUS server would care in the first place.> But given that ther=
e's a list of 34 possible port types, it makes sense> to add one (or more) =
for PON. > > It may be that people will want to distinguish various types o=
f PON.> There's a bunch of ADSL port types (DMT, CAP, etc) in addition to a=
> generic xDSL port type. But we can start with xPON and see if people> rea=
lly want to know that it's specifically EPON or GEPON or whatever.> > It's =
not clear what the NAS port number would be. The protocol defines> a port v=
alue as a 32-bit field. This isn't big enough for a MAC> address. But since=
 the logical links are virtual and dynamically> assigned, it doesn't make l=
ots of sense to me to report a link as either> "link index 12" or "LLID 13"=
. Those values will just be different after> the next reset; so, there's no=
thing useful you can provision or check on> the server side; so, it doesn't=
 really matter what the value is, so> there's no point in having a value in=
 the first place. (Note that there> is a NAS-Port-Type of "virtual", which =
is intended for virtual ports> multiplexed over some transport medium. Perh=
aps it's enough to realize> that port type "xPON" means that the port numbe=
r won't have lasting> value.)> ***> > Let me know, if anything is required =
from .3av in this regard.> > Glen
=20
> From: EffenbergerFrank 73695 [mailto:feffenberger@huawei.com]> Sent: Wedn=
esday, June 13, 2007 11:23 AM> To: Linda Dunbar> Subject: Re: FW: [802.1 - =
2683] FW: [IANA #85318] request a new> NAS-Port-Type for XPON> > If I look =
up the currently defined list of values for NAS-port-type, I> find:> > Valu=
es for RADIUS Attribute 61, NAS-Port-Type [RFC2865]:> > 0 Async> 1 Sync> 2 =
ISDN Sync> 3 ISDN Async V.120> 4 ISDN Async V.110> 5 Virtual> 6 PIAFS> 7 HD=
LC Clear Channel> 8 X.25> 9 X.75> 10 G.3 Fax> 11 SDSL - Symmetric DSL> 12 A=
DSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase> Modulation> 13 ADSL-=
DMT - Asymmetric DSL, Discrete Multi-Tone> 14 IDSL - ISDN Digital Subscribe=
r Line> 15 Ethernet> 16 xDSL - Digital Subscriber Line of unknown type> 17 =
Cable> 18 Wireless - Other> 19 Wireless - IEEE 802.11> 20 Token-Ring [RFC35=
80]> 21 FDDI [RFC3580]> 22 Wireless - CDMA2000 [McCann]> 23 Wireless - UMTS=
 [McCann]> 24 Wireless - 1X-EV [McCann]> 25 IAPP [IEEE 802.11f][Kerry]> 26 =
FTTP - Fiber to the Premises [Nyce]> 27 Wireless - IEEE 802.16 [IEEE 802.16=
]> 28 Wireless - IEEE 802.20 [IEEE 802.20]> 29 Wireless - IEEE 802.22 [IEEE=
 802.22] > 30 PPPoA - PPP over ATM [RFC4603]> 31 PPPoEoA - PPP over Etherne=
t over ATM [RFC4603]> 32 PPPoEoE - PPP over Ethernet over Ethernet [RFC4603=
]> 33 PPPoEoVLAN - PPP over Ethernet over VLAN [RFC4603]> 34 PPPoEoQinQ - P=
PP over Ethernet over IEEE 802.1QinQ [RFC4603]> > Bottom-line - it appears =
that they have been handing out these values> with very little care for doi=
ng a clean job. I'm not sure what use this> information is even put to... >=
 > You might mention that observation, and ask for some more clarification.=
> > > Sincerely,> Frank E.=

--_e5948c01-2c84-4686-b964-11df20fad8d6_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
&nbsp;<BR>
As a result of the IANA allocation request for a NAS-Port-Type for XPON (wh=
ich was approved, based on the RADEXT mailing list discussion), we got some=
 feedback from IEEE 802, enclosed below. <BR>
&nbsp;<BR>
Some questions raised by the feedback include:<BR>
&nbsp;<BR>
a. What is a NAS-Port-Type anyway?&nbsp; My understanding is that this attr=
ibute is mostly used to enable the RADIUS server to execute link-specific p=
olicy (e.g. If NAS-Port-Type=3D"IEEE 802.11" Then Profile =3D 802.11-Profil=
e).&nbsp; So my answer is that it represents link type information that a R=
ADIUS server administrator will find useful. <BR>
&nbsp;<BR>
b. What is the appropriate granularity for NAS-Port-Type?&nbsp; In some cas=
es, values are more granular than a link type (e.g. 3 values for ISDN), in =
others a single value applies to multiple link technologies (e.g. Wireless =
-- Other).<BR>
&nbsp;<BR>
c. How should we&nbsp;handle&nbsp;new IEEE 802 technologies going forward?&=
nbsp; IEEE 802 is not only creating new link technologies (e.g. IEEE 802.16=
, 802.20, etc.) they are also developing new authentication schemes within =
those technologies (e.g. IEEE 802.11r, IEEE 802.1af, etc.).&nbsp;&nbsp; So =
how does a NAS indicate that&nbsp;an Access-Request is for IEEE 802.11s or =
IEEE 802.11r rather than just IEEE 802.11, or IEEE 802.1af, rather than IEE=
E 802.3/IEEE 802.1X-2004?&nbsp; Allocating a NAS-Port-Type value does not s=
eem like a good fit for that kind of differentiation. <BR>
&nbsp;<BR>
&gt; -----Original Message-----<BR>&gt; From: Glen Kramer [mailto:glen.kram=
er@teknovus.com] <BR>&gt; Sent: Wednesday, June 13, 2007 5:04 PM<BR>&gt; To=
: Pat Thaler<BR>&gt; Cc: Congdon, Paul T (ProCurve); Grow, Bob; David Law; =
Steve Carlson;<BR>&gt; Wael Diab<BR>&gt; Subject: RE: [802.1 - 2683] FW: [I=
ANA #85318] request a new<BR>&gt; NAS-Port-Type for XPON<BR>&gt; <BR>&gt; P=
at,<BR>&gt; <BR>&gt; Is this a formal liaison request? .3av focuses on PHY =
and I am not sure<BR>&gt; we have the right expertise in our group to answe=
r this. I think MacSec<BR>&gt; may be a better place to get a meaningful re=
sponse.<BR>&gt; <BR>&gt; Unofficially, I asked an engineer in my company fo=
r his opinion. Here it<BR>&gt; is:<BR>&gt; <BR>&gt; ***<BR>&gt; This field =
isn't really a functional part of the protocol. It's just<BR>&gt; managemen=
t information. In a RADIUS access request, there is a "port<BR>&gt; type" f=
ield that says "I'm a DSL port" or "I'm a cable port" or "I'm a<BR>&gt; PON=
 port". This has nothing to do with the actual authentication, and<BR>&gt; =
I'm not even sure why a RADIUS server would care in the first place.<BR>&gt=
; But given that there's a list of 34 possible port types, it makes sense<B=
R>&gt; to add one (or more) for PON. <BR>&gt; <BR>&gt; It may be that peopl=
e will want to distinguish various types of PON.<BR>&gt; There's a bunch of=
 ADSL port types (DMT, CAP, etc) in addition to a<BR>&gt; generic xDSL port=
 type. But we can start with xPON and see if people<BR>&gt; really want to =
know that it's specifically EPON or GEPON or whatever.<BR>&gt; <BR>&gt; It'=
s not clear what the NAS port number would be. The protocol defines<BR>&gt;=
 a port value as a 32-bit field. This isn't big enough for a MAC<BR>&gt; ad=
dress. But since the logical links are virtual and dynamically<BR>&gt; assi=
gned, it doesn't make lots of sense to me to report a link as either<BR>&gt=
; "link index 12" or "LLID 13". Those values will just be different after<B=
R>&gt; the next reset; so, there's nothing useful you can provision or chec=
k on<BR>&gt; the server side; so, it doesn't really matter what the value i=
s, so<BR>&gt; there's no point in having a value in the first place. (Note =
that there<BR>&gt; is a NAS-Port-Type of "virtual", which is intended for v=
irtual ports<BR>&gt; multiplexed over some transport medium. Perhaps it's e=
nough to realize<BR>&gt; that port type "xPON" means that the port number w=
on't have lasting<BR>&gt; value.)<BR>&gt; ***<BR>&gt; <BR>&gt; Let me know,=
 if anything is required from .3av in this regard.<BR>&gt; <BR>&gt; Glen<BR=
>
&nbsp;<BR>
&gt; From: EffenbergerFrank 73695 [mailto:feffenberger@huawei.com]<BR>&gt; =
Sent: Wednesday, June 13, 2007 11:23 AM<BR>&gt; To: Linda Dunbar<BR>&gt; Su=
bject: Re: FW: [802.1 - 2683] FW: [IANA #85318] request a new<BR>&gt; NAS-P=
ort-Type for XPON<BR>&gt; <BR>&gt; If I look up the currently defined list =
of values for NAS-port-type, I<BR>&gt; find:<BR>&gt; <BR>&gt; Values for RA=
DIUS Attribute 61, NAS-Port-Type [RFC2865]:<BR>&gt; <BR>&gt; 0 Async<BR>&gt=
; 1 Sync<BR>&gt; 2 ISDN Sync<BR>&gt; 3 ISDN Async V.120<BR>&gt; 4 ISDN Asyn=
c V.110<BR>&gt; 5 Virtual<BR>&gt; 6 PIAFS<BR>&gt; 7 HDLC Clear Channel<BR>&=
gt; 8 X.25<BR>&gt; 9 X.75<BR>&gt; 10 G.3 Fax<BR>&gt; 11 SDSL - Symmetric DS=
L<BR>&gt; 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase<BR>&gt;=
 Modulation<BR>&gt; 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone<BR>&g=
t; 14 IDSL - ISDN Digital Subscriber Line<BR>&gt; 15 Ethernet<BR>&gt; 16 xD=
SL - Digital Subscriber Line of unknown type<BR>&gt; 17 Cable<BR>&gt; 18 Wi=
reless - Other<BR>&gt; 19 Wireless - IEEE 802.11<BR>&gt; 20 Token-Ring [RFC=
3580]<BR>&gt; 21 FDDI [RFC3580]<BR>&gt; 22 Wireless - CDMA2000 [McCann]<BR>=
&gt; 23 Wireless - UMTS [McCann]<BR>&gt; 24 Wireless - 1X-EV [McCann]<BR>&g=
t; 25 IAPP [IEEE 802.11f][Kerry]<BR>&gt; 26 FTTP - Fiber to the Premises [N=
yce]<BR>&gt; 27 Wireless - IEEE 802.16 [IEEE 802.16]<BR>&gt; 28 Wireless - =
IEEE 802.20 [IEEE 802.20]<BR>&gt; 29 Wireless - IEEE 802.22 [IEEE 802.22]&n=
bsp;<BR>&gt; 30 PPPoA - PPP over ATM [RFC4603]<BR>&gt; 31 PPPoEoA - PPP ove=
r Ethernet over ATM [RFC4603]<BR>&gt; 32 PPPoEoE - PPP over Ethernet over E=
thernet [RFC4603]<BR>&gt; 33 PPPoEoVLAN - PPP over Ethernet over VLAN [RFC4=
603]<BR>&gt; 34 PPPoEoQinQ - PPP over Ethernet over IEEE 802.1QinQ [RFC4603=
]<BR>&gt; <BR>&gt; Bottom-line - it appears that they have been handing out=
 these values<BR>&gt; with very little care for doing a clean job. I'm not =
sure what use this<BR>&gt; information is even put to... <BR>&gt; <BR>&gt; =
You might mention that observation, and ask for some more clarification.<BR=
>&gt; <BR>&gt; <BR>&gt; Sincerely,<BR>&gt; Frank E.<BR><BR><BR></body>
</html>=

--_e5948c01-2c84-4686-b964-11df20fad8d6_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Thu, 14 Jun 2007 03:58:48 +0000
Message-ID: <BAY117-W189613F96B1E2932C483B3931F0@phx.gbl>
Content-Type: multipart/alternative; boundary="_17999de4-01f3-4c43-b87b-8376147265a8_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <radiusext@ops.ietf.org>
Subject: Re: [IANA #85318] request a new NAS-Port-Type for XPON (fwd)
Date: Wed, 13 Jun 2007 20:58:22 -0700
MIME-Version: 1.0

--_17999de4-01f3-4c43-b87b-8376147265a8_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Here is another comment. > From: EffenbergerFrank 73695 [mailto:feffenberge=
r@huawei.com]> Sent: Wednesday, June 13, 2007 11:23 AM> To: Linda Dunbar> S=
ubject: Re: FW: [802.1 - 2683] FW: [IANA #85318] request a new> NAS-Port-Ty=
pe for XPON> > If I look up the currently defined list of values for NAS-po=
rt-type, I> find:> > Values for RADIUS Attribute 61, NAS-Port-Type [RFC2865=
]:> > 0 Async> 1 Sync> 2 ISDN Sync> 3 ISDN Async V.120> 4 ISDN Async V.110>=
 5 Virtual> 6 PIAFS> 7 HDLC Clear Channel> 8 X.25> 9 X.75> 10 G.3 Fax> 11 S=
DSL - Symmetric DSL> 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Ph=
ase> Modulation> 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone> 14 IDSL=
 - ISDN Digital Subscriber Line> 15 Ethernet> 16 xDSL - Digital Subscriber =
Line of unknown type> 17 Cable> 18 Wireless - Other> 19 Wireless - IEEE 802=
.11> 20 Token-Ring [RFC3580]> 21 FDDI [RFC3580]> 22 Wireless - CDMA2000 [Mc=
Cann]> 23 Wireless - UMTS [McCann]> 24 Wireless - 1X-EV [McCann]> 25 IAPP [=
IEEE 802.11f][Kerry]> 26 FTTP - Fiber to the Premises [Nyce]> 27 Wireless -=
 IEEE 802.16 [IEEE 802.16]> 28 Wireless - IEEE 802.20 [IEEE 802.20]
> 29 Wireless - IEEE 802.22 [IEEE 802.22] > 30 PPPoA - PPP over ATM [RFC460=
3]> 31 PPPoEoA - PPP over Ethernet over ATM [RFC4603]> 32 PPPoEoE - PPP ove=
r Ethernet over Ethernet [RFC4603]> 33 PPPoEoVLAN - PPP over Ethernet over =
VLAN [RFC4603]> 34 PPPoEoQinQ - PPP over Ethernet over IEEE 802.1QinQ [RFC4=
603]> > Bottom-line - it appears that they have been handing out these valu=
es> with very little care for doing a clean job. I'm not sure what use this=
> information is even put to... > > You might mention that observation, and=
 ask for some more clarification.> > > Sincerely,> Frank E.=

--_17999de4-01f3-4c43-b87b-8376147265a8_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
Here is another comment. <BR><BR>&gt; From: EffenbergerFrank 73695 [mailto:=
feffenberger@huawei.com]<BR>&gt; Sent: Wednesday, June 13, 2007 11:23 AM<BR=
>&gt; To: Linda Dunbar<BR>&gt; Subject: Re: FW: [802.1 - 2683] FW: [IANA #8=
5318] request a new<BR>&gt; NAS-Port-Type for XPON<BR>&gt; <BR>&gt; If I lo=
ok up the currently defined list of values for NAS-port-type, I<BR>&gt; fin=
d:<BR>&gt; <BR>&gt; Values for RADIUS Attribute 61, NAS-Port-Type [RFC2865]=
:<BR>&gt; <BR>&gt; 0 Async<BR>&gt; 1 Sync<BR>&gt; 2 ISDN Sync<BR>&gt; 3 ISD=
N Async V.120<BR>&gt; 4 ISDN Async V.110<BR>&gt; 5 Virtual<BR>&gt; 6 PIAFS<=
BR>&gt; 7 HDLC Clear Channel<BR>&gt; 8 X.25<BR>&gt; 9 X.75<BR>&gt; 10 G.3 F=
ax<BR>&gt; 11 SDSL - Symmetric DSL<BR>&gt; 12 ADSL-CAP - Asymmetric DSL, Ca=
rrierless Amplitude Phase<BR>&gt; Modulation<BR>&gt; 13 ADSL-DMT - Asymmetr=
ic DSL, Discrete Multi-Tone<BR>&gt; 14 IDSL - ISDN Digital Subscriber Line<=
BR>&gt; 15 Ethernet<BR>&gt; 16 xDSL - Digital Subscriber Line of unknown ty=
pe<BR>&gt; 17 Cable<BR>&gt; 18 Wireless - Other<BR>&gt; 19 Wireless - IEEE =
802.11<BR>&gt; 20 Token-Ring [RFC3580]<BR>&gt; 21 FDDI [RFC3580]<BR>&gt; 22=
 Wireless - CDMA2000 [McCann]<BR>&gt; 23 Wireless - UMTS [McCann]<BR>&gt; 2=
4 Wireless - 1X-EV [McCann]<BR>&gt; 25 IAPP [IEEE 802.11f][Kerry]<BR>&gt; 2=
6 FTTP - Fiber to the Premises [Nyce]<BR>&gt; 27 Wireless - IEEE 802.16 [IE=
EE 802.16]<BR>&gt; 28 Wireless - IEEE 802.20 [IEEE 802.20]<BR>
&gt; 29 Wireless - IEEE 802.22 [IEEE 802.22]&nbsp;<BR>&gt; 30 PPPoA - PPP o=
ver ATM [RFC4603]<BR>&gt; 31 PPPoEoA - PPP over Ethernet over ATM [RFC4603]=
<BR>&gt; 32 PPPoEoE - PPP over Ethernet over Ethernet [RFC4603]<BR>&gt; 33 =
PPPoEoVLAN - PPP over Ethernet over VLAN [RFC4603]<BR>&gt; 34 PPPoEoQinQ - =
PPP over Ethernet over IEEE 802.1QinQ [RFC4603]<BR>&gt; <BR>&gt; Bottom-lin=
e - it appears that they have been handing out these values<BR>&gt; with ve=
ry little care for doing a clean job. I'm not sure what use this<BR>&gt; in=
formation is even put to... <BR>&gt; <BR>&gt; You might mention that observ=
ation, and ask for some more clarification.<BR>&gt; <BR>&gt; <BR>&gt; Since=
rely,<BR>&gt; Frank E.<BR><BR></body>
</html>=

--_17999de4-01f3-4c43-b87b-8376147265a8_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Thu, 14 Jun 2007 03:58:07 +0000
Message-ID: <BAY117-W168CCC66D930064FBBCB2A931F0@phx.gbl>
Content-Type: multipart/alternative; boundary="_ce255e12-182b-4d42-a87d-c6b0256f472b_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <radiusext@ops.ietf.org>
Subject: Re: [IANA #85318] request a new NAS-Port-Type for XPON (fwd)
Date: Wed, 13 Jun 2007 20:57:02 -0700
MIME-Version: 1.0

--_ce255e12-182b-4d42-a87d-c6b0256f472b_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Paul Congdon forwarded the IANA request to IEEE 802.1 for comment.  Here is=
 one of the comments that came back.=20
=20
> -----Original Message-----> From: Glen Kramer [mailto:glen.kramer@teknovu=
s.com] > Sent: Wednesday, June 13, 2007 5:04 PM> To: Pat Thaler> Cc: Congdo=
n, Paul T (ProCurve); Grow, Bob; David Law; Steve Carlson;> Wael Diab> Subj=
ect: RE: [802.1 - 2683] FW: [IANA #85318] request a new> NAS-Port-Type for =
XPON> > Pat,> > Is this a formal liaison request? .3av focuses on PHY and I=
 am not sure> we have the right expertise in our group to answer this. I th=
ink MacSec> may be a better place to get a meaningful response.> > Unoffici=
ally, I asked an engineer in my company for his opinion. Here it> is:> > **=
*> This field isn't really a functional part of the protocol. It's just> ma=
nagement information. In a RADIUS access request, there is a "port> type" f=
ield that says "I'm a DSL port" or "I'm a cable port" or "I'm a> PON port".=
 This has nothing to do with the actual authentication, and> I'm not even s=
ure why a RADIUS server would care in the first place.> But given that ther=
e's a list of 34 possible port types, it makes sense> to add one (or more) =
for PON. > > It may be that people will want to distinguish various types o=
f PON.> There's a bunch of ADSL port types (DMT, CAP, etc) in addition to a=
> generic xDSL port type. But we can start with xPON and see if people> rea=
lly want to know that it's specifically EPON or GEPON or whatever.> > It's =
not clear what the NAS port number would be. The protocol defines> a port v=
alue as a 32-bit field. This isn't big enough for a MAC> address. But since=
 the logical links are virtual and dynamically> assigned, it doesn't make l=
ots of sense to me to report a link as either> "link index 12" or "LLID 13"=
. Those values will just be different after> the next reset; so, there's no=
thing useful you can provision or check on> the server side; so, it doesn't=
 really matter what the value is, so> there's no point in having a value in=
 the first place. (Note that there> is a NAS-Port-Type of "virtual", which =
is intended for virtual ports> multiplexed over some transport medium. Perh=
aps it's enough to realize> that port type "xPON" means that the port numbe=
r won't have lasting> value.)> ***> > Let me know, if anything is required =
from .3av in this regard.> > Glen> > > -----Original Message-----> > From: =
IEEE 802.1 list HELP only [mailto:hdk-105.xtvbd_h22q10g@att.net]> > On Beha=
lf Of Congdon, Paul T (ProCurve)> > Sent: Wednesday, June 13, 2007 5:29 AM>=
 > To: STDS-802-1-L@listserv.ieee.org> > Subject: [802.1 - 2683] FW: [IANA =
#85318] request a new NAS-Port-Type > > for XPON> > > > Would anyone from I=
EEE 802.1 like to provide a comment here or perhaps> > > pass onto the appr=
opriate 802.3 contacts. The Radius group could > > benefit from a descripti=
on of how this port-type might be used in AAA > > exchanges.> > > > Paul> >=
 > > ________________________________> > > > From: owner-radiusext@ops.ietf=
.org> [mailto:owner-radiusext@ops.ietf.org]> > On Behalf Of Bernard Aboba> =
> Sent: Tuesday, June 12, 2007 8:37 PM> > To: radiusext@ops.ietf.org> > Sub=
ject: FW: [IANA #85318] request a new NAS-Port-Type for XPON> > > > > > IAN=
A has received a request for allocation of a NAS-Port-Type value> for> > XP=
ON. Comments?> > > > > > > Subject: [IANA #85318] request a new NAS-Port-Ty=
pe for XPON> > > From: iana-prot-param-comment@icann.org> > > CC: bernard_a=
boba@hotmail.com> > > Date: Tue, 12 Jun 2007 12:47:07 -0700> > >> > > Dear =
Bernard,> > >> > > Can you advise on this request for a new NAS-Port-Type v=
alue?> > >> > > Thanks,> > >> > > Amanda Baber> > > IANA> > >> > > On Mon J=
un 11 19:57:38 2007, Renxiang.Yan@alcatel-sbell.com.cn> wrote:> > > > Dear =
editor,> > > >> > > > We believed it lacks a RADIUS NAS-Port-Type for PON (=
Passive> Optical> > > > Network) access.> > > > http://www.iana.org/assignm=
ents/radius-types> > > >> > > > Could you please check and allocate one for=
 it?> > > >> > > > Recommended value:> > > > ------------------------------=
----------------------------> > > > value description> > > > 35 xPON - Pass=
ive Optical Network> > > > ------------------------------------------------=
------------> > > >> > > > (xPON may cover: Broadband PON (B-PON/G.983.x), =
Gigabit PON > > > > (G-PON/G.984.x), and Ethernet PON (E-PON/IEEE 802.3ah).=
)> > > >> > > > Kindly regards,> > > >> > > > Renxiang=

--_ce255e12-182b-4d42-a87d-c6b0256f472b_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
Paul Congdon forwarded the IANA request to IEEE 802.1 for comment.&nbsp; He=
re is one of the comments that came back. <BR><BR>
&nbsp;<BR>
&gt; -----Original Message-----<BR>&gt; From: Glen Kramer [mailto:glen.kram=
er@teknovus.com] <BR>&gt; Sent: Wednesday, June 13, 2007 5:04 PM<BR>&gt; To=
: Pat Thaler<BR>&gt; Cc: Congdon, Paul T (ProCurve); Grow, Bob; David Law; =
Steve Carlson;<BR>&gt; Wael Diab<BR>&gt; Subject: RE: [802.1 - 2683] FW: [I=
ANA #85318] request a new<BR>&gt; NAS-Port-Type for XPON<BR>&gt; <BR>&gt; P=
at,<BR>&gt; <BR>&gt; Is this a formal liaison request? .3av focuses on PHY =
and I am not sure<BR>&gt; we have the right expertise in our group to answe=
r this. I think MacSec<BR>&gt; may be a better place to get a meaningful re=
sponse.<BR>&gt; <BR>&gt; Unofficially, I asked an engineer in my company fo=
r his opinion. Here it<BR>&gt; is:<BR>&gt; <BR>&gt; ***<BR>&gt; This field =
isn't really a functional part of the protocol. It's just<BR>&gt; managemen=
t information. In a RADIUS access request, there is a "port<BR>&gt; type" f=
ield that says "I'm a DSL port" or "I'm a cable port" or "I'm a<BR>&gt; PON=
 port". This has nothing to do with the actual authentication, and<BR>&gt; =
I'm not even sure why a RADIUS server would care in the first place.<BR>&gt=
; But given that there's a list of 34 possible port types, it makes sense<B=
R>&gt; to add one (or more) for PON. <BR>&gt; <BR>&gt; It may be that peopl=
e will want to distinguish various types of PON.<BR>&gt; There's a bunch of=
 ADSL port types (DMT, CAP, etc) in addition to a<BR>&gt; generic xDSL port=
 type. But we can start with xPON and see if people<BR>&gt; really want to =
know that it's specifically EPON or GEPON or whatever.<BR>&gt; <BR>&gt; It'=
s not clear what the NAS port number would be. The protocol defines<BR>&gt;=
 a port value as a 32-bit field. This isn't big enough for a MAC<BR>&gt; ad=
dress. But since the logical links are virtual and dynamically<BR>&gt; assi=
gned, it doesn't make lots of sense to me to report a link as either<BR>&gt=
; "link index 12" or "LLID 13". Those values will just be different after<B=
R>&gt; the next reset; so, there's nothing useful you can provision or chec=
k on<BR>&gt; the server side; so, it doesn't really matter what the value i=
s, so<BR>&gt; there's no point in having a value in the first place. (Note =
that there<BR>&gt; is a NAS-Port-Type of "virtual", which is intended for v=
irtual ports<BR>&gt; multiplexed over some transport medium. Perhaps it's e=
nough to realize<BR>&gt; that port type "xPON" means that the port number w=
on't have lasting<BR>&gt; value.)<BR>&gt; ***<BR>&gt; <BR>&gt; Let me know,=
 if anything is required from .3av in this regard.<BR>&gt; <BR>&gt; Glen<BR=
>&gt; <BR>&gt; &gt; -----Original Message-----<BR>&gt; &gt; From: IEEE 802.=
1 list HELP only [mailto:hdk-105.xtvbd_h22q10g@att.net]<BR>&gt; &gt; On Beh=
alf Of Congdon, Paul T (ProCurve)<BR>&gt; &gt; Sent: Wednesday, June 13, 20=
07 5:29 AM<BR>&gt; &gt; To: STDS-802-1-L@listserv.ieee.org<BR>&gt; &gt; Sub=
ject: [802.1 - 2683] FW: [IANA #85318] request a new NAS-Port-Type <BR>&gt;=
 &gt; for XPON<BR>&gt; &gt; <BR>&gt; &gt; Would anyone from IEEE 802.1 like=
 to provide a comment here or perhaps<BR>&gt; <BR>&gt; &gt; pass onto the a=
ppropriate 802.3 contacts. The Radius group could <BR>&gt; &gt; benefit fro=
m a description of how this port-type might be used in AAA <BR>&gt; &gt; ex=
changes.<BR>&gt; &gt; <BR>&gt; &gt; Paul<BR>&gt; &gt; <BR>&gt; &gt; _______=
_________________________<BR>&gt; &gt; <BR>&gt; &gt; From: owner-radiusext@=
ops.ietf.org<BR>&gt; [mailto:owner-radiusext@ops.ietf.org]<BR>&gt; &gt; On =
Behalf Of Bernard Aboba<BR>&gt; &gt; Sent: Tuesday, June 12, 2007 8:37 PM<B=
R>&gt; &gt; To: radiusext@ops.ietf.org<BR>&gt; &gt; Subject: FW: [IANA #853=
18] request a new NAS-Port-Type for XPON<BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt=
; &gt; IANA has received a request for allocation of a NAS-Port-Type value<=
BR>&gt; for<BR>&gt; &gt; XPON. Comments?<BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt=
; &gt; &gt; Subject: [IANA #85318] request a new NAS-Port-Type for XPON<BR>=
&gt; &gt; &gt; From: iana-prot-param-comment@icann.org<BR>&gt; &gt; &gt; CC=
: bernard_aboba@hotmail.com<BR>&gt; &gt; &gt; Date: Tue, 12 Jun 2007 12:47:=
07 -0700<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Dear Bernard,<BR>&gt; &gt; &gt=
;<BR>&gt; &gt; &gt; Can you advise on this request for a new NAS-Port-Type =
value?<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Thanks,<BR>&gt; &gt; &gt;<BR>&gt=
; &gt; &gt; Amanda Baber<BR>&gt; &gt; &gt; IANA<BR>&gt; &gt; &gt;<BR>&gt; &=
gt; &gt; On Mon Jun 11 19:57:38 2007, Renxiang.Yan@alcatel-sbell.com.cn<BR>=
&gt; wrote:<BR>&gt; &gt; &gt; &gt; Dear editor,<BR>&gt; &gt; &gt; &gt;<BR>&=
gt; &gt; &gt; &gt; We believed it lacks a RADIUS NAS-Port-Type for PON (Pas=
sive<BR>&gt; Optical<BR>&gt; &gt; &gt; &gt; Network) access.<BR>&gt; &gt; &=
gt; &gt; http://www.iana.org/assignments/radius-types<BR>&gt; &gt; &gt; &gt=
;<BR>&gt; &gt; &gt; &gt; Could you please check and allocate one for it?<BR=
>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; Recommended value:<BR>&gt; &gt;=
 &gt; &gt; ----------------------------------------------------------<BR>&g=
t; &gt; &gt; &gt; value description<BR>&gt; &gt; &gt; &gt; 35 xPON - Passiv=
e Optical Network<BR>&gt; &gt; &gt; &gt; ----------------------------------=
--------------------------<BR>&gt; &gt; &gt; &gt;<BR>&gt; &gt; &gt; &gt; (x=
PON may cover: Broadband PON (B-PON/G.983.x), Gigabit PON <BR>&gt; &gt; &gt=
; &gt; (G-PON/G.984.x), and Ethernet PON (E-PON/IEEE 802.3ah).)<BR>&gt; &gt=
; &gt; &gt;<BR>&gt; &gt; &gt; &gt; Kindly regards,<BR>&gt; &gt; &gt; &gt;<B=
R>&gt; &gt; &gt; &gt; Renxiang<BR><BR></body>
</html>=

--_ce255e12-182b-4d42-a87d-c6b0256f472b_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Wed, 13 Jun 2007 14:24:52 +0000
From: "David B. Nelson" <dnelson@elbrysnetworks.com>
To: <radiusext@ops.ietf.org>
Subject: RE: [IANA #85318] request a new NAS-Port-Type for XPON
Date: Wed, 13 Jun 2007 10:23:05 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <000101c7adc6$5bfe49b0$6501a8c0@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AcetbMU0igNxv9rmTOmWJZssw717zwAWOmIg

> IANA has received a request for allocation of a NAS-Port-Type
> value for XPON.=A0=A0 Comments?

Seems like a perfectly reasonable request.  The documentation does =
indicate
that this assignment covers all types of PON.  As long as that holds =
true,
this seems fine.  PON is a port type, and not something else, such as a
service type, so assigning a new value of NAS-Port-Type seems =
appropriate.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Wed, 13 Jun 2007 14:20:11 +0000
From: "David B. Nelson" <dnelson@elbrysnetworks.com>
To: <radiusext@ops.ietf.org>
Subject: RE: Proxies and dead home servers
Date: Wed, 13 Jun 2007 10:17:57 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <000001c7adc5$a47c4a80$6501a8c0@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcetwjgcliPFvfq5Tv68dHIEzfUGkwAAykQg

Alan DeKok writes...
> I'm unsure as to why alternatives would be preferred.

I didn't intend to express any preference.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Wed, 13 Jun 2007 13:49:42 +0000
Message-ID: <466FF5A6.1000601@nitros9.org>
Date: Wed, 13 Jun 2007 15:48:22 +0200
From: Alan DeKok <aland@nitros9.org>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: "David B. Nelson" <d.b.nelson@comcast.net>
CC:  radiusext@ops.ietf.org
Subject: Re: Proxies and dead home servers
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

David B. Nelson wrote:
> Alan DeKok Writes ...
>  
>>   In addition, proxies can't know if the client sending them packets is
>> a NAS or is instead another proxy.
> 
> Why not?  Every RADIUS client-server "hop" is protected by a hop-by-hop
> shared secret, keyed at the server by the client's source IP address.
> What's to prevent a server implementation (e.g. in a proxy) from storing a
> NAS/Proxy flag in the local configurations store, along with the shared
> secret?

  Nothing.  Which is why the next sentence started with "Even if they
are configured to treat the client as another proxy ..."

>> So at the minimum, *one* server in the proxy chain (the one local 
>> to the NAS) needs to always respond to the NAS, otherwise the NAS 
>> will think it's down.
> 
> Unless NASes have implemented a form of NAI routing.  I remember one such
> implementation in the DECserver NAS (circa 1985).  It was "pre-NAI" but
> worked similarly, using Kerberos domain syntax.  The "domain decoration" was
> used to select from an arbitrarily long list of possible RADIUS servers.

  To be honest, I haven't seen that in the deployments I work with.  My
experience has been that if your expectations are the
lowest-common-denominator for NASes, you might be aiming a little high.

  I've also seen servers that don't respond to NASes take peoples
networks down.

  Another issue with NAI routing is that when a server goes down, each
route has to discover that independently.  The NAS (or proxying server)
can't know that a server is down, because it may only be the *route*
that's down.  So if N routes are passing through a dead server, some
multiple of N users will get rejected before the NAS decides that all N
routes are down.  If the *server* is marked dead, then all routes can
immediately start using backup servers.

  If the goal is to increase network stability and minimize the number
of users who are rejected due to network outages, then what I'm
proposing appears to do that.  The only users who get rejected are the
ones who's NAI routes are down, and then only for so long as those
routes are down.  I'm unsure as to why alternatives would be preferred.

  Alan DeKok.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Wed, 13 Jun 2007 13:14:45 +0000
From: "David B. Nelson" <d.b.nelson@comcast.net>
To: <radiusext@ops.ietf.org>
Subject: RE: Proxies and dead home servers
Date: Wed, 13 Jun 2007 09:08:38 -0400
Message-ID: <001501c7adbb$f76b4340$6401a8c0@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcetkeP5T6QsSA4sRr+/Uk/52tiLgwAKP1Vw

Alan DeKok Writes ...
 
>   In addition, proxies can't know if the client sending them packets is
> a NAS or is instead another proxy.

Why not?  Every RADIUS client-server "hop" is protected by a hop-by-hop
shared secret, keyed at the server by the client's source IP address.
What's to prevent a server implementation (e.g. in a proxy) from storing a
NAS/Proxy flag in the local configurations store, along with the shared
secret?

> So at the minimum, *one* server in the proxy chain (the one local 
> to the NAS) needs to always respond to the NAS, otherwise the NAS 
> will think it's down.

Unless NASes have implemented a form of NAI routing.  I remember one such
implementation in the DECserver NAS (circa 1985).  It was "pre-NAI" but
worked similarly, using Kerberos domain syntax.  The "domain decoration" was
used to select from an arbitrarily long list of possible RADIUS servers.




--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Wed, 13 Jun 2007 08:03:40 +0000
Message-ID: <466FA476.1020409@nitros9.org>
Date: Wed, 13 Jun 2007 10:01:58 +0200
From: Alan DeKok <aland@nitros9.org>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: "Glen Zorn (gwz)" <gwz@cisco.com>
CC:  radiusext@ops.ietf.org
Subject: Re: Proxies and dead home servers
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn (gwz) wrote:
> No, I'm not.  I'm saying that a proxy should _never_ failover.

  I think we're talking about two separate things.

  I will note that IAS, ACS, Radiator, Navis, SBR, and FreeRADIUS all
support proxy failover.  And that's server-based failover, not
realm-based failover (so far as I can tell).

>>   If what you say about proxy behavior is true, then the NAS can
>> easily tell the difference between a home server and a proxy.  A home
>> server follows RFC 2865, and always sends a response to a request.  
> 
> Nonsense.  It can't send a response if its down.

  Well, yes.  I thought that went without saying.

>> A
>> proxy server sometimes doesn't respond to a request.   
> 
> Reflecting the state of an upstream entity.

  Which is a problem.  So far as the NAS is concerned, the local server
it's sending requests to is authoritative, and *is* the home server.
That local server may be doing proxying, but the NAS doesn't know.  So
what you're saying is that when that local server is proxying, it is
free to violate RFC 2865, which requires that servers always respond to
Access-Requests from a NAS.

  For reasons I outlined previously, this has major negative impact on
the network.  i.e. for a large number of practical, real-world reasons,
it's a good idea for servers to always respond to NASes.

> The problem I'm trying to point out is that the wrong decision is being
> made because the wrong things are being considered.  If NAI-based
> routing is in use & routes instead of servers are marked as up or down
> the problem you're talking about evaporates.

  Do the NASes implement NAI routing, and mark routes up or down instead
of marking servers up or down?  Not that I'm aware of.

  I understand what you're getting at, but treating "routes" as up or
down is something that the NAS just can't do.  So the scenarios I
presented are *explictly* not addressed by your design.  NASes *will*
erroneously believe that a server is down because route A is down, even
though route B is still up.  Users *will* get erroneously rejected, and
administrators will have sleepless nights trying to make their network work.

  In addition, proxies can't know if the client sending them packets is
a NAS or is instead another proxy.  Even if they are configured to treat
the client as another proxy, it is still incumbent on the first server
in the chain to behave properly towards the NAS.  So at the minimum,
*one* server in the proxy chain (the one local to the NAS) needs to
always respond to the NAS, otherwise the NAS will think it's down.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Wed, 13 Jun 2007 05:34:19 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7AD7C.60416D4B"
Subject: RE: [IANA #85318] request a new NAS-Port-Type for XPON
Date: Tue, 12 Jun 2007 22:33:29 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250421B520@xmb-sjc-215.amer.cisco.com>
Thread-Topic: [IANA #85318] request a new NAS-Port-Type for XPON
Thread-Index: AcetbCvc/+bUKgRCTg6C7YDn1AbqQgACzGjQ
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "Bernard Aboba" <bernard_aboba@hotmail.com>
Cc: <radiusext@ops.ietf.org>
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3777; t=1181712813; x=1182576813; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20<gwz@cisco.com> |Subject:=20RE=3A=20[IANA=20#85318]=20request=20a=20new=20NAS-Port-Type=2 0for=20XPON |Sender:=20; bh=wSGPskjWx+jIgHVmpQ3SKQWCae0I+NqWw2IZPRB2ACs=; b=D1z6THlSuxmKvZKSkrLdUKAejQt3iCTfEiFepPSNGagudzCddDCWIeqJ6G2fIRsFWPRmiV6v HHCOqdITPPUCo3VybeU9reqSUJCW8CHOWvH1nx+Vu9T5Kf0F5Aqn4opcIbh9YwEPSJxMDUCvsj WGu+BkEAPLw2O3My1QZ2p9KNo=;
Authentication-Results: sj-dkim-1; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; );

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7AD7C.60416D4B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

IANA has received a request for allocation of a NAS-Port-Type value for
XPON.   Comments?
 I had no idea anyone was actually using PON for access.  Learn
something new every day. =20

> Subject: [IANA #85318] request a new NAS-Port-Type for XPON=20
> From: iana-prot-param-comment@icann.org
> CC: bernard_aboba@hotmail.com
> Date: Tue, 12 Jun 2007 12:47:07 -0700
>=20
> Dear Bernard,
>=20
> Can you advise on this request for a new NAS-Port-Type value?
>=20
> Thanks,
>=20
> Amanda Baber
> IANA
>=20
> On Mon Jun 11 19:57:38 2007, Renxiang.Yan@alcatel-sbell.com.cn wrote:
> > Dear editor,
> >=20
> > We believed it lacks a RADIUS NAS-Port-Type for PON (Passive Optical
> > Network) access.
> > http://www.iana.org/assignments/radius-types
> >=20
> > Could you please check and allocate one for it?
> >=20
> > Recommended value:
> > ----------------------------------------------------------
> > value description
> > 35 xPON - Passive Optical Network
> > ------------------------------------------------------------
> >=20
> > (xPON may cover: Broadband PON (B-PON/G.983.x), Gigabit PON
> > (G-PON/G.984.x), and Ethernet PON (E-PON/IEEE 802.3ah).)=20
> >=20
> > Kindly regards,
> >=20
> > Renxiang
> >=20
> >=20
>=20
>=20
>=20


------_=_NextPart_001_01C7AD7C.60416D4B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE>P {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: =
0px; PADDING-TOP: 0px
}
BODY {
	FONT-SIZE: 10pt; FONT-FAMILY: Tahoma
}
</STYLE>

<META content=3D"MSHTML 6.00.2900.3086" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft>IANA has received a request for allocation =
of a=20
NAS-Port-Type value for XPON.&nbsp;&nbsp; Comments?<BR><SPAN=20
class=3D476385704-13062007><FONT face=3DArial color=3D#0000ff>&nbsp;I =
had no idea=20
anyone was actually using PON for access.&nbsp; Learn something new =
every=20
day.&nbsp; </FONT></SPAN><BR><BR>&gt; Subject: [IANA #85318] request a =
new=20
NAS-Port-Type for XPON <BR>&gt; From: =
iana-prot-param-comment@icann.org<BR>&gt;=20
CC: bernard_aboba@hotmail.com<BR>&gt; Date: Tue, 12 Jun 2007 12:47:07=20
-0700<BR>&gt; <BR>&gt; Dear Bernard,<BR>&gt; <BR>&gt; Can you advise on =
this=20
request for a new NAS-Port-Type value?<BR>&gt; <BR>&gt; Thanks,<BR>&gt; =
<BR>&gt;=20
Amanda Baber<BR>&gt; IANA<BR>&gt; <BR>&gt; On Mon Jun 11 19:57:38 2007,=20
Renxiang.Yan@alcatel-sbell.com.cn wrote:<BR>&gt; &gt; Dear =
editor,<BR>&gt; &gt;=20
<BR>&gt; &gt; We believed it lacks a RADIUS NAS-Port-Type for PON =
(Passive=20
Optical<BR>&gt; &gt; Network) access.<BR>&gt; &gt;=20
http://www.iana.org/assignments/radius-types<BR>&gt; &gt; <BR>&gt; &gt; =
Could=20
you please check and allocate one for it?<BR>&gt; &gt; <BR>&gt; &gt; =
Recommended=20
value:<BR>&gt; &gt;=20
----------------------------------------------------------<BR>&gt; &gt; =
value=20
description<BR>&gt; &gt; 35 xPON - Passive Optical Network<BR>&gt; &gt;=20
------------------------------------------------------------<BR>&gt; =
&gt;=20
<BR>&gt; &gt; (xPON may cover: Broadband PON (B-PON/G.983.x), Gigabit=20
PON<BR>&gt; &gt; (G-PON/G.984.x), and Ethernet PON (E-PON/IEEE =
802.3ah).)=20
<BR>&gt; &gt; <BR>&gt; &gt; Kindly regards,<BR>&gt; &gt; <BR>&gt; &gt;=20
Renxiang<BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; <BR>&gt; <BR>&gt;=20
<BR></DIV></BODY></HTML>

------_=_NextPart_001_01C7AD7C.60416D4B--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Wed, 13 Jun 2007 03:37:28 +0000
Message-ID: <BAY117-W838E1DFF906163CF9C53193180@phx.gbl>
Content-Type: multipart/alternative; boundary="_3031a5aa-dec3-4f8e-8ff0-d46fe95e45b2_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <radiusext@ops.ietf.org>
Subject: FW: [IANA #85318] request a new NAS-Port-Type for XPON
Date: Tue, 12 Jun 2007 20:36:35 -0700
MIME-Version: 1.0

--_3031a5aa-dec3-4f8e-8ff0-d46fe95e45b2_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


IANA has received a request for allocation of a NAS-Port-Type value for XPO=
N.   Comments?> Subject: [IANA #85318] request a new NAS-Port-Type for XPON=
 > From: iana-prot-param-comment@icann.org> CC: bernard_aboba@hotmail.com> =
Date: Tue, 12 Jun 2007 12:47:07 -0700> > Dear Bernard,> > Can you advise on=
 this request for a new NAS-Port-Type value?> > Thanks,> > Amanda Baber> IA=
NA> > On Mon Jun 11 19:57:38 2007, Renxiang.Yan@alcatel-sbell.com.cn wrote:=
> > Dear editor,> > > > We believed it lacks a RADIUS NAS-Port-Type for PON=
 (Passive Optical> > Network) access.> > http://www.iana.org/assignments/ra=
dius-types> > > > Could you please check and allocate one for it?> > > > Re=
commended value:> > -------------------------------------------------------=
---> > value      description> > 35     xPON - Passive Optical Network> > -=
-----------------------------------------------------------> > > > (xPON ma=
y cover: Broadband PON (B-PON/G.983.x), Gigabit PON> > (G-PON/G.984.x), and=
 Ethernet PON (E-PON/IEEE 802.3ah).) > > > > Kindly regards,> > > > Renxian=
g> > > > > > > =

--_3031a5aa-dec3-4f8e-8ff0-d46fe95e45b2_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
IANA has received a request for allocation of a NAS-Port-Type value for XPO=
N.&nbsp;&nbsp; Comments?<br><br><br>&gt; Subject: [IANA #85318] request a n=
ew NAS-Port-Type for XPON <br>&gt; From: iana-prot-param-comment@icann.org<=
br>&gt; CC: bernard_aboba@hotmail.com<br>&gt; Date: Tue, 12 Jun 2007 12:47:=
07 -0700<br>&gt; <br>&gt; Dear Bernard,<br>&gt; <br>&gt; Can you advise on =
this request for a new NAS-Port-Type value?<br>&gt; <br>&gt; Thanks,<br>&gt=
; <br>&gt; Amanda Baber<br>&gt; IANA<br>&gt; <br>&gt; On Mon Jun 11 19:57:3=
8 2007, Renxiang.Yan@alcatel-sbell.com.cn wrote:<br>&gt; &gt; Dear editor,<=
br>&gt; &gt; <br>&gt; &gt; We believed it lacks a RADIUS NAS-Port-Type for =
PON (Passive Optical<br>&gt; &gt; Network) access.<br>&gt; &gt; http://www.=
iana.org/assignments/radius-types<br>&gt; &gt; <br>&gt; &gt; Could you plea=
se check and allocate one for it?<br>&gt; &gt; <br>&gt; &gt; Recommended va=
lue:<br>&gt; &gt; ---------------------------------------------------------=
-<br>&gt; &gt; value      description<br>&gt; &gt; 35     xPON - Passive Op=
tical Network<br>&gt; &gt; ------------------------------------------------=
------------<br>&gt; &gt; <br>&gt; &gt; (xPON may cover: Broadband PON (B-P=
ON/G.983.x), Gigabit PON<br>&gt; &gt; (G-PON/G.984.x), and Ethernet PON (E-=
PON/IEEE 802.3ah).) <br>&gt; &gt; <br>&gt; &gt; Kindly regards,<br>&gt; &gt=
; <br>&gt; &gt; Renxiang<br>&gt; &gt; <br>&gt; &gt; <br>&gt; <br>&gt; <br>&=
gt; <br></body>
</html>=

--_3031a5aa-dec3-4f8e-8ff0-d46fe95e45b2_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Tue, 12 Jun 2007 16:17:03 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proxies and dead home servers
Date: Tue, 12 Jun 2007 09:15:38 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250421B0CC@xmb-sjc-215.amer.cisco.com>
Thread-Topic: Proxies and dead home servers
Thread-Index: AceszdjLpPXohLfoTnmcaTpOAnRNRQAPKpkg
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "Alan DeKok" <aland@nitros9.org>
Cc: <radiusext@ops.ietf.org>
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5217; t=1181664951; x=1182528951; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20<gwz@cisco.com> |Subject:=20RE=3A=20Proxies=20and=20dead=20home=20servers |Sender:=20; bh=Y/k5OM/MZgL8PR0DYnw/eLObV8y7rFFv7rT/GOo+rw0=; b=FsoYfaKYAvJ9ahqzrFu/B2pIFvMSU8Px4GjwO6jaEO6nSvTg6h0jj3IxGJzXxk/w1SgVC/Y9 RrSJ5tyVqpH9Czmi9x/+R7L3EMIxUA10F6LcPRpdzCuAS7ACoVJtMWRynsOswnGJaD3MdK5ieM OskOL4dLd+RwGqZCCt0/MXu1s=;
Authentication-Results: sj-dkim-1; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; );

Alan DeKok <mailto:aland@nitros9.org> allegedly scribbled on Tuesday,
June 12, 2007 1:43 AM:

> Glen Zorn (gwz) wrote:
>>>   If the Home Server does not respond to a proxied Access-Request,
>>> what does the Proxy Server do with it?
>>=20
>> Boringly enough, I posed this exact question thousands of years ago
>> to the (really smart) guy who developed the RADIUS server for what
>> was at the time the largest access network in the world (> 1 million
>> users). His answer is still valid, I think: nothing.
>=20
>   I talked to an ISP operator a month ago.  He said that due to using
> a server with that exact behavior, he had sleepless nights
> frantically trying to allow *some* users on his network.  A home
> server had gone down, and the proxy under his control was behaving in
> the way you suggest, which led the NAS to conclude that the proxy was
> down, too. Since the proxy *also* handled requests for other home
> servers, this was a problem.    =20
>=20
>   His solution was to temporarily update the configuration to not
> proxy *any* requests, and instead allow *all* users on the network
> without performing authentication.=20
>=20
>   I would like to believe such scenarios are bad.  I would like to
> avoid such scenarios by designing systems that are adaptive.=20
>=20
>> No.  You're confusing a "Proxy Server" with a _real_ Server.
>=20
>   The NAS can tell the difference?  Really?  How?
>=20
>   I think you're arguing both sides of the same coin.  You say that a
> proxy can't decide that another box is down, but also that it should
> implement failover. =20

No, I'm not.  I'm saying that a proxy should _never_ failover.

> You say a NAS can't tell the difference between
> a proxy server and home server, but that they should offer different
> behaviors to the NAS. =20

No, what I'm saying is that a proxy needs to be transparent to the NAS;
in order to accomplish this the behavior of its client persona needs to
be different than a normal client, i.e., _not_ failover.
 =20
>=20
>   If what you say about proxy behavior is true, then the NAS can
> easily tell the difference between a home server and a proxy.  A home
> server follows RFC 2865, and always sends a response to a request. =20

Nonsense.  It can't send a response if its down.

> A
> proxy server sometimes doesn't respond to a request.  =20

Reflecting the state of an upstream entity.

>=20
>>  The above
>> does not apply to proxies; to see why, extend the confusion to the
>> client side of the proxy.  If the proxy is a real client, it will
>> discern that no answer is forthcoming by means of the traditional
>> method of multiple time-out and retry, right?  If the proxy clients
>> timeout period is the same as that of the NAS, it will multiply
>> identical but slightly staggered requests before giving up &
>> returning (in your scenario below) an Access-Reject slightly _after_
>> the NAS has given up & tried a different proxy (if available).
>=20
>   Yes.  So?
>=20
>> If the proxy client's time out
>> is too short, though, it risks returning spurious Access-Rejects due
>> to end servers that are just a little bit slow.
>=20
>   Why is this a problem?  If the proxy has reasonable timeouts set,
> then:=20
>=20
>   a) fixed timeouts will be set large enough to handle any reasonable
>   network delay, or b) the proxy will do RTT and discover the real
>   timeouts, AND c) the user will very likely give up after 30 seconds
>   if the network is extremely slow, AND d) one or two users will be
> rejected (likely after they've given up already), because the timers
> aren't synchronized. =20
>=20
>   I fail to understand where the catastrophe is.
>=20
>>  Basically, the time-out &
>> retry behavior in a proxied network MUST be driven by the NAS, not
>> the proxies or total chaos results.
>=20
>   That's what I'm trying to agree with.
>=20
>>    This is not to say that a proxy must blindly forward requests to
>> dead servers. It should certainly note the responsiveness of upstream
>> entities: if one appears to be dead & there is an alternate path
>> available, it should be used but decisions about the health of the
>> upstream entities must be based upon either passive observation or
>> possibly locally generated (& blatantly illegal ;-) probes, not
>> through the imitation of a real client
>=20
>   Do you have comments on RFC 3539, which suggests precisely such
> probes?=20

Just one: Diameter.

>=20
>>> The only safe response is an Access-Reject, I think.
>>=20
>> For reasons outlined above, the only safe response is none.
>=20
>   If I have to choose between a small number of users getting
> erroneously rejected after a long period of time, OR a large number
> of users getting rejected because the NAS erroneously decides that a
> server is down, the choice to me is clear. =20

The problem I'm trying to point out is that the wrong decision is being
made because the wrong things are being considered.  If NAI-based
routing is in use & routes instead of servers are marked as up or down
the problem you're talking about evaporates.
=20
>=20
>   Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Tue, 12 Jun 2007 08:44:32 +0000
Message-ID: <466E5CA3.80301@nitros9.org>
Date: Tue, 12 Jun 2007 10:43:15 +0200
From: Alan DeKok <aland@nitros9.org>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: "Glen Zorn (gwz)" <gwz@cisco.com>
CC:  radiusext@ops.ietf.org
Subject: Re: Proxies and dead home servers
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn (gwz) wrote:
>>   If the Home Server does not respond to a proxied Access-Request,
>> what does the Proxy Server do with it?  
> 
> Boringly enough, I posed this exact question thousands of years ago to
> the (really smart) guy who developed the RADIUS server for what was at
> the time the largest access network in the world (> 1 million users).
> His answer is still valid, I think: nothing.  

  I talked to an ISP operator a month ago.  He said that due to using a
server with that exact behavior, he had sleepless nights frantically
trying to allow *some* users on his network.  A home server had gone
down, and the proxy under his control was behaving in the way you
suggest, which led the NAS to conclude that the proxy was down, too.
Since the proxy *also* handled requests for other home servers, this was
a problem.

  His solution was to temporarily update the configuration to not proxy
*any* requests, and instead allow *all* users on the network without
performing authentication.

  I would like to believe such scenarios are bad.  I would like to avoid
such scenarios by designing systems that are adaptive.

> No.  You're confusing a "Proxy Server" with a _real_ Server.

  The NAS can tell the difference?  Really?  How?

  I think you're arguing both sides of the same coin.  You say that a
proxy can't decide that another box is down, but also that it should
implement failover.  You say a NAS can't tell the difference between a
proxy server and home server, but that they should offer different
behaviors to the NAS.

  If what you say about proxy behavior is true, then the NAS can easily
tell the difference between a home server and a proxy.  A home server
follows RFC 2865, and always sends a response to a request.  A proxy
server sometimes doesn't respond to a request.

>  The above
> does not apply to proxies; to see why, extend the confusion to the
> client side of the proxy.  If the proxy is a real client, it will
> discern that no answer is forthcoming by means of the traditional method
> of multiple time-out and retry, right?  If the proxy clients timeout
> period is the same as that of the NAS, it will multiply identical but
> slightly staggered requests before giving up & returning (in your
> scenario below) an Access-Reject slightly _after_ the NAS has given up &
> tried a different proxy (if available).

  Yes.  So?

> If the proxy client's time out
> is too short, though, it risks returning spurious Access-Rejects due to
> end servers that are just a little bit slow.

  Why is this a problem?  If the proxy has reasonable timeouts set, then:

  a) fixed timeouts will be set large enough to handle any reasonable
network delay, or
  b) the proxy will do RTT and discover the real timeouts, AND
  c) the user will very likely give up after 30 seconds if the network
is extremely slow, AND
  d) one or two users will be rejected (likely after they've given up
already), because the timers aren't synchronized.

  I fail to understand where the catastrophe is.

>  Basically, the time-out &
> retry behavior in a proxied network MUST be driven by the NAS, not the
> proxies or total chaos results.

  That's what I'm trying to agree with.

>    This is not to say that a proxy must
> blindly forward requests to dead servers. It should certainly note the
> responsiveness of upstream entities: if one appears to be dead & there
> is an alternate path available, it should be used but decisions about
> the health of the upstream entities must be based upon either passive
> observation or possibly locally generated (& blatantly illegal ;-)
> probes, not through the imitation of a real client 

  Do you have comments on RFC 3539, which suggests precisely such probes?

>> The only safe response is an Access-Reject, I think. 
> 
> For reasons outlined above, the only safe response is none.

  If I have to choose between a small number of users getting
erroneously rejected after a long period of time, OR a large number of
users getting rejected because the NAS erroneously decides that a server
is down, the choice to me is clear.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Tue, 12 Jun 2007 08:33:53 +0000
Message-ID: <466E5A26.7090406@nitros9.org>
Date: Tue, 12 Jun 2007 10:32:38 +0200
From: Alan DeKok <aland@nitros9.org>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.com>
CC:  radiusext@ops.ietf.org
Subject: Re: Proxies and dead home servers
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

> That depends on the proxy retransmission and backoff behavior.   For
> example, assume that the RTT between the proxy and home server is high
> (e.g. several seconds).  If the proxy doesn't estimate RTT or back off
> its retransmission timer, then it might retransmit several times
> before concluding that the server is dead.  When the server finally
> responds, it is too late because the proxy has already sent an Access-Reject.  

  For one, I'm not aware of proxy implementations that have aggressively
low timeouts.  Deployments that have static timeouts configured
aggressively low will discover that their users are rejected (by the
proxy or even by the NAS), and will fix their timeouts.

  Most fixed timeouts are set to 15-30 seconds.  Those numbers are
chosen *not* from analyzing the network, but from understanding user
behavior.  A slow, low-bandwidth satellite link might have delays of
tens of seconds.  A proxy that properly estimates RTT and adapts to the
slow network without using fixed timeouts is probably wrong... because
the user has given up and walked away.

  As for sending an Access-Reject, I'm not sure it's a problem.  In this
scenario, the NAS thinks the proxy is alive, the proxy thinks the home
server is alive, and one poor user gets told "no".  Given that he's
waited probably 30 seconds for that "no", the delay *already* serves as
an indication that something's gone wrong.

> The discussion in the Appendix applies to UDP as well.  The issue is
> whether the proxy behavior satisfies "conservation of packets". 

  OK.

>> My $0.02 is that it may be useful for the proxy to synthesize an
>> Access-Reject to the NAS when the home server does not respond.
> I would agree as long as the proxy implements appropriate retransmission
> and backoff logic.

  Hmm... That comes back to a question from a few months ago.  Most
RADIUS servers appear to operate as "synchronous" proxies.  i.e. They
retransmit only when the NAS retransmits.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Tue, 12 Jun 2007 08:23:58 +0000
Message-ID: <466E57D6.70105@nitros9.org>
Date: Tue, 12 Jun 2007 10:22:46 +0200
From: Alan DeKok <aland@nitros9.org>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: "Glen Zorn (gwz)" <gwz@cisco.com>
CC: Bernard Aboba <bernard_aboba@hotmail.com>,  radiusext@ops.ietf.org
Subject: Re: Proxies and dead home servers
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn (gwz) wrote:
> Please define "does not respond".  Unless I'm horribly mistaken, the
> only way for a client to determine the unresponsiveness of a server in
> RADIUS is via the time-out & retry method.  Unfortunately, while the
> proxy's timer is running, so is the NAS's.  Are all RADIUS timers
> synchronized in some extremely complex fashion?

  No.  They can all run the same algorithm.

  RADIUS has corner cases where some requests never get response, or
receive responses "too late" (which amounts to the same thing).  If all
implementations run a similar algorithm for timeouts, then the
continuous flow of packets will ensure that they will all settle on the
same view of the network.

  Since the timers are not synchronized, they will not settle on the
same view at the same time.  That is less of a problem than it might
first appear.

> Please explain how & why a NAS knows that a given entry in its server
> table is a proxy & not a home server. 

  It doesn't.  There's no need to.

> By that logic, responding to the NAS should not be necessary;  the proxy
> does not implement its own retransmission logic, it mimics that of the
> NAS and handles failover.

  Once again, what does the proxy do if it runs out of servers in it's
failover list?  Does it drop the request on the floor, or does it
respond to the NAS saying "I'm alive, but the request should be rejected"?

> How does it know what the retransmission logic of the NAS is?

  The proxy doesn't, and doesn't need to.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Tue, 12 Jun 2007 08:18:33 +0000
Message-ID: <466E5678.1020802@nitros9.org>
Date: Tue, 12 Jun 2007 10:16:56 +0200
From: Alan DeKok <aland@nitros9.org>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: "Glen Zorn (gwz)" <gwz@cisco.com>
CC: Bernard Aboba <bernard_aboba@hotmail.com>,  radiusext@ops.ietf.org
Subject: Re: Proxies and dead home servers
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn (gwz) wrote:
>>   I think that the second alternative is preferable to the first one.
> 
> Why?

  For reasons outlined elsewhere.  In short, failures in home server A
should not affect requests destined to home server B.

> I don't really understand your example but be that as it may, in a
> proxied system, neither proxies nor servers can be marked "dead" by a
> client for the reason that (using RADIUS alone) it is not possible for
> the client to know the state of another box on the network.

  I agree it's not possible to know with confidence the state of another
box on the network in RADIUS.  However, the state of the other box
doesn't really matter.  What is at issue is the proxies perception of
that state.

  If, as you say, the proxy can't tell the state of another box, then it
can't implement primary/secondary fail-over.  Since almost all RADIUS
clients and servers implement that, I suspect the covert admission is
that proxies *can* make decisions about the state of another box on the
network.

>  There are
> at least half a dozen things that could keep a response from arriving
> that have nothing at all to do with the health of any of the RADIUS
> entities.  What is down or up is a route to a realm; given that, it's
> not possible for a route to be erroneously marked as dead.  Note that
> routes to different realms are different routes, regardless of whether
> the first hop is the same or not.

  If the first hop is unresponsive to *any* request for extended
periods, then the issue of multiple realms is irrelevant.  That hop is
dead for all practical purposes.

  On top of that, there are no routes in RADIUS.  Requests get sent to
servers based on the key of (dst ip, dst port).  Individual servers may
forward requests based on internal decisions.  Network administrators
may have diagrams which describe hoe packets are routed.  But no machine
inside of the RADIUS "routing" cloud has access to that global routing
information.  In contrast, IP routers have that information available
through BGP/OSPF/whatever.

  I am very leery of talking about "routes" in a protocol which has
"routes" statically configured, and which has no way for "routers" to
exchange "routing" information.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 11 Jun 2007 18:26:35 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proxies and dead home servers
Date: Mon, 11 Jun 2007 11:25:08 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250421AC00@xmb-sjc-215.amer.cisco.com>
Thread-Topic: Proxies and dead home servers
Thread-Index: AcesPBrEkpi87yWjTGuN7yhhwhOHsgAGFoEw
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "Alan DeKok" <aland@nitros9.org>, "Bernard Aboba" <bernard_aboba@hotmail.com>
Cc: <radiusext@ops.ietf.org>
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2181; t=1181586344; x=1182450344; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20<gwz@cisco.com> |Subject:=20RE=3A=20Proxies=20and=20dead=20home=20servers |Sender:=20; bh=NkDxfjBOP+heYqgZgRerhG15yDHM/2MZi1+qQcoflkA=; b=YK1ePrWuqdvUX3M8F83umUNdkjCVJU/VsF9cDpxQuuRB0qEApDbi0+yY5I4McpefNWyuZPM7 k/zH7imwbuk1Y7b/fG2s0j1VW9fwdShVaRTTZPaYd6bVbFPvrOmUHrtUZlGjZIBnSfTtLsYKdf cMVsW1Ft+SU/mJ4WTjAiwsBEc=;
Authentication-Results: sj-dkim-1; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; );

Alan DeKok <> allegedly scribbled on Monday, June 11, 2007 8:19 AM:

> Bernard Aboba wrote:
>> If the home server does not respond to the proxy server, then the
>> proxy server should fail over if it has an alternative home server
>> configured.
>=20
>   When the proxy server doesn't have an alternative home server, then
> what does it do?  If it doesn't respond to the NAS, the NAS may
> erroneously believe it is dead, and reject the session.  If it does
> respond with an Access-Reject, then the NAS will believe that the
> server is still alive, and reject the session.   =20
>=20
>   I think that the second alternative is preferable to the first one.

Why?

...

>   There are corner cases where the NAS may not be able to distinguish
> the proxy being down from the home server being down.  e.g. The NAS
> sends requests through a proxy for "users@example.com" for some time
> while the "example.com" home server is down.  Then, the NAS sends a
> request through a proxy for "user@example.net", while the
> "example.net"    =20
> home server is up.
>=20
>   If the proxy doesn't respond to the requests for "example.com",
> then the NAS may erroneously perform failover, and send the
> "example.net" =20
> requests to a secondary proxy server.  If there's no secondary proxy
> server, the NAS may decide that the proxy is down, and erroneously
> reject the "example.net" request.  This will cause spurious network
> outages for users trying to log in.  =20

I don't really understand your example but be that as it may, in a
proxied system, neither proxies nor servers can be marked "dead" by a
client for the reason that (using RADIUS alone) it is not possible for
the client to know the state of another box on the network.  There are
at least half a dozen things that could keep a response from arriving
that have nothing at all to do with the health of any of the RADIUS
entities.  What is down or up is a route to a realm; given that, it's
not possible for a route to be erroneously marked as dead.  Note that
routes to different realms are different routes, regardless of whether
the first hop is the same or not.

...

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 11 Jun 2007 17:53:00 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7AC51.3480E894"
Subject: RE: Proxies and dead home servers
Date: Mon, 11 Jun 2007 10:51:56 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250421AB9E@xmb-sjc-215.amer.cisco.com>
Thread-Topic: Proxies and dead home servers
Thread-Index: AcesNAxg1x25q2TmT1uQRheh0WZ/WAAHAOMw
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "Bernard Aboba" <bernard_aboba@hotmail.com>, "Alan DeKok" <aland@nitros9.org>, <radiusext@ops.ietf.org>
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7565; t=1181584335; x=1182448335; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20<gwz@cisco.com> |Subject:=20RE=3A=20Proxies=20and=20dead=20home=20servers |Sender:=20; bh=udRNSqHjQfpjyAkajlKQv1qS4M/+kFyPtTHotDMrijo=; b=Nl21yzaaIabCAPj/33DIM/Uror5P+nZfHVlawQjPtIR82IS1CFh85MmY6yDW24OIgqDQseiV EN6XH90UDE0AJjyaOI1EiClO+smocbwOToHRH+fBYgr10BfjdazK6TIL;
Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; );

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7AC51.3480E894
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

If the home server does not respond to the proxy server, then the proxy
server should fail over if it has an alternative home server configured.

Please define "does not respond".  Unless I'm horribly mistaken, the
only way for a client to determine the unresponsiveness of a server in
RADIUS is via the time-out & retry method.  Unfortunately, while the
proxy's timer is running, so is the NAS's.  Are all RADIUS timers
synchronized in some extremely complex fashion?

However, if the home server is busy, then it should send a reply rather
than silently discarding incoming packets, since the latter will cause
the NAS to retransmit.  Ideally RADIUS would have defined a "too busy"
message that would have caused immediate failover, but [RFC2865] did not
define such a message.=20

A NAS should not failover to another proxy unless it has evidence that
they proxy itself (rather than the home server) is down.  That is, if
the proxy has recently responded to any requests at all, then lack of a
response to a particular request is not a reason to failover to another
proxy, it is a reason to retransmit the Request. =20
Please explain how & why a NAS knows that a given entry in its server
table is a proxy & not a home server.=20

By that logic, responding to the NAS should not be necessary;  the proxy
does not implement its own retransmission logic, it mimics that of the
NAS and handles failover.=20
How does it know what the retransmission logic of the NAS is?
This provides the NAS with an equivalent of an "end to end" connection
to the home server in a transport behavior sense.  This is discussed in
RFC 3539.=20


> Date: Mon, 11 Jun 2007 13:47:35 +0200
> From: aland@nitros9.org
> To: radiusext@ops.ietf.org
> Subject: Proxies and dead home servers
>=20
> I've recently come across an issue which the RFC's don't clearly
> address, but which can have major implications in a proxying
environment.
>=20
> Suppose we have a proxy chain as follows:
>=20
> NAS --> Proxy Server --> Home Server
>=20
> If the Home Server does not respond to a proxied Access-Request, what
> does the Proxy Server do with it? RFC 2865 Section 4.1 says:
>=20
> Upon receipt of an Access-Request from a valid client, an
> appropriate reply MUST be transmitted.
>=20
> This would seem to indicate that the Proxy Server MUST respond to the
> NAS, even if the Home Server does not respond to the Proxy Server. The
> only safe response is an Access-Reject, I think.
>=20
> There are implementations that do not behave this way, but I think
> their impact is small.
>=20
> Alan DeKok.
>=20
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>


------_=_NextPart_001_01C7AC51.3480E894
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE>P {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: =
0px; PADDING-TOP: 0px
}
BODY {
	FONT-SIZE: 10pt; FONT-FAMILY: Tahoma
}
</STYLE>

<META content=3D"MSHTML 6.00.2900.3086" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft>If the home server does not respond to the =
proxy server,=20
then the proxy server should fail over if it has an alternative home =
server=20
configured.&nbsp;<SPAN class=3D792464317-11062007><FONT face=3DArial=20
color=3D#0000ff>&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D792464317-11062007><FONT =
face=3DArial=20
color=3D#0000ff>Please define "does not respond".&nbsp;&nbsp;Unless I'm =
horribly=20
mistaken, the only way for a client to determine&nbsp;the =
unresponsiveness of a=20
server in RADIUS is via the time-out &amp; retry method.&nbsp; =
Unfortunately,=20
while the proxy's timer is running, so is the NAS's.&nbsp; Are all =
RADIUS timers=20
synchronized in some extremely complex =
fashion?</FONT></SPAN><BR><BR>However, if=20
the home server is busy, then it should send a reply rather than =
silently=20
discarding incoming packets, since the latter will cause the NAS to=20
retransmit.&nbsp; Ideally RADIUS would have defined a "too busy" message =
that=20
would have caused immediate failover, but [RFC2865] did not define such =
a=20
message. <BR><BR>A NAS should not failover to another proxy unless it =
has=20
evidence that they proxy itself (rather than the home server) is =
down.&nbsp;=20
That is, if the proxy has recently responded to any requests at all, =
then lack=20
of a response to a particular request is not a reason to failover to =
another=20
proxy, it is a reason to retransmit the Request.&nbsp;<SPAN=20
class=3D792464317-11062007><FONT face=3DArial=20
color=3D#0000ff>&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D792464317-11062007><FONT =
face=3DArial=20
color=3D#0000ff>Please explain how &amp; why a NAS knows that a given =
entry in its=20
server table is a proxy &amp; not a home =
server.</FONT>&nbsp;</SPAN><BR><BR>By=20
that logic, responding to the NAS should not be necessary;&nbsp; the =
proxy does=20
not implement its own retransmission logic, it mimics that of the NAS =
and=20
handles failover.<SPAN class=3D792464317-11062007><FONT face=3DArial=20
color=3D#0000ff>&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D792464317-11062007><FONT =
face=3DArial=20
color=3D#0000ff>How does it know what the retransmission logic of the =
NAS=20
is?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft>This provides the NAS with an equivalent of =
an "end to=20
end" connection to the home server in a transport behavior sense.&nbsp; =
This is=20
discussed in RFC 3539. <BR><BR><BR>&gt; Date: Mon, 11 Jun 2007 13:47:35=20
+0200<BR>&gt; From: aland@nitros9.org<BR>&gt; To: =
radiusext@ops.ietf.org<BR>&gt;=20
Subject: Proxies and dead home servers<BR>&gt; <BR>&gt; I've recently =
come=20
across an issue which the RFC's don't clearly<BR>&gt; address, but which =
can=20
have major implications in a proxying environment.<BR>&gt; <BR>&gt; =
Suppose we=20
have a proxy chain as follows:<BR>&gt; <BR>&gt; NAS --&gt; Proxy Server =
--&gt;=20
Home Server<BR>&gt; <BR>&gt; If the Home Server does not respond to a =
proxied=20
Access-Request, what<BR>&gt; does the Proxy Server do with it? RFC 2865 =
Section=20
4.1 says:<BR>&gt; <BR>&gt; Upon receipt of an Access-Request from a =
valid=20
client, an<BR>&gt; appropriate reply MUST be transmitted.<BR>&gt; =
<BR>&gt; This=20
would seem to indicate that the Proxy Server MUST respond to the<BR>&gt; =
NAS,=20
even if the Home Server does not respond to the Proxy Server. =
The<BR>&gt; only=20
safe response is an Access-Reject, I think.<BR>&gt; <BR>&gt; There are=20
implementations that do not behave this way, but I think<BR>&gt; their =
impact is=20
small.<BR>&gt; <BR>&gt; Alan DeKok.<BR>&gt; <BR>&gt; --<BR>&gt; to =
unsubscribe=20
send a message to radiusext-request@ops.ietf.org with<BR>&gt; the word=20
'unsubscribe' in a single line as the message text body.<BR>&gt; =
archive:=20
&lt;http://psg.com/lists/radiusext/&gt;<BR></DIV></BODY></HTML>

------_=_NextPart_001_01C7AC51.3480E894--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 11 Jun 2007 16:20:35 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proxies and dead home servers
Date: Mon, 11 Jun 2007 09:20:00 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250421AAE0@xmb-sjc-215.amer.cisco.com>
Thread-Topic: Proxies and dead home servers
Thread-Index: AcesHqMCh9EemvU4SZ+9991F8xDKjQAIVzQQ
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "Alan DeKok" <aland@nitros9.org>
Cc: <radiusext@ops.ietf.org>
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2623; t=1181578810; x=1182442810; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=20=22Glen=20Zorn=20\(gwz\)=22=20<gwz@cisco.com> |Subject:=20RE=3A=20Proxies=20and=20dead=20home=20servers |Sender:=20; bh=8GYYXWv78jt332hC3cc4Auzq9+x2ws4XXmJVKq5dKw8=; b=K0TrnbI9TtMWYN//nm+qgXp3Yzs7MOCkBR1DOH7Tz5ZRYcHCo2BoWMFUk2/9xewVuxK9AoLI VGBIV3LDxDmFrTSm3sPJgPwM9AJRWbLqLVNPVaET+2WF1XLXaRrUXKPH;
Authentication-Results: sj-dkim-8; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim8002 verified; );

Alan DeKok <> allegedly scribbled on Monday, June 11, 2007 4:48 AM:

>   I've recently come across an issue which the RFC's don't clearly
> address, but which can have major implications in a proxying
> environment. =20
>=20
>   Suppose we have a proxy chain as follows:
>=20
>  NAS --> Proxy Server --> Home Server
>=20
>   If the Home Server does not respond to a proxied Access-Request,
> what does the Proxy Server do with it? =20

Boringly enough, I posed this exact question thousands of years ago to
the (really smart) guy who developed the RADIUS server for what was at
the time the largest access network in the world (> 1 million users).
His answer is still valid, I think: nothing. =20

< RFC 2865 Section 4.1 says:=20
>=20
>       Upon receipt of an Access-Request from a valid client, an
>       appropriate reply MUST be transmitted.
>=20
>   This would seem to indicate that the Proxy Server MUST respond to
> the NAS, even if the Home Server does not respond to the Proxy
> Server. =20

No.  You're confusing a "Proxy Server" with a _real_ Server.  The above
does not apply to proxies; to see why, extend the confusion to the
client side of the proxy.  If the proxy is a real client, it will
discern that no answer is forthcoming by means of the traditional method
of multiple time-out and retry, right?  If the proxy clients timeout
period is the same as that of the NAS, it will multiply identical but
slightly staggered requests before giving up & returning (in your
scenario below) an Access-Reject slightly _after_ the NAS has given up &
tried a different proxy (if available).  If the proxy client's time out
is too short, though, it risks returning spurious Access-Rejects due to
end servers that are just a little bit slow.  Basically, the time-out &
retry behavior in a proxied network MUST be driven by the NAS, not the
proxies or total chaos results.    This is not to say that a proxy must
blindly forward requests to dead servers. It should certainly note the
responsiveness of upstream entities: if one appears to be dead & there
is an alternate path available, it should be used but decisions about
the health of the upstream entities must be based upon either passive
observation or possibly locally generated (& blatantly illegal ;-)
probes, not through the imitation of a real client=20

> The only safe response is an Access-Reject, I think.=20

For reasons outlined above, the only safe response is none.

>=20
>   There are implementations that do not behave this way, but I think
> their impact is small.=20
>=20
>   Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 11 Jun 2007 16:04:21 +0000
Message-ID: <BAY117-W13D05F09CB122F46065EB0931A0@phx.gbl>
Content-Type: multipart/alternative; boundary="_79924146-ff6e-41db-b38d-46e70b4f774c_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Alan DeKok <aland@nitros9.org>
CC: <radiusext@ops.ietf.org>
Subject: RE: Proxies and dead home servers
Date: Mon, 11 Jun 2007 09:03:34 -0700
MIME-Version: 1.0

--_79924146-ff6e-41db-b38d-46e70b4f774c_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> When the proxy server doesn't have an alternative home server, then> what=
 does it do? If it doesn't respond to the NAS, the NAS may> erroneously bel=
ieve it is dead, and reject the session. If it does> respond with an Access=
-Reject, then the NAS will believe that the server> is still alive, and rej=
ect the session.> > I think that the second alternative is preferable to th=
e first one.
=20
That depends on the proxy retransmission and backoff behavior.   For exampl=
e, assume that the RTT between the proxy and home server is high (e.g. seve=
ral seconds).  If the proxy doesn't estimate RTT or back off its retransmis=
sion timer, then it might retransmit several times before concluding that t=
he server is dead.  When the server finally responds, it is too late becaus=
e the proxy has already sent an Access-Reject. =20
=20
> If the proxy doesn't respond to the requests for "example.com", then> the=
 NAS may erroneously perform failover, and send the "example.net"> requests=
 to a secondary proxy server. If there's no secondary proxy> server, the NA=
S may decide that the proxy is down, and erroneously> reject the "example.n=
et" request. This will cause spurious network> outages for users trying to =
log in.
=20
> If the proxy server does not respond to *any* of the retransmissions> fro=
m the NAS, then there are cases where the NAS may conclude that the> proxy =
server is dead, even though it is actually alive.
=20
Yes.=20
> > > This provides the NAS with an equivalent of an "end to end" connectio=
n> > to the home server in a transport behavior sense. This is discussed in=
> > RFC 3539.> > The end-to-end transport issues discussed in RFC 3539 appl=
y only to> TCP or SCTP streams, where the client receives an explicit indic=
ation> that the connection has been closed.=20
=20
The discussion in the Appendix applies to UDP as well.  The issue is whethe=
r the proxy behavior satisfies "conservation of packets".=20
=20
> My $0.02 is that it may be useful for the proxy to synthesize an> Access-=
Reject to the NAS when the home server does not respond. This> indicates to=
 the NAS that the proxy is still alive, and does not change> other NAS beha=
vior such as rejecting the user login attempt.
I would agree as long as the proxy implements appropriate retransmission an=
d backoff logic. =

--_79924146-ff6e-41db-b38d-46e70b4f774c_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
&gt; When the proxy server doesn't have an alternative home server, then<BR=
>&gt; what does it do? If it doesn't respond to the NAS, the NAS may<BR>&gt=
; erroneously believe it is dead, and reject the session. If it does<BR>&gt=
; respond with an Access-Reject, then the NAS will believe that the server<=
BR>&gt; is still alive, and reject the session.<BR>&gt; <BR>&gt; I think th=
at the second alternative is preferable to the first one.<BR>
&nbsp;<BR>
That depends on the proxy retransmission and backoff behavior.&nbsp;&nbsp; =
For example, assume that the RTT between the proxy and home server is high =
(e.g. several seconds).&nbsp; If the proxy doesn't estimate RTT or back off=
 its retransmission timer, then it might retransmit several times before co=
ncluding that the server is dead.&nbsp; When the server finally responds, i=
t is too late because the proxy has already sent an Access-Reject.&nbsp; <B=
R>
&nbsp;<BR>
&gt; If the proxy doesn't respond to the requests for "example.com", then<B=
R>&gt; the NAS may erroneously perform failover, and send the "example.net"=
<BR>&gt; requests to a secondary proxy server. If there's no secondary prox=
y<BR>&gt; server, the NAS may decide that the proxy is down, and erroneousl=
y<BR>&gt; reject the "example.net" request. This will cause spurious networ=
k<BR>&gt; outages for users trying to log in.<BR>
&nbsp;<BR>
&gt; If the proxy server does not respond to *any* of the retransmissions<B=
R>&gt; from the NAS, then there are cases where the NAS may conclude that t=
he<BR>&gt; proxy server is dead, even though it is actually alive.<BR>
&nbsp;<BR>
Yes. <BR>
<BR>&gt; <BR>&gt; &gt; This provides the NAS with an equivalent of an "end =
to end" connection<BR>&gt; &gt; to the home server in a transport behavior =
sense. This is discussed in<BR>&gt; &gt; RFC 3539.<BR>&gt; <BR>&gt; The end=
-to-end transport issues discussed in RFC 3539 apply only to<BR>&gt; TCP or=
 SCTP streams, where the client receives an explicit indication<BR>&gt; tha=
t the connection has been closed. <BR>
&nbsp;<BR>
The discussion in the Appendix applies to UDP as well.&nbsp; The issue is w=
hether the proxy behavior satisfies "conservation of packets". <BR>
&nbsp;<BR>
&gt; My $0.02 is that it may be useful for the proxy to synthesize an<BR>&g=
t; Access-Reject to the NAS when the home server does not respond. This<BR>=
&gt; indicates to the NAS that the proxy is still alive, and does not chang=
e<BR>&gt; other NAS behavior such as rejecting the user login attempt.<BR><=
BR>
I would agree as long as the proxy implements appropriate retransmission an=
d backoff logic. <BR></body>
</html>=

--_79924146-ff6e-41db-b38d-46e70b4f774c_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 11 Jun 2007 15:20:48 +0000
Message-ID: <466D67ED.9070005@nitros9.org>
Date: Mon, 11 Jun 2007 17:19:09 +0200
From: Alan DeKok <aland@nitros9.org>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.com>
CC:  radiusext@ops.ietf.org
Subject: Re: Proxies and dead home servers
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> If the home server does not respond to the proxy server, then the
> proxy server should fail over if it has an alternative home server
> configured.

  When the proxy server doesn't have an alternative home server, then
what does it do?  If it doesn't respond to the NAS, the NAS may
erroneously believe it is dead, and reject the session.  If it does
respond with an Access-Reject, then the NAS will believe that the server
is still alive, and reject the session.

  I think that the second alternative is preferable to the first one.

> However, if the home server is busy, then it should send
> a reply rather than silently discarding incoming packets, since the
> latter will cause the NAS to retransmit.  Ideally RADIUS would have
> defined a "too busy" message that would have caused immediate failover,
> but [RFC2865] did not define such a message.

  Yes.  Hind-sight is 20-20.

> A NAS should not failover
> to another proxy unless it has evidence that they proxy itself (rather
> than the home server) is down.

  There are corner cases where the NAS may not be able to distinguish
the proxy being down from the home server being down.  e.g. The NAS
sends requests through a proxy for "users@example.com" for some time
while the "example.com" home server is down.  Then, the NAS sends a
request through a proxy for "user@example.net", while the "example.net"
home server is up.

  If the proxy doesn't respond to the requests for "example.com", then
the NAS may erroneously perform failover, and send the "example.net"
requests to a secondary proxy server.  If there's no secondary proxy
server, the NAS may decide that the proxy is down, and erroneously
reject the "example.net" request.  This will cause spurious network
outages for users trying to log in.

>  That is, if the proxy has recently
> responded to any requests at all, then lack of a response to a
> particular request is not a reason to failover to another proxy, it is
> a reason to retransmit the Request.

  Yes.

> By that logic, responding to the
> NAS should not be necessary;  the proxy does not implement its own
> retransmission logic, it mimics that of the NAS and handles failover.

  The failure case is between the proxy server and the NAS, not between
the proxy and the home server.

  If the proxy server does not respond to *any* of the retransmissions
from the NAS, then there are cases where the NAS may conclude that the
proxy server is dead, even though it is actually alive.

>  This provides the NAS with an equivalent of an "end to end" connection
> to the home server in a transport behavior sense.  This is discussed in
> RFC 3539.

  The end-to-end transport issues discussed in RFC 3539 apply only to
TCP or SCTP streams, where the client receives an explicit indication
that the connection has been closed.  With those transport protocols,
the NAS does not need to receive an AAA message from the proxy, as the
underlying transport indicates to the NAS that the connection to the
proxy is still up, and that the proxy is still alive.

  RADIUS is implemented over UDP, where the client may receive no
indication that a connection is down, because there is no connection.
So the client can't use the underlying transport protocol as an
indication that the proxy is alive.  Instead, all the NAS knows is that
the proxy has not responded.  It should reject the user, of course.  But
should it mark the proxy as dead?  If so, why?  If not, why not?

  My $0.02 is that it may be useful for the proxy to synthesize an
Access-Reject to the NAS when the home server does not respond.  This
indicates to the NAS that the proxy is still alive, and does not change
other NAS behavior such as rejecting the user login attempt.

  Alan DeKok.

p.s.
 Section 3.4 of RFC 3539 covers the Application-Layer watchdog, but I'm
curious as to how that interacts with Section 2.6 of RFC 2865,
"Keep-Alives Considered Harmful".  I think the watchdog algorithm in RFC
3539 is useful, and could be implemented in RADIUS in spite of the
restrictions in Section 2.6 of RFC 2865.  But that's another issue.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 11 Jun 2007 14:23:09 +0000
Message-ID: <BAY117-W276A45843D653D8B93A3D931A0@phx.gbl>
Content-Type: multipart/alternative; boundary="_ff2dfde7-e356-4e6d-9644-3a2ef60de8cd_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Alan DeKok <aland@nitros9.org>, <radiusext@ops.ietf.org>
Subject: RE: Proxies and dead home servers
Date: Mon, 11 Jun 2007 07:22:17 -0700
MIME-Version: 1.0

--_ff2dfde7-e356-4e6d-9644-3a2ef60de8cd_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


If the home server does not respond to the proxy server, then the proxy ser=
ver should fail over if it has an alternative home server configured. Howev=
er, if the home server is busy, then it should send a reply rather than sil=
ently discarding incoming packets, since the latter will cause the NAS to r=
etransmit.  Ideally RADIUS would have defined a "too busy" message that wou=
ld have caused immediate failover, but [RFC2865] did not define such a mess=
age. A NAS should not failover to another proxy unless it has evidence that=
 they proxy itself (rather than the home server) is down.  That is, if the =
proxy has recently responded to any requests at all, then lack of a respons=
e to a particular request is not a reason to failover to another proxy, it =
is a reason to retransmit the Request. By that logic, responding to the NAS=
 should not be necessary;  the proxy does not implement its own retransmiss=
ion logic, it mimics that of the NAS and handles failover.  This provides t=
he NAS with an equivalent of an "end to end" connection to the home server =
in a transport behavior sense.  This is discussed in RFC 3539. > Date: Mon,=
 11 Jun 2007 13:47:35 +0200> From: aland@nitros9.org> To: radiusext@ops.iet=
f.org> Subject: Proxies and dead home servers> >   I've recently come acros=
s an issue which the RFC's don't clearly> address, but which can have major=
 implications in a proxying environment.> >   Suppose we have a proxy chain=
 as follows:> >  NAS --> Proxy Server --> Home Server> >   If the Home Serv=
er does not respond to a proxied Access-Request, what> does the Proxy Serve=
r do with it?  RFC 2865 Section 4.1 says:> >       Upon receipt of an Acces=
s-Request from a valid client, an>       appropriate reply MUST be transmit=
ted.> >   This would seem to indicate that the Proxy Server MUST respond to=
 the> NAS, even if the Home Server does not respond to the Proxy Server.  T=
he> only safe response is an Access-Reject, I think.> >   There are impleme=
ntations that do not behave this way, but I think> their impact is small.> =
>   Alan DeKok.> > --> to unsubscribe send a message to radiusext-request@o=
ps.ietf.org with> the word 'unsubscribe' in a single line as the message te=
xt body.> archive: <http://psg.com/lists/radiusext/>=

--_ff2dfde7-e356-4e6d-9644-3a2ef60de8cd_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
If the home server does not respond to the proxy server, then the proxy ser=
ver should fail over if it has an alternative home server configured. <br><=
br>However, if the home server is busy, then it should send a reply rather =
than silently discarding incoming packets, since the latter will cause the =
NAS to retransmit.&nbsp; Ideally RADIUS would have defined a "too busy" mes=
sage that would have caused immediate failover, but [RFC2865] did not defin=
e such a message. <br><br>A NAS should not failover to another proxy unless=
 it has evidence that they proxy itself (rather than the home server) is do=
wn.&nbsp; That is, if the proxy has recently responded to any requests at a=
ll, then lack of a response to a particular request is not a reason to fail=
over to another proxy, it is a reason to retransmit the Request. <br><br>By=
 that logic, responding to the NAS should not be necessary;&nbsp; the proxy=
 does not implement its own retransmission logic, it mimics that of the NAS=
 and handles failover.&nbsp; This provides the NAS with an equivalent of an=
 "end to end" connection to the home server in a transport behavior sense.&=
nbsp; This is discussed in RFC 3539. <br><br><br>&gt; Date: Mon, 11 Jun 200=
7 13:47:35 +0200<br>&gt; From: aland@nitros9.org<br>&gt; To: radiusext@ops.=
ietf.org<br>&gt; Subject: Proxies and dead home servers<br>&gt; <br>&gt;   =
I've recently come across an issue which the RFC's don't clearly<br>&gt; ad=
dress, but which can have major implications in a proxying environment.<br>=
&gt; <br>&gt;   Suppose we have a proxy chain as follows:<br>&gt; <br>&gt; =
 NAS --&gt; Proxy Server --&gt; Home Server<br>&gt; <br>&gt;   If the Home =
Server does not respond to a proxied Access-Request, what<br>&gt; does the =
Proxy Server do with it?  RFC 2865 Section 4.1 says:<br>&gt; <br>&gt;      =
 Upon receipt of an Access-Request from a valid client, an<br>&gt;       ap=
propriate reply MUST be transmitted.<br>&gt; <br>&gt;   This would seem to =
indicate that the Proxy Server MUST respond to the<br>&gt; NAS, even if the=
 Home Server does not respond to the Proxy Server.  The<br>&gt; only safe r=
esponse is an Access-Reject, I think.<br>&gt; <br>&gt;   There are implemen=
tations that do not behave this way, but I think<br>&gt; their impact is sm=
all.<br>&gt; <br>&gt;   Alan DeKok.<br>&gt; <br>&gt; --<br>&gt; to unsubscr=
ibe send a message to radiusext-request@ops.ietf.org with<br>&gt; the word =
'unsubscribe' in a single line as the message text body.<br>&gt; archive: &=
lt;http://psg.com/lists/radiusext/&gt;<br></body>
</html>=

--_ff2dfde7-e356-4e6d-9644-3a2ef60de8cd_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 11 Jun 2007 13:10:53 +0000
Message-ID: <466D496B.2090806@nitros9.org>
Date: Mon, 11 Jun 2007 15:08:59 +0200
From: Alan DeKok <aland@nitros9.org>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: "David B. Nelson" <dnelson@elbrysnetworks.com>
CC:  radiusext@ops.ietf.org
Subject: Re: Determining WG consensus on Issue 226: RFC 3576bis and Renumbering
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

David B. Nelson wrote:
> It seems to me that these options would apply equally to any attribute that
> could be either (a) a session identifier attribute or (b) a session
> re-authorization provisioning attribute.  This would include the use of
> VSAs, as discussed in another message.
> 
> Right?

  Yes.  The list is near-infinite.

  Alan DeKok.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 11 Jun 2007 11:49:48 +0000
Message-ID: <466D3657.4000702@nitros9.org>
Date: Mon, 11 Jun 2007 13:47:35 +0200
From: Alan DeKok <aland@nitros9.org>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To:  radiusext@ops.ietf.org
Subject: Proxies and dead home servers
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

  I've recently come across an issue which the RFC's don't clearly
address, but which can have major implications in a proxying environment.

  Suppose we have a proxy chain as follows:

 NAS --> Proxy Server --> Home Server

  If the Home Server does not respond to a proxied Access-Request, what
does the Proxy Server do with it?  RFC 2865 Section 4.1 says:

      Upon receipt of an Access-Request from a valid client, an
      appropriate reply MUST be transmitted.

  This would seem to indicate that the Proxy Server MUST respond to the
NAS, even if the Home Server does not respond to the Proxy Server.  The
only safe response is an Access-Reject, I think.

  There are implementations that do not behave this way, but I think
their impact is small.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Fri, 08 Jun 2007 05:01:09 +0000
Message-ID: <BAY117-W4408E439C592BB68104CE93250@phx.gbl>
Content-Type: multipart/alternative; boundary="_c7403b5f-f7e0-409b-b6d3-f2910ad4a9b1_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <radiusext@ops.ietf.org>
Subject: RADEXT WG last call on RFC 3576bis
Date: Thu, 7 Jun 2007 21:59:59 -0700
MIME-Version: 1.0

--_c7403b5f-f7e0-409b-b6d3-f2910ad4a9b1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This is an announcement of RADEXT WG last call on RFC 3576bis, prior to sen=
ding the document on to the IESG for publication as an Informational RFC.=20
=20
The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-08.txt
=20
The RADEXT WG last call will last until June 22, 2008.   Please send commen=
ts to the RADEXT WG mailing list (radiusext@ops.ietf.org) using the Issues =
format described in the RADEXT WG issues web page (http://www.drizzle.com/~=
aboba/RADEXT). =20
=20
 =

--_c7403b5f-f7e0-409b-b6d3-f2910ad4a9b1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
This is an announcement of RADEXT WG last call on RFC 3576bis, prior to sen=
ding the document on to the IESG for publication as an Informational RFC. <=
BR>
&nbsp;<BR>
The document is available for inspection here:<BR>
<A href=3D"http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis=
-08.txt">http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-0=
8.txt</A><BR>
&nbsp;<BR>
The RADEXT WG last call will last until June 22, 2008.&nbsp;&nbsp; Please s=
end comments to the RADEXT WG mailing list (<A href=3D"mailto:radiusext@ops=
.ietf.org">radiusext@ops.ietf.org</A>) using the Issues format described in=
 the RADEXT WG issues web page (<A href=3D"http://www.drizzle.com/~aboba/RA=
DEXT">http://www.drizzle.com/~aboba/RADEXT</A>).&nbsp; <BR>
&nbsp;<BR>
&nbsp;<BR></body>
</html>=

--_c7403b5f-f7e0-409b-b6d3-f2910ad4a9b1_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Thu, 07 Jun 2007 19:51:33 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: radiusext@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-radext-rfc3576bis-08.txt 
Message-Id: <E1HwNze-0002Ua-04@stiedprstage1.ietf.org>
Date: Thu, 07 Jun 2007 15:50:02 -0400

--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		: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
	Author(s)	: M. Chiba, et al.
	Filename	: draft-ietf-radext-rfc3576bis-08.txt
	Pages		: 37
	Date		: 2007-6-7
	
This document describes a currently deployed extension to the Remote
   Authentication Dial In User Service (RADIUS) protocol, allowing
   dynamic changes to a user session, as implemented by network access
   server products.  This includes support for disconnecting users and
   changing authorizations applicable to a user session.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-radext-rfc3576bis-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-rfc3576bis-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2007-6-7110440.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-rfc3576bis-08.txt

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

Content-Type: text/plain
Content-ID:	<2007-6-7110440.I-D@ietf.org>

--OtherAccess--

--NextPart--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Wed, 06 Jun 2007 00:39:04 +0000
Message-ID: <4665B534.8080700@gmx.net>
Date: Tue, 05 Jun 2007 21:10:44 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: 'radext mailing list' <radiusext@ops.ietf.org>
Subject: Extensibility of draft-ietf-radext-filter-rules
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

I have a question regarding the extensibility of 
draft-ietf-radext-filter-rules.

The document states that there is a version field. Now, there is the 
question when and how you define new versions.

* Does every tiny extension demand a new version number?

* Since a new version number is just a new constant in the rule set and 
does not require a new AVP are there IANA actions associated with the 
definition of new extensions?
 
* Does an extension (e.g., a new action) then require the document 
author to copy-and-paste the entire ABNF with the enhancements or would 
it be more preferable to just place the modified snippet into a new 
document? What would you suggest?

For example, one could just put the following modified ip-filter-rule 
code snippet into a doc:

         ;IP Filter Rule
         ip-filter-rule =  ("permit" / "deny" / NEW-ACTION ) " "
                                                           ^^^^^^^^^^^^^^^
                           ("in" / "out" / "inout") " "
                           ("ip" / ip-proto) filter-body 
                           [" " ip-option] [" " log-rule]


Wouldn't it be necessary or useful to carry the version number also 
attached to the capability attribute from the NAS to the RADIUS server?

Ciao
Hannes


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 04 Jun 2007 17:50:58 +0000
Message-ID: <BAY117-W39F36EB44F44373B5166093210@phx.gbl>
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <radiusext@ops.ietf.org>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Mon, 4 Jun 2007 10:50:16 -0700
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

> [Avi2]  Yes.  I think that this is the best apporoach. Perhaps an example=
 or two would make it clear.  If the NAS receives a session ID that identif=
ies the User Session only such as NAI, and if the user had multiple session=
s such as IP sessions, then ALL the sessions associated with that user are =
affected.

[BA] OK.  I've filed a separate issue on this.=20

> [BA] Where the NAS is a pure L2 device (e.g. IEEE 802 switch, 802.11 AP),=
 it has no awareness of L3,  and so does not track the IP addresses of clie=
nts.
> [Avi2] Then receiving an IP address makes no sense to the NAS either as a=
 session identifier or as a new IP address.

[BA] Right.=20

> [Avi2]  Just for the record.  I am not aware of any application where we =
want to change the IP address using RADIUS.  Infact, in most cases we never=
 want to change the IP address since that breaks IP Session Continuity.  Wh=
y would anyone want to change the IP address?  But lets say that we do want=
 to support such a feature. Who knows what the future will bring.

[BA] This issue originally came up in a 16ng WG presentation, describing us=
e of Framed-IPv6-Prefix/Delegated-IPv6-Prefix for address management in WiM=
AX.  My assumption is that Delegated-IPv6-Prefix would never be used for se=
ssion identification so that there is no issue with attempting to change th=
e delegated prefixes in a CoA-Request.=20

> 1. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier attribute=
s in Disconnect-Request & CoA-Request packets, only for identification.   C=
hanging the address would require a Service-Type=3DAuthorize Only.  This wa=
s what we had in -05.
> [Avi2] This is inefficient.  If you were to have a reason to change an IP=
 address mid session that you should be able to do so with either approach.=
  As I said above, I cant think of any reason to change an IP address.  So =
I could live with this.

[BA] I agree that selection by IP address is likely to be much more common =
than changing an IP address. =20

> 4. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier address a=
ttributes in Disconnect-Request & CoA-Request packets only for identificati=
on.  Invent new attributes for address change.
> [Avi2] Yes.  I think this option is the most appealing to me.
> [Avi2] I think 4 is the right choice.  And we can use that model for any =
other session identifier that can also  be changed dynamically.

[BA] OK. =20

> [Avi2] Yes I agree.  I think we better be explicit about VSAs.

[BA] A separate issue has been opened for this.=20


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 04 Jun 2007 16:24:19 +0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A6C4.EEA79D26"
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Mon, 4 Jun 2007 12:25:15 -0400
Message-ID: <E7CCE8A83907104ABEE91AC3AE3709A0024C3E4A@exchange.bridgewatersys.com>
From: "Avi Lior" <avi@bridgewatersystems.com>
To: "Bernard Aboba" <bernard_aboba@hotmail.com>, "Alan DeKok" <aland@nitros9.org>
Cc: "David B. Nelson" <dnelson@elbrysnetworks.com>, <radiusext@ops.ietf.org>, "Bernard Aboba" <bernarda@windows.microsoft.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7A6C4.EEA79D26
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Please see inline...[Avi2]

________________________________

From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20
Sent: Sunday, June 03, 2007 10:10 PM
To: Avi Lior; Alan DeKok
Cc: David B. Nelson; radiusext@ops.ietf.org; Bernard Aboba
Subject: RE: Issue 226: RFC 3576bis and Renumbering



> Sending a DM with an NAI or some other user identification, we
> terminate all of the users IP sessions.

[BA]  RFC 3576 Section 3 says:=20

	   The ability to use NAS or session identification
	   attributes to map to unique/multiple sessions is beyond the
scope of
	   this document. =20
=09
	Therefore it isn't clear that sending a Disconnect-Request with
a User-Name/CUI attribute=20
	will necessarily terminate *all* the user's sessions if there
are more than one.=20
=09
	Do we need to say something like "all sessions matching the NAS
& session=20
	identification attributes are affected by
CoA/Disconnect-Requests?"
=09
	[Avi2]  Yes.  I think that this is the best apporoach. Perhaps
an example or two would make it clear.  If the NAS receives a session ID
that identifies the User Session only such as NAI, and if the user had
multiple sessions such as IP sessions, then ALL the sessions associated
with that user are affected.
	 =20
=09
	[BA] Also, unless the NAS previously received Framed-IP-Address
or Framed-IPv6-Prefix/Framed-Interface-Id attributes in an Access-Accept
it typically will not know the user's IP address.  This is the situation
with most NAS-Port-Type values, with the exception of PPP or protocols
depending on PPP (e.g. PPPOE, PPPOA, L2TP, PPTP, etc.)
=09
	[Avi]  In most cases that I am aware of, the NAS is the Point of
Attachement to the internet and it knows the IP address(es) assigned to
the user. So it is IP Session aware.  In any case, there are scenarios
where it is IP session aware and it should be possible to make
modification to those Sessions using DM or COA using the IP address as
the Session Identifier.
=09
	[BA] Where the NAS is a pure L2 device (e.g. IEEE 802 switch,
802.11 AP), it has no awareness of L3,  and so does not track the IP
addresses of clients. =20
=09
	[Avi2] Then receiving an IP address makes no sense to the NAS
either as a session identifier or as a new IP address.
	=20
	Where the NAS does track the IP address of clients, it would be
possible to use IP address attributes for *either* identification *or*
change, but not both in the same packet.=20
	=20
	[Avi2]  Just for the record.  I am not aware of any application
where we want to change the IP address using RADIUS.  Infact, in most
cases we never want to change the IP address since that breaks IP
Session Continuity.  Why would anyone want to change the IP address?
But lets say that we do want to support such a feature. Who knows what
the future will bring.
=09
	So the choices are:
=09
	1. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier
attributes in Disconnect-Request & CoA-Request packets, only for
identification.   Changing the address would require a
Service-Type=3DAuthorize Only.  This was what we had in -05.
	[Avi2] This is inefficient.  If you were to have a reason to
change an IP address mid session that you should be able to do so with
either approach.  As I said above, I cant think of any reason to change
an IP address.  So I could live with this.
=09
	2. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier
attributes in Disconnect-Requests for identification.  In CoA-Request
packets allow them only for address change. =20
	[Avi2] No. This  is inconsistant. And it does not allow me to
changes something relating to a specific IP Session. =20
=09
	3. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier
address attributes in Disconnect-Request & CoA-Request packets only for
address change.  Invent new attributes for identification.  This was
previously proposed for -07.
	[Avi2]  No. See 4.
=09
	4. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier
address attributes in Disconnect-Request & CoA-Request packets only for
identification.  Invent new attributes for address change.=20
	[Avi2] Yes.  I think this option is the most appealing to me.
=09

	5. Prohibit use of
Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier attributes for
session identification.  Permit their use only in CoA-Request packets,
for use in address change.  This is what we have in -07.=20
	[Avi2] No. Because of what I stated earlier.  It is uncommon to
change the IP address.  It is most common to change some aspect of an IP
session.
	=20
	I think this more or less describes the choices available on
this issue.  Are there any more?=20
=09
	[Avi2] I think 4 is the right choice.  And we can use that model
for any other session identifier that can also  be changed dynamically.=20
=09
=09
	[Avi] Yes I agree that it "can" be used.  But Alan seems to make
it mandatory. And to mandatory require that it be sent in the
Access-Request packet.  I dont agree with that.  I think if the
deployement requires it to be in the access request then it can be sent.
The current RFCs are fine.
=09
	[BA] I don't think we can make it mandatory to include
Acct-Session-Id/Acct-Multi-Session-Id.  But I would like to be clear
about what other attributes MAY/SHOULD be included, and what happens
when they are included (e.g. how the NAS selects the affected sessions).

	[Avi2] VSA must be allowed for session identification. See
below. =20
	[Avi2]  The problem is that there is no definition for what a
session is.  Therefore we cant be specific in the definition here.  In
general a NAS will maintain one or more Sessions for a given user.
These sessions are going to be related to each other like a tree.  The
top most session is the user session - the authenticated session.  That
session will have subsessions, and thus subsession may have further
subsessions.  The NAS will use the information received to identify one
of those sessions. Then that session and its subsession will be
affected.=20
=09
=09
	[BA]  RFC 3576 Section 3 (or RFC 3576bis) does not include VSAs
for the purpose of session identification.   However, RFC 3576bis
Section 2.3 does say this:
=09
=09
	      Within this specification attributes can be used for
	      identification, authorization or other purposes.  RADIUS
Attribute
	      specifications created after publication of this document
SHOULD
	      state whether an attribute can be included in CoA or
Disconnect
	      messages and if so, which messages it can be included in
and
	      whether it serves as an identification or authorization
attribute.
=09
	I don't intrinsically see anything wrong with using VSAs for
session identification,
	assuming that they are not required, and that sending them to a
NAS which doesn't
	support them generate an appropriate error message (e.g. 401
(Unsupported Attribute)).=20
=09
	So maybe we should add VSAs to the Session Identification list,
as well as a paragraph=20
	stating that their use is optional.=20
=09
	[Avi2] Yes I agree.  I think we better be explicit about VSAs.
	=20


------_=_NextPart_001_01C7A6C4.EEA79D26
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE>P {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: =
0px; PADDING-TOP: 0px
}
BODY {
	FONT-SIZE: 10pt; FONT-FAMILY: Tahoma
}
</STYLE>

<META content=3D"MSHTML 6.00.6000.16441" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D423412515-04062007>Please see=20
inline...[Avi2]</SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<B>From:</B> Bernard Aboba [mailto:bernard_aboba@hotmail.com] =
<BR><B>Sent:</B>=20
Sunday, June 03, 2007 10:10 PM<BR><B>To:</B> Avi Lior; Alan =
DeKok<BR><B>Cc:</B>=20
David B. Nelson; radiusext@ops.ietf.org; Bernard =
Aboba<BR><B>Subject:</B> RE:=20
Issue 226: RFC 3576bis and Renumbering<BR><BR></DIV>
<DIV></DIV><BR>&gt; Sending a DM with an NAI or some other user =
identification,=20
we<BR>&gt; terminate all of the users IP sessions.<BR><BR>[BA]&nbsp; RFC =
3576=20
Section 3 says:
<BLOCKQUOTE>
  <DIV><PRE>   The ability to use NAS or session identification<BR>   =
attributes to map to unique/multiple sessions is beyond the scope of<BR> =
  this document.  <BR><BR>Therefore it isn't clear that sending a =
Disconnect-Request with a User-Name/CUI attribute <BR>will necessarily =
terminate *all* the user's sessions if there are more than one. =
<BR><BR>Do we need to say something like "all sessions matching the NAS =
&amp; session <BR>identification attributes are affected by =
CoA/Disconnect-Requests?"<BR><SPAN class=3D423412515-04062007><FONT =
face=3DTahoma></FONT></SPAN></PRE><PRE><SPAN =
class=3D423412515-04062007><FONT face=3DTahoma>[Avi2]  Yes.  I think =
that this is the best apporoach. Perhaps an example or two would make it =
clear.  </FONT></SPAN><SPAN class=3D423412515-04062007><FONT =
face=3DTahoma>If the NAS receives a session ID that identifies the User =
Session only such as NAI, and if the user had multiple sessions such as =
IP sessions, then ALL the sessions associated with that user are =
affected.</FONT></SPAN></PRE><PRE><SPAN class=3D423412515-04062007><FONT =
face=3DTahoma>&nbsp;&nbsp;</FONT></SPAN><BR></PRE><SPAN=20
  class=3DEC_666361715-29052007></SPAN></DIV>
  <DIV><SPAN class=3DEC_666361715-29052007>[BA]&nbsp;</SPAN>Also, unless =
the NAS=20
  previously received Framed-IP-Address or=20
  Framed-IPv6-Prefix/Framed-Interface-Id attributes in an Access-Accept =
it=20
  typically will not know the user's IP address.&nbsp; This is the =
situation=20
  with most NAS-Port-Type values, with the exception of PPP or protocols =

  depending on PPP (e.g. PPPOE, PPPOA, L2TP, PPTP, etc.)<BR><SPAN=20
  class=3DEC_666361715-29052007></SPAN><BR><SPAN=20
  class=3DEC_666361715-29052007>[Avi]&nbsp;&nbsp;In most cases that I am =
aware of,=20
  the NAS is the Point of Attachement to the internet and it knows the =
IP=20
  address(es) assigned to the user. So it is IP Session aware.&nbsp; In =
any=20
  case, there are scenarios where it is IP session aware and it should =
be=20
  possible to make modification to those Sessions using DM or COA using =
the IP=20
  address as the Session Identifier.<BR><BR>[BA] Where the NAS is a pure =
L2=20
  device (e.g. IEEE 802 switch, 802.11 AP), it has no awareness of =
L3,&nbsp; and=20
  so does not track the IP addresses of clients.&nbsp; <BR><SPAN=20
  class=3D423412515-04062007></SPAN></SPAN></DIV>
  <DIV><SPAN class=3DEC_666361715-29052007><SPAN=20
  class=3D423412515-04062007>[Avi2]&nbsp;Then receiving an IP =
address&nbsp;makes=20
  no sense to the NAS either as a session identifier or&nbsp;as a new IP =

  address.</SPAN></SPAN></DIV>
  <DIV><SPAN class=3DEC_666361715-29052007><SPAN=20
  class=3D423412515-04062007>&nbsp;</SPAN><BR>Where the NAS does track =
the IP=20
  address of clients, it would be possible to use IP address attributes =
for=20
  *either* identification *or* change, but not both in the same=20
  packet.&nbsp;<BR><SPAN =
class=3D423412515-04062007>&nbsp;</SPAN><BR><SPAN=20
  class=3D423412515-04062007>[Avi2]&nbsp;&nbsp;Just for the =
record.&nbsp; I am not=20
  aware of any application where we want to change the IP address using=20
  RADIUS.&nbsp; Infact, in most cases we never want to change the IP =
address=20
  since that breaks IP Session Continuity.&nbsp; Why would anyone want =
to change=20
  the IP address?&nbsp; But lets say that we do want to support such a =
feature.=20
  Who knows what the future will bring.</SPAN><BR><BR>So the choices=20
  are:<BR><BR>1. Allow =
Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier=20
  attributes in Disconnect-Request &amp; CoA-Request packets, only for=20
  identification.&nbsp;&nbsp; Changing the address would require a=20
  Service-Type=3DAuthorize Only.&nbsp; This was what we had in =
-05.<BR><SPAN=20
  class=3D423412515-04062007>[Avi2]&nbsp;This is inefficient.&nbsp; If =
you were to=20
  have a reason to change an IP address mid session that you should be =
able to=20
  do so with either approach.&nbsp;&nbsp;As I said above, I cant think =
of any=20
  reason to change an IP address.&nbsp; So I could live with=20
  this.</SPAN><BR><BR>2. Allow=20
  Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier attributes in=20
  Disconnect-Requests for identification.&nbsp; In CoA-Request packets =
allow=20
  them only for address change.&nbsp; <BR><SPAN =
class=3D423412515-04062007>[Avi2]=20
  No.&nbsp;This&nbsp; is inconsistant.&nbsp;And it does not allow =
me&nbsp;to=20
  changes&nbsp;something relating to a specific IP=20
  Session.&nbsp;&nbsp;</SPAN><BR><BR>3. Allow </SPAN><SPAN=20
  =
class=3DEC_666361715-29052007>Framed-IP-Address/Framed-IPv6-Prefix/Framed=
-Identifier</SPAN><SPAN=20
  class=3DEC_666361715-29052007> address attributes in =
Disconnect-Request &amp;=20
  CoA-Request packets only for address change.&nbsp; Invent new =
attributes for=20
  identification.&nbsp; This was previously proposed for -07.<BR><SPAN=20
  class=3D423412515-04062007>[Avi2]&nbsp;&nbsp;No. See=20
  4.</SPAN><BR><BR></SPAN><SPAN class=3DEC_666361715-29052007>4. Allow=20
  </SPAN><SPAN=20
  =
class=3DEC_666361715-29052007>Framed-IP-Address/Framed-IPv6-Prefix/Framed=
-Identifier</SPAN><SPAN=20
  class=3DEC_666361715-29052007> address attributes in =
Disconnect-Request &amp;=20
  CoA-Request packets only for identification.&nbsp; Invent new =
attributes for=20
  address change. <BR><SPAN=20
  class=3D423412515-04062007>[Avi2]&nbsp;Yes.&nbsp;&nbsp;I think this =
option is=20
  the most appealing to me.</SPAN></SPAN></DIV><SPAN=20
  class=3DEC_666361715-29052007><SPAN class=3D423412515-04062007></SPAN>
  <DIV><BR>5. Prohibit use of </SPAN><SPAN=20
  =
class=3DEC_666361715-29052007>Framed-IP-Address/Framed-IPv6-Prefix/Framed=
-Identifier</SPAN><SPAN=20
  class=3DEC_666361715-29052007> attributes for session =
identification.&nbsp;=20
  Permit their use only in CoA-Request packets, for use in address =
change.&nbsp;=20
  This is what we have in -07. <BR><SPAN =
class=3D423412515-04062007>[Avi2]=20
  No.&nbsp;Because of what&nbsp;I stated earlier.&nbsp; It is uncommon=20
  to&nbsp;change the IP address.&nbsp; It is most common to change some =
aspect=20
  of an IP session.</SPAN></SPAN></DIV>
  <DIV><SPAN class=3DEC_666361715-29052007><SPAN=20
  class=3D423412515-04062007>&nbsp;</SPAN><BR>I think this more or less =
describes=20
  the choices available on this issue.&nbsp; Are there any more?=20
  <BR></SPAN><SPAN class=3DEC_666361715-29052007><BR></SPAN><SPAN=20
  class=3DEC_666361715-29052007></SPAN><SPAN=20
  class=3DEC_666361715-29052007></SPAN><SPAN=20
  class=3D423412515-04062007>[Avi2]&nbsp;I think 4 is the =
right&nbsp;choice.&nbsp;=20
  And we can&nbsp;use&nbsp;that model for any other session identifier =
that can=20
  also&nbsp; be changed dynamically.&nbsp;</SPAN><BR></DIV><SPAN=20
  class=3DEC_666361715-29052007></SPAN>
  <DIV><SPAN class=3DEC_666361715-29052007>[Avi]&nbsp;Yes I agree that=20
  it&nbsp;"can" be used.&nbsp; But Alan seems to make it mandatory. And =
to=20
  mandatory require that it be sent=20
  in&nbsp;the&nbsp;Access-Request&nbsp;packet.&nbsp; I dont agree with=20
  that.&nbsp; I think&nbsp;if the deployement requires it to be in the =
access=20
  request then it can be sent.&nbsp;&nbsp;The current RFCs are =
fine.<BR><BR>[BA]=20
  I don't think we can make it mandatory to include=20
  Acct-Session-Id/Acct-Multi-Session-Id.&nbsp; But I would like to be =
clear=20
  about what other attributes MAY/SHOULD be included, and what happens =
when they=20
  are included (e.g. how the NAS selects the affected sessions).&nbsp; =
<BR><SPAN=20
  class=3D423412515-04062007>[Avi2] VSA&nbsp;must be allowed for session =

  identification. See below.&nbsp;&nbsp;</SPAN><BR><SPAN=20
  class=3D423412515-04062007>[Avi2]&nbsp;&nbsp;The problem is that there =
is no=20
  definition for what a session is.&nbsp; Therefore we cant be specific =
in the=20
  definition here.&nbsp; In general a NAS will maintain one or more =
Sessions for=20
  a given user.&nbsp;&nbsp;These sessions are going to be related to =
each other=20
  like a tree.&nbsp; The top most session is the user session - the=20
  authenticated session.&nbsp; That session&nbsp;will have subsessions, =
and thus=20
  subsession may have further subsessions.&nbsp; The NAS will use the=20
  information received to identify one of those sessions. Then that =
session and=20
  its subsession will be&nbsp;affected.&nbsp;</SPAN><BR><BR></SPAN><SPAN =

  class=3DEC_666361715-29052007><BR>[BA]&nbsp; RFC 3576 Section 3 (or =
RFC 3576bis)=20
  does not include VSAs for the purpose of session =
identification.&nbsp;&nbsp;=20
  However, RFC 3576bis Section 2.3 does say this:<BR><BR></SPAN><PRE>    =
  Within this specification attributes can be used for<BR>      =
identification, authorization or other purposes.  RADIUS Attribute<BR>   =
   specifications created after publication of this document SHOULD<BR>  =
    state whether an attribute can be included in CoA or Disconnect<BR>  =
    messages and if so, which messages it can be included in and<BR>     =
 whether it serves as an identification or authorization =
attribute.<BR><BR>I don't intrinsically see anything wrong with using =
VSAs for session identification,<BR>assuming that they are not required, =
and that sending them to a NAS which doesn't<BR>support them generate an =
appropriate error message (e.g. 401 (Unsupported Attribute)). <BR><BR>So =
maybe we should add VSAs to the Session Identification list, as well as =
a paragraph <BR>stating that their use is optional. <BR><SPAN =
class=3D423412515-04062007><FONT =
face=3DTahoma></FONT></SPAN></PRE><PRE><SPAN =
class=3D423412515-04062007><FONT face=3DTahoma>[Avi2]&nbsp;Yes I agree.  =
I think we better be explicit about VSAs.</FONT></SPAN></PRE><PRE><SPAN =
class=3D423412515-04062007>&nbsp;</SPAN></PRE></DIV></BLOCKQUOTE></BODY><=
/HTML>

------_=_NextPart_001_01C7A6C4.EEA79D26--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 04 Jun 2007 16:11:00 +0000
Message-ID: <BAY117-W7D341D0F982416826F43993210@phx.gbl>
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <radiusext@ops.ietf.org>
Subject: RFC 3576bis and Renumbering:  Some thoughts
Date: Mon, 4 Jun 2007 09:10:05 -0700
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

In looking at the potential choices for resolution of this issue (see below=
), some thoughts come to mind:

a. Renumbering is a rare event.  Therefore there is no requirement that we =
optimize for this case; instead we should focus on more common cases.=20

b. Session identification via Framed-IP-Address/Framed-IPv6-Prefix/Framed-I=
dentifier was included in RFC 3576 and appears to have been implemented (at=
 least by Dynamic Authorization Clients).   Therefore an argument may be ma=
de for retaining backward compatibility.=20

c. A Disconnect-Request may only contain NAS and session identification att=
ributes.  Therefore IP address attributes included in a Disconnect-Request =
have an unambiguous meaning.=20

d. There seem to be valid scenarios where use of an IP address attribute fo=
r session identification can simply operation of a Dynamic Authorization Cl=
ient.  For example, an IDS system may know the source IP address of an offe=
nding packet, and the NASes from which it may have originated, but it may n=
ot have access to attributes sent in the Access-Request or Accounting-Reque=
st. =20

Based on a), objections to 1 relating to inefficiency can be dismissed, and=
 option 4 can be precluded.=20

Based on b), options 3 and 5 would seem to be precluded.=20

Based on c), it would appear to be unnecessary to preclude IP address attri=
butes in a Disconnect-Request as advocated in 5.=20

Based on d), option 2 appears to be precluded.=20

This would appear to leave us with option 1.=20

Does this logic make sense?=20

-------------------------------
1. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier attributes
in Disconnect-Request & CoA-Request packets, only for identification.=20
Changing the address would require a Service-Type=3DAuthorize Only. This
was what we had in -05.

2. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier attributes
in Disconnect-Requests for identification. In CoA-Request packets allow=20
them only for address change.=20

3. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier address
attributes in Disconnect-Request & CoA-Request packets only for address
change. Invent new attributes for identification. This was initially
proposed for -07.=20

4. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier address
attributes in Disconnect-Request & CoA-Request packets only for
identification. Invent new attributes for address change.=20

5. Prohibit use of Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier
attributes for session identification. Permit their use only in CoA-
Request packets, for use in address change. This is what we have in -07.=20
=20


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 04 Jun 2007 15:31:08 +0000
Message-ID: <BAY117-W7DBDD6DAE73FF669DB1E393210@phx.gbl>
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <radiusext@ops.ietf.org>
Subject: RE: Determining WG consensus on Issue 226: RFC 3576bis and Renumbering
Date: Mon, 4 Jun 2007 08:30:47 -0700
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

I think that these issues could definitely apply to VSAs included in a CoA-=
Request.  I'm not aware that they apply to other standard attributes, thoug=
h (e.g. other RFC 3576 session identification attributes don't seem to be u=
seful for authorization change). =20


----------------------------------------
> From: dnelson@elbrysnetworks.com
> To: radiusext@ops.ietf.org
> Subject: RE: Determining WG consensus on Issue 226: RFC 3576bis and Renum=
bering
> Date: Mon, 4 Jun 2007 11:17:05 -0400
>=20
> > 1. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier attribu=
tes
> > in Disconnect-Request & CoA-Request packets, only for identification.=20
> > Changing the address would require a Service-Type=3DAuthorize Only.  Th=
is
> > was what we had in -05.
> >
> > 2. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier attribu=
tes
> > in Disconnect-Requests for identification.  In CoA-Request packets allo=
w=20
> > them only for address change. =20
> >
> > 3. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier address
> > attributes in Disconnect-Request & CoA-Request packets only for address
> > change.  Invent new attributes for identification.  This was initially
> > proposed for -07.=20
> >
> > 4. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier address
> > attributes in Disconnect-Request & CoA-Request packets only for
> > identification.  Invent new attributes for address change.=20
> >
> > 5. Prohibit use of Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifi=
er
> > attributes for session identification.  Permit their use only in CoA-
> > Request packets, for use in address change.  This is what we have in -0=
7.=20
>=20
> It seems to me that these options would apply equally to any attribute th=
at
> could be either (a) a session identifier attribute or (b) a session
> re-authorization provisioning attribute.  This would include the use of
> VSAs, as discussed in another message.
>=20
> Right?
>=20
>=20
>=20
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive:=20

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 04 Jun 2007 15:29:01 +0000
Message-ID: <BAY117-W65A161163C10713ED775093210@phx.gbl>
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <radiusext@ops.ietf.org>
Subject: RE: Issue 238:  Identification of multiple sessions
Date: Mon, 4 Jun 2007 08:28:31 -0700
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

I went through the text again, and I think that some additional changes are=
 needed as well.   IMHO changes of this magnitude will require the document=
 to go through another WG last call.=20

For example, in several places in the document, the term "a session" is use=
d when in fact multiple sessions could be affected.  Affecting multiple ses=
sions also has implications for Diameter/RADIUS translation, since Diameter=
 requires a Session-Id AVP, implying that it can only handle dynamic author=
ization relating to a single session.=20
Also, a NAS may not necessarily support multiple session identification, so=
 an Error-Cause value is needed so that it can explain this to the Dynamic =
Authorization Client.=20

Sections 2.1 and 2.2 need to be changed to indicate that multiple sessions =
can be affected:

2.1.  Disconnect Messages (DM)

   A Disconnect-Request packet is sent by the Dynamic Authorization
   Client in order to terminate user session(s) on a NAS and discard all
   associated session context.  The Disconnect-Request packet is sent to
   UDP port 3799, and identifies the NAS as well as the user session(s)
   to be terminated by inclusion of the identification attributes
   described in Section 3.

   +----------+                          +----------+
   |          |   Disconnect-Request     |          |
   |          |   <--------------------  |  Dynamic |
   |    NAS   |                          |  Authz   |
   |          |   Disconnect-Response    |  Client  |
   |          |   ---------------------> |          |
   +----------+                          +----------+

   The NAS responds to a Disconnect-Request packet sent by a Dynamic
   Authorization Client with a Disconnect-ACK if all associated session
   context is discarded and the user session(s) are no longer connected,
   or a Disconnect-NAK, if the NAS was unable to disconnect one or more
   sessions and discard all associated session context.  A Disconnect-
   ACK MAY contain the Attribute Acct-Terminate-Cause (49) [RFC2866]
   with the value set to 6 for Admin-Reset.

2.2.  Change-of-Authorization Messages (CoA)

   CoA-Request packets contain information for dynamically changing
   session authorizations.  Typically this is used to change data
   filters.  The data filters can be of either the ingress or egress
   kind, and are sent in addition to the identification attributes as
   described in section 3.  The port used, and packet format (described
   in Section 2.3), are the same as that for Disconnect-Request packets.

   The following attributes MAY be sent in a CoA-Request:

   Filter-ID (11) -        Indicates the name of a data filter list
                           to be applied for the session(s) that the
                           identification attributes map to.

   NAS-Filter-Rule (92)  - Provides a filter list to be applied
                           for the session(s) that the identification
                           attributes map to [RFC4849].

   +----------+                          +----------+
   |          |      CoA-Request         |          |
   |          |  <--------------------   |  Dynamic |
   |   NAS    |                          |  Authz   |
   |          |     CoA-Response         |  Client  |
   |          |   ---------------------> |          |
   +----------+                          +----------+

   The NAS responds to a CoA-Request sent by a Dynamic Authorization
   Client with a CoA-ACK if the NAS is able to successfully change the
   authorizations for the user session(s), or a CoA-NAK if the CoA-
   Request is unsuccessful.  A NAS MUST respond to a CoA-Request
   including a Service-Type Attribute with an unsupported value with a
   CoA-NAK; an Error-Cause Attribute with value "Unsupported Service"
   SHOULD be included.

The paragraph in Section 2.3 relating to atomicity needs to be changed to t=
he following to address the possibility
that the NAS will not support multiple session identification:

      State changes resulting from a CoA-Request MUST be atomic: if the
      CoA-Request is successful for all matching sessions, the NAS MUST
      send a CoA-ACK in reply, and all requested authorization changes
      MUST be made.  If the CoA-Request is unsuccessful for any matching
      sessions, the NAS MUST send as CoA-NAK in reply, and the requested
      authorization changes MUST NOT be made for any of the matching
      sessions.  Similarly, a state change MUST NOT occur as a result of
      a Disconnect-Request that is unsuccessful with respect to any of
      the matching sessions; a NAS MUST send a Disconnect-NAK in reply
      if any of the matching sessions cannot be successfully terminated.
      A NAS which does not support dynamic authorization changes
      applying to multiple sessions MUST send a CoA-NAK or Disconnect-
      NAK in reply; an Error-Cause Attribute with value 508 (Multiple
      Session Selection Unsupported) SHOULD be included.

Section 3, first paragraph needs to change to the following:

   In Disconnect-Request and CoA-Request packets, certain attributes are
   used to uniquely identify the NAS as well as user session(s) on the
   NAS.  All NAS and session identification identification attributes
   included in a CoA-Request or Disconnect-Request packet MUST match at
   least one session in order for a Request to be successful; otherwise
   a Disconnect-NAK or CoA-NAK MUST be sent.  If all NAS identification
   attributes match and more than one session matches all of the session
   identification attributes, then a CoA-Request or Disconnect-Request
   MUST apply to all matching sessions.

The Session Identification table needs to accomodate the potential for mult=
iple sessions as well:

     Session identification attributes

     Attribute              #   Reference  Description
     ---------             ---  ---------  -----------
     User-Name              1   [RFC2865]  The name of the user
                                           associated with one or
                                           more sessions.
     NAS-Port               5   [RFC2865]  The port on which a
                                           session is terminated.
     Vendor-Specific       26   [RFC2865]  One or more vendor-specific
                                           identification attributes.
     Called-Station-Id     30   [RFC2865]  The link address to which
                                           a session is connected.
     Calling-Station-Id    31   [RFC2865]  The link address from which
                                           one or more sessions are
                                           connected.
     Acct-Session-Id       44   [RFC2866]  The identifier uniquely
                                           identifying a session
                                           on the NAS.
     Acct-Multi-Session-Id 50   [RFC2866]  The identifier uniquely
                                           identifying related sessions.
     NAS-Port-Id           87   [RFC2869]  String identifying the port
                                           where a session is.
     Chargeable-User-      89   [RFC4372]  The CUI associated with one
     Identity                              or more sessions.  Needed
                                           where a privacy NAI is used,
                                           since in this case the
                                           User-Name (e.g. "anonymous")
                                           may not identify sessions
                                           belonging to a given user.

The following paragraph needs to be changed to reflect the possibility of m=
ultiple sessions:

   Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not
   present in a CoA-Request or Disconnect-Request, it is possible that
   the the User-Name or Chargeable-User-Identity attributes will not be
   sufficient to uniquely identify a single session (e.g. if the same
   user has multiple sessions on the NAS, or if the privacy NAI is
   used).  In this case if it is desired to identify a single session,
   session identification MAY be performed by using one or more of the
   Called-Station-Id, Calling-Station-Id, NAS-Port and NAS-Port-Id
   attributes.

In Section 3.5 an additional Error-Cause value is needed:

      508    Multiple Session Selection Unsupported

      "Multiple Session Selection Unsupported" is a fatal error sent by
      a NAS in response to a CoA-Request or Disconnect-Request whose
      session identification attributes match multiple sessions, where
      the NAS does not support Requests applying to multiple sessions.

Section 4 Diameter Considerations also needs to take multiple session suppo=
rt into account:

4.  Diameter Considerations

   Due to differences in handling change-of-authorization requests in
   RADIUS and Diameter, it may be difficult or impossible for a
   Diameter/RADIUS gateway to successfully translate a Diameter Re-Auth-
   Request (RAR) to a CoA-Request and vice versa.  For example, since a
   CoA-Request only initiates an authorization change but does not
   initiate re-authentication, a RAR command containing a Re-Auth-
   Request-Type AVP with value "AUTHORIZE_AUTHENTICATE" cannot be
   directly translated to a CoA-Request.  A Diameter/RADIUS gateway
   receiving a CoA-Request containing authorization changes will need to
   translate this into two Diameter exchanges.  First, the
   Diameter/RADIUS gateway will issue a RAR command including a Session-
   Id AVP and a Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY".
   Then the Diameter/RADIUS gateway will respond to the ensuing access
   request with a response including the authorization attributes
   gleaned from the CoA-Request.  To enable translation, the CoA-Request
   SHOULD include a Acct-Session-Id Attribute.  If the  Diameter client
   uses the same Session-Id for both authorization and accounting, then
   the Diameter/RADIUS gateway can copy the contents of the Acct-
   Session-Id Attribute into the Session-Id AVP;  otherwise, it will
   need to map the Acct-Session-Id value to an equivalent Session-Id for
   use within a RAR command.

   Where an Acct-Session-Id attribute is not present in a CoA-Request or
   Disconnect-Request, a Diameter/RADIUS gateway will either need to
   determine the appropriate Acct-Session-Id, or if it cannot do so, it
   can send a CoA-NAK or Disconnect-NAK in reply, possibly including an
   Error-Cause Attribute with value 508 (Multiple Session Identification
   Unsupported).

   To simplify translation between RADIUS and Diameter, Dynamic
   Authorization Clients can include a Service-Type Attribute with value
   "Authorize Only" within a CoA-Request, as described in Section 3.2.
   A Diameter/RADIUS gateway receiving a CoA-Request containing a
   Service-Type with value "Authorize Only" translates this to a RAR
   with Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY".  The
   received RAA is then translated to a CoA-NAK with a Service-Type
   value of "Authorize Only".   If the Result-Code AVP in the RAA has a
   value in the success category, then an Error-Cause Attribute with
   value "Request Initiated" is included in the CoA-NAK.   If the
   Result-Code AVP in the RAA has a value indicating a Protocol Error or
   a Transient or Permanent Failure, then an alternate Error-Cause
   Attribute is returned as suggested below.

   Within Diameter, a server can request that a session be aborted by
   sending an Abort-Session-Request (ASR), identifying the session to be
   terminated using Session-ID and User-Name AVPs.  The ASR command is
   translated to a Disconnect-Request containing Acct-Session-Id and
   User-Name attributes.  If the Diameter client utilizes the same
   Session-Id in both authorization and accounting, then the value of
   the Session-ID AVP may be placed in the Acct-Session-Id attribute;
   otherwise the value of the Session-ID AVP will need to be mapped to
   an appropriate Acct-Session-Id value.   To enable translation of a
   Disconnect-Request to an ASR, an Acct-Session-Id attribute SHOULD be
   present.

   If the Diameter client utilizes the same Session-Id in both
   authorization and accounting, then the value of the Acct-Session-Id
   may be placed into the Session-ID AVP within the ASR;  otherwise the
   value of the Acct-Session-Id will need to be mapped to an appropriate
   Session-ID value.

   An Abort-Session-Answer (ASA) command is sent in response to an ASR
   in order to indicate the disposition of the request.  A
   Diameter/RADIUS gateway receiving a Disconnect-ACK translates this to
   an ASA command with a Result-Code AVP of "DIAMETER_SUCCESS".  A
   Disconnect-NAK received from the NAS is translated to an ASA command
   with a Result-Code AVP which depends on the value of the Error-Cause
   Attribute. =20

IANA considerations needs to request allocation of new Error-Cause Attribut=
e values:

5.  IANA Considerations

   This document uses the RADIUS [RFC2865] namespace, see
   .  In addition to the
   allocations already made in [RFC3575] and [RFC3576], this
   specification requests allocation of additional values of the Error-
   Cause Attribute (101):

    #    Value
   ---   -----
   407   Invalid Attribute Value
   508   Multiple Session Selection Unsupported

The changes need to be reflected in Appendix A:

   o Clarified expected behavior when session identification attributes
   match more than one session (Sections 2.3, 3, 3.5, 4).


________________________________
> From: bernard_aboba@hotmail.com
> To: radiusext@ops.ietf.org
> Subject: Issue 238: Identification of multiple sessions
> Date: Sun, 3 Jun 2007 19:51:07 -0700
>=20
> Issue 238: Identification of Multiple Sessions
> Submitter name: Bernard Aboba
> Submitter email address: aboba@internaut.com
> Date first submitted: June 3, 2007
> Reference:
> Document: RFC3576bis-07
> Comment type: Technical
> Priority: S
> Section: 3
> Rationale/Explanation of issue:
> It has been pointed out that the desired effect of including Session Iden=
tification attributes is to affect *all* sessions matching the attributes t=
hat are supplied.  For example, including a User-Name/CUI Attribute and not=
hing else in a Disconnect-Request should cause all sessions with that usern=
ame to be terminated.  However, currently Section 3 appears to make the beh=
avior undefined where more than one session can match the session identific=
ation attributes.  Rather than being "out of scope" it would seem that RFC =
3576bis should define the expected behavior.
> The proposed resolution is as follows:
> Change the following text in Section 2.3 from:
> "
>       State changes resulting from a CoA-Request MUST be atomic: if the
>       CoA-Request is successful, the Dynamic Authorization Server MUST
>       send a CoA-ACK in reply, and all requested authorization changes
>       MUST be made.  If the CoA-Request is unsuccessful, a CoA-NAK MUST
>       be sent in reply, and the requested authorization changes MUST NOT
>       be made.  Similarly, a state change MUST NOT occur as a result of
>       an unsuccessful Disconnect-Request; the Dynamic Authorization
>       Server MUST send a Disconnect-NAK in reply.
> "
> to:
> "
>       State changes resulting from a CoA-Request MUST be atomic: if the
>       CoA-Request is successful for all matching sessions, the Dynamic
>       Authorization Server MUST send a CoA-ACK in reply, and all
>       requested authorization changes MUST be made.  If the CoA-Request
>       is unsuccessful for any matching sessions, a CoA-NAK MUST
>       be sent in reply, and the requested authorization changes MUST NOT
>       be made for any of the matching sessions.  Similarly, a state chang=
e
>       MUST NOT occur as a result of a Disconnect-Request that is unsucces=
sful
>       with respect to any of the matching sessions; a Dynamic Authorizati=
on
>       Server MUST send a Disconnect-NAK in reply if any of the matching
>       sessions cannot be successfully terminated.
> "
> Change the following text in Section 3 from:
> "
>    In Disconnect-Request and CoA-Request packets, certain attributes are
>    used to uniquely identify the NAS as well as a user session on the
>    NAS.  All NAS identification attributes included in a Request packet
>    MUST match in order for a Disconnect-Request or CoA-Request to be
>    successful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent.
>    For session identification attributes, the User-Name and Acct-
>    Session-Id Attributes, if included, MUST match in order for a
>    Disconnect-Request or CoA-Request to be successful; other session
>    identification attributes SHOULD match.  Where a mismatch of session
>    identification attributes is detected, a Disconnect-NAK or CoA-NAK
>    SHOULD  be sent.
>    The ability to use NAS or session identification attributes to map to
>    unique/multiple sessions is beyond the scope of this document.
>    Identification attributes include NAS and session identification
>    attributes, as described below."
> To:
> "
>    In Disconnect-Request and CoA-Request packets, certain attributes are
>    used to uniquely identify the NAS as well as user session(s) on the
>    NAS.  All NAS and session identification identification attributes
>    included in a CoA-Request or Disconnect-Request packet MUST match
>    at least one session in order for a Request to be successful; otherwis=
e
>    a Disconnect-NAK or CoA-NAK MUST be sent.  If all NAS identification
>    attributes match and more than one session matches all of the
>    session identification attributes, then a CoA-Request or Disconnect-Re=
quest
>    MUST apply to all matching sessions.
>    Identification attributes include NAS and session identification
>    attributes, as described below."

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 04 Jun 2007 15:18:56 +0000
From: "David B. Nelson" <dnelson@elbrysnetworks.com>
To: <radiusext@ops.ietf.org>
Subject: RE: Determining WG consensus on Issue 226: RFC 3576bis and Renumbering
Date: Mon, 4 Jun 2007 11:17:05 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <003401c7a6bb$694eb710$5d1216ac@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AcemUF/oPCm7JmbiRNmZhOgxDy2QJwAak0Uw

> 1. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier =
attributes
> in Disconnect-Request & CoA-Request packets, only for =
identification.=A0
> Changing the address would require a Service-Type=3DAuthorize Only.=A0 =
This
> was what we had in -05.
>
> 2. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier =
attributes
> in Disconnect-Requests for identification.=A0 In CoA-Request packets =
allow=20
> them only for address change.=A0=20
>
> 3. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier =
address
> attributes in Disconnect-Request & CoA-Request packets only for =
address
> change.=A0 Invent new attributes for identification.=A0 This was =
initially
> proposed for -07.=20
>
> 4. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier =
address
> attributes in Disconnect-Request & CoA-Request packets only for
> identification.=A0 Invent new attributes for address change.=20
>
> 5. Prohibit use of =
Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier
> attributes for session identification.=A0 Permit their use only in =
CoA-
> Request packets, for use in address change.=A0 This is what we have in =
-07.=20

It seems to me that these options would apply equally to any attribute =
that
could be either (a) a session identifier attribute or (b) a session
re-authorization provisioning attribute.  This would include the use of
VSAs, as discussed in another message.

Right?



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 04 Jun 2007 15:10:55 +0000
From: "David B. Nelson" <dnelson@elbrysnetworks.com>
To: <radiusext@ops.ietf.org>
Subject: RE: Issue 238:  Identification of multiple sessions
Date: Mon, 4 Jun 2007 11:09:01 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <003301c7a6ba$487edcf0$5d1216ac@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcemU7Ctg342BxEYSTWbS7e2VSUpLgAZVOgw

> "
>      State changes resulting from a CoA-Request MUST be atomic: if the
>      CoA-Request is successful for all matching sessions, the Dynamic 
>      Authorization Server MUST send a CoA-ACK in reply, and all 
>      requested authorization changes MUST be made.  If the CoA-Request 
>      is unsuccessful for any matching sessions, a CoA-NAK MUST
>      be sent in reply, and the requested authorization changes MUST NOT
>      be made for any of the matching sessions.  Similarly, a state change 
>      MUST NOT occur as a result of a Disconnect-Request that is
>      Unsuccessful with respect to any of the matching sessions; a 
>      Dynamic Authorization Server MUST send a Disconnect-NAK in reply
>	if any of the matching sessions cannot be successfully terminated.
>"

That works. As I indicated in a previous reply, it leaves the Dynamic Access
Client wondering why it failed.  Since there may be a session that DAC
doesn't know about that is causing the failure, the DAC is left with only so
many options as to a course of corrective action.  It might retry the
request with a more specific set of session identification attributes.

I don't think solving this issue is within the scope of RFC3575bis, unless
we want to crate a new error code that indicates something about the session
that failed to be affected.

>" 
>   In Disconnect-Request and CoA-Request packets, certain attributes are
>   used to uniquely identify the NAS as well as user session(s) on the
>   NAS.  All NAS and session identification identification attributes 

s/identification identification/identification/

>   included in a CoA-Request or Disconnect-Request packet MUST match 
>   at least one session in order for a Request to be successful; otherwise 
>   a Disconnect-NAK or CoA-NAK MUST be sent.  If all NAS identification
>   attributes match and more than one session matches all of the 

s/match/match,/

>   session identification attributes, then a CoA-Request or Disconnect-
>   Request MUST apply to all matching sessions.
>
>   Identification attributes include NAS and session identification
>   attributes, as described below."


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 04 Jun 2007 14:59:56 +0000
From: "David B. Nelson" <dnelson@elbrysnetworks.com>
To: <radiusext@ops.ietf.org>
Subject: RE: Proposed Resolution of Issue 234:  Attribute Restriction
Date: Mon, 4 Jun 2007 10:58:08 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <003201c7a6b8$c35ec630$5d1216ac@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcemT8rlbc8A2fghSwSg7klV44+fvAAaNRRA

> "This Access-Request SHOULD contain the NAS identification
> attributes from the CoA-Request, as well as the session identification
> attributes from the CoA-Request permitted in an Access-Request; it also
> MAY contain other attributes permitted in an Access-Request."

Looks good.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 04 Jun 2007 14:57:08 +0000
From: "David B. Nelson" <dnelson@elbrysnetworks.com>
To: <radiusext@ops.ietf.org>
Subject: RE: RFC3576bis and Session State
Date: Mon, 4 Jun 2007 10:55:23 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <003101c7a6b8$60e1ea00$5d1216ac@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AcemTbag2S81VGazR7CfChBYIkhKIgAahn9w

Bernard Aboba writes...

> > All of this discussion leads me to believe we need a document
> > that describes the current state of affairs with the creation,
> > naming and modification of sessions, sub-sessions, multi-sessions
> > and the like in RADIUS deployments.  This could be a section of
> > RFC3576bis or it could be stand-alone document.
>
> Something like this might make sense, but I don't think it's required
> to be included in RFC 3576bis.

Perhaps not, except the extent that it's needed to implement what you
suggest next:

>=A0What we do need is clear text on the effect of including various=20
> session identification attributes in a CoA-Request/Disconnect-Request.

Agreed.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 04 Jun 2007 14:54:01 +0000
From: "David B. Nelson" <dnelson@elbrysnetworks.com>
To: <radiusext@ops.ietf.org>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Mon, 4 Jun 2007 10:51:12 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <003001c7a6b7$cb6ef120$5d1216ac@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AcemTYBiNeCt9mHWSCa0ilPuR4bcHQAaJh2Q

Bernard Aboba writes...

> [BA]=A0 RFC 3576 Section 3 says:
>   The ability to use NAS or session identification
>   attributes to map to unique/multiple sessions is beyond the scope
>   of this document. =20
>
> Therefore it isn't clear that sending a Disconnect-Request with a=20
> User-Name/CUI attribute will necessarily terminate *all* the user's
> sessions if there are more than one.

Right. The sentence you quote is troubling, IMHO.  We've been having a
discussion on the list that leads me to believe that implementers expect
some predictable, deterministic behavior from NASes in this area, i.e. =
when
the set of session identifier attributes can match more than one =
session.  I
believe some description of such behavior does need to be in RFC3576bis, =
and
that the "beyond the scope" statement no longer serves us well.
=20
> Do we need to say something like "all sessions matching the NAS &=20
> session identification attributes are affected by CoA/Disconnect-
> Requests?"

Something like that.

In another message, you touch on the need for atomicity of action, and =
the
requirement to report an error of any one of the matching sessions =
can=92t be
affected.  This probably doesn=92t happen often, but what is the Dynamic
RADIUS Client supposed to do in this case?   It can't know which =
matching
session is causing the failure at the NAS.  Does it try successively =
more
specific sets of session identification attributes until the request is
honored?


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 04 Jun 2007 03:26:28 +0000
Message-ID: <BAY117-W9642743CB5A43DA6D1A5C93210@phx.gbl>
Content-Type: multipart/alternative; boundary="_abe5b8c6-dcba-47fa-8407-b0a7e8b698c6_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <radiusext@ops.ietf.org>
Subject: Issue 239:  VSAs in Session Identication
Date: Sun, 3 Jun 2007 20:25:36 -0700
MIME-Version: 1.0

--_abe5b8c6-dcba-47fa-8407-b0a7e8b698c6_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Issue 239: VSAs in Session Identification
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: June 3, 2007
Reference:=20
Document: RFC3576bis-07
Comment type: Technical
Priority: S
Section: 3
Rationale/Explanation of issue:The question has arisen as to whether VSAs a=
re be allowed for use in session identification.   In looking at RFC 3576 (=
and 3576bis) the documents appear to contain contradictory information on w=
hether this is permitted or not. RFC 3576 Section 3 (or
RFC 3576bis) does not include VSAs for the purpose of session
identification.   However, in RFC 3576bis Section 3.6 VSAs are allowed in C=
oA-Request and Disconnect-Request packets.  This was also true in RFC 3576.=
 This is somewhat of a contradiction, because the inclusion of a VSA in a D=
isconnect-Request can have no purpose other than session identification.  W=
e can resolve this contradiction in one of the following ways:1. Prohibit i=
nclusion of VSAs within a Disconnect-Request OR2. Include VSAs in the list =
of Session Identification attributes. Opinions on these options are solicit=
ed. If we take option 2, the question arises as to the expected behavior of=
 a NAS receiving a VSA it does not support.   RFC 3576bis Section 2.3 says:=
       In Disconnect and CoA-Request packets, all attributes are treated   =
   as mandatory.This suggests that if a VSA is included, then if the NAS do=
es not understand it,it MUST send a Disconnect-NAK/CoA-NAK.This does create=
 a potential interoperability issue if a VSA is sent to a NAS thatdoes not =
support it.  However, it is not clear to me that an alternative exists. In =
a Disconnect-Request, then NAS can assume that the attribute is includedfor=
 the purpose of session identification, but if it does not support theattri=
bute it will not be able to determine which sessions (if any) are tobe disc=
onnected, since in Issue 238 we suggested that *all* session identification=
attributes MUST match (that would include VSAs, too). In a CoA-Request, VSA=
s could be session identification or authorization changeattributes.  Unles=
s the NAS supports the VSA it will not know which use isintended.  Therefor=
e it seems like it also must reply with a CoA-NAK if a VSA is unsupported. =

--_abe5b8c6-dcba-47fa-8407-b0a7e8b698c6_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
Issue 239: VSAs in Session Identification<br>
Submitter name: Bernard Aboba<br>
Submitter email address: aboba@internaut.com<br>
Date first submitted: June 3, 2007<br>
Reference: <br>
Document: RFC3576bis-07<br>
Comment type: Technical<br>
Priority: S<br>
Section: 3<br>
Rationale/Explanation of issue:<br><br>The question has arisen as to whethe=
r VSAs are be allowed for use in session identification.&nbsp;&nbsp; In loo=
king at RFC 3576 (and 3576bis) the documents appear to contain contradictor=
y information on whether this is permitted or not. <br><span class=3D"EC_66=
6361715-29052007"><br>RFC 3576 Section 3 (or
RFC 3576bis) does not include VSAs for the purpose of session
identification.&nbsp;&nbsp; However, in RFC 3576bis Section 3.6 VSAs are al=
lowed in CoA-Request and Disconnect-Request packets.&nbsp; This was also tr=
ue in RFC 3576. This is somewhat of a contradiction, because the inclusion =
of a VSA in a Disconnect-Request can have no purpose other than session ide=
ntification.&nbsp; <br><br>We can resolve this contradiction in one of the =
following ways:<br><br>1. Prohibit inclusion of VSAs within a Disconnect-Re=
quest OR<br>2. Include VSAs in the list of Session Identification attribute=
s. <br><br>Opinions on these options are solicited. <br><br>If we take opti=
on 2, the question arises as to the expected behavior of a NAS receiving a =
VSA it does not support.&nbsp;&nbsp; RFC 3576bis Section 2.3 says: <br></sp=
an><pre>      In Disconnect and CoA-Request packets, all attributes are tre=
ated<br>      as mandatory.<br><br>This suggests that if a VSA is included,=
 then if the NAS does not understand it,<br>it MUST send a Disconnect-NAK/C=
oA-NAK.<br><br>This does create a potential interoperability issue if a VSA=
 is sent to a NAS that<br>does not support it.  However, it is not clear to=
 me that an alternative exists. <br>In a Disconnect-Request, then NAS can a=
ssume that the attribute is included<br>for the purpose of session identifi=
cation, but if it does not support the<br>attribute it will not be able to =
determine which sessions (if any) are to<br>be disconnected, since in Issue=
 238 we suggested that *all* session identification<br>attributes MUST matc=
h (that would include VSAs, too). <br><br><br>In a CoA-Request, VSAs could =
be session identification or authorization change<br>attributes.  Unless th=
e NAS supports the VSA it will not know which use is<br>intended.  Therefor=
e it seems like it also must reply with a CoA-NAK if a <br>VSA is unsupport=
ed. <br></pre><br></body>
</html>=

--_abe5b8c6-dcba-47fa-8407-b0a7e8b698c6_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 04 Jun 2007 02:51:35 +0000
Message-ID: <BAY117-W281D9895E4ECA0D30715293210@phx.gbl>
Content-Type: multipart/alternative; boundary="_6733c9df-fdbe-4694-b7fb-e9b18b7ea519_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <radiusext@ops.ietf.org>
Subject: Issue 238:  Identification of multiple sessions
Date: Sun, 3 Jun 2007 19:51:07 -0700
MIME-Version: 1.0

--_6733c9df-fdbe-4694-b7fb-e9b18b7ea519_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Issue 238: Identification of Multiple Sessions
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: June 3, 2007
Reference:=20
Document: RFC3576bis-07
Comment type: Technical
Priority: S
Section: 3
Rationale/Explanation of issue:It has been pointed out that the desired eff=
ect of including Session Identification attributes is to affect *all* sessi=
ons matching the attributes that are supplied.  For example, including a Us=
er-Name/CUI Attribute and nothing else in a Disconnect-Request should cause=
 all sessions with that username to be terminated.  However, currently Sect=
ion 3 appears to make the behavior undefined where more than one session ca=
n match the session identification attributes.  Rather than being "out of s=
cope" it would seem that RFC 3576bis should define the expected behavior. T=
he proposed resolution is as follows:Change the following text in Section 2=
.3 from:"      State changes resulting from a CoA-Request MUST be atomic: i=
f the      CoA-Request is successful, the Dynamic Authorization Server MUST=
      send a CoA-ACK in reply, and all requested authorization changes     =
 MUST be made.  If the CoA-Request is unsuccessful, a CoA-NAK MUST      be =
sent in reply, and the requested authorization changes MUST NOT      be mad=
e.  Similarly, a state change MUST NOT occur as a result of      an unsucce=
ssful Disconnect-Request; the Dynamic Authorization      Server MUST send a=
 Disconnect-NAK in reply."to:"      State changes resulting from a CoA-Requ=
est MUST be atomic: if the      CoA-Request is successful for all matching =
sessions, the Dynamic       Authorization Server MUST send a CoA-ACK in rep=
ly, and all       requested authorization changes MUST be made.  If the CoA=
-Request       is unsuccessful for any matching sessions, a CoA-NAK MUST   =
   be sent in reply, and the requested authorization changes MUST NOT      =
be made for any of the matching sessions.  Similarly, a state change       =
MUST NOT occur as a result of a Disconnect-Request that is unsuccessful    =
  with respect to any of the matching sessions; a Dynamic Authorization    =
  Server MUST send a Disconnect-NAK in reply if any of the matching      se=
ssions cannot be successfully terminated."Change the following text in Sect=
ion 3 from:"   In Disconnect-Request and CoA-Request packets, certain attri=
butes are   used to uniquely identify the NAS as well as a user session on =
the   NAS.  All NAS identification attributes included in a Request packet =
  MUST match in order for a Disconnect-Request or CoA-Request to be   succe=
ssful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent.   For session =
identification attributes, the User-Name and Acct-   Session-Id Attributes,=
 if included, MUST match in order for a   Disconnect-Request or CoA-Request=
 to be successful; other session   identification attributes SHOULD match. =
 Where a mismatch of session   identification attributes is detected, a Dis=
connect-NAK or CoA-NAK   SHOULD  be sent.   The ability to use NAS or sessi=
on identification attributes to map to   unique/multiple sessions is beyond=
 the scope of this document.   Identification attributes include NAS and se=
ssion identification   attributes, as described below."To:
"
   In Disconnect-Request and CoA-Request packets, certain attributes are   =
used to uniquely identify the NAS as well as user session(s) on the   NAS. =
 All NAS and session identification identification attributes    included i=
n a CoA-Request or Disconnect-Request packet MUST match    at least one ses=
sion in order for a Request to be successful; otherwise    a Disconnect-NAK=
 or CoA-NAK MUST be sent.  If all NAS identification   attributes match and=
 more than one session matches all of the    session identification attribu=
tes, then a CoA-Request or Disconnect-Request   MUST apply to all matching =
sessions.   Identification attributes include NAS and session identificatio=
n   attributes, as described below."

--_6733c9df-fdbe-4694-b7fb-e9b18b7ea519_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
Issue 238: Identification of Multiple Sessions<br>
Submitter name: Bernard Aboba<br>
Submitter email address: aboba@internaut.com<br>
Date first submitted: June 3, 2007<br>
Reference: <br>
Document: RFC3576bis-07<br>
Comment type: Technical<br>
Priority: S<br>
Section: 3<br>
Rationale/Explanation of issue:<br><br>It has been pointed out that the des=
ired effect of including Session Identification attributes is to affect *al=
l* sessions matching the attributes that are supplied.&nbsp; For example, i=
ncluding a User-Name/CUI Attribute and nothing else in a Disconnect-Request=
 should cause all sessions with that username to be terminated.&nbsp; Howev=
er, currently Section 3 appears to make the behavior undefined where more t=
han one session can match the session identification attributes.&nbsp; Rath=
er than being "out of scope" it would seem that RFC 3576bis should define t=
he expected behavior. <br><br>The proposed resolution is as follows:<br><br=
>Change the following text in Section 2.3 from:<br><br>"<pre>      State ch=
anges resulting from a CoA-Request MUST be atomic: if the<br>      CoA-Requ=
est is successful, the Dynamic Authorization Server MUST<br>      send a Co=
A-ACK in reply, and all requested authorization changes<br>      MUST be ma=
de.  If the CoA-Request is unsuccessful, a CoA-NAK MUST<br>      be sent in=
 reply, and the requested authorization changes MUST NOT<br>      be made. =
 Similarly, a state change MUST NOT occur as a result of<br>      an unsucc=
essful Disconnect-Request; the Dynamic Authorization<br>      Server MUST s=
end a Disconnect-NAK in reply.<br></pre>"<br><br>to:<br><br>"<pre>      Sta=
te changes resulting from a CoA-Request MUST be atomic: if the<br>      CoA=
-Request is successful for all matching sessions, the Dynamic <br>      Aut=
horization Server MUST send a CoA-ACK in reply, and all <br>      requested=
 authorization changes MUST be made.  If the CoA-Request <br>      is unsuc=
cessful for any matching sessions, a CoA-NAK MUST<br>      be sent in reply=
, and the requested authorization changes MUST NOT<br>      be made for any=
 of the matching sessions.  Similarly, a state change <br>      MUST NOT oc=
cur as a result of a Disconnect-Request that is unsuccessful<br>      with =
respect to any of the matching sessions; a Dynamic Authorization<br>      S=
erver MUST send a Disconnect-NAK in reply if any of the matching<br>      s=
essions cannot be successfully terminated.<br></pre>"<br><br>Change the fol=
lowing text in Section 3 from:<br><br>"<pre>   In Disconnect-Request and Co=
A-Request packets, certain attributes are<br>   used to uniquely identify t=
he NAS as well as a user session on the<br>   NAS.  All NAS identification =
attributes included in a Request packet<br>   MUST match in order for a Dis=
connect-Request or CoA-Request to be<br>   successful; otherwise a Disconne=
ct-NAK or CoA-NAK SHOULD be sent.<br>   For session identification attribut=
es, the User-Name and Acct-<br>   Session-Id Attributes, if included, MUST =
match in order for a<br>   Disconnect-Request or CoA-Request to be successf=
ul; other session<br>   identification attributes SHOULD match.  Where a mi=
smatch of session<br>   identification attributes is detected, a Disconnect=
-NAK or CoA-NAK<br>   SHOULD  be sent.<br><br>   The ability to use NAS or =
session identification attributes to map to<br>   unique/multiple sessions =
is beyond the scope of this document.<br>   Identification attributes inclu=
de NAS and session identification<br>   attributes, as described below."<br=
></pre><br>To:<br><br><br>
"
<pre>   In Disconnect-Request and CoA-Request packets, certain attributes a=
re<br>   used to uniquely identify the NAS as well as user session(s) on th=
e<br>   NAS.  All NAS and session identification identification attributes =
<br>   included in a CoA-Request or Disconnect-Request packet MUST match <b=
r>   at least one session in order for a Request to be successful; otherwis=
e <br>   a Disconnect-NAK or CoA-NAK MUST be sent.  If all NAS identificati=
on<br>   attributes match and more than one session matches all of the <br>=
   session identification attributes, then a CoA-Request or Disconnect-Requ=
est<br>   MUST apply to all matching sessions.<br><br>   Identification att=
ributes include NAS and session identification<br>   attributes, as describ=
ed below."<br></pre>
</body>
</html>=

--_6733c9df-fdbe-4694-b7fb-e9b18b7ea519_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 04 Jun 2007 02:28:04 +0000
Message-ID: <BAY117-W103726FB2BBBE968E7757493210@phx.gbl>
Content-Type: multipart/alternative; boundary="_fd1ac3e4-3090-417c-8c82-cb3846f547b1_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <radiusext@ops.ietf.org>
Subject: Determining WG consensus on Issue 226: RFC 3576bis and Renumbering
Date: Sun, 3 Jun 2007 19:27:44 -0700
MIME-Version: 1.0

--_fd1ac3e4-3090-417c-8c82-cb3846f547b1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


We have been discussing this issue for a while.  The time has come to lay o=
ut the potential solutions and get a sense of the WG consensus on this issu=
e. In preparation for determining WG consensus, I'd like to articulate the =
potential choices for resolving this issue, then attempt to determine wheth=
er there is a "rough consensus". Here is what I have so far:1. Allow
Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier attributes in
Disconnect-Request & CoA-Request packets, only for
identification.   Changing the address would require a
Service-Type=3DAuthorize Only.  This was what we had in -05.2.
Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier attributes
in Disconnect-Requests for identification.  In CoA-Request packets
allow them only for address change.  3. Allow Framed-IP-Address/Framed-IPv6=
-Prefix/Framed-Identifier
address attributes in Disconnect-Request & CoA-Request packets only
for address change.  Invent new attributes for identification.  This
was initially proposed for -07. 4. Allow Framed-IP-Address/Framed-IPv6-Pref=
ix/Framed-Identifier
address attributes in Disconnect-Request & CoA-Request packets only
for identification.  Invent new attributes for address change. 5. Prohibit =
use of Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier
attributes for session identification.  Permit their use only in
CoA-Request packets, for use in address change.  This is what we have
in -07. Are there any more potential solutions? =

--_fd1ac3e4-3090-417c-8c82-cb3846f547b1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
We have been discussing this issue for a while.&nbsp; The time has come to =
lay out the potential solutions and get a sense of the WG consensus on this=
 issue. <br><br>In preparation for determining WG consensus, I'd like to ar=
ticulate the potential choices for resolving this issue, then attempt to de=
termine whether there is a "rough consensus". <br><br>Here is what I have s=
o far:<span class=3D"EC_666361715-29052007"><br><br>1. Allow
Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier attributes in
Disconnect-Request &amp; CoA-Request packets, only for
identification.&nbsp;&nbsp; Changing the address would require a
Service-Type=3DAuthorize Only.&nbsp; This was what we had in -05.<br><br>2.
Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier attributes
in Disconnect-Requests for identification.&nbsp; In CoA-Request packets
allow them only for address change.&nbsp; <br><br>3. Allow </span><span cla=
ss=3D"EC_666361715-29052007">Framed-IP-Address/Framed-IPv6-Prefix/Framed-Id=
entifier</span><span class=3D"EC_666361715-29052007">
address attributes in Disconnect-Request &amp; CoA-Request packets only
for address change.&nbsp; Invent new attributes for identification.&nbsp; T=
his
was initially proposed for -07. <br><br></span><span class=3D"EC_666361715-=
29052007">4. Allow </span><span class=3D"EC_666361715-29052007">Framed-IP-A=
ddress/Framed-IPv6-Prefix/Framed-Identifier</span><span class=3D"EC_6663617=
15-29052007">
address attributes in Disconnect-Request &amp; CoA-Request packets only
for identification.&nbsp; Invent new attributes for address change. <br><br=
>5. Prohibit use of </span><span class=3D"EC_666361715-29052007">Framed-IP-=
Address/Framed-IPv6-Prefix/Framed-Identifier</span><span class=3D"EC_666361=
715-29052007">
attributes for session identification.&nbsp; Permit their use only in
CoA-Request packets, for use in address change.&nbsp; This is what we have
in -07. <br><br>Are there any more potential solutions? </span><br></body>
</html>=

--_fd1ac3e4-3090-417c-8c82-cb3846f547b1_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 04 Jun 2007 02:23:19 +0000
Message-ID: <BAY117-W1980EED1E001F0B29508C493210@phx.gbl>
Content-Type: multipart/alternative; boundary="_cb92e110-a4a3-47ec-9f0a-2c9b16f5c15d_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <radiusext@ops.ietf.org>
Subject: Proposed Resolution of Issue 234:  Attribute Restriction
Date: Sun, 3 Jun 2007 19:22:49 -0700
MIME-Version: 1.0

--_cb92e110-a4a3-47ec-9f0a-2c9b16f5c15d_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


To address Avi's concern, I propose that the following sentence in Section =
3.2"   This Access-Request SHOULD contain the NAS   identification attribut=
es from the CoA-Request, as well as the   session identification attributes=
 from the CoA-Request legal for   inclusion in an Access-Request as specifi=
ed in [RFC2865], [RFC2868],   [RFC2869] and [RFC3162]."be changed to:"This =
Access-Request SHOULD contain the NAS identificationattributes from the CoA=
-Request, as well as the session identificationattributes from the CoA-Requ=
est permitted in an Access-Request; it alsoMAY contain other attributes per=
mitted in an Access-Request."=

--_cb92e110-a4a3-47ec-9f0a-2c9b16f5c15d_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
To address Avi's concern, I propose that the following sentence in Section =
3.2<br><br>"<pre>   This Access-Request SHOULD contain the NAS<br>   identi=
fication attributes from the CoA-Request, as well as the<br>   session iden=
tification attributes from the CoA-Request legal for<br>   inclusion in an =
Access-Request as specified in [RFC2865], [RFC2868],<br>   [RFC2869] and [R=
FC3162]."<br></pre><br>be changed to:<br><br>"This Access-Request SHOULD co=
ntain the NAS identification<br>attributes from the CoA-Request, as well as=
 the session identification<br>attributes from the CoA-Request permitted in=
 an Access-Request; it also<br>MAY contain other attributes permitted in an=
 Access-Request."<br></body>
</html>=

--_cb92e110-a4a3-47ec-9f0a-2c9b16f5c15d_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 04 Jun 2007 02:11:59 +0000
Message-ID: <BAY117-W22694B438042EA389605CD93210@phx.gbl>
Content-Type: multipart/alternative; boundary="_1ce30cba-9cb7-424b-a51a-886804f19a5a_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: "David B. Nelson" <dnelson@elbrysnetworks.com>, <radiusext@ops.ietf.org>
Subject: RE: RFC3576bis and Session State
Date: Sun, 3 Jun 2007 19:11:40 -0700
MIME-Version: 1.0

--_1ce30cba-9cb7-424b-a51a-886804f19a5a_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Something like this might make sense, but I don't think it's required to be=
 included in RFC 3576bis.  What we do need is clear text on the effect of i=
ncluding various session identification attributes in a CoA-Request/Disconn=
ect-Request. > From: dnelson@elbrysnetworks.com> To: radiusext@ops.ietf.org=
> Subject: RE: RFC3576bis and Session State> Date: Wed, 30 May 2007 16:45:2=
7 -0400> > All of this discussion leads me to believe we need a document th=
at describes> the current state of affairs with the creation, naming and mo=
dification of> sessions, sub-sessions, multi-sessions and the like in RADIU=
S deployments.> This could be a section of RFC3576bis or it could be stand-=
alone document.> > Do I recall that someone once attempted to write such a =
document?  Or am I> just remembering a long thread from the RADEXT list abo=
ut three or four> years ago?> > > > --> to unsubscribe send a message to ra=
diusext-request@ops.ietf.org with> the word 'unsubscribe' in a single line =
as the message text body.> archive: <http://psg.com/lists/radiusext/>=

--_1ce30cba-9cb7-424b-a51a-886804f19a5a_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
Something like this might make sense, but I don't think it's required to be=
 included in RFC 3576bis.&nbsp; What we do need is clear text on the effect=
 of including various session identification attributes in a CoA-Request/Di=
sconnect-Request. <br><br>&gt; From: dnelson@elbrysnetworks.com<br>&gt; To:=
 radiusext@ops.ietf.org<br>&gt; Subject: RE: RFC3576bis and Session State<b=
r>&gt; Date: Wed, 30 May 2007 16:45:27 -0400<br>&gt; <br>&gt; All of this d=
iscussion leads me to believe we need a document that describes<br>&gt; the=
 current state of affairs with the creation, naming and modification of<br>=
&gt; sessions, sub-sessions, multi-sessions and the like in RADIUS deployme=
nts.<br>&gt; This could be a section of RFC3576bis or it could be stand-alo=
ne document.<br>&gt; <br>&gt; Do I recall that someone once attempted to wr=
ite such a document?  Or am I<br>&gt; just remembering a long thread from t=
he RADEXT list about three or four<br>&gt; years ago?<br>&gt; <br>&gt; <br>=
&gt; <br>&gt; --<br>&gt; to unsubscribe send a message to radiusext-request=
@ops.ietf.org with<br>&gt; the word 'unsubscribe' in a single line as the m=
essage text body.<br>&gt; archive: &lt;http://psg.com/lists/radiusext/&gt;<=
br></body>
</html>=

--_1ce30cba-9cb7-424b-a51a-886804f19a5a_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: radiusext-data@psg.com
Delivery-date: Mon, 04 Jun 2007 02:11:09 +0000
Message-ID: <BAY117-W190699F6B48153B5853BEB93210@phx.gbl>
Content-Type: multipart/alternative; boundary="_1a109d7c-b44e-4d2c-9949-57d2f5a5719c_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Avi Lior <avi@bridgewatersystems.com>, Alan DeKok <aland@nitros9.org>
CC: "David B. Nelson" <dnelson@elbrysnetworks.com>, <radiusext@ops.ietf.org>, Bernard Aboba <bernarda@windows.microsoft.com>
Subject: RE: Issue 226:  RFC 3576bis and Renumbering
Date: Sun, 3 Jun 2007 19:10:09 -0700
MIME-Version: 1.0

--_1a109d7c-b44e-4d2c-9949-57d2f5a5719c_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> Sending a DM with an NAI or some=20
other user identification, we> terminate all of the users IP=20
sessions.[BA]  RFC 3576 Section 3 says:   The ability to use NAS or session=
 identification   attributes to map to unique/multiple sessions is beyond t=
he scope of   this document.  Therefore it isn't clear that sending a Disco=
nnect-Request with a User-Name/CUI attribute will necessarily terminate *al=
l* the user's sessions if there are more than one. Do we need to say someth=
ing like "all sessions matching the NAS & session identification attributes=
 are affected by CoA/Disconnect-Requests?"

[BA] Also, unless the NAS=20
previously received Framed-IP-Address or Framed-IPv6-Prefix/Framed-Interfac=
e-Id=20
attributes in an Access-Accept it typically will not know the user's IP=20
address.  This is the situation with most NAS-Port-Type values, with the=20
exception of PPP or protocols depending on PPP (e.g. PPPOE, PPPOA, L2TP, PP=
TP,=20
etc.)[Avi]  In most cases that I am aware of, the=20
NAS is the Point of Attachement to the internet and it knows the IP address=
(es)=20
assigned to the user. So it is IP Session aware.  In any case, there are=20
scenarios where it is IP session aware and it should be possible to make=20
modification to those Sessions using DM or COA using the IP address as the=
=20
Session Identifier.[BA] Where the NAS is a pure L2 device (e.g. IEEE 802 sw=
itch, 802.11 AP), it has no awareness of L3,  and so does not track the IP =
addresses of clients.  Where the NAS does track the IP address of clients, =
it would be possible to use IP address attributes for *either* identificati=
on *or* change, but not both in the same packet. So the choices are:1. Allo=
w Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier attributes in Disc=
onnect-Request & CoA-Request packets, only for identification.   Changing t=
he address would require a Service-Type=3DAuthorize Only.  This was what we=
 had in -05.2. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier=
 attributes in Disconnect-Requests for identification.  In CoA-Request pack=
ets allow them only for address change.  3. Allow Framed-IP-Address/Framed-=
IPv6-Prefix/Framed-Identifier address attributes in Disconnect-Request & Co=
A-Request packets only for address change.  Invent new attributes for ident=
ification.  This was previously proposed for -07. 4. Allow Framed-IP-Addres=
s/Framed-IPv6-Prefix/Framed-Identifier
address attributes in Disconnect-Request & CoA-Request packets only
for identification.  Invent new attributes for address change. 5. Prohibit =
use of Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier
attributes for session identification.  Permit their use only in CoA-Reques=
t packets, for use in address change.  This is what we have in -07. I think=
 this more or less describes the choices available on this issue.  Are ther=
e any more?=20

[Avi] Yes I agree that it "can" be=20
used.  But Alan seems to make it mandatory. And to mandatory require that=20
it be sent in the Access-Request packet.  I dont agree with=20
that.  I think if the deployement requires it to be in the access=20
request then it can be sent.  The current RFCs are fine.[BA] I don't think =
we can make it mandatory to include Acct-Session-Id/Acct-Multi-Session-Id. =
 But I would like to be clear about what other attributes MAY/SHOULD be inc=
luded, and what happens when they are included (e.g. how the NAS selects th=
e affected sessions).  Where only an Access-Request is=20
available, with no Acct-Session-Id, other session identification attributes=
 can=20
be used (NAS-Port/NAS-Port-Id, User-Name).  [Avi] Yes I agree and even=20
VSAs. [BA]  RFC 3576 Section 3 (or RFC 3576bis) does not include VSAs for t=
he purpose of session identification.   However, RFC 3576bis Section 2.3 do=
es say this:      Within this specification attributes can be used for     =
 identification, authorization or other purposes.  RADIUS Attribute      sp=
ecifications created after publication of this document SHOULD      state w=
hether an attribute can be included in CoA or Disconnect      messages and =
if so, which messages it can be included in and      whether it serves as a=
n identification or authorization attribute.I don't intrinsically see anyth=
ing wrong with using VSAs for session identification,assuming that they are=
 not required, and that sending them to a NAS which doesn'tsupport them gen=
erate an appropriate error message (e.g. 401 (Unsupported Attribute)). So m=
aybe we should add VSAs to the Session Identification list, as well as a pa=
ragraph stating that their use is optional. [BA] So=20
it's hard to imagine a case where the IP address is *required* as a session=
=20
identifier.   And there are quite a few situations in which the NAS=20
will be unable to identify the session by IP address.   Given this,=20
encouraging the use of the IP address as a session identifier seems like a =
bad=20
idea. [Avi] I agree that the IP Address is=20
not *required*.  I think that nothing should=20
be *required*  because different scenarios will use different=20
session identifiers.  Furthermore, I think they should be used in=20
combination.  For example, User-Name + Accounting Session Id to delete=20
the session associated with Accounting session id is better practice then j=
ust=20
using Accounting Session Id.  [BA]  RFC 3576 allows this, and RFC 3576bis d=
oes too.=20

--_1a109d7c-b44e-4d2c-9949-57d2f5a5719c_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
P
{
margin:0px;
padding:0px
}
body
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body>
<br>&gt; Sending a DM with an NAI or some=20
other user identification, we<br>&gt; terminate all of the users IP=20
sessions.<br><br>[BA]&nbsp; RFC 3576 Section 3 says:<blockquote><div><pre> =
  The ability to use NAS or session identification<br>   attributes to map =
to unique/multiple sessions is beyond the scope of<br>   this document.  <b=
r><br>Therefore it isn't clear that sending a Disconnect-Request with a Use=
r-Name/CUI attribute <br>will necessarily terminate *all* the user's sessio=
ns if there are more than one. <br><br>Do we need to say something like "al=
l sessions matching the NAS &amp; session <br>identification attributes are=
 affected by CoA/Disconnect-Requests?"<br></pre><span class=3D"EC_666361715=
-29052007"></span></div>

<div><span class=3D"EC_666361715-29052007">[BA]&nbsp;</span>Also, unless th=
e NAS=20
previously received Framed-IP-Address or Framed-IPv6-Prefix/Framed-Interfac=
e-Id=20
attributes in an Access-Accept it typically will not know the user's IP=20
address.&nbsp; This is the situation with most NAS-Port-Type values, with t=
he=20
exception of PPP or protocols depending on PPP (e.g. PPPOE, PPPOA, L2TP, PP=
TP,=20
etc.)<br><span class=3D"EC_666361715-29052007"></span><br><span class=3D"EC=
_666361715-29052007">[Avi]&nbsp;&nbsp;In most cases that I am aware of, the=
=20
NAS is the Point of Attachement to the internet and it knows the IP address=
(es)=20
assigned to the user. So it is IP Session aware.&nbsp; In any case, there a=
re=20
scenarios where it is IP session aware and it should be possible to make=20
modification to those Sessions using DM or COA using the IP address as the=
=20
Session Identifier.<br><br>[BA] Where the NAS is a pure L2 device (e.g. IEE=
E 802 switch, 802.11 AP), it has no awareness of L3,&nbsp; and so does not =
track the IP addresses of clients.&nbsp; <br><br>Where the NAS does track t=
he IP address of clients, it would be possible to use IP address attributes=
 for *either* identification *or* change, but not both in the same packet. =
<br><br>So the choices are:<br><br>1. Allow Framed-IP-Address/Framed-IPv6-P=
refix/Framed-Identifier attributes in Disconnect-Request &amp; CoA-Request =
packets, only for identification.&nbsp;&nbsp; Changing the address would re=
quire a Service-Type=3DAuthorize Only.&nbsp; This was what we had in -05.<b=
r><br>2. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier attri=
butes in Disconnect-Requests for identification.&nbsp; In CoA-Request packe=
ts allow them only for address change.&nbsp; <br><br>3. Allow </span><span =
class=3D"EC_666361715-29052007">Framed-IP-Address/Framed-IPv6-Prefix/Framed=
-Identifier</span><span class=3D"EC_666361715-29052007"> address attributes=
 in Disconnect-Request &amp; CoA-Request packets only for address change.&n=
bsp; Invent new attributes for identification.&nbsp; This was previously pr=
oposed for -07. <br><br></span><span class=3D"EC_666361715-29052007">4. All=
ow </span><span class=3D"EC_666361715-29052007">Framed-IP-Address/Framed-IP=
v6-Prefix/Framed-Identifier</span><span class=3D"EC_666361715-29052007">
address attributes in Disconnect-Request &amp; CoA-Request packets only
for identification.&nbsp; Invent new attributes for address change. <br><br=
>5. Prohibit use of </span><span class=3D"EC_666361715-29052007">Framed-IP-=
Address/Framed-IPv6-Prefix/Framed-Identifier</span><span class=3D"EC_666361=
715-29052007">
attributes for session identification.&nbsp; Permit their use only in CoA-R=
equest packets, for use in address change.&nbsp; This is what we have in -0=
7. <br><br>I think this more or less describes the choices available on thi=
s issue.&nbsp; Are there any more? <br></span><span class=3D"EC_666361715-2=
9052007"><br></span><span class=3D"EC_666361715-29052007"></span><span clas=
s=3D"EC_666361715-29052007"></span><br><span class=3D"EC_666361715-29052007=
"></span></div>

<div><span class=3D"EC_666361715-29052007">[Avi]&nbsp;Yes I agree that it&n=
bsp;"can" be=20
used.&nbsp; But Alan seems to make it mandatory. And to mandatory require t=
hat=20
it be sent in&nbsp;the&nbsp;Access-Request&nbsp;packet.&nbsp; I dont agree =
with=20
that.&nbsp; I think&nbsp;if the deployement requires it to be in the access=
=20
request then it can be sent.&nbsp;&nbsp;The current RFCs are fine.<br><br>[=
BA] I don't think we can make it mandatory to include Acct-Session-Id/Acct-=
Multi-Session-Id.&nbsp; But I would like to be clear about what other attri=
butes MAY/SHOULD be included, and what happens when they are included (e.g.=
 how the NAS selects the affected sessions).&nbsp; <br><br></span><br>Where=
 only an Access-Request is=20
available, with no Acct-Session-Id, other session identification attributes=
 can=20
be used (NAS-Port/NAS-Port-Id, User-Name).&nbsp; <br><span class=3D"EC_6663=
61715-29052007">[Avi]&nbsp;Yes I agree and even=20
VSAs. <br><br>[BA]&nbsp; RFC 3576 Section 3 (or RFC 3576bis) does not inclu=
de VSAs for the purpose of session identification.&nbsp;&nbsp; However, RFC=
 3576bis Section 2.3 does say this:<br><br></span><pre>      Within this sp=
ecification attributes can be used for<br>      identification, authorizati=
on or other purposes.  RADIUS Attribute<br>      specifications created aft=
er publication of this document SHOULD<br>      state whether an attribute =
can be included in CoA or Disconnect<br>      messages and if so, which mes=
sages it can be included in and<br>      whether it serves as an identifica=
tion or authorization attribute.<br><br>I don't intrinsically see anything =
wrong with using VSAs for session identification,<br>assuming that they are=
 not required, and that sending them to a NAS which doesn't<br>support them=
 generate an appropriate error message (e.g. 401 (Unsupported Attribute)). =
<br><br>So maybe we should add VSAs to the Session Identification list, as =
well as a paragraph <br>stating that their use is optional. <br></pre><span=
 class=3D"EC_666361715-29052007">[BA]&nbsp;</span>So=20
it's hard to imagine a case where the IP address is *required* as a session=
=20
identifier.&nbsp;&nbsp; And there are quite a few situations in which the N=
AS=20
will be unable to identify the session by IP address.&nbsp;&nbsp; Given thi=
s,=20
encouraging the use of the IP address as a session identifier seems like a =
bad=20
idea. <br><br><span class=3D"EC_666361715-29052007">[Avi] I agree that the =
IP Address is=20
not *required*.&nbsp; I think that nothing should=20
be&nbsp;*required*&nbsp;&nbsp;because different scenarios will use differen=
t=20
session identifiers.&nbsp;&nbsp;Furthermore, I think they should be used in=
=20
combination.&nbsp; For example, User-Name + Accounting Session Id&nbsp;to d=
elete=20
the session associated with Accounting session id is better practice then j=
ust=20
using&nbsp;Accounting Session Id.&nbsp; <br><br>[BA]&nbsp; RFC 3576 allows =
this, and RFC 3576bis does too. </span><br></div>
</blockquote></body>
</html>=

--_1a109d7c-b44e-4d2c-9949-57d2f5a5719c_--

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>