Subject: [radext] A proposal to allow more than 256 packets on any connection

From: Alan DeKok <[email-masked]>
Date: Mon, 24 Apr 2017 16:00:57 -0400

I've written a draft to allow more than 256 packets on any connection.  Note that I'm *not* proposing a change to the Id field, or to much else in the protocol.

  The document is a first draft, and doesn't cover some of the protocol details.  But the concept is very simple:

a) use Status-Server to negotiate the new functionality (see below for details)

b) allow clients to use Request Authenticator as a unique key for packets, in addition to src/dst ip/port, Code, and Id

  i) For Access-Request packets, Request Authenticator is a bunch of random numbers, which is fine.

  ii) for other packet types Request Authenticator is the signature of the packet contents and the secret.  So if the contents are the same, the Request Authenticator is the same.  If the contents are different, it's different.

c) have the server send a new attribute: Original-Request-Authenticator in response packets.  This allows clients to correlate responses with requests, using the key mentioned in (b), above.

  For negotiation, a client sends Status-Server containing Original-Request-Authenticator of all zeroes.  If the server has the functionality, it sends a response containing Original-Request-Authenticator with value copied from the original Request Authenticator.

  All other packet signing / Id management stays the same.

  I think this is the minimal possible change to RADIUS which solves the underlying problem.  As such, I hope it's also the least contentious.

  To do for the spec:

- more text on how Original-Request-Authenticator works in response packets

- more text on why this works for all packet types

- make the text less hacky (it was written in less than a day, after the concept was worked out)

- get WG review (I don't think we can achieve consensus quickly on this)

  Alan DeKok.

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-dekok-radext-request-authenticator-00.txt
> Date: April 24, 2017 at 3:48:56 PM EDT
> To: "Alan DeKok" <[email-masked]>
> 
> 
> A new version of I-D, draft-dekok-radext-request-authenticator-00.txt
> has been successfully submitted by Alan DeKok and posted to the
> IETF repository.
> 
> Name:		draft-dekok-radext-request-authenticator
> Revision:	00
> Title:		Correlating requests and replies in the Remote Authentication Dial In User Service (RADIUS) Protocol via the Request Authenticator.
> Document date:	2017-04-24
> Group:		Individual Submission
> Pages:		14
> URL:            https://www.ietf.org/internet-drafts/draft-dekok-radext-request-authenticator-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-dekok-radext-request-authenticator/
> Htmlized:       https://tools.ietf.org/html/draft-dekok-radext-request-authenticator-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-dekok-radext-request-authenticator-00
> 
> 
> Abstract:
>   RADIUS contains a one-octet Identifier field which is used to
>   correlate requests and replies.  This field limits the number of
>   outstanding requests to 256.  Experience shows that this limitation
>   is problematic for high load systems.  This document proposes to use
>   the Request Authenticator field as an additional unique identifier.
>   The replies can then be correlated to requests by copying the Request
>   Authenticator from the request to a new attribute in the response,
>   called the Original-Request-Authenticator.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Ignacio Goyret <[email-masked]>
Date: Mon, 24 Apr 2017 14:04:56 -0700

At what point would a new header be better instead of hacking new attributes
into the uniqueness equation? And at what point RADIUS becomes Diameter?

Since this proposal would require non-trivial changes to both servers and
clients to agree on a new algorithm, they might as well agree on a new header,
something like this:

struct NewRadiusHeader {
    UINT8   code;
    UINT8   reserved_MBZ;
    UINT16  length;  // length extended from 1
    UINT8   authenticator[16];
    UINT32  identifier;
};

This way, the uniqueness function (src/dst ip/port + id) doesn't need to change.

Just a thought,
-Ignacio

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 24 Apr 2017 14:20:23 -0700

Alan said:

"Note that I'm *not* proposing a change to the Id field, or to much else in
the protocol."

[BA] +1 to that.

RADIUS is 25+ years old, and given the pace of change on the Internet, one
can make a case that protocol age is somewhat akin to "dog years".

That would make RADIUS 175 years old!

Changing the Id field in RADIUS is somewhat akin to attempting a heart
transplant on a 175 year-old.

While some doctor might try this (more as a "cash-ectomy" than a legitimate
procedure), let's not pretend that it is in the best interest of the
patient.

Carry on!

On Mon, Apr 24, 2017 at 1:00 PM, Alan DeKok <[email-masked]> wrote:

>   I've written a draft to allow more than 256 packets on any connection.
> Note that I'm *not* proposing a change to the Id field, or to much else in
> the protocol.
>
> b) allow clients to use Request Authenticator as a unique key for packets,
> in addition to src/dst ip/port, Code, and Id
>
>   ii) for other packet types Request Authenticator is the signature of the
> packet contents and the secret.  So if the contents are the same, the
> Request Authenticator is the same.  If the contents are different, it's
> different.
>
> c) have the server send a new attribute: Original-Request-Authenticator in
> response packets.  This allows clients to correlate responses with
> requests, using the key mentioned in (b), above.
>
>   For negotiation, a client sends Status-Server containing
> Original-Request-Authenticator of all zeroes.  If the server has the
> functionality, it sends a response containing
> Original-Request-Authenticator with value copied from the original Request
> Authenticator.
>
>   I think this is the minimal possible change to RADIUS which solves the
> underlying problem.  As such, I hope it's also the least contentious.
>
>   To do for the spec:
>
> > Title:                Correlating requests and replies in the Remote
> Authentication Dial In User Service (RADIUS) Protocol via the Request
> Authenticator.
> > Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-dekok-radext-request-authenticator-00
> >
> >
> > Abstract:
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
>
>

