Subject: RE: Comments on draft-ietf-radext-filter-05
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Date: Fri, 1 Dec 2006 00:14:52 +0200

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Friday, December 01, 2006 12:12 AM
> To: Romascanu, Dan (Dan) ; [email-masked]
> Subject: RE: Comments on draft-ietf-radext-filter-05
> 
> Here is a rewritten Abstract:
> 
> "While RFC 2865 defines the Filter-Id attribute, this 
> requires that the Network Access Server (NAS) be 
> pre-populated with the desired filters.
> However, in situations where the server operator does not 
> know which filters have been pre-populated, it useful to 
> specify filter rules explicitly.
> This document defines the NAS-Filter-Rule attribute within 
> the Remote Authentication Dial In User Service (RADIUS).  
> This attribute is based on the Diameter NAS-Filter-Rule 
> Attribute Value Pair (AVP) described in RFC 4005, and the 
> IPFilterRule syntax defined in RFC 3588."

Thanks, looks good. 

> 
> Indicating that the Length value is >3 is a way of sayin that 
> a data field of zero length (e.g. Length =2) is not 
> acceptable for the NAS-Filter-Rule attribute.

I know, but this is cryptic for somebody who is not that familiar with
the stile of other RADIUS documents. 

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: Thu, 30 Nov 2006 22:14:04 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Comments on draft-ietf-radext-filter-05
Date: Thu, 30 Nov 2006 14:11:43 -0800

Here is a rewritten Abstract:

"While RFC 2865 defines the Filter-Id attribute,
this requires that the Network Access Server (NAS) be pre-populated with the 
desired filters.
However, in situations where the server operator does not know which filters 
have been
pre-populated, it useful to specify filter rules explicitly.
This document defines the NAS-Filter-Rule attribute within the
Remote Authentication Dial In User Service (RADIUS).  This attribute is
based on the Diameter NAS-Filter-Rule Attribute Value Pair (AVP) described
in RFC 4005, and the IPFilterRule syntax defined in RFC 3588."

Indicating that the Length value is >3 is a way of sayin that a data field 
of zero length (e.g. Length =2) is not acceptable for the NAS-Filter-Rule 
attribute.

>From: "Romascanu, Dan  (Dan)" <[email-masked]>
>To: <[email-masked]>
>Subject: Comments on draft-ietf-radext-filter-05 Date: Thu, 30 Nov 2006 
>23:37:40 +0200
>
>
>A couple of editorial comments:
>
>1. Acronyms in the Abstract section should be expanded. In this document
>NAS and AVP are present in the Abstract section and not expanded (but
>RADIUS is!)
>2. In the format description there is no explanation about the Length
>field other than saying '>=3'. While this may be normal in a document
>where Length is explained some other part, or may be easy to understand
>for people familiar with the other RADIUS documents, it is cryptic for
>the reader of this document alone. It would be useful to provide at
>least a reference for a definition of the Length of a attribute in
>another document.
>
>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/>

--
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, 30 Nov 2006 21:40:21 +0000
content-class: urn:content-classes:message
Subject: Comments on draft-ietf-radext-filter-05 
Date: Thu, 30 Nov 2006 23:37:40 +0200
From: "Romascanu, Dan  \(Dan\)" <[email-masked]>
To: <[email-masked]>

A couple of editorial comments:

1. Acronyms in the Abstract section should be expanded. In this document
NAS and AVP are present in the Abstract section and not expanded (but
RADIUS is!)
2. In the format description there is no explanation about the Length
field other than saying '>=3'. While this may be normal in a document
where Length is explained some other part, or may be easy to understand
for people familiar with the other RADIUS documents, it is cryptic for
the reader of this document alone. It would be useful to provide at
least a reference for a definition of the Length of a attribute in
another document. 

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

Envelope-to: [email-masked]
Delivery-date: Mon, 27 Nov 2006 21:03:17 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: Proposed Resolution to RFC 3576bis Issue 163: VSA with Disconnect-Request 
cc: [email-masked]
Date: Mon, 27 Nov 2006 15:53:01 -0500
Message-Id: <[email-masked]>

"Bernard Aboba" <[email-masked]> wrote:
> "Where a Service-Type Attribute with value "Authorize Only" is
> included within a CoA-Request, only NAS or session identification
> attributes are permitted, as well as Service-Type, Nonce and State
> attributes.  If other attributes are included in such a CoA-Request,
> implementations MUST send a CoA-NAK; an Error-Cause Attribute with
> value "Unsupported Attribute" MAY be included."

  Looks good to me.  

  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, 27 Nov 2006 20:00:01 +0000
Content-class: urn:content-classes:message
Subject: RE: Inclusion of Filter-Id and NAS-Filter-Rule AVPs
Date: Mon, 27 Nov 2006 14:59:16 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...
 
> Perhaps the best solution is simply to say this in the document.

That may, in fact, be the best we can do.

>  For example:
> 
> "The NAS-Filter-Rule attribute is not intended to be used 
> concurrently with any other filter rule attribute, including 
> Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes.  
> NAS-Filter-Rule and NAS-Traffic-Rule attributes MUST NOT appear
> in the same RADIUS packet.  If a NAS-Traffic-Rule attribute is
> present, a NAS implementing this specification MUST silently
> discard NAS-Filter-Rule attributes, if present.  Filter-Id and
> NAS-Filter-Rule attributes SHOULD NOT appear in the same RADIUS
> packet.
>
> Given the absence in [RFC4005] of well-defined precedence rules 
> for combining Filter-Id and NAS-Filter-Rule attributes into a single 
> rule set, the behavior of NASes receiving both attributes is 
> undefined, and therefore a RADIUS server implementation cannot 
> assume a consistent behavior."

This seems OK to me.

--
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, 27 Nov 2006 19:06:15 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Inclusion of Filter-Id and NAS-Filter-Rule AVPs
Date: Mon, 27 Nov 2006 11:05:08 -0800

>Dave Mitton writes...
>
> > I've changed my view of this issue of being that of forwards
> > compatibility.
> >
> > You are adding a new feature, and there is existing deployment
> > of the old feature.  You cannot just wish them to disappear.
> > > There will be mixed deployments, and the definition of the
> > new feature should accommodate the existing systems as best
> > as possible.
> > > Perhaps leaving it to the vendor is insufficient.  But the
> > situation cannot be outlawed.
>
>Well, if anyone truly cares about multi-vendor interoperability,
>something needs to be done.  IMHO, the current Diameter spec is badly
>flawed in this regard. In the absence of a set of well-defined
>precedence rules, users can't reasonably expect to see consistent
>application of access control policy, in multi-vendor NAS deployments,
>when using a combination of Filter-ID and Filter-Rule semantics.

Perhaps the best solution is simply to say this in the document.  For 
example:

"The NAS-Filter-Rule attribute is not intended to be used concurrently with 
any other filter rule attribute, including Filter-Id (11) and 
NAS-Traffic-Rule [Traffic] attributes.  NAS-Filter-Rule and NAS-Traffic-Rule 
attributes MUST NOT appear in the same RADIUS packet.  If a NAS-Traffic-Rule 
attribute is present, a NAS implementing this specification MUST silently 
discard NAS-Filter-Rule attributes, if present.  Filter-Id and 
NAS-Filter-Rule attributes SHOULD NOT appear in the same RADIUS packet.  
Given the absence in [RFC4005] of well-defined precedence rules for 
combining Filter-Id and NAS-Filter-Rule attributes into a single rule set, 
the behavior of NASes receiving both attributes is undefined, and therefore 
a RADIUS server implementation cannot assume a consistent behavior."

--
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, 27 Nov 2006 18:00:49 +0000
Content-class: urn:content-classes:message
Subject: RE: Inclusion of Filter-Id and NAS-Filter-Rule AVPs
Date: Mon, 27 Nov 2006 13:00:24 -0500
To: <[email-masked]>

Dave Mitton writes...

> I've changed my view of this issue of being that of forwards
> compatibility.
> 
> You are adding a new feature, and there is existing deployment
> of the old feature.
> You cannot just wish them to disappear.

I can certainly _wish_ it.  How practical that wish might be is another
issue, of course.

> There will be mixed deployments, and the definition of the 
> new feature should accommodate the existing systems as best 
> as possible.

I believe Diameter made a big mistake in allowing both Filter-ID and
Filter-Rule semantics in the same AVP without explicit rules of
precedence.  Can we go back and correct that "mistake"?  You are
suggesting that we can't, and further that we need to continue that
"mistake" into the RADIUS work.

> Perhaps leaving it to the vendor is insufficient.  But the
> situation cannot be outlawed.

Well, if anyone truly cares about multi-vendor interoperability,
something needs to be done.  IMHO, the current Diameter spec is badly
flawed in this regard. In the absence of a set of well-defined
precedence rules, users can't reasonably expect to see consistent
application of access control policy, in multi-vendor NAS deployments,
when using a combination of Filter-ID and Filter-Rule semantics.

--
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, 27 Nov 2006 17:53:47 +0000
Content-class: urn:content-classes:message
Subject: FW: Inclusion of Filter-Id and NAS-Filter-Rule AVPs
Date: Mon, 27 Nov 2006 12:52:38 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Forwarding to the RADEXT list, at Dave Mitton's suggestion...

> Dave Mitton writes...
>
> > Sigh... this is another problem where some sort of NAS
> > version number or capabilities field would be useful.
> > I guess the best compromise would be to continue to allow
> > them to be sent together.
>
> > An older system would ignore the new rule and use the 
> > Filter-ID.
> > A newer system would use the new rules (if present) and 
> > either ignore the Filter-ID or have it defined as a 
> > Non-operation.  The provisioning of the rules behind a
> > Filter-ID are still not defined.
>
> This begs the question of multi-vendor interoperability. 
> If the interpretation and precedence rules for the "both" 
> scenario are left to the implementer, then any user who 
> wishes to take advantage of the "both" feature better 
> sole-source his NASes.  This is contrary to the spirit of
> Standards Track RFCs, IMHO.

(Dave Mitton, responding)

We should have this conversation on list.

I've changed my view of this issue of being that of forwards 
compatibility.

You are adding a new feature, and there is existing deployment
of the old feature.
You cannot just wish them to disappear.  There will be mixed 
deployments, and the definition of the new feature should 
accommodate the existing systems as best as possible.

Perhaps leaving it to the vendor is insufficient.  But the 
situation cannot be outlawed.

--
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: Fri, 24 Nov 2006 17:50:25 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: Proposed Resolution to RFC 3576bis Issue 161: Authorize-Only Service-Type 
cc: [email-masked]
Date: Fri, 24 Nov 2006 09:12:32 -0500
Message-Id: <[email-masked]>

> The text of Issue 161 is enclosed below.  The proposed resolution is as 
> follows:

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

Envelope-to: [email-masked]
Delivery-date: Fri, 24 Nov 2006 17:50:17 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: Proposed Resolution to RFC 3576bis Issue 139: Nonce Attribute 
cc: [email-masked]
Date: Fri, 24 Nov 2006 09:10:56 -0500
Message-Id: <[email-masked]>

> The text of Issue 139 is enclosed below.  The proposed resolution is as 
> follows:

  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: Fri, 24 Nov 2006 16:24:30 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Proposed Resolution to RFC 3576bis Issue 139: Nonce Attribute
Date: Fri, 24 Nov 2006 08:10:21 -0800

Noticed that the Attribute Table allows a Nonce attribute in any CoA or 
Disconnect message.  As a result, the last sentence in the first paragraph 
of Section 3.3 needs to read as follows:

"For this purpose, a Nonce Attribute MAY be included within CoA-Request,
CoA-ACK, CoA-NAK, Disconnect-Request, Disconnect-ACK, Disconnect-NAK and 
Accounting-Request packets. "

> > The text of Issue 139 is enclosed below.  The proposed resolution is as
> > follows:
>
>   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: Fri, 24 Nov 2006 16:23:43 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Proposed Resolution to RFC 3576bis Issue 163: VSA with Disconnect-Request
Date: Fri, 24 Nov 2006 08:22:42 -0800

> > "   Where a Service-Type Attribute with value "Authorize Only" is
> >    included within a CoA-Request, attributes representing an
> >    authorization change MUST NOT be included;
>
>  On first reading, that could be interpreted as "when asking for
>change of authorization, authorization changes are not permitted".  I
>suggest adding text stating what it means to have CoA-Request without
>authorization changes.  I'm not sure what to suggest, though.

How about this?

"Where a Service-Type Attribute with value "Authorize Only" is included
within a CoA-Request,  only NAS or session identification attributes
are permitted, as well as Service-Type, Nonce and State attributes.  If 
other
attributes are included in such a CoA-Request, implementations MUST send a 
CoA-NAK;
an Error-Cause Attribute with value "Unsupported Attribute" MAY be 
included."

BTW, since the NAS only needs the session identification attributes in order 
to prepare its response, it would seem that it would be "liberal in what you 
accept" to just ignore additional 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: Fri, 24 Nov 2006 16:07:14 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Proposed Resolution to RFC 3576bis Issue 132: Must Proxy-State be Copied by 
Date: Fri, 24 Nov 2006 08:02:56 -0800

>   To resolve the first question raised in the issue, I would change
>the text to add "or NAS"
>
>"      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.

Looks ok.

--
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, 24 Nov 2006 16:07:07 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Proposed Resolution to RFC 3576bis Issue 132: Must Proxy-State be Copied by 
Date: Fri, 24 Nov 2006 08:02:56 -0800

>   To resolve the first question raised in the issue, I would change
>the text to add "or NAS"
>
>"      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.

Looks ok.

--
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: Fri, 24 Nov 2006 15:26:01 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: Proposed Resolution to RFC 3576bis Issue 132: Must Proxy-State be Copied by NAS? 
cc: [email-masked]
Date: Fri, 24 Nov 2006 09:10:08 -0500
Message-Id: <[email-masked]>

> The text of issue 132 is enclosed below.  The proposed resolution is to add 
> the following text to Section 3.2:

  To resolve the first question raised in the issue, I would change
the text to add "or NAS"

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

  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: Fri, 24 Nov 2006 14:32:06 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: Proposed Resolution to RFC 3576bis Issue 163: VSA with Disconnect-Request 
cc: [email-masked]
Date: Fri, 24 Nov 2006 09:22:06 -0500
Message-Id: <[email-masked]>

> So my take is that the omission of vendor-specific attributes from  a RFC 
> 3576 Disconnect-Request is intentional.

  I would agree.

> The proposed resolution is to change the last two paragraphs of Section 3 to 
> the following:
>
> "   Where a Service-Type Attribute with value "Authorize Only" is
>    included within a CoA-Request, attributes representing an
>    authorization change MUST NOT be included;

  On first reading, that could be interpreted as "when asking for
change of authorization, authorization changes are not permitted".  I
suggest adding text stating what it means to have CoA-Request without
authorization changes.  I'm not sure what to suggest, though.

  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: Fri, 24 Nov 2006 14:12:47 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: Proposed Resolution to RFC 3576bis Issue 55: Message-Authenticator Attribute 
cc: [email-masked]
Date: Fri, 24 Nov 2006 09:02:08 -0500
Message-Id: <[email-masked]>

> The proposed resolution is as follows:

  I concur.

  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: Fri, 24 Nov 2006 07:23:13 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Proposed Resolution to RFC 3576bis Issue 163: VSA with Disconnect-Request
Date: Thu, 23 Nov 2006 23:22:11 -0800

The text of Issue 163 is enclosed below.

The permitted attributes in a Disconnect-Request parallels the attributes 
permitted in a RADIUS Access-Reject to some extent.  The Disconnect-Request 
only includes session identification attributes since the goal is not to 
change the authorizations, but to terminate the user.  Therefore the only 
attributes needed are those that are used for user-identification.

RFC 2865 only enables Reply-Message and Proxy-State attributes in an 
Access-Reject;  Vendor-Specific attributes are prohibited.  RFC 2869 enables 
inclusion of Password-Retry, EAP-Message and Message-Authenticator 
attributes.  RFC 3579 enables inclusion of an Error-Cause attribute within 
an Access-Reject.  RFC 2868 and 3162 do not enable use of the attributes 
defined there within an Access-Reject.

So my take is that the omission of vendor-specific attributes from  a RFC 
3576 Disconnect-Request is intentional.

Of course, this begs the question of why a Service-Type value of "Authorize 
Only" is being used with a Disconnect-Request in the first place.  RFC 3576 
is in error in stating that this is useful for Diameter interoperability;  
in fact, Diameter disconnect requests are handled via request/response, not 
via generation of another Access-Request.

The proposed resolution is to change the last two paragraphs of Section 3 to 
the following:

"   Where a Service-Type Attribute with value "Authorize Only" is
   included within a CoA-Request, attributes representing an
   authorization change MUST NOT be included; only NAS or session
   identification attributes are permitted, as well as Service-Type,
   Nonce and State attributes.  If other attributes are included in such
   a CoA-Request, implementations MUST send a CoA-NAK; an Error-Cause
   Attribute with value "Unsupported Attribute" MAY be included.

   A Disconnect-Request MUST contain only NAS and session identification
   attributes (see Section 3), as well as Service-Type, Nonce and State
   attributes.  If other attributes are included in  a Disconnect-
   Request, implementations MUST send a Disconnect-NAK; an Error-Cause
   Attribute with value "Unsupported Attribute" MAY be included."

--------------------------------------------------------
Issue 163: Vendor-Specific Attribute with "Authorize-Only" Service-Type
Submitter names: Steven Xu
Submitter email address: [email-masked]
Date first submitted: January 20, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00034.html
Document: FIXES-01
Comment type: 'T'echnical |
Priority: S
Section: Various
Rationale/Explanation of issue:

I am looking for a clarification on "Vendor-Specific" attribute in 
Disconnect-Request when it is used for "Authorize Only".
 
In RFC3576 section 3.2, there is no Note for "Vendor-Specific" in Disconnect 
Request. (There is Note 3 for the COA). So when the Service-Type is 
"Authorize Only" in Disconnect-Request, can it have the Vendor-Specific 
attribute? The Note 3 says NO, but it is not added for DM.

--
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, 24 Nov 2006 07:15:31 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Proposed Resolution to RFC 3576bis Issue 161: Authorize-Only Service-Type
Date: Thu, 23 Nov 2006 23:14:59 -0800

The text of Issue 161 is enclosed below.  The proposed resolution is as 
follows:

Add Section 3.1:

"3.1.  State

   [RFC2865] Section 5.44 states:

      An Access-Request MUST contain either a User-Password or a CHAP-
      Password or State.  An Access-Request MUST NOT contain both a
      User-Password and a CHAP-Password.  If future extensions allow
      other kinds of authentication information to be conveyed, the
      attribute for that can be used in an Access-Request instead of
      User-Password or CHAP-Password.

   In order to satisfy the requirements of [RFC2865] Section 5.44, an
   Access-Request with Service-Type="Authorize-Only" MUST contain a
   State attribute.

   In order to provide a State attribute to the NAS, a server sending a
   CoA-Request or Disconnect-Request with a Service-Type value of
   "Authorize-Only" MUST include a State Attribute, and the NAS MUST
   include the State Attribute unchanged in the Access-Request.  A NAS
   receiving a Disconnect or CoA-Request containing a Service-Type value
   of "Authorize-Only" but lacking a State attribute MUST send a
   Disconnect or CoA-NAK and SHOULD include an Error-Cause attribute
   with value 402 (Missing Attribute)."

In Section 3.5, change Note 6 to the following:

"   [Note 6] When included within a Disconnect-Request or CoA-Request, a
   Service-Type Attribute with value "Authorize Only" indicates that the
   Request only contains NAS and session identification attributes, and
   that the NAS should attempt reauthorization by sending an Access-
   Request with a Service-Type Attribute with value "Authorize Only".
   This enables a usage model akin to that supported in Diameter, thus
   easing translation between the two protocols.  Support for the
   Service-Type Attribute is optional within CoA-Request and Disconnect-
   Request messages; where it is not included, the Request message may
   contain both identification and authorization attributes.  A NAS that
   does not support the Service-Type Attribute with the value "Authorize
   Only" within a Disconnect-Request MUST respond with a Disconnect-NAK
   including no Service-Type Attribute; an Error-Cause Attribute with
   value "Unsupported Service" MAY be included.  A NAS that does not
   support the Service-Type Attribute with the value "Authorize Only"
   within a CoA-Request MUST respond with a CoA-NAK including no
   Service-Type Attribute; an Error-Cause Attribute with value
   "Unsupported Service" MAY be included.

   A NAS supporting the "Authorize Only" Service-Type value within
   Disconnect-Request or CoA-Request messages MUST respond with a
   Disconnect-NAK or CoA-NAK respectively, containing a Service-Type
   Attribute with value "Authorize Only", and an Error-Cause Attribute
   with value "Request Initiated".  The NAS then sends an Access-Request
   to the RADIUS server with a Service-Type Attribute with value
   "Authorize Only".  This Access-Request SHOULD contain the NAS
   attributes from the Disconnect or CoA-Request, as well as the session
   attributes from the Request legal for inclusion in an Access-Request
   as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162].  As
   noted in [RFC2869] Section 5.19, a Message-Authenticator attribute
   SHOULD be included in an Access-Request that does not contain a User-
   Password, CHAP-Password, ARAP-Password or EAP-Message Attribute.  The
   RADIUS server should send back an Access-Accept to (re-)authorize the
   session or an Access-Reject to refuse to (re-)authorize it."

------------------------------------------------------------------------------------------------------------
Issue 161: Authorize-Only Service-Type
Submitter name: Joe Urbasik
Submitter email address: [email-masked]
Date first submitted: January 12, 2006
Reference: http://ops.ietf.org/lists/radiusext/2006/msg00030.html
Document: FIXES-01
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

I am looking at implementing a server for the protocol in RFC 3576, and I
have a few questions regarding the "Authorize-only" Service-type.

I have looked through the archives for this list, and have also browsed RFC
2865 and 4005, in trying to find answers.

RFC 3576 requires a conforming implementation to respond to a DM or CoA
request with Service-type Authoize-only with a NAK to the Initial Request,
followed by a RADIUS Access-request. I understand from the description in
RFC 3576 that this Access-request is meant to trigger a "reauthorization".

I am trying to understand this part of the protocol, in the case where the
Initial request is generated from a Radius server, as opposed to a
Radius/Diameter gateway.

I have these two general questions:

1a. What is the usage scenario for this feature, from a network management
perspective ?

I know the RFC says that "This enables a usage model akin to that supported
in Diameter, thus easing translation between the two protocols". but I am
not so familiar with Diameter, and I do not understand what the need is for
this feature - is this strictly for forward compatibility with Diameter ?

