Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 30 Jun 2007 15:20:45 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_32aaaad7-8b63-4730-b12b-34f2f67cf518_" From: Bernard Aboba To: "David B. Nelson" , 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:= = --_32aaaad7-8b63-4730-b12b-34f2f67cf518_ Content-Type: text/html; 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: radiusext@ops.ietf.org
> Subject: RE: New version of RADIU= S WLAN document
> Date: Fri, 29 Jun 2007 13:54:17 -0400
>
&= gt; Is Allowed-Called-Station-ID a RADIUS String type or Text type? From t= he
> 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 bo= dy.
> archive: <http://psg.com/lists/radiusext/>
= --_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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 29 Jun 2007 17:56:46 +0000 From: "David B. Nelson" To: 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: 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: Thread-Topic: PRELIMINARY Agenda and Package for July 5, 2007 Telechat Thread-Index: Ace51bGZD3VD9TOARX+lQsp8kJaqbgAYHqBg From: "Romascanu, Dan (Dan)" To: , "Ops-Nm" , "Aaa-Doctors (E-mail)" , , , 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 29 Jun 2007 06:14:08 +0000 From: Stefan Winter 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: 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: From: David Mitton 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 > >Before then, it is available here: >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: 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" To: , 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 28 Jun 2007 01:20:10 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_3fa43b0f-3028-47da-9604-8cf551a27fd6_" From: Bernard Aboba To: 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
Issue 230 (RFC 4590bis Last Call Comments) is enclosed below.

The length of the Digest-Nonce-Count attribute has to include the Type and = Length fields, so that it is indeed 10, not 8.

Here is what RFC 2617 Section 3.2.2 says about nonce-count:

   nonce-count
     This MUST be specified= if a qop directive is sent (see above), and
     MU= ST 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 request= s (including the current request)
     that the clie= nt has sent with the nonce value in this request. For
  =    example, in the first request sent in response to a given nonc= e
     value, the client sends "nc=3D00000001". = ; The purpose of this
     directive is to allow the= server to detect request replays by
     maintainin= g its own copy of this count - if the same nc-value is
   = ; seen twice, then the request is a replay.   See the descr= iption
     below of the construction of the request= -digest value.

So all the examples (not just the first) in Section 6 do ind= eed appear to be illegal.

Also, the examples should supply the password so as to allow = ;for verification of the calculations.

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.

Issue 230: RFC 4590bis Last Call Comments
<= /B>Submitter name: Frank Ellermann
Submitter email address:
D= ate first submitted: May 18, 2007
Reference: http://ops= .ietf.org/lists/radiusext/2007/msg00287.html
Document: RF= C 4590bis-01
Comment type: Technical
Priority: S
Section: Various<= BR>Rationale/Explanation of issue:

Hi, this draft might be also interesting for the 2831bis (SASL) and
2617= bis (HTTP-AUTH) folks. From a quick read I found that the I-D
pick= ed the "keep backslash as is" approach between client and proxy,
trimmin= g \\ and \" only at the RADIUS server.

The other DIGEST-MD5 paramete= rs are as always confusing, I don't see
anything related to SASLprep in = the draft (it's based on 2617). It
mentions 2069 backwards compati= bility based on the absence of "QoP",
I'm not sure if that's correct for= "md5-sess" without "QoP".

The draft says that the length of NC is 1= 0, shouldn't that be 8 ?

The first example has no CNONCE and no NC, = my script claims that this
is a fatal error for qop=3Dauth, isn't it ?&n= bsp; RFC 2617 says that it MUST
be sent for a non-empty qop.

The = password for the 4590 examples isn't shown, therefore I'm unable
to chec= k them, even after adjusting the code to treat qop=3Dauth without
CNONCE= as 2069 fallback. Should I treat CNONCE as empty and make up
an N= C 00000001 ?

Without SASLprep the draft IMO needs some "I18N conside= rations" about
non-ASCII user names and passwords as mandated by BCP 18 = (RFC 2277).
Proposed Resolution: Discuss
= --_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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 28 Jun 2007 00:35:51 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_de188002-88f0-4e1c-9c9c-5ba703f34a7f_" From: Bernard Aboba To: 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 The RADEXT WG last call on RFC 3576bis-08 has concluded.

No comments were received, and there are no open issues with respect to thi= s document.

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_-- -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 28 Jun 2007 00:34:55 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_fca386b0-13fe-45f5-bc04-cbb979953eab_" From: Bernard Aboba To: 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 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<= BR>
Before then, it is available here:
http://www.drizzle.com/~aboba/RADEXT/draft-aboba-radext-wlan-04.txt

Comments welcome.
= --_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: 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 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: 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: 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 19 Jun 2007 20:12:16 +0000 From: "David B. Nelson" To: 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 19 Jun 2007 18:58:00 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_33be9c01-00d4-42fa-ad2e-7f76505b3e7c_" From: Bernard Aboba To: "David B. Nelson" , 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 > 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 t= hat such mappings would
> always pertain.
>
> Are you attempting to signal device functionality (end node vs. mesh p= oint)
> or signal the use of a particular EAP method?

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.

Both of these examples involve features of the EAP lower layer. Howev= er,
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).
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).

