Subject: [radext] RADIUS fragmentation concept

From: Peter Deacon <[email-masked]>
Date: Sat, 2 Feb 2013 21:37:00 -0800 (Pacific Standard Time)

Put together a small presentation for an approach to support large RADIUS 
packets beyond 4096 bytes.  The approach leverages a simple 802.1Q style 
scheme for large packet support across all command codes.

Would be interested to gage any interest from WG in general concept.

Narration not included.. please feel free to contact me if you have any 
questions.

http://www.iea-software.com/ietf/radfragment.pdf

regards,
Peter

---

From: Sam Hartman <[email-masked]>
Date: Sun, 03 Feb 2013 11:03:48 -0500

>>>>> "Peter" == Peter Deacon <[email-masked]> writes:

    Peter> Put together a small presentation for an approach to support
    Peter> large RADIUS packets beyond 4096 bytes.  The approach
    Peter> leverages a simple 802.1Q style scheme for large packet
    Peter> support across all command codes.

Hi.

When I read your presentation, I was quite frustrated, because there's
been a concept of RADIUS fragmentation going on for several months and
your presentation is not responsive to that existing discussion. I hope
that when people introduce alternatives into an ongoing discussion it is
because they believe their alternative provides significant additional
value. I hope that the introduction of the alternative would be focused
around that additional value rather than presenting an alternative
without relating it to the context of the ongoing discussion. I believe
that by relating it to the ongoing discussion and comparing approaches,
the conversation is more respectful of the different alternatives and
their value.
Would you explain why you find this approach better than the approach
already under discussion?

I think the existing approach has two  significant advantages over the
new approach:

1) It never requires there to be RADIUS packets running around longer
than 4096 bytes. In a lot of RADIUS implementations I've looked at,
there are a number of places where 4096-byte static buffers are
used. I'd have fairly low confidence that you could find and fix all
those buffers, especially in calling code for libraries. Interestingly,
these same implementations can deal much more gracefully with
decoded/expanded packets that couldn't possibly fit into 4096
bytes. That is, the structures used to deal with attributes are far more
able to deal with larger attributes than the structures used to deal
with packets.  Note that even for RADIUS over TCP we did not relax the
4096 limit. I think this is a good call both because of the
implementation concern and because of the proxy concern.

2) The existing solution works better in a case where an intermediate
proxy does not support fragmentation.

I *think* support with proxies that don't understand fragmentation is
probably important.
However I need to ponder that more.

--Sam

---

From: Arran Cudbard-Bell <[email-masked]>
Date: Sun, 3 Feb 2013 12:53:02 -0500

> implementation concern and because of the proxy concern.

With Peter's approach reassembling the complete packet in an intermmediary buffer may introduce issues with exhaustion, and makes it more likely that a client that has misimplemented the fragmentation extention could acidentally cause a DoS on the upstream proxy.

Though I believe in theory it may have a slight advantage in the case where there are multiple unreliable hops.

Say we have a single proxy server, with unrealiable upstream and downstream connections, and that there's a 50% chance the packet will be dropped as it traverses those connections.

NAS <-- 50% --> Proxy <-- 50% --> Server

There's a 6.25% chance that the fragmentation round will complete, so lets say it'd take 16 retransmissions to complete the round successfully.

Now for the poposed scheme, lets say it takes 2 attempts to complete each link traversal successfully, meaning it should only take 8 retransmissions to complete the round successfully.

> However I need to ponder that more.

I think it probably is too. If nothing else it'd require additional effort on the part of the administrator to upgrade all intermmediary proxy servers.

I've also seen a few instances recently where vendors have implemented proxy servers on auxillary devices like firewalls and NAT boxes to mirror sessions created on the NAS. Upgrading these embedded devices to support fragmentation would not be feasible.

On a non-technical note. I don't know about everyone else I prefer to read proposals without the chromic assault, maybe it'd be best to stick to something resembling the standard RFC format in future?

-Arran

---

