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

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

Hi Stefan,

thanks for the thorough review. Let me try to complete Alan's answers.

> Hello,
>
> I support adoption of this document as an immediate solution to a
> real-world problem.
>
> As stated on the mic in Berlin, a more long-term solution would be to
> modify the RADIUS protocol to allow more than 4096 bytes, and to
> transmit over a transport which does not need to resort to UDP
> fragmentation, i.e. over TCP (with or without TLS). I understand that
> work to that end is ongoing, but not submitted as an I-D yet. When that
> work has happened, it may be that the the work done in this draft will
> eventually become obsolete; but that's not a reason not to adopt it at
> this point.
>
> I've reviewed -06 and have a few nits.
>
> 1. Introduction
> ===============
> You state: "As noted in that document [RFC6158], the practical
>     limit on RADIUS packet sizes is governed by the Path MTU (PMTU),
>     which may be significantly smaller than 4096 octets."
>
> I wouldn't phrase it in such a harsh way. A packet with
> PMTU < packet size <= 4096
> will lead to UDP fragmentation, sure. But that's not the end of the
> world. The consequence of it is that you have to make sure you are using
> sane network equipment which can handle that condition. When that is the
> case, the practical limit remains the 4096 boundary.
>
> In eduroam, we firs thought that we'll have to limit ourselves to the
> PMTU in an attempt of duck-and-cover, but in the long run, the only sane
> thing to do was to document that UDP frag support is required, and to
> shout loudly at operators if we found their equipment not to do it properly.
>
> In that light, I see your draft as useful (only) in cases where the data
> to be transmitted is actually >4096 bytes; for anything below my answer
> would be "fix your equipment!".
>
> In the second bullet, you state that the approach "is not usable". As
> you explain later in the paragraph, it *is*. It is only very clumsy;
> some deployments might put enough effort into their setup to get it to
> work that way. So for this item, I'd rather like to see you state that
> it is not very practical for most deployments, as opposed to unusable.
>
> Your draft is from 2 July, when RADIUS Extensions was already RFC6929;
> you still mention its draft. Please update the reference.
>
> 2. Scope
> ========
> I have trouble parsing the third and fourth para here. First you state
> that CoA does not need to be fragmented. Then in the next para there
> seems to be a mechanism that is about: if it is needed anyway, then
> here's an alternative to do it; the alternative involves sending an
> Access-Request.
>
> I don't understand how this goes together. If it's not needed, it's not
> needed - and no alternative needs to be specified.
>
> I guess the core of my confusion is the sentence "Implementations
> supporting this specification may not be able to change authorization
> data for a particular session." Why (they do support fragmentation, but
> not for this particular session)? And if they can't, why is that a
> fragmentation problem?
>
> I also don't get how the roles are here. A CoA client is often the
> RADIUS server; the CoA Server is the NAS.
>
> In that paragraph, "implementations" seems to be a CoA Server/NAS -
> because you require such an implementation to send a CoA NAK.
> If that's true, I wonder why fragmentation would occur; the bulk of the
> authorization change payload data is sent from the CoA client (RADIUS
> server) to the CoA Server (NAS). The return is either an ACK or a NAK,
> but according to RFC5176's Table of Attributes, their content is
> extremely limited in size.
>
> 3. Overview
> ===========
> As stated above, IMHO your definition of "size limit" should really be
> exactly 4096 bytes; not the min(PMTU,4096).
>
> I also continue my long-standing comment about hazardous unknowns again:
> You state
>
>    "The number of
>     attributes encoded in a particular chunk depends on the size limit,
>     the size of each attribute, the number of proxies between client and
>     server, and the overhead for fragmentation signalling attributes."
>
> The size limit, size of attributes, and size of fragmentation overhead
> signalling are known and can be calculated.
>
> The "number of proxies between client and server" is UNknown and CANNOT
> be considered in the chunk size calculation.

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

> Even if Proxy-State-Len is
> able to figure out how many Proxy-State space is needed, it will still
> be a whacky assumption because those proxies could decide they need to
> add *more* bytes than just a Proxy-State attribute; they could add or
> delete more VSAs or arbitrary other attributes. There is no way for an
> implementation of your draft to know that.

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.

> I know that sections 5 and 7
> speak about this. I just want to reiterate that this is a rather
> dangerous/necessarily-clumsy area of the spec. E.g. Proxy-State-Len
> might fail its discovery if the packet size is not monotonically
> increasing from proxy to proxy.

I agree. This attribute tries to help deciding. A Client may keep 
sending 1KB chunks no matter what the Proxy-State-Len says. In the worse 
case, you have plain RADIUS (i.e. chunk size fixed on configuration files).


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

>
> In the paragraph about the "Extended Type" attributes you introduce a
> new flag to support chunking. I'm not convinced this is necessary. Sure,
> RFC6929 requires that all fragments of Long-Extended need to be
> consecutive, in the same packet, and be in-order. But that is not
> necessarily something you need to consider; your draft requires to
> re-assemble the chunks before treating the combined result as packet "as
> usual". So long as the Long-Extended checks are performed after the
> re-assembly has been done, all is fine on that layer.
>
> 4.1 Pre-authz
> =============
> For the last exchange, you incorrectly state
> "It generates the appropriate response, which can be either
> Access-Accept or Access-Reject."
>
> It may also be an Access-Challenge; imagine a big fragmented packet, out
> of which one attribute is EAP-Message which starts an EAP conversation.

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.

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

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