Re: [proxies] [IETF Proxy] Next Steps

Bernard Aboba <bernard_aboba@hotmail.com> Fri, 02 May 2008 22:25 UTC

Return-Path: <proxies-bounces@ietf.org>
X-Original-To: proxies-archive@ietf.org
Delivered-To: ietfarch-proxies-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A43063A68BB; Fri, 2 May 2008 15:25:28 -0700 (PDT)
X-Original-To: proxies@core3.amsl.com
Delivered-To: proxies@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B044C3A6A65 for <proxies@core3.amsl.com>; Fri, 2 May 2008 15:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.82
X-Spam-Level:
X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=0.778, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebYUBS5cTf4c for <proxies@core3.amsl.com>; Fri, 2 May 2008 15:25:26 -0700 (PDT)
Received: from blu139-omc2-s12.blu139.hotmail.com (blu139-omc2-s12.blu139.hotmail.com [65.55.175.182]) by core3.amsl.com (Postfix) with ESMTP id 64CE23A6C71 for <proxies@ietf.org>; Fri, 2 May 2008 15:23:55 -0700 (PDT)
Received: from BLU137-W50 ([65.55.162.185]) by blu139-omc2-s12.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 May 2008 15:23:57 -0700
Message-ID: <BLU137-W506321B2B181EA8A61C6F593DA0@phx.gbl>
X-Originating-IP: [131.107.0.105]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Katrin Hoeper <katrin.hoeper@nist.gov>, Stefan Winter <stefan.winter@restena.lu>, proxies@ietf.org
Date: Fri, 02 May 2008 15:23:57 -0700
Importance: Normal
In-Reply-To: <7.0.1.0.2.20080502100123.023b9330@nist.gov>
References: <7.0.1.0.2.20080416172531.02401228@nist.gov> <200804171550.48931.stefan.winter@restena.lu> <7.0.1.0.2.20080502100123.023b9330@nist.gov>
MIME-Version: 1.0
X-OriginalArrivalTime: 02 May 2008 22:23:57.0293 (UTC) FILETIME=[366EB1D0:01C8ACA3]
Subject: Re: [proxies] [IETF Proxy] Next Steps
X-BeenThere: proxies@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for ad hoc group interested in security and proxies <proxies.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/proxies>, <mailto:proxies-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:proxies@ietf.org>
List-Help: <mailto:proxies-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/proxies>, <mailto:proxies-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0058350158=="
Sender: proxies-bounces@ietf.org
Errors-To: proxies-bounces@ietf.org



Stefan said:
 
It turned out that in addition to the pure authentication information that is user-supplied, it is in some cases necessary for home and service provider server to speak to each other *about* the user. The most prominent example here is: in Australia, unfiltered Internet access is only allowed for adults. So if a foreign eduroam user authenticates within Australia, the visited domain needs to get information about the age of the user. Without proxies, this would not be a problem: define a Vendor-Specific attribute and communicate the value. With proxies, things are worse: the traffic will be sent through intermediate proxy servers, which can then correlate the information of the age to the user identity, and thus create personally identifiable data sets. These are heavily regulated in the EU, introducing a legal problem (I'll save you from the details).
 
[BA] Wouldn't EU regulations have a problem with the local ISP obtaining the age of the user, irrespective of proxies?  Also, why can't the problem (with or without proxies) be solved using the CUI, described in RFC 4372?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 flightThe 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.
 
[BA] I think these issues are described in RFC 2607, no? 
_______________________________________________
Proxies mailing list
Proxies@ietf.org
https://www.ietf.org/mailman/listinfo/proxies