From: Arran Cudbard-Bell <[email-masked]>
Date: Sun, 3 Feb 2013 12:48:40 -0500

-Arran

---

From: Peter Deacon <[email-masked]>
Date: Sun, 3 Feb 2013 09:57:23 -0800 (Pacific Standard Time)

> already under discussion?

Hi Sam,

My understanding fragmentation approach SAML uses is intended for Interop 
with existing systems (proxies) already in the field while my approach 
does not.  While both accomplish same goals where they overlap the 
constraints are different.

My primary issue with SAML draft which prompted this is lack of command 
code coverage.

It does not work with accounting even while there is talk about pushing 
large quantities of data thru accounting messages.

If I am to push a large authorization attribute there is no way to alter 
my authorization later via dynamic authorization.

I have no interest in seeing these issues constantly readdressed as 
someone later finds a need to support huge messages in Accounting or CoA.

> there are a number of places where 4096-byte static buffers are used. 
> I'd have fairly low confidence that you could find and fix all those 
> buffers, especially in calling code for libraries. Interestingly, these 
> same implementations can deal much more gracefully with decoded/expanded 
> packets that couldn't possibly fit into 4096 bytes. That is, the 
> structures used to deal with attributes are far more able to deal with 
> larger attributes than the structures used to deal with packets.  Note 
> that even for RADIUS over TCP we did not relax the 4096 limit. I think 
> this is a good call both because of the implementation concern and 
> because of the proxy concern.

Illustrations were intended to help convey a logical concept.  Any 
approach accomplishing the same result gets the job done.

There is no reason individual fragments ever have to be combined into a 
single block of memory if the implementor finds this to be easier given 
their constraints.

One may elect to calculate lengths, MD5s, HMACs..etc over fragments just 
as they could a fully assembled product.

With regards to the artificial limit in TCP case fragments could act as a 
bridge to enable large packet flows between TCP and UDP systems supporting 
fragments.

> probably important. However I need to ponder that more.

I agree this is a key difference.

regards,
Peter

---

From: Sam Hartman <[email-masked]>
Date: Sun, 03 Feb 2013 13:14:56 -0500

>> 1) It never requires there to be RADIUS packets running around
    >> longer than 4096 bytes. In a lot of RADIUS implementations I've
    >> looked at, there are a number of places where 4096-byte static
    >> buffers are used. I'd have fairly low confidence that you could
    >> find and fix all those buffers, especially in calling code for
    >> libraries. Interestingly, these same implementations can deal
    >> much more gracefully with decoded/expanded packets that couldn't
    >> possibly fit into 4096 bytes. That is, the structures used to
    >> deal with attributes are far more able to deal with larger
    >> attributes than the structures used to deal with packets.  Note
    >> that even for RADIUS over TCP we did not relax the 4096 limit. I
    >> think this is a good call both because of the implementation
    >> concern and because of the proxy concern.

    Peter> Illustrations were intended to help convey a logical concept.
    Peter> Any approach accomplishing the same result gets the job done.

I apparently wasn't clear.
The advantage I see in the existing draft is that each packet is
composed entirely of well-formed RADIUS attributes and each packet has
its own ID and RADIUS header.
You can use almost all  your existing packet decoding logic and all your
existing attribute decoding logic.

You could get some of these benefits if you introduce constraints like
each fragment must end on an attribute boundary.
However I still think you're approach is going to do much more damage to
packet processing routines and especially to the APIs to these routines.

---

From: Peter Deacon <[email-masked]>
Date: Sun, 3 Feb 2013 10:28:56 -0800 (Pacific Standard Time)

On Sun, 3 Feb 2013, Arran Cudbard-Bell wrote:

> With Peter's approach reassembling the complete packet in an 
> intermmediary buffer may introduce issues with exhaustion, and makes it 
> more likely that a client that has misimplemented the fragmentation 
> extention could acidentally cause a DoS on the upstream proxy.

Hi Arran,

You are correct proxies would need to store the entire request before 
passing it on.

Some mitigating thoughts..

Pick a lower bound on fragment size everyone must support making anything 
above this an administrative option.