---

From: Alan DeKok <[email-masked]>
Date: Mon, 24 Apr 2017 17:57:47 -0400

On Apr 24, 2017, at 5:04 PM, Ignacio Goyret <[email-masked]> wrote:
> into the uniqueness equation?

 When you want to use Diameter.

> And at what point RADIUS becomes Diameter?

  When you change the header.

> clients to agree on a new algorithm,

  I don't know what you mean by "new algorithm".  *Any* change to RADIUS requires negotiation.  And any change requires changes on both the client and server.

> they might as well agree on a new header,

  Which requires *more* changes to clients and servers than my proposal.

> This way, the uniqueness function (src/dst ip/port + id) doesn't need to change.

  I'm proposing to change  (src/dst ip/port + id)  to  (src/dst ip/port + id + request-authenticator)

  Which is a smaller change than the one you propose.

  In this proposal, all RADIUS request packets are *identical* to existing RADIUS.  All RADIUS response packets contain one new attribute.  The responses are otherwise 100% standard RADIUS.

  There are *implementation* changes on client and server.  But again, they are largely limited to using "Request Authenticator" in the key that determines packet identity.  The encoding and decoding procedures are *exactly* the same as for standard RADIUS.

  Alan DeKok.

---

From: Ignacio Goyret <[email-masked]>
Date: Mon, 24 Apr 2017 15:25:51 -0700

> When you want to use Diameter.

Or you when you want to minimize changes to RADIUS.

>  When you change the header.

Or when you change the equation that matches pending requests.

A change is a change, regardless of how you want to paint it.

>  I don't know what you mean by "new algorithm".  *Any* change to RADIUS requires negotiation.  And any change requires changes on both the client and server.

Well, you are proposing a new algorithm for handling more pending requests
which requires a new matching function to be used only for certain peers.

At any rate, the point is that changes are required on both ends.
If you are going to change something, why not do a simpler change?

>  Which requires *more* changes to clients and servers than my proposal.

Well, that's your assessment not mine. I see a lot more complex changes
in your proposal since it requires two separate matching trees with
different matching functions.

My suggestion would require a single tree with a single function.
Only the size of the id changes. Everything else stays the same.

>  Which is a smaller change than the one you propose.

Again, your assessment does not match my assessment. Your proposal requires
significant changes in the matching of pending requests which is far
from trivial.

My suggestion requires trivial changes in deciding to use one type of
header versus another when extracting or inserting the initial packet
header.

After extracting the packet header, the rest of the code, including
attribute encoding and decoding, stays exactly the same.

For example, this idea allows me to figure out if it is a duplicate
without having to inspect any of the attributes, just like it is
now possible.

This looks to me like a much smaller and simpler change.

