Re: [apps-discuss] Comments on draft-ietf-appsawg-http-forwarded-02

SM <sm@resistor.net> Thu, 17 May 2012 22:52 UTC

Return-Path: <sm@resistor.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBE121F85B1 for <apps-discuss@ietfa.amsl.com>; Thu, 17 May 2012 15:52:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.487
X-Spam-Level:
X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJKfE4qfK9ar for <apps-discuss@ietfa.amsl.com>; Thu, 17 May 2012 15:52:28 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DF021F85A7 for <apps-discuss@ietf.org>; Thu, 17 May 2012 15:52:28 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q4HMq6Jc027470; Thu, 17 May 2012 15:52:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1337295131; i=@resistor.net; bh=wM2zMkha5PSvsXv3NVwcSSHiFe3y16RD0D2kcySBIu0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=waha06pdbQKfg10nZqafkEolBNvP6HjXTBmJzG3zRhypDtigagHkd8do8jwVY2X2Y kyD92I0lGufMihfVCDn1AsMzY/3jw/odyxyn/K/hrrijZEg9r5NZvNT0b8N+dCeCIg hjxG7yw0HtHZEgtvHVNfzp/TpU3eY4EVNlqfIxbE=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1337295131; i=@resistor.net; bh=wM2zMkha5PSvsXv3NVwcSSHiFe3y16RD0D2kcySBIu0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=IbEwUuyxDSQFiIK6/i7G9LhqevYC/sSJq9/9G2FLDZLNIRGd7GDoKtTgNr5GUu9X0 SXFy8a9V0SogZGOXyMfrspKmPrLIth6jS1H7WSV5F2Z7kYxcQLAYi/GGrNxY2XIDV2 5TuGWhHm1Gd7cH2otnYCuMC1nrhbcWgRK0pb6AfA=
Message-Id: <6.2.5.6.2.20120517151720.0ab367c8@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 17 May 2012 15:39:24 -0700
To: Alissa Cooper <acooper@cdt.org>
From: SM <sm@resistor.net>
In-Reply-To: <B3876539-F25E-4519-99CF-04A59D5E36D0@cdt.org>
References: <6.2.5.6.2.20120502074325.0ababa28@elandnews.com> <4FAFA51F.4040508@sbin.se> <6.2.5.6.2.20120513074613.092bab70@resistor.net> <4FB0D246.4020608@cs.tcd.ie> <20120514122954.242cb1be@hetzer> <4FB0E828.9040405@cs.tcd.ie> <20120514134501.067cbd96@hetzer> <4FB18597.1020703@cs.tcd.ie> <6.2.5.6.2.20120514155407.099847c8@resistor.net> <B3876539-F25E-4519-99CF-04A59D5E36D0@cdt.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-http-forwarded-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 May 2012 22:52:31 -0000

Hi Alissa,
At 14:29 17-05-2012, Alissa Cooper wrote:
>    As a general matter, the Forwarded extention does not seek to make hosts
>    any more identifiable than they would be if their traffic were 
> not passing through a proxy. [Wondering if there are corner cases 
> here. See note 2 below.]
>
>    The trust placed in the information conveyed by the Forwarded 
> extension is likely
>    to be the same as for current practices with source IP addresses.  In
>    that sense, a forwarded IP address can be spoofed.  Furthermore, 
> users of anonymous proxies may be capable of stripping forwarded
>    information before it reaches its destination.

With all due respect I beg to disagree about this.  There are cases 
when the proxy is selected by the user so that their host is not 
identifiable.  The user is intentionally trying not to have the 
client host identified.

The spoofing is an interesting point.  The user agent could add the 
relevant header.  That can be traced though.  User agents, by 
default, may not offer such functionality.

How can users of anonymous proxies strip forwarded information before 
it reaches its destination?

>2. I'm wondering if, in addition to the information leak problem 
>discussed in 8.2, there is also an issue of distinguishability of 
>multiple users who are all behind the same NAT/proxy but may not all 
>be behind the same chain of proxies. That is, suppose A and B are 
>the only two hosts behind a particular NAT and A installed the NAT 
>to help protect his identity. B's traffic passes through 2 further 
>proxies that use Forwarded headers before arriving at C. A's traffic 
>passes through no proxies to arrive at C. C can now effectively 
>identify A. This is just one case -- I'm not sure how realistic it 
>is, but I'm sure there are others. Seems like this is worth more 
>thought/discussion in the text.

The NAT case is different as the user cannot affect "chaining" unless 
he/she has control over the infrastructure.

Web Proxy chaining is used in an attempt to make it more difficult to 
"trace back" to the client.  There can be multiple proxy hops, which 
the user does not operate, before the destination is reached.

Regards,
-sm