Re: [proxies] [IETF Proxy] Next Steps

"Dan Harkins" <> Sun, 04 May 2008 00:21 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id E469B3A6983; Sat, 3 May 2008 17:21:15 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E37333A6967 for <>; Sat, 3 May 2008 17:21:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.883
X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DcUProJ7RX0E for <>; Sat, 3 May 2008 17:21:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0D1633A6915 for <>; Sat, 3 May 2008 17:21:14 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 68986A8882BA; Sat, 3 May 2008 17:21:15 -0700 (PDT)
Received: from (SquirrelMail authenticated user by with HTTP; Sat, 3 May 2008 17:21:15 -0700 (PDT)
Message-ID: <>
In-Reply-To: <>
References: <><> <> <>
Date: Sat, 3 May 2008 17:21:15 -0700 (PDT)
From: "Dan Harkins" <>
To: "Glen Zorn" <>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
X-Priority: 3 (Normal)
Importance: Normal
Subject: Re: [proxies] [IETF Proxy] Next Steps
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for ad hoc group interested in security and proxies <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

  Hi Glen,

On Sat, May 3, 2008 1:55 pm, Glen Zorn wrote:
> <> 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.


Proxies mailing list