With Fragment-Reject server can signal request too big to client.

While request must be stored it my not necessarily have to be a contiguous 
block.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Sun, 3 Feb 2013 11:14:01 -0800 (Pacific Standard Time)

> I apparently wasn't clear. The advantage I see in the existing draft is 
> that each packet is composed entirely of well-formed RADIUS attributes 
> and each packet has its own ID and RADIUS header.

Hi Sam,

I apologize for any confusion.

It is the case here as well.  "outer" (Fragment-Req/Resp) messages are 
essentially the same as Accounting-Request / Accounting-Response.

The only difference they have a different command code.  ALL constraints 
which apply to an Accounting style of request (Also Disconnect/CoA) apply 
to Fragment-Request.

Fragment-Requests are well formed containing complete AVPs only.

> each fragment must end on an attribute boundary.

Each fragment ends on an attribute boundary.

On pg16 responsibilities of the "outer" (What is sent on the wire) vs 
"inner" (constructed packet) briefly touch on this issue.

"outer" request has an id, header, must be well formed with its 
authenticator validated.

"inner" request has header, must be well formed with authenticator fully 
validated same as if it were on wire.

Inner request does not have an ID field as outer request is performing 
this function.  It is set 0 in inner header for compatibility.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Sun, 03 Feb 2013 15:29:28 -0500

> large quantities of data thru accounting messages.

  Such as?

> my authorization later via dynamic authorization.

  The CoA packet can contain Service-Type = Additional-Authorization.
The fragmentation method can then be used to send large amounts of
authorization data.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Sun, 3 Feb 2013 13:47:25 -0800 (Pacific Standard Time)

>> large quantities of data thru accounting messages.

Dreams of RADIUS transport of detailed statistical information per session 
from prior threads involving counters and IPFIX.

> The fragmentation method can then be used to send large amounts of

Or solve the underlying problem and avoid having to invent more and more 
workarounds.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Sun, 03 Feb 2013 19:04:40 -0500

Peter Deacon wrote:
> Dreams of RADIUS transport of detailed statistical information per
> session from prior threads involving counters and IPFIX.

  Accounting can use the Acct-Multi-Session-Id to tie accounting for
individual streams to one session.

> Or solve the underlying problem and avoid having to invent more and more

  Having one method to get authorization to the NAS is preferable to
having two methods.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Sun, 3 Feb 2013 18:33:31 -0800 (Pacific Standard Time)

> individual streams to one session.

With a few thousand flows to export for one session what happens?

Do I send a few thousand accounting records?  Do I invent only as many 
sessions as necessary to make everything fit into a few accounting 
records?

How many "workarounds" must be tolerated?

>  Having one method to get authorization to the NAS is preferable to

If I want to change an authorization parameter I send a message with the 
parameter I want changed and thats that.  If the parameter cannot be 
changed I get an Error-Cause back explaining why.

With this hypothetical reauthorization scheme I send a message saying 
please reauthorize yourself and hope for the best.  Two RADIUS 
transactions instead of one and no feedback.

regards,
Peter

---

From: Arran Cudbard-Bell <[email-masked]>
Date: Sun, 3 Feb 2013 22:14:08 -0500

On 3 Feb 2013, at 21:33, Peter Deacon <[email-masked]> wrote:

> Do I send a few thousand accounting records?  Do I invent only as many sessions as necessary to make everything fit into a few accounting records?

Yes, I've seen at least one vendor implement their NAT accounting like this. Of course there's huge overhead with this approach, but it's significantly reduced if you pack multiple RADIUS packets into a single UDP packet. I believe Alan has some ideas on this.

It also re-uses the existing accounting model to signal when connections are established and terminate.

> If I want to change an authorization parameter I send a message with the parameter I want changed and thats that.  If the parameter cannot be changed I get an Error-Cause back explaining why.

Yes.

> With this hypothetical reauthorization scheme I send a message saying please reauthorize yourself and hope for the best.  Two RADIUS transactions instead of one and no feedback.