1b. What is the usage scenario, with radius servers ? (This may be the same
question from another perspective, but in case it isn't) :

>From the point of view of someone wanting to enhance a radius server, what
is the need or attraction for implementing/issuing the "Authorize-only"
requests within this protocol ?

2. The RFC states that the Radius Access-request is to be sent by the
RFC3576 Server. Implicit in this is that the RFC3576 server will get a
response - is it expected to act on that response message ?

Can the sending of the Access Request be performed by a different server
process, or must the Request come from the same process (or port) that
received the initial Authorize-only request, and that issued the NAK ? In
other words, is the Radius Server maintaining some sort of state between the
two messages ?

I also have 2 specific technical questions

1. I have assumed that the values for the Attributes are to be taken from
RFC 2865, yet in that RFC, "Service-type" has defined the value
"Authenticate-only", not "Authorize-only"

2. Regarding permitted attributes, the paragraph at the top of page 13 says:

   Where a Service-Type Attribute with value "Authorize Only" is
   included within a CoA-Request or Disconnect-Request, attributes
   representing an authorization change MUST NOT be included; only
   identification attributes are permitted.  If attributes other than
   NAS or session identification attributes are included in such a CoA-
   Request, implementations MUST send a CoA-NAK;

My interpretation of this statement is that only the (3) "NAS identification
attributes" and (12) "Session identification attributes", as listed at the
start of section 3, MAY be in the message. However that interpretation
excludes Service-type (trivial) and State (less trivial - see [Note 7] ).

Have I misinterpreted the paragraph, or are those actually the exceptions ?

[Bernard Aboba]

RFC 3576 Section 4 allocates the "Authorize-Only" Service-Type value.

My take is that a State attribute is permited in a CoA/Disconnect-Request 
with Service-Type=Authorize-Only", and in fact RFC 2865 Section 4.1 suggests 
that it is required:

     An Access-Request MUST contain either a User-Password or a CHAP-
     Password or a State.

The RFC 3576 "Authorize-Only" Service-Type was originally created for the 
purpose of Diameter compatibility. However, Diameter compatibility issues 
only arise with the CoA-Request, and never with the Disconnect-Request. This 
is because a Disconnect-Request can always be handled as a single 
request/response sequence either in Diameter or RADIUS so it should never be 
necessary to include a Service-Type="Authorize-Only" within a 
Disconnect-Request.

Since a Diameter disconnect request will always generate an immediate 
response, and never another access request, including 
Service-Type="Authorize-Only" in a RADIUS Disconnect-Request can cause 
problems with Diameter compatibility, rather than enhancing it.

There are situations in which include a Service-Type="Authorize-Only" 
attribute in a RADIUS CoA-Request makes sense. This can happen in situations 
where it is necessary to change an attribute which could potentially be 
interpretted as a session identification attribute. This is the "semantic 
ambiguity" problem described in RFC 3576. There are also situations in which 
this is needed for Diameter compatibility. For example, if there is a RADIUS 
client/NAS interacting with a Diameter Server, then it is possible that a 
Diameter change-of-authorization request will not be easily translatable to 
a standard RADIUS CoA-Request without use of Service-Type="Authorize-Only".

A number of issues can arise with respect to processing of an 
"Authorize-Only" Disconnect or CoA-Request:

a. Which RADIUS server to respond to. While the CoA-NAK needs to be sent to 
the entity that sent the CoA-Request, it is not entirely clear who the 
Access-Request is to be sent to. A RADIUS client is typically configured 
with one or more RADIUS servers, but the CoA-Request might have been sent by 
a different entity. As a result, it is possible that the Access-Request will 
go to a different server than the one that sent the CoA-Request.

b. Security problems. The RFC 2865 Section 4.1 text suggests that RADIUS 
requires Access-Request messages to contain either an authentication 
attribute or a state attribute. Since "Authorize-Only" messages do not 
contain an authentication attribute, the only alternative is to include a 
State attribute, which presumably needs to be obtained from the CoA or 
Disconnect-Request. This is why I believe that the State attribute needs to 
be allowed; there may even by RADIUS servers that will reject the 
Access-Request unless it is included.

However, since the State attribute typically can only be interpretted 
locally, it may not be interprettable by a server other than the one that 
originated the CoA or Disconnect-Request, so if the Access-Request goes to a 
different server interoperability problems can result.

Therefore while there is no RFC 3576 requirement that the same process 
generating the Disconnect or CoA-NAK also generate the Access-Request, this 
might in fact be a good idea, since it could help guarantee that the 
Access-Request goes back to the same entity that sent the 
CoA/Disconnect-Request.

--
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, 24 Nov 2006 07:07:04 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Proposed Resolution to RFC 3576bis Issue 139:  Nonce Attribute
Date: Thu, 23 Nov 2006 23:06:26 -0800

The text of Issue 139 is enclosed below.  The proposed resolution is as 
follows:

Add the following text to Section 1.1:

"  Existing implementations lack replay protection.  In order to support
   replay detection, it is recommended that a Nonce or Event-Timestamp
   Attribute be added to all messages in situations where IPsec replay
   protection is not employed.  See Section 6.4 for details."

Change the last two paragraphs of Section 3 to the following:

"   Where a Service-Type Attribute with value "Authorize Only" is
   included within a CoA-Request, attributes representing an
   authorization change MUST NOT be included; only NAS or session
   identification attributes are permitted, as well as Service-Type,
   Nonce and State attributes.  If other attributes are included in such
   a CoA-Request, implementations MUST send a CoA-NAK; an Error-Cause
   Attribute with value "Unsupported Attribute" MAY be included.

   A Disconnect-Request MUST contain only NAS and session identification
   attributes (see Section 3), as well as Service-Type, Nonce and State
   attributes.  If other attributes are included in  a Disconnect-
   Request, implementations MUST send a Disconnect-NAK; an Error-Cause
   Attribute with value "Unsupported Attribute" MAY be included."

Add Section 3.2:

"3.3.  Nonce

   Description

      Since the Request Authenticator field within CoA-Request
      Disconnect-Request packets does not contain a nonce, these packets
      are vulnerable to replay attack without the countermeasures
      described in Section 6.4.  As noted in Section 6.4, replay attacks
      can be addressed by using IPsec to protect RADIUS or by adding an
      Event-Timestamp attribute to CoA and Disconnect-Request packets.
      Since use of the Event-Timestamp Attribute requires time
      synchronization, where this is not possible an alternative replay
      protection mechanism is required.  For this purpose, a Nonce
      Attribute MAY be included within CoA-Request, Disconnect-Request,
      and Accounting-Request packets.

      A summary of the Nonce Attribute format is shown below.  The
      fields are transmitted from left to right.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |             Value
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Value (cont)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      TBD for Nonce

   Length

      6

   Value

      The Value field is four octets, containing a randomly chosen value
      [RFC4086]."

Add the following entries to the Attribute Table (Section 3.5) for both 
Disconnect and CoA messages:

"   0-1       0-1      0-1 TBD   Nonce [Note 8]

   [Note 8] A Nonce Attribute SHOULD be included in a CoA-Request or
   Disconnect-Request packet that is not protected by IPsec or does not
   contain an Event-Timestamp Attribute, so as to prevent replay
   attacks.  A Nonce Attribute MAY also be included in CoA-ACK, CoA-NAK,
   Disconnect-ACK, Disconnect-NAK, or Accounting-Request packets."

--------------------------------------------------------------------------------------------------------------
Issue 139: Nonce Attribute
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: October 10, 2005
Reference:
Document: RFC3576bis-00
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
It has been pointed out that the replay protection mechanisms
recommended in RFC 3576 may be difficult to deploy.

For example, the Event-Timestamp attribute requires time synchronization
between the RADIUS server and NAS. In roaming situations this would
require all networks between the RADIUS server and NAS to be running
NTP, synchronized to the same clock.

Similarly, IPsec with replay protection may not be deployable on all
hops in the path.

To provide more deployable replay protection it has been suggested that
a Nonce attribute be introduced. This attribute would be sent by the DAC
in a CoA/Disconnect-Request. If the DAS understands the attribute it would
be copied into the CoA/Disconnect ACK/NAK (possibly along with another
Nonce-attribute inserted by the DAS).

The Nonce attribute could also be used to enhance replay protection
in Accounting-Request packets. Since the receiver of the packet
with a Nonce attribute doesn't need to understand it, this attribute
is backward compatible with existing RFC 3576 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: Fri, 24 Nov 2006 06:58:09 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RFC 3576bis Issue 207: Diameter considerations Section
Date: Thu, 23 Nov 2006 22:57:38 -0800

Issue 207: Diameter Considerations Section
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: November 23, 2006
Reference:
Document: RFC 3576bis
Comment type: Technical
Priority: S
Section: 4
Rationale/Explanation of issue:

RFC 3576bis has no Diameter Considerations section.

The proposed resolution is to add a Section 4 as follows:

"4.  Diameter Considerations

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

   To simplify translation between RADIUS and Diameter, a server
   compliant with this specification MAY include a Service-Type
   Attribute with value "Authorize Only" within a CoA-Request.  Such a
   CoA-Request MUST contain a State Attribute.  A NAS supporting the
   "Authorize Only" Service-Type within a CoA-Request responds with a
   CoA-NAK containing a Service-Type Attribute with value "Authorize
   Only", and an Error-Cause Attribute with value "Request Initiated".
   The NAS will then send an Access-Request containing a Service-Type
   Attribute with a value of "Authorize Only", along with a State
   Attribute.  A Diameter/RADIUS gateway receiving a CoA-Request
   containing a Service-Type with value "Authorize Only" translates this
   to a RAR with Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY".
   The received RAA is then translated to a CoA-NAK with a Service-Type
   value of "Authorize Only".   If the Result-Code AVP in the RAA has a
   value in the success category, then an Error-Cause Attribute with
   value "Request Initiated" is included in the CoA-NAK.   If the
   Result-Code AVP in the RAA has a value indicating a Protocol Error or
   a Transient or Permanent Failure, then an alternate Error-Cause
   Attribute is returned as suggested below.

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

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

   Suggested translations between Error-Cause Attribute values and
   Result-Code AVP values are included below:

    #    Error-Cause Attribute Value   Result-Code AVP
   ---   ---------------------------  ------------------------
   201   Residual Session Context     DIAMETER_SUCCESS
         Removed
   202   Invalid EAP Packet           DIAMETER_LIMITED_SUCCESS
         (Ignored)
   401   Unsupported Attribute        DIAMETER_AVP_UNSUPPORTED
   402   Missing Attribute            DIAMETER_MISSING_AVP
   403   NAS Identification           DIAMETER_REALM_NOT_SERVED
         Mismatch
   404   Invalid Request              DIAMETER_UNABLE_TO_COMPLY
   405   Unsupported Service          DIAMETER_COMMAND_UNSUPPORTED
   406   Unsupported Extension        DIAMETER_APPLICATION_UNSUPPORTED
   501   Administratively             DIAMETER_AUTHORIZATION_REJECTED
         Prohibited
   502   Request Not Routable         DIAMETER_UNABLE_TO_DELIVER
         (Proxy)
   503   Session Context Not Found    DIAMETER_UNKNOWN_SESSION_ID
   504   Session Context Not          DIAMETER_AUTHORIZATION_REJECTED
         Removable
   505   Other Proxy Processing       DIAMETER_UNABLE_TO_COMPLY
         Error
  506   Resources Unavailable        DIAMETER_RESOURCES_EXCEEDED
   507   Request Initiated            DIAMETER_SUCCESS

   Since both the ASR/ASA and Disconnect-Request/Disconnect-
   NAK/Disconnect-ACK exchanges involve just a request and response,
   inclusion of an "Authorize Only" Service-Type within a Disconnect-
   Request is not needed to assist in Diameter/RADIUS translation, and
   may make translation more difficult.  As a result, inclusion of a
   Service-Type of "Authorize Only" within a Disconnect-Request is NOT
   RECOMMENDED."

--
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, 24 Nov 2006 06:46:26 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Proposed Resolution to RFC 3576bis Issue 132: Must Proxy-State be Copied by NAS?
Date: Thu, 23 Nov 2006 22:45:57 -0800

The text of issue 132 is enclosed below.  The proposed resolution is to add 
the following text to Section 3.2:

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

      A forwarding proxy MUST NOT modify existing Proxy-State, State, or
      Class Attributes present in the packet.  The forwarding proxy 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."

------------------------------------------------------------------------------------------------------------------------
Issue 132: Must Proxy-State be Copied by the NAS?
Submitter name: Jim Martin
Submitter email address: [email-masked]
Date first submitted: September 12, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00841.html
Document: RFC3576bis
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

I have a question regarding RFC3576, specifically the behavior
of the Proxy-State attribute when contained in a Disconnect Message.
Fundamentally, the question is, if a Disconnect-Request is received
by a NAS which contains a Proxy-State, MUST the NAS copy this Proxy-
State into the associated Disconnect-Response?

While there is no /explicit/ statement that says "Proxy-state
must be preserved by the client receiving the Disconnect-Request",
there are a couple of places where it is clearly implied.

First in section 2.3, in discussing the behavior of forwarding
proxies with respect to these messages, it says:
When using a forwarding proxy, the proxy must be able to alter the
packet as it passes through in each direction. When the proxy
forwards a Disconnect or CoA-Request, it MAY add a Proxy-State
Attribute, and when the proxy forwards a response, it MUST remove
its Proxy-State Attribute if it added one. Proxy-State is always
added or removed after any other Proxy-States, but no other
assumptions regarding its location within the list of Attributes
can be made. 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. A forwarding proxy MUST NOT modify existing Proxy-
State, State, or Class Attributes present in the packet.

To me, this seems a clear implication that the NAS would include the
proxy-state in the response, and hence the need for text to specify
that it must be removed by the proxy. This is further supported by
the following excerpt from the table in Section 3.2:

Disconnect Messages

Request      ACK      NAK      #      Attribute
[text deleted]
0+           0+       0+       33     Proxy-State

Do you (jointly or severally) agree with my assessment?
Clarification would be very helpful.

[Emile Bergen]
I completely agree -- the NAS has server role in this exchange, and just
like Proxy-State MUST be echoed by the server for Access-Request and
Accounting-Request packets, it MUST be echoed by the NAS for
Disconnect-Request (and other RFC3576 messages where the NAS functions
as the server), for exactly the same reasons.

The situation seems quite symmetrical to me.

--
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, 24 Nov 2006 06:41:14 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Proposed Resolution to RFC 3576bis Issue 88:  VSAs for Session Identification
Date: Thu, 23 Nov 2006 22:40:43 -0800

The text of Issue 88 s enclosed below.    The proposed resolution is to 
reject the proposed change.

It can probably be argued that RFC 3576 already allows too many session
identification attributes.  For example, in Diameter a RAR requires
a Session-ID AVP (equivalent to Acct-Session-Id) and also allows
a User-Name AVP, but that is it.

If a CoA-Request doesn't include an Account-Session-Id attribute, then
it cannot be easily translated to a Diameter RAR.  If only a User-Name
attribute is included and the user is connected on multiple ports, the
semantics of a Disconnect or CoA-Request is not defined.  In retrospect,
this is probably an argument for making the Acct-Session-Id attribute
mandatory in a CoA-Request or Disconnect-Request, at least in situations
where the intent is to affect a single session.

There would appear to be several issues with enabling use of VSAs
for identification purposes in CoA or Disconnect-Request packets:

1. Since Diameter does not enable use of VSAs for identification within
a RAR or ASR, use of VSAs for identification in a Disconnect or CoA-Request
would seem to be untranslatable within a Diameter/RADIUS gateway.

2. Currently VSAs are assumed to represent authorization changes
within a CoA-Request.  If some VSAs were to represent identification
attributes, and some were to represent authorization changes, then a
NAS would need to keep track of which VSAs were used for which
purposes, for all potential VSAs that it could support.  This seems
like it could dramatically increase implementation complexity.

In this case, the potential downside (difficulties in RADIUs/Diameter
translation, implementation complexity) seems to outweigh the potential
benefits (increased flexibility in session identification.

----------------------------------------------------------------------------------------------------------
Issue 88: VSAs for Session-Identification
Submitter name: Murtaza Chiba
Submitter email address: [email-masked]
Date first submitted: April 28, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00405.html
Document: RFC3576bis
Comment type: T
Priority: 1
Section: 3
Rationale/Explanation of issue:

Some VSAs could be used for Session-Identification in addition to any 
authorization purpose.

In section 3 under Session Identification attributes, Vendor-Specific
attributes are not mentioned. This should be left to a vendor to decide
which attributes designate session identification and which designate
authorization in the case where ambiguity is clearly eliminated.
That is a subtype and/or contents readily distinguish between session
identification and authorization.

Also in section 3.3 Note 3 mentions that the VSA is only for authorization.
This too should be changed to allow for session identification.

Requested change:

Section 3:

Please add VSA to the list under "Session identification attributes" the 
following text
Vendor-Specific    26   [RFC2865]  The Vendor Specific attribute used
                                   for Session Identification purposes.

Section 3.3:
Modify note 3. from

"When included within a CoA-Request, these attributes
represent an authorization change request"

to

"When included within a CoA-Request, these attributes MAY represent an 
authorization change requests"

--
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, 24 Nov 2006 06:17:39 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Proposed Resolution to RFC 3576bis Issue 55: Message-Authenticator Attribute
Date: Thu, 23 Nov 2006 22:16:18 -0800

The text of Issue 55 is enclosed below.  The basic problem is that the lack 
of a nonce in the Request Authenticator of the CoA or Disconnect-Request 
presents a chicken-egg issue.   The Message-Authenticator attribute depends 
on the RA and the RA depends on the  Message-Authenticator.

The issue could be solved either by prohibiting inclusion of the 
Message-Authenticator in CoA or Disconnect-Request or Response messages.   
It can also be fixed by having the Message-Authenticator be calculated based 
on assuming that the RA and Message-Authenticator attribute consisted of all 
zeroes.  The RA could then be calculated based on the actual 
Message-Authenticator attribute.

Given the potential weakness of the keyed MD5 construction used to calculate 
the Request and Response Authenticator field, enabling use of the 
Message-Authenticator Attribute seems like the better choice for now.

The proposed resolution is as follows:

Leave the entries in the attribute table for Message-Authenticator as "0-1".

Add Section 3.2:

"3.2.  Message-Authenticator

   The Message-Authenticator Attribute MAY be used to authenticate and
   integrity-protect Disconnect/CoA-Request, ACK and NAK packets in
   order to prevent spoofing.

   A RADIUS client receiving a CoA or Disconnect-Request with a Message-
   Authenticator Attribute present MUST calculate the correct value of
   the Message-Authenticator and silently discard the packet if it does
   not match the value sent.  A RADIUS server receiving a
   CoA/Disconnect-ACK or CoA/Disconnect-NAK with a Message-Authenticator
   Attribute present MUST calculate the correct value of the Message-
   Authenticator and silently discard the packet if it does not match
   the value sent.

   When a Message-Authenticator Attribute is included within a CoA or
   Disconnect-Request, it is calculated as follows:

      Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
      Request Authenticator, Attributes)

      When the HMAC-MD5 message integrity check is calculated the
      Request Authenticator field and Message-Authenticator Attribute
      should be considered to be sixteen octets of zero.  The Message-
      Authenticator Attribute is calculated and inserted in the packet
      before the Request Authenticator is calculated.

      When a Message-Authenticator Attribute is included within a CoA or
      Disconnect-ACK/NAK, it is calculated as follows:

         Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
         Request Authenticator, Attributes)

      When the HMAC-MD5 message integrity check is calculated the
      Message-Authenticator Attribute should be considered to be sixteen
      octets of zero.  The Request Authenticator is taken from the
      corresponding CoA/Disconnect-Request.  The Message-Authenticator
      is calculated and inserted in the packet before the Response
      Authenticator is calculated."

