Subject: [radext] working group next steps

From: Stefan Winter <[email-masked]>
Date: Tue, 5 Sep 2017 08:19:41 +0200

Hello!

During IETF99 in Prague we discussed the future of this working group.

Given the very low amount of discussion on the list, almost nobody being
available for document review, and almost empty sessions at physical
meetings, the outcome was that the radext working group has no real future.

The plan for the immediate future is to

* finish the ongoing work

* close the WG

* keep the list open

New proposed work on RADIUS will subsequently be discussed on the
mailing list and can take the AD sponsoring or opsawg route.

There was consensus in the meeting (which wasn't all that difficult
considering that the meeting room was almost empty). As usual, we are
asking to confirm this on the mailing list; any objections should be
voiced within two weeks, i.e. until 22 Sept.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

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: Enke Chen <[email-masked]>
Date: Mon, 4 Sep 2017 23:29:14 -0700

Hi, Stefan:

In the WG meeting minutes of IETF99, it says that:

   It is proposed to push forward the draft-chen-radext-identifier-attr. This will
   be discussed on the mailing list.

   It has been decided to finish the ongoing work, including the non-WG document on
   Extended ID and then close the WG.

Can we request WG adoption of draft-chen-radext-identifier-attr as an ongoing
work item?

Thanks.  -- Enke

On 9/4/17 11:19 PM, Stefan Winter wrote:
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 5 Sep 2017 15:30:13 -0400

> Can we request WG adoption of draft-chen-radext-identifier-attr as an ongoing

  I still prefer my draft.  But I would like to see *some* discussion of the subject.

  some comments:

- the identifier should just be a 32-bit number.  There's no need to reserve 2 bits for the "status" field.

- the draft offers little guidance to implementors, and has minimal discussion of the compatibility of this proposal with "standard" RADIUS.

  If the WG does decide to use extended-attars, I would suggest merging that document with the additional text from my proposal.  Only minor edits should be necessary.

---

From: Astrid Smith <[email-masked]>
Date: Tue, 5 Sep 2017 13:01:51 -0700

On Tue, Sep 05, 2017 at 03:30:13PM -0400, Alan DeKok wrote:
> > > It is proposed to push forward the
> > > draft-chen-radext-identifier-attr. This will be discussed on the
> > > mailing list.
> > 
> > > It has been decided to finish the ongoing work, including the
> > > non-WG document on Extended ID and then close the WG.
> > 
> > Can we request WG adoption of draft-chen-radext-identifier-attr as
> > an ongoing work item?
> 
> - the draft offers little guidance to implementors, and has minimal
>   discussion of the compatibility of this proposal with "standard"
>   RADIUS.
> 
> If the WG does decide to use extended-attars, I would suggest
> merging that document with the additional text from my proposal.
> Only minor edits should be necessary.

Hi, new to the list here - I work at F5, maintaining support for
RADIUS (and other protocols) in BIG-IP.

Neither of these proposals seem to clash with the RADIUS proxy which I
maintain, because we don't try to correlate request/response messages.

I like the DeKok draft a lot, particularly because it doesn't add any
overhead to most packets.

However, if we were to add a request/response pairing feature, an
explicit ID as in Chen's draft would be easier for me to implement
cleanly.  I suspect that I'm not alone in this.

-- 
astrid smith     -------------------
--<[ c y b e r  |  s o f t w a r e  |  e n g i n e e r ]>--
    ------------                     ------------------

---

From: Enke Chen <[email-masked]>
Date: Tue, 5 Sep 2017 13:24:30 -0700

Hi, Alan:

> - the identifier should just be a 32-bit number.  There's no need to reserve 2 bits for the "status" field.

Are you saying that the "status" field is not needed, or it should be a separate field? 

If the former, as stated in the draft:

   ... where the 2-bit Status field is to be used in a Status-Server message
   to discover the support for the Extended Identifier feature. :

If the latter, I think that is just personal preference in encoding.
In this case we need 2 bits, and there are enough bits in the 4-byte field.

> 
> - the draft offers little guidance to implementors, and has minimal discussion of
>   the compatibility of this proposal with "standard" RADIUS.

Could be be more specific about which part of the draft is not clear for implementation?

On backward compatibility, the proposal is completely compatible as it follows
the well-established practice of using the "Status-Server" message for discovery.
If it is desired, sure we can add minimal discussion. 

> 
>   If the WG does decide to use extended-attars, I would suggest merging that document
>   with the additional text from my proposal.  Only minor edits should be necessary.
> 

Sure, we can work together on these minor edits.  Actually I proposed to collaborate
several months ago, and never received a reply from you. Shall we work together offline?

Thanks. -- Enke

---

From: Alan DeKok <[email-masked]>
Date: Tue, 5 Sep 2017 17:14:10 -0400

> Are you saying that the "status" field is not needed, or it should be a separate field? 

  I'm saying the field isn't needed.

>   to discover the support for the Extended Identifier feature. :

  If the extended-identifier attribute exists in a Status-Server message, it's an indication that the client supports the attribute.  If the attribute exists in a reply to Status-Server, it indicates that the server supports the attribute.

> In this case we need 2 bits, and there are enough bits in the 4-byte field.

  I'm saying simply the fact that it exists at all is good enough.  And RFC 6929 suggests that non-standard data fields are a bad thing.

> Could be be more specific about which part of the draft is not clear for implementation?

  Compare my draft to yours.  There's a huge difference.

  Your draft basically says "use an extended ID".  Mine goes into details of what that means to a client, what it means to a server, how each of them manages the data, how the change affects RADIUS proxying.

  i.e. it explains in detail *all* of the side effects of changing RADIUS.

> If it is desired, sure we can add minimal discussion. 

  Sure... and what happens when things go wrong?

  When a client sends Status-Server with extended ID, does it have to wait for a response before sending other packets?  Or can it just send lots of packets, and add in Extended-Id later?  If so, how does this all work?

  One major purpose of RFCs is to guide implementors in the corner cases.  Everyone knows how to add an attribute to a packet.  That's the easy part.  The hard part is ensuring that all of the corner cases are explained.

  Just compare the two documents to see what's missing from your draft.  I'm not saying your draft is wrong.  I'm saying that there are many cases where an implementor will read it, implement part of it, and then get to a point where he just doesn't know what to do...  so he picks something, and hopes for the best.

  Having implementation-defined behaviour is a bad idea.

> several months ago, and never received a reply from you. Shall we work together offline?

  I did reply... I suggest waiting for the rest of the WG to make comments before changing either draft.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 5 Sep 2017 17:16:48 -0400

I strongly prefer Alan's draft. 

> On Sep 5, 2017, at 3:30 PM, Alan DeKok <[email-masked]> wrote:
> 
>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 5 Sep 2017 17:17:16 -0400

> overhead to most packets.

  And a large overhead to reply packets.  :( Oh well.

  On major benefit is that it is explicitly an hop-by-hop identifier.  And there is no way to accidentally make the identifier "leak" across proxies.

  One minor drawback is that it's easy for people to read PCAP traces and see an "extended identifier" attribute in request / reply.  It's harder for them to look at PCAP traces and somehow figure out that only the *reply* contains an extended identifier.

> cleanly.  I suspect that I'm not alone in this.

  I've done both in FreeRADIUS (v4).  The code difference isn't that large.  Both are about ~300 line patches.

  Alan DeKok.