This is no different than what happens when the server returns an Access-Accept. Yes it may be useful to allow the NAS to signal the server saying that an error occurred, but that is outside of the scope of fragmentation.

-Arran

---

From: Alan DeKok <[email-masked]>
Date: Sun, 03 Feb 2013 22:50:05 -0500

> With a few thousand flows to export for one session what happens?

  I have no idea.  How does it work today?

> sessions as necessary to make everything fit into a few accounting records?

  How does it work with your solution?

> parameter I want changed and thats that.

  Then you don't need to send bulk data, do you?

> transactions instead of one and no feedback.

  This is how some vendors have implemented CoA, because the semantics
around changing an existing session can be difficult.  Instead of CoA,
they implement Disconnect-Request, and force the end machine to
re-authenticate / re-authorize.

  So there is precedent for the approach I'm suggesting.  It's deployed
today, and it works.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Sun, 3 Feb 2013 20:15:06 -0800 (Pacific Standard Time)

>  So there is precedent for the approach I'm suggesting.  It's deployed

Dropping the session and expecting it will quickly re-authenticate is very 
different from reauthorization approach suggested earlier.

I remember myself once making this same assumption - CoA is pointless you 
could just issue a disconnect and most systems would reauth so quick the 
user would be none the wiser.

Unfortunately I was proven wrong after operators saw things differently.

regards,
Peter

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 04 Feb 2013 09:28:23 +0100

El 03/02/13 18:57, Peter Deacon escribió:
> My understanding fragmentation approach SAML uses is intended for 
> Interop with existing systems (proxies) already in the field while my 
> approach does not.  While both accomplish same goals where they 
> overlap the constraints are different.
>
> My primary issue with SAML draft which prompted this is lack of 
> command code coverage.

Current fragmentation draft is not only for SAML, but a generic 
fragmentation mechanism. Indeed, it does not need to be a consequence of 
large attributes. It could also be provoked by a large amount of small 
attributes.

>
> It does not work with accounting even while there is talk about 
> pushing large quantities of data thru accounting messages.
>
> If I am to push a large authorization attribute there is no way to 
> alter my authorization later via dynamic authorization.
>

Well, current fragmentation draft could be extended for Accounting 
support. It should be straightforward as it adds only minor changes to 
RADIUS processing.

>> buffers, especially in calling code for libraries. Interestingly, 
>> decoded/expanded packets that couldn't possibly fit into 4096 bytes. 
>> That is, the structures used to deal with attributes are far more 
>> with packets.  Note that even for RADIUS over TCP we did not relax 
>> the 4096 limit. I think this is a good call both because of the 
> There is no reason individual fragments ever have to be combined into 
> a single block of memory if the implementor finds this to be easier 
> given their constraints.
>
> One may elect to calculate lengths, MD5s, HMACs..etc over fragments 
> just as they could a fully assembled product.
>
> With regards to the artificial limit in TCP case fragments could act 
> as a bridge to enable large packet flows between TCP and UDP systems 
> supporting fragments.
>
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Peter Deacon <[email-masked]>
Date: Mon, 4 Feb 2013 02:38:35 -0800 (Pacific Standard Time)

On Mon, 4 Feb 2013, Alejandro Perez Mendez wrote:

>>> that when people introduce alternatives into an ongoing discussion it

> large attributes. It could also be provoked by a large amount of small 

Hi Alejandro,

I might as well list all of my problems with the draft.  Before I do for 
what it is worth as with IPv6 transition efforts there are multiple 
solutions given different constraints faced by operators and implementors. 
One and only one solution is not necessarily going to solve everyones 
problem.

My intent was not necessarily to compete with your approach but to offer 
up a more general solution separately to solve the larger problem as a 
separate matter on a separate tract.

Like I told Sam the constraints are different.  You I assume want this to 
pass thru existing proxy infrastructure.  I am looking for a solution that 
is more universal and offers less of a chance for breakage and unintended 
consequences.  I do not think it is reasonable to assume these differences 
can be reconciled given tools we have to work with.