-------------------------------------------------------------------------------------------------------------------------
Issue 55: Message-Authenticator Attribute
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: January 28, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00082.html
Document: RFC 3576bis
Comment type: T
Priority: S
Section: 3.2
Rationale/Explanation of issue:

RFC 3576 calculation of the Request and Response Authenticator is modeled
after RFC 2866 (RADIUS Accounting).  However, the Message-Authenticator
attribute is not allowed in Accounting-Request and Accounting-Response
messages, because these messages do not contain a random Request
Authenticator, as specified in RFC 3579:

      Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
      Request Authenticator, Attributes)

It therefore would appear that a Message-Authenticator attribute is not
allowed in CoA-Request, CoA-ACK, CoA-NAK, Disconnect-Request,
Disconnect-ACK or Disconnect-NAK messages.

This is contrary to the table in Section 3.2, which has the following
entry for both CoA and Disconnect messages:

   Request   ACK      NAK   #   Attribute
   0-1       0-1      0-1  80   Message-Authenticator

Proposed Resolution:

My proposal is that we submit an errata to RFC 3576, changing the "0-1"
entries to "0" entries.

[John Loughney]
I agree with your proposal.

[Murtaza Chiba]
Sounds good. Somewhat related, there are Vendor attributes that are 
encrypted,
although we want to discourage per attribute encryption, the fact of the 
matter
is that Customers are using it. So I would like to request a new attribute
Initialization-Vector that can be used for all encrypted attributes in CoA
and Disconnect Messages.

[Bernard Aboba]
In looking through the Attribute table in RFC 3576, Section 3.2, there
appears to be two attributes that depend on the Request Authenticator:
Message-Authenticator (80), and Tunnel-Password (69).

If the desire were to change the value of the Tunnel-Password attribute or
any other attribute depending on the Request Authenticator, one way to
get around the chicken-egg problem would be to send a CoA-Request
with Service-Type="Authorize Only".  The encrypted attribute would not need 
to
be present in the CoA-Request, but could then be present in a subsequent
Access-Accept, using the existing attribute definitions.

It would therefore appear to me that the Tunnel-Password attribute should
probably also have a "0" for its entries in the table in Section 3.2,
instead of "0-1".

Defining a new Nonce attribute, and then re-defining existing
IETF standard attributes to use it when present in a CoA-Request seems
somewhat problematic to me.

[Glen Zorn]
The word "random" is not present in RFC 3579; therefore it's hard to
see how one can claim that a random Request Authenticator is
"specified" thereby.  Maybe a better phrase would be "tacitly
assumed by the authors"?  In any case, however, I agree that the use
of the accounting-style Request Authenticator in the generation of
the Message-Authenticator Attribute is probably inappropriate.
Given the existence of the above-mentioned and undocumented
assumption in RFC 3579 and the effect that the absence of the
Message-Authenticator Attribute on the already less-than-stellar
security properties of RFC 3576, I think that more than just a
change in a table is required.  For example, the usage of the
Event-Timestamp for replay detection in 3576 would seem to be
weakened.  I really think that the assumption in RFC 3579 needs to
be laid bare; I'm not sure whether an erratum is sufficient for this
or if an applicability statement needs to be published.