= --_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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 19 Jun 2007 17:50:11 +0000 From: "David B. Nelson" To: 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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 19 Jun 2007 17:41:17 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_f3be5e43-88b1-4151-a53a-b68f9b3b26bf_" From: Bernard Aboba To: "David B. Nelson" , 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
> That's a good example. Are you thinking that there should be a dis= tinct
> NAS-Port-Type for Wireless Mesh Point?

I think not, because the port type for 11s would still be IEEE 802.11. = ;

One possibility is to define an "EAP-Medium" Attribute that would prov= ide information on the EAP lower layer, such as:

      1 - Wired IEEE 802.1X Version 1 (2001)=
      2 - Wired IEEE 802.1X Version 2 (2= 004)
      3 - WPA
   &= nbsp; 4 - WPA2 (non pre-authentication)
   &n= bsp; 5 - WPA2: IEEE 802.1X pre-authentication
  &n= bsp;   6 - IEEE 802.11r
      7= - IEEE 802.11s
      8 - IEEE 802.= 11af
      9 - IEEE 802.16e
&nbs= p;    10 - IKEv2
      11 - PPP<= BR>      12 - PANA

= --_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: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 19 Jun 2007 14:25:18 +0000 From: "David B. Nelson" To: 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 18 Jun 2007 23:24:13 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_a807c73d-ca80-41af-b4b6-f6f0848df36a_" From: Bernard Aboba To: "David B. Nelson" , 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
> This goes back to the "network selection" problem, and the discuss= ion of
> using NAS-Port-Type for that purpose. If all RADIUS ever see= s 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.

I think it does matter, in the case of 11s vs. 11i, for example. Ther= e 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 Point may be quite
small compared to those authorized to act as a station. So if the use= r were 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_-- -- 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: 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: Thread-Topic: Submission cut-off dates before Chicago Thread-Index: Acex2PmEtxbDklB8TrC3YaXjv/x7Yw== From: "Romascanu, Dan (Dan)" To: , , "Netconf (E-mail)" , , , , , 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 18 Jun 2007 15:19:03 +0000 From: "David B. Nelson" To: 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 18 Jun 2007 04:33:22 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_e5948c01-2c84-4686-b964-11df20fad8d6_" From: Bernard Aboba To: 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
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.

Some questions raised by the feedback include:

a. What is a NAS-Port-Type anyway? 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). So my answer is that it represents link type information that a R= ADIUS server administrator will find useful.

b. What is the appropriate granularity for NAS-Port-Type? 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).

c. How should we handle 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.).   So = how does a NAS indicate that 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? Allocating a NAS-Port-Type value does not s= eem like a good fit for that kind of differentiation.

