Re: [proxies] [IETF Proxy] Next Steps

["Dan Harkins" <[e-mail]>]

  Hi Glen,

On Sat, May 3, 2008 1:55 pm, Glen Zorn wrote:
> [e-mail] <> scribbled on Friday, May 02, 2008 4:07 PM:
>
>>  Hi Stefan,
>>
>> On Thu, April 17, 2008 6:50 am, Stefan Winter wrote:
>> [snip]
>>> To me, the above model seems to have two role models of proxies:
>>>
>>> - the "technical" proxy - to aggregate or channelize traffic for
>>> managability reasons
>>> - the "political" proxy - due to the requirement or wish to inspect,
>>> control or modify traffic while in flight
>>>
>>> The first kind might go away with dynamic discovery between service
>>> provider and home server; the second might most certainly not. So my
>>> answer to the proxy problem in general is: we will have to live with
>>> them.
>>
>>  This political proxy thing concerns me. The only traffic
>> that a AAA proxy could inspect, control or modify is AAA
>> traffic. So what this entity would do is glean information
>> about who is using what network where and, in some cases,
>> prevent some people somewhere from using some network.
>>
>>  These are not things that I think we _have_ to deal with
>> especially in a technical forum. These are issues that a
>> customer will require a vendor of AAA product to support, in
>> much the same way that "lawful intercept"
>> is a political add-on to a technical solution-- e.g. the IPsec
>> WG did not architect "lawful intercept" into RFC2401 but
>> people that have implemented IPsec have added backdoors into
>> their products to allow for it.
>
> If the "security gateway" is not an architected listening post, what is
> it?

  It's an architected security gateway that secures traffic based on a
well-defined policy. By the nature of the beast at least one of its
interfaces will probably be unsecured and traffic on the network on
which that interface is connected can be snarfed. But that doesn't mean
it's an "architected listening post".

  If the vendor added what we used to call "service spy mode" where it
would T-off specified traffic and send one copy to the intended destination
and another to some nefarious location then that would be in line with
what I was talking about.

  But "service spy mode" is not part of the IPsec specification. It's
a political add-on that certain vendors have added after they were asked
for it.

>> I'm sure that some RFP
>> somewhere will mandate, if it doesn't already, that
>> evesdropping and controlling entities be required in between
>> AAA client and AAA server but that isn't really the
>> problemspace we're dealing with.
>
> Things aren't quite as sinister as you seem to imagine, Dan.  Attributes
> may be added or removed for perfectly valid operational reasons; that is
> exactly the problemspace with which we're dealing.  It's not always
> either possible or appropriate for the home AAA server to be aware of
> the correct parameters to be supplied to a visited NAS, for example...

  Once again, you're missing the point. Perfectly valid operational issues
are one thing. Mandating something for purely political reasons-- to
enable evesdropping or tracking-- is quite another. And I don't think
these political motivations justify proxys in any way.

>>  I have heard many other reasons why AAA proxies must exist.
>> If a magic wand made all those reasons disappear I really hope
>> this political justification would not keep them around.
>> (Note: I'm not entertaining the notion of getting rid of
>> proxies, just theorizing, so don't attack me).
>>
>>  This does highlight threats though. It's not just that
>> proxies can listen to AAA exchanges, they can glean
>> information out of AAA exchanges, and they can constrain or
>> deny service that should otherwise be unconstrained or allowed.
>
> Hmm.  Substitute "would" for "should" & it seems to me that you have
> just restated a definition of the term "authorization".

  So? It's a threat. A tool used inappropriately can be a weapon. Cars,
guns, even plastic bags come with threat warnings describing what can
happen if not used properly. I think it deserves mentioning what problems
can arise if proxies are used inappropriately.

  Dan.




_______________________________________________
Proxies mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/proxies