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

[Peter Deacon <[e-mail]>]

On Tue, 3 Sep 2013, Diego R. Lopez wrote:

> As I see it, there is a clear rule for proxy behavior with respect to 
> this: Proxies have to behave in the most transparent possible way 
> because they are simply relays for the communication. Validations (for 
> security, semantics or whatever else) should occur only E2E. If you want

While I appreciate many here are working on behalf of a specific network 
assumptions made above are not universal.

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.

> to have a middlebox that breaks E2E validation for whatever the reason 
> (as much legitimate as it can be) don't claim it to be a proxy.

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.

> In brief: Hop-by-hop security MUST be checked at each proxy, of course. 
> But E2E security MUST NOT be checked at a proxy.

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)

I don't support the above sentence with HOP/E2E/MUST/MUST NOT language in 
the general context although it may seem perfectly reasonable in the 
context of your network.

regards,
Peter