Re: [proxies] Recap for -00 draft

Alan DeKok <> Fri, 02 May 2008 16:07 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id 5DC3E28C1BC; Fri, 2 May 2008 09:07:15 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7A423A67D0 for <>; Fri, 2 May 2008 09:07:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uFt3QD7uypdK for <>; Fri, 2 May 2008 09:07:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 670023A6A5E for <>; Fri, 2 May 2008 09:06:37 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTP id 9F25CA7052 for <>; Fri, 2 May 2008 09:06:35 -0700 (PDT)
Message-ID: <>
Date: Fri, 02 May 2008 18:02:26 +0200
From: Alan DeKok <>
User-Agent: Thunderbird (X11/20080227)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Subject: Re: [proxies] Recap for -00 draft
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="utf-8"
Content-Transfer-Encoding: base64

Katrin Hoeper wrote:
> 1) a worldwide WLAN that enables roaming registered users to access
> information free of charge
> (thanks Stefan for your detailed description)

  I'll see if I can write up a description of a commercial global
roaming system.

> 1) proxies can listen to traffic
> 2) insert fake accounting  packets

  - users can use stolen credentials
  - visited networks can listen to traffic
  - visited networks can insert fake accounting packets
  - home network can authenticate the user, and then
    refuse to pay the proxy or the visited network

> -easy to sniff traffic for proxies
> -most attributes readable due to AAA hop-by-hop security

  - everyone in the "AAA trust" boundary can see all of the traffic,
    and lie about any of it.

> -depends on the content of the exchanged data
> When data contains valuable user information (such as the user’s age),
> this information can be correlated with the user identity and then be
> exploited.
> -depends on national laws and regulations
> -depends on whether offered services are free or paid
> -some providers seem to be more worried about malicious insiders and
> outsider sniffers rather than proxies

  I would add a section "mitigating factors".  These are not *solution*,
but pragmatic self-interest.

 - if the visited networks have a pattern of theft/fraud, the
   proxies and/or home networks will refuse to work with them
 - if the proxies have a pattern of theft/fraud, the
   visited and/or home networks will refuse to work with them
 - if the home networks have a pattern of refusal to pay bills,
   the visited networks / proxies will refuse to work with them
 - if a user has a pattern of theft/fraud, the home network will
   refuse to authorize their access

  i.e. as soon as someone gets caught doing bad things, it's in everyone
else's interest to kick them out of the AAA network.


  - home networks inform proxies / visited networks about limits on
    their willingness to pay.  e.g. "allow 10 minutes of access"
  - visited networks are responsible for enforcing these limits
  - home networks refuse to pay for access outside of those limits
    after all... the visited network was *told* to hang up.  If it
    doesn't, the home network isn't responsible for the bill
  - the visited network is responsible for informing the proxies
    and home network that the user is still online, and what they are
    doing (time/traffic accounting).  If they stop, the home network
    can assume that the user has logged off, and refuse to pay for
    further service.
  - if mid-session disconnection is supported, the home network
    can inform the visited network to disconnect the user.  Again,
    the visited network does this, because the home network will
    refuse to pay for service after a disconnection request has been

> Please send other information that you would like to be included in the
> 00 draft to the list. Also let me know if you disagree with previous
> discussions (items I-IV, not solutions!). Off course, everybody is more
> than welcome to volunteer as a co-author. Just let me know.

  I'm interested, but I don't know how much time I have.

> We definitely need more use cases. I will try to cover all aspects
> listed under IV. Severity in the use cases. It would be very helpful if
> people could send me more “real implementation” examples of networks
> using proxies, especially the architecture of such networks and the
> particular functions of proxies in them (e.g. what data do they need to
> know).

  I'll grab some diagrams and send them over.

  As for the data the proxies need to know... it's as much data as the
visited network can supply.  Which is usually nothing more than user
identification, visited network identification (access points, etc.),
data traffic in/out, and session time.

  Everyone would like to get more data, but the equipment at the visited
networks is so old that it often doesn't support 8 year-old standards.

  Alan DeKok.
Proxies mailing list