Subject: [radext] Control of RFC 3580. Transfer to RADIUS WG possible?

From: Nick Lowe <[email-masked]>
Date: Tue, 6 Oct 2015 16:19:38 +0100

Dear list,

Might it be possible for RFC 3580 to be transferred to be under the
control of the RADIUS WG? Presently, as far as I can see, it is not, I
believe it should be.

I would certainly like to try to convince others that it is necessary
in any case to clarify this RFC as it does not meet the needs of
implementors today.

There is a persistent technical error, being charitable... limitation,
in RFC 3580 in that “Access Point” is used instead of “Basic Service
Set” (BSS). This has lead to inconsistencies in RADIUS client
behaviour, it is unnecessary and should, I believe, be corrected.

The RFC was written prior to central controllers being common place
and does not specify the expected behaviour where they are,
particularly when it comes to roaming from one BSS to another BSS.
In the Subsystem-on and Subsystem-off thread, I have drafted the type
of change that I would like to see to the Called-Station-Id and
Acct-Multi-Session-Id advise given.

Access points may contain multiple radios and, for each radio, offer
multiple Extended Service Sets (colloquially multiple SSIDs), which
each use a discrete Basic Service Set (BSS). This ability is commonly
known under the umbrella term Virtual Access Point (VAP).

Stating an Access Point MAC address is at best meaningless as it is
ambiguous, at worst it is harmful.

A client can roam from one BSS to another BSS on the same AP,
typically between 2.4 GHz and 5 GHz BSSes.

I also wish to see a statement on the expected interaction of 802.1X
re-authentication with Class attributes.

1) Should Class attributes being accounted with be replaced with
subsequent values provided by a RADIUS server in the Access-Accept
during 802.1X re-authentication? I think so.

2) What should happen if no Class attributes are provided during
802.1X re-authentication in the Access-Accept, yet the original
authentication possessed one or more? I think the original Class
attributes should continue to be accounted with.

3) Should the RADIUS server ensure that the Class attribute(s)
provided in the Access-Accept when 802.1X re-authentication takes
place matches those that were previously so that this becomes
technically moot and not the concern of the NAS?

Furthermore, should a Stop and Start should be observed when 802.1X
re-authentication takes place? This is not specified anywhere. The
expected behaviour should be specified. I believe that no Stop and a
Start should be observed as the session continues.

The construction recommended for the Acct-Multi-Session-Id is also
suboptimal as it requires time synchronisation to have occurred. This
is not always possible for an 802.11 NAS, a UUID is therefore
preferable to guarantee global and temporal uniqueness.

There is also a need to specify that because SSIDs can be UTF-8
encoded, a Called-Station-Id that contains BSSID:SSID SHOULD be UTF-8
encoded. This is missing from the RFC.

The proposed Subsystem-on and Subsystem-off require something to use
to define and scope to the subsystem. For 802.11, I believe that
combination should be BSSID:SSID

Ideally, the Called-Station-Id value used for a session SHOULD match
the Called-Station-Id that is defines the subsystem. Clearly that
should not be a MUST requirement though.

Regards,

Nick

---

From: Alan DeKok <[email-masked]>
Date: Tue, 6 Oct 2015 11:30:48 -0400

> control of the RADIUS WG? Presently, as far as I can see, it is not, I

  RFCs are under the control of the IETF / IESG.  They can delegate updates to any WG they desire.

  In this case, if there is consensus and charter updates, the RADEXT WG could update 3580.

> in any case to clarify this RFC as it does not meet the needs of

  We'll put it on the list of documents to fix RADIUS. :(

> behaviour, it is unnecessary and should, I believe, be corrected.

  That's less an error than a limitation of the time it was written.

> re-authentication with Class attributes.

  My $0.02 is to write a document which updates RFC 3580 and others.  I can assist.

  If the document is simple and has no objections... it might take 3 years to get published as an RFC.

> during 802.1X re-authentication? I think so.\

  I would agree.

> attributes should continue to be accounted with.

  I agree.

> technically moot and not the concern of the NAS?

  I'm not sure.

  I would *prefer* to push more behaviour off to the RADIUS server.  There are 100x as many NASes as RADIUS servers, and the RADIUS servers get upgraded more often.  So it's easier to fix things by upgrading the RADIUS servers.

> Start should be observed as the session continues.

  I agree.  The difficulty here is the ambiguity / race condition.

  If Session-Timeout is 1000 seconds.  Is the session *stopped* at 1000 seconds?  Or does the supplicant re-authenticate at 999 seconds, so that the session can continue?

  If the re-authentication fails, does the NAS send Acct-Status-Type = Stop?

  If the re-authentication succeeds, does the NAS send an Acct-Status-Type = Start?

  The specs are *full* of ambiguities which cause problems in the real world.

> preferable to guarantee global and temporal uniqueness.

  I agree.

> encoded. This is missing from the RFC.

  I agree.

> combination should be BSSID:SSID

  That's a good idea, but it's difficult to define exactly what a "session" is, or what a "scope" is.

> should not be a MUST requirement though.

  I agree.

  Alan DeKok.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 6 Oct 2015 12:14:47 -0400

Hi,

Just one quick question...

>   If the document is simple and has no objections... it might take 3 years to get published as an RFC.

Is this a result of the workload of Radext, editors, or process
problems?  If it's process problems, let's fix that as I don' want to
see drafts taking 3 years to publish. If it is workload and priorities
for the WG, that is another matter (we can look at that as well).

Thanks,
Kathleen

> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

-- 

Best regards,
Kathleen

---

From: Alan DeKok <[email-masked]>
Date: Tue, 6 Oct 2015 15:05:30 -0400

> for the WG, that is another matter (we can look at that as well).

  It's been the process for as long as I've been involved in RADEXT.  Call it 10+ years?

  Alan DeKok.

---

From: <[email-masked]>
Date: Wed, 7 Oct 2015 14:16:50 +0000

This document was published as Informational RFC through ISE process, so without WG consensus, even if key IETF participants were involved in this work.

Obviously, it does not prevent RADEXT to work on a new version of this document. However, before rushing for publishing a bis-version of this document, it would be good to know what would be the purpose of this new document.
The initial aim was to have non-normative text describing how to use RADIUS with 802.1X, and this material was put in an information RFC as well as in a non-normative appendix in IEEE specification. 

I know that some cleanup/updates/clarifications are required for this document. But to be really useful,  it could be interesting to know whether IEEE would be happy to endorse/reference the new version of the RFC, especially if some proposed changes have impacts on existing RADIUS implementation. Just to ensure that the proposed modifications/clarifications put in a bis-version will be followed by IEEE community.

And also, what should be the status of this document: Standard track/Informational?

Now, if the work is agreed, the proposed changes straightforward and there is no contentious discussions, I don't see why a 3-year period would be required to publish a new version. It will depend on the amount and type of change.

Regards,

Lionel

-----Message d'origine-----
De : radext [mailto:[email-masked]] De la part de Alan DeKok
Envoyé : mardi 6 octobre 2015 21:06
À : Kathleen Moriarty
Cc : Nick Lowe; [email-masked]
Objet : Re: [radext] Control of RFC 3580. Transfer to RADIUS WG possible?

  Alan DeKok.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 7 Oct 2015 10:50:23 -0400

> Obviously, it does not prevent RADEXT to work on a new version of this document. However, before rushing for publishing a bis-version of this document, it would be good to know what would be the pu…

  To bring the standards up to date with current requirements, and with current use-cases.  To address ambiguities in the current specifications.  To clarify best practices.

  I agree.

> And also, what should be the status of this document: Standard track/Informational?

  Probably the same as RFC 3580, informational.

> Now, if the work is agreed, the proposed changes straightforward and there is no contentious discussions, I don't see why a 3-year period would be required to publish a new version. It will depend…

  I agree.  I'll work with Nick to come up with an I-D.  I won't be in Yokohama, but I can do a remote presentation.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 8 Oct 2015 06:05:20 -0700

So far, the issues discussed relate to accounting, which is a relatively minor aspect of RFC 3580.  
Furthermore, the accounting issues relate largely to IEEE 802.11, rather than to IEEE 802.1X, which was the focus of RFC 3580. 
As a result, it is not at all clear to me why it is necessary to transfer control of this document from IEEE 802 to the IETF, let alone why it is necessary to revise it at all. 
If there is a desire to deal with accounting issues relating to IEEE 802.11, why not create a new document focused on that topic, with review by IEEE 802.11?  If necessary, it can update RFC 3580.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 8 Oct 2015 09:17:19 -0400

> So far, the issues discussed relate to accounting, which is a relatively minor aspect of RFC 3580.  

  Which is good.

> Furthermore, the accounting issues relate largely to IEEE 802.11, rather than to IEEE 802.1X, which was the focus of RFC 3580. 

  Which is also goo.

> As a result, it is not at all clear to me why it is necessary to transfer control of this document from IEEE 802 to the IETF,

  That's not the purpose of the discussion.

> let alone why it is necessary to revise it at all. 

  The revisions were motivated from seeing inter-operability problems, and implementation problems.  The existing RFCs discuss user sessions, but the concept is vague and ill defined.  The guidelines for how a NAS / server should handle user sessions are similarly vague.

  This vagueness causes real-world problems.  I run into this pretty much every week.

> If there is a desire to deal with accounting issues relating to IEEE 802.11, why not create a new document focused on that topic, with review by IEEE 802.11?  If necessary, it can update RFC 3580. 

  That is the best approach, I think.

  Alan DeKok.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 8 Oct 2015 10:35:58 -0400

If the IETF does not have change control, which is the case with some
documents, we can't just pick it up and change/update the document.
Let's figure out if something is needed and then we'll figure out what
we can do or what needs to be done in the IEEE.

Thanks,
Kathleen

-- 

Best regards,
Kathleen