[Bernard Aboba]
The term is used in RFC 2865, though.  For example, in Section 5.2:

      Call the shared secret S and the pseudo-random 128-bit Request
      Authenticator RA.

In this particular case, I think the issue was not so much whether the
Request Authenticator from RFC 2866 is pseudo-random but rather the
circular dependency:  Message-Authenticator, Tunnel-Password, etc. depend
on the RA, but the RA depends on the attributes.

If the issue were merely pseudo-randomness, then perhaps it might be
solved by including a pseudo-random attribute (e.g. a Nonce) in the
Request, in order to introduce entropy into the calculated RA.

>For example, the usage of the
>Event-Timestamp for replay detection in 3576 would seem to be
>weakened.

Can you elaborate?  Is this because the RA calculation involves MD5,
rather than HMAC-MD5?  From RFC 2866:

      The NAS and RADIUS accounting server share a secret.  The Request
      Authenticator field in Accounting-Request packets contains a one-
      way MD5 hash calculated over a stream of octets consisting of the
      Code + Identifier + Length + 16 zero octets + request attributes +
      shared secret (where + indicates concatenation).  The 16 octet MD5
      hash value is stored in the Authenticator field of the
      Accounting-Request packet.

>I really think that the assumption in RFC 3579 needs to
>be laid bare; I'm not sure whether an erratum is sufficient for this
>or if an applicability statement needs to be published.

I'm not sure how RFC 3579 comes into play here, since it only
defines usage of Message-Authenticator in
Access-Request, Challenge, Accept and Reject packets, not in
Accounting-Request/Response or CoA/Disconnect messages.
Here is the text from Section 3.2:

      When present in an Access-Request packet, Message-Authenticator is
      an HMAC-MD5 [RFC2104] hash of the entire Access-Request packet,
      including Type, ID, Length and Authenticator, using the shared
      secret as the key, as follows.

      Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
      Request Authenticator, Attributes)

      When the message integrity check is calculated the signature
      string should be considered to be sixteen octets of zero.

      For Access-Challenge, Access-Accept, and Access-Reject packets,
      the Message-Authenticator is calculated as follows, using the
      Request-Authenticator from the Access-Request this packet is in
      reply to:

      Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
      Request Authenticator, Attributes)

      When the message integrity check is calculated the signature
      string should be considered to be sixteen octets of zero.  The
      shared secret is used as the key for the HMAC-MD5 message
      integrity check.  The Message-Authenticator is calculated and
      inserted in the packet before the Response Authenticator is
      calculated.

--
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, 24 Nov 2006 01:39:50 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Comments from the editor of RFC 4005 on Filter-Id & NAS-Filter-Rule (fwd)
Date: Thu, 23 Nov 2006 17:38:35 -0800

RFC 4005 recommends that the NAS-Filter-Rule AVP be used instead of the 
Filter-Id AVP, but does not require this.  Below, David Mitton, editor of 
RFC 4005, comments on the thinking behind the RFC 4005 text.

-----------------------------------------------
Date: Tue, 21 Nov 2006 10:04:46 -0500
From: David Mitton <[email-masked]>
To: Bernard Aboba <[email-masked]>
Subject: Re: Inclusion of Filter-Id and NAS-Filter-Rule AVPs

I'm not sure I have much enlightenment to spread here, but I
might have a clue on the orginal motivation.

        Comments embedded below....

Dave.

>RFC 4005 Section 6.7 states the following with respect to the Filter-Id
>AVP:
>
>    In non-RADIUS environments, it is RECOMMENDED that the NAS-Filter-
>    Rule AVP be used instead.
>
>However, since this is a recommendation, it appears possible that an RFC
>4005 implementation could send a NAS-Filter-Rule AVP along with a
>Filter-Id AVP.  Based on the current text in the NAS-Filter-Rule document, 
>such a message would not be translatable to an equivalent RADIUS packet.

At the time of RFC 4005 authoring, the NAS-Filter-Rule AVP was not 
expressable as a RADIUS attribute, as it has the Diameter AVP code of 400.  
So I doubt that combining the two was intended. Given the current lack of 
enthusiasm for mapping Diameter into RADIUS, that still may be the case.

>Some questions:
>
>a. Do you, the esteemed author of RFC 4005 have an opinion on the
>appropriate normative language for the Section 2 text above?  For
>example, is the "MUST NOT" too strict?

I think it depends on the next issue.  If this technique is now officially 
frowned on, then it's probably not too strict.

>b. Is there a situation in which both the NAS-Filter-Rule and Filter-Id 
>AVPs will need to be sent in a >Diameter message?

I suspect that we (some?) believed that some servers might send both, and if 
the message was headed to an older system, a gateway would strip the 
NAS-Filter-Rule but take the Filter-ID.  Of course this supposes that the 
Diameter system would have a defined behavior for both the Filter-ID and
Filter-Rule.

>c. If such a situation exists, how is a NAS to interpret such a message?
>Does one AVP take precedence?  Or are the AVPs combined somehow?

This is an area where there is a total lack of vendor standardization.   The 
Xylogics Annex had a filtering command system unlike anything Cisco, Ascend, 
or 3Com had at the time.

Rules typically have some sort of sequential processing assumptions, and to 
try to combine a predefined set (the Filter-ID definition) with another set 
(the Filter-Rules) it could be problematic.

But the implementor of the new standard rules would have to deal with the 
native interface somewhere during implementation anyways.

So I think any assumption of combining both was not an expectation.  
However, this problem could be left to the system operator given his 
configuration & equipment capabilities to decide.  So, that may be why there 
is a lack of totally restrictive language.

I think the original intent was to define a new common Filter-Rule for 
Diameter native systems (something we have not had in the past), while 
accommodating RADIUS standard attributes and practice.   Diameter systems 
must define how they want to interpret this situation, since it is clearly 
allowed.  It this attribute is also to be implemented in the RADIUS space, 
then they have the same problem.

Sigh... this is another problem where some sort of NAS version number or 
capabilities field would be useful. I guess the best compromise would be to 
continue to allow them to be sent together.
An older system would ignore the new rule and use the Filter-ID. A newer 
system would use the new rules (if present) and either ignore the Filter-ID 
or have it defined as a Non-operation.  The provisioning of the rules behind 
a Filter-ID are still not defined.

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: Mon, 20 Nov 2006 20:12:47 +0000
Date: Mon, 20 Nov 2006 12:11:25 -0800
From: "Sean Convery" <[email-masked]>
To: [email-masked]
Subject: Issue: draft-ietf-radext-filter-05.txt

Description of issue: Add Reference to RFC 3588
Submitter name: Sean Convery
Submitter email address: [email-masked]
Date first submitted: 11/20/06
Reference: none
Document: draft-ietf-radext-filter-05.txt
Comment type: E
Priority: 2
Section: 1
Rationale/Explanation of issue:

For those uninitiated in the specifics of Diameter's document
architecture, it may be useful to add a reference to RFC3588 in the
introduction to this document (in addition to the reference in section
2). Just looking at RFC 4005 doesn't provide you the formatting of the
filter itself. Suggested rewording for section 1, paragraph 1:

This document defines the NAS-Filter-Rule attribute within the Remote
Authentication Dialin User Service (RADIUS). This attribute has the
same functionality as the Diameter NAS-Filter-Rule AVP (400) defined
in [RFC4005] Section 6.6 and the same syntax as an IPFilterRule
defined in [RFC3588] Section 4.3.  This attribute may prove useful for
provisioning of filter rules.

This is great functionality, I hope the major vendors implement it.

Thanks,

Sean

--
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, 11 Nov 2006 15:46:36 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue on filter-rules-01
Date: Sat, 11 Nov 2006 10:42:30 -0500
From: "Nelson, David" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>, <[email-masked]>

Bernard writes...

> Maybe they both should be "SHOULD NOT be sent".  That way if a 
> Diameter gateway sends both they will both be passed through to
>  RADIUS.

I think it ought to be MUST NOT.  I think the Diameter specification is defective in that it allows both kinds of filtering attributes, but fails to specify how to correctly apply them (i.e. a precedence order) so as to allow interoperability.  I recommend that we not compound that error in this draft.

--
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, 10 Nov 2006 18:53:05 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue on filter-rules-01
Date: Fri, 10 Nov 2006 19:52:40 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

I would be very fine with "SHOULD NOT" in both drafts. I was just in
an impression after the RADEXT meeting that "MUST NOT" was preferred.

Cheers,
	Jouni 

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: 10. marraskuuta 2006 20:26
> To: Korhonen, Jouni /TeliaSonera Finland Oyj; [email-masked]
> Subject: RE: Issue on filter-rules-01
> 
> Maybe they both should be "SHOULD NOT be sent".  That way if 
> a Diameter gateway sends both they will both be passed 
> through to RADIUS.
> 
> 
> >From: <[email-masked]>
> >To: <[email-masked]>
> >Subject: Issue on filter-rules-01
> >Date: Fri, 10 Nov 2006 19:17:44 +0100
> >
> >Hi,
> >
> >In section 2.5 there's the following text:
> >
> >          Filter-ID (11) and NAS-Traffic-Rule both define 
> how filters are
> >
> >          to be applied in the NAS. These attributes are not 
> intended to
> >          be used concurrently and SHOULD NOT appear in the 
> same RADIUS
> >          message. Only one type of filtering attribute must be
> >          processed. If a Filter-ID (11) is present, then the NAS-
> >          Traffic-Rule MUST be ignored, if present.
> >
> >I think this text should be align with the equivalent text in
> >the radext-filter-05 draft. So the text saying
> >   "..SHOULD NOT appear in the same RADIUS message." should be
> >   "..MUST NOT appear in the same RADIUS packet." right?
> >
> >Cheers,
> >	Jouni
> >
> >--
> >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, 10 Nov 2006 18:26:36 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Issue on filter-rules-01
Date: Fri, 10 Nov 2006 10:26:21 -0800

Maybe they both should be "SHOULD NOT be sent".  That way if a Diameter 
gateway sends both they will both be passed through to RADIUS.

>From: <[email-masked]>
>To: <[email-masked]>
>Subject: Issue on filter-rules-01
>Date: Fri, 10 Nov 2006 19:17:44 +0100
>
>Hi,
>
>In section 2.5 there's the following text:
>
>          Filter-ID (11) and NAS-Traffic-Rule both define how filters are
>
>          to be applied in the NAS. These attributes are not intended to
>          be used concurrently and SHOULD NOT appear in the same RADIUS
>          message. Only one type of filtering attribute must be
>          processed. If a Filter-ID (11) is present, then the NAS-
>          Traffic-Rule MUST be ignored, if present.
>
>I think this text should be align with the equivalent text in
>the radext-filter-05 draft. So the text saying
>   "..SHOULD NOT appear in the same RADIUS message." should be
>   "..MUST NOT appear in the same RADIUS packet." right?
>
>Cheers,
>	Jouni
>
>--
>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, 10 Nov 2006 18:18:58 +0000
Content-class: urn:content-classes:message
Subject: Issue on filter-rules-01
Date: Fri, 10 Nov 2006 19:17:44 +0100
From: <[email-masked]>
To: <[email-masked]>

Hi,