There is unpredictable consequences in breaking a contract which until now 
has always been true with regards to access to entire proxied request 
attributes and response attributes in order for intermediates to make 
decisions.

First and most importantly it is not simply the case proxy is only 
performed based on user-name attribute.  It can and is done on any 
arrangement of arbitrary attributes.

Second if I am a proxy applying policy I want to make decisions based on a 
full picture of what is going on not part of it and not a dynamic 
situation that looks different based on how many bytes were in the 
original packet.  If I see something that needs to be changed how do I 
change it if part of the thing has already leaked past me?

How do I understand a data filters implications if the other half of it is 
in the next packet and it is too late to do anything about it then?

This is not EAP where you are doing challenges just to establish identity.

There are some interesting things in this draft like the misuse of 
Access-Challenge to convey authorization attributes and the covering up of 
this misuse by following the letter but not the spirit of law by resorting 
a bunch of sorting and shifting of attributes.  Once you add up the hacks, 
dynamic sizing arithmetic, removal of various attributes and workarounds 
for specific protocols mentioned by name (EAP) this scheme ceases to be 
the simple solution advertised.

regards,
Peter

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 04 Feb 2013 11:56:49 +0100

El 04/02/13 11:38, Peter Deacon escribió:
>>> Interop with existing systems (proxies) already in the field while 
>>> my approach does not. While both accomplish same goals where they 
>> fragmentation mechanism. Indeed, it does not need to be a consequence 
>> of large attributes. It could also be provoked by a large amount of 
>> small attributes.
>
> Hi Alejandro,
>
> I might as well list all of my problems with the draft.  Before I do 
> for what it is worth as with IPv6 transition efforts there are 
> multiple solutions given different constraints faced by operators and 
> implementors. One and only one solution is not necessarily going to 
> solve everyones problem.
>
> My intent was not necessarily to compete with your approach but to 
> offer up a more general solution separately to solve the larger 
> problem as a separate matter on a separate tract.
>
> Like I told Sam the constraints are different.  You I assume want this 
> to pass thru existing proxy infrastructure.  I am looking for a 
> solution that is more universal and offers less of a chance for 
> breakage and unintended consequences.  I do not think it is reasonable 
> to assume these differences can be reconciled given tools we have to 
> work with.
>
>
> There is unpredictable consequences in breaking a contract which until 
> now has always been true with regards to access to entire proxied 
> request attributes and response attributes in order for intermediates 
> to make decisions.
>
> Second if I am a proxy applying policy I want to make decisions based 
> on a full picture of what is going on not part of it and not a dynamic 

We also provide a mechanism where proxies supporting this fragmentation 
scheme can receive the whole packet, modify it, and then continue with 
the proxing. Hence, it would then be very similar to what you propose.

>
> How do I understand a data filters implications if the other half of 
> it is in the next packet and it is too late to do anything about it then?
>
> Access-Challenge to convey authorization attributes 

Authorization attributes are just an example of a possible cause for a 
large RADIUS packets. But they may not be the only one.The draft intends 
to provide a generic fragmentation mechanisms, not only for 
authorization purposes.

> and the covering up of this misuse by following the letter but not the 
> spirit of law by resorting a bunch of sorting and shifting of 
> attributes.  Once you add up the hacks, dynamic sizing arithmetic, 
> removal of various attributes and workarounds for specific protocols 
> mentioned by name (EAP) this scheme ceases to be the simple solution 
> advertised.

As you explained before, we started from different requirements. Our aim 
was to introduce the minimal impact on existing infrastructures, to ease 
its deployment, in such a way that End to End implementations can work, 
even though intermediary parties do not implement the specification.

Regards,
Alejandro

>> support. It should be straightforward as it adds only minor changes 
>> to RADIUS processing.
>
> regards,
> Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 04 Feb 2013 08:15:18 -0500

> separate matter on a separate tract.

  The current draft tries to meet the following goals:

- no changes required to existing proxies (who don't implement it)

- minimal changes to RADIUS

- fits within the existing RADIUS infrastructure

> to pass thru existing proxy infrastructure.  I am looking for a solution
> that is more universal and offers less of a chance for breakage and
> unintended consequences.  I do not think it is reasonable to assume
> these differences can be reconciled given tools we have to work with.

  If the proposal is to not use existing RADIUS, you might as well
design the *best* solution, and pretend that RADIUS doesn't exist.

> request attributes and response attributes in order for intermediates to
> make decisions.

  The proposal allows for that.  Proxies CAN re-assemble the traffic, if
they are aware of the new functionality.  If they are unaware, they pass
it straight through.

  With your proposal, proxies unaware of fragmentation will simply block
all of the traffic.

> arrangement of arbitrary attributes.

  "Can".  Not "Required".

> Second if I am a proxy applying policy I want to make decisions based on
> a full picture of what is going on not part of it and not a dynamic

  You're inventing a problem which doesn't need to exist.

> How do I understand a data filters implications if the other half of it
> is in the next packet and it is too late to do anything about it then?

  You just re-assemble the traffic.  Like with your draft.

> Access-Challenge to convey authorization attributes and the covering up
> of this misuse by following the letter but not the spirit of law by
> resorting a bunch of sorting and shifting of attributes.

  The point of allowing updates to standards is... to allow updates.

  We can update 2865 to allow *certain* authorization attributes in
Access-Challenge.  The RFCs aren't written in stone.  They aren't
inviolate for all time.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 4 Feb 2013 08:30:30 -0800 (Pacific Standard Time)

>  You just re-assemble the traffic.  Like with your draft.

Reassembling requires support for the specification.  If you don't support 
the specification then you experience breakage.  There is no free lunch.

> Access-Challenge.  The RFCs aren't written in stone.  They aren't

I don't see any standards being updated.  All I see are hacks to work 
around them.

regards,
Peter

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Feb 2013 11:38:04 -0500

Hi, Peter.
I'm a bit confused by some of your language; I'd appreciate it if you
would help me get past the 0th order to the emotions and thoughts behind
it.

I've found that terms like hacks tend to have a lot of perception behind
them.  One person's hack is another person's evolution in action.

Are you saying that you're concerned because you don't think that the
complexity introduced by Alex's solution justifies the benefits?

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Mon, 04 Feb 2013 13:05:42 -0500

Peter Deacon wrote:
> Reassembling requires support for the specification.  If you don't
> support the specification then you experience breakage. 

  That is not true.  If proxies don't support the proposal, then they
can't filter the new attributes.  This is the *same* problem proxies
have today, when new attributes are defined.

  And your proposal is worse.  Implementations which don't support can't
proxy anything.  It is impossible to get large amounts of authorization
data from a compliant server, through non-compliant proxies, and to a
compliant NAS.

  You're complaining about a problem which doesn't exist for the current
proposal.  And most tellingly, you're *not* applying the same standard
to your proposal.

> There is no free lunch.

  For the other readers, the text I wrote which Peter deleted, says:

> I don't see any standards being updated.  All I see are hacks to work

  I said: "We CAN update 2865".

  You are straw-manning me.  You are inventing problems which don't
exist.  You apply rules to me that you don't apply to yourself.  You are
deleting my comments, and then claiming I don't support my position.
You ignore *direct* questions when I ask you to explain your position.
You "defend" your position by re-stating it over and over.  You insult
people by calling their solutions "hacks".

  It makes you no friends.  And it ensures that people will ignore you
as contributing nothing positive to the discussion.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 4 Feb 2013 10:55:47 -0800 (Pacific Standard Time)

> have today, when new attributes are defined.

What new attributes?  My understanding this is a general solution there 
need not be any new attributes involved.

This is not about filtering new attributes themselves exceeding 4096 bytes 
the problem is loss of ability to see and manage existing ones.

I think Alex's careful precise language in responding to me on this exact 
issue is 100% accurate.  You have to parse the whole context.

> data from a compliant server, through non-compliant proxies, and to a

As I've been saying all along and Q&A section brings up as the very first 
issues.

What my little slideshow however says or does not say is ultimately 
irrelevant in context of Alex's draft which must stand on its own.

> proposal.  And most tellingly, you're *not* applying the same standard

I have gone out of my way to make it clear both to Sam and Alex in at 
least three separate messages the constraints and assumptions behind both 
are different.

I am seeking a long term solution that solves the problem generally for 
all command codes and place no value in interop with the proxies of today.

> deleting my comments, and then claiming I don't support my position. You 
> ignore *direct* questions when I ask you to explain your position. You 
> "defend" your position by re-stating it over and over.  You insult 

I will respond separately on the "hack" comment later.  Needless to say no 
insult was intended toward Alex or anyone else.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Mon, 4 Feb 2013 11:49:52 -0800 (Pacific Standard Time)

Hi Sam,

I appreciate Alex's effort and while this sounds contradictory I don't 
object to Alex's works or the resulting draft and its trade-offs.

I believe have been able to see the space clearly enough to at least 
understand constraints involved and with that understanding don't know I 
would have done much differently.

The underlying theme that lead to "hack" was my focus on the disparity 
between the nature of the problem and the nature of the solution:

The problem is essentially a low level transport issue.  The solution 
involves assorted changes at a much different logical layer.  What does 
the order of attributes of certain types and special accommodations for 
specific instances of authentication protocols have to do with just making 
a packet bigger?  This was my thinking.

And like I said before my main issue is not these issues for as much 
oxygen as they have consumed but lack of command code coverage.

I think in the final analysis when you tally up the workaround/machinary 
necessary to make this work and opportunity cost of leaving other command 
codes *CURRENTLY* undressed -- from my understanding of implementation 
effort for all concerned it does not add up for me.

When I looked the totality of the situation I wondered if we can't do 
better and thats what I still want to explore.  Not better in terms of a 
direct comparison with Alex's work but different..different goals 
different constraints.

regards,
Peter

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Feb 2013 15:16:12 -0500

Hi, Peter.

If you view this as a transport issue, I think that learning from around
8 or 9 years of Kerberos experience with fragmentation would be
valuable.

Kerberos supports longer packets over TCP than UDP.  If a client finds
that it's trying to send a large message over UDP, it opens a TCP
connection.  If a server finds it's trying to send a large message over
UDP, then it generats a TCP required error message.

If we're going to view this problem at the transport layer, that's
probably a simpler approach that gets the command code coverage you're
looking for.

--Sam

---

From: Peter Deacon <[email-masked]>
Date: Mon, 4 Feb 2013 12:35:13 -0800 (Pacific Standard Time)

Hi Sam,

I've never been thrilled with TCP transport for RADIUS but in a situation 
where it might only get used when shippings lots of data it sounds like a 
great idea!

Excessive round trip delay that follows from moving bulk data in 
RADIUS/UDP acking every 'fragment' would also go away.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 04 Feb 2013 15:39:40 -0500

> need not be any new attributes involved.

  You haven't read the draft, and you're wasting my time.

  Even without that, this is an ignorant response.  The existin

> This is not about filtering new attributes themselves exceeding 4096
> bytes the problem is loss of ability to see and manage existing ones.
> 
> I think Alex's careful precise language in responding to me on this
> exact issue is 100% accurate.  You have to parse the whole context.
> 
> As I've been saying all along and Q&A section brings up as the very
> first issues.
> 
> least three separate messages the constraints and assumptions behind
> both are different.
> 
>> exist.  You apply rules to me that you don't apply to yourself.  You
>> are deleting my comments, and then claiming I don't support my
>> position. You ignore *direct* questions when I ask you to explain your
>> position. You "defend" your position by re-stating it over and over. 
>> You insult people by calling their solutions "hacks".
> 
> I will respond separately on the "hack" comment later.  Needless to say
> no insult was intended toward Alex or anyone else.
> 
> regards,
> Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 04 Feb 2013 15:42:43 -0500

> RADIUS/UDP acking every 'fragment' would also go away.

  P = # of hops
  N = # of fragments

  You either have (N) acks at each hop, for N*P acks.

  Or, you have P hops, with N acks traversing all hops... for P*N acks.

  How is N*P != P*N?

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 04 Feb 2013 15:45:59 -0500

A more complete response...

Peter Deacon wrote:
> What new attributes?

  Any new attributes which require multi-packet reassembly.

>  My understanding this is a general solution there

  Existing attributes can't be fragmented across multiple packets.  This
proposal doesn't change that.

> irrelevant in context of Alex's draft which must stand on its own.

  My comments were directed to your methods of discourse, not the documents.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Feb 2013 15:52:09 -0500

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    >> RADIUS/UDP acking every 'fragment' would also go away.

    Alan>   P = # of hops N = # of fragments

    Alan>   You either have (N) acks at each hop, for N*P acks.

No.  TCP can combine acks.  Also, TCP can have multiple acks
outstanding.  See analysis of TFTP performance compared to say FTP
performance for a discussion of this and related TCP vs UDP performance
issues.

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Mon, 04 Feb 2013 15:57:06 -0500

> performance for a discussion of this and related TCP vs UDP performance

  Yes.  But the RADIUS fragmentation proposals can't.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 4 Feb 2013 12:55:58 -0800 (Pacific Standard Time)

>  How is N*P != P*N?

I was thinking mostly of clients and servers talking to each other rather 
than proxy chains.

In proxy case the benefit is local handling of transport problems at each 
hop combined with windowing benefit vs having to chain up delay times and 
probability of further dropped packets.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 04 Feb 2013 16:02:21 -0500

Peter Deacon wrote:
> In proxy case the benefit is local handling of transport problems at
> each hop combined with windowing benefit vs having to chain up delay
> times and probability of further dropped packets.

  Then TCP should be used.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Mon, 4 Feb 2013 13:01:35 -0800 (Pacific Standard Time)

> proposal doesn't change that.

It is not the attributes individually it is access to the full request and 
or response messages.  See my original message to Alex.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 04 Feb 2013 16:13:13 -0500

Peter Deacon wrote:
> It is not the attributes individually it is access to the full request
> and or response messages.  See my original message to Alex.

  And if the proxy doesn't implement the proposal, it won't know about
the fragmentation.  Just like what happens with your proposal.

  Your comments amount to "systems which don't implement a feature won't
be able to use the feature."

  So?  I fail to see why this is a surprise.  I fail to see why you're
wasting everyone's time by claiming it's a problem with the
fragmentation draft.

  Alan DeKok.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 05 Feb 2013 08:35:12 +0100

El 04/02/13 20:49, Peter Deacon escribió:
> understand constraints involved and with that understanding don't know 
> I would have done much differently.
>
> involves assorted changes at a much different logical layer.  What 
> does the order of attributes of certain types and special 
> accommodations for specific instances of authentication protocols have 
> to do with just making a packet bigger?  This was my thinking.
Hello Peter,

I understand what you say, but this is the way this kind of problems 
have been addressed within RADIUS. Take for example attribute 
fragmentation. You could have defined instead a new attribute format, 
which supports more than 255 bytes. However, what it is defined is that 
you can put several "small" attributes into an ordered sequence, and it 
does the trick. Our solution follows the same reasoning. We can arrange 
packets in such a way that multiple packets represents logically a 
single large packet.

I understand one can think problem and solution are not at the same 
level..., but this is far from being a new way to face this kind of 
problems within RADIUS.

Regards,
Alejandro

> I think in the final analysis when you tally up the 
> workaround/machinary necessary to make this work and opportunity cost 
> of leaving other command codes *CURRENTLY* undressed -- from my 
> understanding of implementation effort for all concerned it does not 
> add up for me.
>
> better and thats what I still want to explore.  Not better in terms of 
> a direct comparison with Alex's work but different..different goals 
> different constraints.
>
> regards,
> Peter