Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06

[Stefan Winter <[e-mail]>]

Hi,

> Actually, they are known by the Server, but unknown by the Client. When
> the server is the one fragmenting information, that information is accurate.

It doesn't know; it's an estimation which is hopefully rather accurate
these days because many sane implementations of forwarding server do add
Proxy-State; but they are not at all obliged to.

RFC2865, 2.3 "Proxy" states:

The forwarding server MAY add one Proxy-State attribute to the
      packet.  (It MUST NOT add more than one.)

So your server in the end may see less Proxy-State than there were
proxies. This is mostly irrelevant to your draft, because if that proxy
didn't add Proxy-State, then is also doesn't consume space in the packet.

OTOH, if that proxy decided that it wants to add other attributes
besides Proxy-State, then that proxy *will* have an impact. For extra
fun, consider that a proxy may not feel the urge to add an attribute in
the request, but does so in the reply. That makes for an asynchronous MTU!

This begs the question: if a fragmentation-draft-unaware proxy receives
a chunk close to 4096, and decides it wants to add an arbitrary
attribute on its own, and cannot -> bad luck, discard?

I also just found another gem regarding Proxy-State that I wasn't aware
of until now: a forwarding server may truncate the Proxy-State values it
found from earlier proxies, and only send its new one further on. It
merely needs to remember the content of the earlier ones, to add them
back in the reply. I'm speaking of this text in the same section:

"  The forwarding server MAY
   include the Proxy-State attributes in the access-request when it
   forwards the request, or MAY omit them in the forwarded request.  If
   the forwarding server omits the Proxy-State attributes in the
   forwarded access-request, it MUST attach them to the response before
   sending it to the client."

This would totally break your proxy detection. I am not aware of anyone
implementing this though.

> That's right. Proxy-State-Len provides an approximation to that value. A
> Client will probably adjust chunk size as if Proxy-State-Len would be
> higher. I agree that being conservative is the best.
> This calculation mechanisms does not solve all the problems, but IMHO
> offers more information that using plain RADIUS, where the Client cannot
> even guess.

Your 7.1 point 3 does not explicitly mention that the client should
leave some leeway. You might want to add a sentence to that effect.

>> It might be worthwhile to consider if stacking of fragmentation is
>> possible with your draft; i.e. if a proxy receives a chunk, can it use
>> the fragmentation draft to split that incoming packet into chunks on its
>> own again? Can the receiver make sense of that double-fragging? I didn't
>> wrap my head around your draft enough to be able to answer that question
>> myself at this point :-)
> 
> No, please :).

Okay :-) Alan's response kind of gave a hint already: reassemble the
whole packet, add your attributes, chunk it.

The question of frag-unaware proxies remains; their only choice is to
discard if they can't fit in their attributes.

> It will not be an Access-Challenge, as the Access-Request of a pre-authz
> exchange does not contain any authentication attribute (e.g.
> EAP-Messsage). It only contains authorization related information, thus
> suitable responses are Access-Accept (i.e. I correctly received and
> understood your data), or Access-Reject (i.e. data not understood or not
> valid).
> 
> In previous versions of the draft it was possible to do what you said,
> but we decided to simplify to avoid a lot of troubles if mixing with
> authentication exchanges.

That's not what your example does: The packet in 4.1 contains a
"User-Password" attribute.

Maybe that's a leftover from an earlier rev?

>> 6. Allowed size
>> ===============
>> It might be worthwhile to calculate how much actual fragmented data will
>> be transmittable with 20 such roundtrips, and the maximum possible overhead.
>>
>> I think it would be (4096-517)*19+(4096-517+253) in the worst case (one
>> round-trip's User-Name is actually part of the payload, and not a
>> repetition.
> 
> Well, the draft also states to set the limit in a few tens of kilooctets
> 20. That is, whatever is reached first. Nonetheless, this are
> recommendations, but it will be a configuration decision, not sure if it
> is really important to state in the draft.

My point is that you could give implementers or even deployers some
hints regarding "what they get" for specific values. Just stating: when
using the default 20 roundtrips maximum ceiling, the amount of data that
can be transferred is between x Bytes (lowest overhead) and y Bytes
(highest overhead).

It makes life easier for people who want or need to judge whether the
default value is good enough for their implementation or deployment.
It's just a suggestion for readability / comprehensability of the draft
anyway.

Greetings,

Stefan

> 
> Best regards,
> Alejandro
>> 1 Legacy proxies
>> ==================
>> There is an implicit assumption in the draft that proxies make their
>> routing decisions based on User-Name; that's the reason why User-Name
>> always gets repeated in every chunk.
>>
>> The whole fragmentation along unmodified proxies will break if the proxy
>> uses other attributes for its forwarding decisions, say the SSID part of
>> Called-Station-Id.
>>
>> I don't know how common that is; but your draft should at least
>> explicitly state that User-Name is the (only) attribute that proxies can
>> use to make their forwarding decisions. You may also want to discuss
>> replacing or augmenting the attribute repetition for other attributes as
>> needed; but that increases the complexity of your draft significantly.
>>
>> Actually, now that I think of it, I have heard of (few) eduroam SP
>> RADIUS proxies which decide based on the SSID whether the incoming
>> request is for eduroam (proxy to their national eduroam server) or for
>> something else (proxy elsewhere). So that use case is not completely
>> theoretical.
>>
>> Greetings,
>>
>> Stefan Winter
>>
>> On 09.08.2013 14:02, Jouni Korhonen wrote:
>>> Folks,
>>>
>>> Based on the discussion in Berlin we are ready to start another
>>> adoption call for the solution for fragmentation of RADIUS packets.
>>>
>>> This email starts a two week consensus call on adopting:
>>>
>>>  Filename:         draft-perez-radext-radius-fragmentation
>>>  Revision:         06
>>>  Title:            Support of fragmentation of RADIUS packets
>>>  Creation date:    2013-07-02
>>>
>>> Express your concerns or support by 23rd August EOB on the mailing list.
>>>
>>> - Jouni & Mauricio
>>> _______________________________________________
>>> radext mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/radext
>>>
>>
>>
>>
>> _______________________________________________
>> radext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/radext
> 
> 
> 
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext
> 


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]