Subject: Review of draft-ietf-radext-status-server-05 (Part II)

From: Bernard Aboba <[email-masked]>
Date: Sat, 6 Feb 2010 16:32:26 -0800

Sections 2.1 and Section 2.2

Section 2 explains the unique properties of Status-Server and why a RADIUS client might want to use it.  RFC 2865 Section 2.6
explains why "keepalives" are a bad idea.  Presumably this advice applies to both RADIUS Access-Request and Accounting-Request keepalives.  Given that, Sections 2.1 and 2.2 belabor the point.  I'd suggest that they be deleted. 

Section 2.3

I would suggest deleting this section as well. 

Section 2.3.1

My advice is to incorporate the material in this section into Section 2 (To be retitled Overview). 

Section 3

     Response Authenticator

         The value of the Authenticator field in Access-Accept, or
         Accounting-Response packets is called the Response
         Authenticator, and contains a one-way MD5 hash calculated over
         a stream of octets consisting of: the RADIUS packet, beginning
         with the Code field, including the Identifier, the Length, the
         Request Authenticator field from the Status-Server packet, and
         the response Attributes (if any), followed by the shared
         secret.  That is, ResponseAuth =
         MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where +
         denotes concatenation.

[BA] Why is this material here?  If you need it at all (I don't think so), you can just reference
RFC 2865 and/or 2866. 

   Status-Server packets MAY include NAS-Identifier, and one of NAS-IP-
   Address or NAS-IPv6-Address.  These attributes are not necessary for
   the operation of Status-Server, but may be useful information to a
   server that receives those packets.

[BA] You might say that the server MUST ignore other attributes. 

   Other attributes SHOULD NOT be included in a Status-Server packet.
   User authentication credentials such as User-Password, CHAP-Password,
   EAP-Message, etc. MUST NOT appear in a Status-Server packet sent to a
   RADIUS authentication port.  User or NAS accounting attributes such
   as Acct-Session-Id, Acct-Status-Type, Acct-Input-Octets, etc.  MUST
   NOT appear in a Status-Server packet sent to a RADIUS accounting
   port.

[BA] Also, presumably User-Name is not included (relevant to the point about realms made earlier).

---

From: Alan DeKok <[email-masked]>
Date: Tue, 16 Feb 2010 15:51:56 +0100

Bernard Aboba wrote:
> Section 2 explains the unique properties of Status-Server and why a
> RADIUS client might want to use it.  RFC 2865 Section 2.6
> explains why "keepalives" are a bad idea.  Presumably this advice
> applies to both RADIUS Access-Request and Accounting-Request
> keepalives.  Given that, Sections 2.1 and 2.2 belabor the point.  I'd
> suggest that they be deleted.

  I think that they have some use.  There are a number of
implementations which "overload" Access-Requests for all kinds of
functionality.  Having an explanation as to why this is bad can help
guide implementors.

> I would suggest deleting this section as well.

  OK.

> (To be retitled Overview).

  Done.

> [BA] Why is this material here?  If you need it at all (I don't think so), you can just reference

  Otherwise there will be confusion over how to calculate it.  The other
RFCs define how the Response Authenticator is calculated for response
packets.  It's not a *bad* idea to include similar text here.

> [BA] You might say that the server MUST ignore other attributes. 

  OK.

> [BA] Also, presumably User-Name is not included (relevant to the point about realms made earlier). 

  Yes.  I'll add that in.

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

---

From: Alan DeKok <[email-masked]>
Date: Wed, 24 Feb 2010 23:06:13 +0100

Ignacio Goyret wrote:
>                                       ^^^^
> Why MUST?
> Shouldn't that be up to the server's local policy?
> What if the server needs/wants to check one of those extra attributes?
> (possibly including vendor-specific attributes)

  What are the checks for?  The only possible decision that can be made
is whether or not to reply to a Status-Server.

  Would it be useful to allow a server to *not* respond, if it saw a VSA
with a particular value?

  I could see this being useful for checking "liveliness" of upstream
realms.  But some providers have dozens, if not hundreds of realms, and
this functionality gets awkward pretty quickly.

  Alan DeKok.

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 24 Feb 2010 14:27:07 -0800

Alan said:

"  I could see this being useful for checking "liveliness" of upstream
realms.  But some providers have dozens, if not hundreds of realms, and
this functionality gets awkward pretty quickly."

[BA] Since Status-Server isn't forwardable, I'm not sure how it could help
with the realm reachability issue.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 25 Feb 2010 07:32:27 +0100

> with the realm reachability issue.  

  Say a NAS has two paths to realm FOO.  It can ask each one; can *you*
reach FOO?  The one that answers "yes" has packets sent to it.

  The Status-Server isn't being forwarded.  But the NAS still finds out
the proxies view of the reachability of realm FOO.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 25 Feb 2010 08:05:40 +0100

Ignacio Goyret wrote:
> I'm just questioning the choice of MUST vs SHOULD.
> I've seen far too many specs that include MUSTs that should
> have been less restrictive.

  I agree.

> So, unless it hurts interoperability, I'd suggest replacing
> that MUST with a SHOULD, leaving the door open for servers
> to use other attributes, if their admins choose to do so.

  It won't hurt interoperability, so far as I can tell.

> Makes sense?

  Yes.

  I don't have strong opinions either way.

  Alan DeKok.

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 25 Feb 2010 09:49:23 -0800

Alan said:

"  Say a NAS has two paths to realm FOO.  It can ask each one; can *you*
reach FOO?  The one that answers "yes" has packets sent to it.

  The Status-Server isn't being forwarded.  But the NAS still finds out
the proxies view of the reachability of realm FOO."

[BA] The effectiveness of this will depend on the definition of
"reachability" in this context. For example, does a "yes" mean:

1. "Proxy has realm FOO in its routing table"  OR
2. "Proxy got a response from realm FOO in the last X seconds" OR
3. "Proxy tested reachability to realm FOO as a result of receiving
Status-Server with a realm request and got a response"