Alan's Review of draft-lourdelet-radext-ipv6-access-01.txt

[Behcet Sarikaya <[e-mail]>]

----- Forwarded Message ----
> From: Alan DeKok <[e-mail]>
> To: Behcet Sarikaya <[e-mail]>
> Sent: Friday, August 21, 2009 2:37:58 PM
> Subject: Re: Fw: Review of draft-lourdelet-radext-ipv6-access-01.txt

>   My review is:
> 
> IPv6-Address:
> 
>   I'd suggest giving it a more descriptive name, like "Uplink-IPv6-Address"
> 
> IPv6-Route-Option-Preference:
> 
>   2 octet signed integers aren't nice.  I would suggest using a normal
> 32-bit integer.  This should work, if I understand it correctl.
> 
> IPv6-Route-Option-Lifetime:
> Auth-IPv6-Prefix-Valid-Lifetime:
> 
>   Defining a tag field *and* a 32-bit integer means that you're
> re-defining the meaning of a tag + integer attribute.  See RFC 2868,
> Section 3.1 for the historical definition.
> 
>   It would seem to be OK to have a 24-bit lifetime.  That would allow
> everyone to use this attribute by simply updating their dictionaries,
> rather than writing new code to handle a new format.
> 
> Prefix-Lifetime-Service-Type:
> 
>   This could just be a normal 32-bit integer, rather than a 2-byte integer.
> 
>   Other than that, it looks OK to me.
> 
> >>
> >>  Alan DeKok.



      

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

Envelope-to: [e-mail]
Delivery-date: Mon, 24 Aug 2009 18:55:07 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t51140064; bh=VxJywNe6ZBzskae+ONssOtxdk3rTLvXpK4zNiBKu/zI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FUeVopAqAlqtXzdKEafbmaA48hwZdV3Bn14hXUR7u+BTF3r6jn+n0gXm1f8TOIf1QrJat4whtx074k8PCk/bzDQsCtzgKn2TjqS9y8CBTSxY50KpzLSEFmnTTnwg6+9ceg7wLLjMXMpSDVlP6p70KMvfqj1A/aiTSI9Rq7XPnPgDomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kMhL2XX61CBgFOO1ntWIoONR/nHDzfinT/HzqMLvLpDw1JpniaIkJC4be559mmCMmIHsaZl/HOAGTpaLaPijq62gH0bbTENpP7GRa6zmPRGNgr1OnhPtNGRG6fLmCm7z/inDD1HZ4B4yGfpcCTtwmc++rV2T1a762wxNOObO7YY=;
Message-ID: <[e-mail]>
Date: Mon, 24 Aug 2009 18:54:24 +0000 (GMT)
From: Behcet Sarikaya <[e-mail]>
Reply-To: Behcet Sarikaya <[e-mail]>
Subject: Alan's Review of draft-lourdelet-radext-ipv6-access-01.txt
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable





----- Forwarded Message ----
> From: Alan DeKok <[e-mail]>
> To: Behcet Sarikaya <[e-mail]>
> Sent: Friday, August 21, 2009 2:37:58 PM
> Subject: Re: Fw: Review of draft-lourdelet-radext-ipv6-access-01.txt

>   My review is:
> 
> IPv6-Address:
> 
>   I'd suggest giving it a more descriptive name, like "Uplink-IPv6-Address"
> 
> IPv6-Route-Option-Preference:
> 
>   2 octet signed integers aren't nice.  I would suggest using a normal
> 32-bit integer.  This should work, if I understand it correctl.
> 
> IPv6-Route-Option-Lifetime:
> Auth-IPv6-Prefix-Valid-Lifetime:
> 
>   Defining a tag field *and* a 32-bit integer means that you're
> re-defining the meaning of a tag + integer attribute.  See RFC 2868,
> Section 3.1 for the historical definition.
> 
>   It would seem to be OK to have a 24-bit lifetime.  That would allow
> everyone to use this attribute by simply updating their dictionaries,
> rather than writing new code to handle a new format.
> 
> Prefix-Lifetime-Service-Type:
> 
>   This could just be a normal 32-bit integer, rather than a 2-byte integer.
> 
>   Other than that, it looks OK to me.
> 
> >>
> >>  Alan DeKok.



      

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


Envelope-to: [e-mail]
Delivery-date: Mon, 17 Aug 2009 17:29:31 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_c640c029-a700-4eeb-a4a8-dd76ebb1a694_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Design Guidelines Issues
Date: Mon, 17 Aug 2009 10:28:38 -0700
MIME-Version: 1.0

--_c640c029-a700-4eeb-a4a8-dd76ebb1a694_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


The review of the PKMv1 document has revealed a number of ambiguities in the Design Guidelines document.  Among the issues that have come up:

a. Scope of the "security exemption".   Does this exemption apply only to attributes relating to RADIUS security, to attributes relating to "authentication", or to security attributes in general?  

b.  Use of attribute extension schemes.  The document currently recommends against use of the existing tagging schemes, recommending use of Extended Attributes (currently in draft).  Did the document intend to discourage use of adhoc extension mechanisms (e.g. RFC 3579 EAP attributes)?  Is the normative dependency on Extended Attributes required? 

Are there other ambiguities that remain in the document?  







--_c640c029-a700-4eeb-a4a8-dd76ebb1a694_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
The review of the PKMv1 document has revealed a number of ambiguities in the Design Guidelines document.&nbsp; Among the issues that have come up:<br><br>a. Scope of the "security exemption". &nbsp; Does this exemption apply only to attributes relating to RADIUS security, to attributes relating to "authentication", or to security attributes in general?&nbsp; <br><br>b.&nbsp; Use of attribute extension schemes.&nbsp; The document currently recommends against use of the existing tagging schemes, recommending use of Extended Attributes (currently in draft).&nbsp; Did the document intend to discourage use of adhoc extension mechanisms (e.g. RFC 3579 EAP attributes)?&nbsp; Is the normative dependency on Extended Attributes required? <br><br>Are there other ambiguities that remain in the document?&nbsp; <br><br><br><br><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table></body>
</html>
--_c640c029-a700-4eeb-a4a8-dd76ebb1a694_--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 17 Aug 2009 12:23:53 +0000
Message-ID: <[e-mail]>
Date: Mon, 17 Aug 2009 14:22:37 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Review of draft-ietf-radext-dynamic-discovery-01
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> [BA] As we discussed at IETF 75, RadSec is a product name.  Can we use "RADIUS over TLS" and "RADIUS over DTLS" 
> (or maybe RAD-TLS and RAD-DTLS) instead?

  That's a reasonable idea.  I can update the DTLS document to say this.

> [BA] Given that RadSec is a product name, what should the SRV prefixes be? 
> _radtls._tcp?  _raddtls._udp? 

  I would say the latter two.  However, _radsec._tcp SHOULD also be used
for backwards compatibility.

>    This document contains no actions for IANA.  Maybe.  Not sure about
>    the labels "AAAS+RADSECT" and "_radsec._tcp.".
> 
> [BA] What about RADIUS over DTLS?  Does this document apply to that as well? 

  I would suggest so, yes.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Wed, 12 Aug 2009 05:28:16 +0000
Message-ID: <[e-mail]>
Date: Wed, 12 Aug 2009 07:27:23 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Glen Zorn <[e-mail]>
CC: 'radext mailing list' <[e-mail]>
Subject: Re: Chargeable-User-Identity
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
>Alan DeKok wrote:
>>   The design guidelines is opposed to the *gratuitous* use of complex
>> types. ...
> 
> I'm unaware of any technical usage for the word "gratuitous";

  The design guidelines document clearly states when complex attributes
are necessary, and when they are not.  The unnecessary use of something
fits the common meaning of the word "gratuitous".

  If you like, we could update the design guidelines document to use the
word "gratuitous".

> it seems most
> useful in the context of a value judgment.  Aside from that, your response
> seems to be (again) utterly disconnected from my assertion.  

  You're playing word games, and claiming to not understand things that
have been explained and well understood for years.  If you think this
means I'm avoiding your assertion, fine.

  It seems like you're trying to win a logical argument by re-defining
the words "logic" and "argument".

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Aug 2009 22:19:33 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>
Cc: "'radext mailing list'" <[e-mail]>
Subject: RE: Chargeable-User-Identity
Date: Tue, 11 Aug 2009 15:18:17 -0700
Message-ID: <00dc01ca1ad1$a0f15ce0$e2d416a0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AcoatofoRuSxN1ByQb2cbkpkx0QqKAADiuCQ
Content-Language: en-us

Alan DeKok [mailto://[e-mail]] writes:

> Glen Zorn wrote:
> > What is being "protected" seem not to be so much the _idea_ of data-
> driven
> > dictionaries but the existing, simplistic _implementations_
> thereof...
> 
>   Let's look at the statistics.  For the dictionaries I have:
> 
> attributes:		4294
> 	integer		2045
> 	text		1606
> 	ipaddr		278
> 	string		259
> 	byte		40	(unsigned 8-bit integer)
> 	date		30
>  	ipv6addr	15
> 	short		14	(unsigned 16-bit integer)
> 	ascend filter	6	(Ascend)
> 	ipv4/ipv6addr	5	(ipv4 or ipv6 address)
> 	ifid		4
> 	ipv6prefix	3
> 	signed		1	(signed 32-bit int)
> 
>   13 data types in wide use, of which 5 are vendor extensions.
> 
>   The "complex" attributes have all been lumped together into the
> "string" category.  All together, they account for about 6% of
> attributes.
> 
>   This means that about 95% of the attributes in wide use follow the
> RADIUS data model, as described in the guidelines document.
> 
>   That's good evidence that the data model is not only in wide use, but
> that it is widely useful.

What does this have to do with whether or not "complex" attributes can be
handled by a dictionary-based server?  

> 
> > If, after 9+ years of the existence of so-called "complex"
> attributes, your
> > programmers haven't managed to create a simple data-driven machine to
> parse
> > them, maybe you need new programmers...
> 
>   The design guidelines is opposed to the *gratuitous* use of complex
> types.  Such use indicates that you've hired people who prefer complex
> solutions to simple ones.

I'm unaware of any technical usage for the word "gratuitous"; it seems most
useful in the context of a value judgment.  Aside from that, your response
seems to be (again) utterly disconnected from my assertion.  




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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Aug 2009 19:01:32 +0000
Message-ID: <[e-mail]>
Date: Tue, 11 Aug 2009 21:00:50 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: 'radext mailing list' <[e-mail]>
Subject: Re: Chargeable-User-Identity
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> What is being "protected" seem not to be so much the _idea_ of data-driven
> dictionaries but the existing, simplistic _implementations_ thereof...

  Let's look at the statistics.  For the dictionaries I have:

attributes:		4294
	integer		2045
	text		1606
	ipaddr		278
	string		259
	byte		40	(unsigned 8-bit integer)
	date		30
 	ipv6addr	15
	short		14	(unsigned 16-bit integer)
	ascend filter	6	(Ascend)
	ipv4/ipv6addr	5	(ipv4 or ipv6 address)
	ifid		4
	ipv6prefix	3
	signed		1	(signed 32-bit int)

  13 data types in wide use, of which 5 are vendor extensions.

  The "complex" attributes have all been lumped together into the
"string" category.  All together, they account for about 6% of attributes.

  This means that about 95% of the attributes in wide use follow the
RADIUS data model, as described in the guidelines document.

  That's good evidence that the data model is not only in wide use, but
that it is widely useful.

> If, after 9+ years of the existence of so-called "complex" attributes, your
> programmers haven't managed to create a simple data-driven machine to parse
> them, maybe you need new programmers...

  The design guidelines is opposed to the *gratuitous* use of complex
types.  Such use indicates that you've hired people who prefer complex
solutions to simple ones.

  Alan DeKok.


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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Aug 2009 17:20:48 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Dave Nelson'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Chargeable-User-Identity
Date: Tue, 11 Aug 2009 10:19:48 -0700
Message-ID: <007301ca1aa7$ee406a60$cac13f20$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AcoZmET0wlDkQFnORGiHr7wXmtfeCAAACm1AABOYgGAAEdfSMAATq6mwAAmMRkAContent-Language: en-us

Dave Nelson [mailto:[e-mail]] writes:

> Glen,
> 
> > OK, I'll bite: why?
> 
> You I have always disagreed over what constitutes a clean and easily
> re-usable format for attributes, and I wouldn't expect that to change
> anytime soon.
> 
> My point here is that the "exclusion" in the RADIUS Design Guidelines
> draft
> for certain classes of attributes (*) falls down when someone wants to
> re-use one of the heretofore "excepted" attributes in another
> application
> area, one which nicely fits into the traditional RADIUS data model
> (**).
> 
> (*) The "exclusion" is for any attribute that is related to "security",
> is
> intended for parsing and action by some "plug-in" element that's
> outside the
> RADIUS server proper (such as GEOPRIV), or in general for some
> application
> where new code is absolutely required on the server.

This is very a very interesting statement.  
> 
> (**)  The traditional RADIUS data model supports single-valued
> attributes
> and data dictionary driven RADIUS Servers.  Yes, there are existing
> RFCs
> that deviate from this model, slightly.  

2865, 2868, 3162, 4675.  The "tradition" you venerate seems to be of fairly
recent vintage... 

> The idea here is to "protect"
> the
> ability of data dictionary driven RADIUS server implementations to add
> new
> attributes simply as dictionary entries.  

What is being "protected" seem not to be so much the _idea_ of data-driven
dictionaries but the existing, simplistic _implementations_ thereof...

> Complex, multi-part "string"
> attributes cannot be added in this fashion.  They require custom
> parsing
> code.

If, after 9+ years of the existence of so-called "complex" attributes, your
programmers haven't managed to create a simple data-driven machine to parse
them, maybe you need new programmers...



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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Aug 2009 15:19:10 +0000
Message-ID: <[e-mail]>
Date: Tue, 11 Aug 2009 17:18:22 +0200
From: Tomasz Wolniewicz <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Chargeable-User-Identity
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

David B. Nelson wrote:
>> I still think that providing an option for the Operator-Name
>> to carry something Operator-Name related, but otherwise not
>> obvious, could be useful in various applications...
>>     
>
> In other words, an obfuscated name for the operator.  From a security
> (privacy protection) perspective, simply using an obfuscated name for each
> visited network won't provide very much protection if the same name string
> is used in each request, as the operator's name can likely be derived by
> correlating the source of the messages with the obfuscated name.  If the
> messages are originating from an IP address assigned to foo.edu, it's a safe
> bet that the obfuscated name stands for Foo University.  :-)
>   
Not quite :). The messages carry the NAS-IP-Address, which (in very many
cases) can be something like 192.168..,
but I admit that this can be a give away. Since the messages pass
thorough proxies the actual source of the request is lost on the way.
> I think you may want to create a threat model to enumerate the adversaries
> that can discover and misuse personal information, and then see how to
> design the protocol to address the attack opportunities presented in that
> threat model.
>   
Let's say that we want to use a best effort here. We do not want to
transport and collect data that we do not need for the system to work.
The current eduroam structure is not perfect in many respects. The next
model should be direct server connections based on RadSec, without any
proxy structure. In this model, the Operator-Name will not be needed, as
the peers will know each other and the AAA server will be able to
generate the CUI differentiating between the networks. Therefore we are
discussing a temporary model here, however this temporary state may take
several years.

RADIUS over UDP is not a very secure transport, while RadSec will be. So
we do not want to invest too much time designing something perfect, when
we already have the candidate.

While I am at it, I should perhaps add, that the entire project is based
on CUI implemented in the server and not in the NAS. With help from Alan
DeKok we have a working FreeRADIUS implementation. This way we are able
to introduce CUI on a large scale, in spite of the lack of NAS-based
support.

Tomasz

-- 
Tomasz Wolniewicz    
          [e-mail]        http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne   Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika     Nicolaus Copernicus University,
pl. Rapackiego 1, Torun               pl. Rapackiego 1, Torun, Poland
tel: [phone]     fax: [phone]       tel kom.: [phone]


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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Aug 2009 14:52:51 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Chargeable-User-Identity
Date: Tue, 11 Aug 2009 10:52:21 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <58C1841F05F148148AF3D805B78F8416@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Acoah93xw6ozqnybT9afABsbb5khRgAChinQ

Tomasz Wolniewicz writes...

> I still think that providing an option for the Operator-Name
> to carry something Operator-Name related, but otherwise not
> obvious, could be useful in various applications...

In other words, an obfuscated name for the operator.  From a security
(privacy protection) perspective, simply using an obfuscated name for each
visited network won't provide very much protection if the same name string
is used in each request, as the operator's name can likely be derived by
correlating the source of the messages with the obfuscated name.  If the
messages are originating from an IP address assigned to foo.edu, it's a safe
bet that the obfuscated name stands for Foo University.  :-)

I think you may want to create a threat model to enumerate the adversaries
that can discover and misuse personal information, and then see how to
design the protocol to address the attack opportunities presented in that
threat model.
  
> Of course there is an option of using a new VSA and keep it
> all internal to eduroam.

You could also do that.



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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Aug 2009 13:27:03 +0000
Message-ID: <[e-mail]>
Date: Tue, 11 Aug 2009 15:26:21 +0200
From: Tomasz Wolniewicz <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Dave Nelson <[e-mail]>
CC: [e-mail]
Subject: Re: Chargeable-User-Identity
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Dave Nelson wrote:
>> Since the visited network does not bill us for our users, we have no
>> reason to know where our user is, but more importantly, we would not
>> want this information to travel in the open.
>>     
>
> OK, that sounds a bit paranoid.  If the user wants to maintain true
> anonymity, they will need to use EAP methods with an anonymous outer
> identity.  In that case all that can be detected is the number of users
> visiting a particular university on a particular day, not their identity.
> I'll admit there is *some* information there, but if you're going to perform
> traffic analysis of eduroam traffic, that kind of information is going to
> come out anyway.
>   
It *is* paranoid. I quite agree. Personally, I do not mind if people
know where I am. But there are plenty of paranoid people out there and
we do not want to loose the potentially useful thing like an opaque user
identity by doing something that will be challenged.
>   
>> We want to have the Operator-Name (or equivalent) for just one reason -
>> when we generate the CUI we want to do something like:
>> md5(User-Name:Operator-Name:local_salt)
>>     
>
> Sure.  You don't need it to be the actual name of an operator.  I
> understand.  What I'm challenging is whether it's acceptable practice to
> overload an existing RADIUS attribute to carry a new data object.  Including
> a "unique but meaningless salt" in an attribute defined to hold a human
> readable operator name sounds attribute overloading to me.
>   
But this is exactly what I would want to avoid.

Frankly, I think that this  discussion is going in the wrong direction.
We definitely would not want to use any attributes in a way that they
have not been designed for.