At any rate, it is important to realize that either way, the change
is not compatible with 25+ years of RADIUS.

-Ignacio

---

From: Alan DeKok <[email-masked]>
Date: Mon, 24 Apr 2017 19:07:23 -0400

> A change is a change, regardless of how you want to paint it.

  Some changes are smaller than others.  As a general rule, RADEXT tends to stay with smaller changes.

> which requires a new matching function to be used only for certain peers.

  Yes.

> If you are going to change something, why not do a simpler change?

 Because I disagree that your proposal is simpler.

> Only the size of the id changes. Everything else stays the same.

   The packet encoder / decoder changes.  Don't ignore that.

> significant changes in the matching of pending requests which is far

  Really?  Implementing callback A versus callback B for key comparisons is trivial.

  As someone who's written the most popular RADIUS server on the planet, my experience counts for something.

> header versus another when extracting or inserting the initial packet

  Again, you're changing the packet encoding / decoding.

  You're proposing to use function A versus function B for packet encoding... which is ends up being no different than using function A versus function B for key comparison.

> attribute encoding and decoding, stays exactly the same.

  I'm proposing that all attribute encoding / decoding stay the same.

> This looks to me like a much smaller and simpler change.

  That's your opinion.  As an implementor, I disagree.

> is not compatible with 25+ years of RADIUS.

  I suggest reading the draft.  I go into detail on how my proposal *is* compatible with 25+ years of RADIUS.

  Again:

* nothing changes in packet encoding / decoding

* nothing changes in attribute encoding / decoding

* nothing changes in RADIUS security (what little there is)

* nothing changes for existing clients and servers

* there is a simple fallback to existing RADIUS.

  Even if I agreed with your arguments, I suspect that the wider RADIUS community in the iETF (i.e. RADEXT, DIME, and the IESG) would oppose changing the RADIUS header.  Adding a new attribute is much simpler in comparison.  Even if the clients and servers use one more field for the unique key.

  Your implementation arguments are largely that using two functions for the packet encoder/decoder is more efficient than using two functions for the key comparison.  I just don't see that as being true.

  I suggest trying to convince everyone *else* that your proposal is simpler than mine.  I don't believe it is, until there's evidence to the contrary.

  Alan DeKok.

---

From: Ignacio Goyret <[email-masked]>
Date: Mon, 24 Apr 2017 16:59:37 -0700

> Because I disagree that your proposal is simpler.

I guess we'll have to agree to disagree.

Your proposal is complex, much more so than increasing the size of
a header field.

It requires protocol changes, a big no-no in RADIUS, as has been
repeatedly stated many times by you.

It also requires a lot more cpu cycles since it requires decoding
every attribute before an incoming packet can be determined to be
a duplicate or not, which also means a hardware implementation of
the de-dup algorithm is out of the question.

>   The packet encoder / decoder changes.  Don't ignore that.

Note that may be a detail of your particular implementation which does not
necessarily hold as a universal truth.

Other implementations may be layered in ways that can handle my suggestion
more easily.

>  Really?  Implementing callback A versus callback B for key comparisons is trivial.

You do realize that the same can be said about either proposal, right?

>As someone who's written the most popular RADIUS server on the planet, my experience counts for something.

I never said or implied otherwise. I have great respect for you and
your contributions over the years.

But let's keep it civil and on a technical level.

You may not know me but I also have significant experience implementing
and maintaining server, client and proxy implementations of RADIUS spanning
over two decades.

>  Again, you're changing the packet encoding / decoding.

Again, that may be the case on a particular implementation, not on others.

>You're proposing to use function A versus function B for packet encoding... which is ends up being no different than using function A versus function B for key comparison.

Good, we are on the same page.

>  That's your opinion.  As an implementor, I disagree.

Precisely. And as another implementor, I disagree with you.

>Your implementation arguments are largely that using two functions for the packet encoder/decoder is more efficient than using two functions for the key comparison.  I just don't see that as being t…

Note that the suggestion was strictly limited to the first 20/24 bytes
of the packet. Once that header is extracted, the attribute handling
remains identical.

>I suggest trying to convince everyone *else* that your proposal is simpler than mine.  I don't believe it is, until there's evidence to the contrary.

