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

El 21/08/13 15:44, Stefan Winter escribió:
> Hi,
>
>>    The PMTU / 4096 octet problem is one which I think should be supported
>> by the draft.  Telling operators to "fix their equipment" works in some
>> cases.  In others, it's useful to be able to fragment at sizes which are
>> *known* to work.
> I don't have particularly hard feelings about this; so if there's use
> for it, the text can also stay as it is.
>
>>    Fragmentation in this draft is only for authorization (Access-Request
>> / Access-Accept).  CoA can be done via sending a CoA with "Service-Type
>> = Additional-Authorization".  The client should then do fragmentation as
>> per the draft.  It's just too much to add fragmentation in multiple
>> places in the protocol.
> That's how I understood the first two paras in the document. The third
> one seemed to deal with the CoA-ACK/NAK replies, but there I got lost
> why these would need to be fragmented.

We will improve that paragraph, to make it clearer.

>
>>    Additional fragmentation in proxies can be done.  But it likely
>> involves re-assembly and subsequent re-sending / re-fragmentation of the
>> entire data.  Doing "on the fly" additional fragmentation is just too
>> hard (IMHO).
> So it would suffice to state that chunks are not supposed to be
> fragmented as-is; they need to be re-assembled into the long packet, and
> then that needs to be chunked again.

We could add that sentence if it serves to clarify further that aspect.

>
>>    We need a new flag for extended-type attributes.  Each Access-Request
>>   / Access-Accept packet MUST be a perfect RADIUS packet in and of
>> itself.  Some proxies MAY support RFC 6929, and will toss the packet if
>> it isn't formatted correctly.  i.e. if the attribute fragments "fall
>> off" the end of a packet.
> That doesn't seem right. If a proxy supports RFC6929, but not the
> fragmentation draft, it will not know that the T flag exists and can't
> react accordingly. It will see an M flag and some gibberish in the
> Reserved field (which RFC6929 says should simply be ignored). It will
> observe that the M flag requirements are violated and has every right to
> drop the packet.

Probably you are right. Indeed we have repeatedly discuss about that 
flag's utility, but we decided that having it will not harm anyone. 
However, it makes specification slightly complexer, and if it is not 
really useful, I agree it should be just removed.

>
>>    Fragmentation doesn't work with Access-Challenge.  There was a lot of
>> discussion between the draft authors about this.  The fragmentation is
>> *only* for authorization.  And it carries *only* authorization data, not
>> authentication data.  Think of it as pausing an existing RADIUS
>> conversation, and inserting a "fragmented data" exchange.
> That's understood; I didn't want Access-Challenge packets to be
> fragmented. My concern was that an initial (long) Access-Request needs
> to be fragmented, but that upon completing its reassembly, the server
> side finds that it is in the middle of an exchange which requires
> Access-Challenge as a subsequent packet. It must be possible to finalise
> the fragmented packet reassambly not just with an Accept or Reject; it
> may need to be a Challenge to complete the subsequent authentication
> that is done after the pre-authz.

Nope, the first Access-Request packet of an Authentication conversation 
is supposed to not need to be fragmented, as authentication mechanisms 
(e.g. RADIUS-EAP) already deal with packet size. If a Client generates a 
large Access-Request packet with EAP-Message, would be most probably to 
the inclusion of additional authorization attributes, and then, a 
pre-authz exchange is the way to go.

>
>>    We're assuming that proxy decisions are made via User-Name.  If it's
>> done via anything else... well... sorry, but it won't work.  There are
>> trade-offs which have to be made.
>>
>>    And eduroam proxying via SSID is just weird.  Isn't the SSID for
>> eduroam just "EDUROAM"?
> Sure it is. But you may be participating in more than one consortium
> with your hotspot.
>
> Imagine a single access point which is part of "eduroam" and "S-Mobile";
> and emits both SSIDs. Both consortia use RADIUS auth; the access point
> is dumb and only knows "its" authentication server.
>
> At that point, the RADIUS server which gets the AP's packet needs to
> realise: if a user tried to log into the eduroam SSID, I'll proxy the
> packet to eduroam infrastructure; if the user tried S-Mobile, I'll proxy
> to their infrastructure.
>
> That's real life (but not on very many sites, as far as I can see).
>
> "Sorry" may well be the appropriate answer. But that answer should be
> written explicitly into the draft.

We need to clearly state that, so far, proxying is only supported by 
means of User-Name attribute. Although I guess that's allowing a 
different attribute could be something configurable.

Best regards,
Alejandro
>
> Greetings,
>
> Stefan Winter
>
>
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext