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

[Alejandro Perez Mendez <[e-mail]>]

El 22/08/13 09:53, Stefan Winter escribió:
> 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.

I meant, when the server is sending chunks, it will know exactly how 
much space it needs to leave for sending back the received Proxy-State 
attributes, isn't it. (I will say otherwise below, after knowing more 
about proxy state behaviour :D)

>
> 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?
Exactly, just like it happens today with RADIUS.

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

Oh, I did not know either. This would complicate things, as the packet 
may grow arbitrarily between the Client and the Server, without any of 
them knowing that. That makes even more important to leave a "safety" 
margin.

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

Sure. It should be stated.

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

Well, that's right.

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

Sure, it should be removed. Thanks!

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

You are right, but in this particular portion of the text, 20 roundtrips 
means exactly that, 20 roundtrips. We also added a byte-based limit: "a 
few tens of kilooctets".
Probably that limit should be more specific, like 15 kilooctets, or 32. 
Anyway, if you think it would increase readability, it won't harm :).

Best regards,
Alejandro

>
> 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
>>
>
>
>
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext