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

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

El 23/08/13 02:12, Peter Deacon escribió:
> 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."
>

The purpose of that text is to explain why we do not deal with CoA or 
Accounting, that is, why they do not need of a fragmentation solution. 
Removing them would provoke other people to ask why we do not support them.

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

They are completely different exchanges, composed by different packets. 
Let me picture it.

Let's imagine the following exchange where, in addition to the usual 
authentication exchange (that is, RADIUS-EAP), the NAS wants to send a 
SAML request to the AS, that will be replied after the User has been 
authenticated. SAML messages could exceed the 4096 limit.

User ----- EAP-Identity ---> NAS (triggers a RADIUS conversation)

Pre-authorization exchange: NAS needs to send authz data to AS prior 
authentication. This is actually carried out by a series of 
Access-Request/Access-Accept exchanges.
NAS  ----- SAML request ---> AS

Authentication exchange: typical RADIUS-EAP exchange. No changes at all.
NAS  ----- EAP-Identity ---> AS
NAS  <----     EAP      ---> AS
NAS  <---- Access-Accept---- AS

Post authorization exchange: AS needs to send authz data to NAS after 
authentication. This is actually carried out by a series of 
Access-Accept/Access-Request exchanges.
NAS  <---- SAML Response---- AS

All these exchanges are tied together by the use of the State attribute.
I hope this clarifies the concepts
>
> 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?

That paragraph just states that current existing authentication 
exchanges (e.g. RADIUS-EAP) already deal with fragmentation issues. 
That's why we do not interfere.

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

Alan provided an answer to this in relation to Stefan's comments: We're 
assuming that proxy decisions are made via User-Name.

Regards,
Alejandro

>
> regards,
> Peter