In section 2.5 there's the following text:

         Filter-ID (11) and NAS-Traffic-Rule both define how filters are

         to be applied in the NAS. These attributes are not intended to 
         be used concurrently and SHOULD NOT appear in the same RADIUS 
         message. Only one type of filtering attribute must be 
         processed. If a Filter-ID (11) is present, then the NAS-
         Traffic-Rule MUST be ignored, if present. 

I think this text should be align with the equivalent text in 
the radext-filter-05 draft. So the text saying
  "..SHOULD NOT appear in the same RADIUS message." should be
  "..MUST NOT appear in the same RADIUS packet." right?

Cheers,
	Jouni

--
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, 10 Nov 2006 18:01:52 +0000
Content-class: urn:content-classes:message
Subject: Filter-rules-01 & Issue 192
Date: Fri, 10 Nov 2006 19:01:14 +0100
From: <[email-masked]>
To: <[email-masked]>

Hi Mauricio,

Sorry for a late reply on this issue ;-) I checked the -01
version and see the responses below (marked with [JiK]).

Cheers,
	Jouni

[Mauricio Sanchez]
>  o Introduction talks about 'home realm' and in the same
>    sentence also about 'local operator'. Maybe changing
>    home realm to home operator would be better?

I'm open to this suggestion.  It does seem more succinct when the home
operator term is used.

[JiK] -01 looks better now. I would still change change the
       'local operator' to 'local visited operator'.

>  o Introduction also discusses VLANs. I think that text
>    there does not really belong to this draft anymore.

Sounds appropriate.  We'll back off the usage of VLANs as a driving use
case
and focus on what specifically drives the need for these attributes. 

[JiK] Ok.

>  o terminology section lists Authenticator, Authentication
>    Server and Supplicant even if those are not used in the
>    text outside the terminology section. Imho a reference
>    to 802.1X should be enough
>

I remember adding this terms into the terminology section after group
discussion.  I remember people wanting additional detail around this and
having only a reference to 802.1X did not seem like enough.  I'll push
back
and say that unless you really think having these terms are distraction,
then we should just leave them in. 

[JiK] Right.. I don't really mind having these terms in the terminology
      but then you better not state they are used in the document (at
      least authenticator, authentication server, supplicant..)

>  o hot-lining is also only mentioned in the terminology
>    section. Should there be some more text in the draft
>    itself about hot-lining e.g. in form of motivation for
>    this draft? Actually I would like to see a general
>    short motivation section somewhere under section 1

Hmmm, previous version talked about hotlining and people started to feel
that it was getting to be a distraction in the introduction. Elaboration
on
hotlining was cut down to what it is now. Why do you feel we need to add
more motivation based on hot-lining?

[JiK] There seems to be a bit more in appendix & example scenario.
      I'm OK with the current text.

>  o what is the purpose of the rule-delim in the
>    NAS-Traffic-Rule ABNF? As far as I interpreted the
>    ABNF there can be only one rule per attribute anyway?
>    I could be wrong ;)

The first version of the syntax had no rule delimiter and people
commented
that having a delimiter would eliminate any possibility for ambiguity of
rule end. 

[JiK] So if there can be only one rule per attribute I still don't see a
      need for rule-delim. It does not add any value imho.

>  o in the NAS-Traffic-Rule why there could not be
>     - ip-proto = ["!"] d8
>     - tcp-ports = ["!"] tcp-port *("," tcp-port)
> 
>    That would ease blocking of specific ports and 
>    protocols. E.g. in case of trying to block some
>    virus/worm generated traffic, while allowing 
>    everything else..

There no strong reason anymore why this couldn't be done.  It used to be
an
argument of remaining true to the L3-L4 capabilities specified by
Diameter's
IPFilterRule to facilitate translation.  However,  given that we're
going
down the path of creating a Diameter AVP for NAS-Traffic-Rule, we
probably
no longer need to constrain ourselves to the limitations of the
IPFilterRule
syntax. 

[JiK] I'm OK not having the chance I proposed earlier.
      
>  o tcp-port name might be a bit misleading as ports are
>    also used for other protocols. Maybe just using
>    ports or similar?

How about 'layer4-port' or 'l4-port'?

[JiK] OK.

>  o What's the intended use for the L2 filtering? I'd
>    like to see some real use case described here 

BPDU filtering is one real use case. 

[JiK] Right. Probably a sentence or two saying L2 filtering is needed 
      e.g. for BPDU filtering in the intro or some appendix examples
      would be good.. 

>  o section 3.1 Acct-NAS-Traffic-Rule attribute definition
>     - the length should probably be >= 11
>     - The 'String' should probably be 'Counter'
>     - the description for 'Text' is missing

Ok.

[JiK] OK.

>  o Security considerations mention VLAN-related attributes
>    several times although those are now in a separate
>    document.

Ok. Will update.

[JiK] OK.

> 
> Some nits:
> 
>  o section 2
>    s/one new RADIUS authentication attributes/...attribute

Ok.

[JiK] OK. 

--
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, 10 Nov 2006 01:58:23 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: WG last call on RADIUS Filter Document
Date: Thu, 09 Nov 2006 17:57:49 -0800

This is an announcement of RADEXT WG last call on the RADIUS filter 
document.  The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-05.txt

WG last call will last until  November 30, 2006.  Please send your comments 
to the RADEXT WG mailing list, in the Issues format described on the RADEXT 
WG Issues web page:
http://www.drizzle.com/~aboba/RADEXT/

--
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, 09 Nov 2006 23:50:39 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-filter-05.txt 
Date: Thu, 09 Nov 2006 18:50:01 -0500

--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		: RADIUS Filter Rule Attribute
	Author(s)	: P. Congdon, et al.
	Filename	: draft-ietf-radext-filter-05.txt
	Pages		: 10
	Date		: 2006-11-9
	
This document defines the NAS-Filter-Rule attribute within the Remote
   Authentication Dial In User Service (RADIUS).  This attribute is
   based on the Diameter NAS-Filter-Rule AVP described in RFC 4005.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-05.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-filter-05.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-filter-05.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-filter-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-filter-05.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, 08 Nov 2006 17:05:04 +0000
Content-class: urn:content-classes:message
Subject: Crypto-Agility work item
Date: Wed, 8 Nov 2006 12:04:22 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

I spoke to Russ Housley this AM about our discussion of the
Crypto-Agility work item in the RADEXT session at IETF-67 yesterday.  He
confirms the sense of the room, that all we are being asked to do is
provide a way to "negotiate" replacement algorithms.  Negotiate could
mean what we already do in RADIUS, i.e. the client sends a "hint"
attribute indicating supported algorithms, and the server chooses (at
most) one of these.  There are details to work out, of course. However,
we are not expected to address the non-algorithm portions of the
requirements ID referenced in the proposed charter text.

We'll have a formal write up on the goals.

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, 07 Nov 2006 16:55:57 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RE: Comments on the draft-ietf-radext-filter-04 or.. -05
Date: Tue, 07 Nov 2006 08:55:45 -0800

>Right... just one more question to my clarification. What does a D->R
>translator box do based on this draft? Drop the NAS-Filter-Rule if
>Filter-ID also exists? What happens in D->R->D case (not that it is a
>realistic case but could happen)?

I believe the Diameter/RADIUS gateway will drop the NAS-Filter-Rule if 
Filter-ID also exists.

Perhaps a more fundamental question is if and when a Diameter peer would 
ever include both a NAS-Filter-Rule and Filter-ID attribute.

--
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, 07 Nov 2006 16:53:52 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on the draft-ietf-radext-filter-04 or.. -05
Date: Tue, 7 Nov 2006 17:53:01 +0100
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

> -----Original Message-----
> From: Congdon, Paul T (ProCurve) [mailto:[email-masked]] 
> Sent: 7. marraskuuta 2006 0:51
> To: Bernard Aboba; Korhonen, Jouni /TeliaSonera Finland Oyj; 
> [email-masked]
> Subject: RE: Comments on the draft-ietf-radext-filter-04 or.. -05
> 
> 
> We are covering old ground here again...  The restriction 
> should remain to ensure interoperability and predictable operation. 

Right... just one more question to my clarification. What does a D->R
translator box do based on this draft? Drop the NAS-Filter-Rule if
Filter-ID also exists? What happens in D->R->D case (not that it is a
realistic case but could happen)?

/Jouni

> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Bernard Aboba
> > Sent: Monday, November 06, 2006 12:39 PM
> > To: [email-masked]; [email-masked]
> > Subject: RE: Comments on the draft-ietf-radext-filter-04 or.. -05
> > 
> > >Just a small note/question regarding the text stating 
> Filter-ID and 
> > >NAS-Filter-Rule must not appear in the same message. I don't
> > see this
> > >kind of "must" restriction on Diameter side (RFC4005) so 
> why should 
> > >RADIUS have it?
> > 
> > Right.  Diameter allows both Filter-ID and NAS-Filter-Rule AVPs, so 
> > adding a usage restriction within RADIUS might result in a 
> Diameter -> 
> > RADIUS translation issue.
> > 
> > >So e.g. in section 2 would
> > >"..attributes, and SHOULD NOT appear in the same RADIUS
> > packet." be better?
> > 
> > There might be a case where Filter-Id and NAS-Filter-Rule might be 
> > included in the same packet, but then the document would need to 
> > explain what happens when that occurs.
> > 
> > I don't think there would ever be a reason to include both 
> > NAS-Traffic-Rule and NAS-Filter-Rule in the same packet.
> > 
> > >Also it is not entirely clear to me why e.g. Filter-Id and 
> > >NAS-Filter-Rule must be mutually exclusive?
> > 
> > The question was what the resulting filter rule set would be. 
> >  Is the result consistent or unpredictable?  If it is 
> predictable, how 
> > does it work?
> > 
> > >This was questioned by some organizations that intend to use 
> > >NAS-Filter-Rule. I guess defining rule applying order 
> would also be 
> > >alternative..?
> > 
> > Do you have an opinion on how this should be handled?
> > 
> > For example, you could say that Filter-ID would be applied 
> first, then 
> > NAS-Filter-Rule.
> > 
> > 
> > 
> > --
> > 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: Mon, 06 Nov 2006 23:46:04 +0000
Content-class: urn:content-classes:message
Subject: RE: Mailing list issues and IETF-67 Agenda
Date: Mon, 6 Nov 2006 18:45:36 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

> The most recent message I found in a cursory check of the archives
> was dated October 15.

This was caused by a broken link issue at ops.ietf.org that has now been
corrected.

> There have been reports that some important messages, such
> as the call for presentations (RADEXT WG Agenda Items) and the
> draft WG Agenda were not received by all list members.

Investigation by the list server manager indicates that, at least in the
reported instance, the messages were delivered to the recipient's
incoming SMTP server.

It appears that all the issues have now been addressed.  If that is not
the case, or you have reason to suspect it is not the case, please let
the chairs know.

--
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, 06 Nov 2006 22:51:57 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on the draft-ietf-radext-filter-04 or.. -05
Date: Mon, 6 Nov 2006 16:51:24 -0600
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>, <[email-masked]>