> -----Original Message-----
> From: Glen Kramer [mailto:glen.kram= er@teknovus.com]
> Sent: Wednesday, June 13, 2007 5:04 PM
> To= : Pat Thaler
> Cc: Congdon, Paul T (ProCurve); Grow, Bob; David Law; = Steve Carlson;
> Wael Diab
> Subject: RE: [802.1 - 2683] FW: [I= ANA #85318] request a new
> NAS-Port-Type for XPON
>
> P= at,
>
> Is this a formal liaison request? .3av focuses on PHY = and I am not sure
> we have the right expertise in our group to answe= r this. I think MacSec
> may be a better place to get a meaningful re= sponse.
>
> Unofficially, I asked an engineer in my company fo= r his opinion. Here it
> is:
>
> ***
> This field = isn't really a functional part of the protocol. It's just
> managemen= t 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 sure why a RADIUS server would care in the first place.
>= ; But given that there's a list of 34 possible port types, it makes sense> to add one (or more) for PON.
>
> It may be that peopl= e will want to distinguish various types of 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
> really 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 value as a 32-bit field. This isn't big enough for a MAC
> ad= dress. But since the logical links are virtual and dynamically
> assi= gned, it doesn't make lots 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 nothing useful you can provision or chec= k on
> the server side; so, it doesn't really matter what the value i= s, 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 v= irtual ports
> multiplexed over some transport medium. Perhaps it's e= nough to realize
> that port type "xPON" means that the port number w= on't have lasting
> value.)
> ***
>
> Let me know,= if anything is required from .3av in this regard.
>
> Glen
> From: EffenbergerFrank 73695 [mailto:feffenberger@huawei.com]
> = Sent: Wednesday, June 13, 2007 11:23 AM
> To: Linda Dunbar
> Su= bject: Re: FW: [802.1 - 2683] FW: [IANA #85318] request a new
> NAS-P= ort-Type for XPON
>
> If I look up the currently defined list = of values for NAS-port-type, I
> find:
>
> Values for RA= DIUS Attribute 61, NAS-Port-Type [RFC2865]:
>
> 0 Async
>= ; 1 Sync
> 2 ISDN Sync
> 3 ISDN Async V.120
> 4 ISDN Asyn= c V.110
> 5 Virtual
> 6 PIAFS
> 7 HDLC Clear Channel
&= gt; 8 X.25
> 9 X.75
> 10 G.3 Fax
> 11 SDSL - Symmetric DS= L
> 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase
>= Modulation
> 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone
&g= t; 14 IDSL - ISDN Digital Subscriber Line
> 15 Ethernet
> 16 xD= SL - Digital Subscriber Line of unknown type
> 17 Cable
> 18 Wi= reless - Other
> 19 Wireless - IEEE 802.11
> 20 Token-Ring [RFC= 3580]
> 21 FDDI [RFC3580]
> 22 Wireless - CDMA2000 [McCann]
= > 23 Wireless - UMTS [McCann]
> 24 Wireless - 1X-EV [McCann]
&g= t; 25 IAPP [IEEE 802.11f][Kerry]
> 26 FTTP - Fiber to the Premises [N= yce]
> 27 Wireless - IEEE 802.16 [IEEE 802.16]
> 28 Wireless - = IEEE 802.20 [IEEE 802.20]
> 29 Wireless - IEEE 802.22 [IEEE 802.22]&n= bsp;
> 30 PPPoA - PPP over ATM [RFC4603]
> 31 PPPoEoA - PPP ove= r Ethernet over ATM [RFC4603]
> 32 PPPoEoE - PPP over Ethernet over E= thernet [RFC4603]
> 33 PPPoEoVLAN - PPP over Ethernet over VLAN [RFC4= 603]
> 34 PPPoEoQinQ - PPP over Ethernet over IEEE 802.1QinQ [RFC4603= ]
>
> 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...
>
> = You might mention that observation, and ask for some more clarification.>
>
> Sincerely,
> Frank E.

= --_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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 14 Jun 2007 03:58:48 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_17999de4-01f3-4c43-b87b-8376147265a8_" From: Bernard Aboba To: 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 Here is another comment.

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

= --_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: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 14 Jun 2007 03:58:07 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_ce255e12-182b-4d42-a87d-c6b0256f472b_" From: Bernard Aboba To: 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 Paul Congdon forwarded the IANA request to IEEE 802.1 for comment. He= re is one of the comments that came back.

> -----Original Message-----
> From: Glen Kramer [mailto:glen.kram= er@teknovus.com]
> Sent: Wednesday, June 13, 2007 5:04 PM
> To= : Pat Thaler
> Cc: Congdon, Paul T (ProCurve); Grow, Bob; David Law; = Steve Carlson;
> Wael Diab
> Subject: RE: [802.1 - 2683] FW: [I= ANA #85318] request a new
> NAS-Port-Type for XPON
>
> P= at,
>
> Is this a formal liaison request? .3av focuses on PHY = and I am not sure
> we have the right expertise in our group to answe= r this. I think MacSec
> may be a better place to get a meaningful re= sponse.
>
> Unofficially, I asked an engineer in my company fo= r his opinion. Here it
> is:
>
> ***
> This field = isn't really a functional part of the protocol. It's just
> managemen= t 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 sure why a RADIUS server would care in the first place.
>= ; But given that there's a list of 34 possible port types, it makes sense> to add one (or more) for PON.
>
> It may be that peopl= e will want to distinguish various types of 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
> really 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 value as a 32-bit field. This isn't big enough for a MAC
> ad= dress. But since the logical links are virtual and dynamically
> assi= gned, it doesn't make lots 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 nothing useful you can provision or chec= k on
> the server side; so, it doesn't really matter what the value i= s, 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 v= irtual ports
> multiplexed over some transport medium. Perhaps it's e= nough to realize
> that port type "xPON" means that the port number w= on'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 Beh= alf Of Congdon, Paul T (ProCurve)
> > Sent: Wednesday, June 13, 20= 07 5:29 AM
> > To: STDS-802-1-L@listserv.ieee.org
> > Sub= ject: [802.1 - 2683] FW: [IANA #85318] request a new NAS-Port-Type
>= > for XPON
> >
> > Would anyone from IEEE 802.1 like= to provide a comment here or perhaps
>
> > pass onto the a= ppropriate 802.3 contacts. The Radius group could
> > benefit fro= m a description of how this port-type might be used in AAA
> > ex= changes.
> >
> > 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
> > Subject: FW: [IANA #853= 18] request a new NAS-Port-Type for XPON
> >
> >
>= ; > IANA has received a request for allocation of a NAS-Port-Type value<= BR>> for
> > XPON. 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
> > > IANA
> > >
> &= gt; > On Mon Jun 11 19:57:38 2007, Renxiang.Yan@alcatel-sbell.com.cn
= > wrote:
> > > > Dear editor,
> > > >
&= gt; > > > We believed it lacks a RADIUS NAS-Port-Type for PON (Pas= sive
> Optical
> > > > Network) access.
> > &= gt; > http://www.iana.org/assignments/radius-types
> > > >= ;
> > > > Could you please check and allocate one for it?> > > >
> > > > Recommended value:
> >= > > ----------------------------------------------------------
&g= t; > > > value description
> > > > 35 xPON - Passiv= e Optical Network
> > > > ----------------------------------= --------------------------
> > > >
> > > > (x= PON 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_-- -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 13 Jun 2007 14:24:52 +0000 From: "David B. Nelson" To: 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 13 Jun 2007 14:20:11 +0000 From: "David B. Nelson" To: 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: 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 User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "David B. Nelson" 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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 13 Jun 2007 13:14:45 +0000 From: "David B. Nelson" To: 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: 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 User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Glen Zorn (gwz)" 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: 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$" To: "Bernard Aboba" Cc: 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 |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
IANA has received a request for allocation = of a=20 NAS-Port-Type value for XPON.   Comments?
I = had no idea=20 anyone was actually using PON for access. Learn something new = every=20 day.

> Subject: [IANA #85318] request a = new=20 NAS-Port-Type for XPON
> From: = iana-prot-param-comment@icann.org
>=20 CC: bernard_aboba@hotmail.com
> Date: Tue, 12 Jun 2007 12:47:07=20 -0700
>
> Dear Bernard,
>
> Can you advise on = this=20 request for a new NAS-Port-Type value?
>
> Thanks,
> =
>=20 Amanda Baber
> IANA
>
> On Mon Jun 11 19:57:38 2007,=20 Renxiang.Yan@alcatel-sbell.com.cn wrote:
> > Dear = editor,
> >=20
> > We believed it lacks a RADIUS NAS-Port-Type for PON = (Passive=20 Optical
> > Network) access.
> >=20 http://www.iana.org/assignments/radius-types
> >
> > = Could=20 you please check and allocate one for it?
> >
> > = Recommended=20 value:
> >=20 ----------------------------------------------------------
> > = value=20 description
> > 35 xPON - Passive Optical Network
> >=20 ------------------------------------------------------------
> = >=20
> > (xPON may cover: Broadband PON (B-PON/G.983.x), Gigabit=20 PON
> > (G-PON/G.984.x), and Ethernet PON (E-PON/IEEE = 802.3ah).)=20
> >
> > Kindly regards,
> >
> >=20 Renxiang
> >
> >
>
>
>=20
------_=_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: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 13 Jun 2007 03:37:28 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_3031a5aa-dec3-4f8e-8ff0-d46fe95e45b2_" From: Bernard Aboba To: 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 IANA has received a request for allocation of a NAS-Port-Type value for XPO= N.   Comments?

> Subject: [IANA #85318] request a n= ew NAS-Port-Type for XPON
> From: iana-prot-param-comment@icann.org<= br>> 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
> IANA
>
> On Mon Jun 11 19:57:3= 8 2007, Renxiang.Yan@alcatel-sbell.com.cn wrote:
> > Dear editor,<= br>> >
> > We believed it lacks a RADIUS NAS-Port-Type for = PON (Passive Optical
> > Network) access.
> > http://www.= iana.org/assignments/radius-types
> >
> > Could you plea= se check and allocate one for it?
> >
> > Recommended va= lue:
> > ---------------------------------------------------------= -
> > value description
> > 35 xPON - Passive Op= tical Network
> > ------------------------------------------------= ------------
> >
> > (xPON may cover: Broadband PON (B-P= ON/G.983.x), Gigabit PON
> > (G-PON/G.984.x), and Ethernet PON (E-= PON/IEEE 802.3ah).)
> >
> > Kindly regards,
> >= ;
> > Renxiang
> >
> >
>
>
&= gt;
= --_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: 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$" To: "Alan DeKok" Cc: 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 |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 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: 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 User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Glen Zorn (gwz)" 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: 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 User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Bernard Aboba 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: 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 User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Glen Zorn (gwz)" CC: Bernard Aboba , 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: 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 User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "Glen Zorn (gwz)" CC: Bernard Aboba , 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: 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$" To: "Alan DeKok" , "Bernard Aboba" Cc: 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 |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: 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$" To: "Bernard Aboba" , "Alan DeKok" , 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 |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: ------_=_NextPart_001_01C7AC51.3480E894 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
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.

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

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

A NAS should not failover to another proxy unless it = has=20 evidence that they proxy itself (rather than the home server) is = down. =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.

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

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

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

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

> Date: Mon, 11 Jun 2007 13:47:35=20 +0200
> From: aland@nitros9.org
> To: = radiusext@ops.ietf.org
>=20 Subject: Proxies and dead home servers
>
> I've recently = come=20 across an issue which the RFC's don't clearly
> address, but which = can=20 have major implications in a proxying environment.
>
> = Suppose we=20 have a proxy chain as follows:
>
> NAS --> Proxy Server = -->=20 Home Server
>
> If the Home Server does not respond to a = proxied=20 Access-Request, what
> does the Proxy Server do with it? RFC 2865 = Section=20 4.1 says:
>
> Upon receipt of an Access-Request from a = valid=20 client, an
> appropriate reply MUST be transmitted.
> =
> This=20 would seem to indicate that the Proxy Server MUST respond to the
> = NAS,=20 even if the Home Server does not respond to the Proxy Server. = The
> only=20 safe response is an Access-Reject, I think.
>
> There are=20 implementations that do not behave this way, but I think
> their = impact is=20 small.
>
> Alan DeKok.
>
> --
> to = unsubscribe=20 send a message to radiusext-request@ops.ietf.org with
> the word=20 'unsubscribe' in a single line as the message text body.
> = archive:=20 <http://psg.com/lists/radiusext/>
------_=_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: 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$" To: "Alan DeKok" Cc: 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 |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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 11 Jun 2007 16:04:21 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_79924146-ff6e-41db-b38d-46e70b4f774c_" From: Bernard Aboba To: Alan DeKok CC: 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 > 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<= BR>> is still alive, and reject the session.
>
> I think th= at the second alternative is preferable to the first one.

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 co= ncluding that the server is dead. When the server finally responds, i= t is too late because the proxy has already sent an Access-Reject.
> 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 prox= y
> server, the NAS may decide that the proxy is down, and erroneousl= y
> reject the "example.net" request. This will cause spurious networ= k
> outages for users trying to log in.

> 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 t= he
> proxy server is dead, even though it is actually alive.

Yes.

>
> > 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
> tha= t the connection has been closed.

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

> My $0.02 is that it may be useful for the proxy to synthesize an
&g= t; 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 chang= e
> other NAS behavior such as rejecting the user login attempt.
<= BR> I would agree as long as the proxy implements appropriate retransmission an= d backoff logic.
= --_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: 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 User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Bernard Aboba 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 11 Jun 2007 14:23:09 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_ff2dfde7-e356-4e6d-9644-3a2ef60de8cd_" From: Bernard Aboba To: Alan DeKok , 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: = --_ff2dfde7-e356-4e6d-9644-3a2ef60de8cd_ Content-Type: text/html; 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.
<= 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. 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.

A NAS should not failover to another proxy unless= it has evidence that they proxy itself (rather than the home server) is do= wn. 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.

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

> Date: Mon, 11 Jun 200= 7 13:47:35 +0200
> From: aland@nitros9.org
> To: radiusext@ops.= ietf.org
> Subject: Proxies and dead home servers
>
> = I've recently come across an issue which the RFC's don't clearly
> ad= dress, 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
> ap= propriate 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 r= esponse is an Access-Reject, I think.
>
> There are implemen= tations that do not behave this way, but I think
> their impact is sm= all.
>
> Alan DeKok.
>
> --
> to unsubscr= ibe send a message to radiusext-request@ops.ietf.org with
> the word = 'unsubscribe' in a single line as the message text body.
> archive: &= lt;http://psg.com/lists/radiusext/>
= --_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: 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 User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: "David B. Nelson" 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: 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 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 08 Jun 2007 05:01:09 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_c7403b5f-f7e0-409b-b6d3-f2910ad4a9b1_" From: Bernard Aboba To: 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 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>
The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-0= 8.txt

The RADEXT WG last call will last until June 22, 2008.   Please s= end comments 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).

= --_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: 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: 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: 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 User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: 'radext mailing list' 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 04 Jun 2007 17:50:58 +0000 Message-ID: From: Bernard Aboba To: 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: 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: From: "Avi Lior" To: "Bernard Aboba" , "Alan DeKok" Cc: "David B. Nelson" , , "Bernard Aboba" 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
Please see=20 inline...[Avi2]

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

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

[BA] RFC = 3576=20 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.

Therefore it isn't clear that sending a = Disconnect-Request with a User-Name/CUI attribute
will necessarily = terminate *all* the user's sessions if there are more than one. =

Do we need to say something like "all sessions matching the NAS = & session
identification attributes are affected by = CoA/Disconnect-Requests?"
[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.


[BA] 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. 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.)

[Avi]  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. 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.

[BA] Where the NAS is a pure = L2=20 device (e.g. IEEE 802 switch, 802.11 AP), it has no awareness of = L3, and=20 so does not track the IP addresses of clients.

[Avi2] Then receiving an IP = address makes=20 no sense to the NAS either as a session identifier or as a new IP = address.

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.

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

So the choices=20 are:

1. Allow = Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier=20 attributes in Disconnect-Request & CoA-Request packets, only for=20 identification.   Changing the address would require a=20 Service-Type=3DAuthorize Only. This was what we had in = -05.
[Avi2] This is inefficient. 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.  As I said above, I cant think = of any=20 reason to change an IP address. So I could live with=20 this.

2. Allow=20 Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier attributes in=20 Disconnect-Requests for identification. In CoA-Request packets = allow=20 them only for address change.
[Avi2]=20 No. This is inconsistant. And it does not allow = me to=20 changes something relating to a specific IP=20 Session.

3. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed= -Identifier address attributes in = Disconnect-Request &=20 CoA-Request packets only for address change. Invent new = attributes for=20 identification. This was previously proposed for -07.
[Avi2]  No. See=20 4.

4. Allow=20 Framed-IP-Address/Framed-IPv6-Prefix/Framed= -Identifier address attributes in = Disconnect-Request &=20 CoA-Request packets only for identification. Invent new = attributes for=20 address change.
[Avi2] Yes.  I think this = option is=20 the most appealing to me.

5. Prohibit use of Framed-IP-Address/Framed-IPv6-Prefix/Framed= -Identifier attributes for session = identification. =20 Permit their use only in CoA-Request packets, for use in address = change. =20 This is what we have in -07.
[Avi2]=20 No. Because of what I stated earlier. It is uncommon=20 to change the IP address. It is most common to change some = aspect=20 of an IP session.

I think this more or less = describes=20 the choices available on this issue. Are there any more?=20

[Avi2] I think 4 is the = right choice. =20 And we can use that model for any other session identifier = that can=20 also be changed dynamically.

[Avi] Yes I agree that=20 it "can" be used. But Alan seems to make it mandatory. And = to=20 mandatory require that it be sent=20 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]=20 I don't think we can make it mandatory to include=20 Acct-Session-Id/Acct-Multi-Session-Id. 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). =
[Avi2] VSA must be allowed for session = identification. See below.
[Avi2]  The problem is that there = is no=20 definition for what a session is. Therefore we cant be specific = in the=20 definition here. In general a NAS will maintain one or more = Sessions for=20 a given user.  These sessions are going to be related to = each other=20 like a tree. The top most session is the user session - the=20 authenticated session. That session will have subsessions, = and thus=20 subsession may have further subsessions. The NAS will use the=20 information received to identify one of those sessions. Then that = session and=20 its subsession will be affected.

[BA] RFC 3576 Section 3 (or = RFC 3576bis)=20 does not include VSAs for the purpose of session = identification.  =20 However, RFC 3576bis Section 2.3 does say this:

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

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

So = maybe we should add VSAs to the Session Identification list, as well as = a paragraph
stating that their use is optional.
[Avi2] Yes I agree. = I think we better be explicit about VSAs.

<= /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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 04 Jun 2007 16:11:00 +0000 Message-ID: From: Bernard Aboba To: 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 04 Jun 2007 15:31:08 +0000 Message-ID: From: Bernard Aboba To: 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 04 Jun 2007 15:29:01 +0000 Message-ID: From: Bernard Aboba To: 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 04 Jun 2007 15:18:56 +0000 From: "David B. Nelson" To: 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 04 Jun 2007 15:10:55 +0000 From: "David B. Nelson" To: 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 04 Jun 2007 14:59:56 +0000 From: "David B. Nelson" To: 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 04 Jun 2007 14:57:08 +0000 From: "David B. Nelson" To: 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 04 Jun 2007 14:54:01 +0000 From: "David B. Nelson" To: 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 04 Jun 2007 03:26:28 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_abe5b8c6-dcba-47fa-8407-b0a7e8b698c6_" From: Bernard Aboba To: 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 Issue 239: VSAs in Session Identification
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:

The question has arisen as to whethe= r VSAs are be allowed for use in session identification.   In loo= king at RFC 3576 (and 3576bis) the documents appear to contain contradictor= y information on whether 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 al= lowed in CoA-Request and Disconnect-Request packets. 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.

We can resolve this contradiction in one of the = following ways:

1. Prohibit inclusion of VSAs within a Disconnect-Re= quest OR
2. Include VSAs in the list of Session Identification attribute= s.

Opinions on these options are solicited.

If we take opti= on 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 tre= ated
as mandatory.

This suggests that if a VSA is included,= then if the NAS does not understand it,
it MUST send a Disconnect-NAK/C= oA-NAK.

This does create a potential interoperability issue if a VSA= is sent to a NAS that
does not support it. However, it is not clear to= me that an alternative exists.
In a Disconnect-Request, then NAS can a= ssume that the attribute is included
for the purpose of session identifi= cation, but if it does not support the
attribute it will not be able to = determine which sessions (if any) are to
be disconnected, since in Issue= 238 we suggested that *all* session identification
attributes MUST matc= h (that would include VSAs, too).

In a CoA-Request, VSAs could = be session identification or authorization change
attributes. Unless th= e NAS supports the VSA it will not know which use is
intended. Therefor= e it seems like it also must reply with a CoA-NAK if a
VSA is unsupport= ed.

= --_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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 04 Jun 2007 02:51:35 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_6733c9df-fdbe-4694-b7fb-e9b18b7ea519_" From: Bernard Aboba To: 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 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 des= ired effect of including Session Identification attributes is to affect *al= l* sessions matching the attributes that are supplied. 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. Howev= er, currently Section 3 appears to make the behavior undefined where more t= han one session can match the session identification attributes. Rath= er than being "out of scope" it would seem that RFC 3576bis should define t= he expected behavior.

The proposed resolution is as follows:
Change the following text in Section 2.3 from:

"
State ch= anges resulting from a CoA-Request MUST be atomic: if the
CoA-Requ= est is successful, the Dynamic Authorization Server MUST
send a Co= A-ACK in reply, and all requested authorization changes
MUST be ma= de. 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 unsucc= essful Disconnect-Request; the Dynamic Authorization
Server MUST s= end a Disconnect-NAK in reply.
"

to:

"
Sta= te changes resulting from a CoA-Request MUST be atomic: if the
CoA= -Request is successful for all matching sessions, the Dynamic
Aut= horization Server MUST send a CoA-ACK in reply, and all
requested= authorization changes MUST be made. If the CoA-Request
is unsuc= cessful 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 oc= cur as a result of a Disconnect-Request that is unsuccessful
with = respect to any of the matching sessions; a Dynamic Authorization
S= erver MUST send a Disconnect-NAK in reply if any of the matching
s= essions cannot be successfully terminated.
"

Change the fol= lowing text in Section 3 from:

"
In Disconnect-Request and Co= A-Request packets, certain attributes are
used to uniquely identify t= he 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 Dis= connect-Request or CoA-Request to be
successful; otherwise a Disconne= ct-NAK or CoA-NAK SHOULD be sent.
For session identification attribut= es, the User-Name and Acct-
Session-Id Attributes, if included, MUST = match in order for a
Disconnect-Request or CoA-Request to be successf= ul; other session
identification attributes SHOULD match. Where a mi= smatch 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 inclu= de NAS and session identification
attributes, as described below."

To:

"
In Disconnect-Request and CoA-Request packets, certain attributes a= re
used to uniquely identify the NAS as well as user session(s) on th= e
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 identificati= on
attributes match and more than one session matches all of the
= session identification attributes, then a CoA-Request or Disconnect-Requ= est
MUST apply to all matching sessions.

Identification att= ributes include NAS and session identification
attributes, as describ= ed below."
= --_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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 04 Jun 2007 02:28:04 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_fd1ac3e4-3090-417c-8c82-cb3846f547b1_" From: Bernard Aboba To: 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 We have been discussing this issue for a while. The time has come to = lay out the potential solutions and get a sense of the WG consensus on this= issue.

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

Here is what I have s= o 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-Id= entifier address attributes in Disconnect-Request & CoA-Request packets only for address change. Invent new attributes for identification. T= his was initially proposed for -07.

4. Allow Framed-IP-A= ddress/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-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_-- -- 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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 04 Jun 2007 02:23:19 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_cb92e110-a4a3-47ec-9f0a-2c9b16f5c15d_" From: Bernard Aboba To: 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 To address Avi's concern, I propose that the following sentence in Section = 3.2

"
This Access-Request SHOULD contain the NAS
identi= fication attributes from the CoA-Request, as well as the
session iden= tification attributes from the CoA-Request legal for
inclusion in an = Access-Request as specified in [RFC2865], [RFC2868],
[RFC2869] and [R= FC3162]."

be changed to:

"This Access-Request SHOULD co= ntain 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."
= --_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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 04 Jun 2007 02:11:59 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_1ce30cba-9cb7-424b-a51a-886804f19a5a_" From: Bernard Aboba To: "David B. Nelson" , 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: = --_1ce30cba-9cb7-424b-a51a-886804f19a5a_ Content-Type: text/html; 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 including various session identification attributes in a CoA-Request/Di= sconnect-Request.

> From: dnelson@elbrysnetworks.com
> To:= radiusext@ops.ietf.org
> Subject: RE: RFC3576bis and Session State> Date: Wed, 30 May 2007 16:45:27 -0400
>
> All of this d= iscussion 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 deployme= nts.
> This could be a section of RFC3576bis or it could be stand-alo= ne document.
>
> Do I recall that someone once attempted to wr= ite such a document? Or am I
> just remembering a long thread from t= he RADEXT list about three or four
> years ago?
>
>
= >
> --
> to unsubscribe send a message to radiusext-request= @ops.ietf.org with
> the word 'unsubscribe' in a single line as the m= essage text body.
> archive: <http://psg.com/lists/radiusext/><= br> = --_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: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 04 Jun 2007 02:11:09 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_1a109d7c-b44e-4d2c-9949-57d2f5a5719c_" From: Bernard Aboba To: Avi Lior , Alan DeKok CC: "David B. Nelson" , , Bernard Aboba 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
> 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 the scope of
this document.
Therefore it isn't clear that sending a Disconnect-Request with a Use= r-Name/CUI attribute
will necessarily terminate *all* the user's sessio= ns if there are more than one.

Do we need to say something like "al= l sessions matching the NAS & session
identification attributes are= affected by CoA/Disconnect-Requests?"

[BA] 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. 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.)

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

[BA] Where the NAS is a pure L2 device (e.g. IEE= E 802 switch, 802.11 AP), it has no awareness of L3, and so does not = track the IP addresses of clients.

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

So the choices are:

1. Allow Framed-IP-Address/Framed-IPv6-P= refix/Framed-Identifier attributes in Disconnect-Request & CoA-Request = packets, only for identification.   Changing the address would re= quire a Service-Type=3DAuthorize Only. This was what we had in -05.
2. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier attri= butes in Disconnect-Requests for identification. In CoA-Request packe= ts 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.&n= bsp; Invent new attributes for identification. This was previously pr= oposed for -07.

4. All= ow Framed-IP-Address/Framed-IP= v6-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-R= equest packets, for use in address change. This is what we have in -0= 7.

I think this more or less describes the choices available on thi= s issue. Are there any more?

[Avi] Yes I agree that it&n= bsp;"can" be=20 used. But Alan seems to make it mandatory. And to mandatory require t= hat=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 attri= butes MAY/SHOULD be included, and what happens when they are included (e.g.= how the NAS selects the 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 inclu= de VSAs for the purpose of session identification.   However, RFC= 3576bis Section 2.3 does say this:

Within this sp= ecification attributes can be used for
identification, authorizati= on or other purposes. RADIUS Attribute
specifications created aft= er publication of this document SHOULD
state whether an attribute = can be included in CoA or Disconnect
messages and if so, which mes= sages it can be included in and
whether it serves as an identifica= tion or authorization attribute.

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

So maybe we should add VSAs to the Session Identification list, as = well as a paragraph
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 N= AS=20 will be unable to identify the session by IP address.   Given thi= s,=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 differen= t=20 session identifiers.  Furthermore, I think they should be used in= =20 combination. For example, User-Name + Accounting Session Id to d= elete=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 does too.

= --_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: