Subject: RE: Request for allocation of Tunnel-Type value (fwd)
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Fri, 27 Apr 2007 15:25:37 -0700

Bernard Aboba <mailto:[email-masked]> allegedly scribbled on
Friday, April 27, 2007 12:15 PM:

> Anyway, it looks like the right answer is that Tunnel-Type and
> Tunnel-Medium-Type are allocated as specified in RFC 2868, not 3575. 

Yup.

> 
> Glen Zorn said:
>> I stand corrected.

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

Delivery-date: Fri, 27 Apr 2007 19:15:16 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: RE: Request for allocation of Tunnel-Type value (fwd)
Date: Fri, 27 Apr 2007 12:14:32 -0700

Anyway, it looks like the right answer is that Tunnel-Type and 
Tunnel-Medium-Type are allocated as specified in RFC 2868, not 3575.

Glen Zorn said:
>I stand corrected.

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

Delivery-date: Fri, 27 Apr 2007 17:05:36 +0000
Content-class: urn:content-classes:message
Subject: RE: Request for allocation of Tunnel-Type value (fwd)
Date: Fri, 27 Apr 2007 10:04:51 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Bernard Aboba <mailto:[email-masked]> allegedly scribbled on
Friday, April 27, 2007 7:51 AM:

>> As I recall, the intent was to require both the publication of an RFC
>> and expert review (preferably by a relevant WG).  "Expert Review" as
>> defined in BCP 26 requires neither of these; RFC 3575 seems to imply
>> that the former is required in the case of "Expert Review", but not
>> the latter.
> 
> Here is what RFC 3575 Section 2.1 says:

I stand corrected.

> 
>    For registration requests where a Designated Expert should be
>    consulted, the responsible IESG area director should appoint the
>    Designated Expert.  The intention is that any allocation will be
>    accompanied by a published RFC.  However, the Designated Expert can
>    approve allocations once it seems clear that an RFC will be
>    published, allowing for the allocation of values prior to the
>    document being approved for publication as an RFC.  The Designated
>    Expert will post a request to the AAA WG mailing list (or a
>    successor designated by the Area Director) for comment and review,
>    including an Internet-Draft.  Before a period of 30 days has
>    passed, the Designated Expert will either approve or deny the
>    registration request, publish a notice of the decision to the AAA
>    WG mailing list or its successor, and inform IANA of its decision.
>    A denial notice must be justified by an explanation and, in the
>    cases where it is possible, concrete suggestions on how the
>    request can be modified so as to become acceptable.

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

Delivery-date: Fri, 27 Apr 2007 14:51:52 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: RE: Request for allocation of Tunnel-Type value (fwd)
Date: Fri, 27 Apr 2007 07:51:17 -0700

>As I recall, the intent was to require both the publication of an RFC
>and expert review (preferably by a relevant WG).  "Expert Review" as
>defined in BCP 26 requires neither of these; RFC 3575 seems to imply
>that the former is required in the case of "Expert Review", but not the
>latter.

Here is what RFC 3575 Section 2.1 says:

   For registration requests where a Designated Expert should be
   consulted, the responsible IESG area director should appoint the
   Designated Expert.  The intention is that any allocation will be
   accompanied by a published RFC.  However, the Designated Expert can
   approve allocations once it seems clear that an RFC will be
   published, allowing for the allocation of values prior to the
   document being approved for publication as an RFC.  The Designated
   Expert will post a request to the AAA WG mailing list (or a successor
   designated by the Area Director) for comment and review, including an
   Internet-Draft.  Before a period of 30 days has passed, the
   Designated Expert will either approve or deny the registration
   request, publish a notice of the decision to the AAA WG mailing list
   or its successor, and inform IANA of its decision.  A denial notice
   must be justified by an explanation and, in the cases where it is
   possible, concrete suggestions on how the request can be modified so
   as to become acceptable.

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

Delivery-date: Thu, 26 Apr 2007 23:40:50 +0000
Content-class: urn:content-classes:message
Subject: RE: Request for allocation of Tunnel-Type value (fwd)
Date: Thu, 26 Apr 2007 16:40:30 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Bernard Aboba <> allegedly scribbled on Thursday, April 26, 2007 3:46
PM:

> A question has arisen as to the appropriate IANA allocaiton policy
> for new values of the Tunnel-Type and Tunnel-Medium-Type attributes. 
> 
> RFC 3575 states that all RADIUS attribute values are assigned by
> Designated Expert, with the exception of Service-Type.  However this
> document only indicates that it updates RFC 2865, not RFC 2868, which
> indicates allocation by IETF consensus.   
> 
> At first glance, this looks like an oversight.  

Maybe, but nevertheless we can change either RFC or leave them both
alone.  I prefer the latter.

> Is there a reason why
> assignment of a new Tunnel-Type value should require IETF consensus
> rather than Designated Expert?  

As I recall, the intent was to require both the publication of an RFC
and expert review (preferably by a relevant WG).  "Expert Review" as
defined in BCP 26 requires neither of these; RFC 3575 seems to imply
that the former is required in the case of "Expert Review", but not the
latter.

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

Delivery-date: Thu, 26 Apr 2007 22:46:40 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Request for allocation of Tunnel-Type value (fwd)
Date: Thu, 26 Apr 2007 15:46:05 -0700

A question has arisen as to the appropriate IANA allocaiton policy for new 
values of the Tunnel-Type and Tunnel-Medium-Type attributes.

RFC 3575 states that all RADIUS attribute values are assigned by Designated 
Expert, with the exception of Service-Type.  However this document only 
indicates that it updates RFC 2865, not RFC 2868, which indicates allocation 
by IETF consensus.

At first glance, this looks like an oversight.  Is there a reason why 
assignment of a new Tunnel-Type value should require IETF consensus rather 
than Designated Expert?

--------------------------------------------------------------------------------
From: Amanda Baber via RT [mailto:[email-masked]]
Sent: Thu 4/26/2007 2:15 PM
Cc: Bernard Aboba; [email-masked]
Subject: [IANA #75548] General Request for Assignments (RADIUS Attribute 64, 
Tunnel-Type)

Dear Bernard,

Can you advise IANA on this request for a new value for RADIUS
attribute 64 (Tunnel-Type)?

Section 6.1 of RFC 2868 states, "Values 1-12 of the Tunnel-Type
Attribute are defined in Section 5.1; the remaining values are
available for assignment by the IANA with IETF Consensus [16]."
(Section 6.2 describes the same procedure for the remaining
Tunnel-Medium-Type Attribute Values.)

Section 2.1 of RFC 3575 appears to indicate that all attribute
values are assigned by Designated Expert, except for those values
associated with the Service-Type attribute. However, RFC 2868 does
not appear to have been updated or obsoleted.

RFC 3575 also states, "The intention is that any allocation will be
accompanied by a published RFC.  However, the Designated Expert can
approve allocations once it seems clear that an RFC will be
published, allowing for the allocation of values prior to the
document being approved for publication as an RFC."

Is the value he's requesting assigned by IETF Consensus, or by the
process described in RFC 3575? If the latter, how should we advise
the requester to proceed with this application?

Thanks,

Amanda Baber
IANA

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

Delivery-date: Fri, 20 Apr 2007 02:42:47 +0000
Date: Thu, 19 Apr 2007 22:39:55 -0400
To: [email-masked]
From: David Mitton <[email-masked]>
Subject: RE: new Service-Type

I attempted to reply to this message last week, but my provider's webmail
failed me twice and then lost the draft copy.  Sigh....

On 4/10/2007 07:19 AM, David B. Nelson wrote:
>Alan DeKok writes ...
...
>IANA allocations for RADIUS are controlled by RFC 3575, which reads, in
>part, as follows:
...
> >   The benefit with the method suggested in RFC 2882 is that
> > you do not need IANA approval for the allocation.
>
>I personally consider vendor-specific enumerations, as described in RFC 2882
>to be a very bad practice.  Please recall that RFC 2882 describes RADIUS
>practices encountered in implementations, but does not necessisarily
>recommend these practices.  Various versions of the RADIUS Design Guidelines
>draft have included text recommending against using VSEs, in favor of
>standard IANA allocations.
>
>RFC 2882 says, in part:
>
>    This technique has not seen any acceptance by the
>    working group or other vendors, however, the vendor did accomplish
>    the goal of not conflicting with working group additions or other
>    vendor values.
>
>In my opinion, which is based in part on discussions with the author of RFC
>2882, that document lists certain practices which ought not to be
>encouraged, in the interests of interoperability, but rather which vendors
>have resorted to in order to bypass the normal IETF processes.

RFC 2882 was written in the NASREQ WG to provide information as to why RADIUS
as it was, needed more work.  The re-reading the abstract I see it 
says it well:

    This document describes current practices implemented in NAS products
    that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The
    purpose of this effort is to give examples that show the need for
    addressing and standardizing these types of ad-hoc functions.  Since
    many of these features require a matching server support component,
    the ability to deploy and manage interoperable NAS and AAA server
    products is severely hindered.

The document itself, is often called by me, as a "Worst Practices" document.
It is not an example of what to do, but to open peoples eyes to the types of
things people were trying to do, and the problems they create.
>In any event, new values of Service-Type, VSE or otherwise, do require IANA
>allocation and do require IETF consensus.

I will also point out that RFC 2882 was written before RFC 3575 was published.
And I'm sure some of the portions Dave N. quotes were probably 
tweaked to prevent some
of the issues I documented in 2882.

W.r.t. VSEs, Since I created them, I am sympathetic to the rationale.
While they do work, they create the interoperabilty problems Dave 
points out later in this thread.
I encountered at least one RADIUS server that couldn't deal with the 
attribute values because they'd
used only a byte internally for the nominal 4 byte integer.

At the time, the code points I needed were additional Service-Types 
and Acct-Status-Types.
Ultimately that product made the VSE code points an option that could 
be turned off.

In general I would not recommend this type of design, but at the 
time, the politics of the IETF
made it seem impossible to get anything RADIUS related even discussed.

Some things have changed....

Dave.

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

Delivery-date: Fri, 20 Apr 2007 00:35:35 +0000
Content-class: urn:content-classes:message
Subject: RE: comments on draft-zorn-radius-keywrap-12.txt
Date: Thu, 19 Apr 2007 17:35:03 -0700
From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>, <[email-masked]>

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Thursday, April 19, 2007 5:12 PM
> To: [email-masked]; [email-masked]
> Subject: RE: comments on draft-zorn-radius-keywrap-12.txt
> 
> >[Joe] I disagree here.  The KEK ID is an opaque octet string to 
> >identify the key that is being used to encrypt the key.  
> This document 
> >does not specify a way to establish a key and the KEK ID is there to 
> >facilitate different forms of key management.
> 
> In the existing implementations, what forms of key management 
> are used to establish the KEK ID?
> Is there a specification for the key management mechanisms?
> 
[Joe] Currently it is done by manual keying, which is less than ideal.

> >In particular the attributes are
> >designed not to require additional state on the RADIUS server so the 
> >use of a KEK ID allows a new key to be brought into use.  
> The KEK ID is 
> >necessary unless a particular key management scheme is 
> specified that 
> >does not require it.
> 
> RADIUS as it exists today does not require a KEK ID because 
> it impliictly assumes that there is only one key used between 
> a RADIUS client and server at a time and that this key is 
> identified by the client and server IP 
> addresses.   At IETF 68, Key Rollover was given as the 
> primary reason why 
> more than one key might be valid at a given time, so that 
> some other key identifier might be needed.  Assuming that 
> credible ciphers (e.g. AES) are used, why should key rollover 
> represent a problem?
> 

[Joe] yes, the primary reason to have a key ID is so you can change
keys.  Credible ciphers are not the problem.  People may wish to change
keys for administrative reasons (change of personnel etc.).  In addition
if an automated key management is performed "out-of-band" then you may
need to identify a specific key from several generated keys. Regardless
of whether it is cryptographically necessary or not a key lifetime is
often defined for management purposes, when the life time expires the
key needs to be replaced. 

> >The KM ID serves to identify they key that is being 
> transported.  This 
> >definition of this is specified by the application for which 
> the key is 
> >to be used.  The draft should specify that for a the EAP-MSK 
> >application this field is not used since there already is an 
> attribute 
> >defined to hold the EAP-MSK ID.
> 
> So you are saying that this specification is designed to 
> enable future RADIUS key managment applications, rather than 
> the existing ones?
> 

[Joe] No, the specification supports existing RADIUS key management
applications as well as enables future one.  

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

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

Delivery-date: Fri, 20 Apr 2007 00:12:29 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: comments on draft-zorn-radius-keywrap-12.txt
Date: Thu, 19 Apr 2007 17:11:44 -0700

>[Joe] I disagree here.  The KEK ID is an opaque octet string to identify
>the key that is being used to encrypt the key.  This document does not
>specify a way to establish a key and the KEK ID is there to facilitate
>different forms of key management.

In the existing implementations, what forms of key management are used to 
establish the KEK ID?
Is there a specification for the key management mechanisms?

>In particular the attributes are
>designed not to require additional state on the RADIUS server so the use
>of a KEK ID allows a new key to be brought into use.  The KEK ID is
>necessary unless a particular key management scheme is specified that
>does not require it.

RADIUS as it exists today does not require a KEK ID because it impliictly 
assumes that there is only one key used between a RADIUS client and server 
at a time and that this key is identified by the client and server IP 
addresses.   At IETF 68, Key Rollover was given as the primary reason why 
more than one key might be valid at a given time, so that some other key 
identifier might be needed.  Assuming that credible ciphers (e.g. AES) are 
used, why should key rollover represent a problem?

>The KM ID serves to identify they key that is being transported.  This
>definition of this is specified by the application for which the key is
>to be used.  The draft should specify that for a the EAP-MSK application 
>this field is
>not used since there already is an attribute defined to hold the EAP-MSK
>ID.

So you are saying that this specification is designed to enable future 
RADIUS key managment applications, rather than the existing ones?

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

Delivery-date: Thu, 19 Apr 2007 21:45:45 +0000
Content-class: urn:content-classes:message
Subject: RE: Request for RADIUS crypto-agility solutions
Date: Thu, 19 Apr 2007 14:45:04 -0700
From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

I propose an attribute based crypto agility solution based on the
following documents:

http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-12.txt
and
http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-06.txt

One of the goals of this approach is to reduce the impact on current
RADIUS implementations by using attributes similar to existing
attributes and not requiring "session state" between the RADIUS client
and server.  I believe this will be less impact on RADIUS
implementations than the DTLS approach.

Joe 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Wednesday, April 11, 2007 6:10 AM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Re: Request for RADIUS crypto-agility solutions
> 
> Bernard Aboba wrote:
> > This is a formal request for submission of documents solving the 
> > RADIUS crypto-agility problem.  Proposers should send an 
> email to the RADEXT WG
> > list providing a pointer to their proposal by April 21, 
> 2007.   Once the
> > proposals have been submitted, we will initiate WG review.
> 
>   I propose RADIUS + DTLS, as presented at IETF 68:
> 
> http://tools.ietf.org/id/draft-dekok-radext-dtls-00.txt
> 
>   Alan DeKok.
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Wed, 18 Apr 2007 17:35:41 +0000
Content-class: urn:content-classes:message
Subject: RE: comments on draft-zorn-radius-keywrap-12.txt
Date: Wed, 18 Apr 2007 10:34:37 -0700
From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
To: "Dan Harkins" <[email-masked]>, <[email-masked]>

Hi Dan,

Comments inline.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Dan Harkins
> Sent: Monday, January 22, 2007 4:45 PM
> To: [email-masked]
> Subject: comments on draft-zorn-radius-keywrap-12.txt
> 
> 
>   Hi,
> 
>   I recently read draft-zorn-radius-keywrap-12.txt and have a few 
> comments. I hope they can be addressed before this draft is advanced 
> to RFC.
> 
>   general:
>     * there is a real lack of requirements in this draft. Most things
>       are MAY and it looks like a compliant implementation could do
>       almost nothing, which seems odd for an RFC. Furthermore
>       interoperability will be extremely difficult since little 
> behavior
>       MUST be followed. Ironically. one of the rare MUSTs in the draft
>       really should be a SHOULD.

[Joe] There are interoperable implementations of this specification
between different vendors, however the specification could probably be
improved for clarity. 
 
>   section 3.1:
>     * the Key ID, lifetime, IV and Key material fields MAY be omitted
>       but then the length of the keying material attribute would not
>       be >= 24 as defined later on when the layout of the attribute is
>       defined. I suggest changing the length to be >= 8 and specify 
> that
>       if any of these attributes are omitted then they MUST all be 
> omitted
>       otherwise someone could legitimately omit one field and include
>       another and it would be impossible to parse the attribute on 
> receipt.

[Joe] I agree. 

>     * "if the client requires the use of the Keying-Material 
> Attribute"
>       but it's not present then it "MAY ignore the message"? 
> This should
>       be MUST or else "require" doesn't mean what I believe most 
> people
>       think it means.
> 
[Joe] This seems reasonable to me. 

>     * KEK ID, KM ID are both unspecified. They are supposed to 
> identify
>       the key but how? If the Frobnitz corporation defines the ID to 
> be
>       sha("the KEK ID") and the Fubar corporation defines it as the
>       string "this is your KEK ID!" (both 20 bytes) then how do they
>       interoperate? 20 bytes? Why won't 4 do? Or even 2? Does this 
> have
>       something to do with hashing to produce an ID? It's not 
> specified.
> 
>       Having unspecified things and then say "Further specification of

> the
>       content of this field is outside the scope of this document" 
> means
>       that specification in its entirety is outside the scope of this
>       document. That being the case then why is this even part of an 
> IETF
>       document? These fields should be removed before the document is
>       advanced.
> 
>       The KEK ID and KM ID, being entirely unspecified, are gigantic
>       subliminal channels. I really don't think that's appropriate.
> 
[Joe] I disagree here.  The KEK ID is an opaque octet string to identify
the key that is being used to encrypt the key.  This document does not
specify a way to establish a key and the KEK ID is there to facilitate
different forms of key management.  In particular the attributes are
designed not to require additional state on the RADIUS server so the use
of a KEK ID allows a new key to be brought into use.  The KEK ID is
necessary unless a particular key management scheme is specified that
does not require it.  

The KM ID serves to identify they key that is being transported.  This
definition of this is specified by the application for which the key is
to be used.  Incorporating this identity in the attribute reduces the
need to have separate attributes for key ID which would be difficult to
disambiguate if there are multiple attributes keys in the packet. The
draft should specify that for a the EAP-MSK application this field is
not used since there already is an attribute defined to hold the EAP-MSK
ID.   

>     * if the Enc Type field is 0 then "the IV field MUST be as 
> specified
>       in RFC3394". Is it supposed to be the "default IV"? If so then 
> why
>       even bother sending it in the attribute? It would be painful to
>       make the attribute variable length-- i.e. if Enc Type field is 0
>       then there is no IV field-- so why not change this MUST to a 
> SHOULD?
>       Also, there may be legitimate reasons to use a different IV than

> the
>       default one listed in RFC3394 (which is why that RFC allows it).
> 

[Joe] Apparently there are many different opinions on whether they IV
MUST be the default specified in RFC 3394.  Originally we meant it to be
variable with the default suggested, however during expert review it was
strongly suggested by an expert that it MUST be the default IV.  

>   section 3.3:
>     * MAC Key ID, same comments apply here as with KEK ID and KM ID 
> above.
>
[Joe] Same comment as the KEK ID above.
 
>   section 5:
>     * If two new keys are being defined then there is no point in 
> having 3
>       ID fields to identify them. They are implicitly identified here.

> One
>       key is for key wrapping and the other key is used for integrity
>       checking. Again, there is no need for a KEK ID, KM ID, or MAC 
> Key ID.
> 
[Joe] there are 3 keys the key used for MAC, the key used for key
encryption and the key being encrypted.  All are currently identified as
they are different keys.  As for the KEK and MAC keys it is possible for
them to be derived from the same key or key exchange.  If a key
management mechanism is decided upon perhaps one of these fields may be
deprecated.  However, the freedom to be able to have these keys vary can
facilitate different deployment models that are not possible with RADIUS
today.  

>     * I think these two new keys MUST be cryptographically independent

> of
>       the RADIUS shared secret (not SHOULD). The RADIUS shared secret
>       already has a defined use and it's not as a key deriving key. 
> There
>       is no valid reason in any particular circumstance to ignore this
>       particular item (to paraphrase RFC2119).
> 
[Joe] We had some discussion of this among the authors.  In general we
all agreed that these keys SHOULD be independent of the RADIUS shared
secret.  We stopped short of mandating this because several felt that
these new attributes provided a significant advantage over the current
RADIUS mechanisms even if the current shared secret is used to
facilitate deployment.  Ideally we would be able to specify a key
management mechanism that would allow for automated key exchange.  

>   I think it's great to have an RFC3394-style way to send keys from a 
> RADIUS server to a RADIUS client but this seems to go way beyond that 
> simple task. And there isn't any real apparent justification for those

> excesses. KEK ID, KM ID, MAC Key ID... please just get rid of them. If

> someone wants to pass VSAs then they should just pass VSAs.
> 
>   thanks,
> 
>   Dan.
> 
> 
> 
> 

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

Delivery-date: Mon, 16 Apr 2007 18:32:38 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Proxy State and RFC 3576bis
Date: Mon, 16 Apr 2007 11:31:50 -0700

Good point.

RFC 3576 implementers -- can you weigh in?

>From: Alan DeKok <[email-masked]>
>To: Bernard Aboba <[email-masked]>
>CC: [email-masked]
>Subject: Re: Proxy State and RFC 3576bis
>Date: Fri, 13 Apr 2007 03:06:18 +0200
>
>Bernard Aboba wrote:
> > [Alan DeKok]  Yes.
> >
> > [BA] This suggests that paragraphs 3 and 4 in the text below are not
> > correct. Any suggestions on how we can fix it?
>
>   Before I do that, it would appear that my recommendation here is
>opposite to what RFC 3576 says.  Are we OK with changing the
>recommendation in -bis?
>
>   That is, do current implementations behave as per RFC 3576?  If so, I
>would prefer to maintain inter-operability.  The text can then be left
>as-is.
>
>   If not, then the implementations do not use Proxy-State, and I would
>prefer to replace the paragraphs with other text explaining why
>Proxy-State is not used.  The text in RFC 3576 permits implementations
>to receive Proxy-State, but to not forward it.  Maybe the
>implementations have chosen that method.
>
>   My preference is to have one recommended method of operation, rather
>than 2-3.
>
>   I'd like to get clarity on those questions before submitting suggested
>text.
>
>   Alan DeKok.
>

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

Delivery-date: Mon, 16 Apr 2007 13:01:15 +0000
Content-class: urn:content-classes:message
Subject: FW: Publication of RADIUS Prepaid Document
Date: Mon, 16 Apr 2007 15:00:05 +0200
From: "Andreas Pashalidis" <[email-masked]>
To: <[email-masked]>

Dear all,

No objections from my side. 
(apologies for this late reply).

Kind Regards,
Andreas Pashalidis

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

Original Message:

From: Bernard Aboba
Sent: Wed 3/21/2007 6:26 AM
To: [email-masked]
Subject: Publication of RADIUS Prepaid Document

At IETF 68, it was suggested that the RADIUS Prepaid document be published as an Informational RFC documenting existing usage (presumably based on 
RADIUS VSAs).   This would enable us to unblock the document, since 
conformance to the Guidelines document (still in progress) would no longer be required.

Are there any objections to this approach?

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

Delivery-date: Fri, 13 Apr 2007 01:08:06 +0000
Date: Fri, 13 Apr 2007 03:06:18 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Proxy State and RFC 3576bis

Bernard Aboba wrote:
> [Alan DeKok]  Yes.
> 
> [BA] This suggests that paragraphs 3 and 4 in the text below are not
> correct. Any suggestions on how we can fix it?

  Before I do that, it would appear that my recommendation here is
opposite to what RFC 3576 says.  Are we OK with changing the
recommendation in -bis?

  That is, do current implementations behave as per RFC 3576?  If so, I
would prefer to maintain inter-operability.  The text can then be left
as-is.

  If not, then the implementations do not use Proxy-State, and I would
prefer to replace the paragraphs with other text explaining why
Proxy-State is not used.  The text in RFC 3576 permits implementations
to receive Proxy-State, but to not forward it.  Maybe the
implementations have chosen that method.

  My preference is to have one recommended method of operation, rather
than 2-3.

  I'd like to get clarity on those questions before submitting suggested
text.

  Alan DeKok.

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

Delivery-date: Thu, 12 Apr 2007 19:14:04 +0000
Date: Thu, 12 Apr 2007 21:12:17 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Proxies and retransmissions?

Bernard Aboba wrote:
> Proxy retransmission is definitely a bad idea, since it violates the
> principle of "Conservation of Packts", and thus could lead to congestion
> problems. I don't have personal knowledge of proxy implementations that
> retransmit, but then again I wouldn't be surprised if such
> implementations existed.

  I've just been reviewing a proposal for a standardized RADIUS
fail-over and retransmit.  It involves N stages of proxies, each with
primary & secondary.  On NAS retransmit, each proxy is supposed to send
 packets to both the primary and secondary.  The document states that
there's obviously an exponential explosion in the number of packets, but
for small N, it's claimed to be OK.

  I don't agree.

  Alan DeKok.

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

Delivery-date: Thu, 12 Apr 2007 15:57:25 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Proxies and retransmissions?
Date: Thu, 12 Apr 2007 08:56:57 -0700

>   I think it's best to say intermediate nodes SHOULD NOT retransmit of
>their own accord.  They should do so only when they receive a retransmit
>from the NAS.
>
>   Is this an issue we need to address?  How do current implementations
>deal with retransmits?

Proxy retransmission is definitely a bad idea, since it violates the 
principle of "Conservation of Packts", and thus could lead to congestion 
problems. I don't have personal knowledge of proxy implementations that 
retransmit, but then again I wouldn't be surprised if such implementations 
existed.

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

Delivery-date: Thu, 12 Apr 2007 15:49:36 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Proxy State and RFC 3576bis
Date: Thu, 12 Apr 2007 08:49:07 -0700

Bernard Aboba wrote:
>One of the deployment blockers with RFC 3576 is the need to modify
>proxies to handle routing of RFC 3576 packets.  While proxies typically
>keep tables for dowstream forwarding, they typically do not keep tables
>Given this, I am wondering how RADIUS proxies should handle Proxy-State
>for RFC 3576 packets:
>
>a. Do they add Proxy-State attributes to a Disconnect/CoA-Request as
>suggested in the current text (and as would be done for an Access-Request)?

[Alan DeKok] No.

>b. Or can the RADIUS server include a Proxy-State attribute previously
>obtained from an Access-Request used in the original authentication
>within the Disconnect/CoA-Request to assist the proxy in routing the
>request back to the NAS?  In this case, wouldn't the RADIUS proxy
>*remove* Proxy-State attributes from the Disconnect/CoA-Request??

[Alan DeKok]  Yes.

[BA] This suggests that paragraphs 3 and 4 in the text below are not
correct. Any suggestions on how we can fix it?

---------------
     If there are any Proxy-State Attributes in a Disconnect-Request or
     CoA-Request received from the server, the forwarding proxy or NAS
     MUST include those Proxy-State Attributes in its response to the
     server.

     A forwarding proxy or NAS MUST NOT modify existing Proxy-State,
     State, or Class Attributes present in the packet.  The forwarding
     proxy or NAS MUST treat any Proxy-State attributes already in the
     packet as opaque data.  Its operation MUST NOT depend on the
     content of Proxy-State attributes added by previous proxies.  The
     forwarding proxy MUST NOT modify any other Proxy-State Attributes
     that were in the packet; it may choose not to forward them, but it
     MUST NOT change their contents.  If the forwarding proxy omits the
     Proxy-State Attributes in the request, it MUST attach them to the
     response before sending it.

     When the proxy forwards a Disconnect or CoA-Request, it MAY add a
     Proxy-State Attribute, but it MUST NOT add more than one.  If a
     Proxy-State Attribute is added to a packet when forwarding the
     packet, the Proxy-State Attribute MUST be added after any existing
     Proxy-State attributes.  The forwarding proxy MUST NOT change the
     order of any attributes of the same type, including Proxy-State.
     Other Attributes can be placed before, after or even between the
     Proxy-State Attributes.

     When the proxy receives a response to a CoA-Request or Disconnect-
     Request, it MUST remove its own Proxy-State (the last Proxy- State
     in the packet) before forwarding the response.  Since Disconnect
     and CoA responses are authenticated on the entire packet contents,
     the stripping of the Proxy-State Attribute invalidates the
     integrity check - so the proxy needs to recompute it.

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

Delivery-date: Thu, 12 Apr 2007 14:57:06 +0000
Date: Thu, 12 Apr 2007 16:55:37 +0200
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  [email-masked]
Subject: Re: Guidelines Document Discussion

Avi Lior wrote:
> [Avi] Sorry i must be missing something.  Can you explain what you mean
> by non-qualified attribute names or qualified attribute name.

  Qualified attribute name: SDO-Attribute-Foo
  Unqualified attribute name: Attribute-Foo

> [Avi] Sorry Alan but i don't get it.  We never work with attribute names
> themselves we work with Vendor Specific Dictionaries so all attributes
> are always relative to a dictionary.  So there is no confusion.

  The qualified attribute names are an attempt to enforce naming
relative to a dictionary.

  Let's take RFC 4679 as an example.  It defines Agent-Circuit-Id, among
other attributes.  As a vendor, Redback also defines Agent-Circuit-Id.

  If we simply refer to Agent-Circuit-Id, that name is ambiguous.  We
could say "RFC 4679 Agent-Circuit-Id", and "Redback VSA
Agent-Circuit-Id".  Or, we could say "ADSL-Agent-Circuit-Id", and
"Redback-Agent-Circuit-Id".

  I prefer the second method.

> [Avi] If you are thinking of suggesting that SDO prefix their attributes
> with the SDOs name.  That could be a good idea.  Its a little too late.
> And would require that we create a registry for SDO prefixes.  But I am
> not sure that this really helps.  It may make it easier for humans to read.

  The 3GPP && 3GPP2 forums have already done this.  We can request that
SDOs do this for future work.

> [Avi] The conflict is in the human brain but not in the protocol. Right?

  And in the implementation that has to parse "Agent-Circuit-Id", and
try to guess which SDO or vendor it applies to.  Ambiguity does not
result in interoperable implementations.

> [Avi] I am not opposed to it but I dont think its as big a problem as
> you make it out to be.

  It's been a problem for me, and for the people I have to support.

> [Avi]  X_DNS_NAME and Y_DNS_NAME is equally confusing.  And we already
> of namespaces.  If someone gave me a policy if IF X = 1.2.3.4 I would
> ask which Vendor Dictionary are you using for X.

  Why do that when you can just refer to the fully qualified name?

>  By the way that is a
> human readable policy not an actual policy.  That policy would translate
> X to something like (26,2234,45). 

  The administrator may be typing in the name, rather than selecting it
from a drop-down menu.  With a drop down menu, that qualification can
happen automatically, because the context for the name is available.  If
the name is entered as a test string, additional qualification is needed
to resolve ambiguity.

  And humans need to be able to discuss policy, too.  We're not going to
talk about (26,2234,45) on this list.  (Or at least, I can't be bothered
to remember those numbers).  We can talk about Agent-Circuit-Id, though.

> [Avi] Why do you think SDOs are stupid?  They change the
> meaning/definition of an attribute like smart people at the IETF do. 
> For example, adding a new enumeration to an enumerated type. Or when a
> bug is found.  Or the semantics of an attribute can change as well while
> still maintianing backwards compatibility.

  The semantics of an attribute can be clarified without changing its
meaning.  If the meaning changes, then I don't understand how the "same"
attribute can be used simultaneously with two different meanings.  Maybe
I'm the one that's stupid, but I just don't see how it can work.

  Alan DeKok.

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

Delivery-date: Thu, 12 Apr 2007 14:33:53 +0000
Subject: RE: Guidelines Document Discussion
Date: Thu, 12 Apr 2007 10:34:15 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C77D0F.A50F527A
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Avi Lior
Office: +1 613 591-9104 x 6417
Cell  : +1 613 796-4183

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]]
Sent: Thu 4/12/2007 4:01 AM
To: Avi Lior
Cc: Bernard Aboba; [email-masked]
Subject: Re: Guidelines Document Discussion
 
Avi Lior wrote:
>   i.e. SDO-One-DNS-Server && SDO-Two-DNS-Server are OK.
> [Avi] When I said name space I mean an implicit name-space.  I don't
> think that vendors and operators be required to call their attribute
> SDO-A-Foobar.  The vendor id creates a name-space and that is
> sufficient.

  I strongly disagree.  Vendors or SDOs who use non-qualified attribute
names have caused interoperability problems in the past, and will
continue to do so in the future.

[Avi] Sorry i must be missing something.  Can you explain what you mean by non-qualified attribute names or qualified attribute name.

>  The actual naming of the attribute is for human
> readability.

  And for policies.  If the policy says "Do X if DNS-Server is set to
1.2.3.4", what does that mean when two SDO's define the same name?

  SDO namespaces allow clear policies to be created.  Non-SDO namespaces
allow policies to be created that cannot be meaningfully interpreted.

[Avi] Sorry Alan but i don't get it.  We never work with attribute names themselves we work with Vendor Specific Dictionaries so all attributes are always relative to a dictionary.  So there is no confusion.

[Avi] If you are thinking of suggesting that SDO prefix their attributes with the SDOs name.  That could be a good idea.  Its a little too late. And would require that we create a registry for SDO prefixes.  But I am not sure that this really helps.  It may make it easier for humans to read.

> [Avi] it's a fact of life that two SDOs can and probably will define
> attribute that have the same name.  They are operating autonomously.

  Then the RADIUS guidelines document needs to say that the attribute
names should be prefixed with the SDO name, to obtain an SDO-specific
namespace.  They can then operate autonomously without the possibility
of conflict.

[Avi] The conflict is in the human brain but not in the protocol. Right?

[Avi] This is not a RADIUS only problem by the way.  It is an IETF problem since VSA are defined by many protocols.

[Avi] I am not opposed to it but I dont think its as big a problem as you make it out to be.

> When working in one SDO I am not checking the attributes of another SDOs
> or other vendors.  Its not practical.  I don't know about all the SDOs
> or all the vendors.  Lets get real here.

  Yes.  Which is why prefixes create independent name spaces, and do not
require coordination.  Allowing SDO's to create names *without* prefixes
has all of the problems you highlight, and all of the problems I
highlight.  Why not avoid both problems by using namespaces?

[Avi]  X_DNS_NAME and Y_DNS_NAME is equally confusing.  And we already of namespaces.  If someone gave me a policy if IF X == 1.2.3.4 I would ask which Vendor Dictionary are you using for X.  By the way that is a human readable policy not an actual policy.  That policy would translate X to something like (26,2234,45).  

Even if we had a prefix, I still would not rely on that prefix when writting the policy down.  I still would use X plus dictionary name.  Or I would say X as defined by some reference so I know the context of the attribute.

>   Attributes change their meaning?  That's bad practice.
> 
> [Avi] Meaning or semantics. Well that is just the way the cookie
> crumbles sometimes.  It is precisely dogma like that that make some SDOs
> nervous about sharing.

  That's an interesting approach.  SDO's change the meaning of
attributes so that existing implementations and deployments are
non-compliant with the new meanings.  Existing implementations and
deployments are also non-interoperable with new deployments that
understand the new meaning.  And it makes the SDO's nervous to have this
pointed out?

  Curious.  Or maybe I misunderstood exactly how the SDO's change the
meaning of attributes, while maintaining backwards compatibility and
interoperability.

[Avi] Why do you think SDOs are stupid?  They change the meaning/definition of an attribute like smart people at the IETF do.  For example, adding a new enumeration to an enumerated type. Or when a bug is found.  Or the semantics of an attribute can change as well while still maintianing backwards compatibility.

  Alan DeKok.

------_=_NextPart_001_01C77D0F.A50F527A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59">
<TITLE>RE: Guidelines Document Discussion</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<BR>

<P><FONT SIZE=2>Avi Lior<BR>
Office: +1 613 591-9104 x 6417<BR>
Cell&nbsp; : +1 613 796-4183<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Alan DeKok [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]<BR>
Sent: Thu 4/12/2007 4:01 AM<BR>
To: Avi Lior<BR>
Cc: Bernard Aboba; [email-masked]<BR>
Subject: Re: Guidelines Document Discussion<BR>
<BR>
Avi Lior wrote:<BR>
&gt;&nbsp;&nbsp; i.e. SDO-One-DNS-Server &amp;&amp; SDO-Two-DNS-Server are OK.<BR>
&gt; [Avi] When I said name space I mean an implicit name-space.&nbsp; I don't<BR>
&gt; think that vendors and operators be required to call their attribute<BR>
&gt; SDO-A-Foobar.&nbsp; The vendor id creates a name-space and that is<BR>
&gt; sufficient.<BR>
<BR>
&nbsp; I strongly disagree.&nbsp; Vendors or SDOs who use non-qualified attribute<BR>
names have caused interoperability problems in the past, and will<BR>
continue to do so in the future.<BR>
<BR>
[Avi] Sorry i must be missing something.&nbsp; Can you explain what you mean by non-qualified attribute names or qualified attribute name.<BR>
<BR>
<BR>
&gt;&nbsp; The actual naming of the attribute is for human<BR>
&gt; readability.<BR>
<BR>
&nbsp; And for policies.&nbsp; If the policy says &quot;Do X if DNS-Server is set to<BR>
1.2.3.4&quot;, what does that mean when two SDO's define the same name?<BR>
<BR>
&nbsp; SDO namespaces allow clear policies to be created.&nbsp; Non-SDO namespaces<BR>
allow policies to be created that cannot be meaningfully interpreted.<BR>
<BR>
<BR>
[Avi] Sorry Alan but i don't get it.&nbsp; We never work with attribute names themselves we work with Vendor Specific Dictionaries so all attributes are always relative to a dictionary.&nbsp; So there is no confusion.<BR>
<BR>
[Avi] If you are thinking of suggesting that SDO prefix their attributes with the SDOs name.&nbsp; That could be a good idea.&nbsp; Its a little too late. And would require that we create a registry for SDO prefixes.&nbsp; But I am not sure that this really helps.&nbsp; It may make it easier for humans to read.<BR>
<BR>
<BR>
<BR>
&gt; [Avi] it's a fact of life that two SDOs can and probably will define<BR>
&gt; attribute that have the same name.&nbsp; They are operating autonomously.<BR>
<BR>
&nbsp; Then the RADIUS guidelines document needs to say that the attribute<BR>
names should be prefixed with the SDO name, to obtain an SDO-specific<BR>
namespace.&nbsp; They can then operate autonomously without the possibility<BR>
of conflict.<BR>
<BR>
[Avi] The conflict is in the human brain but not in the protocol. Right?<BR>
<BR>
[Avi] This is not a RADIUS only problem by the way.&nbsp; It is an IETF problem since VSA are defined by many protocols.<BR>
<BR>
[Avi] I am not opposed to it but I dont think its as big a problem as you make it out to be.<BR>
<BR>
&gt; When working in one SDO I am not checking the attributes of another SDOs<BR>
&gt; or other vendors.&nbsp; Its not practical.&nbsp; I don't know about all the SDOs<BR>
&gt; or all the vendors.&nbsp; Lets get real here.<BR>
<BR>
&nbsp; Yes.&nbsp; Which is why prefixes create independent name spaces, and do not<BR>
require coordination.&nbsp; Allowing SDO's to create names *without* prefixes<BR>
has all of the problems you highlight, and all of the problems I<BR>
highlight.&nbsp; Why not avoid both problems by using namespaces?<BR>
<BR>
[Avi]&nbsp; X_DNS_NAME and Y_DNS_NAME is equally confusing.&nbsp; And we already of namespaces.&nbsp; If someone gave me a policy if IF X == 1.2.3.4 I would ask which Vendor Dictionary are you using for X.&nbsp; By the way that is a human readable policy not an actual policy.&nbsp; That policy would translate X to something like (26,2234,45).&nbsp;<BR>
<BR>
Even if we had a prefix, I still would not rely on that prefix when writting the policy down.&nbsp; I still would use X plus dictionary name.&nbsp; Or I would say X as defined by some reference so I know the context of the attribute.<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
&gt;&nbsp;&nbsp; Attributes change their meaning?&nbsp; That's bad practice.<BR>
&gt;<BR>
&gt; [Avi] Meaning or semantics. Well that is just the way the cookie<BR>
&gt; crumbles sometimes.&nbsp; It is precisely dogma like that that make some SDOs<BR>
&gt; nervous about sharing.<BR>
<BR>
&nbsp; That's an interesting approach.&nbsp; SDO's change the meaning of<BR>
attributes so that existing implementations and deployments are<BR>
non-compliant with the new meanings.&nbsp; Existing implementations and<BR>
deployments are also non-interoperable with new deployments that<BR>
understand the new meaning.&nbsp; And it makes the SDO's nervous to have this<BR>
pointed out?<BR>
<BR>
&nbsp; Curious.&nbsp; Or maybe I misunderstood exactly how the SDO's change the<BR>
meaning of attributes, while maintaining backwards compatibility and<BR>
interoperability.<BR>
<BR>
[Avi] Why do you think SDOs are stupid?&nbsp; They change the meaning/definition of an attribute like smart people at the IETF do.&nbsp; For example, adding a new enumeration to an enumerated type. Or when a bug is found.&nbsp; Or the semantics of an attribute can change as well while still maintianing backwards compatibility.<BR>
<BR>
&nbsp; Alan DeKok.<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C77D0F.A50F527A--

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

Delivery-date: Thu, 12 Apr 2007 14:04:22 +0000
Subject: RE: Guidelines Document Discussion
Date: Thu, 12 Apr 2007 10:02:11 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C77D0B.8B67F15F
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>[Avi] Given the IETF is a common denominator across SDOs, a way forward
>perhaps is to encourage SDOs to publish their dictionaries as
>INFORMATIONAL RFCs.  And perhaps to register their Dictionaries in IANA.

I agree that this would be a good thing.  If it were done, do you think that 
SDOs would be more willing to reuse attributes from other SDOs?

[Avi] At least they will know about them.  That would be a start. But there is still the control thing.

[Avi] Here is a question for you.  Do you think the IETF would use the VSAs defined by an SDO?  MS-MPPE... is such an example I guess.

------_=_NextPart_001_01C77D0B.8B67F15F
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59">
<TITLE>RE: Guidelines Document Discussion</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=2>&gt;[Avi] Given the IETF is a common denominator across SDOs, a way forward<BR>
&gt;perhaps is to encourage SDOs to publish their dictionaries as<BR>
&gt;INFORMATIONAL RFCs.&nbsp; And perhaps to register their Dictionaries in IANA.<BR>
<BR>
I agree that this would be a good thing.&nbsp; If it were done, do you think that<BR>
SDOs would be more willing to reuse attributes from other SDOs?<BR>
<BR>
[Avi] At least they will know about them.&nbsp; That would be a start. But there is still the control thing.<BR>
<BR>
[Avi] Here is a question for you.&nbsp; Do you think the IETF would use the VSAs defined by an SDO?&nbsp; MS-MPPE... is such an example I guess.<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C77D0B.8B67F15F--

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

Delivery-date: Thu, 12 Apr 2007 13:53:39 +0000
Date: Thu, 12 Apr 2007 15:52:07 +0200
From: Alan DeKok <[email-masked]>
To: radext mailing list <[email-masked]>
Subject: Proxies and retransmissions?

  I noticed recently that retransmissions by intermediate nodes wasn't
covered in the Issues & Fixes draft.  I'm not proposing that we add more
text to it, but the issue is one that's come up recently in SDO's.

  This topic was discussed earlier:

http://www1.tools.ietf.org/wg/radext/minutes?item=minutes58.html

...
- some implementations retransmitting at intermediate [proxy] nodes
          - recommendations:
                no retransmission from [proxy] intermediate nodes
                  (but track retransmission)
...

  I think it's best to say intermediate nodes SHOULD NOT retransmit of
their own accord.  They should do so only when they receive a retransmit
from the NAS.

  Is this an issue we need to address?  How do current implementations
deal with retransmits?

  Alan DeKok.

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

Delivery-date: Thu, 12 Apr 2007 08:02:40 +0000
Date: Thu, 12 Apr 2007 10:01:50 +0200
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  [email-masked]
Subject: Re: Guidelines Document Discussion

Avi Lior wrote:
>   i.e. SDO-One-DNS-Server && SDO-Two-DNS-Server are OK.
> [Avi] When I said name space I mean an implicit name-space.  I don't
> think that vendors and operators be required to call their attribute
> SDO-A-Foobar.  The vendor id creates a name-space and that is
> sufficient.

  I strongly disagree.  Vendors or SDOs who use non-qualified attribute
names have caused interoperability problems in the past, and will
continue to do so in the future.

>  The actual naming of the attribute is for human
> readability.

  And for policies.  If the policy says "Do X if DNS-Server is set to
1.2.3.4", what does that mean when two SDO's define the same name?

  SDO namespaces allow clear policies to be created.  Non-SDO namespaces
allow policies to be created that cannot be meaningfully interpreted.

> [Avi] it's a fact of life that two SDOs can and probably will define
> attribute that have the same name.  They are operating autonomously.

  Then the RADIUS guidelines document needs to say that the attribute
names should be prefixed with the SDO name, to obtain an SDO-specific
namespace.  They can then operate autonomously without the possibility
of conflict.

> When working in one SDO I am not checking the attributes of another SDOs
> or other vendors.  Its not practical.  I don't know about all the SDOs
> or all the vendors.  Lets get real here.

  Yes.  Which is why prefixes create independent name spaces, and do not
require coordination.  Allowing SDO's to create names *without* prefixes
has all of the problems you highlight, and all of the problems I
highlight.  Why not avoid both problems by using namespaces?

>   Attributes change their meaning?  That's bad practice.
> 
> [Avi] Meaning or semantics. Well that is just the way the cookie
> crumbles sometimes.  It is precisely dogma like that that make some SDOs
> nervous about sharing.

  That's an interesting approach.  SDO's change the meaning of
attributes so that existing implementations and deployments are
non-compliant with the new meanings.  Existing implementations and
deployments are also non-interoperable with new deployments that
understand the new meaning.  And it makes the SDO's nervous to have this
pointed out?

  Curious.  Or maybe I misunderstood exactly how the SDO's change the
meaning of attributes, while maintaining backwards compatibility and
interoperability.

  Alan DeKok.

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

Delivery-date: Thu, 12 Apr 2007 07:48:55 +0000
Date: Thu, 12 Apr 2007 09:47:49 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Proxy State and RFC 3576bis

Bernard Aboba wrote:
> One of the deployment blockers with RFC 3576 is the need to modify
> proxies to handle routing of RFC 3576 packets.  While proxies typically
> keep tables for dowstream forwarding, they typically do not keep tables
> for upstream forwarding.  Rather, they typically rely on the Proxy-State
> attribute to enable forwarding of an Access-Response back to the
> originating NAS.

  I've been working with sites recently to deploy RFC 3576 solutions.
We've found out that the simplest way to perform upstream forwarding is
to keep session state in DB's for all intermediate nodes.  i.e. We
ignore Proxy-State.

  When there is a failover relationship between two servers for
downstream forwarding, DBN replication is used to ensure that both share
the same information for upstream forwarding.

  That is, the packets may traverse different paths going downstream and
upstream.  However, since servers in a failover relationship are
"identical", they should behave identically for up/downstream forwarding.

> Given this, I am wondering how RADIUS proxies should handle Proxy-State
> for RFC 3576 packets:
> 
> a. Do they add Proxy-State attributes to a Disconnect/CoA-Request as
> suggested in the current text (and as would be done for an Access-Request)?

  No.

> b. Or can the RADIUS server include a Proxy-State attribute previously
> obtained from an Access-Request used in the original authentication
> within the Disconnect/CoA-Request to assist the proxy in routing the
> request back to the NAS?  In this case, wouldn't the RADIUS proxy
> *remove* Proxy-State attributes from the Disconnect/CoA-Request??

  Yes.

  However, Proxy-State is almost entirely useless.  For downstream
forwarding, we can't key off of the Proxy-State in replies to find the
corresponding request, because some implementations historically mangled
 Proxy-State, in defiance of the RFC requirements.  Therefore, it's best
for the server to keep internal tables for downstream forwarding, and
use those tables to match replies to requests.

  Proxy-State is added for RFC compliance, but is otherwise ignored.
The contents are never examined to match replies to requests.

  For RFC 3576 behavior, once sessions are kept in a DB, Proxy-State is
also useless.  Since Proxy-State isn't signed or authenticated, and
since it can be mangled by intermediate nodes, it can't be used by an
intermediate node as the basis for any decision.

  If we ignore deployment issues, a solution to the upstream routing
problem would be add a new attribute.  This attribute would be added on
downstream proxying by intermediate nodes, just like Proxy-State.  But
it would be signed and authenticated at each hop.  Its contents would be
sufficient information for the upstream path to make a forwarding
decision, independent of any other data.  Intermediate nodes therefore
become stateless, and servers in a failover relationship do not have to
contact each other to maintain information about upstream paths for
sessions.

  This means that all of the proxying servers would have to support this
attribute, and that the final home server would have to store N copies
of the attribute per session, one for each intermediate hop.  It would
also allow intermediate nodes to catch routing loops, as they could
potentially examine all copies of the new attribute for "their" copy.

  Since all proxies have to be updated from base RFC 2865 functionality
to support RFC 3576 upstream routing, this proposal might just work.

  Alan DeKok.

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

Envelope-to: [email-masked]
Delivery-date: Thu, 12 Apr 2007 00:39:34 +0000
Date: Wed, 11 Apr 2007 17:39:18 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject:  RFC 4818 on RADIUS Delegated-IPv6-Prefix Attribute
From: [email-masked]
Cc: [email-masked], [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 4818

        Title:      RADIUS Delegated-IPv6-Prefix Attribute 
        Author:     J. Salowey, R. Droms
        Status:     Standards Track
        Date:       April 2007
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      7
        Characters: 12993
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-radext-delegated-prefix-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4818.txt

This document defines a RADIUS (Remote Authentication Dial In User
Service) attribute that carries an IPv6 prefix that is to be
delegated to the user.  This attribute is usable within either RADIUS
or Diameter.  [STANDARDS TRACK]

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

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

Delivery-date: Thu, 12 Apr 2007 00:38:55 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Proxy State and RFC 3576bis
Date: Wed, 11 Apr 2007 17:38:40 -0700

One of the deployment blockers with RFC 3576 is the need to modify proxies 
to handle routing of RFC 3576 packets.  While proxies typically keep tables 
for dowstream forwarding, they typically do not keep tables for upstream 
forwarding.  Rather, they typically rely on the Proxy-State attribute to 
enable forwarding of an Access-Response back to the originating NAS.

Given this, I am wondering how RADIUS proxies should handle Proxy-State for 
RFC 3576 packets:

a. Do they add Proxy-State attributes to a Disconnect/CoA-Request as 
suggested in the current text (and as would be done for an Access-Request)?

b. Or can the RADIUS server include a Proxy-State attribute previously 
obtained from an Access-Request used in the original authentication within 
the Disconnect/CoA-Request to assist the proxy in routing the request back 
to the NAS?  In this case, wouldn't the RADIUS proxy *remove* Proxy-State 
attributes from the Disconnect/CoA-Request??

FYI, here is the current text on Proxy-State in -04:

      If there are any Proxy-State Attributes in a Disconnect-Request or
      CoA-Request received from the server, the forwarding proxy or NAS
      MUST include those Proxy-State Attributes in its response to the
      server.

      A forwarding proxy or NAS MUST NOT modify existing Proxy-State,
      State, or Class Attributes present in the packet.  The forwarding
      proxy or NAS MUST treat any Proxy-State attributes already in the
      packet as opaque data.  Its operation MUST NOT depend on the
      content of Proxy-State attributes added by previous proxies.  The
      forwarding proxy MUST NOT modify any other Proxy-State Attributes
      that were in the packet; it may choose not to forward them, but it
      MUST NOT change their contents.  If the forwarding proxy omits the
      Proxy-State Attributes in the request, it MUST attach them to the
      response before sending it.

      When the proxy forwards a Disconnect or CoA-Request, it MAY add a
      Proxy-State Attribute, but it MUST NOT add more than one.  If a
      Proxy-State Attribute is added to a packet when forwarding the
      packet, the Proxy-State Attribute MUST be added after any existing
      Proxy-State attributes.  The forwarding proxy MUST NOT change the
      order of any attributes of the same type, including Proxy-State.
      Other Attributes can be placed before, after or even between the
      Proxy-State Attributes.

      When the proxy receives a response to a CoA-Request or Disconnect-
      Request, it MUST remove its own Proxy-State (the last Proxy- State
      in the packet) before forwarding the response.  Since Disconnect
      and CoA responses are authenticated on the entire packet contents,
      the stripping of the Proxy-State Attribute invalidates the
      integrity check - so the proxy needs to recompute it.

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

Delivery-date: Thu, 12 Apr 2007 00:26:40 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Guidelines Document Discussion
Date: Wed, 11 Apr 2007 17:25:46 -0700

>[Avi] Given the IETF is a common denominator across SDOs, a way forward
>perhaps is to encourage SDOs to publish their dictionaries as
>INFORMATIONAL RFCs.  And perhaps to register their Dictionaries in IANA.

I agree that this would be a good thing.  If it were done, do you think that 
SDOs would be more willing to reuse attributes from other SDOs?

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

Delivery-date: Wed, 11 Apr 2007 19:51:11 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-rfc3576bis-04.txt 
Date: Wed, 11 Apr 2007 15:50:02 -0400

--NextPart

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

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

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

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

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

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

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

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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

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

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

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

--OtherAccess--

--NextPart--

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

Delivery-date: Wed, 11 Apr 2007 16:30:45 +0000
Subject: RE: Guidelines Document Discussion
Date: Wed, 11 Apr 2007 12:31:05 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Alan see inline, 

Avi Lior wrote:
> [Avi] The name space for a VSA is defined -- it the SDOs (or vendors 
> namespace).  I don't know what else you would do.
...
> [Avi] The reality is that one SDO may define DNS-Server because it 
> does not know that another attribute by that name is already defined.

> There is no global repository for looking up what other SDO have done.

  Which appears to contract your previous statement.

  i.e. SDO-One-DNS-Server && SDO-Two-DNS-Server are OK.
[Avi] When I said name space I mean an implicit name-space.  I don't
think that vendors and operators be required to call their attribute
SDO-A-Foobar.  The vendor id creates a name-space and that is
sufficient.  The actual naming of the attribute is for human
readability.  Having said that, it would be nice if a vendor did want
their attribute to be widely used that they did somehow decorated the
name with the vendor designation as Microsoft did (I assume that the MSS
of the MSS-MPPE... Attribute is for Microsoft). 

  Both SDO's defining "DNS-Server" without qualification is not OK.

[Avi] it's a fact of life that two SDOs can and probably will define
attribute that have the same name.  They are operating autonomously.
When working in one SDO I am not checking the attributes of another SDOs
or other vendors.  Its not practical.  I don't know about all the SDOs
or all the vendors.  Lets get real here.

[Avi] As to the qualification part, I am sure when an SDO defines
DNS-Server they do provide both the definition for the attribute and the
semantics for its use.

> [Avi] There is apprehension and that relates to change control.  If I 
> use an attribute x from VendorA, then I need assurances that if that 
> attribute is going to change or that I would be consulted or be 
> notified when such a change occurs.

  Attributes change their meaning?  That's bad practice.

[Avi] Meaning or semantics. Well that is just the way the cookie
crumbles sometimes.  It is precisely dogma like that that make some SDOs
nervous about sharing.

> [Avi] Given the IETF is a common denominator across SDOs, a way 
> forward perhaps is to encourage SDOs to publish their dictionaries as 
> INFORMATIONAL RFCs.  And perhaps to register their Dictionaries in
IANA.

  I agree.

  Alan DeKok.

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

Delivery-date: Wed, 11 Apr 2007 16:14:15 +0000
Date: Wed, 11 Apr 2007 18:13:09 +0200
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  [email-masked]
Subject: Re: Guidelines Document Discussion

Avi Lior wrote:
> [Avi] The name space for a VSA is defined -- it the SDOs (or vendors
> namespace).  I don't know what else you would do.
...
> [Avi] The reality is that one SDO may define DNS-Server because it does
> not know that another attribute by that name is already defined.  There
> is no global repository for looking up what other SDO have done.

  Which appears to contract your previous statement.

  i.e. SDO-One-DNS-Server && SDO-Two-DNS-Server are OK.

  Both SDO's defining "DNS-Server" without qualification is not OK.

> [Avi] There is apprehension and that relates to change control.  If I
> use an attribute x from VendorA, then I need assurances that if that
> attribute is going to change or that I would be consulted or be notified
> when such a change occurs.

  Attributes change their meaning?  That's bad practice.

> [Avi] Given the IETF is a common denominator across SDOs, a way forward
> perhaps is to encourage SDOs to publish their dictionaries as
> INFORMATIONAL RFCs.  And perhaps to register their Dictionaries in IANA.

  I agree.

  Alan DeKok.

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

Delivery-date: Wed, 11 Apr 2007 16:02:20 +0000
Subject: RE: Guidelines Document Discussion
Date: Wed, 11 Apr 2007 12:02:47 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi,

Please see inline.... 

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Wednesday, April 11, 2007 11:39 AM
To: [email-masked]; Avi Lior
Cc: [email-masked]
Subject: Re: Guidelines Document Discussion

>   If the name space is SDO-specific.  "SDO-Attribute-Foo".  I don't 
>see why the IETF would not honor such name spaces.

[Avi] The name space for a VSA is defined -- it the SDOs (or vendors
namespace).  I don't know what else you would do.
>
>   Having SDOs define attributes *without* a specific name-space leads 
>to problems.  Common terms are... common.  Is "DNS-Server" a good 
>attribute name for multiple SDO's to define?  Probably not.

This makes sense to me; it probably should be part of design guidelines.

[Avi] The reality is that one SDO may define DNS-Server because it does
not know that another attribute by that name is already defined.  There
is no global repository for looking up what other SDO have done.

>Interoperability where we don't have to write or maintain a RADIUS 
>server implementation for every SDO.  VSA's and name spaces are useful 
>here, because they mean that one RADIUS server deployment can 
>interoperate with multiple SDO's simultaneously.

Right.  That is a good goal, I think.  There is no good reason why one
SDO shouldn't be able to reuse VSAs from another SDO, 

[Avi] There is apprehension and that relates to change control.  If I
use an attribute x from VendorA, then I need assurances that if that
attribute is going to change or that I would be consulted or be notified
when such a change occurs.

[Avi] A great example of a widely used VSA is the Microsoft
MS-MPPE-SEND-KEY etc. because it was published as an RFC.  How many
other SDOs publish their attributes as RFCs. 
 
or why configuring a RADIUS server to send a VSA should be any  more
complex than configuring the same server to send an attribute from the
Standards space.  We need to make it easier to incorporate VSAs into
standard RADIUS implementations.

[Avi] Given the IETF is a common denominator across SDOs, a way forward
perhaps is to encourage SDOs to publish their dictionaries as
INFORMATIONAL RFCs.  And perhaps to register their Dictionaries in IANA.

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

Delivery-date: Wed, 11 Apr 2007 15:44:13 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: Guidelines Document Discussion
Date: Wed, 11 Apr 2007 08:43:54 -0700

> > Right.  Assuming that the SDOs utilize similar attribute formats, and
> > the specifications are published, this should work.  In particular, I
> > would like to eliminate the need for SDOs to utilize RADIUS standard
> > attributes just in order to have their specification widely
> > disseminated.  In the long term the IETF should strive to assist SDOs in
> > defining their own RADIUS attributes.
>
>   That is a very good idea.  It would enhance interoperability, and
>reduce problems.

There is no inherent reason why SDO-defined RADIUS attributes are any less 
"legitimate" than ones defined by the IETF.  I am puzzled by documents such 
as the RADIUS MIPv4 specification, which claim that the solution to 
interoperability issues between SDO-defined VSAs is to define attributes in 
the IETF standards space.  You cannot solve an interoperability problem by 
creating *yet another* way to do something, particularly if the new way has 
to be significantly different from the existing VSA attributes, due to 
differences in the data models.

In such a case, it seems better to me to start from a single deployed set of 
VSA attributes, enhancing them with additional VSAs or standards space 
attributes as necessary.

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

Delivery-date: Wed, 11 Apr 2007 15:39:40 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Guidelines Document Discussion
Date: Wed, 11 Apr 2007 08:38:48 -0700

>   If the name space is SDO-specific.  "SDO-Attribute-Foo".  I don't see
>why the IETF would not honor such name spaces.
>
>   Having SDOs define attributes *without* a specific name-space leads to
>problems.  Common terms are... common.  Is "DNS-Server" a good attribute
>name for multiple SDO's to define?  Probably not.

This makes sense to me; it probably should be part of design guidelines.

>Interoperability where we don't have to write or maintain a RADIUS
>server implementation for every SDO.  VSA's and name spaces are useful
>here, because they mean that one RADIUS server deployment can
>interoperate with multiple SDO's simultaneously.

Right.  That is a good goal, I think.  There is no good reason why one SDO 
shouldn't be able to reuse VSAs from another SDO, or why configuring a 
RADIUS server to send a VSA should be any  more complex than configuring the 
same server to send an attribute from the Standards space.  We need to make 
it easier to incorporate VSAs into standard RADIUS implementations.

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

Delivery-date: Wed, 11 Apr 2007 13:26:48 +0000
Date: Wed, 11 Apr 2007 15:25:55 +0200
From: Alan DeKok <[email-masked]>
To: Avi Lior <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  [email-masked]
Subject: Re: Guidelines Document Discussion

Avi Lior wrote:
> I don't think we could standerdize a VSA encoding.   But at least we can
> make a recommendation on how an VSA could be encoded.  I would offer the
> WiMAX encoding as a good example. It aligns with the RADIUS attribute
> extension encoding at least in the header. And for the payload it allows
> a structured types -- like 3GPP2.

  Sounds good to me.

>  - 1 or 2 byte VSA's for "efficiency" where "integer" type would do
> [Avi]You mean prohibit the use of 1 or 2 byte TLVs where an integer
> would do?  If yes I disagree.  RADIUS packets are getting smaller and
> smaller these days?  If I have an enumeration (of TRUE or FALSE) using a
> 32-bit value is wasteful in view of the size limitation of both
> attributes and packet size.

  I don't see it as necessary.  I won't object if other people think
it's necessary, though.

>  - SDO-specific interpretations of existing RADIUS commands, attributes,
>    or values for "integer" attributes.
> [Avi] Not sure I understand the "...values for integer" part.

  e.g. 'Service-Type = Foo'  doesn't mean "Foo", it means something else.

  Not that Service-Type is the problem... the problem is people saying
"Foo doesn't really apply, but it's the closest of the existing
standards to what we want, so we'll just use it."

>  - SDO's publishing standards that use existing standardized attribute
>    names for SDO-specific attributes, or which use confusingly similar
>    names
> 
> [Avi] A good idea for readability. But not a show stopper.  Is the IETF
> willing to also honor SDOs name spaces? Probably not.

  If the name space is SDO-specific.  "SDO-Attribute-Foo".  I don't see
why the IETF would not honor such name spaces.

  Having SDOs define attributes *without* a specific name-space leads to
problems.  Common terms are... common.  Is "DNS-Server" a good attribute
name for multiple SDO's to define?  Probably not.

>   SDO's and vendors should be reminded that the goal of VSA's is to
> obtain interoperability.
> 
> [Avi] interoperability within the SDO or with others?  I think within
> the SDO primarily.  To achieve interoperability between SDOs, and SDO is
> free to use another SDOs attributes.  It would be helpful for us RADIUS
> vendors if the encoding was the same though.

  Interoperability where we don't have to write or maintain a RADIUS
server implementation for every SDO.  VSA's and name spaces are useful
here, because they mean that one RADIUS server deployment can
interoperate with multiple SDO's simultaneously.

  Alan DeKok.

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

Delivery-date: Wed, 11 Apr 2007 13:16:01 +0000
Date: Wed, 11 Apr 2007 15:15:16 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: Guidelines Document Discussion

Bernard Aboba wrote:
> Avi wrote:
>> If I have an enumeration (of TRUE or FALSE) using a
>> 32-bit value is wasteful in view of the size limitation of both
>> attributes and packet size.
> 
> Are you saying that the VSA space should allow one octet or two octet
> data types?

  I don't see why.  While it may be useful, a quick perusal of the
dictionaries shows few existing definitions of one or two-byte data types.

> We could certainly recommend the use of unique name spaces for VSAs
> (e.g. SDO-Name) so as to avoid confusion.

  By all means, yes.  Since only attribute spaces were deemed to be
vendor-specific, vendors have used non-unique name spaces for VSA's,
making inter-operation with multiple vendors more difficult.

>> [Avi] interoperability within the SDO or with others?  I think within
>> the SDO primarily.  To achieve interoperability between SDOs, and SDO is
>> free to use another SDOs attributes.  It would be helpful for us RADIUS
>> vendors if the encoding was the same though.
> 
> Right.  Assuming that the SDOs utilize similar attribute formats, and
> the specifications are published, this should work.  In particular, I
> would like to eliminate the need for SDOs to utilize RADIUS standard
> attributes just in order to have their specification widely
> disseminated.  In the long term the IETF should strive to assist SDOs in
> defining their own RADIUS attributes.

  That is a very good idea.  It would enhance interoperability, and
reduce problems.

  Alan DeKok.

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

Delivery-date: Wed, 11 Apr 2007 13:11:59 +0000
Date: Wed, 11 Apr 2007 15:10:27 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Request for RADIUS crypto-agility solutions

Bernard Aboba wrote:
> This is a formal request for submission of documents solving the RADIUS
> crypto-agility problem.  Proposers should send an email to the RADEXT WG
> list providing a pointer to their proposal by April 21, 2007.   Once the
> proposals have been submitted, we will initiate WG review.

  I propose RADIUS + DTLS, as presented at IETF 68:

http://tools.ietf.org/id/draft-dekok-radext-dtls-00.txt

  Alan DeKok.

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

Delivery-date: Tue, 10 Apr 2007 21:16:21 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Issue 130: Diameter Compatibility (traffic-rule-draft)
Date: Tue, 10 Apr 2007 14:16:08 -0700

>Propose resolution to be the current Diameter Considerations section in
>draft -02. This uses the same approach as RFC4675.

Looks good.

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

Delivery-date: Tue, 10 Apr 2007 21:15:29 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Issue 111: Accounting (traffic-rule-draft)
Date: Tue, 10 Apr 2007 14:14:39 -0700

>In light that the treatment of accounting behavior would be best treated
>elsewhere, such as in 3576bis, I would suggest that we omit any discussion
>of accounting behavior in this draft.  This means that sections 1.4 would 
>be
>modified and section A.3 would be eliminated to remove accounting
>references.
>
>Does this seem like a reasonable path?

Yes.

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

Delivery-date: Tue, 10 Apr 2007 19:54:06 +0000
Date: Tue, 10 Apr 2007 23:46:32 +0400
From: Victor Gamov <[email-masked]>
To: [email-masked]
Subject: Re: new Service-Type

OK, let me explain my point of view.

As this I-D propose new Service-Type values it's means that IETF 
Consensus required. It's a real fact.

As to the question about only one implementation using this values so I 
propose this attributes because I really hope that it may be useful in 
environment where video services (like video-call or video-on-demand) 
are deployed.

As recommended by http://www.ietf.org/ietf/1id-guidelines.html, chair of 
the WG must grant permissions to IETF to publish I-D. But I think that
the utility of this new values need to be discussed by RADext WG 
firstly.  If this values will be found helpful -- WG can recommend it 
for using in suitable situations and publish this I-D to get IETF 
Consensus.  If not -- WG can discard it.

If its needed to have more examples where this values may be used I will 
try to give it.

-- 
CU,
Victor Gamov

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

Delivery-date: Tue, 10 Apr 2007 19:50:44 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-fixes-03.txt 
Date: Tue, 10 Apr 2007 15:50:02 -0400

--NextPart

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

	Title		: Common RADIUS Implementation Issues and Suggested Fixes
	Author(s)	: D. Nelson, A. DeKok
	Filename	: draft-ietf-radext-fixes-03.txt
	Pages		: 23
	Date		: 2007-4-10
	
This document describes common issues seen in RADIUS implementations
   and suggests some fixes.  Where applicable, ambiguities and errors in
   previous RADIUS specifications are clarified.

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

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

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

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

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

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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

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

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

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

--OtherAccess--

--NextPart--

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

Delivery-date: Tue, 10 Apr 2007 14:57:16 +0000
Date: Tue, 10 Apr 2007 14:56:52 +0000 (UTC)
From: "[email-masked]" <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To:  <[email-masked]>
Subject: RE: RFC 2882 and new Service-Type

Let be re-iterate some of Dave's comments....

The purpose of RFC 2882 was to indicate the nature and scope of 
"extentions" to RADIUS that were seen in practice.  I have often called 
it by a name that is not part of IETF nomenclature, a "Worst Practices" 
document.

The goal of the document was to bring some of these issues to light, 
so that hopefully they would be addressed by the AAA movement at the 
time.  The politics of the situation at the time didn't seem to think 
there was much to be done in the area.   I was trying to illustrate the 
reality of the situation.  One prominent vendor objected vocally to his 
products being described there.

Also note that it preceeds RFC 3575, and some of the sections quoted 
below have probably been tweaked in response to it.

That said, being the author of the VSE concept, I still think it has 
merit.  But it does suffer the arguments given here and later in this 
thread.  If it were baked into the protocol somehow, then it would 
benefit from the standard.   

As an ad-hoc extention, VSEs can and will cause interoperability 
problems.   I ran into at least one RADIUS server that couldn't handle 
them at all because they exceeded the bit width of the variable they 
had carefully optimized to carry the known values.    While this is an 
example of a short sighted implementation, I think a standard should be 
very clear on what and where values can be extended.  And since the WG 
has not accepted the VSE scheme, I would not recommend it's use in a 
product today.

David Mitton.

----Original Message----
From: [email-masked]
Date: Apr 10, 2007 7:19 
To: "Alan DeKok"<[email-masked]>, "Victor Gamov"<[email-masked]>
Cc: <[email-masked]>
Subj: RE: new Service-Type

Alan DeKok writes ...

>   IANA performs the allocations itself.  You can request 
> that IANA allocate numbers for those Service-Type values.  
> But you cannot control which numbers IANA allocates.

IANA allocations for RADIUS are controlled by RFC 3575, which reads, 
in
part, as follows:

   Certain attributes (for example, NAS-Port-Type) in RADIUS define a
   list of values to correspond with various meanings.  There can be 4
   billion (2^32) values for each attribute.  Additional values can be
   allocated by the Designated Expert.  The exception to this policy 
is
   the Service-Type attribute (6), whose values define new modes of
   operation for RADIUS.  Values 1-16 of the Service-Type attribute 
have
   been allocated.  Allocation of new Service-Type values are by IETF
   Consensus.  The intention is that any allocation will be 
accompanied
   by a published RFC.

Allocation of new Service-Type values requires IETF Consensus.

>   If there is only one application that uses these two 
> Service-Types, my suggestion would be to allocate a vendor-
> specific enumeration.  See RFC 2882, Section 2.2.1 for how this
> is done.
> 
>   The benefit with the method suggested in RFC 2882 is that
> you do not need IANA approval for the allocation.

I personally consider vendor-specific enumerations, as described in 
RFC 2882
to be a very bad practice.  Please recall that RFC 2882 describes 
RADIUS
practices encountered in implementations, but does not necessisarily
recommend these practices.  Various versions of the RADIUS Design 
Guidelines
draft have included text recommending against using VSEs, in favor of
standard IANA allocations.

RFC 2882 says, in part:

   This technique has not seen any acceptance by the
   working group or other vendors, however, the vendor did accomplish
   the goal of not conflicting with working group additions or other
   vendor values.

In my opinion, which is based in part on discussions with the author 
of RFC
2882, that document lists certain practices which ought not to be
encouraged, in the interests of interoperability, but rather which 
vendors
have resorted to in order to bypass the normal IETF processes.

In any event, new values of Service-Type, VSE or otherwise, do require 
IANA
allocation and do require IETF consensus.

Regards,

Dave Nelson
--

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

Delivery-date: Tue, 10 Apr 2007 14:46:47 +0000
Date: Tue, 10 Apr 2007 14:46:05 +0000 (UTC)
From: "[email-masked]" <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: [email-masked]
Subject: RE: RFC 2882 and new Service-Type

Let be re-iterate some of Dave's comments....

The purpose of RFC 2882 was to indicate the nature and scope of 
"extentions" to RADIUS that were seen in practice.  I have often called 
it by a name that is not part of IETF nomenclature, a "Worst Practices" 
document.

The goal of the document was to bring some of these issues to light, 
so that hopefully they would be addressed by the AAA movement at the 
time.  The politics of the situation at the time didn't seem to think 
there was much to be done in the area.   I was trying to illustrate the 
reality of the situation.  One prominent vendor objected vocally to his 
products being described there.

Also note that it preceeds RFC 3575, and some of the sections quoted 
below have probably been tweaked in response to it.

That said, being the author of the VSE concept, I still think it has 
merit.  But it does suffer the arguments given here and later in this 
thread.  If it were baked into the protocol somehow, then it would 
benefit from the standard.   

As an ad-hoc extention, VSEs can and will cause interoperability 
problems.   I ran into at least one RADIUS server that couldn't handle 
them at all because they exceeded the bit width of the variable they 
had carefully optimized to carry the known values.    While this is an 
example of a short sighted implementation, I think a standard should be 
very clear on what and where values can be extended.  And since the WG 
has not accepted the VSE scheme, I would not recommend it's use in a 
product today.

David Mitton.

----Original Message----
From: [email-masked]
Date: Apr 10, 2007 7:19 
To: "Alan DeKok"<[email-masked]>, "Victor Gamov"<[email-masked]>
Cc: <[email-masked]>
Subj: RE: new Service-Type

Alan DeKok writes ...

>   IANA performs the allocations itself.  You can request 
> that IANA allocate numbers for those Service-Type values.  
> But you cannot control which numbers IANA allocates.

IANA allocations for RADIUS are controlled by RFC 3575, which reads, 
in
part, as follows:

   Certain attributes (for example, NAS-Port-Type) in RADIUS define a
   list of values to correspond with various meanings.  There can be 4
   billion (2^32) values for each attribute.  Additional values can be
   allocated by the Designated Expert.  The exception to this policy 
is
   the Service-Type attribute (6), whose values define new modes of
   operation for RADIUS.  Values 1-16 of the Service-Type attribute 
have
   been allocated.  Allocation of new Service-Type values are by IETF
   Consensus.  The intention is that any allocation will be 
accompanied
   by a published RFC.

Allocation of new Service-Type values requires IETF Consensus.

>   If there is only one application that uses these two 
> Service-Types, my suggestion would be to allocate a vendor-
> specific enumeration.  See RFC 2882, Section 2.2.1 for how this
> is done.
> 
>   The benefit with the method suggested in RFC 2882 is that
> you do not need IANA approval for the allocation.

I personally consider vendor-specific enumerations, as described in 
RFC 2882
to be a very bad practice.  Please recall that RFC 2882 describes 
RADIUS
practices encountered in implementations, but does not necessisarily
recommend these practices.  Various versions of the RADIUS Design 
Guidelines
draft have included text recommending against using VSEs, in favor of
standard IANA allocations.

RFC 2882 says, in part:

   This technique has not seen any acceptance by the
   working group or other vendors, however, the vendor did accomplish
   the goal of not conflicting with working group additions or other
   vendor values.

In my opinion, which is based in part on discussions with the author 
of RFC
2882, that document lists certain practices which ought not to be
encouraged, in the interests of interoperability, but rather which 
vendors
have resorted to in order to bypass the normal IETF processes.

In any event, new values of Service-Type, VSE or otherwise, do require 
IANA
allocation and do require IETF consensus.

Regards,

Dave Nelson
--

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

Delivery-date: Tue, 10 Apr 2007 13:25:35 +0000
Date: Tue, 10 Apr 2007 15:24:00 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: 'Victor Gamov' <[email-masked]>,  [email-masked]
Subject: Re: new Service-Type

David B. Nelson wrote:
> One of the properties of a standard protocol is that the code-points are
> controlled and universally understood.  If you want to have a private
> version of the foo-bar protocol, then it doesn't matter what code-points you
> use in your implementation, as they will not be encountered by
> standards-compliant implementations.  In that case, however, you need not
> engage the IETF at all.  The reason for standards is for plug-'n-play
> interoperability.

  No argument there.

>>   The alternative is to perform allocations for every little 
>> variation of every little application, which will not scale.
> 
> That depends, I suppose, on whether you think of RADIUS as a standardized,
> interoperable protocol or simply a convenient a transport for proprietary,
> boutique applications.

  Realistically, all protocols are used in both scenarios.  In some
cases, it's simpler, cheaper, and easier to deploy localized
non-standard and non-interoperable solutions... especially where those
solutions are intended to never inter-operate with other deployments.

  The question for this document is whether or not it falls into the
first set, or the second.

  If there is only one application that needs these values, I see no
point in standardizing them.  If there is only one implementation, it
is, by definition, non-interopable with anything else,

  Non-interoperable implementations have no requirements for
inter-operability.  The vendor can use VSE's, or poach on the IANA
space.  It's up to him.  And since his implementation is already
non-interoperable, it won't affect anyone else.

  And doesn't the IETF process generally require two inter-operable
implementations?  If there is no second implementation that will support
this functionality, why can we not push off the discussion until there
is an inter-operable RADIUS client?

  Alan DeKok.

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

Delivery-date: Tue, 10 Apr 2007 12:18:19 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'Victor Gamov'" <[email-masked]>, <[email-masked]>
Subject: RE: new Service-Type
Date: Tue, 10 Apr 2007 08:16:13 -0400

Alan DeKok writes...
 
>   If there is not a strong demand for RADIUS allocations, 
> then the deployments using the new numbers are few and far 
> between.  In that case, it matters little to the rest of the
> world which numbers are used.

One of the properties of a standard protocol is that the code-points are
controlled and universally understood.  If you want to have a private
version of the foo-bar protocol, then it doesn't matter what code-points you
use in your implementation, as they will not be encountered by
standards-compliant implementations.  In that case, however, you need not
engage the IETF at all.  The reason for standards is for plug-'n-play
interoperability.

If there is a chance that your "walled garden" will ever open up and
interact with the rest of the world, however, non-assigned code-points are a
very bad practice, indeed.

The fact that VSEs poach on high-valued regions of the code-point space,
that IANA is never likely to reach, does make them "work".  It does nothing
to promote interoperability, however.

>    In that case, I would recommend VSE's.

I, on the other hand, would never recommend VSEs.  In my opinion VSEs for
Service-Type violate the RADIUS IANA Considerations RFC.  

>   The alternative is to perform allocations for every little 
> variation of every little application, which will not scale.

That depends, I suppose, on whether you think of RADIUS as a standardized,
interoperable protocol or simply a convenient a transport for proprietary,
boutique applications.

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

Delivery-date: Tue, 10 Apr 2007 11:53:24 +0000
Date: Tue, 10 Apr 2007 13:52:46 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: PROTO writeup for Issues & Fixes

Bernard Aboba wrote:
> Find enclosed the proposed PROTO writeup for Issues & Fixes, which will
> submitted for IESG review once -03 hits the archive.  Comment welcome.

  I have just submitted -03.

> The document splits normative and informative references.
> There are no normative references to IDs.

  There is a normative reference to [PREFIX].  tools.ietf.org says it's
in state AUTH48.  There appear to be about 8-10 requests before it in
the RFC editors queue.

  Alan DeKok.

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

Delivery-date: Tue, 10 Apr 2007 11:46:23 +0000
Date: Tue, 10 Apr 2007 13:45:12 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: 'Victor Gamov' <[email-masked]>,  [email-masked]
Subject: Re: new Service-Type

David B. Nelson wrote:
> IANA allocations for RADIUS are controlled by RFC 3575, which reads, in
> part, as follows:
...
> Allocation of new Service-Type values requires IETF Consensus.

  Hmm... OK.

> I personally consider vendor-specific enumerations, as described in RFC 2882
> to be a very bad practice.  Please recall that RFC 2882 describes RADIUS
> practices encountered in implementations, but does not necessisarily
> recommend these practices.  Various versions of the RADIUS Design Guidelines
> draft have included text recommending against using VSEs, in favor of
> standard IANA allocations.

  I understand.  However, VSE's are known to work.

> In my opinion, which is based in part on discussions with the author of RFC
> 2882, that document lists certain practices which ought not to be
> encouraged, in the interests of interoperability, but rather which vendors
> have resorted to in order to bypass the normal IETF processes.
> 
> In any event, new values of Service-Type, VSE or otherwise, do require IANA
> allocation and do require IETF consensus.

  If there is a strong demand for RADIUS allocations, then I agree that
the allocations should be made, and documented.

  If there is not a strong demand for RADIUS allocations, then the
deployments using the new numbers are few and far between.  In that
case, it matters little to the rest of the world which numbers are used.
   In that case, I would recommend VSE's.

  The alternative is to perform allocations for every little variation
of every little application, which will not scale.

  So... is there a strong demand for the allocations requested by the
original document?

  Alan DeKok.

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

Delivery-date: Tue, 10 Apr 2007 11:21:41 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, "'Victor Gamov'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: new Service-Type
Date: Tue, 10 Apr 2007 07:19:21 -0400

Alan DeKok writes ...

>   IANA performs the allocations itself.  You can request 
> that IANA allocate numbers for those Service-Type values.  
> But you cannot control which numbers IANA allocates.

IANA allocations for RADIUS are controlled by RFC 3575, which reads, in
part, as follows:

   Certain attributes (for example, NAS-Port-Type) in RADIUS define a
   list of values to correspond with various meanings.  There can be 4
   billion (2^32) values for each attribute.  Additional values can be
   allocated by the Designated Expert.  The exception to this policy is
   the Service-Type attribute (6), whose values define new modes of
   operation for RADIUS.  Values 1-16 of the Service-Type attribute have
   been allocated.  Allocation of new Service-Type values are by IETF
   Consensus.  The intention is that any allocation will be accompanied
   by a published RFC.

Allocation of new Service-Type values requires IETF Consensus.

>   If there is only one application that uses these two 
> Service-Types, my suggestion would be to allocate a vendor-
> specific enumeration.  See RFC 2882, Section 2.2.1 for how this
> is done.
> 
>   The benefit with the method suggested in RFC 2882 is that
> you do not need IANA approval for the allocation.

I personally consider vendor-specific enumerations, as described in RFC 2882
to be a very bad practice.  Please recall that RFC 2882 describes RADIUS
practices encountered in implementations, but does not necessisarily
recommend these practices.  Various versions of the RADIUS Design Guidelines
draft have included text recommending against using VSEs, in favor of
standard IANA allocations.

RFC 2882 says, in part:

   This technique has not seen any acceptance by the
   working group or other vendors, however, the vendor did accomplish
   the goal of not conflicting with working group additions or other
   vendor values.

In my opinion, which is based in part on discussions with the author of RFC
2882, that document lists certain practices which ought not to be
encouraged, in the interests of interoperability, but rather which vendors
have resorted to in order to bypass the normal IETF processes.

In any event, new values of Service-Type, VSE or otherwise, do require IANA
allocation and do require IETF consensus.

Regards,

Dave Nelson

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

Delivery-date: Tue, 10 Apr 2007 10:27:01 +0000
Date: Tue, 10 Apr 2007 12:25:57 +0200
From: Alan DeKok <[email-masked]>
To: Victor Gamov <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  [email-masked]
Subject: Re: new Service-Type

Victor Gamov wrote:
> Some times ago I ask about propose new Service-Type values to carry
> information about video services.  Now I have I-D which propose such
> values. This document placed at
> http://so.comsat.ru/IST/draft-vit-radext-videoservicetype-00.txt
> 
> Please tell me what else must I do to approve this values by IANA?

  IANA performs the allocations itself.  You can request that IANA
allocate numbers for those Service-Type values.  But you cannot control
which numbers IANA allocates.

  If there is only one application that uses these two Service-Types, my
suggestion would be to allocate a vendor-specific enumeration.  See RFC
2882, Section 2.2.1 for how this is done.

  The benefit with the method suggested in RFC 2882 is that you do not
need IANA approval for the allocation.

  Alan DeKok.

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

Delivery-date: Tue, 10 Apr 2007 08:25:06 +0000
Date: Tue, 10 Apr 2007 12:23:42 +0400
From: Victor Gamov <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: new Service-Type

Hi Bernard!

Some times ago I ask about propose new Service-Type values to carry 
information about video services.  Now I have I-D which propose such
values. This document placed at
http://so.comsat.ru/IST/draft-vit-radext-videoservicetype-00.txt

Please tell me what else must I do to approve this values by IANA?

Thanks!

-- 
CU,
Victor Gamov

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

Delivery-date: Mon, 09 Apr 2007 19:07:19 +0000
Subject: RE: Guidelines Document Discussion
Date: Mon, 9 Apr 2007 15:06:56 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Monday, April 09, 2007 2:55 PM
To: Avi Lior; [email-masked]
Cc: [email-masked]
Subject: RE: Guidelines Document Discussion

>[Avi] Ideally it will help if we did suggest an encoding for VSAs. SDO 
>will always need to create their own VSAs.  We are starting to see 
>convergences in the Wireless/Wireline networks and it would be nice if 
>SDOs attributes would interoperate or at least it should be easy to 
>translate between SDOs.

This seems like it might be an achievable goal.  The RFC 2865
recommended VSA format has caused some problems because of its
limitations (8-bit type
space) and lack of treatment as opaque octets (the Diameter/RADIUS 
translation problem in RFC 4005).   If we address the limitations, and
make 
it clear that following the recommendation is not required and cannot be
assumed by implementations, then this can work.

[avi] Good.

>If I have an enumeration (of TRUE or FALSE) using a 32-bit value is 
>wasteful in view of the size limitation of both attributes and packet 
>size.

Are you saying that the VSA space should allow one octet or two octet
data types?

[Avi] Why not?  Certainly in structured types this is very useful.  In
the past when working in SDO space I had lots of questions as to why are
we using a 32-bit value for an enumeration of true or false.

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

Delivery-date: Mon, 09 Apr 2007 18:55:05 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Guidelines Document Discussion
Date: Mon, 09 Apr 2007 11:54:47 -0700

>[Avi] Ideally it will help if we did suggest an encoding for VSAs. SDO
>will always need to create their own VSAs.  We are starting to see
>convergences in the Wireless/Wireline networks and it would be nice if
>SDOs attributes would interoperate or at least it should be easy to
>translate between SDOs.

This seems like it might be an achievable goal.  The RFC 2865 recommended 
VSA format has caused some problems because of its limitations (8-bit type 
space) and lack of treatment as opaque octets (the Diameter/RADIUS 
translation problem in RFC 4005).   If we address the limitations, and make 
it clear that following the recommendation is not required and cannot be 
assumed by implementations, then this can work.

>If I have an enumeration (of TRUE or FALSE) using a
>32-bit value is wasteful in view of the size limitation of both
>attributes and packet size.

Are you saying that the VSA space should allow one octet or two octet data 
types?

>[Avi] A good idea for readability. But not a show stopper.  Is the IETF
>willing to also honor SDOs name spaces? Probably not.

We could certainly recommend the use of unique name spaces for VSAs (e.g. 
SDO-Name) so as to avoid confusion.

>[Avi] interoperability within the SDO or with others?  I think within
>the SDO primarily.  To achieve interoperability between SDOs, and SDO is
>free to use another SDOs attributes.  It would be helpful for us RADIUS
>vendors if the encoding was the same though.

Right.  Assuming that the SDOs utilize similar attribute formats, and the 
specifications are published, this should work.  In particular, I would like 
to eliminate the need for SDOs to utilize RADIUS standard attributes just in 
order to have their specification widely disseminated.  In the long term the 
IETF should strive to assist SDOs in defining their own RADIUS attributes.

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

Delivery-date: Mon, 09 Apr 2007 18:40:44 +0000
Subject: RE: Guidelines Document Discussion
Date: Mon, 9 Apr 2007 14:39:44 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Bernard and Alan,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Alan DeKok
Sent: Sunday, April 08, 2007 10:35 AM
To: Bernard Aboba
Cc: [email-masked]
Subject: Re: Guidelines Document Discussion

Bernard Aboba wrote:
> One of the things that struck me about the current document is that it

> assumes that the differences in data model between the IETF Standard 
> space and the VSA space represent a long term problem which needs to 
> be resolved.

  I think the problem does need to be resolved in a standards body.
I've had any number of off-line discussions trying to get people to fix
their implementations (less code usually means it is more
inter-operable).  It's difficult to convince people that they're doing
anything problematic if they can point to RFC 2865, and say "the VSA
space is a free-for-all".

[Avi] Ideally it will help if we did suggest an encoding for VSAs. SDO
will always need to create their own VSAs.  We are starting to see
convergences in the Wireless/Wireline networks and it would be nice if
SDOs attributes would interoperate or at least it should be easy to
translate between SDOs.  

I don't think we could standerdize a VSA encoding.   But at least we can
make a recommendation on how an VSA could be encoded.  I would offer the
WiMAX encoding as a good example. It aligns with the RADIUS attribute
extension encoding at least in the header. And for the payload it allows
a structured types -- like 3GPP2.

> Even if there were to be some convergence of the standard and VSA data

> models, it strikes me that this convergence might only be temporary, 
> since a vendor or SDO using the VSA space can define their own 
> attribute format as well as attributes.

  As many have already done.

[Avi] I think that SDOs will always create their own attributes. But as
to the attribute format, I don't think an SDO would invent something if
there was already a good example to follow.

> It strikes me that RADIUS VSA usage may face a similar evolution, and 
> that such a parth, if successfully traveled, should not be cause for
> dismay.   As we have discovered, there may be circumstances in which a
> particular RADIUS attribute set may be easier to define within a VSA 
> space than within the standards space.  Rather than trying to fit a 
> square peg into a round hole by modifying the document to work with 
> the existing RADIUS standard data model, it is simpler to retain use
of VSAs.

  I concur.
[Avi] I agree.

> If we were writing an equivalent paragraph to the VSA allocation 
> description found in RFC 2865 Section 6.2 today, I think we might 
> include more instances in which allocation of VSAs is desirable.  For
> example:
> 
> * Where interoperability is useful but usage is confined to a specific

> access mechanism or SDO specification;
> * Where allocation of a large number of attributes is required (>5?)
> * Where data types are required that fall outside of the usage defined

> in the Guidelines document;

  And where SDOs wish to exert change control over the specification.

> We might also include circumstances in which VSA usage would be 
> strongly
> discouraged:
> 
> * Where the VSAs represent a change to the RADIUS protocol.  This 
> would include definition of new commands or operational modes.

  We should also encourage good practices, and discourage bad ones:

 - near-random numbering of VSA's per packet
 - VSA's containing ASCII string data, rather than TLV's
 - 1 or 2 byte VSA's for "efficiency" where "integer" type would do
[Avi]You mean prohibit the use of 1 or 2 byte TLVs where an integer
would do?  If yes I disagree.  RADIUS packets are getting smaller and
smaller these days?  If I have an enumeration (of TRUE or FALSE) using a
32-bit value is wasteful in view of the size limitation of both
attributes and packet size.

 - defining attributes in the IANA managed space, rather than using
   VSA's
[Avi] When feasible.
 - SDO-specific interpretations of existing RADIUS commands, attributes,
   or values for "integer" attributes.
[Avi] Not sure I understand the "...values for integer" part.

 - SDO's publishing standards that use existing standardized attribute
   names for SDO-specific attributes, or which use confusingly similar
   names

[Avi] A good idea for readability. But not a show stopper.  Is the IETF
willing to also honor SDOs name spaces? Probably not.

  SDO's and vendors should be reminded that the goal of VSA's is to
obtain interoperability.

[Avi] interoperability within the SDO or with others?  I think within
the SDO primarily.  To achieve interoperability between SDOs, and SDO is
free to use another SDOs attributes.  It would be helpful for us RADIUS
vendors if the encoding was the same though.

> I would suggest that the Guidelines document needs to tackle this and 
> other issues arising from the usage of VSAs.

  Yes.

[Avi] I agree as well.

  Alan DeKok.

--

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

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

Delivery-date: Sun, 08 Apr 2007 14:36:39 +0000
Date: Sun, 08 Apr 2007 16:35:13 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Guidelines Document Discussion

Bernard Aboba wrote:
> One of the things that struck me about the current document is that it
> assumes that the differences in data model between the IETF Standard
> space and the VSA space represent a long term problem which needs to be
> resolved.

  I think the problem does need to be resolved in a standards body.
I've had any number of off-line discussions trying to get people to fix
their implementations (less code usually means it is more
inter-operable).  It's difficult to convince people that they're doing
anything problematic if they can point to RFC 2865, and say "the VSA
space is a free-for-all".

> Even if there were to be some convergence of the standard and VSA data
> models, it strikes me that this convergence might only be temporary,
> since a vendor or SDO using the VSA space can define their own attribute
> format as well as attributes.

  As many have already done.

> As a result, it strikes me that the Guidelines document probably needs
> to accept that the RADIUS standard and VSA data models are currently
> different and are likely to remain so.  The document also needs to
> recognize the reality of today's VSA usage in other ways.

  Yes.

...
> While this paragraph has been used to argue that SDO usage of VSAs has
> gone beyond the original intent of RFC 2865, on comparing this paragraph
> with those in Section 5.26, I am not sure.  Since this paragraph comes
> from the IANA considerations section, it is really talking about the
> circumstances in which vendors (which would include SDOs) should be
> encouraged to use VSAs rather than requesting an allocation from the
> standards space.

  Yes.  That should be made very clear.

> It strikes me that RADIUS VSA usage may face a similar evolution, and
> that such a parth, if successfully traveled, should not be cause for
> dismay.   As we have discovered, there may be circumstances in which a
> particular RADIUS attribute set may be easier to define within a VSA
> space than within the standards space.  Rather than trying to fit a
> square peg into a round hole by modifying the document to work with the
> existing RADIUS standard data model, it is simpler to retain use of VSAs.

  I concur.

> If we were writing an equivalent paragraph to the VSA allocation
> description found in RFC 2865 Section 6.2 today, I think we might
> include more instances in which allocation of VSAs is desirable.  For
> example:
> 
> * Where interoperability is useful but usage is confined to a specific
> access mechanism or SDO specification;
> * Where allocation of a large number of attributes is required (>5?)
> * Where data types are required that fall outside of the usage defined
> in the Guidelines document;

  And where SDOs wish to exert change control over the specification.

> We might also include circumstances in which VSA usage would be strongly
> discouraged:
> 
> * Where the VSAs represent a change to the RADIUS protocol.  This would
> include definition of new commands or operational modes.

  We should also encourage good practices, and discourage bad ones:

 - near-random numbering of VSA's per packet
 - VSA's containing ASCII string data, rather than TLV's
 - 1 or 2 byte VSA's for "efficiency" where "integer" type would do
 - defining attributes in the IANA managed space, rather than using
   VSA's
 - SDO-specific interpretations of existing RADIUS commands, attributes,
   or values for "integer" attributes.
 - SDO's publishing standards that use existing standardized attribute
   names for SDO-specific attributes, or which use confusingly similar
   names

  SDO's and vendors should be reminded that the goal of VSA's is to
obtain interoperability.

> I would suggest that the Guidelines document needs to tackle this and
> other issues arising from the usage of VSAs.

  Yes.

  Alan DeKok.

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

Delivery-date: Sun, 08 Apr 2007 00:18:38 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: PROTO writeup for Issues & Fixes
Date: Sat, 07 Apr 2007 17:18:17 -0700

Find enclosed the proposed PROTO writeup for Issues & Fixes, which will 
submitted for IESG review once -03 hits the archive.  Comment welcome.

------------------------------------------------------------------------
Title:
Common RADIUS Implementation Issues and Suggested Fixes
I-D:
http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-03.txt
Status: Proposed Standard

(1.a) Who is the Document Shepherd for this document? Has the Document
Shepherd personally reviewed this version of the document and, in 
particular,
does he or she believe this version is ready for forwarding to the IESG for
publication?

Document Shepherd: Bernard Aboba
I have personally reviewed the document.

(1.b) Has the document had adequate review from both key WG members and
key non-WG members? Does the Document Shepherd have any concerns
about the depth or breadth of the reviews that have been performed?

Yes. This document has been through a WG last call.

(1.c) Does the Document Shepherd have concerns that the document needs
more review from a particular or broader perspective e.g., security, 
operational
complexity, someone familiar with AAA, internationalization or XML?

Document review has focused on the RADEXT WG since the document is about
RADIUS protocol issues and fixes.

(1.d) Does the Document Shepherd have any specific concerns or issues with 
this
document that the Responsible Area Director and/or the IESG should be aware 
of?
For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any 
event, if the WG
has discussed those issues and has indicated that it still wishes to advance 
the
document, detail those concerns here. Has an IPR disclosure related to this 
document been
filed? If so, please include a reference to the disclosure and summarize the 
WG
discussion and conclusion on this issue.

No concerns.

(1.e) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with
it?

There is consensus behind this document.  At various points,
8 people have posted review comments or made contributions relating
to the document.

The issues raised and the resolutions are available for inspection at
http://www.drizzle.com/~aboba/RADEXT/

(1.f) Has anyone threatened an appeal or otherwise indicated extreme 
discontent?
If so, please summarise the areas of conflict in separate email messages to 
the
Responsible Area Director. (It should be in a separate email because this
questionnaire is entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the document 
satisfies
all ID nits? (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; 
this
check needs to be thorough. Has the document met all formal review criteria 
it
needs to, such as the MIB Doctor, media type and URI type reviews?

Yes. An output of the run on this revision of the ID by the online nits
checker:

TBD, pending -03 submission to address IDNits.

(1.h) Has the document split its references into normative and informative?
Are there normative references to documents that are not ready for 
advancement
or are otherwise in an unclear state? If such normative references exist, 
what
is the strategy for their completion? Are there normative references that 
are
downward references, as described in [RFC3967]? If so, list these downward
references to support the Area Director in the Last Call procedure for them
[RFC3967].

The document splits normative and informative references.
There are no normative references to IDs.

(1.i) Has the Document Shepherd verified that the document IANA 
consideration
section exists and is consistent with the body of the document? If the 
document
specifies protocol extensions, are reservations requested in appropriate 
IANA
registries? Are the IANA registries clearly identified? If the document 
creates
a new registry, does it define the proposed initial contents of the registry 
and
an allocation procedure for future registrations? Does it suggest a 
reasonable
name for the new registry? See [RFC2434]. If the document describes an 
Expert
Review process has Shepherd conferred with the Responsible Area Director so
that the IESG can appoint the needed Expert during the IESG Evaluation?

This document has no actions for IANA.

(1.j) Has the Document Shepherd verified that sections of the document that
are written in a formal language, such as XML code, BNF rules, MIB 
definitions,
etc., validate correctly in an automated checker?

This document does not contain sections written in a formal language.

(1.k) The IESG approval announcement includes a Document Announcement 
Write-Up.
Please provide such a Document Announcement Write-Up? Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

   - Technical Summary

   This document describes common issues seen in RADIUS implementations
   and suggests some fixes.  Where applicable, ambiguities and errors in
   previous RADIUS specifications are clarified.

   - Working Group Summary

This document originally included issues and fixes relating to RFC 3576, but 
it
was decided that handling that in a separate document (RFC 3576bis) would be
more appropriate.  During the development of this document, a number of 
issues
required extended discussion, most recently text relating to handling of
duplicate detection within RADIUS.

   - Document Quality

This document describes issues that have been raised as a result of the
widespread
deployment of RADIUS for authentication, authorization and accounting.

   - Personnel

Bernard Aboba is the document shepherd.  The responsible Area Director is
Dan Romascanu. No IANA expert is needed.

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

Delivery-date: Sat, 07 Apr 2007 23:21:38 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Guidelines Document Discussion
Date: Sat, 07 Apr 2007 16:20:47 -0700

After IETF 68, I spent some time reading the current guidelines document and 
thinking about how we should proceed to revise it.

One of the things that struck me about the current document is that it 
assumes that the differences in data model between the IETF Standard space 
and the VSA space represent a long term problem which needs to be resolved.

Part of the reasoning is that without converging the data models, it may be 
difficult for RADIUS attributes specified using VSAs to be standardized 
without requiring changes to the standard data model.

At IETF 66, we had a discussion about this, and there was considerable 
resistance to the notion of extending the RADIUS data model to sync up 
better with the VSA data model.

Even if there were to be some convergence of the standard and VSA data 
models, it strikes me that this convergence might only be temporary, since a 
vendor or SDO using the VSA space can define their own attribute format as 
well as attributes.

As a result, it strikes me that the Guidelines document probably needs to 
accept that the RADIUS standard and VSA data models are currently different 
and are likely to remain so.  The document also needs to recognize the 
reality of today's VSA usage in other ways.

RFC 2865 Section 5.26 characterizes VSAs as follows:

      This Attribute is available to allow vendors to support their own
      extended Attributes not suitable for general usage.  It MUST not
      affect the operation of the RADIUS protocol.

      Servers not equipped to interpret the vendor-specific information
      sent by a client MUST ignore it (although it may be reported).
      Clients which do not receive desired vendor-specific information
      SHOULD make an attempt to operate without it, although they may do
      so (and report they are doing so) in a degraded mode.

These two paragraphs, which occur within the core of the RADIUS 
specification [RFC2865] hold up quite well even today.

The characterization of VSAs as "not suitable for general usage" is 
consistent with specifications created by SDOs for specific uses.  An 
example is RFC 4679 created by the DSL Forum.  It would also fit VSAs 
defined by IEEE 802 that are specific to the IEEE 802 family of protocols, 
such as those defined in RFC 4675.  The point made in the second sentence is 
that VSAs are just attirbutes and do not affect the RADIUS protocol itself; 
this would preclude SDOs from creating their own RADIUS dialects.

Note that this section does not talk about interoperability.  That 
discussion occurs in RFC 2865, Section 6.2:

   Note that RADIUS defines a mechanism for Vendor-Specific extensions
   (Attribute 26) and the use of that should be encouraged instead of
   allocation of global attribute types, for functions specific only to
   one vendor's implementation of RADIUS, where no interoperability is
   deemed useful.

While this paragraph has been used to argue that SDO usage of VSAs has gone 
beyond the original intent of RFC 2865, on comparing this paragraph with 
those in Section 5.26, I am not sure.  Since this paragraph comes from the 
IANA considerations section, it is really talking about the circumstances in 
which vendors (which would include SDOs) should be encouraged to use VSAs 
rather than requesting an allocation from the standards space.  However, 
this is not the only situation in which use of VSAs would make sense; the 
"not for general use" description from Section 5.26 is more comprehensive.

If we are to adjust to the idea that the standards data model and the VSA 
data model will not necessarily converge,  I think we will also need to 
adjust to a potentially larger role for VSAs, as well as thinking about the 
long-term relationship between the IETF and SDOs which utilize the RADIUS 
protocol.

Within the SNMP community, the need for an efficient and scalable approach 
to non-IETF MIB development has been evident for quite a while.  As 
described in RFC 4663, it is most efficient for MIBs to be developed within 
the standards organizations developing the protocols that require 
management, since handling MIB work in a separate standards body results in 
additional travel and coordination costs which are difficult to justify.  To 
help ensure quality, the IETF can provide assistance in the form of 
Guidelines documents and reviews provided by a Doctor team, and of course 
the IETF continues to assert change control over the SNMP protocol.

It strikes me that RADIUS VSA usage may face a similar evolution, and that 
such a parth, if successfully traveled, should not be cause for dismay.   As 
we have discovered, there may be circumstances in which a particular RADIUS 
attribute set may be easier to define within a VSA space than within the 
standards space.  Rather than trying to fit a square peg into a round hole 
by modifying the document to work with the existing RADIUS standard data 
model, it is simpler to retain use of VSAs.

If we were writing an equivalent paragraph to the VSA allocation description 
found in RFC 2865 Section 6.2 today, I think we might include more instances 
in which allocation of VSAs is desirable.  For example:

* Where interoperability is useful but usage is confined to a specific 
access mechanism or SDO specification;
* Where allocation of a large number of attributes is required (>5?)
* Where data types are required that fall outside of the usage defined in 
the Guidelines document;

We might also include circumstances in which VSA usage would be strongly 
discouraged:

* Where the VSAs represent a change to the RADIUS protocol.  This would 
include definition of new commands or operational modes.

I would suggest that the Guidelines document needs to tackle this and other 
issues arising from the usage of VSAs.

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

Delivery-date: Sat, 07 Apr 2007 06:04:56 +0000
Content-class: urn:content-classes:message
Subject: RE: Publication of RADIUS Prepaid Document
Date: Fri, 6 Apr 2007 23:03:54 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba <mailto:[email-masked]> allegedly scribbled on
Thursday, April 05, 2007 4:13 PM:

>> OK w/me.  Any idea _what_ VSA set?
> 
> WiMAX or 3GPP2 VSAs?

Cool - I think they are (at least close to) identical, so that sounds
pretty useful.

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

Delivery-date: Thu, 05 Apr 2007 23:14:19 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Publication of RADIUS Prepaid Document
Date: Thu, 05 Apr 2007 16:13:29 -0700

>OK w/me.  Any idea _what_ VSA set?

WiMAX or 3GPP2 VSAs?

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

Delivery-date: Thu, 05 Apr 2007 15:12:52 +0000
Content-class: urn:content-classes:message
Subject: RE: Publication of RADIUS Prepaid Document
Date: Thu, 5 Apr 2007 08:12:39 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Bernard Aboba <> allegedly scribbled on Wednesday, March 21, 2007 3:27
AM:

> At IETF 68, it was suggested that the RADIUS Prepaid document be
> published as an Informational RFC documenting existing usage
> (presumably based on RADIUS VSAs).   This would enable us to unblock
> the document, since  
> conformance to the Guidelines document (still in progress) would no
> longer be required. 
> 
> Are there any objections to this approach?

OK w/me.  Any idea _what_ VSA set?

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

Delivery-date: Thu, 05 Apr 2007 15:10:23 +0000
Content-Class: urn:content-classes:message
Subject: RE: Publication of RADIUS Prepaid Document
Date: Thu, 5 Apr 2007 10:41:11 -0400
From: "Chowdhury, Kuntal" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

I support publishing this document as an informational RFC.

-Kuntal

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Bernard Aboba
> Sent: Wednesday, March 21, 2007 5:27 AM
> To: [email-masked]
> Subject: Publication of RADIUS Prepaid Document
> 
> At IETF 68, it was suggested that the RADIUS Prepaid document be
published
> as an Informational RFC documenting existing usage (presumably based
on
> RADIUS VSAs).   This would enable us to unblock the document, since
> conformance to the Guidelines document (still in progress) would no
longer
> be required.
> 
> Are there any objections to this approach?
> 
> 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."

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

Delivery-date: Thu, 05 Apr 2007 09:50:44 +0000
Date: Thu, 05 Apr 2007 11:49:55 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: I-D ACTION:draft-ietf-radext-fixes-02.txt

Bernard Aboba wrote:
..
>  ** Missing expiration date.  The document expiration date should appear on
>     the first and last page.

  Added 'Expires:' header.

>  ** The document seems to lack separate sections for Informative/Normative
>     References.  All references will be assumed normative when checking for
>     downward references.

  Removed a trailing '.' from normative/informative section names.

  A -03 will be issued shortly.

  Alan DeKok.

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

Delivery-date: Thu, 05 Apr 2007 06:09:16 +0000
Date: Thu, 05 Apr 2007 08:07:59 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: I-D ACTION:draft-ietf-radext-fixes-02.txt

Bernard Aboba wrote:
> IDNITs gives some errors on this document:

  Hmm..   I'm not sure why the -01 was OK, and this one isn't.

>  ** Missing expiration date.  The document expiration date should appear on
>     the first and last page.

  It's on the first, apparently not on the last.  Is this a new requirement?

>  ** The document seems to lack separate sections for Informative/Normative
>     References.  All references will be assumed normative when checking for
>     downward references.

  5.1 has Normative && 5.2 has Informative references.  I think idnits
is looking for very specific text.

>  -- Missing reference section? 

  I think this is because idnits is looking for very specific text for
the section names.  We can update those, andn run idnits again.

  I think the only substantive error is the lack of an expiration date
on the last page.  A -03 will be issued shortly.

  Alan DeKok.

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

Delivery-date: Wed, 04 Apr 2007 23:47:14 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: PROTO Writeup: RFC 4590bis
Date: Wed, 04 Apr 2007 16:46:39 -0700

Since no additional issues have been raised, we are preparing to send RFC 
4590bis off to the IESG for publication as a Proposed Standard.  Here is the 
PROTO writeup:

------------------------------------------------------------------------
Title:   RADIUS Extension for Digest Authentication
I-D:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc4590bis-01.txt

Status: Proposed Standard

(1.a) Who is the Document Shepherd for this document? Has the Document
Shepherd personally reviewed this version of the document and, in 
particular,
does he or she believe this version is ready for forwarding to the IESG for
publication?

Document Shepherd: Bernard Aboba
I have personally reviewed the document.

(1.b) Has the document had adequate review from both key WG members and
key non-WG members? Does the Document Shepherd have any concerns
about the depth or breadth of the reviews that have been performed?

Yes. This document has been through a WG last call.

(1.c) Does the Document Shepherd have concerns that the document needs
more review from a particular or broader perspective e.g., security, 
operational
complexity, someone familiar with AAA, internationalization or XML?

This document includes some fixes to RFC 4590, which was discovered to 
contain
IANA errors after publication.  These problems were fixed along with a
few other errata.  So this document has already received extensive review in
the relatively recent past.

(1.d) Does the Document Shepherd have any specific concerns or issues with 
this
document that the Responsible Area Director and/or the IESG should be aware 
of?
For example, perhaps he or she is uncomfortable with certain parts of the
document,  or has concerns whether there really is a need for it. In any 
event, if the WG
has discussed those issues and has indicated that it still wishes to advance 
the
document, detail those concerns here. Has an IPR disclosure related to this 
document been
filed? If so, please include a reference to the disclosure and summarize the 
WG
discussion and conclusion on this issue.

No concerns.

(1.e) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with
it?

There is solid consensus behind this document, as there was behind
RFC 4590.

The issues raised and the resolutions are available for inspection at
http://www.drizzle.com/~aboba/RADEXT/

(1.f) Has anyone threatened an appeal or otherwise indicated extreme 
discontent?
If so, please summarise the areas of conflict in separate email messages to 
the
Responsible Area Director. (It should be in a separate email because this
questionnaire is entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the document 
satisfies
all ID nits? (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; 
this
check needs to be thorough. Has the document met all formal review criteria 
it
needs to, such as the MIB Doctor, media type and URI type reviews?

Yes. An output of the run on this revision of the ID by the online nits
checker:

idnits 2.04.05

tmp/draft-ietf-radext-rfc4590bis-01.txt:
tmp/draft-ietf-radext-rfc4590bis-01.txt(1132): Found possible
IPv4 address '3.2.2.2' in position 64; this doesn't match RFC3330's 
suggested
192.0.2.0/24 address range.

[BA] 3.2.2.2 is a section header, not an address.

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
  
----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  
----------------------------------------------------------------------------

  ** Missing expiration date.  The document expiration date should appear on
     the first and last page.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  
----------------------------------------------------------------------------

  ** There are 1 instance of lines with non-RFC3330-compliant IPv4 addresses
     in the document.  If these are example addresses, they should be 
changed.

[BA] They are not example addresses.

  Miscellaneous warnings:
  
----------------------------------------------------------------------------

     No issues found here.

  Checking references for intended status: Proposed Standard
  
----------------------------------------------------------------------------

  -- Looks like a reference, but probably isn't: '4' on line 1008
     '0-1      0      0      1          0    24  State [4]...'

  -- Looks like a reference, but probably isn't: '1' on line 1028
     '0        0-1    0      0          0   121  Digest-HA1 [1][2]...'

  -- Looks like a reference, but probably isn't: '2' on line 1028
     '0        0-1    0      0          0   121  Digest-HA1 [1][2]...'

  -- Looks like a reference, but probably isn't: '3' on line 1018
     '0-1      0      0      0-1        0-1 111  Digest-Algorithm [3]...'

  = Missing Reference: 'Note 1' is mentioned on line 1039, but not
     defined
     '[Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth...'

  -- Possible downref: Undefined Non-RFC (?) reference : ref. 'Note 1'

  = Missing Reference: 'Note 2' is mentioned on line 1042, but not
     defined
     '[Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1...'

  -- Possible downref: Undefined Non-RFC (?) reference : ref. 'Note 2'

  = Missing Reference: 'Note 3' is mentioned on line 1045, but not
     defined
'[Note 3] If Digest-Algorithm is missing, 'MD5' is assumed....'

  -- Possible downref: Undefined Non-RFC (?) reference : ref. 'Note 3'

  = Missing Reference: 'Note 4' is mentioned on line 1047, but not
     defined
     '[Note 4] An Access-Challenge MUST contain a State attribute, whic...'

  -- Possible downref: Undefined Non-RFC (?) reference : ref. 'Note 4'

  ** Downref: Normative reference to an Informational RFC: RFC 3579

  -- Obsolete informational reference (is this intentional?): RFC 2069
     (Obsoleted by RFC 2617)

[BA] This is intentional.

     Summary: 3 errors (**), 4 warnings (=), 9 comments (--).

(1.h) Has the document split its references into normative and informative?
Are there normative references to documents that are not ready for 
advancement
or are otherwise in an unclear state? If such normative references exist, 
what
is the strategy for their completion? Are there normative references that 
are
downward references, as described in [RFC3967]? If so, list these downward
references to support the Area Director in the Last Call procedure for them
[RFC3967].

The document splits normative and informative references.
There are no normative references to IDs.

(1.i) Has the Document Shepherd verified that the document IANA 
consideration
section exists and is consistent with the body of the document? If the 
document
specifies protocol extensions, are reservations requested in appropriate 
IANA
registries? Are the IANA registries clearly identified? If the document 
creates
a new registry, does it define the proposed initial contents of the registry 
and
an allocation procedure for future registrations? Does it suggest a 
reasonable
name for the new registry? See [RFC2434]. If the document describes an 
Expert
Review process has Shepherd conferred with the Responsible Area Director so
that the IESG can appoint the needed Expert during the IESG Evaluation?

I have verified that the IANA consideration exists and is consistent with 
the
body of the document.  The inconsistency in RFC 4590 was the reason why this
document needed to be produced.

(1.j) Has the Document Shepherd verified that sections of the document that
are written in a formal language, such as XML code, BNF rules, MIB 
definitions,
etc., validate correctly in an automated checker?

This document does not contain sections written in a formal language.

(1.k) The IESG approval announcement includes a Document Announcement 
Write-Up.
Please provide such a Document Announcement Write-Up? Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

   - Technical Summary

   This document defines an extension to the Remote Authentication Dial-
   In User Service (RADIUS) protocol to enable support of Digest
   Authentication, for use with HTTP-style protocols like the Session
   Initiation Protocol (SIP) and HTTP.

   - Working Group Summary

   Working Group discussion largely centered on whether the issues
   identified in RFC 4590 could be fixed via an errata or whether
   a new RFC was required.  Due to conflicts between the RFC 4590 text
   and the parameters allocated by IANA, it was decided that a new
   RFC would be needed, so as to avoid potential interoperability
   problems.

   - Document Quality

This document is needed to address a problem in the IANA allocations for
Digest Authentication as well as several errata that were found after the
publication of RFC 4590.  At this point, we believe that RFC 4590bis 
addresses
all issues raised since the publication of RFC 4590.

   - Personnel

Bernard Aboba is the document shepherd.  The responsible Area Director is
Dan Romascanu. No IANA expert is needed.

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

Delivery-date: Wed, 04 Apr 2007 21:43:49 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RE: I-D ACTION:draft-ietf-radext-fixes-02.txt
Date: Wed, 04 Apr 2007 14:43:10 -0700

IDNITs gives some errors on this document:

idnits 2.04.05

tmp/draft-ietf-radext-fixes-02.txt:

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
  
----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  
----------------------------------------------------------------------------

  ** Missing expiration date.  The document expiration date should appear on
     the first and last page.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  
----------------------------------------------------------------------------

  ** The document seems to lack separate sections for Informative/Normative
     References.  All references will be assumed normative when checking for
     downward references.

  Miscellaneous warnings:
  
----------------------------------------------------------------------------

     No issues found here.

  Checking references for intended status: Proposed Standard
  
----------------------------------------------------------------------------

  -- Missing reference section? 'RFC2119' on line 924 looks like a
     reference
     '[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate...'

  -- Missing reference section? 'RFC2865' on line 903 looks like a
     reference
'[RFC2865]...'

  -- Missing reference section? 'RFC3579' on line 970 looks like a
     reference
     'The alternate algorithm to [RFC3579] Section 2.6.1 that is descri...'

  -- Missing reference section? 'RFC4669' on line 956 looks like a
     reference
     '[RFC4669] Nelson, D, "RADIUS Authentication Server MIB for IPv6", 
RF...'

  -- Missing reference section? 'RFC2866' on line 907 looks like a
     reference
'[RFC2866]...'

  -- Missing reference section? 'RFC2869' on line 910 looks like a
     reference
'[RFC2869]...'

  -- Missing reference section? 'RFC2618' on line 933 looks like a
     reference
     '[RFC2618] Aboba, B. and G. Zorn, "RADIUS Authentication Client 
MIB",...'

  -- Missing reference section? 'RFC4668' on line 953 looks like a
     reference
     '[RFC4668] Nelson, D, "RADIUS Authentication Client MIB for IPv6", 
RF...'

  -- Missing reference section? '1' on line 627 looks like a reference
     '[1]  New RADIUS specifications and implementations MUST NOT use 
Acce...'

  -- Missing reference section? '2' on line 630 looks like a reference
     '[2]  Access-Reject MUST mean denial of access to the requested 
servi...'

  -- Missing reference section? '3' on line 634 looks like a reference
     '[3]  New deployments of ARAP [RFC2869] SHOULD use Access-Challenge...'

  -- Missing reference section? 'Note 2' on line 651 looks like a
     reference
     '[Note 2] As per RFC 3579, the use of the Password-Retry in EAP...'

  -- Missing reference section? 'RFC2462' on line 927 looks like a
     reference
     '[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address...'

  -- Missing reference section? 'RFC3927' on line 947 looks like a
     reference
     '[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic 
Configura...'

  -- Missing reference section? 'RFC3162' on line 936 looks like a
     reference
     '[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", 
RFC...'

  -- Missing reference section? 'RFC3580' on line 939 looks like a
     reference
     '[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. 
Roese,...'

  -- Missing reference section? 'RFC3748' on line 943 looks like a
     reference
     '[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H....'

  -- Missing reference section? 'RFC4282' on line 950 looks like a
     reference
     '[RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The 
Netw...'

  -- Missing reference section? 'PREFIX' on line 961 looks like a
     reference
     'The references to [PREFIX] should be replaced with a reference to...'

  -- Missing reference section? 'RFC2607' on line 930 looks like a
     reference
     '[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy...'

     Summary: 2 errors (**), 0 warnings (=), 20 comments (--).

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

Delivery-date: Wed, 04 Apr 2007 19:50:44 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-fixes-02.txt 
Date: Wed, 04 Apr 2007 15:50:02 -0400

--NextPart

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

	Title		: Common RADIUS Implementation Issues and Suggested Fixes
	Author(s)	: D. Nelson, A. DeKok
	Filename	: draft-ietf-radext-fixes-02.txt
	Pages		: 23
	Date		: 2007-4-4
	
This document describes common issues seen in RADIUS implementations
   and suggests some fixes.  Where applicable, ambiguities and errors in
   previous RADIUS specifications are clarified.

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

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

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

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

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

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

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

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

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

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

--OtherAccess--

--NextPart--

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

Delivery-date: Wed, 04 Apr 2007 14:04:36 +0000
Date: Wed, 04 Apr 2007 17:03:54 +0300
From: Jouni Korhonen <[email-masked]>
To: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
CC: Jouni Korhonen <[email-masked]>, [email-masked]
Subject: Re: Filter-rules-01 & Issue 192

Now also CC:ing the RADEXT.

Jouni Korhonen kirjoitti:
> Hi,
> 
> There are of course corner cases where the last rule-delim alone would 
> go into the a new attribute.. then the savings would be more ;-)
> 
> I'm OK with your earlier ABNF proposal as it now allows multiple rules 
> per attribute. So, consider issue 192 closed from my side.
> 
> Anyway, in the ABNF you proposed earlier the role of 'rule-delim' is 
> actually something like 'end-of-rule' mark. It would be nice if you 
> could reflect this in the ABNF.
> 
> 
> Cheers,
>     Jouni
> 
> 
> 
> Sanchez, Mauricio (ProCurve) kirjoitti:
>> Jouni recommended...
>>
>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [JiK] Yes. Is there a particular reason to add a trailing rule-delim if
>>> there is only a single rule? If not maybe the example below would work:
>>>
>>>        rule-list      =  rule
>>>          rule-list      =/ rule-list rule-delim rule
>>>          rule           =  "v1" " " (flush-rule / permit-all-rule
>>>                            / l2-filter-rule / l2-tunnel-rule
>>>                            / ip-filter-rule / ip-tunnel-rule
>>>                            / http-filter-rule / http-redir-rule)
>>
>> Yes, your syntax saves one whole octet :), but is the complexity merited?
>> Can we just go with my proposal?  It would keep the general rule syntax
>> consistent.
>> MS
> 

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

Delivery-date: Wed, 04 Apr 2007 13:10:43 +0000
Date: Wed, 04 Apr 2007 16:09:53 +0300
From: Jari Arkko <[email-masked]>
To: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
CC:  [email-masked]
Subject: Re: Issue 164: Review (traffic-rule-draft)

I have reviewed the new draft revision for the relevant
parts and I'm happy with it. Thanks for the making
the changes. You can close the issue.

Jari

Sanchez, Mauricio (ProCurve) kirjoitti:
>
> I believe draft -02 contains resolutions to all Jari’s comments in
> issue 164. Need confirmation from Jari.
>
> Cheers,
>
> MS
>
> --------------------------------------------
>
> Mauricio Sanchez, CISSP
>
> Network Security Architect
>
> ProCurve Networking Business
>
> Hewlett Packard
>
> 8000 Foothills Boulevard, ms 5557
>
> Roseville CA, 95747-5557
>
> 916.785.1910 Tel
>
> 916.785.1815 Fax
>
> [email-masked]
>
> --------------------------------------------
>

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