Perhaps I should repeat our case.
We would like to use the Chargeable-User-Identity attribute and this
seems to fall within its expected usage.
We have found out that we would need some visited-network identifier to
be fed into the CUI generation algorithm.
While looking at that, we have also realised that this network
identifier could be relevant also for other possible CUI applications
and this is why Stefan asked the list. Then the Operator-Name was
suggested and this looked like just the thing. But now it looks like we
would want to overload the attribute, so probably we are back to square
one. :(
I still think that providing an option for the Operator-Name to carry
something Operator-Name related, but otherwise not obvious, could be
useful in various applications, but perhaps the future will show the
need for yet another attribute for this purpose.

Of course there is an option of using a new VSA and keep it all internal
to eduroam.

Tomasz

-- 
Tomasz Wolniewicz    
          [e-mail]        http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne   Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika     Nicolaus Copernicus University,
pl. Rapackiego 1, Torun               pl. Rapackiego 1, Torun, Poland
tel: [phone]     fax: [phone]       tel kom.: [phone]


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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Aug 2009 13:06:11 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Chargeable-User-Identity
Date: Tue, 11 Aug 2009 09:05:54 -0400
Message-ID: <00E53F4CD37E4FCCAA068D3F57F8D5C9@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcoafuaRblzV4a4fSE23ZeI3dj2rPgAAM2rgAAEdYKA
> Well, GEOPRIV is all about specifying the rather react location of
> particular users.

Arrgh!  s/react/exact/

(and damn the auto-spell-correct feature of my client, that I've forgotten
how to turn off)



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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Aug 2009 12:42:49 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Chargeable-User-Identity
Date: Tue, 11 Aug 2009 08:42:33 -0400
Message-ID: <D39471610F984CE09F31AA426985A7A1@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcoafuaRblzV4a4fSE23ZeI3dj2rPgAAM2rg

> Well, not the names of consortium members, but fact that a particular
> user is in a particular location is, of course, private and sensitive.
> Quoting from the abstract of RFC 5580:
> 
>    The distribution of location information is a privacy-sensitive task.
>    Dealing with mechanisms to preserve the user's privacy is important
>    and is addressed in this document.

Well, GEOPRIV is all about specifying the rather react location of
particular users.  Certainly some of that level of concern spills over to
the eduroam use case, but I don't see them as analogous.  Still, that's
really none of my concern.  I'm only interested in how RADIUS attributes are
re-used in this case.

> Since the visited network does not bill us for our users, we have no
> reason to know where our user is, but more importantly, we would not
> want this information to travel in the open.

OK, that sounds a bit paranoid.  If the user wants to maintain true
anonymity, they will need to use EAP methods with an anonymous outer
identity.  In that case all that can be detected is the number of users
visiting a particular university on a particular day, not their identity.
I'll admit there is *some* information there, but if you're going to perform
traffic analysis of eduroam traffic, that kind of information is going to
come out anyway.

> We want to have the Operator-Name (or equivalent) for just one reason -
> when we generate the CUI we want to do something like:
> md5(User-Name:Operator-Name:local_salt)

Sure.  You don't need it to be the actual name of an operator.  I
understand.  What I'm challenging is whether it's acceptable practice to
overload an existing RADIUS attribute to carry a new data object.  Including
a "unique but meaningless salt" in an attribute defined to hold a human
readable operator name sounds attribute overloading to me.



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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Aug 2009 12:26:24 +0000
From: "Dave Nelson" <[e-mail]>
To: "'Glen Zorn'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Chargeable-User-Identity
Date: Tue, 11 Aug 2009 08:25:57 -0400
Message-ID: <8B0887A83B5D46449EE1537A036AD66A@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcoZmET0wlDkQFnORGiHr7wXmtfeCAAACm1AABOYgGAAEdfSMAATq6mw

Glen,

> OK, I'll bite: why?

You I have always disagreed over what constitutes a clean and easily
re-usable format for attributes, and I wouldn't expect that to change
anytime soon.

My point here is that the "exclusion" in the RADIUS Design Guidelines draft
for certain classes of attributes (*) falls down when someone wants to
re-use one of the heretofore "excepted" attributes in another application
area, one which nicely fits into the traditional RADIUS data model (**).

(*) The "exclusion" is for any attribute that is related to "security", is
intended for parsing and action by some "plug-in" element that's outside the
RADIUS server proper (such as GEOPRIV), or in general for some application
where new code is absolutely required on the server.

(**)  The traditional RADIUS data model supports single-valued attributes
and data dictionary driven RADIUS Servers.  Yes, there are existing RFCs
that deviate from this model, slightly.  The idea here is to "protect" the
ability of data dictionary driven RADIUS server implementations to add new
attributes simply as dictionary entries.  Complex, multi-part "string"
attributes cannot be added in this fashion.  They require custom parsing
code.



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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Aug 2009 12:26:16 +0000
Message-ID: <[e-mail]>
Date: Tue, 11 Aug 2009 14:25:55 +0200
From: Tomasz Wolniewicz <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Dave Nelson <[e-mail]>
CC: [e-mail]
Subject: Re: Chargeable-User-Identity
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Dave Nelson wrote:
> Wait.  Now you've got me confused.  I though that Operator-Name was being
> proposed, in the eduroam usage scenario, to carry the name of the visited
> network.  In other words, the name of a consortium member.  Do you mean to
> convey that the names of the visited networks, the eduroam consortium
> members, are also considered private and sensitive?  Gee...
>   
Well, not the names of consortium members, but fact that a particular
user is in a particular location is, of course, private and sensitive.
Quoting from the abstract of RFC 5580:

   The distribution of location information is a privacy-sensitive task.
   Dealing with mechanisms to preserve the user's privacy is important
   and is addressed in this document.

Since the visited network does not bill us for our users, we have no
reason to know where our user is, but more importantly, we would not
want this information to travel in the open.

We want to have the Operator-Name (or equivalent) for just one reason -
when we generate the CUI we want to do something like:
md5(User-Name:Operator-Name:local_salt)
This way we will have different CUIs for the same user visiting
different networks and we will also be safe against a dictionary attack
against the User-Name when the Operator-Name is known).

Tomasz

-- 
Tomasz Wolniewicz    
          [e-mail]        http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne   Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika     Nicolaus Copernicus University,
pl. Rapackiego 1, Torun               pl. Rapackiego 1, Torun, Poland
tel: [phone]     fax: [phone]       tel kom.: [phone]


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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Aug 2009 12:07:16 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Chargeable-User-Identity
Date: Tue, 11 Aug 2009 08:06:29 -0400
Message-ID: <6612B18ADC444C81864933D7C87D45A8@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcoaSmsWSUm/ZO/mSPeC1ru9sUcucgAMRUwg

Tomasz Wolniewicz writes...

> So now a suggestion. Would it be acceptable to register a 
> namespace ID for "private" usage, something like the private
> IP address classes.  Operator-Name value tagged this way,
> would then be known to contain stuff, that is not guaranteed 
> to be universally unique and does not adhere to any universal
> syntax (except being ASCII text).

Wait.  Now you've got me confused.  I though that Operator-Name was being
proposed, in the eduroam usage scenario, to carry the name of the visited
network.  In other words, the name of a consortium member.  Do you mean to
convey that the names of the visited networks, the eduroam consortium
members, are also considered private and sensitive?  Gee...



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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Aug 2009 06:07:50 +0000
Message-ID: <[e-mail]>
Date: Tue, 11 Aug 2009 08:06:54 +0200
From: Tomasz Wolniewicz <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Glen Zorn <[e-mail]>
CC: [e-mail]
Subject: Re: Chargeable-User-Identity
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn writes:
> The encoding of the attributes in 5580 isn't really so unusual: similar
> encodings have been around for years (see the CHAP-Password (RFC 3588) & the
> tunnel attributes (RFC 2868)).  
>   
The expected use of the Operator-Name attribute is, obviously, to carry
a unique operator identifier, be it a registered domain name or some
officially assigned id. For some applications, a global identifier is
not required or perhaps even harmful. I do not feel too happy about
eduroam Access-Request packets possibly carrying a user certificate with
his real name, or an unhidden e-mail address, accompanied by the domain
name of the visited network. It's true, that home institutions should
take care that users do not display their true identity and one could
say, why should we be worried if they do not do that, but still, we
(eduroam) do not need this open identifier of the institution. In fact,
the visited network could produce a different identifier for every realm
it needs to contact.

So now a suggestion. Would it be acceptable to register a namespace ID
for "private" usage, Something like the private IP address classes.
Operator-Name value tagged this way, would then be known to contain
stuff, that is not guaranteed to be universally unique and does not
adhere to any universal syntax (except being ASCII text).

Regards
Tomasz Wolniewicz

-- 
Tomasz Wolniewicz    
          [e-mail]        http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne   Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika     Nicolaus Copernicus University,
pl. Rapackiego 1, Torun               pl. Rapackiego 1, Torun, Poland
tel: [phone]     fax: [phone]       tel kom.: [phone]


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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Aug 2009 02:58:57 +0000
From: "Glen Zorn" <[e-mail]>
To: "'David B. Nelson'" <[e-mail]>, <[e-mail]>
Subject: RE: Chargeable-User-Identity
Date: Mon, 10 Aug 2009 19:58:08 -0700
Message-ID: <005d01ca1a2f$8ecec0e0$ac6c42a0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcoZmET0wlDkQFnORGiHr7wXmtfeCAAACm1AABOYgGAAEdfSMA=
Content-Language: en-us

> Pasi Eronen writes...
> 
> > Many of the other attributes in RFC 5580 indeed have
> > complex encodings, but using Operator-Name doesn't
> > necessarily require anything new from the RADIUS server...
> > The "Namespace ID" values are intentionally printable ASCII
> > digits, so you could treat the whole attribute as one string,
> > and put something like 'if Operator-Name = "1example.com"
> > then...' in your RADIUS configuration.
> 
> Yeah.
> 
> At the risk of appearing to beat a very dead horse, I'll observe that
> the
> notion of RADIUS attribute re-use, outside the original area of
> application,
> is yet another reason to use simple attributes that comply with the
> RADIUS
> Design Guidelines.

OK, I'll bite: why?  Either the server & client support the attributes in
question or not, regardless of whether they follow those guidelines.  

> 
> Sigh.

Indeed.



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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Aug 2009 02:32:42 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Stefan Winter'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Chargeable-User-Identity
Date: Mon, 10 Aug 2009 19:31:34 -0700
Message-ID: <005c01ca1a2b$d90faec0$8b2f0c40$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcoZmMXv3BrAX6UxST+33EmAfO+K9gAkgFwg
Content-Language: en-us

Stefan Winter [mailto://[e-mail]] writes:

> Hi,
> 
> > RFC 5580 does specify an "Operator-Name" attribute (to identify the
> > access network operator/"NAS owner") -- would it be useful in your
> > situation?
> >
> 
> Oh! Cute. That's exactly the thing. Thanks!
> 
> Now the only problem is to find RADIUS servers that support the unusual
> encoding of 5580 attributes to parse the content of Operator-Name. 

The encoding of the attributes in 5580 isn't really so unusual: similar
encodings have been around for years (see the CHAP-Password (RFC 3588) & the
tunnel attributes (RFC 2868)).  

...


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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 18:57:04 +0000
From: "David B. Nelson" <[e-mail]>
To: "'Tomasz Wolniewicz'" <[e-mail]>, <[e-mail]>
Subject: RE: Chargeable-User-Identity and Operator-Name
Date: Mon, 10 Aug 2009 14:56:41 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <B971A06F23FD4DDDB7504F6189930325@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcoZ6iIu/IClBUoQTN2QXimje49oAgAAJHWg

Tomasz Wolniewicz writes...

> Observe, that the RFC allows the visited institution
> to turn an Access-Accept into and Access-Reject if the
> reply does not contain the CUI. Now *this* is something
> that is very likely to [impact] interoperability, if
> the parties have not agreed on the principles first.

Umm.  No.

First, the RFC says that's the expected / required behavior, so from an
implementation design perspective, it *can't* come as a surprise -- except
to someone who didn't read the RFC carefully.

Second, that's the way that RADIUS has traditionally implemented the notion
of a "mandatory" attribute.  If an attribute is considered "mandatory", the
RADIUS client either effectuates it faithfully or treats the entire message
as if it had been an Access-Reject.  It's an all or nothing proposition.
You'll find this behavior required in a number of RADIUS RFCs.

> Some of our concerns are not about trust in the eduroam
> infrastructure, but about making our lives easier by 
> convincing our site lawyers that the amount of opacity
> introduced by our procedures is high enough to state that
> the CUI is not personal data of our guests.

I hear you.  ;-)

CUI as originally defined certainly passed that litmus test.  How far you
can go with turning it into a secondary form of user identity understood by
multiple parties while claiming it's not personal information is an open
question, I think.



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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 18:39:20 +0000
Message-ID: <[e-mail]>
Date: Mon, 10 Aug 2009 20:39:02 +0200
From: Tomasz Wolniewicz <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Chargeable-User-Identity and Operator-Name
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dave Nelson wrote:
> MUST makes for highly predictable behavior in a protocol and leads to
> interoperable implementations.
>
> There is an implicit assumption of trust between a NAS and RADIUS server
> that's central to the RADIUS architecture.  I understand that proxies and
> roaming consortia may have business, legal, privacy and other non-protocol
> concerns that make RADIUS a less than ideal protocol for such use cases.
>
> The problem is that, in the absence of a real capabilities negotiation
> feature in RADIUS, SHOULD and other forms of variable behavior make the
> implementation and error recovery design needlessly complicated.
>   
  I understand the technical perspective of this reasoning, but this 
particular RFC is very much policy related.
Observe, that the RFC allows the visited institution to turn an 
Access-Accept into and Access-Reject if the reply does not contain the 
CUI. Now *this* is something that is very likely to interoperability, if 
the parties have not agreed on the principles first.

In order for the CUI to be usable, there always has to be a business 
agreement between the parties even if, as in eduroam case, it is not 
direct. Since the CUI support is optional anyway, I do not see any real 
danger that not responding to a CUI request can seriously harm the 
RADIUS protocol.

Some of our concerns are not about trust in the eduroam infrastructure, 
but about making our lives easier by convincing our site lawyers that 
the amount of opacity introduced by our procedures is high enough to 
state that the CUI is not personal data of our guests.

Tomasz


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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 18:38:49 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Chargeable-User-Identity
Date: Mon, 10 Aug 2009 14:38:32 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <A5671FDEEECB4522BEF2BD3A31AE8D05@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcoZ5/+bX2g4hBq8Ske0uOjC66chKAAAMKvQ

Tomasz Wolniewicz writes...
 
> The main reason why we have brought up this problem on this
> list was to draw attention to the fact that the standard
> could take our approach into account.

Well, we can't amend RFC 4372 (CUI), but you could write an Informational
RFC for eduroam usage that explains its additional requirements for CUI.
Implementers targeting eduroam usage could then take those requirements into
account.  There is a history of "RADIUS Usage" documents for specific
applications areas, such as RFC 3580 (802.1X), which do not re-define
attributes, but explain how they are used for a particular application.



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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 18:22:51 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Chargeable-User-Identity
Date: Mon, 10 Aug 2009 14:22:24 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <2404F7A363114ECC83D50823B493779E@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcoZmET0wlDkQFnORGiHr7wXmtfeCAAACm1AABOYgGA
Pasi Eronen writes...
 
> Many of the other attributes in RFC 5580 indeed have
> complex encodings, but using Operator-Name doesn't
> necessarily require anything new from the RADIUS server...
> The "Namespace ID" values are intentionally printable ASCII
> digits, so you could treat the whole attribute as one string,
> and put something like 'if Operator-Name = "1example.com" 
> then...' in your RADIUS configuration.

Yeah.

At the risk of appearing to beat a very dead horse, I'll observe that the
notion of RADIUS attribute re-use, outside the original area of application,
is yet another reason to use simple attributes that comply with the RADIUS
Design Guidelines.

Sigh.



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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 18:16:07 +0000
Message-ID: <[e-mail]>
Date: Mon, 10 Aug 2009 20:15:43 +0200
From: Tomasz Wolniewicz <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: Chargeable-User-Identity
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

David B. Nelson writes:
>> 3. Promoting the user access rights. A positive example,
>> for a change.  Suppose we gave an official guest at the 
>> university and we want to provide him with some extra 
>> services. CUI will allow us to place the user in a special
>> VLAN and allow printing, for instance. This is a lot
>> easier then creating a local account and setting up the
>> user access based on that.
>>     
>
> You're going to set up a local "shadow" user authorization database, keyed
> on CUI values, to add, remove and modify user access permissions?  Hmmm.
> Good luck managing that.  You potentially have no way to link the real user
> identity to a CUI at the remote site, but you think it can be useful for
> creating a supplementary authorization service?  I can foresee all sorts of
> operational problems with such a scheme.  As I say, good luck with that.  I
> see no direct conflict with RADIUS services or attributes.  It's just that
> sometimes CUI can only be related to a specific session, and its
> packet-level behaviors, and not to a person.
>   
I think these would be some fairly special cases. Having the MAC address 
of a user and his realm we may find out the CUI value. We can also ask 
the user to get the value form his home institution. All this sounds 
fairly clumsy, I agree. Perhaps it is not terribly useful, perhaps we 
will go for a more complicated system of sending additional user 
attributes by other means. I am not going to defend this user case too 
strongly, time will show if it holds water.

Tomasz


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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 17:50:25 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Chargeable-User-Identity
Date: Mon, 10 Aug 2009 13:50:17 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <6194D731613843A8A6E54E711BA6342D@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcoZ3xJdEKvpTcmzTgSairPlcbqdJwAAZBmAAAB0LeA
> I see no direct conflict with RADIUS services or attributes.

On the other hand, it does appear that your use cases place additional
requirements on the properties of CUI beyond what is defined in the RFC.
RADIUS Servers that are fully compliant to the RFC may not work well in the
eduroam scenarios you describe.  



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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 17:42:58 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Chargeable-User-Identity
Date: Mon, 10 Aug 2009 13:42:43 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <175D4B0E692B4ADCA14111B09D9E2AB7@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcoZ3xJdEKvpTcmzTgSairPlcbqdJwAAZBmA

Tomasz Wolniewicz writes...

> ... user blacklisting based on and observed misbehaviour
> is just one of the use cases for CUI in eduroam, but there
> are more.

It's often very useful to enumerate and explain all the relevant use cases.

> 3. Promoting the user access rights. A positive example,
> for a change.  Suppose we gave an official guest at the 
> university and we want to provide him with some extra 
> services. CUI will allow us to place the user in a special
> VLAN and allow printing, for instance. This is a lot
> easier then creating a local account and setting up the
> user access based on that.

You're going to set up a local "shadow" user authorization database, keyed
on CUI values, to add, remove and modify user access permissions?  Hmmm.
Good luck managing that.  You potentially have no way to link the real user
identity to a CUI at the remote site, but you think it can be useful for
creating a supplementary authorization service?  I can foresee all sorts of
operational problems with such a scheme.  As I say, good luck with that.  I
see no direct conflict with RADIUS services or attributes.  It's just that
sometimes CUI can only be related to a specific session, and its
packet-level behaviors, and not to a person.



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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 17:22:43 +0000
Message-ID: <[e-mail]>
Date: Mon, 10 Aug 2009 19:21:56 +0200
From: Tomasz Wolniewicz <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: "David B. Nelson" <[e-mail]>
CC: [e-mail]
Subject: Re: Chargeable-User-Identity
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

David,
  user blacklisting based on and observed misbehaviour is just one of 
the use cases for CUI in eduroam, but there are more.

1. Timely reaction to incidents - if something happens the visited 
institution may have to react at once, by blocking the particular user. 
Going to the home institution and blocking the user there may be the 
next step, but this always takes time. Without CUI the visited site 
would have to block an entire realm until the incident is resolved.

