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

[Alan DeKok <[e-mail]>]

Peter Deacon wrote:
> For example consider a roaming network enforcing data filtering rules
> for all participants.  It may check authorization parameters and inject
> additional rules to meet networks policy objectives if home
> authentication server has neglected to enforce agreed upon policy.

  i.e. that proxy is largely *terminating* the authorization parameters,
and injecting new ones.

  I used to work at a roaming company where we did exactly that, so I'm
aware of the use-case.  I think the fragmentation draft needs to support
the use-case, too.

> In this specific case the problem is 'M' bit in long extended type is
> set where RFC6929 says it ought not to be.  As any logical attribute can
> be conveyed the purpose "E2E" or otherwise does not seem to be knowable
> in advance.

  The intention of the client is to convey the authorization data to the
home server.  That seems a fairly clear E2E purpose to me.

> As stipulated when I originally responded to call for adoption my
> objections to this draft only apply when scope is not narrowed to where
> authors intend to use it. (e.g. Eduroam)

  The draft can be useful outside of that context.  My suggestion allows
it to be used in a roaming context like you suggest.

  I see the objections as being largely artificial in nature.  If a
client needs to use the draft inside of a roaming consortium, it can:

   a) send the data, and proxies won't filter / modify it

   b) ask the proxies to upgrade to support the draft, at which point
      they can filter / modify the fragmented data.

  Both options are workable.

  Alan DeKok.