Subject: Re: RADEXT WG Last Call on Status-Server Document

From: Alan DeKok <[email-masked]>
Date: Mon, 08 Dec 2008 13:37:00 +0100

Stig Venaas wrote:
> I think clients should allow Access-Accept responses to status-server
> messages sent to the accounting port. Even if it's not the expected
> message, it shows that the server is alive.

  Ok.  I've updated the draft, and will issue a new version shortly.

> Also, towards the end of section 4.2 the draft says:
> 
>    Some server implementations accept both Access-Request and
>    Accounting-Request packets on the same port, and do not distinguish
>    between "authentication only" ports, and "accounting only" ports.
>    Those implementations SHOULD reply to Status-Server packets with an
>    Access-Accept packet.
> 
> Due to this, I think the text in 2.3.2 is too strict:
> 
>    The Status-Server packet MUST contain a Message-Authenticator
>    attribute for security.  The response (if any) to a Status-Server
>    packet sent to an accounting port MUST be an Accounting-Response
>    packet.  The list of attributes that are permitted in the Accounting-
>    Response packet is given in the Table of Attributes in Section 6,
>    below.
> 
> I think the second MUST should be a SHOULD. Or at the very least, in
> section 4.1 where it talks about clients being liberal at what they
> accept. Add a note that they SHOULD accept this.

  OK.  I've done that:

      The response (if any) to a Status-Server
      packet sent to an accounting port SHOULD be an Accounting-Response
      packet, and MAY be an Access-Accept packet.  Other response packet
      codes MUST NOT be used.

  With similar text for authentication packets.

  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: Mon, 08 Dec 2008 13:41:16 +0100

Stig Venaas wrote:
> In most places (but not all) the draft uses the term "Status-Server
> packet" or just "packet". Wouldn't it be better to replace "packet"
> with "message"? Especially since it's not limited to UDP transport.

  Maybe.  It's still a RADIUS packet, and the term "packet" is
consistent with RFC 2865.

> "it's" should be replaced with "its" throughout (genitive).

  Fixed, thanks.

> TOC formatting is slightly broken (2.3.1/2.3.2).

  I'll fix that in the next rev.

> Section 2.3.2 has no title (missing both in TOC and body).
> 
> In 2.2:
> 
>    A similar solution for the problem of querying server status may be
>    for a NAS to send specially formed Accounting-Request packets to a
>    RADIUS servers authentication port.  The NAS can then look for a
>           ^^^^^^^^^^^^^^^^^^^^^^
>  server's accounting

  Fixed, thanks.

> In 3:
> 
>    Note that when a server responds to a Status-Server request, it MUST
>    NOTE send more than one response packet.
> s/NOTE/NOT/

  Fixed, thanks.

> In 4.2:
> 
>    The server MAY prioritize the handling Status-Server queries over the
> 
> Insert "of"                            ^^^^^
> 
>    The server MAY decide to not respond to a Status-Server, depending on
> Insert "packet" or "message"                        ^^^^^^^

  Fixed, thanks.

> In 4.3:
>    unresponsive, this change would enable the NAS to start packets to
>                                                     ^^^^^^^^^^^^^^^^^^
>    start sending packets to that RADIUS server again.  The NAS MAY
> Remove " start packets to".

  Fixed, thanks.

> In 4.6:
>    In the worst case, failures in routing for Realm A may affect users
>    Realm B.  For example, if Proxy Server P can reach Realm B but not
>  ^^^^^
> Insert "of"

  Fixed, thanks.

>    In this situation, if all participants impement Status-Server as
> s/impement/implement/                    ^^^^^^^^^^

  Fixed, thanks.

> In 6:
>    The following table provide a guide to which attributes may be found
> s/provide/provides/   ^^^^^^^^^

  Fixed, thanks.

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 8 Dec 2008 09:42:16 -0500

Alan DeKok writes...

> > I think clients should allow Access-Accept responses to 
> > status-server messages sent to the accounting port. Even
> > if it's not the expected message, it shows that the server
> > is alive.
> 

Hmm.  IIRC, the consensus of the room at the RADEXT WG meeting at IETF-73
was that this was a bad idea.  I realize this was probably the only
substantive comment received during WGLC on this draft.  However, it's only
one opinion.

<WG Chair hat on>

I think document editors need to be careful to avoid adding technical
changes to WG drafts at the request of just one commenter.  If that one
comment happens to represent WG consensus, then fine.  If the one comment is
simply one individual's opinion, then maybe not so fine.  I also realize
that in RADEXT, these days, it's sometimes hard to distinguish.  :-(

