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

[Alan DeKok <[e-mail]>]

Peter Deacon wrote:
> Speaking for myself this is problematic.  Dynamic auth clients are just
> clients with no capability to act as RADIUS server.  They only manage a
> subset of possible authorization parameters not capable of full response.

  Would it be possible to change them?  After all, implementing any
draft requires changes to existing systems.

  As with anything RADIUS, no proposal will be perfect.  There may be
some situations where the proposal doesn't match existing practices.
e.g. multiple clients behind a NAT.  The solution isn't to give on the
proposal and walk away.  The solution may be to say that certain
situations are simply not supported.

> The argument is not whether it is possible to coordinate rather value in
> maintaining separation.  If transport limits are lifted rather than
> supporting adoption of this draft none of these "workarounds" are
> necessary.

  Write a draft proposing to lift the transport limits for UDP.  Make it
 handle all of the existing situations.  e.g. "my upstream equipment
doesn't deal with fragmented UDP packets, therefore I absolutely oppose
raising the transport limits".

  When you replace one imperfect proposal with another imperfect
proposal because the first one is imperfect... I just find it unproductive.

> I apologize for any confusion.  By attribute proxy I mean forwarding
> requests based on attributes other than User-Name.

  See my response to Stefan.

  Are there roaming federations which proxy based on anything *other*
than User-Name?  If so, I'm unaware of them.

  What you do in your own network is your issue.  However, the draft
could be clearer, and state that private networks need to do something
so that the fragmentation proxy works.

> My understanding is both existing and new attributes may be conveyed
> using the fragmentation mechanism.  Existing attributes may end up being
> transmitted in separate requests where previously they would have to
> occur in the same request.

  Yes.  This does not address my counter-argument.

> [ re: UDP fragmentation]
>
> This is an edge problem within most operators administrative control to
> effect.

  Maybe.  Do a search for "SIP UDP fragmentation", and you'll see many
complaints.  The summary is that fragmented UDP packets are not
generally supported across the Internet.  An operator may be able to fix
their own equipment.  They do *not* have the capability to fix someone
else's equipment.

  Alan DeKok.