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

From: Benoit Claise <[email-masked]>
Date: Tue, 29 Sep 2015 16:23:12 +0200

And another one to discuss.

Regards, Benoit
> 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=4488
>
> --------------------------------------
> Type: Technical
> Reported by: Nick Lowe <[email-masked]>
>
> Section: 5.11
>
> Original Text
> -------------
> Acct-Multi-Session-Id
>
>     Description
>
>        This attribute is a unique Accounting ID to make it easy to link
>        together multiple related sessions in a log file.  Each session
>        linked together would have a unique Acct-Session-Id but the same
>        Acct-Multi-Session-Id.  It is strongly recommended that the Acct-
>        Multi-Session-Id contain UTF-8 encoded 10646 [7] characters.
>
> Corrected Text
> --------------
> Acct-Multi-Session-Id
>
>     Description
>
>        This attribute is a globally unique Accounting ID to make it easy
>        to link together multiple related sessions in a log file.  Each
>        session linked together would have a globally unique
>        Acct-Session-Id but the same Acct-Multi-Session-Id.  It is
>        strongly recommended that the Acct-Multi-Session-Id contain
>        UTF-8 encoded 10646 [7] characters.
>
> Notes
> -----
> The RFC does not explicitly state the scope of uniqueness and it must be clarified to state that Acct-Multi-Session-Ids are expected to be globally unique. I believe this to be the original, implicit intent of the author.
>
> An ideal Acct-Multi-Session-Id would have the properties of a GUID/UUID.
>
> See Errata 4487 for the same clarification on the Acct-Session-Id.
>
> 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
>
> .
>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 29 Sep 2015 10:47:04 -0400

I think the Acct-Session-Id *should* be globally unique, but I think just adding the word "global" is insufficient.

  RFC 2865 Section 3 says this about the Request Authenticator:

         ...  the Request Authenticator field
         SHOULD exhibit global and temporal uniqueness.

  We could have similar text about uniqueness for Acct-Session-ID, and Acct-Multi-Session-ID.

  On a practical note, I've found that it's pretty much impossible to rely on Acct-Session-ID as being in any way unique.  Most NAS equipment has *terrible* choices for Acct-Session-ID.  e.g. start at "00000000" when the NAS reboots, and increment for every new session.  Having IDs generated via a cryptographically strong pseudo-random number generate would be *much* better.

  I typically end up creating a separate ID, let's call it "Better-Acct-Session-ID".  That ID is composed of a cryptographic hash of the original Acct-Session-ID, and a number of other session identification attributes.  That ID can be relied on to be unique in cases where Acct-Session-ID is essentially garbage.

  So.. I'm in favour of making RFC 2866 clearer that Acct-Session-ID is UNIQUE, and not just sort of unique, sometimes, maybe.

On Sep 29, 2015, at 10:23 AM, Benoit Claise <[email-masked]> wrote:

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

---

From: Benoit Claise <[email-masked]>
Date: Wed, 30 Sep 2015 00:02:00 +0200

[including the AAA doctors]

Regards, Benoit
> Thanks for the clarification Carl!
>
> At first sight, to me, it is far more realistic and pragmatic to see a
> globally unique id in the Acct-Session-Id going forward rather than
> introducing another attribute.
>
> Systems would likely remain non-compatible for a long time to a new
> attribute. There would be inherent complexity doing this that would
> easily lead to nuanced handling issues.
>
> A clarification to the RFC for the Acct-Session-Id, which is not clear
> in this area today so there is room for manoeuvre, would regress very
> little and fix a lot.
> That is, despite what the original intent was, it is a highly
> backwards compatible clarification that enhances and improves RADIUS.
>
> On balance, I feel that it is the right thing to do when the poor
> quality Acct-Session-Id issues we see today are considered, along with
> the kludges necessary to work with that accounting information. (Even
> then such kludges do not always work and duplicates are encountered.)
>
> The present status quo is highly undesirable and seems unnecessary.
>
> Poor implementations could and would carry on as normal, a
> clarification to the RFC would provide the feedback means to get
> better RADIUS client implementations in the field going forward.
>
> Kind regards,
>
> Nick Lowe
>
> On Tue, Sep 29, 2015 at 9:12 PM, Carl Rigney <[email-masked]> wrote:
>> It was not at all the intent of the original RADIUS working group
>> to make Account-Session-Id or Acct-Multi-Session-Id globally unique.
>> They were only intended to be unique to that NAS on that boot, as
>> a way for servers to acknowledge to the NAS that they'd received
>> the record and the NAS could remove it from its retransmit buffer,
>> and to make it easier for the Accounting Server to match start and
>> stop and interim records, using the ID and either NAS-IP-Address
>> or NAS-Identifier.  The Acct-Session-Id example given explicitly
>> acknowledges it might wrap.
>>
>> There was never any idea that any given NAS would know about the
>> existence of any other NAS, or maintain a lot of state between boots
>> other than knowing its RADIUS server IP address and shared secret.
>>
>> RADIUS was written to be runnable on boxes with very weak CPUS
>> (remember the 80286?) and limited memory, back in the days when one
>> megabyte was a lot.
>>
>> If you want some cryptographically strong universal ID, I'd definitely
>> recommend allocating a new Attribute for that, instead of attempting
>> to shoehorn it retroactively into an attribute never intended for it.
>>
>> That's my 2 cents as one of the original authors.
>>
>> --
>> Carl Rigney
>> [email-masked]
> .
>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 29 Sep 2015 18:25:09 -0400

>> introducing another attribute.

  Unfortunately, such technical changes are outside of the scope of an errata.

>> The present status quo is highly undesirable and seems unnecessary.

  As with many things RADIUS, unfortunately.  We're left with being compatible with a protocol designed 20+ years ago.

>> better RADIUS client implementations in the field going forward.

  This errata could arguably have gone into the "issues and fixes" document, as a clarification.  Unfortunately, it was missed.

>>> acknowledges it might wrap.

  That's OK.

>>> other than knowing its RADIUS server IP address and shared secret.

  I don't think such tracking is necessary.

>>> (remember the 80286?) and limited memory, back in the days when one

  Sure. 

>>> to shoehorn it retroactively into an attribute never intended for it.

  The original intent of Acct-Session-ID is nice to know, but I don't think it should be a limiting factor.  The main requirements are inter-operability, and no change to the *meaning* of the attribute.  I think the suggestion to create it's value via a CSPRNG meets all of those criteria.  There is no requirement that it *must* wrap, or that it *must* be an incrementing counter.

  Every other entity in the network treats Acct-Session-ID as an opaque token.  By definition, changing the *contents* of the opaque token has no effect on other entities in the network.

  In any case, I think the errata should be rejected.  It's (IMHO) a good idea, but an errata isn't really the place to make technical changes to the RADIUS protocol.

  Let's see if the RADEXT WG has enough bandwidth for yet another "update RADIUS" document. :)

  Alan DeKok.