We are covering old ground here again...  The restriction should remain
to ensure interoperability and predictable operation. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Monday, November 06, 2006 12:39 PM
> To: [email-masked]; [email-masked]
> Subject: RE: Comments on the draft-ietf-radext-filter-04 or.. -05
> 
> >Just a small note/question regarding the text stating Filter-ID and 
> >NAS-Filter-Rule must not appear in the same message. I don't 
> see this 
> >kind of "must" restriction on Diameter side (RFC4005) so why should 
> >RADIUS have it?
> 
> Right.  Diameter allows both Filter-ID and NAS-Filter-Rule 
> AVPs, so adding a usage restriction within RADIUS might 
> result in a Diameter -> RADIUS translation issue.
> 
> >So e.g. in section 2 would
> >"..attributes, and SHOULD NOT appear in the same RADIUS 
> packet." be better?
> 
> There might be a case where Filter-Id and NAS-Filter-Rule 
> might be included in the same packet, but then the document 
> would need to explain what happens when that occurs.
> 
> I don't think there would ever be a reason to include both 
> NAS-Traffic-Rule and NAS-Filter-Rule in the same packet.
> 
> >Also it is not entirely clear to me why e.g. Filter-Id and 
> >NAS-Filter-Rule must be mutually exclusive?
> 
> The question was what the resulting filter rule set would be. 
>  Is the result consistent or unpredictable?  If it is 
> predictable, how does it work?
> 
> >This was questioned by some organizations that intend to use 
> >NAS-Filter-Rule. I guess defining rule applying order would also be 
> >alternative..?
> 
> Do you have an opinion on how this should be handled?
> 
> For example, you could say that Filter-ID would be applied 
> first, then NAS-Filter-Rule.
> 
> 
> 
> --
> 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: Mon, 06 Nov 2006 22:33:43 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on the draft-ietf-radext-filter-04 or.. -05
Date: Mon, 6 Nov 2006 23:33:27 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: 6. marraskuuta 2006 22:39
> To: Korhonen, Jouni /TeliaSonera Finland Oyj; [email-masked]
> Subject: RE: Comments on the draft-ietf-radext-filter-04 or.. -05
> 
> >Just a small note/question regarding the text stating Filter-ID and 
> >NAS-Filter-Rule must not appear in the same message. I don't 
> see this 
> >kind of "must" restriction on Diameter side (RFC4005) so why should 
> >RADIUS have it?
> 
> Right.  Diameter allows both Filter-ID and NAS-Filter-Rule 
> AVPs, so adding a usage restriction within RADIUS might 
> result in a Diameter -> RADIUS translation issue.
> 
> >So e.g. in section 2 would
> >"..attributes, and SHOULD NOT appear in the same RADIUS 
> packet." be better?
> 
> There might be a case where Filter-Id and NAS-Filter-Rule 
> might be included in the same packet, but then the document 
> would need to explain what happens when that occurs.
> 
> I don't think there would ever be a reason to include both 
> NAS-Traffic-Rule and NAS-Filter-Rule in the same packet.

Right. I was actually only referring to Filter-ID and
NAS-Filter-ID case.

> >Also it is not entirely clear to me why e.g. Filter-Id and 
> >NAS-Filter-Rule must be mutually exclusive?
> 
> The question was what the resulting filter rule set would be. 
>  Is the result consistent or unpredictable?  If it is 
> predictable, how does it work?

I didn't find anything on e.g. preferred order of applying
filters in RFC4005. I guess it makes this somewhat more complicated.

> >This was questioned by some organizations that intend to use 
> >NAS-Filter-Rule. I guess defining rule applying order would also be 
> >alternative..?
> 
> Do you have an opinion on how this should be handled?
> 
> For example, you could say that Filter-ID would be applied 
> first, then NAS-Filter-Rule.

Something like the above. We could state that Filter-ID must be applied
first and then NAS-Filter-Rule. However, I'm not sure whether this kind
of recommendation should also be reflected in Diameter as well?

/Jouni

--
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, 06 Nov 2006 22:14:08 +0000
Content-class: urn:content-classes:message
Subject: VS: Comments on the draft-ietf-radext-filter-04 or.. -05
Date: Mon, 6 Nov 2006 23:13:56 +0100
To: <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

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

Hmmm.. so far before these two new filter IDs we have only had 
RFC on Filter-ID right? So we are possibly making those rules
now. And a NAS would drop NAS-Filter-Rule anyway if it
does not understand it.
 
/Jouni

________________________________

Lähettäjä: [email-masked] puolesta: Nelson, David
Lähetetty: ma 6.11.2006 23:46
Vastaanottaja: [email-masked]
Aihe: RE: Comments on the draft-ietf-radext-filter-04 or.. -05

Jouni Korhonen writes...

> Just a small note/question regarding the text stating Filter-ID and
> NAS-Filter-Rule must not appear in the same message. I don't see
> this kind of "must" restriction on Diameter side (RFC4005) so why
> should RADIUS have it? So e.g. in section 2 would
>   "..attributes, and SHOULD NOT appear in the same RADIUS packet."
> be better? Also it is not entirely clear to me why e.g. Filter-Id
> and NAS-Filter-Rule must be mutually exclusive? This was questioned
> by some organizations that intend to use NAS-Filter-Rule. I guess
> defining rule applying order would also be alternative..?

The reason is that there is no existing specification in the RADIUS RFCs
that would indicate what the precedence would be among potentially
competing expressions of filtering behavior.  In the absence of any such
specification, then the precedence is up the NAS implementation and
would lead to very poor interoperability.

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

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

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>

<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7638.1">
<TITLE>RE: Comments on the draft-ietf-radext-filter-04 or.. -05</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText67897 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT>&nbsp;</DIV></DIV>
<DIV dir=ltr>Hmmm.. so far before these two new filter IDs we have only had 
</DIV>
<DIV dir=ltr>RFC on Filter-ID right? So we are possibly making those rules</DIV>
<DIV dir=ltr>now. And a NAS would drop NAS-Filter-Rule anyway if it</DIV>
<DIV dir=ltr>does not&nbsp;understand it.</DIV>
<DIV dir=ltr>&nbsp;</DIV>
<DIV dir=ltr>/Jouni<BR></DIV>
<DIV dir=ltr>
<HR tabIndex=-1>
</DIV>
<DIV dir=ltr><FONT face=Tahoma size=2><B>Lähettäjä:</B> 
[email-masked] puolesta: Nelson, David<BR><B>Lähetetty:</B> ma 
6.11.2006 23:46<BR><B>Vastaanottaja:</B> [email-masked]<BR><B>Aihe:</B> 
RE: Comments on the draft-ietf-radext-filter-04 or.. -05<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>Jouni Korhonen writes...<BR><BR>&gt; Just a small note/question 
regarding the text stating Filter-ID and<BR>&gt; NAS-Filter-Rule must not appear 
in the same message. I don't see<BR>&gt; this kind of "must" restriction on 
Diameter side (RFC4005) so why<BR>&gt; should RADIUS have it? So e.g. in section 
2 would<BR>&gt;&nbsp;&nbsp; "..attributes, and SHOULD NOT appear in the same 
RADIUS packet."<BR>&gt; be better? Also it is not entirely clear to me why e.g. 
Filter-Id<BR>&gt; and NAS-Filter-Rule must be mutually exclusive? This was 
questioned<BR>&gt; by some organizations that intend to use NAS-Filter-Rule. I 
guess<BR>&gt; defining rule applying order would also be 
alternative..?<BR><BR>The reason is that there is no existing specification in 
the RADIUS RFCs<BR>that would indicate what the precedence would be among 
potentially<BR>competing expressions of filtering behavior.&nbsp; In the absence 
of any such<BR>specification, then the precedence is up the NAS implementation 
and<BR>would lead to very poor interoperability.<BR><BR><BR>--<BR>to unsubscribe 
send a message to [email-masked] with<BR>the word 'unsubscribe' 
in a single line as the message text body.<BR>archive: &lt;<A 
href="http://psg.com/lists/radiusext/">http://psg.com/lists/radiusext/</A>&gt;<BR></FONT></P></DIV>

</BODY>
</HTML>
------_=_NextPart_001_01C701F0.D9BAAD68--

--
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, 06 Nov 2006 22:10:56 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on the draft-ietf-radext-filter-04 or.. -05
Date: Mon, 6 Nov 2006 17:10:35 -0500
To: <[email-masked]>

Pasi Eronen writes...

> RFC4005 does not define how using both of them would actually
> work (e.g. which is applied first).... so IMHO we could keep
> the restriction.

I agree.

--
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, 06 Nov 2006 21:51:31 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on the draft-ietf-radext-filter-04 or.. -05
Date: Mon, 6 Nov 2006 23:47:26 +0200
From: <[email-masked]>
To: <[email-masked]>

Bernard Aboba wrote:

> >Just a small note/question regarding the text stating Filter-ID and
> >NAS-Filter-Rule must not appear in the same message. I don't see
> >this kind of "must" restriction on Diameter side (RFC4005) so why
> >should RADIUS have it?
> 
> Right.  Diameter allows both Filter-ID and NAS-Filter-Rule 
> AVPs, so adding a usage restriction within RADIUS might result in 
> a Diameter -> RADIUS translation issue.

RFC4005 does not define how using both of them would actually work 
(e.g. which is applied first).... so IMHO we could keep the
restriction.

Best regards,
Pasi

--
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, 06 Nov 2006 21:47:02 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on the draft-ietf-radext-filter-04 or.. -05
Date: Mon, 6 Nov 2006 16:46:37 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Jouni Korhonen writes...

> Just a small note/question regarding the text stating Filter-ID and
> NAS-Filter-Rule must not appear in the same message. I don't see
> this kind of "must" restriction on Diameter side (RFC4005) so why
> should RADIUS have it? So e.g. in section 2 would
>   "..attributes, and SHOULD NOT appear in the same RADIUS packet."
> be better? Also it is not entirely clear to me why e.g. Filter-Id
> and NAS-Filter-Rule must be mutually exclusive? This was questioned
> by some organizations that intend to use NAS-Filter-Rule. I guess
> defining rule applying order would also be alternative..?

The reason is that there is no existing specification in the RADIUS RFCs
that would indicate what the precedence would be among potentially
competing expressions of filtering behavior.  In the absence of any such
specification, then the precedence is up the NAS implementation and
would lead to very poor interoperability.

--
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, 06 Nov 2006 20:45:51 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Comments on the draft-ietf-radext-filter-04 or.. -05
Date: Mon, 06 Nov 2006 12:45:41 -0800

Your comment about combinations of 
NAS-Filter-Rule/NAS-Traffic-Rule/Filter-Id brought some other thoughts to 
mind:

a. What if an operator doesn't know whether a given NAS supports 
NAS-Filter-Rule or NAS-Traffic-Rule?  Can it send *both* attributes, knowing 
that a NAS supporting NAS-Traffic-Rule will automatically ignore 
NAS-Filter-Rule?

b. What if an operator has a large set of constant filter rules, but needs 
to tag a different rule onto the end of the rule set, which depends on the 
user?  Could they send a Filter-Id attribute as well as a NAS-Filter-Rule or 
NAS-Traffic-Rule attribute?

c. In what circumstances will we be likely to see Filter-Id and 
NAS-Filter-Rule in the same Diameter message?

--
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, 06 Nov 2006 20:39:34 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Comments on the draft-ietf-radext-filter-04 or.. -05
Date: Mon, 06 Nov 2006 12:38:31 -0800

>Just a small note/question regarding the text stating Filter-ID and
>NAS-Filter-Rule must not appear in the same message. I don't see
>this kind of "must" restriction on Diameter side (RFC4005) so why
>should RADIUS have it?

Right.  Diameter allows both Filter-ID and NAS-Filter-Rule AVPs, so adding a 
usage restriction within RADIUS might result in a Diameter -> RADIUS 
translation issue.

>So e.g. in section 2 would
>"..attributes, and SHOULD NOT appear in the same RADIUS packet." be better?