2. Long-time associations. This is actually the case that got me started 
on this subject. eduroam has been created to enable user mobility and 
casual guest access. Now suppose we have two eduroam institutions in one 
city. A student of institution A may set up a permanent wireless link to 
the network of institution B.This is not the kind of guest access that 
most of educational institutions will find desirable. If the user keeps 
changing the MAC address then institution B will have a difficulty 
spotting the actual problem. With CUI in place it is possible to employ 
some QoS and limit the bandwidth after so many bytes transferred. No 
need to track the user or contact the home institution, just apply and 
automatic policy.

3. Promoting the user access rights. A positive example, for a change. 
Suppose we gave an official guest at the university and we want to 
provide him with some extra services. CUI will allow us to place the 
user in a special VLAN and allow printing, for instance. This is a lot 
easier then creating a local account and setting up the user access 
based on that.

4. Guest usage statistics. This is probably self-explanatory.

All these cases require a reasonably long-life CUI, actually we think of 
a permanent one (but changing from one visited institution to another).


David B. Nelson writes:
> Stefan Winter writes...
>
>
>   
>> The user would be banned throughout the (potentially
>> huge) roaming infrastructure, since the home AAA's
>> decision is a global one. If other access networks in 
>> the infrastructure do allow peer-to-peer traffic, it 
>> would be unjust to Reject the user from the home AAA side.
>>     
>
> Unjust?  Well, that's a moral judgment.  Banning the user from *all*
> networks in the consortium would certainly be an effective "punishment" to
> incent the potentially errant user to carefully follow the rules of *any*
> network that they choose to visit.
>
>   
Indeed, but please observe that eduroam is a global project. Accessing a 
certain WWW site could be regarded unacceptable in one country, but 
quite OK in another. We do not want to place the home site administrator 
in a position where he has to take moral judgements whether to ban a 
user from entire eduroam or not. It really is a lot easier to allow the 
local site admin to block the user. Of course, it the user breakes the 
local law then this is another case, but then the law enforcement 
agencies should come in and it will be up to them to reach the home 
institution of the user in order to obtain the actual identity.

Greetings

Tomasz Wolniewicz




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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 15:35:32 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Chargeable-User-Identity
Date: Mon, 10 Aug 2009 11:35:18 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <D1C3A4E42EF8473890B2FF6B9E2F5F5D@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcoZzcW9FCtpMW1vRz6cWcnWu4WBAAAAPuCw

Thomas Wolniewicz writes...

> We do not want to have a chance of sites collecting
> their data together and create user mobility profiles.

Ah.  CUI can accommodate that, in terms of accounting behavior.  As long as
the home AAA server retains all bindings between CUI and the actual user
identity for as long as may be needed for billing reconciliation, it can
issue a unique CUI for every authenticated "session".

That would preclude third parties from tracking the user's roaming behaviors
based on matching up CUI values.  Of course, it would also preclude third
parties from building user blacklists based on CUI values.

> So, when we generate the CUI value we want to feed in the
> User-Name and the visited network identifier and produce an
> opaque value.

I see.  You want a CUI that is re-used for access via a single remote access
provider, for purposes of blacklisting, but not re-used across multiple
providers to prevent them from sharing data and tracking user roaming
patterns.

That much is now clear.

> This is why we want a visited network identifier passed to
> the home institution.

Yep.



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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 15:18:44 +0000
Message-ID: <[e-mail]>
Date: Mon, 10 Aug 2009 17:18:01 +0200
From: Tomasz Wolniewicz <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: "David B. Nelson" <[e-mail]>
CC: [e-mail]
Subject: Re: Chargeable-User-Identity
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

David,
  let me jump in here.
David B. Nelson wrotes:
> Stefan Winter writes...
>
>   
>> It is of course possible to use long-lived IDs.
>>     
>
> OK.
>
>   
>> Our concern comes from using long-lived, *globally
>> valid* IDs.
>>     
>
> Globally valid?  CUI was intended to be valid only to its issuer, i.e., it's
> a "cookie".  All other bets are off.  I see that your use case requires a
> globally unique surrogate user identifier that NASes and Proxies can use to
> build user blacklists.  I'm not sure that the definition of CUI exactly fits
> the bill, in that it's possible for two disjoint home AAA servers to issue
> the same CUI for completely different users.  Unlikely, perhaps, but
> possible.
>   
Well, CUI is intended for mainly accounting purposes, and it is passed
from the home AAA server of the user to the visited organisation, which
can then do its accounting based on the CUI value and pass the bill to
the home site. Right?

CUI is supposed to persistent (or semi-persistent) but in a structure
like eduroam, where the home institution does not know where the user
currently is, we would have no option but to set the CUI to the same
value (for a given amount of time), regardless of the user location.
This is what Stefan calls a "globally valid" CUI. For our needs (and
probably also for most other roaming scenarios) it only matters that the
CUI for a given user stays the same when communicated to the same
visited network. If it is another network, then we can use another CUI
value.
We do not want to have a chance of sites collecting their data together
and create user mobility profiles.
So, when we generate the CUI value we want to feed in the User-Name and
the visited network identifier and produce an opaque value.

This is why we want a visited network identifier passed to the home
institution.

Cheers
Tomasz Wolniewicz

-- 
Tomasz Wolniewicz    
          [e-mail]        http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne   Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika     Nicolaus Copernicus University,
pl. Rapackiego 1, Torun               pl. Rapackiego 1, Torun, Poland
tel: [phone]     fax: [phone]       tel kom.: [phone]


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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 15:05:32 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Chargeable-User-Identity
Date: Mon, 10 Aug 2009 11:05:21 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <DB68F260B4FD46F3817A143A7CFACC98@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcoZwDIx93O7bErYR4WSh4oj9j1fSwACu7gg

Stefan Winter writes...

> It is about proper, service-eligible users that conduct
> unappropriate actions while logged in at some point of
> presence.

Ah.  Bad boys on vacation.  :-)

> The user would be banned throughout the (potentially
> huge) roaming infrastructure, since the home AAA's
> decision is a global one. If other access networks in 
> the infrastructure do allow peer-to-peer traffic, it 
> would be unjust to Reject the user from the home AAA side.

Unjust?  Well, that's a moral judgment.  Banning the user from *all*
networks in the consortium would certainly be an effective "punishment" to
incent the potentially errant user to carefully follow the rules of *any*
network that they choose to visit.



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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 14:59:38 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Chargeable-User-Identity
Date: Mon, 10 Aug 2009 10:59:02 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <880C516331C547EAABBAA997C2002593@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AcoZwadRdXtJ0LIERj6rbNbTltsgpwACIe0g

Stefan Winter writes...

> It is of course possible to use long-lived IDs.

OK.

> Our concern comes from using long-lived, *globally
> valid* IDs.

Globally valid?  CUI was intended to be valid only to its issuer, i.e., it's
a "cookie".  All other bets are off.  I see that your use case requires a
globally unique surrogate user identifier that NASes and Proxies can use to
build user blacklists.  I'm not sure that the definition of CUI exactly fits
the bill, in that it's possible for two disjoint home AAA servers to issue
the same CUI for completely different users.  Unlikely, perhaps, but
possible.

> That is not the intention of CUI as a semi-permanent identifier
> though. 

Correct.



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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 14:35:28 +0000
From: <[e-mail]>
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: REMINDER: Call for adoption of RADIUS for IPv6 Access Networks document as a WG work item
Date: Mon, 10 Aug 2009 16:34:54 +0200
Message-ID: <[e-mail]>
Thread-Topic: REMINDER: Call for adoption of RADIUS for IPv6 Access Networks document as a WG work item
Thread-Index: AcoWN18mfisciI4RSXGOufiV5MFC+AALVAmgAEAJSyATo: <[e-mail]>
Cc: <[e-mail]>

Hey Hannes,

when you just asks those questions.
"I will review the document."

Best regards
 

>-----Ursprüngliche Nachricht-----
>Von: [e-mail] 
>[mailto:[e-mail]] Im Auftrag von Hannes Tschofenig
>Gesendet: Donnerstag, 6. August 2009 09:11
>An: [e-mail]; [e-mail]
>Cc: [e-mail]
>Betreff: RE: REMINDER: Call for adoption of RADIUS for IPv6 
>Access Networks document as a WG work item
>
>"Fine for me" means
>- "I don't care. Do whatever you want." 
>- "I am going to implement it into my AAA server."
>- "I am going to add it to my AAA clients."
>- "I am planning to deploy it."
>- "I will review the document." 
>- "I will contribute to it."
>- "Glen asked me to send a message and here is it."
>? 
>
>So, what do you mean by "fine for me"? 
>
>
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]] On Behalf Of Yungui Wang
>>Sent: 06 August, 2009 04:44
>>To: [e-mail]; [e-mail]
>>Cc: [e-mail]; [e-mail]
>>Subject: RE: REMINDER: Call for adoption of RADIUS for IPv6 Access 
>>Networks document as a WG work item
>>
>>Hello
>>
>>It is fine with me.
>>
>>B.R.
>>Yungui
>>
>>> 
>>> From: [e-mail]
>>[mailto:[e-mail]] On Behalf Of Bernard Aboba
>>> Sent: Friday, June 26, 2009 1:24 PM
>>> To: [e-mail]
>>> Subject: REMINDER: Call for adoption of RADIUS for IPv6 Access
>>Networks document as a WG work item
>>> 
>>>  
>>> 
>>> This is a reminder of an ongoing call for review of the document
>>"RADIUS attributes for IPv6 Access Networks" for adoption as a RADEXT 
>>WG work item.  This document is being targeted at Proposed Standard 
>>status.
>>>  
>>> The document is available for review here:
>>> http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access
>>> 
>>> This call for review will last until August 7, 2009.  Please
>>send email to the RADEXT WG mailing list indicating whether 
>you support 
>>adoption of this document as a RADEXT WG work item.  If you have 
>>comments on the document, please also send these to the list in the 
>>format described on the RADEXT WG Issues list:
>>> http://www.drizzle.com/~aboba/RADEXT/
>>> 
>>> 
>>
>>
>>--
>>to unsubscribe send a message to
>>[e-mail] with the word 'unsubscribe' in 
>a single 
>>line as the message text body.
>>archive: <http://psg.com/lists/radiusext/>
>>
>
>
>--
>to unsubscribe send a message to [e-mail] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>
>

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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 13:48:09 +0000
Message-ID: <[e-mail]>
Date: Mon, 10 Aug 2009 15:47:54 +0200
From: Stefan Winter <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (X11/20090605)
MIME-Version: 1.0
To: Dave Nelson <[e-mail]>
CC: [e-mail]
Subject: Re: Chargeable-User-Identity
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Hi,

> Yes.  In drafting the document, support for anonymity of the user was a
> requirement.  It was felt that a long-lived ID could be used to track the
> user and violate his/her privacy, and thus the CUI *could* be short-lived.
> IIRC, it need not be however.
>
> Exactly what normative text of the RFC do you think prohibits you from using
> long-lived IDs?
>   


It is of course possible to use long-lived IDs. Our concern comes from
using long-lived, *globally valid* IDs. If there are many service
providers in an infrastructure, and all get the same CUI, they could
co-operate and create a mobility profile for the user.
One approach is to keep a global CUI, but make its lifetime rather
short. That is not the intention of CUI as a semi-permanent identifier
though. So we are trying to pursue this other way; but then, a handle to
distinguish service providers from one another becomes necessary.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]


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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 13:38:51 +0000
Message-ID: <[e-mail]>
Date: Mon, 10 Aug 2009 15:38:15 +0200
From: Stefan Winter <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (X11/20090605)
MIME-Version: 1.0
To: Dave Nelson <[e-mail]>
CC: [e-mail]
Subject: Re: Chargeable-User-Identity
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Hi,

I should have been more verbose...

> By "fraudulent", do you mean a user that is unknown or invalid at the home
> AAA server?  Or do you have some other thought in mind?
>   

It is about proper, service-eligible users that conduct unappropriate
actions while logged in at some point of presence. Like, downloading
terabytes of data via peer to peer links on sites that have spelled out
to forbid this kind of usage. An access network may want to prevent this
user from re-entering the network; but that is a local decision of that
access network only.

> Well, if the home AAA server continually sends Access-Reject, the user would
> be permanently banned.  No?
>   

That's correct. The user would be banned throughout the (potentially
huge) roaming infrastructure, since the home AAA's decision is a global
one. If other access networks in the infrastructure do allow
peer-to-peer traffic, it would be unjust to Reject the user from the
home AAA side.

> So, I'm thinking you likely have another idea in mind, such as protecting
> from DoS attacks or use of resources in the roaming partner's network by
> unauthorized users.  A pre-authentication sort of behavior, like Call-Check
> used to provide in dial-up networks.
>
>   
>> .. E.g. a user could change his MAC and outer identity on every
>> re-connect, and evade blocking measures ...
>>     
>
> Blocking where, exactly? 
>   

With the (limited) user identification of RADIUS, a NAS can only act
upon properties like MAC address and EAP outer identity. This check
would be during the authentication phase. Since both parameters are
insufficient, a CUI would be transferred on Access-Accept as an opaque,
permanent, handle of the user, tied to (but to preserve privacy, not
reverse-calculatable to) the inner identity. Then the access network can ...

>> ...if no permanent opaque handle identifies him on return.
>>     
>
> Well, keep in mind that CUI was designed to be an opaque cookie of meaning
> only to it's issuer, the home AAA server.  Edge devices, e.g. NASes could do
> a binary comparison for equality to tell that one CUI is the same as
> another. That much is feasible.  Are you suggesting that NASes keep a
> "denied parties list" or "blacklist" of CUIs?
>   

... do exactly that: blacklist the CUI in question.

>   
>> ...since there is no reliable end-to-end identifier for
>> service providers...
>>     
>
> Nor has there event been one in RADIUS.
>   

True. But when operating a clearing-house, it could be made one of the
duties of the clearing-house to tag incoming requests per service
provider according to the source.

>> ... the home server may not know which business partner
>> it is talking to - it sees only the proxy's connection.
>>     
>
> Well, it is in fact only "talking' to the immediate proxy.  It has to rely
> on the chain of proxies to "do the right thing" on its behalf.  That's also
> a central tenet of the RADIUS architecture, limiting as that my be in
> certain circumstances.  You simply have to trust the proxies.
>   

Sure. The proxy is trusted, and in the particular case is trusted to add
the correct service provider identifier. This whole topic is *not* about
distrusting proxies, it's about distrusting end users and being able to
convey reliable information about them across the infrastructure.

>> A concrete example from the RFC is: "For example, the lifetime can be
>> set to one billing period." A home server H doing business with two
>> service providers S1 (billing period: end of month), S2 (billing period:
>> 25th of every odd month) via a proxy P would need to see an identifier
>> for S1, S2 when receiving Access-Requests from P to adjust the CUIs it
>> generates properly, and roll them over at the appropriate end of billing
>> period.
>>     
>
> That assumes the home server tries to optimize its data storage and internal
> state by the clever the "re-use" of CUIs.  The [unstated] idea behind CUI
> was that it would be converted back to the true user identity when received
> at the home RADIUS accounting server, as a trusted extension of the home
> RADIUS server, it is entitled to know how to decode the CUI contents.
>
> Are you saying that the home provider expects to get a detailed bill from
> each remote partner that includes connect minutes associated with each
> corresponding CUI and will attempt to reconcile that bill for potential
> fraud?
>   

Since it's not my own example, merely a use-case quote from the RFC, I
can't say much more about the intent. The RFC says that a home server
might want to change the CUI per billing period; I say that there might
be different billing periods for multiple service providers hidden
behind the same proxy, and so the home server needs to know who exactly
asked for auth. And that's it.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]


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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 13:08:41 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Chargeable-User-Identity
Date: Mon, 10 Aug 2009 09:08:19 -0400
Message-ID: <8B4A408B19B14FA5972A5D2F0E39DC0E@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcoZhNAHeVjmwU1MQkyEeYxNLzo57wAM7lsQAACrG5A
Following up on my last posting...

> Are you suggesting that NASes keep a "denied parties list" or
> "blacklist" of CUIs?

Well, that clearly makes no sense.  What was I thinking?  The NAS would have
no CUI for comparison until the home AAA server round trip was completed.

I guess I'll stop hypothesizing and let you explain what it is you're trying
to accomplish. :-)



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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 13:02:23 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Chargeable-User-Identity
Date: Mon, 10 Aug 2009 09:01:54 -0400
Message-ID: <5A1555961F4C4B0495923ABDAEFAF05E@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcoZhNAHeVjmwU1MQkyEeYxNLzo57wAM7lsQ

Stefan Winter writes...

Let me try to understand you usage a little better.

> Our motivation is not billing, but being able to recognize
> fraudulent users when they return...

By "fraudulent", do you mean a user that is unknown or invalid at the home
AAA server?  Or do you have some other thought in mind?

> ... to have a means of permanently banning them.

Well, if the home AAA server continually sends Access-Reject, the user would
be permanently banned.  No?

So, I'm thinking you likely have another idea in mind, such as protecting
from DoS attacks or use of resources in the roaming partner's network by
unauthorized users.  A pre-authentication sort of behavior, like Call-Check
used to provide in dial-up networks.

> .. E.g. a user could change his MAC and outer identity on every
> re-connect, and evade blocking measures ...

Blocking where, exactly? 

> ...if no permanent opaque handle identifies him on return.

Well, keep in mind that CUI was designed to be an opaque cookie of meaning
only to it's issuer, the home AAA server.  Edge devices, e.g. NASes could do
a binary comparison for equality to tell that one CUI is the same as
another. That much is feasible.  Are you suggesting that NASes keep a
"denied parties list" or "blacklist" of CUIs?

> ...since there is no reliable end-to-end identifier for
> service providers...

Nor has there event been one in RADIUS.

> ... the home server may not know which business partner
> it is talking to - it sees only the proxy's connection.

Well, it is in fact only "talking' to the immediate proxy.  It has to rely
on the chain of proxies to "do the right thing" on its behalf.  That's also
a central tenet of the RADIUS architecture, limiting as that my be in
certain circumstances.  You simply have to trust the proxies.

> A concrete example from the RFC is: "For example, the lifetime can be
> set to one billing period." A home server H doing business with two
> service providers S1 (billing period: end of month), S2 (billing period:
> 25th of every odd month) via a proxy P would need to see an identifier
> for S1, S2 when receiving Access-Requests from P to adjust the CUIs it
> generates properly, and roll them over at the appropriate end of billing
> period.

That assumes the home server tries to optimize its data storage and internal
state by the clever the "re-use" of CUIs.  The [unstated] idea behind CUI
was that it would be converted back to the true user identity when received
at the home RADIUS accounting server, as a trusted extension of the home
RADIUS server, it is entitled to know how to decode the CUI contents.

Are you saying that the home provider expects to get a detailed bill from
each remote partner that includes connect minutes associated with each
corresponding CUI and will attempt to reconcile that bill for potential
fraud?



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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 12:25:42 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Chargeable-User-Identity and Operator-Name
Date: Mon, 10 Aug 2009 08:25:30 -0400
Message-ID: <9B827D7C7B784AED84B85E17F96F5AC1@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcoZqshabGi9P4lYTbitLfuEFSX6QQACfe8A

