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

[Peter Deacon <[e-mail]>]

On Thu, 22 Aug 2013, Alejandro Perez Mendez wrote:

> Hello Peter,
> thanks for the comments. See some responses below.

>>> Based on the discussion in Berlin we are ready to start another
>>> adoption call for the solution for fragmentation of RADIUS packets.

>> I would support this draft with narrower scope as interim solution 
>> addressing a specific use.

>> Have some concerns with draft as a general solution:

>> Section 2.
>> RFC5176 dynamic auth clients are not necessarily always RADIUS servers. 
>> We have production systems where CoA client and RADIUS server are 
>> separate with separate roles.  Seeing value in maintaining separation I 
>> do not favor Additional-Authorization.

>> Accounting proposal is not atomic and depends on assumptions about type 
>> of content.  (e.g long attribute not able to fit within 4096 byte limit 
>> cannot be transmitted)

> I probably misunderstood your comment. We do not deal with CoA or 
> Accounting exchanges. They are left the way they are.

Hi Alejandro,

>From section 2 "scope of this document".  Perhaps it might be best to 
simply address what is supported and remove extraneous references to what 
is not changed (CoA and Accounting).  Specifically:

"  Instead, the
    CoA client MUST send a CoA-Request packet containing session
    identification attributes, along with Service-Type = Additional-
    Authorization, and a State attribute.  Implementations not supporting
    fragmentation will respond with a CoA-NAK, and an Error-Cause of
    Unsupported-Service.

    Implementations supporting this specification may not be able to
    change authorization data for a particular session.  In that case,
    they MUST respond with a CoA-NAK, as above.  Otherwise, the
    implementation MUST start fragmentation via Access-Request, using the
    methods defined here."

>> Proposed 'T' bit in extended long attributes means existing systems 
>> supporting extended attributes may require enhancement to pass needed 
>> data.  Despite 'SHOULD' language from RFC6929 I do not believe it 
>> reasonable expectation proxy systems able to understand an attribute 
>> known to be broke would elect to forward such an attribute anyway.

>> Attribute proxy not possible without proxy server modification to 
>> support draft.

>> Existing proxy servers not supporting draft may lose ability to 
>> understand/enforce policy when attribute fragmentation is used.

> According to your previous comment, that would be partially true, but 
> only when the proxy supports RFC6929.

Thinking about a case where there is a fragmented "Pre-authorization" 
request.  Attributes normally sent with Access-Request could be scattered 
about in different Access-Requests requests?

I'm a little confused with "authentication" terminology normally during 
Access-Request there are attributes which provide context to 
authentication and then attributes which perform authentication.

Attributes normally in Access-Request that are not passwords or EAPs is 
essentially "Pre-authorization" or is there another separation?

>From section 2

" Specifically, its scope is limited to the exchange of authorization
    data, as other exchanges do not require of such a mechanism.  In
    particular, authentication exchanges have already been defined to
    overcome this limitation"

Is this still true in -06?

For example am I allowed to send NAS-Id in first request and a 
NAS-Port-Type attribute in subsequent message where they are later 
combined by RADIUS server?  If so just as an example what happens if an 
old proxy server is doing something that depends on both of these items 
being present?  If just one is present there could be behavior it misses?

regards,
Peter