Re: [OPSAWG] RADIUS Extension, Getting Started
On Jul 6, 2020, at 11:40 AM, Massameno, Dan wrote: > > Dear Ops and Management Area WG, > > There have been a number of great suggestions on where to post this document > (Thanks Stefan!). I'm now emailing opsawg@ietf.org and cc'ing > rad...@ietf.org. > > The draft is posted here... > https://tools.ietf.org/html/draft-massameno-radius-lb-00 > > Do I need an official IETF sponsor? Would it help to try and get a vendor > interested in implementing the protocol? Cisco is our primary vendor at Yale > University. I was wondering if there is anyone on either of these working > groups that communicates with Cisco people on a regular basis? There are lots of Cisco people. I'm sure some of those people have opinions. There are a few things ongoing here. The RADEXT WG is still alive, but inactive. There is a still an open discussion in the WG about previous documents which addressed shortcomings in the base RADIUS protocol. The polite version is that the long-term RADEXT participants supported one draft. Many people who had never been involved with RADEXT supported a competing draft. There was never any resolution. The RADEXT WG was left in limbo. I'll avoid the subject of the best place for this draft. Overall, I would oppose this draft. For the simple reason that brains belong in the RADIUS server, not in the NAS. NAS vendors haven't even implemented the retransmission behaviours suggested in RFC 5080 Section 2.1, which is well over a decade old at this point. If they can't do that, how can they implement an even more complex load-balancing system? Further, there is no standard in RADIUS for load-balancing with fail-over and fail-back. Every NAS vendor and RADIUS vendor does something different. While this document tries to address that issue, it does not address a number of key points. I do have a review, as follows. Many of these issues given below are nits, and can be fixed by rewording the document, or moving to an approach which follows existing standards (RFC 6158, RFC 6929, RFC 8044). However, for reasons given above, I don't think it's useful to move ahead with this document. * Section 2 - Message Summary I recommend deleting this part. The RADIUS packet format is well known. There's no need to repeat the definition here. Just refer to RFC 5997. * Section 2.2 - nitpick: 191 is not defined, so it's likely best to leave this attribute value as TBD, even if IANA is likely to choose 191. Further, RADIUS definitions use consistent names for attributes. The names do not change when they're used in different packet types. The attribute should just be called something like "Load-Balance-Status" * Section 2.3.2 - the text here is simply wrong. The Request-Authenticator is not "hashed with the identity material from the calling-station and the RADIUS shared secret." RFC 5997 Section 5 already mandates the use of Message-Authenticator with Status-Server. I suggest deleting 2.3.2 entirely. * Section 3 - the definition of the LB-Request does not satisfy the requirements of RFC 6929 Section 5.2. There is no reason to use a 16-bit data type here. https://tools.ietf.org/html/rfc6929#section-6.2 RFC 8044 also defines data types which are appropriate for use in RADIUS. That RFC also suggests that there is no longer need for ASCII art in most cases, as attribute definitions can just use predefined data types. Also in general, reserved bits should go at the top of an integer attribute. Status bits should be in the lower bits. * Section 4.1 redefines attribute 191 to contain completely different data. This definition violates the prohibition on polymorphic attributes given in RFC 6159 Section 3.4 https://tools.ietf.org/html/rfc6158#section-3.4 I suggest using two different attributes, one for signalling client to server, and another for responding server to client. The text in this section is also unclear: Server_Info The String field is one or more server_info PDUs. Each PDU defines the status of a single server and its defining characteristics. What does that mean? Is the intent to carry the SVR-Record attributes inside of attribute 191? If so, then using attribute 191 as both a 16-bit bitfield, and as a TLV carrier is very odd. It's safe to say that nothing will ever support this. I suggest using two different attrributes. I suggest simply relying on the existence of one or more SRV-Record attributes in the reply. There is no need to repeat the LB-* attribute. * Section 5 The SRV-Record TLV This section does not define any TLV attribute. It's not clear what this means. * Section 5.1 and 5.2 It's not clear why two different attributes are needed. Why not just use SRV-Record? And there's no need to repeat ASCII art. RFC 8044 Section 3.13 already defines the TLV data type, and format. You should just reference that. * Section 5.3 defines a table of
Re: [OPSAWG] RADIUS Extension, Getting Started
Dear Ops and Management Area WG, There have been a number of great suggestions on where to post this document (Thanks Stefan!). I'm now emailing opsawg@ietf.org and cc'ing rad...@ietf.org. The draft is posted here... https://tools.ietf.org/html/draft-massameno-radius-lb-00 Do I need an official IETF sponsor? Would it help to try and get a vendor interested in implementing the protocol? Cisco is our primary vendor at Yale University. I was wondering if there is anyone on either of these working groups that communicates with Cisco people on a regular basis? Thank you for your help. --Dan -Original Message- From: Stefan Winter Sent: Friday, July 3, 2020 01:52 To: Joe Clarke (jclarke) ; Massameno, Dan Cc: war...@kumari.net; Benjamin Kaduk ; Roman Danyliw ; Rob Wilton (rwilton) ; OpsAWG-Chairs ; radext-cha...@ietf.org Subject: Re: RADIUS Extension, Getting Started Hello Joe, thanks for reaching out. RADEXT is dormant since a number of years already. I'm afraid if you were to send the document that way, you would get little to no review. I think the best way forward is to take this to OPSAWG and send a mail to radext about the draft just in case. Greetings, Stefan Winter Am 30.06.20 um 17:21 schrieb Joe Clarke (jclarke): > Thanks, Dan. I’m also copying the radext-chairs to get their perspective on > this. > > Joe > >> On Jun 30, 2020, at 11:03, Massameno, Dan wrote: >> >> Warren, >> >> I have the RADIUS extension draft now posted: >> https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftoo >> ls.ietf.org%2Fhtml%2Fdraft-massameno-radius-lb-00data=02%7C01%7C >> dan.massameno%40yale.edu%7Cc0b3c01a3a9d44d004c308d81f152ef2%7Cdd8cbeb >> b21394df8b4114e3e87abeb5c%7C0%7C0%7C637293523139392341sdata=7dOp >> ZmU5Xsj2tusf2Fiukqv1oxd2b8uL4Po%2BI04hw%2BE%3Dreserved=0 >> >> Abstract >> >> This document describes a method for a Network Access Server (NAS) to >> dynamically discover all available RADIUS servers. It defines a new >> message type within the STATUS-SERVER message, which is requested by >> the NAS and provided by the RADIUS server. The NAS is then able to >> load balance its RADIUS messages across multiple RADIUS servers based >> on priority and weight supplied by the initial server. >> >> Base on the draft do you have a better idea on if this should be posed into >> RADEXT or OPSAWG? I must admit I am not familiar with either of these >> groups. >> >> Thank you for your help. >> >> --Dan >> >> -Original Message- >> From: Massameno, Dan >> Sent: Thursday, June 25, 2020 10:56 >> To: Rob Wilton (rwilton) >> Cc: Benjamin Kaduk ; Roman Danyliw ; >> OpsAWG-Chairs ; Warren Kumari >> >> Subject: RE: RADIUS Extension, Getting Started >> >> Rob, >> Thank you and the extended team for all your help. I have uploaded >> draft-massameno-radius-lb to the I-D Submission system. Also attached is >> the PDF version. >> >> I'm very much interested in seeing how the process goes from here. Please >> let me know how I may be of assistance. >> >> --Dan >> >> -Original Message- >> From: Warren Kumari >> Sent: Monday, June 22, 2020 18:00 >> To: Rob Wilton (rwilton) >> Cc: Benjamin Kaduk ; Massameno, Dan >> ; Roman Danyliw ; OpsAWG-Chairs >> >> Subject: Re: RADIUS Extension, Getting Started >> >> On Mon, Jun 22, 2020 at 1:06 PM Rob Wilton (rwilton) >> wrote: >>> Hi Ben, >>> >>> Good catch re Radext, copying Warren. Warren, the question is whether >>> RADEXT is still active and taking new work, or whether it should go to >>> OPSAWG instead? I have a slight concern whether we will get enough >>> interest for this work in OPSAWG ... >> Without knowing a bunch more about the draft I don't really think that this >> is a question that I can usefully weigh in on. >> >> If it is an extension to RADIUS/is heavily RADIUS focused, then RADEXT is >> probably the right place -- but, it could always be aimed at RADEXT (put >> -radext- in the draft name), but we can try and stir up some interest in >> OPSAWG. If it turns out that it is RADIUS related, and RADEXT doesn't want >> to pick it up and run with it, perhaps that's a strong signal that RADEXT >> should be closed...? >> >> W >> >>> Regards, >>> Rob >>> >>> -Original Message- From: Benjamin Kaduk Sent: 21 June 2020 03:42 To: Massameno, Dan Cc: Rob Wilton (rwilton) ; Roman Danyliw ; OpsAWG-Chairs Subject: Re: RADIUS Extension, Getting Started On Fri, Jun 19, 2020 at 12:58:12PM +, Massameno, Dan wrote: > Rob, > This sounds great. With the links provided by Roman I am > reviewing the literature to make sure my draft has everything it needs to start the process. I found references to xml2rfc and kramdown, which I also want to run it through. > Thank you for your help. I would be happy to have someone take a > look before it's posted. As soon as I have it formatted