I'm not going to try to convince anyone about either proposal because
I personally believe that RADIUS shouldn't be changed at all.

The point of my initial message was to highlight that if you are going
to change something in RADIUS, there are cleaner and simpler alternatives.
Your suggestion is better than others that have been floated around
but it also fails on the basic issue of no protocol changes.

The best solution still remains that if you need more than 255 pending
requests, use another UDP port. And if you ran out of UDP ports, use
another IP address.

These are much simpler solutions than any other proposal so far.

-Ignacio

---

From: Alan DeKok <[email-masked]>
Date: Mon, 24 Apr 2017 20:41:08 -0400

> Your proposal is complex, much more so than increasing the size of

 As I said... no.

> repeatedly stated many times by you.

 As the author or co-author of many RFC which require protocol changes, this is simply not true.

> the de-dup algorithm is out of the question.

  Please point me to a hardware implementation of RADIUS.  And even if one exists, why it matters.

  As I've pointed out, my proposal is 100% backwards compatible with all existing RADIUS implementations  So if you want to continue using existing RADIUS (hardware or software implementations), you're free to do so.

> Other implementations may be layered in ways that can handle my suggestion

  Then show evidence for your assertions.  If you can't, it's just my opinion (backed by publicly available facts) against your opinion (backed by vague assertions to proprietary implementations).

> You do realize that the same can be said about either proposal, right?

  I'm well aware of that.  And... again... which is simpler?  Adding an attribute, or changing the RADIUS header?

  Honestly, every time I come up with a counter-argument, you just re-assert your position, without additional evidence.  It's circular logic.

> But let's keep it civil and on a technical level.

  My comments *were* on a technical level.  The insinuation that I was uncivil is inappropriate.

> and maintaining server, client and proxy implementations of RADIUS spanning

  You have pretty much zero track record in RADEXT.  Whatever you've done, it's been in a walled garden, with minimal interaction with the IETF or other implementors.

  Now, it *is* important to understand how this proposal affects existing implementations.  And as I've said repeatedly.. it doesn't.  What part of that is unclear?

> Again, that may be the case on a particular implementation, not on others.

  You're *explicitly* proposing to change the RADIUS header, and now are claiming that it's not changing the packet encoding / decoding.

  One or the other statement is false.

  I find such arguments unconvincing.  And, inappropriate for a standards forum.

> Precisely. And as another implementor, I disagree with you.

  Since your implementation doesn't exist for purposes of peer review, we only have your naked assertion to go by.

  I suggest explaining *why* these changes are difficult in your implementation.  A naked assertion that "it's difficult" isn't much of an argument.

  In contrast, my code is public.

> of the packet. Once that header is extracted, the attribute handling

  That's disingenuous.

  Changing the header means changing how attributes are encoded and decoded.  Because attributes are encoded *after* the header.

  In my proposal, there are no changes to header encoding.  There are no changes to attribute encoding.  Which, pretty much by definition,  is simpler than your proposal.

> I personally believe that RADIUS shouldn't be changed at all.

  Then state that explicitly.  Oppose any and all changes to RADIUS.  See how far that gets you.

> to change something in RADIUS, there are cleaner and simpler alternatives.

  Simply stating a contrary position isn't an argument.

> but it also fails on the basic issue of no protocol changes.

  That's ridiculous.  If we couldn't make changes to RADIUS, we would disband the RADEXT WG.

> These are much simpler solutions than any other proposal so far.

  Then I don't think you've been paying attention.

  The existing implementations have problems with using multiple UDP ports and/or multiple IP addresses.  That's the sole reason why multiple people are proposing changes that allow more than 256 packets on one src/dst ip/port combination.  Because allowing that is *simpler* and *cheaper* than opening multiple source sockets.

  Honestly, this response makes it sounds like you haven't been paying attention to the implementation problems and the reasons why people are proposing these changes in the first place.

  Alan DeKok.

---

From: Ignacio Goyret <[email-masked]>
Date: Mon, 24 Apr 2017 18:44:40 -0700

>Since your implementation doesn't exist for purposes of peer review, we only have your naked assertion to go by.

Either one of those comments are either ad-hominen attacks or dismissive,
either way quiet inappropriate for the discussion at hand. Thus, my call
for civility.

Your opinion, very valuable without a doubt, is not the only opinion
in the world, just like your implementation is not the only implementation
in the world.

I'm done arguing.

-Ignacio

---

From: Peter Deacon <[email-masked]>
Date: Mon, 24 Apr 2017 18:49:58 -0700 (Pacific Daylight Time)

> These are much simpler solutions than any other proposal so far.

Completely agree.  Useful to look at the numbers.

Assume a single src/dst IP with pool of 1000 src ports and an average 
round trip time of 100 ms.  This translates to 256,000 concurrently 
"in-flight" requests or 2,560,000 RADIUS requests+responses per second.

Who pushes anything approaching this from aclient?  What specifically is 
your request/response rate per second and total number of concurrently 
outstanding requests from your clients?  I would love to see actual 
figures justifying change rather than blanket assertions which for all 
anyone knows could well be entirely explained away by known or unknown 
implementation problems.

There are defiantly problems.  I don't think anyone believes the current 
situation is ideal.  Managing source port or connection pools is 
inconvenient. If you don't have access to scalable method of listening on 
order of hundreds of "sockets" concurrently you begin to accumulate 
unreasonable overhead.

Those using TCP and DTLS transports have a much better case.  No doubt ID 
space is more inconvenient here leading to many times more TCP/TLS 
connections than optimal.

With TCP there are inherent limits associated with too many requests 
dependent on a single head-of-line blocked stream.  You don't want 
thousands of realtime authentication requests piling up generally or 
simultaneously delayed by single events (e.g. tail loss)

Is it unreasonable to expect a system acting as a RADIUS client for what 
must be millions of concurrent users to not be resource limited by 
something as trivial as number of available source ports or lack a 
scalable mechanism to listen concurrently across them?  Speaking for 
myself while clearly inconvenient the answer is no.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Tue, 25 Apr 2017 01:44:11 -0400

> Either one of those comments are either ad-hominen attacks or dismissive,

  Saying "your proposal is hard for my implementation" is a reasonable argument.

  Saying "I've been doing this for over two decades" is a data point, but isn't a convincing argument.

  Saying "my code is publicly available, and therefore I can demonstrate the code changes are simple" is a reasonable argument.

  Saying "my code is private, so therefor you have to believe me" isn't a convincing argument.

  My request for evidence-based discussion *is* me being dismissive of appeals to authority.  But it in no way is an ad hominem.

> either way quiet inappropriate for the discussion at hand. Thus, my call

  Asking for evidence isn't being uncivil, and no reasonable person would conclude otherwise.

> in the world, just like your implementation is not the only implementation

  I never claimed my implementation was the only one in the world, and no reasonable person would insinuate otherwise.

  That comment is a thinly-veiled insult.  It shows that fi you can't convince people based on appeals to authority, you resort to ad hominems.

> I'm done arguing.

  That's your prerogative.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 25 Apr 2017 02:01:06 -0400

On Apr 24, 2017, at 9:49 PM, Peter Deacon <[email-masked]> wrote:
> Assume a single src/dst IP with pool of 1000 src ports and an average round trip time of 100 ms.  This translates to 256,000 concurrently "in-flight" requests or 2,560,000 RADIUS requests+responses per second.
> 
> Who pushes anything approaching this from aclient?

  Not many systems.

  However... one problem with UDP is the ability to fill a network with data.  Networks are bounded both by per packet rates, and by total throughput.  RADIUS packets are small enough that they hit the network limit on packets, long before they hit the limit on total throughput.

  This is mainly due to having small packets, and using UDP transport.

  You could use TCP to avoid the problem of "one RADIUS packet == one ethernet frame".  But RADIUS allows only 256 packets outstanding at a time.  So if the packets are proxied, each TCP connection can only have <100K of data sent before the client MUST open another source port.  Which again runs into the ethernet frame limit.

  Allowing many RADIUS packets over one TCP connection means that you can fill a network with RADIUS traffic.  This is just impossible with RADIUS as it exists today.

