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

[Alan DeKok <[e-mail]>]

On Apr 24, 2017, at 7:59 PM, Ignacio Goyret <[e-mail]> wrote:
> Your proposal is complex, much more so than increasing the size of
> a header field.

 As I said... no.

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

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

> 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.

  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.

> 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.

  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).

>> 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?

  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.

>> 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.

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

> 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.

  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, you're changing the packet encoding / decoding.
> 
> 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.

>> That's your opinion.  As an implementor, I disagree.
> 
> 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.

>> 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.
> 
> 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.

  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 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.

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

> 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.

  Simply stating a contrary position isn't an argument.

> Your suggestion is better than others that have been floated around
> 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.

> 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.

  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.