Tomasz Wolniewicz writes...

> The unconditional MUST in the quoted paragraph seems
> to be too strong.

MUST makes for highly predictable behavior in a protocol and leads to
interoperable implementations.

There is an implicit assumption of trust between a NAS and RADIUS server
that's central to the RADIUS architecture.  I understand that proxies and
roaming consortia may have business, legal, privacy and other non-protocol
concerns that make RADIUS a less than ideal protocol for such use cases.

The problem is that, in the absence of a real capabilities negotiation
feature in RADIUS, SHOULD and other forms of variable behavior make the
implementation and error recovery design needlessly complicated.



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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 12:17:10 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Chargeable-User-Identity
Date: Mon, 10 Aug 2009 08:16:25 -0400
Message-ID: <7EAFF0A0A1794D3EBD594F70458D9983@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcoZhNAHeVjmwU1MQkyEeYxNLzo57wALuw7g

Stefan Winter writes...

> The RFC says that the business agreement between service
> provider and home server determines the lifetime of a CUI.

Yes.  In drafting the document, support for anonymity of the user was a
requirement.  It was felt that a long-lived ID could be used to track the
user and violate his/her privacy, and thus the CUI *could* be short-lived.
IIRC, it need not be however.

Exactly what normative text of the RFC do you think prohibits you from using
long-lived IDs?



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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 11:04:52 +0000
Message-ID: <[e-mail]>
Date: Mon, 10 Aug 2009 13:04:04 +0200
From: Tomasz Wolniewicz <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: [e-mail]
Subject: Chargeable-User-Identity and Operator-Name
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 7bit

There is one more issue about the CUI.
The RFC states:

   If a home RADIUS server that supports the CUI attribute receives an
   Access-Request packet containing a CUI (set to nul or otherwise), it
   MUST include the CUI attribute in the Access-Accept packet.

As Stefan has described, the information about the visited institution
may be important for the CUI generation. In our (eduroam) case we would
want to generate different CUI values for different visited networks,
but in scenarios described by Stefan, the information about the visited
institution is also crucial. Therefore I would see it as completely
justified to say, that a server supporting the CUI can refrain from
sending it, if some of additional policy-related conditions have not
been met (for instance there is no business agreement stating that this
should be done for a particular visited network or that the
Access-Request does not carry an additional attribute required by this
business agreement).

The unconditional MUST in the quoted paragraph seems to be too strong.

Greetings
Tomasz Wolniewicz

-- 
Tomasz Wolniewicz    
          [e-mail]        http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne   Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika     Nicolaus Copernicus University,
pl. Rapackiego 1, Torun               pl. Rapackiego 1, Torun, Poland
tel: [phone]     fax: [phone]       tel kom.: [phone]


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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 09:05:59 +0000
Message-ID: <[e-mail]>
Date: Mon, 10 Aug 2009 11:05:35 +0200
From: Stefan Winter <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (X11/20090605)
MIME-Version: 1.0
To: [e-mail],  "[e-mail]" <[e-mail]>
Subject: Re: Chargeable-User-Identity
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Hi,

> anything new from the RADIUS server... The "Namespace ID" values 
> are intentionally printable ASCII digits, so you could treat
> the whole attribute as one string, and put something like
> 'if Operator-Name = "1example.com" then...' in your RADIUS
> configuration.
>   

Sure. Not exactly clean, but an acceptable workaround.

Stefan

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]


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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 09:04:13 +0000
From: <[e-mail]>
To: <[e-mail]>
CC: <[e-mail]>
Date: Mon, 10 Aug 2009 11:03:48 +0200
Subject: RE: Chargeable-User-Identity
Thread-Topic: Chargeable-User-Identity
Thread-Index: AcoZmET0wlDkQFnORGiHr7wXmtfeCAAACm1A
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Stefan Winter wrote:

> > RFC 5580 does specify an "Operator-Name" attribute (to identify the
> > access network operator/"NAS owner") -- would it be useful in your
> > situation?
> >
> 
> Oh! Cute. That's exactly the thing. Thanks!
> 
> Now the only problem is to find RADIUS servers that support the unusual
> encoding of 5580 attributes to parse the content of Operator-Name. But
> that's not for this mailing list to solve :-)

Many of the other attributes in RFC 5580 indeed have complex
encodings, but using Operator-Name doesn't necessarily require
anything new from the RADIUS server... The "Namespace ID" values 
are intentionally printable ASCII digits, so you could treat
the whole attribute as one string, and put something like
'if Operator-Name == "1example.com" then...' in your RADIUS
configuration.

Best regards,
Pasi


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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 08:55:28 +0000
Message-ID: <[e-mail]>
Date: Mon, 10 Aug 2009 10:54:49 +0200
From: Stefan Winter <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (X11/20090605)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Chargeable-User-Identity
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Hi,

> RFC 5580 does specify an "Operator-Name" attribute (to identify the
> access network operator/"NAS owner") -- would it be useful in your
> situation?
>   

Oh! Cute. That's exactly the thing. Thanks!

Now the only problem is to find RADIUS servers that support the unusual
encoding of 5580 attributes to parse the content of Operator-Name. But
that's not for this mailing list to solve :-)

Greetings,

Stefan Winter

> Best regards,
> Pasi
>
>   
>> -----Original Message-----
>> From: [e-mail] [mailto:owner-
>> [e-mail]] On Behalf Of ext Stefan Winter
>> Sent: 10 August, 2009 09:32
>> To: [e-mail]
>> Subject: Chargeable-User-Identity
>>
>> Hello,
>>
>> in eduroam, we are just about starting to make real use of the
>> Chargeable-User-Identity (RFC4372). Our motivation is not billing, but
>> being able to recognise fraudulent users when they return, to have a
>> means of permanently banning them. E.g. a user could change his MAC and
>> outer identity on every re-connect, and evade blocking measures if no
>> permanent opaque handle identifies him on return.
>>
>> We are mostly happy with the RFC, but one of my colleagues stumbled
>> upon
>> something. The RFC says that the business agreement between service
>> provider and home server determines the lifetime of a CUI. While that's
>> correct, there is a problem when intermediate proxies are involved
>> (like
>> a clearing-house): since there is no reliable end-to-end identifier for
>> service providers, the home server may not know which business partner
>> it is talking to - it sees only the proxy's connection.
>> A concrete example from the RFC is: "For example, the lifetime can be
>> set to one billing period." A home server H doing business with two
>> service providers S1 (billing period: end of month), S2 (billing
>> period:
>> 25th of every odd month) via a proxy P would need to see an identifier
>> for S1, S2 when receiving Access-Requests from P to adjust the CUIs it
>> generates properly, and roll them over at the appropriate end of
>> billing
>> period.
>>
>> There is not currently a standard attribute to convey this information.
>> NAS-IP-Address and NAS-Identifier are semantically bound to a single
>> NAS. A service provider can operate multiple NASes, on the same or
>> different access media.
>>
>> I'm not sure if there is much to do about this. I suppose a good
>> real-life way to do this is to set a VSA with the information, and make
>> sure that P sets it for its customers. I wonder if it's worth defining
>> a
>> properly standardised attribute for this though (since implementing
>> RFC4372 seems to implicitly require its existence)...
>>
>> Greetings,
>>
>> Stefan Winter
>>
>> --
>> Stefan WINTER
>> Ingenieur de Recherche
>> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
>> de la Recherche
>> 6, rue Richard Coudenhove-Kalergi
>> L-1359 Luxembourg
>>
>> Tel: [phone]
>> Fax: [phone]
>>
>>
>> --
>> to unsubscribe send a message to [e-mail] with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://psg.com/lists/radiusext/>
>>     
>
> --
> to unsubscribe send a message to [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>   


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]


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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 08:19:31 +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: RE: Chargeable-User-Identity
Date: Mon, 10 Aug 2009 10:18:33 +0200
Message-ID: <D109C8C97C15294495117745780657AE0BDC935C@ftrdmel1>
Thread-Topic: Chargeable-User-Identity
Thread-Index: AcoZhGiczfLT9uGZT46x8YqoZMRmKwAAICpQAANf/iAFrom: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>

Hi Stephan,

It should be! The Operator-Name attribute was defined for that :)

Best Regards,

Lionel

> -----Message d'origine-----
> De : [e-mail] 
> [mailto:[e-mail]] De la part de 
> [e-mail]
> Envoyé : lundi 10 août 2009 08:42
> À : [e-mail]; [e-mail]
> Objet : RE: Chargeable-User-Identity
> 
> Hi,
> 
> RFC 5580 does specify an "Operator-Name" attribute (to 
> identify the access network operator/"NAS owner") -- would it 
> be useful in your situation?
> 
> Best regards,
> Pasi
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:owner- 
> > [e-mail]] On Behalf Of ext Stefan Winter
> > Sent: 10 August, 2009 09:32
> > To: [e-mail]
> > Subject: Chargeable-User-Identity
> > 
> > Hello,
> > 
> > in eduroam, we are just about starting to make real use of the 
> > Chargeable-User-Identity (RFC4372). Our motivation is not 
> billing, but 
> > being able to recognise fraudulent users when they return, 
> to have a 
> > means of permanently banning them. E.g. a user could change his MAC 
> > and outer identity on every re-connect, and evade blocking 
> measures if 
> > no permanent opaque handle identifies him on return.
> > 
> > We are mostly happy with the RFC, but one of my colleagues stumbled 
> > upon something. The RFC says that the business agreement between 
> > service provider and home server determines the lifetime of a CUI. 
> > While that's correct, there is a problem when intermediate 
> proxies are 
> > involved (like a clearing-house): since there is no reliable 
> > end-to-end identifier for service providers, the home 
> server may not 
> > know which business partner it is talking to - it sees only the 
> > proxy's connection.
> > A concrete example from the RFC is: "For example, the 
> lifetime can be 
> > set to one billing period." A home server H doing business with two 
> > service providers S1 (billing period: end of month), S2 (billing
> > period:
> > 25th of every odd month) via a proxy P would need to see an 
> identifier 
> > for S1, S2 when receiving Access-Requests from P to adjust 
> the CUIs it 
> > generates properly, and roll them over at the appropriate end of 
> > billing period.
> > 
> > There is not currently a standard attribute to convey this 
> information.
> > NAS-IP-Address and NAS-Identifier are semantically bound to 
> a single 
> > NAS. A service provider can operate multiple NASes, on the same or 
> > different access media.
> > 
> > I'm not sure if there is much to do about this. I suppose a good 
> > real-life way to do this is to set a VSA with the information, and 
> > make sure that P sets it for its customers. I wonder if it's worth 
> > defining a properly standardised attribute for this though (since 
> > implementing
> > RFC4372 seems to implicitly require its existence)...
> > 
> > Greetings,
> > 
> > Stefan Winter
> > 
> > --
> > Stefan WINTER
> > Ingenieur de Recherche
> > Fondation RESTENA - Réseau Téléinformatique de l'Education 
> Nationale 
> > et de la Recherche 6, rue Richard Coudenhove-Kalergi
> > L-1359 Luxembourg
> > 
> > Tel: [phone]
> > Fax: [phone]
> > 
> > 
> > --
> > to unsubscribe send a message to 
> [e-mail] with 
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> 
> --
> to unsubscribe send a message to 
> [e-mail] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 06:42:31 +0000
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Date: Mon, 10 Aug 2009 08:41:50 +0200
Subject: RE: Chargeable-User-Identity
Thread-Topic: Chargeable-User-Identity
Thread-Index: AcoZhGiczfLT9uGZT46x8YqoZMRmKwAAICpQ
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi,

RFC 5580 does specify an "Operator-Name" attribute (to identify the
access network operator/"NAS owner") -- would it be useful in your
situation?

Best regards,
Pasi

> -----Original Message-----
> From: [e-mail] [mailto:owner-
> [e-mail]] On Behalf Of ext Stefan Winter
> Sent: 10 August, 2009 09:32
> To: [e-mail]
> Subject: Chargeable-User-Identity
> 
> Hello,
> 
> in eduroam, we are just about starting to make real use of the
> Chargeable-User-Identity (RFC4372). Our motivation is not billing, but
> being able to recognise fraudulent users when they return, to have a
> means of permanently banning them. E.g. a user could change his MAC and
> outer identity on every re-connect, and evade blocking measures if no
> permanent opaque handle identifies him on return.
> 
> We are mostly happy with the RFC, but one of my colleagues stumbled
> upon
> something. The RFC says that the business agreement between service
> provider and home server determines the lifetime of a CUI. While that's
> correct, there is a problem when intermediate proxies are involved
> (like
> a clearing-house): since there is no reliable end-to-end identifier for
> service providers, the home server may not know which business partner
> it is talking to - it sees only the proxy's connection.
> A concrete example from the RFC is: "For example, the lifetime can be
> set to one billing period." A home server H doing business with two
> service providers S1 (billing period: end of month), S2 (billing
> period:
> 25th of every odd month) via a proxy P would need to see an identifier
> for S1, S2 when receiving Access-Requests from P to adjust the CUIs it
> generates properly, and roll them over at the appropriate end of
> billing
> period.
> 
> There is not currently a standard attribute to convey this information.
> NAS-IP-Address and NAS-Identifier are semantically bound to a single
> NAS. A service provider can operate multiple NASes, on the same or
> different access media.
> 
> I'm not sure if there is much to do about this. I suppose a good
> real-life way to do this is to set a VSA with the information, and make
> sure that P sets it for its customers. I wonder if it's worth defining
> a
> properly standardised attribute for this though (since implementing
> RFC4372 seems to implicitly require its existence)...
> 
> Greetings,
> 
> Stefan Winter
> 
> --
> Stefan WINTER
> Ingenieur de Recherche
> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
> de la Recherche
> 6, rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
> 
> Tel: [phone]
> Fax: [phone]
> 
> 
> --
> to unsubscribe send a message to [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 06:32:47 +0000
Message-ID: <[e-mail]>
Date: Mon, 10 Aug 2009 08:32:26 +0200
From: Stefan Winter <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (X11/20090605)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Chargeable-User-Identity
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

Hello,

in eduroam, we are just about starting to make real use of the
Chargeable-User-Identity (RFC4372). Our motivation is not billing, but
being able to recognise fraudulent users when they return, to have a
means of permanently banning them. E.g. a user could change his MAC and
outer identity on every re-connect, and evade blocking measures if no
permanent opaque handle identifies him on return.

We are mostly happy with the RFC, but one of my colleagues stumbled upon
something. The RFC says that the business agreement between service
provider and home server determines the lifetime of a CUI. While that's
correct, there is a problem when intermediate proxies are involved (like
a clearing-house): since there is no reliable end-to-end identifier for
service providers, the home server may not know which business partner
it is talking to - it sees only the proxy's connection.
A concrete example from the RFC is: "For example, the lifetime can be
set to one billing period." A home server H doing business with two
service providers S1 (billing period: end of month), S2 (billing period:
25th of every odd month) via a proxy P would need to see an identifier
for S1, S2 when receiving Access-Requests from P to adjust the CUIs it
generates properly, and roll them over at the appropriate end of billing
period.

There is not currently a standard attribute to convey this information.
NAS-IP-Address and NAS-Identifier are semantically bound to a single
NAS. A service provider can operate multiple NASes, on the same or
different access media.

I'm not sure if there is much to do about this. I suppose a good
real-life way to do this is to set a VSA with the information, and make
sure that P sets it for its customers. I wonder if it's worth defining a
properly standardised attribute for this though (since implementing
RFC4372 seems to implicitly require its existence)...

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]


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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 06:05:57 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_b0021973-0d3b-4f3d-8cbf-6791f5b88cdf_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Review of draft-ietf-radext-dynamic-discovery-01
Date: Sun, 9 Aug 2009 23:05:19 -0700
MIME-Version: 1.0

--_b0021973-0d3b-4f3d-8cbf-6791f5b88cdf_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Abstract

   This document specifies a means to find authoritative AAA servers for
   a given NAI realm as defined in [RFC4282].  It can be used in
   conjunction with RADIUS over TLS and RADIUS over DTLS.

[BA] References aren't allowed in the abstract.  Also, this is only about RADIUS, not AAA in general, no?

1.2

   RadSec node: a RadSec client or server

   RadSec Client: a RadSec instance which initiates a new connection.

   RadSec Server: a RadSec instance which listens on a RadSec port and
   accepts new connections

[BA] As we discussed at IETF 75, RadSec is a product name.  Can we use "RADIUS over TLS" and "RADIUS over DTLS" 
(or maybe RAD-TLS and RAD-DTLS) instead?

Section 2.1

   Dynamic server discovery as defined in this document is only
   applicable for AAA transactions where a AAA server receives a request
   with a NAI realm for which no home AAA server is known.  I.e. where
   static server configuration does not contain a known home
   authentication server, or where the server configuration explicitly
   states that the realm destination is to be looked up dynamically.
   Furthermore, it is only applicable for new user sessions, i.e. for
   the initial Access-Request.  

[BA] Is this about AAA in general (including Diameter) or just about RADIUS?

2.2.  DNS RR definition

   DNS definitions of RadSec servers can be either NAPTR records or SRV
   records.  When both are defined, the resolution algorithm prefers
   NAPTR results (see section Section 2.3 below).  The NAPTR service
   field used is "AAAS+RADSECT".  The SRV prefix used is "_radsec._tcp".
   It is expected that in most cases, the label used for the records is
   the DNS representation (punycode) of the literal realm name for which
   the server is the AAA server.

[BA] Given that RadSec is a product name, what should the SRV prefixes be? 
_radtls._tcp?  _raddtls._udp? 

   bank-rupt.com

[BA] Suggest use of an example.com domain instead (e.g. bank.example.com). 

2.3.  Realm to AAA server resolution algorithm

   Input I to the algorithm is a User-Name in the form of a NAI as
   defined in [RFC4282] as extracted from the User-Name attribute in an
   Access-Request.  Output O of the algorithm is a set of hostname:port
   and an assoiciated order/preference; the set can be empty.

   Note well: The attribute User-Name does not necessarily contain well-
   formed NAIs and may not even contain well-formed UTF-8 strings.  This
   document describes server discovery only for well-formed NAIs in
   UTF-8 encoding.  The result of all other possible contents of User-
   Name is unspecified; this includes, but is not limited to:

[BA] Given the problems with RFC 4282 described by Alan at IETF 73, I'd suggest not referencing RFC 4282
if possible, just focusing on the User-Name attribute, which is defined as UTF-8 by RFC 2865. 

As far as I can tell here, the issue here is whether it is possible to utilize the realm-name in UTF-8
to resolve the address of the RADTLS/DTLS server.  As noted in the IAB document, there are several possible
ways that this resolution could take place:

a. An A/AAAA query could be sent via mDNS and/or LLMNR, using the realm encoded in UTF-8. 
b. An A/AAAA query could be sent, by converting the realm in UTF-8 to punycode, using ToASCII(). 
c. An A/AAAA query could be sent, using the realm encoded in UTF-8. 

When attempting resolution via b), it is possible that the conversion will fail.  If none of the other 
resolution mechanisms are attempted, or if they fail too, then resolution of the server will not be 
possible.

Now that the IDNAbis documents are headed toward WG last call, my recommendation is to reference these,
rather than IDNA. 

2.3.  Realm to AAA server resolution algorithm

