Subject: Re: [AAA-DOCTORS] [Technical Errata Reported] RFC2866 (4485)

From: Stefan Winter <[email-masked]>
Date: Mon, 28 Sep 2015 13:09:17 +0200

Hello, this time including the doctors,

hm, I'm not so sure. The errata notes contain the assertion that RFC2866
was not meant to be used like that.

But that statement is not a given. the RFC states in 4.1 that

"Any attribute valid in a RADIUS Access-Request or Access-Accept
      packet is valid in a RADIUS Accounting-Request packet, except that
      the following attributes MUST NOT [...]"

So, sending Called-Station-Id is something that's allowed just fine.

It is not reasonable to assume the On/Off is atomic for the entire NAS -
the text "(for example, just before a scheduled reboot)" is really jsut
that - an example.

True, it is not defined how this attribute is supposed to be used and
that the action "only terminate Accounting for sessions matching this
Called-Station-Id" is not explicitly defined.

But I do not concur with the consequence that all Accounting-On/Off must
be treated as an atomic operation for the entire NAS.

If a reaction to this admitted ambiguity is needed, IMHO it should not
take the form of an errata which retroactively makes everyone else's
halfways reasonable assumption of behaviour incorrect, but take the form
of an RFC making the desired behaviour explicit.

In that latter case, I am even against the errata Notes suggestion -
there is no need for "Scoped-Accounting-*" - instead, an RFC can very
simply clarify the matters by stating:

"Presence of additional attributes in Accounting-On/Off means that
accounting is starting/stopping only for sessions matching the
attributes that are present in the packet."

Thinking of it further, *that* would also be an errata text I could live
with :-)

But an interesting nuance to discuss. Looking forward to Lionel's opinion.

Greetings,

Stefan Winter

Am 28.09.2015 um 10:46 schrieb Benoit Claise:
> FYI.
> 
> Regards, Benoit
> 
> 
> -------- Forwarded Message --------
> Subject:     Re: [Technical Errata Reported] RFC2866 (4485)
> Date:     Sun, 27 Sep 2015 20:07:05 -0700
> From:     Carl Rigney <[email-masked]>
> To:     [email-masked], [email-masked], [email-masked],
> [email-masked]
> CC:     [email-masked]
> 
> 
> 
> That seems like a reasonable clarification to me.
> 
> -- 
> Carl Rigney
> [email-masked]
> 
> On Sun, Sep 27, 2015 at 9:51 AM, RFC Errata System
> <[email-masked]> wrote:
> 
>     The following errata report has been submitted for RFC2866,
>     "RADIUS Accounting".
> 
>     --------------------------------------
>     You may review the report below and at:
>     http://www.rfc-editor.org/errata_search.php?rfc=2866&eid=4485
> 
>     --------------------------------------
>     Type: Technical
>     Reported by: Nick Lowe <[email-masked]
> 
>     Section: 5.1
> 
>     Original Text
>     -------------
>     This attribute indicates whether this Accounting-Request
>     marks the beginning of the user service (Start) or the end (Stop).
> 
>     It MAY be used by the client to mark the start of accounting
>     (for example, upon booting) by specifying Accounting-On and
>     to mark the end of accounting (for example, just before a
>     scheduled reboot) by specifying Accounting-Off.
> 
>     Corrected Text
>     --------------
>     This attribute indicates
>     whether this Accounting-Request marks the beginning of the
>     user service (Start) or the end (Stop).
> 
>     It MAY be used by the client to mark the start of accounting
>     for the NAS (for example, upon booting) by specifying
>     Accounting-On and to mark the end of accounting for the NAS
>     (for example, just before a scheduled reboot) by specifying
>     Accounting-Off.
> 
>     Notes
>     -----
>     Some RADIUS client implementations send scoped Accounting-On
>     and Accounting-Off Accounting-Request packets.  This is
>     seen, for example, with some wireless APs that include a
>     Called-Station-Id attribute to scope to a Basic Service Set (BSS).
> 
>     This is an incorrect interpretation of the RFC that is not
>     backwards compatible with consumers of RADIUS accounting
>     information, yet the RFC is ambiguous on this point.
> 
>     The RFC must be clear that Accounting-On and Accounting-Off
>     apply to the whole NAS and cannot be scoped in this manner.
> 
>     New Acct-Status-Type values must instead be defined to allow
>     this, perhaps named something like Scoped-Accounting-On and
>     Scoped-Accounting-Off.
> 
>     Instructions:
>     -------------
>     This erratum is currently posted as "Reported". If necessary,
>     please use "Reply All" to discuss whether it should be
>     verified or rejected. When a decision is reached, the
>     verifying party (IESG) can log in to change the status and
>     edit the report, if necessary.
> 
>     --------------------------------------
>     RFC2866 (draft-ietf-radius-accounting-v2-05)
>     --------------------------------------
>     Title               : RADIUS Accounting Publication
>     Date    : June 2000
>     Author(s) : C. Rigney
>     Category            : INFORMATIONAL
>     Source : Remote Authentication Dial-In User Service
>     Area : Operations and Management
>     Stream              : IETF
>     Verifying Party     : IESG
> 

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

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Sep 2015 07:37:07 -0400

On Sep 28, 2015, at 7:09 AM, Stefan Winter <[email-masked]> wrote:
> But that statement is not a given.

  The main problem with the RADIUS RFCs is that they make a lot of assumptions, and leave a lot unsaid.  As a result, a huge portion of odd behaviour is neither permitted nor denied.

  I've had *many* discussions with people who claim "X is allowed by the RFCs".  No... it's not *disallowed*.  But there is no statement saying "You can do X".

  The same applies here.

> the RFC states in 4.1 that
> 

  Yes, but that's a separate issue.

> the text "(for example, just before a scheduled reboot)" is really jsut

  This is a problem with ambiguity in the language.  Is it:

a) On/Off is used to signal the start or stop of RADIUS accounting for the NAS.  e.g. for example, when the NAS boots or is about to go down

  or

b) On/Off is use to signal (for example) the start or stop of RADIUS accounting.

  I think the answer is (a).  The interpretation of (b) would indicate that On/Off can really mean anything.  Which makes them useless.

> Called-Station-Id" is not explicitly defined.

  Like too many things in RADIUS.

  The problem is that until recently, *everyone* treated On/Off as "NAS reboot".  And marked all "matching" sessions as offline.

  I say "matching" sessions because the RFCs are silent on this.  Which means much behaviour is implementation-defined.

> be treated as an atomic operation for the entire NAS.

  I would agree to that.  It's what everyone has been doing until fairly recently.

> of an RFC making the desired behaviour explicit.

  I see the errata as documenting existing practice.

> attributes that are present in the packet."

 *Which* attributes?  All of them?  None?  Some random sample?

  You can't just wave your hands and go "People will know what I mean".  This errata exists precisely of ambiguities in the specs.

  I fully support a new value for Acct-Status-Type for "subsystem on/off".  Since the values for Acct-Status-Type are assigned by "expert review", there's nothing stopping us from doing that now.  There are (approximately) 2^32 unused values for Acct-Status-Type.  I suggest that explicit descriptions of behaviour (Subsystem on/off) is better than implicit descriptions (On/Off with ???? some different attributes)

  The various vendors implementing the *changed* behaviour for On/Off didn't request a new value.  Doing so would have avoided this problem.

  I *really* think that On/Off is the wrong thing to  use for subsystem reboot.  At least until we have some *standard* for what a "session identification attribute" is.  We had that discussion with RFC 5176, and everyone agreed to disagree.  Which makes me think any agreement is impossible.

> <0x8A39DC66.asc><0x8A39DC66.asc>_______________________________________________
> AAA-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aaa-doctors

---

From: Benoit Claise <[email-masked]>
Date: Wed, 30 Sep 2015 15:50:39 +0200

Including the AAA doctors.

B.
> Hi all,
>
> I ought to supply you with the response that I have just had from
> Aerohive Tier 3 regarding their RADIUS client implementation in
> HiveOS, the OS for their APs, as it is pertinent to what is being
> considered.
>
> Please feel free to copy it to the list.
>
> Without the erratum being approved to close the ambiguity, it is
> unlikely that I will be able to get this changed.
>
> I agree with Alan that On-Off is conceptually meaningless without it
> applying to the whole NAS. I believe the erratum is valid and should
> be approved therefore.
>
> Kind regards,
>
> Nick Lowe
>
> "From: Keith McIntyre (Aerohive)
> To: Nick Lowe
> Cc: Gary Smith
> Subject: Accounting-On and Accounting-Off should be sent, by default,
> on a per-NAS basis not per-BSS
>
> Hey Nick,
>
> Engineering have reviewed the CFD and the information that you
> provided. They are in agreement that this is not a specific defect in
> the way that Aerohive have implemented this feature, rather this is a
> request to improve upon it.
>
> Aerohive complies with the way the RFC is written and there is no
> specific defect reported. As a result I will open a Feature Request to
> request enhancement as you’ve requested. Based on the current
> understanding this is a request to enhance currently designed
> behaviour with no specific HiveOS defect reported.
>
> If you have any questions I will be happy to discuss and provide a
> followup to our engineering team.
>
> Cheers,
>
> Keith"
>
> On Mon, Sep 28, 2015 at 4:07 AM, Carl Rigney <[email-masked]> wrote:
>> On Sun, Sep 27, 2015 at 9:51 AM, RFC Errata System <[email-masked]> wrote:
>>
> .

---

From: Alan DeKok <[email-masked]>
Date: Wed, 30 Sep 2015 15:30:47 -0400

I think this errata should be accepted.

  I also think a solution to the larger problem would be to assign new values for Acct-Status-Type, of Subsystem-On and Subsystem-Off.  That would allow NAS vendors to indicate that a portion of the NAS has rebooted, without affecting the rest of the users.

  I've put a write-up online at:

http://freeradius.org/rfc/acct_status_type_subsystem.html

  Since new values for Acct-Status-Type can be assigned via expert review, it may be quick to get new values.

  I've sent in a request to IANA for allocation, and referenced the above page.

On Sep 30, 2015, at 9:50 AM, Benoit Claise <[email-masked]> wrote:

> _______________________________________________
> AAA-DOCTORS mailing list
> [email-masked]