<WG Chair hat off>

> >    Accounting-Request packets on the same port, and do not
> >    distinguish between "authentication only" ports, and "accounting 
> >    only" ports.  Those implementations SHOULD reply to Status-Server 
> >    packets with an Access-Accept packet.

Yeah, but isn't that extremely broken behavior?  I know we're documenting
existing behavior, but do we have to document the most broken parts?  I
thought the idea was to support the needs of RADSEC with respect to server
"liveness", and in doing so, re-use an existing mechanism.  Otherwise, there
are probably lots of other broken behaviors in RADIUS implementations that
could be documented.  You know... "A bug, once documented, becomes a
feature".  :-(  Where do we draw the line?

---

From: Alan DeKok <[email-masked]>
Date: Mon, 08 Dec 2008 15:49:57 +0100

> substantive comment received during WGLC on this draft.  However, it's only

  OK, if the consensus is that it's a bad idea, that can be removed from
the draft.

> Yeah, but isn't that extremely broken behavior?

  Umm... if you say so.  I won't comment.

>  I know we're documenting

  We'd like to draw it at things that are crazy.  But we're too late for
that.

  Maybe it's best to say that authentication ports respond with
Access-Accept, and accounting ports respond with Accounting-Response.
Anything else is NOT RECOMMENDED.

  Comments?

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 8 Dec 2008 10:01:17 -0500

Alan DeKok writes...

> > IIRC, the consensus of the room at the RADEXT WG meeting at
> > IETF-73 was that this was a bad idea.
 
> OK, if the consensus is that it's a bad idea, that can be
> removed from the draft.

As usual, tentative consensus from an IETF meeting needs to be confirmed on
the list.  This would seem to be a good opportunity to do so.

Consensus Call:  Should we document the following as "recognized" RADIUS
behavior?

> > Where do we draw the line?
> 
>   We'd like to draw it at things that are crazy.  But we're
> too late for that.

Too late in terms of what folks have implemented, yes.  Not too late in
terms of what we publish in an RFC and recognize as "recommended" behavior.
Not all bugs need to be promoted to feature status.
 
> Anything else is NOT RECOMMENDED.

That would certainly cover all bases.
 
>   Comments?

Yes, comments from others, please.

---

From: Stefan Winter <[email-masked]>
Date: Mon, 08 Dec 2008 16:14:02 +0100

Hi,

> That would certainly cover all bases.

That text sounds good to me.

Stefan

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

Tel: +352 424409 1
Fax: +352 422473

---

From: Stig Venaas <[email-masked]>
Date: Mon, 08 Dec 2008 17:01:02 +0100

> That text sounds good to me.

I am also OK with that.

It would have been easier to implement this correctly if there were
something distinguishing the requests (other than they being received
at auth or acc ports).

Stig

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 11 Dec 2008 17:53:55 -0600

On November 3, 2008, a call was issues for the review the status of open
issues on draft-ietf-radext-extended-attributes-05.txt:

http://ops.ietf.org/lists/radiusext/2008/msg00720.html

This generated the following responses:

http://ops.ietf.org/lists/radiusext/2008/msg00727.html

http://ops.ietf.org/lists/radiusext/2008/msg00737.html

http://ops.ietf.org/lists/radiusext/2008/msg00757.html

http://ops.ietf.org/lists/radiusext/2008/msg00755.html

Looking over these responses and subsequent postings, it would appear that
the following issues remain open:

Extended Attributes 

Issue Number

Status

Type

Description

Owner

Issue 225

Pending

Technical

Review <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20225> 

Alan DeKok <mailto:[email-masked]> 

Issue 251

Pending

Technical

Review <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20251> 

Bernard Aboba <mailto:[email-masked]> 

Issue 278

Pending

Technical

Comments
<http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20278> 

Alan DeKok <mailto:[email-masked]> 

Issue 279

Pending

Technical

Comments
<http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20279> 

Stefan Winter <mailto:[email-masked]> 

Issue 287

No Discussion

Technical

Comments
<http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20287> 

Greg Weber <mailto:[email-masked]> 

Issue 290

No Discussion

Technical

RFC <http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20290>
4005bis Dependency

Bernard Aboba <mailto:[email-masked]> 

I have updated the Issues list to take into account the current status, as
well as to reflect

the mailing list discussion of these issues.  If any of the above issues are
now closed, or

if there is are any additional comments that the original posters wish to
make relating to

current status, please reply to this message.