In addition to the material here, I recommend providing advice on IPv4/IPv6 usage.  One issue that
has been encountered in IPv6 implementations is that attempting to connect via IPv6 preferentially
is problematic.  Even though a AAAA RR might be available, and IPv6 might be supported and available
on a link, this doesn't mean that IPv6 connectivity exists, due to routing table issues.  As a result,
attempting bring up an IPv6 connection before failing over to IPv4 will often result in a performance
problem.  A better approach (implemented in MacOS X) is to attempt to bring up both IPv4 and IPv6
connections and then use the connection that comes up first. 

Section 3

   [Note:
   assuming here that a hypothetical RADIUS/UDP SRV discovery will NOT
   deliver the shared secret in the DNS response!]

[BA] I certainly hope not. This somewhat begs the question of when server resolution is useful.  Presumably,
this is primarily for use with certificate-based authentication, no?  I'd assume that if TLS PSK is being
used then you'd have static configuration, correct?

Section 4

   This document contains no actions for IANA.  Maybe.  Not sure about
   the labels "AAAS+RADSECT" and "_radsec._tcp.".

[BA] What about RADIUS over DTLS?  Does this document apply to that as well? 



   the labels "AAAS+RADSECT" and "_radsec._tcp.".







--_b0021973-0d3b-4f3d-8cbf-6791f5b88cdf_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Abstract<br><br><pre class="newpage">   This document specifies a means to find authoritative AAA servers for<br>   a given NAI realm as defined in [<a href="http://tools.ietf.org/html/rfc4282" title="&quot;The Network Access Identifier&quot;">RFC4282</a>].  It can be used in<br>   conjunction with RADIUS over TLS and RADIUS over DTLS.<br><br>[BA] References aren't allowed in the abstract.  Also, this is only about RADIUS, not AAA in general, no?<br><br>1.2<br><br>   RadSec node: a RadSec client or server<br><br>   RadSec Client: a RadSec instance which initiates a new connection.<br><br>   RadSec Server: a RadSec instance which listens on a RadSec port and<br>   accepts new connections<br><br>[BA] As we discussed at IETF 75, RadSec is a product name.  Can we use "RADIUS over TLS" and "RADIUS over DTLS" <br>(or maybe RAD-TLS and RAD-DTLS) instead?<br><br>Section 2.1<br><br>   Dynamic server discovery as defined in this document is only<br>   applicable for AAA transactions where a AAA server receives a request<br>   with a NAI realm for which no home AAA server is known.  I.e. where<br>   static server configuration does not contain a known home<br>   authentication server, or where the server configuration explicitly<br>   states that the realm destination is to be looked up dynamically.<br>   Furthermore, it is only applicable for new user sessions, i.e. for<br>   the initial Access-Request.  <br><br>[BA] Is this about AAA in general (including Diameter) or just about RADIUS?<br><br><span class="h3"><h3><a name="section-2.2">2.2</a>.  DNS RR definition</h3></span><br><br>   DNS definitions of RadSec servers can be either NAPTR records or SRV<br>   records.  When both are defined, the resolution algorithm prefers<br>   NAPTR results (see section <a href="http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery-01#section-2.3">Section 2.3</a> below).  The NAPTR service<br>   field used is "AAAS+RADSECT".  The SRV prefix used is "_radsec._tcp".<br>   It is expected that in most cases, the label used for the records is<br>   the DNS representation (punycode) of the literal realm name for which<br>   the server is the AAA server.<br><br>[BA] Given that RadSec is a product name, what should the SRV prefixes be? <br>_radtls._tcp?  _raddtls._udp? <br><br>   bank-rupt.com<br><br>[BA] Suggest use of an example.com domain instead (e.g. bank.example.com). <br><br><span class="h3"><h3><a name="section-2.3">2.3</a>.  Realm to AAA server resolution algorithm</h3></span><br><br>   Input I to the algorithm is a User-Name in the form of a NAI as<br>   defined in [<a href="http://tools.ietf.org/html/rfc4282" title="&quot;The Network Access Identifier&quot;">RFC4282</a>] as extracted from the User-Name attribute in an<br>   Access-Request.  Output O of the algorithm is a set of hostname:port<br>   and an assoiciated order/preference; the set can be empty.<br><br>   Note well: The attribute User-Name does not necessarily contain well-<br>   formed NAIs and may not even contain well-formed UTF-8 strings.  This<br>   document describes server discovery only for well-formed NAIs in<br>   UTF-8 encoding.  The result of all other possible contents of User-<br>   Name is unspecified; this includes, but is not limited to:<br><br>[BA] Given the problems with RFC 4282 described by Alan at IETF 73, I'd suggest not referencing RFC 4282<br>if possible, just focusing on the User-Name attribute, which is defined as UTF-8 by RFC 2865. <br><br>As far as I can tell here, the issue here is whether it is possible to utilize the realm-name in UTF-8<br>to resolve the address of the RADTLS/DTLS server.  As noted in the IAB document, there are several possible<br>ways that this resolution could take place:<br><br>a. An A/AAAA query could be sent via mDNS and/or LLMNR, using the realm encoded in UTF-8. <br>b. An A/AAAA query could be sent, by converting the realm in UTF-8 to punycode, using ToASCII(). <br>c. An A/AAAA query could be sent, using the realm encoded in UTF-8. <br><br>When attempting resolution via b), it is possible that the conversion will fail.  If none of the other <br>resolution mechanisms are attempted, or if they fail too, then resolution of the server will not be <br>possible.<br><br>Now that the IDNAbis documents are headed toward WG last call, my recommendation is to reference these,<br>rather than IDNA. <br><br><span class="h3"><h3><a name="section-2.3">2.3</a>.  Realm to AAA server resolution algorithm</h3></span><br><br>In addition to the material here, I recommend providing advice on IPv4/IPv6 usage.  One issue that<br>has been encountered in IPv6 implementations is that attempting to connect via IPv6 preferentially<br>is problematic.  Even though a AAAA RR might be available, and IPv6 might be supported and available<br>on a link, this doesn't mean that IPv6 connectivity exists, due to routing table issues.  As a result,<br>attempting bring up an IPv6 connection before failing over to IPv4 will often result in a performance<br>problem.  A better approach (implemented in MacOS X) is to attempt to bring up both IPv4 and IPv6<br>connections and then use the connection that comes up first. <br><br>Section 3<br><br>   [Note:<br>   assuming here that a hypothetical RADIUS/UDP SRV discovery will NOT<br>   deliver the shared secret in the DNS response!]<br><br>[BA] I certainly hope not. This somewhat begs the question of when server resolution is useful.  Presumably,<br>this is primarily for use with certificate-based authentication, no?  I'd assume that if TLS PSK is being<br>used then you'd have static configuration, correct?<br><br>Section 4<br><br>   This document contains no actions for IANA.  Maybe.  Not sure about<br>   the labels "AAAS+RADSECT" and "_radsec._tcp.".<br><br>[BA] What about RADIUS over DTLS?  Does this document apply to that as well? <br><br><br><br>   the labels "AAAS+RADSECT" and "_radsec._tcp.".<br><br><br><br><br></pre><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table></body>
</html>
--_b0021973-0d3b-4f3d-8cbf-6791f5b88cdf_--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 05:09:45 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_3bc8b54e-0ca2-4f86-978d-465168933018_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Re:  REMINDER: RADEXT WG Last Call on Status Server document (part 2)
Date: Sun, 9 Aug 2009 22:09:24 -0700
MIME-Version: 1.0

--_3bc8b54e-0ca2-4f86-978d-465168933018_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Section 4.3
   When a client fails over from one server to another because of a lack
   of responsiveness, it SHOULD send periodic Status-Server packets to
   the unresponsive server, using the timer (Tw) defined above.

[BA] Can you provide a section reference for the Tw timer?

   Once three time periods have passed where Status-Server packets have
   been sent and responded to, the server should be deemed responsive
   and RADIUS requests may sent to it again.  This determination should
   be made separately for each server that the client has a relationship
   with.  The same algorithm should be used for both authentication and
   accounting ports.  The client MUST treat each destination (ip, port)
   combination as a unique server for the purposes of this
   determination.

   The above behavior is modelled after [RFC3539] Section 3.4.1.  We
   note that if a reliable transport is used for RADIUS, then the
   algorithms specified in [RFC3539] MUST be used in preference to the
   ones given here.

[BA] I think a bit more explanation would be helpful here.  Traditional "failover" algorithms have
depended on use of Access-Request packets.  Unfortunately, these techniques can lead a client to failover
in circumstances where there is nothing wrong with the primary proxy.  So in reading the first paragraph,
I'm unclear what is being advocated, precisely.  For example, is it being advocated that a Status-Server 
packet be sent to the primary proxy after a number of Access-Requests do not receive a response?  That
would help determine whether the primary proxy was the issue in the first place.  If it is not the issue
(e.g. primary proxy responds), then sending Status-Server packets to the primary proxy would seem
pointless.  

If the primary proxy is responding to Status-Server, then the problem must be downstream, and it might
make sense for the client to continue to send Access-Requests for a while longer, under the assumption
that those downstream elements are also attempting to diagnose the problem (possibly with Status-Server),
so that in the meantime they might also fail-over, restoring end-to-end RADIUS connectivity.  Based on the
algorithms presented in RFC 5080, one might come up with some recommendations on how long the client
might stick with the primary under the circumstance where it is responding to Status-Server packets. 

Assuming that a failure of the primary proxy is confirmed by Status-Server, then failing over to the 
secondary proxy quickly would seem to make sense.  At this point, it would make sense to continue
to send Status-Server packets to the primary to figure out when it comes up again.  

Section 4.4

The point that Status-Server packets are non-forwardable is quite central to the document, so it would
be a good idea to make the point earlier. 

Section 4.5

4.5.  Realm Routing

   RADIUS servers are commonly used in an environment where Network
   Access Identifiers (NAIs) are used as routing identifiers [RFC4282].
   In this practice, the User-Name attribute is decorated with realm
   routing information, commonly in the format of "user@realm".  Since a
   particular RADIUS server may act as a proxy for more than one realm,
   the mechanism outlined above may be inadequate.

[BA] What mechanism?  Since Status-Server packets are non-forwardable, there no concept of a destination
realm,  right? 

Overall, I think this section might be retitled "Limitations of Status-Server" because that is really the
main focus. 

On reading this section, the thought did occur to me that in the cause where Status-Server indicated
a downstream failure that "per-realm" failover might make sense.  For example, if the primary could
reach realm A but not B, there is no point in failing over all Requests to the secondary, just those
for realm B.  Of course, it is also possible that a fault in a downstream node that prevented 
reaching realm A (e.g. a failure in a server for realm A) might subsequently be corrected, so that
realm A might become reachable again. 

Section 5

Recommend including a row for User-Name, which presumably would have all 0s in it (e.g. User-Name is not used
in Status-Server packets, right?). 

What is the purpose of VSAs in Status-Server packets or Access-Responses? 





--_3bc8b54e-0ca2-4f86-978d-465168933018_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Section 4.3<br><pre>   When a client fails over from one server to another because of a lack<br>   of responsiveness, it SHOULD send periodic Status-Server packets to<br>   the unresponsive server, using the timer (Tw) defined above.<br><br>[BA] Can you provide a section reference for the Tw timer?<br><br>   Once three time periods have passed where Status-Server packets have<br>   been sent and responded to, the server should be deemed responsive<br>   and RADIUS requests may sent to it again.  This determination should<br>   be made separately for each server that the client has a relationship<br>   with.  The same algorithm should be used for both authentication and<br>   accounting ports.  The client MUST treat each destination (ip, port)<br>   combination as a unique server for the purposes of this<br>   determination.<br><br>   The above behavior is modelled after [RFC3539] Section 3.4.1.  We<br>   note that if a reliable transport is used for RADIUS, then the<br>   algorithms specified in [RFC3539] MUST be used in preference to the<br>   ones given here.<br><br>[BA] I think a bit more explanation would be helpful here.  Traditional "failover" algorithms have<br>depended on use of Access-Request packets.  Unfortunately, these techniques can lead a client to failover<br>in circumstances where there is nothing wrong with the primary proxy.  So in reading the first paragraph,<br>I'm unclear what is being advocated, precisely.  For example, is it being advocated that a Status-Server <br>packet be sent to the primary proxy after a number of Access-Requests do not receive a response?  That<br>would help determine whether the primary proxy was the issue in the first place.  If it is not the issue<br>(e.g. primary proxy responds), then sending Status-Server packets to the primary proxy would seem<br>pointless.  <br><br>If the primary proxy is responding to Status-Server, then the problem must be downstream, and it might<br>make sense for the client to continue to send Access-Requests for a while longer, under the assumption<br>that those downstream elements are also attempting to diagnose the problem (possibly with Status-Server),<br>so that in the meantime they might also fail-over, restoring end-to-end RADIUS connectivity.  Based on the<br>algorithms presented in RFC 5080, one might come up with some recommendations on how long the client<br>might stick with the primary under the circumstance where it is responding to Status-Server packets. <br><br>Assuming that a failure of the primary proxy is confirmed by Status-Server, then failing over to the <br>secondary proxy quickly would seem to make sense.  At this point, it would make sense to continue<br>to send Status-Server packets to the primary to figure out when it comes up again.  <br><br>Section 4.4<br><br>The point that Status-Server packets are non-forwardable is quite central to the document, so it would<br>be a good idea to make the point earlier. <br><br>Section 4.5<br><br>4.5.  Realm Routing<br><br>   RADIUS servers are commonly used in an environment where Network<br>   Access Identifiers (NAIs) are used as routing identifiers [RFC4282].<br>   In this practice, the User-Name attribute is decorated with realm<br>   routing information, commonly in the format of "user@realm".  Since a<br>   particular RADIUS server may act as a proxy for more than one realm,<br>   the mechanism outlined above may be inadequate.<br><br>[BA] What mechanism?  Since Status-Server packets are non-forwardable, there no concept of a destination<br>realm,  right? <br><br>Overall, I think this section might be retitled "Limitations of Status-Server" because that is really the<br>main focus. <br><br>On reading this section, the thought did occur to me that in the cause where Status-Server indicated<br>a downstream failure that "per-realm" failover might make sense.  For example, if the primary could<br>reach realm A but not B, there is no point in failing over all Requests to the secondary, just those<br>for realm B.  Of course, it is also possible that a fault in a downstream node that prevented <br>reaching realm A (e.g. a failure in a server for realm A) might subsequently be corrected, so that<br>realm A might become reachable again. <br><br>Section 5<br><br>Recommend including a row for User-Name, which presumably would have all 0s in it (e.g. User-Name is not used<br>in Status-Server packets, right?). <br><br>What is the purpose of VSAs in Status-Server packets or Access-Responses? <br></pre><br><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table></body>
</html>
--_3bc8b54e-0ca2-4f86-978d-465168933018_--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Aug 2009 04:43:59 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_318c77d9-5b52-4d78-84aa-7a7d9c3c1221_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Re: REMINDER: RADEXT WG Last Call on Status Server document (part 1)
Date: Sun, 9 Aug 2009 21:42:52 -0700
MIME-Version: 1.0

--_318c77d9-5b52-4d78-84aa-7a7d9c3c1221_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Here is my review. 

Abstract
   RFC 2865 defines a Status-Server code for use in RADIUS, but labels
   it as "Experimental" without further discussion.  This document
   describes a practical use for the Status-Server packet code, which is
   to let clients query the status of a RADIUS server.  These queries,
   and responses (if any) enable the client to make more informed
   decisions.  The result is a more stable, and more robust RADIUS
   architecture.

How about something more along the lines of the RFC 5176 abstract?  

   This document describes a deployed extension to the Remote
   Authentication Dial In User Service (RADIUS) protocol, enabling
   clients to query the status of a RADIUS server.  This extension
   utilizes the Status-Server (12) Code, which was reserved for
   experimental use in RFC 2865. 

Section 1

   The RADIUS Working Group was formed in 1995 to document the protocol
   of the same name, and created a number of standards surrounding the
   protocol.  It also defined experimental commands within the protocol,
   without elaborating further on the potential uses of those commands.
   One of the commands so defined was Status-Server ([RFC2865] Section
   3.).

   This document describes how some current implementations are using
   Status-Server packets as a method for querying the status of a RADIUS
   server.  These queries do not otherwise affect the normal operation
   of a server, and do not result in any side effects other than perhaps
   incrementing an internal packet counter.

   These queries are not intended to implement the application-layer
   watchdog messages described in [RFC3539] Section 3.4.  That document
   describes Authentication, Authorization, and Accounting (AAA)
   protocols that run over reliable transports which handle
   retransmissions internally.  Since RADIUS runs over the User Datagram
   Protocol (UDP) rather than Transport Control Protocol (TCP), the full
   watchdog mechanism is not applicable here.

Not sure the history is necessarily correct (e.g. I believe that the RADIUS Working Group was formed earlier).
In any case, it is probably best to focus on the purpose of this document.  How about this? 

   This document specifies a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, enabling
   clients to query the status of a RADIUS server.   While the Status-Server Code (12) was defined as experimental in [RFC2865] 
   Section 3, details of the operation and potential uses of the Code were not provided. 

   As with the core RADIUS protocol, the Status-Server extension is stateless, and queries do not
   otherwise affect the normal operation of a server, nor do they result in any side effects, other
   than perhaps incrementing of an internal packet counter.  Most of the implementations of
   this extension have utilized it alongside implementations of RADIUS as defined in [RFC2865],
   so that this document focuses solely on the use of this extension with UDP transport. 

Network Access Server (NAS)
     The device providing access to the network.  Also known as the
     Authenticator (in IEEE 802.1x terminology) or RADIUS client.

"x" -> "X"

Proxy Server
     A RADIUS server that acts as a Home Server to the NAS, but in turn
     proxies the request to another Proxy Server, or to a Home Server.

I am not sure that the use of the term "Home Server" here adds clarity.  The definition of proxy from
RFC 2607 might be more applicable:

   RADIUS proxy
      In order to provide for the routing of RADIUS authentication and
      accounting requests, a RADIUS proxy can be employed. To the NAS,
      the RADIUS proxy appears to act as a RADIUS server, and to the
      RADIUS server, the proxy appears to act as a RADIUS client.

1.1 Applicability

I think this document needs an applicability section, to explain potential differences between
this specification and existing implementations, as well as why it is being published as Informational,
as opposed to Experimental or Standards Track.  Suggest the following:

1.1.  Applicability

   This protocol is being recommended for publication as an
   Informational RFC rather than as a standards-track RFC because of
   problems that cannot be fixed without creating incompatibilities with
   deployed implementations.  This includes security vulnerabilities.  
   While fixes are recommended, they cannot be made mandatory since 
   this would be incompatible with existing implementations.

   Existing implementations of this protocol do not support the
   Message-Authenticator attribute.  This enables spoofing of
   Status-Server packets.  In order to remedy this problem, 
   this specification recommends the use of the Message-Authenticator
   attribute to provide per-packet authentication and integrity
   protection. 

   With existing implementations of this protocol, the potential
   exists for Status-Server requests to be in conflict with Access-Request
   or Accounting-Requests packets using the same Identifier.  This
   specification recommends techniques to avoid this problem. 

   [Add information on other issues here]