>  What specifically is your request/response rate per second and total number of concurrently outstanding requests from your clients?  I would love to see actual figures justifying change rather than blanket assertions which for all anyone knows could well be entirely explained away by known or unknown implementation problems.

  One word: proxying.

  Once a packet is proxied, the clients can see request / response time frames of 100s of milliseconds, or even seconds  That puts a much stronger pressure on the number of packets outstanding.

> Those using TCP and DTLS transports have a much better case.  No doubt ID space is more inconvenient here leading to many times more TCP/TLS connections than optimal.
> 
> With TCP there are inherent limits associated with too many requests dependent on a single head-of-line blocked stream.  You don't want thousands of realtime authentication requests piling up generally or simultaneously delayed by single events (e.g. tail loss)

  The need for many RADIUS packets is largely driven by accounting traffic, not authentication traffic.

  And TCP "head of line" blocking only affects the network side of the transport.  If the packets actually make it to the RADIUS server, it is free to respond to the packets in any order it choses.

  Another counter-argument to TCP "head of line" blocking is that it's 2017.  The internet is large and fast.  People download gigabytes of traffic daily, and are minimally affected by packet loss.  I think it's reasonable to assume that packet loss won't affect RADIUS over TCP much, either.

> Is it unreasonable to expect a system acting as a RADIUS client for what must be millions of concurrent users to not be resource limited by something as trivial as number of available source ports or lack a scalable mechanism to listen concurrently across them?  Speaking for myself while clearly inconvenient the answer is no.

  That's a reasonable argument.  I'm not even disagreeing with it much.

  My draft is an attempt to address the stated need for allowing more outstanding RADIUS packets on one UDP or TCP connection.  There have been multiple suggestions for a solution to the problem, most of which involve changing the RADIUS header.  As I've pointed out, I think such changes will be rejected not only by RADEXT, but by the wider IETF reviewers.

  My draft is an attempt to address both the technical requirements, and the wider review.  There's no question that it will work.  The questions are whether it's needed, and whether it will achieve larger consensus that the solution is a reasonable one.

  Alan DeKok.

---

From: Enke Chen <[email-masked]>
Date: Wed, 26 Apr 2017 12:37:36 -0700

Hi, Bernard:

In this case it is more like a "wart removal" than a "heart transplant" :-)

Regards,  -- Enke

On 4/24/17 2:20 PM, Bernard Aboba wrote:
> Alan said: 
> 
> "Note that I'm *not* proposing a change to the Id field, or to much else in the protocol."
> 
> [BA] +1 to that.
> 
> RADIUS is 25+ years old, and given the pace of change on the Internet, one can make a case that protocol age is somewhat akin to "dog years". 
> 
> Changing the Id field in RADIUS is somewhat akin to attempting a heart transplant on a 175 year-old. 
> 
> While some doctor might try this (more as a "cash-ectomy" than a legitimate procedure), let's not pretend that it is in the best interest of the patient.
> 
> Carry on!
> 
> 
> On Mon, Apr 24, 2017 at 1:00 PM, Alan DeKok <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     > From: [email-masked] <mailto:[email-masked]>
>     > To: "Alan DeKok" <[email-masked] <mailto:[email-masked]>>
>     >
>     >
>     > URL:            https://www.ietf.org/internet-drafts/draft-dekok-radext-request-authenticator-00.txt <https://www.ietf.org/internet-drafts/draft-dekok-radext-request-authenticator-00.txt>
>     > Status:         https://datatracker.ietf.org/doc/draft-dekok-radext-request-authenticator/ <https://datatracker.ietf.org/doc/draft-dekok-radext-request-authenticator/>
>     > Htmlized:       https://tools.ietf.org/html/draft-dekok-radext-request-authenticator-00 <https://tools.ietf.org/html/draft-dekok-radext-request-authenticator-00>
>     > Htmlized:       https://datatracker.ietf.org/doc/html/draft-dekok-radext-request-authenticator-00 <https://datatracker.ietf.org/doc/html/draft-dekok-radext-request-authenticator-00>
>     >
>     >
>     > Abstract:
>     > until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org>.
>     >
>     > The IETF Secretariat
>     >
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/radext <https://www.ietf.org/mailman/listinfo/radext>
> 
> 
> 
>