There might be a case where Filter-Id and NAS-Filter-Rule might be included 
in the same packet, but then the document would need to explain what happens 
when that occurs.

I don't think there would ever be a reason to include both NAS-Traffic-Rule 
and NAS-Filter-Rule in the same packet.

>Also it is not entirely clear to me why e.g. Filter-Id and NAS-Filter-Rule 
>must be mutually exclusive?

The question was what the resulting filter rule set would be.  Is the result 
consistent or unpredictable?  If it is predictable, how does it work?

>This was questioned by some organizations that intend to use 
>NAS-Filter-Rule. I guess
>defining rule applying order would also be alternative..?

Do you have an opinion on how this should be handled?

For example, you could say that Filter-ID would be applied first, then 
NAS-Filter-Rule.

--
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, 06 Nov 2006 20:09:53 +0000
Content-class: urn:content-classes:message
Subject: Comments on the draft-ietf-radext-filter-04 or.. -05
Date: Mon, 6 Nov 2006 21:08:57 +0100
From: <[email-masked]>
To: <[email-masked]>

Hi All,

I just reviewed the latest version of the draft. It looks ok to me
and I don't have much to add to Pasi's and Alan's notes that got
posted earlier.

Just a small note/question regarding the text stating Filter-ID and
NAS-Filter-Rule must not appear in the same message. I don't see
this kind of "must" restriction on Diameter side (RFC4005) so why
should RADIUS have it? So e.g. in section 2 would
  "..attributes, and SHOULD NOT appear in the same RADIUS packet."
be better? Also it is not entirely clear to me why e.g. Filter-Id
and NAS-Filter-Rule must be mutually exclusive? This was questioned
by some organizations that intend to use NAS-Filter-Rule. I guess
defining rule applying order would also be alternative..?  

/Jouni

--
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, 06 Nov 2006 18:25:25 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Presentations?
Date: Mon, 06 Nov 2006 10:25:12 -0800

If you have a presentation for the IETF 67 RADEXT WG meeting, please send 
them to David or myself.

--
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, 06 Nov 2006 18:19:22 +0000
Content-class: urn:content-classes:message
Subject: IETF-67 streaming audio and jabber room
Date: Mon, 6 Nov 2006 13:19:03 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

The RADEXT WG session will be covered by streaming audio, as in past
meetings.  We will be on Channel 5, starting at 9:00 AM PST, Tuesday,
November 7, 2006.  The URL for Channel 5 is:
http://videolab.uoregon.edu/events/ietf/ietf675.m3u

Will also monitor the "radext" jabber room at "jabber.ietf.org" for
questions and feedback from remote participants.

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: Mon, 06 Nov 2006 18:12:40 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: Comments on draft-ietf-radext-filter-04
Date: Mon, 06 Nov 2006 10:11:48 -0800

>Does this look ok?

Looks good to me.  A strawman -05 document incorporating Pasi and Alan's 
comments is available here:

http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-filter-05.txt

--
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: Mon, 06 Nov 2006 17:32:20 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Comments on draft-ietf-radext-filter-04 
cc: [email-masked]
Date: Mon, 06 Nov 2006 12:21:43 -0500
Message-Id: <[email-masked]>

> Merging your text and my earlier suggestion:
...
> Does this look ok?

  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: Mon, 06 Nov 2006 17:09:25 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-ietf-radext-filter-04 
Date: Mon, 6 Nov 2006 19:08:37 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

[email-masked] wrote:
> I would suggest re-using the text from the RADIUS encapsulation case
> above:
> 
>       When translating Diameter NAS-Filter-Rule AVPs to RADIUS
>       NAS-Filter-Rule attributes, the set of NAS-Filter-Rule
>       attributes SHOULD be created by concatenating the individual
>       filter rules, separated by a NUL (0x00) octet.  The resulting
>       data should be split on 253 byte boundaries to obtain a set of
>       NAS-Filter-Rule attributes.  When translating RADIUS
>       NAS-Filter-Rule attributes to Diameter NAS-Filter-Rule AVPs, the
>       individual Diameter NAS-Filter-Rule AVPs rules SHOULD be
>       determined by concatenating the contents of all NAS-Filter-Rule
>       attributes, and then splitting individual filter rules with the
>       the NUL octet (0x00) as a delimeter.  Each rule is then encoded
>       as a single Diameter NAS-Filter-Rule AVP.
> 
>   i.e. Take the last paragraph from section 2, and added a few phrases
> about Diameter.

Hmm... it looks like the SHOULDs cover too much: e.g. adding NULs
between the individual rules (or determining rule boundaries based on
NULs) is not optional; splitting them on exactly 253 byte boundaries
is.

Merging your text and my earlier suggestion:

   When translating Diameter NAS-Filter-Rule AVPs to RADIUS
   NAS-Filter-Rule attributes, the set of NAS-Filter-Rule attributes
   is created by concatenating the individual filter rules, separated
   by a NUL octet.  The resulting data SHOULD then be split on 253
   byte boundaries.

   When translating RADIUS NAS-Filter-Rule attributes to Diameter
   NAS-Filter-Rule AVPs, the individual rules are determined by
   concatenating the contents of all NAS-Filter-Rule, and then
   splitting individual filter rules with the NUL octet as a
   delimeter.  Each rule is then encoded as a single Diameter
   NAS-Filter-Rule AVP.

Does this look ok?

Best regards,
Pasi

--
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, 06 Nov 2006 16:56:01 +0000
Content-class: urn:content-classes:message
Subject: Mailing list issues and IETF-67 Agenda
Date: Mon, 6 Nov 2006 11:55:03 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

It has been brought to the chairs' attention that the RADEXT WG mailing
List at ops.ietf.org may be experiencing technical difficulties.  The
most recent message I found in a cursory check of the archives was dated
October 15.  There have been reports that some important messages, such
as the call for presentations (RADEXT WG Agenda Items) and the draft WG
Agenda were not received by all list members.  These messages were
reflected back to me, so the issue appears to be a partial failure.

The most current version of the RADEXT WG Meeting Agenda for IETF-67 may
be found in the Slides (presentations) at the IETF-67 Meeting Materials
web page.
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67

Note that the plain text Agenda is in need of an update, as of this
writing.

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

Envelope-to: [email-masked]
Delivery-date: Mon, 06 Nov 2006 16:27:28 +0000
From: "Alan DeKok" <[email-masked]>
To: "Pasi Eronen" <[email-masked]>
Subject: Re: Comments on draft-ietf-radext-filter-04 
cc: [email-masked]
Date: Mon, 06 Nov 2006 11:16:37 -0500
Message-Id: <[email-masked]>

  Additional comments, similar to Pasi's comments:

  Abstract: 

   This document defines the NAS-Filter-Rule attribute within the Remote
   Authentication Dial In User Service (RADIUS), equivalent to the
   Diameter NAS-Filter-Rule AVP described in RFC 4005.

  I'm not sure what "equivalent" means here.  Maybe "the RADIUS
counterpart to the Diameter AVP"?  The attributes aren't equivalent,
as their ID's and encapsulation methods are different.  But the intent
is that they carry the same data, in the same format.

> 1) Section 1.3: "It is recommended that an Error-Cause..." 
> Perhaps uppercase "RECOMMENDED" would be appropriate here?

  Or SHOULD?

  Also section 1.3:

   this situation does not result in session termination
   and the pre-existing configuration remains unchanged.  As a result,
   no accounting packets should be generated.

  ... for the CoA request.  The session may still generate accounting
packets as part of its ongoing process.

> 2) Section 2: "the individual filter rules SHOULD be determined by
> concatenating the contents of all NAS-Filter-Rule attributes, and then
> splitting individual filter rules with the the NUL octet (0x00) as a
> delimeter." I don't think "SHOULD" is correct here. How about just
> "the individual filter rules _are_ determined..."?

  Yes.

> 3) Section 4: The text about Diameter-to-RADIUS translation could be
> clearer (currently it only describes how the translation works for
> >253 octet rules, but not the <253 octet case). Suggested
> text (replacing 2nd paragraph):

  I would suggest re-using the text from the RADIUS encapsulation case
above:

      When translating Diameter NAS-Filter-Rule AVPs to RADIUS
      NAS-Filter-Rule attributes, the set of NAS-Filter-Rule
      attributes SHOULD be created by concatenating the individual
      filter rules, separated by a NUL (0x00) octet.  The resulting
      data should be split on 253 byte boundaries to obtain a set of
      NAS-Filter-Rule attributes.  When translating RADIUS
      NAS-Filter-Rule attributes to Diameter NAS-Filter-Rule AVPs, the
      individual Diameter NAS-Filter-Rule AVPs rules SHOULD be
      determined by concatenating the contents of all NAS-Filter-Rule
      attributes, and then splitting individual filter rules with the
      the NUL octet (0x00) as a delimeter.  Each rule is then encoded
      as a single Diameter NAS-Filter-Rule AVP.

  i.e. Take the last paragraph from section 2, and added a few phrases
about Diameter.

  That repetition should make it clear that the process for RADIUS
encapsulation is the same, independent of the source of the attributes.

  Also for section 3, I would add:

   Access- Access- Access- Access-   CoA-  Acct-
   Request Accept  Reject  Challenge Req   Req   #   Attribute
    0       0+      0       0        0+    0+   TBD  NAS-Filter-Rule [note1]

   Note1: NAS-Filter-Rule is precluded from appearing in a packet if a
   Filter-Id or NAS-Traffic-Rule attribute is present

  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, 06 Nov 2006 04:56:54 +0000
From: "Pasi Eronen" <[email-masked]>
To: <[email-masked]>
Subject: Comments on draft-ietf-radext-filter-04
Date: Mon, 6 Nov 2006 06:56:05 +0200

I've gone through the latest version, and this looks basically
ready. There clearly are other alternative how long rules could have
been handled, but IMHO the chosen approach is good enough (and
spending more time on this issue would be counterproductive).

Some minor editorial suggestions:

1) Section 1.3: "It is recommended that an Error-Cause..." 
Perhaps uppercase "RECOMMENDED" would be appropriate here?

2) Section 2: "the individual filter rules SHOULD be determined by
concatenating the contents of all NAS-Filter-Rule attributes, and then
splitting individual filter rules with the the NUL octet (0x00) as a
delimeter." I don't think "SHOULD" is correct here. How about just
"the individual filter rules _are_ determined..."?

3) Section 4: The text about Diameter-to-RADIUS translation could be
clearer (currently it only describes how the translation works for
>253 octet rules, but not the <253 octet case). Suggested
text (replacing 2nd paragraph):

   "When translating Diameter NAS-Filter-Rule AVPs to RADIUS
   NAS-Filter-Rule attributes, a Diameter/RADIUS gateway adds a NUL
   octet between each individual rule. The Diameter/RADIUS gateway
   then splits rules longer than 253 octets to multiple RADIUS
   NAS-Filter-Rule attributes, and MAY also combined multiple rules
   (or parts of multiple rules) to a single NAS-Filter-Rule attribute.

   When translating RADIUS NAS-Filter-Rule attributes to Diameter
   NAS-Filter-Rule AVPs, the Diameter/RADIUS gateway concatenates all
   the received NAS-Filter-Rule attributes, and determines rule
   boundaries using the NUL octet as a delimiter. Each rule (without
   the NUL octet delimiter) is then encoded as a single Diameter
   NAS-Filter-Rule AVP."

4) Section 7.2 : [Traffic] title is now "RADIUS Attributes for
Filtering and Redirection".

Best regards,
Pasi

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