2.  Problem Statement

   It is often useful to know if a RADIUS server is alive and responding
   to requests.  The most accurate way to obtain this information is to
   query the server via application protocol traffic, as other methods
   are either less accurate, or cannot be performed remotely.

   The reasons for wanting to know the status of a server are many.  The
   administrator may simply be curious if the server is responding, and
   may not have access to NAS or traffic data that would give him that
   information.  The queries may also be performed automatically by a
   NAS or proxy server, which is configured to send packets to a RADIUS
   server, and where that server may not be responding.  That is, while
   [RFC2865] Section 2.6 indicates that sending Keep-Alives is harmful,
   it may be useful to send "Are you Alive" queries to a server once it
   has been marked "dead" due to prior unresponsiveness.

   The occasional query to a "dead" server offers little additional load
   on the network or server, and permits clients to more quickly
   discover when the server returns to a responsive state.  Overall,
   status queries can be a useful part of the deployment of a RADIUS
   server.

RFC 2865 Section 2.6 strongly discourages the use of keep-alives.  
>From reading this section, I am unclear whether the intent is to refute the
arguments made there, or to articulate how the uses of Status-Server
defined here go beyond those of the "test RADIUS request" described 
in RFC 2865. 

For example, unlike a RADIUS Access-Request, the Status-Server packet 
cannot be forwarded, and therefore the lack of a response can only be
due either to packet loss or to a problem with the server to whom the 
packet is sent.  In contrast, an Access-Request might not be answered 
because of a problem somewhere along the chain between the sender and 
the RADIUS server.  This difference allows the Status-Server packet to
be used as a diagnostic tool in ways that an Access-Request could not
be. 

Overall, I wonder whether some of the introductory material in Section 4.3
might be removed from that section and instead be revised and presented 
in this section.  For example:

   A common problem in RADIUS client implementations is the
   implementation of a robust fail-over mechanism between proxies.  A
   client may have multiple proxies configured, with one proxy marked
   as primary and another marked as secondary.  If the client does
   not receive a response to a request sent to the primary proxy, 
   it can "fail over" to the secondary, and send requests to the
   secondary instead of to the primary proxy. 

   However, it is possible that the lack of a response to requests
   sent to the primary proxy was due not to a failure within the
   the primary, but to alternative causes such as a failed link 
   along the path to the destination server, or the failure of
   a downstream proxy or server.  In such a situation, it may
   be useful for the client to be able to distinguish between
   failure causes.  For example, if the primary proxy is down,
   then quick failover to the secondary proxy would be prudent,
   whereas if a downstream failure is the cause, then the value
   of failing over to a secondary proxy will depend on whether
   packets forwarded by the secondary will utilize independent links, 
   intermediaries or destination servers.  

   Since the Status-Server packet is non-forwardable, lack of a
   response may only be due to packet loss or the failure of
   the server in the destination IP address, not due to faults
   in downstream links, proxies or servers.  It therefore 
   provides an unambiguous indication of the status of a 
   proxy or server. 

Sections 2.1-2.2

I find these sections puzzling, because they suggest alternatives to the Status-Server packet
that do not serve the same function.  Given that Status-Server packets are not forwardable, 
they serve a different purpose than the "test RADIUS requests" which RFC 2865 recommends
against.  Given this, talking about "alternatives" in these sections is somewhat confusing. 
What might make more sense is to describe the function that Status-Server packets provide
and why this is not provided by alternatives such as the RADIUS Access-Request packet. 

Section 2.3

   Since the
   packet is otherwise undefined, it does not cause interoperability
   issues to create implementation-specific definitions for it.  The
   difficulty until now has been defining an interoperable method of
   performing these queries.
 
While the Status-Server packet format was not defined in RFC 2865, it was implemented by Ascend and
other vendors.  As far as I know, a number of deployments did use NAS and RADIUS servers from different
vendors so that "implementation-specific definitions" would indeed have resulted in interoperability 
problems.  

In any case, as I understand it, the goal of this work item is to document existing implementations of 
the Status-Server extension, correct?  

Section 2.3.1

   Status-Server SHOULD be used instead of Access-Request to query the
   responsiveness of a server.  In this use case, the protocol exchange
   between client and server is similar to the usual exchange of Access-
   Request and Access-Accept, as shown below.

           NAS                          RADIUS server
           ---                          -------------
           Status-Server/
            Message-Authenticator ->
                                     <- Access-Accept/
                                         Reply-Message

   The Status-Server packet MUST contain a Message-Authenticator
   attribute for security.  The response (if any) to a Status-Server
   packet sent to an authentication port SHOULD be an Access-Accept
   packet.  Other response packet codes are NOT RECOMMENDED.  The list
   of attributes that are permitted in the Access-Accept packet is given
   in the Table of Attributes in Section 6, below.

Given that the Status-Server packet is not forwardable, this section is a bit
confusing.  Also, I'm not clear how useful the diagram is. 
I'd suggest focusing on the basics of the exchange:

Status-Server Exchange

   Status-Server packets are typically sent to the destination address and port 
   of a RADIUS server or proxy.  A Message-Authenticator attribute SHOULD be
   included so as to provide per-packet authentication and integrity protection. 
   A single Status-Server packet MUST be included within a UDP datagram.  RADIUS 
   proxies MUST NOT forward Status-Server packets.  

   A RADIUS server or proxy implementing this specification SHOULD 
   respond to a Status-Server packet with an Access-Accept.  Other response packet
   codes (such as Access-Challenge or Access-Reject) are NOT RECOMMENDED.  The
   list of attributes that are permitted in Status-Server and Access-Accept
   packets responding to Status-Server packets are provided in the Section 6. 
 
BTW, I'm curious as to whether a Status-Server packet can be sent to the address
and port (3799) of a DAS, and if so, what the appropriate response is.  

Section 2.3.2

   The Status-Server packet MUST contain a Message-Authenticator
   attribute for security.  

Given that implementations exist that did not support Message-Authenticator, my suggestion is that this
become a SHOULD. 

Section 3

   This method
   MUST be used to avoid conflicts between Status-Server and other
   packet types.

Given that implementations exist that did not support this, my suggestion is that this
become a SHOULD as well. 

   In addition to the above requirements, all Status-Server packets MUST
   include a Message-Authenticator attribute.  Failure to do so would
   mean that the packets could be trivially spoofed.

Suggest MUST -> SHOULD here. 

 




=============================
This is a reminder of an ongoing RADEXT WG last call on the Status Server
specification, prior to sending this document on to the IESG for
publication as an Informational RFC.  The document is available for
inspection here:
http://tools.ietf.org/html/draft-ietf-radext-status-server

RADEXT
WG last call will last until August 7, 2009.  Please send comments to
the RADEXT WG mailing list using the format described in the RADEXT
Issues list (http://www.drizzle.com/~aboba/RADEXT/).  




--_318c77d9-5b52-4d78-84aa-7a7d9c3c1221_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Here is my review. <br><br>Abstract<br><pre class="newpage">   <a href="http://tools.ietf.org/html/rfc2865">RFC 2865</a> defines a Status-Server code for use in RADIUS, but labels<br>   it as "Experimental" without further discussion.  This document<br>   describes a practical use for the Status-Server packet code, which is<br>   to let clients query the status of a RADIUS server.  These queries,<br>   and responses (if any) enable the client to make more informed<br>   decisions.  The result is a more stable, and more robust RADIUS<br>   architecture.<br><br>How about something more along the lines of the RFC 5176 abstract?  <br><br>   This document describes a deployed extension to the Remote<br>   Authentication Dial In User Service (RADIUS) protocol, enabling<br>   clients to query the status of a RADIUS server.  This extension<br>   utilizes the Status-Server (12) Code, which was reserved for<br>   experimental use in RFC 2865. <br><br>Section 1<br><br>   The RADIUS Working Group was formed in 1995 to document the protocol<br>   of the same name, and created a number of standards surrounding the<br>   protocol.  It also defined experimental commands within the protocol,<br>   without elaborating further on the potential uses of those commands.<br>   One of the commands so defined was Status-Server ([RFC2865] Section<br>   3.).<br><br>   This document describes how some current implementations are using<br>   Status-Server packets as a method for querying the status of a RADIUS<br>   server.  These queries do not otherwise affect the normal operation<br>   of a server, and do not result in any side effects other than perhaps<br>   incrementing an internal packet counter.<br><br>   These queries are not intended to implement the application-layer<br>   watchdog messages described in [RFC3539] Section 3.4.  That document<br>   describes Authentication, Authorization, and Accounting (AAA)<br>   protocols that run over reliable transports which handle<br>   retransmissions internally.  Since RADIUS runs over the User Datagram<br>   Protocol (UDP) rather than Transport Control Protocol (TCP), the full<br>   watchdog mechanism is not applicable here.<br><br>Not sure the history is necessarily correct (e.g. I believe that the RADIUS Working Group was formed earlier).<br>In any case, it is probably best to focus on the purpose of this document.  How about this? <br><br>   This document specifies a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, enabling<br>   clients to query the status of a RADIUS server.   While the Status-Server Code (12) was defined as experimental in [RFC2865] <br>   Section 3, details of the operation and potential uses of the Code were not provided. <br><br>   As with the core RADIUS protocol, the Status-Server extension is stateless, and queries do not<br>   otherwise affect the normal operation of a server, nor do they result in any side effects, other<br>   than perhaps incrementing of an internal packet counter.  Most of the implementations of<br>   this extension have utilized it alongside implementations of RADIUS as defined in [RFC2865],<br>   so that this document focuses solely on the use of this extension with UDP transport. <br><br>Network Access Server (NAS)<br>     The device providing access to the network.  Also known as the<br>     Authenticator (in IEEE 802.1x terminology) or RADIUS client.<br><br>"x" -&gt; "X"<br><br>Proxy Server<br>     A RADIUS server that acts as a Home Server to the NAS, but in turn<br>     proxies the request to another Proxy Server, or to a Home Server.<br><br>I am not sure that the use of the term "Home Server" here adds clarity.  The definition of proxy from<br>RFC 2607 might be more applicable:<br><br>   RADIUS proxy<br>      In order to provide for the routing of RADIUS authentication and<br>      accounting requests, a RADIUS proxy can be employed. To the NAS,<br>      the RADIUS proxy appears to act as a RADIUS server, and to the<br>      RADIUS server, the proxy appears to act as a RADIUS client.<br><br>1.1 Applicability<br><br>I think this document needs an applicability section, to explain potential differences between<br>this specification and existing implementations, as well as why it is being published as Informational,<br>as opposed to Experimental or Standards Track.  Suggest the following:<br><br>1.1.  Applicability<br><br>   This protocol is being recommended for publication as an<br>   Informational RFC rather than as a standards-track RFC because of<br>   problems that cannot be fixed without creating incompatibilities with<br>   deployed implementations.  This includes security vulnerabilities.  <br>   While fixes are recommended, they cannot be made mandatory since <br>   this would be incompatible with existing implementations.<br><br>   Existing implementations of this protocol do not support the<br>   Message-Authenticator attribute.  This enables spoofing of<br>   Status-Server packets.  In order to remedy this problem, <br>   this specification recommends the use of the Message-Authenticator<br>   attribute to provide per-packet authentication and integrity<br>   protection. <br><br>   With existing implementations of this protocol, the potential<br>   exists for Status-Server requests to be in conflict with Access-Request<br>   or Accounting-Requests packets using the same Identifier.  This<br>   specification recommends techniques to avoid this problem. <br><br>   [Add information on other issues here]<br><br>2.  Problem Statement<br><br>   It is often useful to know if a RADIUS server is alive and responding<br>   to requests.  The most accurate way to obtain this information is to<br>   query the server via application protocol traffic, as other methods<br>   are either less accurate, or cannot be performed remotely.<br><br>   The reasons for wanting to know the status of a server are many.  The<br>   administrator may simply be curious if the server is responding, and<br>   may not have access to NAS or traffic data that would give him that<br>   information.  The queries may also be performed automatically by a<br>   NAS or proxy server, which is configured to send packets to a RADIUS<br>   server, and where that server may not be responding.  That is, while<br>   [RFC2865] Section 2.6 indicates that sending Keep-Alives is harmful,<br>   it may be useful to send "Are you Alive" queries to a server once it<br>   has been marked "dead" due to prior unresponsiveness.<br><br>   The occasional query to a "dead" server offers little additional load<br>   on the network or server, and permits clients to more quickly<br>   discover when the server returns to a responsive state.  Overall,<br>   status queries can be a useful part of the deployment of a RADIUS<br>   server.<br><br>RFC 2865 Section 2.6 strongly discourages the use of keep-alives.  <br>From reading this section, I am unclear whether the intent is to refute the<br>arguments made there, or to articulate how the uses of Status-Server<br>defined here go beyond those of the "test RADIUS request" described <br>in RFC 2865. <br><br>For example, unlike a RADIUS Access-Request, the Status-Server packet <br>cannot be forwarded, and therefore the lack of a response can only be<br>due either to packet loss or to a problem with the server to whom the <br>packet is sent.  In contrast, an Access-Request might not be answered <br>because of a problem somewhere along the chain between the sender and <br>the RADIUS server.  This difference allows the Status-Server packet to<br>be used as a diagnostic tool in ways that an Access-Request could not<br>be. <br><br>Overall, I wonder whether some of the introductory material in Section 4.3<br>might be removed from that section and instead be revised and presented <br>in this section.  For example:<br><br>   A common problem in RADIUS client implementations is the<br>   implementation of a robust fail-over mechanism between proxies.  A<br>   client may have multiple proxies configured, with one proxy marked<br>   as primary and another marked as secondary.  If the client does<br>   not receive a response to a request sent to the primary proxy, <br>   it can "fail over" to the secondary, and send requests to the<br>   secondary instead of to the primary proxy. <br><br>   However, it is possible that the lack of a response to requests<br>   sent to the primary proxy was due not to a failure within the<br>   the primary, but to alternative causes such as a failed link <br>   along the path to the destination server, or the failure of<br>   a downstream proxy or server.  In such a situation, it may<br>   be useful for the client to be able to distinguish between<br>   failure causes.  For example, if the primary proxy is down,<br>   then quick failover to the secondary proxy would be prudent,<br>   whereas if a downstream failure is the cause, then the value<br>   of failing over to a secondary proxy will depend on whether<br>   packets forwarded by the secondary will utilize independent links, <br>   intermediaries or destination servers.  <br><br>   Since the Status-Server packet is non-forwardable, lack of a<br>   response may only be due to packet loss or the failure of<br>   the server in the destination IP address, not due to faults<br>   in downstream links, proxies or servers.  It therefore <br>   provides an unambiguous indication of the status of a <br>   proxy or server. <br><br>Sections 2.1-2.2<br><br>I find these sections puzzling, because they suggest alternatives to the Status-Server packet<br>that do not serve the same function.  Given that Status-Server packets are not forwardable, <br>they serve a different purpose than the "test RADIUS requests" which RFC 2865 recommends<br>against.  Given this, talking about "alternatives" in these sections is somewhat confusing. <br>What might make more sense is to describe the function that Status-Server packets provide<br>and why this is not provided by alternatives such as the RADIUS Access-Request packet. <br><br>Section 2.3<br><br>   Since the<br>   packet is otherwise undefined, it does not cause interoperability<br>   issues to create implementation-specific definitions for it.  The<br>   difficulty until now has been defining an interoperable method of<br>   performing these queries.<br>&nbsp;<br>While the Status-Server packet format was not defined in RFC 2865, it was implemented by Ascend and<br>other vendors.  As far as I know, a number of deployments did use NAS and RADIUS servers from different<br>vendors so that "implementation-specific definitions" would indeed have resulted in interoperability <br>problems.  <br><br>In any case, as I understand it, the goal of this work item is to document existing implementations of <br>the Status-Server extension, correct?  <br><br>Section 2.3.1<br><br>   Status-Server SHOULD be used instead of Access-Request to query the<br>   responsiveness of a server.  In this use case, the protocol exchange<br>   between client and server is similar to the usual exchange of Access-<br>   Request and Access-Accept, as shown below.<br><br>           NAS                          RADIUS server<br>           ---                          -------------<br>           Status-Server/<br>            Message-Authenticator -&gt;<br>                                     &lt;- Access-Accept/<br>                                         Reply-Message<br><br>   The Status-Server packet MUST contain a Message-Authenticator<br>   attribute for security.  The response (if any) to a Status-Server<br>   packet sent to an authentication port SHOULD be an Access-Accept<br>   packet.  Other response packet codes are NOT RECOMMENDED.  The list<br>   of attributes that are permitted in the Access-Accept packet is given<br>   in the Table of Attributes in Section 6, below.<br><br>Given that the Status-Server packet is not forwardable, this section is a bit<br>confusing.  Also, I'm not clear how useful the diagram is. <br>I'd suggest focusing on the basics of the exchange:<br><br>Status-Server Exchange<br><br>   Status-Server packets are typically sent to the destination address and port <br>   of a RADIUS server or proxy.  A Message-Authenticator attribute SHOULD be<br>   included so as to provide per-packet authentication and integrity protection. <br>   A single Status-Server packet MUST be included within a UDP datagram.  RADIUS <br>   proxies MUST NOT forward Status-Server packets.  <br><br>   A RADIUS server or proxy implementing this specification SHOULD <br>   respond to a Status-Server packet with an Access-Accept.  Other response packet<br>   codes (such as Access-Challenge or Access-Reject) are NOT RECOMMENDED.  The<br>   list of attributes that are permitted in Status-Server and Access-Accept<br>   packets responding to Status-Server packets are provided in the Section 6. <br> <br>BTW, I'm curious as to whether a Status-Server packet can be sent to the address<br>and port (3799) of a DAS, and if so, what the appropriate response is.  <br><br>Section 2.3.2<br><br>   The Status-Server packet MUST contain a Message-Authenticator<br>   attribute for security.  <br><br>Given that implementations exist that did not support Message-Authenticator, my suggestion is that this<br>become a SHOULD. <br><br>Section 3<br><br>   This method<br>   MUST be used to avoid conflicts between Status-Server and other<br>   packet types.<br><br>Given that implementations exist that did not support this, my suggestion is that this<br>become a SHOULD as well. <br><br>   In addition to the above requirements, all Status-Server packets MUST<br>   include a Message-Authenticator attribute.  Failure to do so would<br>   mean that the packets could be trivially spoofed.<br><br>Suggest MUST -&gt; SHOULD here. <br><br> <br><br><br><br><br></pre>=============================<br>This is a reminder of an ongoing RADEXT WG last call on the Status Server
specification, prior to sending this document on to the IESG for
publication as an Informational RFC.&nbsp; The document is available for
inspection here:<br>http://tools.ietf.org/html/draft-ietf-radext-status-server<br><br>RADEXT
WG last call will last until August 7, 2009.&nbsp; Please send comments to
the RADEXT WG mailing list using the format described in the RADEXT
Issues list (http://www.drizzle.com/~aboba/RADEXT/).&nbsp; <br><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table></body>
</html>
--_318c77d9-5b52-4d78-84aa-7a7d9c3c1221_--

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


Envelope-to: [e-mail]
Delivery-date: Thu, 06 Aug 2009 08:07:48 +0000
Date: Thu, 06 Aug 2009 16:07:07 +0800
From: Yungui Wang <[e-mail]>
Subject: RE: REMINDER: Call for adoption of RADIUS for IPv6 Access Networks document as a WG work item
To: 'Hannes Tschofenig' <[e-mail]>, [e-mail]
Cc: [e-mail]
Reply-to: [e-mail]
Message-id: <00ac01ca166c$e4b70880$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcoWN18mfisciI4RSXGOufiV5MFC+AALVAmgAABMMoA
Hello

Sorry for confusing you. 

I just want to say I have read this document. It is helpful for me
to work on some items such as multiple IPv6 access in the IP edge
which may need some of these attributes. Hence, I personally
support it is moved forward. In addition, I am willing to
contribute it too. :)

B.R.
Yungui
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Hannes
Tschofenig
> Sent: Thursday, August 06, 2009 3:11 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: REMINDER: Call for adoption of RADIUS for IPv6 
> Access Networks document as a WG work item
> 
> "Fine for me" means
> - "I don't care. Do whatever you want." 
> - "I am going to implement it into my AAA server."
> - "I am going to add it to my AAA clients."
> - "I am planning to deploy it."
> - "I will review the document." 
> - "I will contribute to it."
> - "Glen asked me to send a message and here is it."
> ? 
> 
> So, what do you mean by "fine for me"? 
> 
> 
> >-----Original Message-----
> >From: [e-mail]
> >[mailto:[e-mail]] On Behalf Of Yungui Wang
> >Sent: 06 August, 2009 04:44
> >To: [e-mail]; [e-mail]
> >Cc: [e-mail]; [e-mail]
> >Subject: RE: REMINDER: Call for adoption of RADIUS for IPv6
Access 
> >Networks document as a WG work item
> >
> >Hello
> >
> >It is fine with me.
> >
> >B.R.
> >Yungui
> >
> >> 
> >> From: [e-mail]
> >[mailto:[e-mail]] On Behalf Of Bernard
Aboba
> >> Sent: Friday, June 26, 2009 1:24 PM
> >> To: [e-mail]
> >> Subject: REMINDER: Call for adoption of RADIUS for IPv6
Access
> >Networks document as a WG work item
> >> 
> >>  
> >> 
> >> This is a reminder of an ongoing call for review of the
document
> >"RADIUS attributes for IPv6 Access Networks" for adoption as 
> a RADEXT 
> >WG work item.  This document is being targeted at Proposed
Standard 
> >status.
> >>  
> >> The document is available for review here:
> >> http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access
> >> 
> >> This call for review will last until August 7, 2009.  Please
> >send email to the RADEXT WG mailing list indicating whether 
> you support 
> >adoption of this document as a RADEXT WG work item.  If you
have 
> >comments on the document, please also send these to the list in
the 
> >format described on the RADEXT WG Issues list:
> >> http://www.drizzle.com/~aboba/RADEXT/
> >> 
> >> 
> >
> >
> >--
> >to unsubscribe send a message to
> >[e-mail] with the word 'unsubscribe' 
> in a single 
> >line as the message text body.
> >archive: <http://psg.com/lists/radiusext/>
> >
> 
> 
> --
> to unsubscribe send a message to [e-mail]
with
> the word 'unsubscribe' in a single line as the message text
body.
> archive: <http://psg.com/lists/radiusext/>
> 


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


Envelope-to: [e-mail]
Delivery-date: Thu, 06 Aug 2009 07:09:00 +0000
From: "Hannes Tschofenig" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: REMINDER: Call for adoption of RADIUS for IPv6 Access Networks document as a WG work item
Date: Thu, 6 Aug 2009 10:10:30 +0300
Message-ID: <03fe01ca1664$fc3bf950$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcoWN18mfisciI4RSXGOufiV5MFC+AALVAmg

"Fine for me" means 
- "I don't care. Do whatever you want." 
- "I am going to implement it into my AAA server."
- "I am going to add it to my AAA clients."
- "I am planning to deploy it."
- "I will review the document." 
- "I will contribute to it."
- "Glen asked me to send a message and here is it."
? 

So, what do you mean by "fine for me"? 


>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Yungui Wang
>Sent: 06 August, 2009 04:44
>To: [e-mail]; [e-mail]
>Cc: [e-mail]; [e-mail]
>Subject: RE: REMINDER: Call for adoption of RADIUS for IPv6 
>Access Networks document as a WG work item
>
>Hello
>
>It is fine with me.
>
>B.R.
>Yungui
>
>> 
>> From: [e-mail]
>[mailto:[e-mail]] On Behalf Of Bernard Aboba
>> Sent: Friday, June 26, 2009 1:24 PM
>> To: [e-mail]
>> Subject: REMINDER: Call for adoption of RADIUS for IPv6 Access
>Networks document as a WG work item
>> 
>>  
>> 
>> This is a reminder of an ongoing call for review of the document
>"RADIUS attributes for IPv6 Access Networks" for adoption as a 
>RADEXT WG work item.  This document is being targeted at 
>Proposed Standard status. 
>>  
>> The document is available for review here:
>> http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access
>> 
>> This call for review will last until August 7, 2009.  Please
>send email to the RADEXT WG mailing list indicating whether 
>you support adoption of this document as a RADEXT WG work 
>item.  If you have comments on the document, please also send 
>these to the list in the format described on the RADEXT WG Issues list:
>> http://www.drizzle.com/~aboba/RADEXT/
>> 
>> 
>
>
>--
>to unsubscribe send a message to 
>[e-mail] with the word 'unsubscribe' in 
>a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>
>


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


Envelope-to: [e-mail]
Delivery-date: Thu, 06 Aug 2009 01:48:22 +0000
Date: Thu, 06 Aug 2009 09:44:01 +0800
From: Yungui Wang <[e-mail]>
Subject: RE: REMINDER: Call for adoption of RADIUS for IPv6 Access Networks document as a WG work item
To: [e-mail]
Cc: [e-mail]
Reply-to: [e-mail]
Message-id: <009701ca1637$5f887070$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcoWN18mfisciI4RSXGOufiV5MFC+A=

Hello

It is fine with me.

B.R.
Yungui

> 
> From: [e-mail]
[mailto:[e-mail]] On Behalf Of Bernard Aboba
> Sent: Friday, June 26, 2009 1:24 PM
> To: [e-mail]
> Subject: REMINDER: Call for adoption of RADIUS for IPv6 Access
Networks document as a WG work item
> 
>  
> 
> This is a reminder of an ongoing call for review of the document
"RADIUS attributes for IPv6 Access Networks" for adoption as a
RADEXT WG work item.  This document is being targeted at Proposed
Standard status. 
>  
> The document is available for review here:
> http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access
> 
> This call for review will last until August 7, 2009.  Please
send email to the RADEXT WG mailing list indicating whether you
support adoption of this document as a RADEXT WG work item.  If
you have comments on the document, please also send these to the
list in the format described on the RADEXT WG Issues list:
> http://www.drizzle.com/~aboba/RADEXT/
> 
> 


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


Envelope-to: [e-mail]
Delivery-date: Mon, 03 Aug 2009 22:58:26 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_98d6072b-dc34-476b-ac40-f0b9aeae7208_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Draft IETF 75 RADEXT WG minutes
Date: Mon, 3 Aug 2009 15:57:55 -0700
MIME-Version: 1.0

--_98d6072b-dc34-476b-ac40-f0b9aeae7208_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


http://www.ietf.org/proceedings/75/minutes/radext.txt



--_98d6072b-dc34-476b-ac40-f0b9aeae7208_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
http://www.ietf.org/proceedings/75/minutes/radext.txt<br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table></body>
</html>
--_98d6072b-dc34-476b-ac40-f0b9aeae7208_--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 03 Aug 2009 22:53:03 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/mixed; boundary="_af35414b-5f76-44e1-814a-3728da88fa1d_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Subject: Draft Minutes of RADEXT WG Meeting at IETF 75
Date: Mon, 3 Aug 2009 15:52:11 -0700
MIME-Version: 1.0

--_af35414b-5f76-44e1-814a-3728da88fa1d_
Content-Type: multipart/alternative;
	boundary="_fcbe0981-5af7-4909-99fe-1496b5578ac9_"

--_fcbe0981-5af7-4909-99fe-1496b5578ac9_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







--_fcbe0981-5af7-4909-99fe-1496b5578ac9_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<br><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table></body>
</html>
--_fcbe0981-5af7-4909-99fe-1496b5578ac9_--

--_af35414b-5f76-44e1-814a-3728da88fa1d_
Content-Type: text/plain
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="radext75.txt"

TWludXRlcyBvZiB0aGUgUkFERVhUIFdHCklFVEYgNzUKU3RvY2tob2xtLCBTd2VkZW4KRnJpZGF5
LCBKdWx5IDMxLCAyMDA5CgpOb3RlIFdlbGwKClRoZSBOb3RlIFdlbGwgYW5kIElFVEYgSVBSIG9i
bGlnYXRpb25zIHdlcmUgcHJlc2VudGVkLiAgCgpBZ2VuZGEgQmFzaAoKRXh0ZW5kZWQgQXR0cmli
dXRlcyBhbmQgQ3J5cHRvLWFnaWxpdHkgUmVxdWlyZW1lbnRzIGRvY3VtZW50cyBhcmUgbm90IG9u
IHRoZSBhZ2VuZGEgYXQgSUVURiA3NS4KVGhleSB3ZXJlIGRpc2N1c3NlZCBhdCB0aGUgaW50ZXJp
bS4gIERpYW1ldGVyL1JBRElVUyBjb21wYXRpYmxpdHkgaXNzdWVzIGJsb2NraW5nIEV4dGVuZGVk
CkF0dHJpYnV0ZXMgd2lsbCBiZSBkaXNjdXNzZWQgaW4gRElNRS4gIAogCkRvY3VtZW50IFN0YXR1
cyB1cGRhdGUKCk5BUyBBdXRob3JpemF0aW9uIGZvciBOQVMgTWFuYWdlbWVudCBwdWJsaXNoZWQg
YXMgUkZDIDU2MDcuClJBRElVUyBMb2NhdGlvbiBpcyBpbiBBVVRINDguIApEZXNpZ24gR3VpZGVs
aW5lcyBoYXMgY29tcGxldGVkIElFVEYgbGFzdCBjYWxsIGFuZCBpcyBpbiBBRCBGb2xsb3d1cC4K
VHVubmVsLVR5cGUgVmFsdWVzIGRvY3VtZW50IGhhcyBjb21wbGV0ZWQgV0cgbGFzdCBjYWxsLCBh
bmQgaXMgcmVhZHkgZm9yIElFVEYgbGFzdCBjYWxsLCBwZW5kaW5nCiAgIGEgUFJPVE8gd3JpdGV1
cC4gClJBRFNFQywgQ3J5cHRvLWFnaWxpdHkgUmVxdWlyZW1lbnRzIGFuZCBFeHRlbmRlZCBBdHRy
aWJ1dGVzIGRvY3VtZW50cyBoYXZlIGNvbXBsZXRlZCBXRyBsYXN0IGNhbGwsIHdpdGggb3BlbiBp
c3N1ZXMuICBTZWUgUkFERVhUIGlzc3VlcyB0cmFjayBmb3IgZGV0YWlsczogaHR0cDovL3d3dy5k
cml6emxlLmNvbS9+YWJvYmEvUkFERVhULyAKVGhlIFN0YXR1cyBTZXJ2ZXIgYW5kIFJBRElVUyBv
dmVyIFRDUCBkb2N1bWVudHMgYXJlIGluIFdHIGxhc3QgY2FsbC4gCk5BSS1iYXNlZCBwZWVyIGRp
c2NvdmVyeSBoYXMgYmVlbiBhZG9wdGVkIGFzIGEgV0cgd29yayBpdGVtLiAKClJBRFNFQywgU3Rl
ZmFuIFdpbnRlciAoMTAgbWludXRlcykKaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
aWV0Zi1yYWRleHQtcmFkc2VjCgpCZXJuYXJkOiAgV2hhdCBpcyB0aGUgZGVmaW5pdGlvbiBvZiB0
aGUgdGVybSAiUkFEU0VDIj8KU3RlZmFuIFdpbnRlcjogSW4gcGxhY2VzIHRoZSBkb2N1bWVudHMg
cmVmZXIgdG8gYm90aCBSQURJVVMgb3ZlciBUTFMgYW5kIFJBRElVUyBvdmVyIERUTFMgYXMgIlJB
RFNFQyIuIApBbGFuIERlS29rOiBSQURTRUMgaXMgUkFESVVTIG92ZXIgVExTL1NTTCwgTk9UIG92
ZXIgRFRMUy4gIApBbGFuIERlS29rOiAgIlJBRFNFQyIgaXMgYSBwcm9kdWN0IG5hbWUuICBJcyB1
c2luZyB0aGlzIG9rIGluIElFVEYgZG9jdW1lbnRzPwpEYW4gUm9tYXNjYW51OiBXZSBzaG91bGQg
bm90IHVzZSBhIHByb2R1Y3QgbmFtZSBmb3IgdGhlIHRlY2hub2xvZ3kuIEJlcm5hcmQgYWdyZWVz
LiAKClNvbHV0aW9uOiAgVGhlIHRlcm0gIlJBRFNFQyIgd2lsbCBubyBsb25nZXIgYmUgdXNlZCBp
biBSQURFWFQgV0cgZG9jdW1lbnRzOyB0aGUgdGVybSAiUkFESVVTIG92ZXIgVExTIiB3aWxsIGJl
IHVzZWQgaW5zdGVhZCB0byByZWZlciB0byBUTFMgdHJhbnNwb3J0LiAgIlJBRElVUyBvdmVyIERU
TFMiIHdpbGwgYmUgdXNlZCB0byByZWZlciB0byB0aGUgRFRMUyB0cmFuc3BvcnQgZm9yIFJBRElV
Uy4gIFN0ZWZhbiBhZ3JlZXMgdG8gY2hhbmdlIHRoZSB0ZXJtaW5vbG9neSBpbiB0aGUgbmV4dCBy
ZXZpc2lvbiBvZiB0aGUgZG9jdW1lbnQgc2V0LiAKClJldiAtMDUgb2YgdGhlIGRvY3VtZW50IGFk
ZHJlc3NlcyBtb3N0IGNvbW1lbnRzIGZyb20gV0cgbGFzdCBjYWxsLiAgVGhlcmUgaGF2ZSBiZWVu
IGRzY3Vzc2lvbnMgIG9uIHRoZSBtYWlsaW5nIGxpc3QgcmVsYXRpbmcgdG8gb24gYmlkZGluZyBk
b3duIGZyb20gVExTIHRvIFVEUC4gCgpCZXJuYXJkOiBXaGVuIHVwZ3JhZGluZyBhIE5BUyB0byBS
QURJVVMgb3ZlciAoRClUTFMgaG93IGRvZXMgdGhlIFJBRElVUyBzZXJ2ZXIgbGluayB0aGUgdXBn
cmFkZWQgTkFTIHRvIHRoZSBwcmV2aW91cyAobGVnYWN5KSBSQURJVVMgb3ZlciBVRFAgaW5zdGFu
Y2UgaW4gb3JkZXIgdG8gYmxvY2sgZnV0dXJlIFJBRElVUyBvdmVyIFVEUCB0cmFuc2FjdGlvbnM/
ICBJcyB0aGUgTkFTIGlkZW50aWZpZWQgYnkgSVAgYWRkcmVzcyBvciBieSBhbiBhdHRyaWJ1dGUg
c3VjaCBhcyBOQVMtSWRlbnRpZmllcj8gCgpTdGVmYW46IEkgZG91YnQgdGhhdCBhdHRyaWJ1dGVz
IGNhbiBiZSB1c2VmdWwsIHNpbmNlIHRoYXQncyBvbmx5IGFmdGVyIChEKVRMUyBpcyBlc3RhYmxz
aGVkLiAKKEQpVExTIGlkZW50aWZpZXJzIGFyZSB1c2VkIHRvIGRlbm90ZSBjbHVzdGVycy4gCkJl
cm5hcmQ6ICBTbyB0aGUgSVAgYWRkcmVzcyBjb3VsZCBjaGFuZ2U/ClN0ZWZhbjogIENvbmNlaXZh
Ymx5LiAgVGhlIGFzc3VtcHRpb24gaXMgdGhhdCAoRClUTFMgY29uZmlndXJhdGlvbiBpcyBhdmFp
bGFibGUgb24gdGhlIFJBRElVUyBzZXJ2ZXIsIGluIGFkZGl0aW9uIHRvIGxlZ2FjeSBSQURJVVMg
Y29uZmlndXJhdGlvbi4gIFRoZXJlIGFyZSBkaWZmZXJlbnQgKEQpVExTIG9wZXJhdGluZyBtb2Rl
cwooUFNLLCBjZXJ0aWZpY2F0ZXMpIHNvIHRoYXQgcHJlLWNvbmZpZ3VyYXRpb24gbWF5IGJlIG5l
Y2Vzc2FyeS4gIApCZXJuYXJkOiAgUkZDIDUyODAgbWFrZXMgcmVjb21tZW5kYXRpb25zIGFib3V0
IHRoZSB1c2Ugb2YgdGhlIHN1YmplY3QgYW5kIHN1YmplY3RBbHROYW1lIGZpZWxkczsgd2Ugc2hv
dWxkIHByb2JhYmx5IGhhdmUgdGhlIHBhcnQgb2YgdGhlIGRvY3VtZW50IHJlbGF0aW5nIHRvIGNl
cnRpZmljYXRlcyByZXZpZXdlZCBieSBhIFBLSSBleHBlcnQuIApEYW4gSGFya2luczogd2h5IG5v
dCBsZWF2ZSB0aGlzIGRlY2lzaW9uIHRvIGltcGxlbWVudGF0aW9ucz8gCkJlcm5hcmQ6IHRoaXMg
aXMgdG8gcHJldmVudCBiaWRkaW5nIGRvd24gYXR0YWNrcy4gCkRhbjogbm90IHJlYWxseSwgeW91
J2Qgc3RpbGwgbmVlZCB0byBoYXZlIHRoZSBzaGFyZWQgc2VjcmV0LiAKQmVybmFyZDogdGhpcyBp
cyBqdXN0IGEgcmVjb21tZW5kYXRpb24sIHRob3VnaC4KClJBRElVUyBUdW5uZWwgVmFsdWVzLCBB
Ymhpc2hlayBUaXdhcmkgKDEwIG1pbnV0ZXMpCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LXRpd2FyaS1yYWRleHQtdHVubmVsLXR5cGUKClRoZSBkb2N1bWVudCBoYXMgYmVlbiAic2l0
dGluZyBhcm91bmQiIGZvciAxOCBtb250aHMuICBJdCBoYXMgY29tcGxldGVkIFdHIGxhc3QgY2Fs
bCwgd2l0aCBubyBvcGVuIGlzc3VlcywgYW5kIGlzIHBlbmRpbmcgYSBQUk9UTyB3cml0ZXVwIHBy
aW9yIHRvIElFVEYgbGFzdCBjYWxsLiAgVGhpcyBzZWVtcyBsaWtlIGEgbG90IG9mIHByb2Nlc3Mg
Zm9yIGFsbG9jYXRpb24gb2YgYSBUdW5uZWwtVHlwZSB2YWx1ZS4gIFJGQyAzNTc1IFNlY3Rpb24g
Mi4xIHN0YXRlcyB0aGF0IHZhbHVlcyBhcmUgYWxsb2NhdGVkIGJ5IERlc2lnbmF0ZWQgRXhwZXJ0
IHdpdGggc29tZSBleGNlcHRpb25zLiAgSG93ZXZlciwgUkZDIDM1NzUgZGlkIG5vdCB1cGRhdGUg
UkZDIDI4NjgsIHNvIGl0IGlzIGNsYWltZWQgdGhhdCB0aGlzIGRvZXMgbm90IGFwcGx5IHRvIFR1
bm5lbC1UeXBlIHZhbHVlcy4gCgpEYW4gUm9tYXNjYW51OiAgSWYgdGhlIHByb2JsZW0gaXMgYW4g
ZXJyYXRhIGluIFJGQyAzNTc1LCB0aGVuIHdlIHNob3VsZCBmaXggdGhlIGVycmF0YSwgcmF0aGVy
IHRoYW4gZm9yY2luZyBldmVyeSB0dW5uZWwtdHlwZSB2YWx1ZSB0byBnbyB0aHJvdWdoIElFVEYg
bGFzdCBjYWxsLiAgVGhpcyBjb3VsZCBhbGxvdyB0aGUgZG9jdW1lbnQgdG8gYmUgYXBwcm92ZWQg
bXVjaCBmYXN0ZXIhCgpCZXJuYXJkOiAgQWdyZWVkLiAKCk5BSS1iYXNlZCBQZWVyIERpc2NvdmVy
eSwgU3RlZmFuIFdpbnRlciAoMTAgbWludXRlcykKaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtaWV0Zi1yYWRleHQtZHluYW1pYy1kaXNjb3ZlcnkKCi0wMSBjbGVhbmVkIHVwIHRoZSBh
bGdvcml0aG0sIGFkZGVkIGkxOG4gZXhhbXBsZXMuIEFzc3VtcHRpb24gaXMgdGhhdCB0aGUgcmVh
bG0gaXMgYSB2YWxpZApkb21haW4gbmFtZS4gIApCZXJuYXJkOiBjYW4geW91IGRpc2NvdmVyIGlm
IHlvdSdyZSB1c2luZyBUTFMgb3IgRFRMUyB0aHJ1IHRoZSBOQVBUUj8gClN0ZWZhbjsgeWVzLiAK
QmVybmFyZDogIERvZXMgdGhlIHJlZmVyZW5jZSB0byBSRkMgNDI4MiBtYWtlIHNlbnNlPyAgQWxh
biBoYXMgZG9jdW1lbnRlZCBpMThuIGlzc3VlcyB3aXRoIHRoYXQgZG9jdW1lbnQuIE1heWJlIHdl
IHNob3VsZCBqdXN0IHJlZmVyIHRvIElETkEgKGJpcykgZG9jdW1lbnRzIGluc3RlYWQuIAoKUkFE
SVVTIGF0dHJpYnV0ZXMgZm9yIElFRUUgODAyIE5ldHdvcmtzLCBCZXJuYXJkIEFib2JhICgxMCBt
aW51dGVzKQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hYm9iYS1yYWRleHQtd2xh
bgoKODAyLjExcyBzY2hlZHVsZSBjaGFuZ2VkLCBhcyBkaWQgdGhlIGFyY2hpdGVjdHVyZS4gIApE
YW4gSGFya2luczogS2V5IERpc3RyaWJ1dGlvbiBTZXJ2ZXIgZG9lc24ndCBleGlzdCBhbnkgbW9y
ZSBpbiAxMXMuIApCZXJuYXJkOiAxMXMgYXR0cmlidXRlcyBoYXZlIGJlZW4gcmVtb3ZlZDsgdGhl
IGRvY3VtZW50IGZvY3VzZXMgb24gMTFpLCAxMXIgYW5kIElFRUUgODAyLjFYLVJFViAobm93IGlu
IFNwb25zb3IgQmFsbG90KS4gCk5leHQgc3RlcDogIENvbXBsZXRlIHRoZSBXRyBhZG9wdGlvbiBj
YWxsIHN0YXJ0ZWQgaW4gTm92ZW1iZXIgMjAwNyAtLSAxOCBtb250aHMgYWdvIQoKUkFESVVTIG92
ZXIgVENQIGRvY3VtZW50LCBBbGFuIERlS29rICgxMCBtaW51dGVzKQpodHRwOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJhZGV4dC10Y3AtdHJhbnNwb3J0CgpUaGlzIGRvY3VtZW50
IGlzIGluIFdHIGxhc3QgY2FsbCB1bnRpbCBBdWd1c3QgNywgMjAwOS4gIFBsZWFzZSByZWFkIGl0
IGFuZCBjb21tZW50IQoKQmVybmFyZDogSXMgdGhlIHVzZSBvZiBTdGF0dXMgU2VydmVyIGlzIGV4
YWN0bHkgYXMgZGVzY3JpYmVkIGluIHRoZSBTdGF0dXMgU2VydmVyIGRvYz8gIE9yIGlzCnRoZXJl
IHNvbWUgZGlmZmVyZW5jZSBiZXR3ZWVuIHVzZSB3aXRoIChEKVRMUyBhbmQgVURQIHRyYW5zcG9y
dHM/ICAKU3RlZmFuOiBBcyBmYXIgYXMgSSBrbm93LCB1c2FnZSBpcyB0aGUgc2FtZS4gClN0ZWZh
bjogd2hhdCBpcyB0aGUgc3RhdHVzIG9mIHRoZSBoZWFkIG9mIGxpbmUgZGlzY3Vzc2lvbj8gCkJl
cm5hcmQ6IHdlIHNob3VsZCBoYXZlIGEgVHJhbnNwb3J0IEFyZWEgcmV2aWV3IG9mIHRoZSBkb2N1
bWVudDsgTWFnbnVzIGFza2VkIGEgbG90IG9mIHF1ZXN0aW9ucwp3aGVuIGl0IHdhcyBmaXJzdCBw
cmVzZW50ZWQuIApCZXJuYXJkOiAgRG9lcyB0aGlzIGRvY3VtZW50IG9ubHkgYXBwbHkgdG8gdXNl
IHdpdGggVExTPyAKQWxhbjogWWVzLCB0aGlzIGlzIHJlYWxseSB1bmludGVyZXN0aW5nIHVubGVz
cyB1c2luZyBSQURJVVMgb3ZlciBUTFMuIAoKRGVzaWduIEd1aWRlbGluZXMgZG9jdW1lbnQsIEFs
YW4gRGVLb2sgKDIwICBtaW51dGVzKQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p
ZXRmLXJhZGV4dC1kZXNpZ24KCkRvY3VtZW50IGhhcyBjb21wbGV0ZWQgSUVURiBsYXN0IGNhbGwu
ICBUaGVyZSBpcyBhbiBvcGVuIERJU0NVU1MgZnJvbSBKYXJpIEFya2tvLiAgClRoZXJlIGhhcyBh
bHNvIGJlZW4gYSAidGVzdCBjYXNlIiBkb2N1bWVudCB3aGljaCBleHBvc2VkIGFtYmlndWl0aWVz
IGluIHRoZSBEZXNpZ24gR3VpZGVsaW5lcwpkb2N1bWVudC4gIElzIGl0IGNsZWFyIGVub3VnaCB0
byBhbGxvdyByZXZpZXdzIHRvIGJlIGJhc2VkIG9uIGl0LCBvciB3aWxsIHdlIGhhdmUgaW50ZXJw
cmV0YXRpb24KcHJvYmxlbXMgZ29pbmcgZm9yd2FyZD8gIAoKQWxhbjogdGhlIG9ubHkgbWFqb3Ig
dGhpbmcgaXMgcmVtb3ZpbmcgdGhlIG5vcm1hdGl2ZSByZWYgb24gRXh0ZW5kZWQgQXR0cmlidXRl
cy4gCkJlcm5hcmQ6IEV4dGVuZGVkIEF0dHJpYnV0ZXMgc2hvdWxkIGhhdmUgaXRzIG93biBkZXNp
Z24gZ3VpZGVsaW5lcyBhbnl3YXkuCkJlcm5hcmQ6ICBzb21lIGludHJlcHJldGF0aW9uIGlzc3Vl
cyB3ZXJlIGV4cG9zZWQgYnkgdGhlIFJBRElVUyBQS012MSBkb2N1bWVudCByZXZpZXcuIFdoYXQg
ZG9lcyB0aGUgInNlY3VyaXR5IGV4ZW1wdGlvbiIgYXBwbHkgdG8sIGV4YWN0bHk/IEdsZW4gdGhv
dWdodCBpdCBhcHBsaWVkIHdoZXJlIGF0dHJpYnV0ZXMgcmVsYXRlZCB0byBzZWN1cml0eSAoZS5n
LiB0aGUgd2hvbGUgZG9jdW1lbnQpCkFsYW4gc2FpZCBpdCBpcyBvbmx5IGZvciBhdHRyaWJ1dGVz
IHJlbGF0aW5nIHRvIFJBRElVUyBzZWN1cml0eSAobWF5YmUgbm90IGF1dGhlbnRpY2F0aW9uLCBz
dWNoIGFzCkVBUCkuIApCZXJuYXJkOiAgVGhlIGRvY3VtZW50IG5lZWRzIHRvIGJlIGNsZWFyIGVu
b3VnaCB0byBhdm9pZCB0aGVzZSBraW5kIG9mIGRpc3B1dGVzLiAgVGhlIG92ZXJhbGwgZ29hbCBp
cyB0byBlbmFibGUgYXR0cmlidXRlcyB0byBiZSBhZGRlZCBpbiB0aGUgU2VydmVyIERpY3Rpb25h
cnkgd2l0aG91dCBjb2RlIGNoYW5nZXMsIGlmIHBvc3NpYmxlLiAKClRoZSBTZWN1cml0eSBleGVt
cHRpb24gd2FzIGFkZGVkIHNpbmNlIGF1dGhlbnRpY2F0aW9uIGF0dHJpYnV0ZXMgKENIQVAsIEVB
UCwgRGlnZXN0LCBldGMuKSBvciBSQURJVVMgc2VjdXJpdHkgYXR0cmlidXRlcyAoTWVzc2FnZS1B
dXRoZW50aWNhdG9yKSByZXF1aXJlIGNvbXB1dGF0aW9ucyB0byBiZSBwZXJmb3JtZWQgb24gdGhl
IFJBRElVUyBjbGllbnQgYW5kIHNlcnZlci4gIFNvIHlvdSBuZWVkIHRvIGNoYW5nZSBjb2RlOyBj
aGFuZ2luZyB0aGUgc2VydmVyIGRpY3Rpb25hcnkgaXNuJ3QgZW5vdWdoLiAgU28gdGhlIHF1ZXN0
aW9uIGlzIHdoZXRoZXIgdGhlIFBLTXYxIGRvY3VtZW50IGlzIHJlcXVpcmluZyBhIGNvZGUgY2hh
bmdlIG9uIHRoZSBzZXJ2ZXIgd2hlbiBub25lIHNob3VsZCBiZSBuZWNlc3NhcnkuICBBcyBhbiBl
eGFtcGxlLCBhIHNlcnZlciBjYW4gc2VuZCBhIGNlcnRpZmljYXRlIGFzIGEgU3RyaW5nIGF0dHJp
YnV0ZSBieSBhZGRpbmcgYSBEaWN0aW9uYXJ5IGVudHJ5IGFuZCBmaWxsaW5nIGl0IGluLiAgSG93
ZXZlciwgaW4gb3JkZXIgdG8gdmVyaWZ5IGEgY2VydGlmaWNhdGUsIGNvZGUgY2hhbmdlcyBhcmUg
bmVlZGVkLiAKCkRlc2lnbiBHdWlkZWxpbmVzIHNob3VsZCBwcm9iYWJseSBiZSBjbGFyaWZpZWQg
dG8gZGVhbCB3aXRoIHRoZXNlIGlzc3Vlcy4gCgpTdGF0dXMtU2VydmVyIGRvY3VtZW50LCBBbGFu
IERlS29rICgxMCBtaW51dGVzKQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm
LXJhZGV4dC1zdGF0dXMtc2VydmVyCgpUaGUgZG9jdW1lbnQgaXMgaW4gV0cgbGFzdCBjYWxsIHVu
dGlsIEF1Zy4gNy4gMyBwZW9wbGUgaGF2ZSByZWFkIGl0LiAKQmVybmFyZDogV2Ugc2hvdWxkIGFz
ayBmb3IgcmV2aWV3IGZyb20gSWduYWNpbyBHb3lyZXQgb2YgQXNjZW5kLCB3aG8gaW1wbGVtZW50
ZWQgaXQuIApNYXJrIEpvbmVzOiBkbyBpbXBsZW1lbnRhdGlvbnMgKCJ3aWRlIHVzZSIpIHVzZSB0
aGUgbWVzc2FnZSBhdXRoZW50aWNhdG9yPyAKQWxhbjogc29tZSBkby4gQXNjZW5kIGltcGxlbWVu
dGF0aW9uIGRpZCBub3QuIApBbGFuOiBzdGF0dXMgc2VydmVyIHRoZSBvbmx5IHdheSBvZiBrbm93
aW5nIHRoYXQgYSBwcm94eSBjYW1lIHVwIGFmdGVyIGRpc2Nvbm5lY3RpbmcuCgpSQURJVVMgb3Zl
ciBEVExTLCBBbGFuIERlS29rICgxMCBtaW51dGVzKQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1kZWtvay1yYWRleHQtZHRscwoKTWFqb3IgbmV3IGNvbnRlbnQgaW4gLTAyLiBEb25l
IGFzIGEgZGlmZiBmcm9tIFJBRElVUyBvdmVyIFRMUyBkb2N1bWVudC4gClN0ZWZhbjogd2h5IHJl
dXNlIHNhbWUgcG9ydCBhcyBSQURJVVMsIGFwcC1sZXZlbCBtdWx0aXBsZXhpbmc/IApTdGVmYW4g
YW5kIFlhcm9uOiB3aWxsIG5vdCB3b3JrIHdlbGwgd2l0aCBmaXJld2FsbHMgdGhhdCBpbnNwZWN0
IHRyYWZmaWMuICBUaGV5J2xsIGNvbmNsdWRlIHRoYXQgdGhlIHRyYWZmaWMgaXMgbm90ICJyZWFs
bHkiIFJBRElVUy4gCkFsYW4gRGVLb2s6IFdlIHVzZSBjb2RlIDIyIHRvIGRpZmZlcmVudGlhdGUg
YSBSQURJVVMgcGFja2V0IGZyb20gUkFESVVTIG92ZXIgRFRMUy4gCkJlcm5hcmQ6IGNvZGUgMjIg
aGFzIGJlZW4gYWxsb2NhdGVkLiAgSXMgRFRMUyB0cmFuc3BvcnQgdXNlZCBmb3IgRHluYW1pYyBB
dXRob3JpemF0aW9uPyAgSW4gdGhhdCBjYXNlIGNvdWxkbid0IGNvZGUgMjIgZW5kIHVwIGJlaW5n
IGNvbmZ1c2VkIHdpdGggc29tZXRoaW5nIGVsc2U/IApBbGFuOiBidXQgaXQncyBhIHJlc3BvbnNl
IHBhY2tldCwgc28gaXQncyBzYWZlIGZvciBtdWx0aXBsZXhpbmcuIApCZXJuYXJkOiAgSGFzIERU
TFMgYmVlbiBpbXBsZW1lbnRlZD8gCkFsYW46IGl0IGlzIGluIFJhZFNlYyBwcm94eSwgd2lsbCBt
b3ZlIGluIHRoZSBmdXR1cmUgaW50byBPcGVuUkFESVVTLgoKUkFESVVTIEF0dHJpYnV0ZXMgZm9y
IElQdjYgQWNjZXNzIE5ldHdvcmtzLCBCZWhjZXQgU2FyaWtheWEgKDEwIG1pbnV0ZXMpCmh0dHA6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvdXJkZWxldC1yYWRleHQtaXB2Ni1hY2Nlc3MK
ClN0ZWZhbiBXaW50ZXI6ICBXaHkgaXMgUkFESVVTIGJlaW5nIHVzZWQgYWxvbmcgd2l0aCBESENQ
PyAgVGhlcmUgaXMgbm8gYXV0aGVudGljYXRpb24gaGVyZS4gIApBbGFuOiAgVGhlc2Ugc2xpZGVz
IGRvIG5vdCBtYWtlIHNlbnNlLiAKQmVybmFyZDogIFdoYXQgaXMgYWN0dWFsbHkgaGFwcGVuaW5n
IGlzIHRoYXQgUFBQIGF1dGhlbnRpY2F0aW9uIGlzIG9jY3VycmluZyAoZS5nLiBEU0wpLCBhbmQg
dGhlIEROUyBzZXJ2ZXIgYXR0cmlidXRlIGlzIGJlaW5nIGRlbGl2ZXJlZCBhcyBwYXJ0IG9mIHRo
YXQuICBUaGVuIHdoZW4gdGhlIGNsaWVudCBkb2VzIERIQ1B2NiB3aXRoIHRoZSBOQVMsIHRoZSBO
QVMgaGFzIGdvdCB0aGUgRE5TIHNlcnZlciBhdHRyaWJ1dGUgcmVhZHkuICBUaGUgUHJlZml4IGxp
ZmV0aW1lIGFuZCBETlMgc2VydmVyIGF0dHJpYnV0ZSBjYW4gYmUgc2VudCBhbG9uZyB3aXRoIHRo
ZSBSQSBhcyB3ZWxsLiAgU28gdGhlIHNsaWRlcyBzaG93aW5nIHRoZSBwYWNrZXQgdGltaW5ncyAo
ZS5nLiBSQURJVVMgQWNjZXNzLVJlcXVlc3QgYmVpbmcgc2VudCBzeW5jaHJvbm91c2x5IHdpdGgg
REhDUCkgYXJlIHdyb25nLiAgUkFESVVTIGV4Y2hhbmdlIG9jY3VycyBiZWZvcmUgREhDUCBvciBS
QSBpcyBzZW50IG91dCwgbm8gcmVsYXRpb25zaGlwIHRoZXJlLiAgUkFESVVTIGlzIG5vdCBjYXJy
eWluZyBESENQIHBhY2tldHMsIG9yIGFueXRoaW5nIGxpa2UgdGhhdC4gIFRoZSBzbGlkZXMgYXJl
IG1pc2xlYWRpbmcgKGFuZCBjb25mdXNpbmchKS4gCgpTdGVmYW46ICBXaHkgaXMgdGhpcyBkb2N1
bWVudCB1c2luZyB0aGUgVGFnIGZpZWxkLiAgSXNuJ3QgdGhhdCBkZXByZWNhdGVkIGJ5IERlc2ln
biBHdWlkZWxpbmVzPwpCZXJuYXJkOiBZZXMKClN0ZWZhbiB2b2x1bnRlZXJzIHRvIHJlYWQgdGhl
IGRvY3VtZW50IGFuZCBjb21tZW50IG9uIGl0LiAKIApDb25jbHVkZWQgMTA6MTAuCg=

--_af35414b-5f76-44e1-814a-3728da88fa1d_--

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