Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting

<mohamed.boucadair@orange.com> Wed, 16 November 2011 13:34 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A614C21F9521 for <int-area@ietfa.amsl.com>; Wed, 16 Nov 2011 05:34:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.115
X-Spam-Level:
X-Spam-Status: No, score=-3.115 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001]
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 qwUfVggzzR8i for <int-area@ietfa.amsl.com>; Wed, 16 Nov 2011 05:34:24 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id ACC1A21F951B for <int-area@ietf.org>; Wed, 16 Nov 2011 05:34:23 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 2793E2DC5E0; Wed, 16 Nov 2011 14:34:22 +0100 (CET)
Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 047204C066; Wed, 16 Nov 2011 14:34:22 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 16 Nov 2011 14:34:21 +0100
From: mohamed.boucadair@orange.com
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, "int-area@ietf.org" <int-area@ietf.org>
Date: Wed, 16 Nov 2011 14:34:20 +0100
Thread-Topic: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
Thread-Index: AcykKryT9yWolJKLSj+ELiFC2giOygAN5x+A
Message-ID: <94C682931C08B048B7A8645303FDC9F35A8B20E0F6@PUEXCB1B.nanterre.francetelecom.fr>
References: <6DD45DA1-C5D8-4F46-A2C7-A5425DF249FA@gmx.net>
In-Reply-To: <6DD45DA1-C5D8-4F46-A2C7-A5425DF249FA@gmx.net>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.11.16.130326
Cc: JACQUENET Christian OLNC/NAD/TIP <christian.jacquenet@orange.com>
Subject: Re: [Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2011 13:34:24 -0000

Dear Hannes, all,

Thank you for your comments.

We seriously considered the privacy comment; this is why we contacted the IETF privacy mailing list hopping to receive feedback (see http://www.ietf.org/mail-archive/web/int-area/current/msg02958.html) but unfortunately only one comment was received (see http://www.ietf.org/mail-archive/web/ietf-privacy/current/msg00092.html).

You quoted this text from the draft: 

> "
>    The HOST_ID does not reveal more privacy information than what the
>    source IP address does in a non-shared address environment (see
>    [I-D.morris-privacy-considerations]).
> "

without explicitly stating what is wrong with that text. 

I would appreciate if you can provide some guidance about the content of the Privacy Section. Thanks.

The document does not advocate for the use of source IP address for implicit identification but only acknowledge (quoting RFC6269) that such systems will break when address sharing is used. 

Cheers,
Med
 

> -----Message d'origine-----
> De : int-area-bounces@ietf.org 
> [mailto:int-area-bounces@ietf.org] De la part de Hannes Tschofenig
> Envoyé : mercredi 16 novembre 2011 07:41
> À : int-area@ietf.org
> Objet : [Int-area] My comments on 
> draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting
> 
> Hi all, 
> 
> I wanted to repeat my comments on the draft from the working 
> group session because I raised my hand when Suresh asked 
> whether this document is a good starting point as a WG item. 
> 
> My comments on the microphone concerned two aspects: 
> 
> * Scope
> 
> At the beginning of the presentation the purpose of the 
> document was advertised to the audience as telling others 
> about the implication of address sharing (because people do 
> not know about that). The expected audience was seen as both 
> inside the IETF (the MTCP group was described as a group that 
> is in need to lean about NATs) and outside the IETF. RFC 6269 
> already does this. 
> 
> It was also stated in the draft as well as in the 
> presentation that recommendations regarding the solutions 
> will be provided. During the working group session I believe 
> we reached an agreement that the document would only document 
> existing solutions and not provide recommendations on what to 
> use for what specific application usages).
> 
> Here my concern was that documenting solutions to an 
> unspecified range of problems is somewhat difficult when you 
> talk about pros and cons. During the presentation alone more 
> than three application domains were mentioned, namely denial 
> of service attacks, charging, and authentication without 
> having to re-type the password (a SSO type of solution). Some 
> of you would agree with me that the solution space to only 
> these three application scenarios is much larger than what is 
> described in the document. 
> 
> I called it "stupid" to use the IP address for authentication 
> purposes and the presenters made jokes about that statement 
> (in the wrong believe I think they are stupid). Clearly, Joe 
> and Pierre also do not believe that the source IP address can 
> be used for authentication today anymore because that is the 
> main statement of their draft - you have to at least consider 
> the source port as well. I encourage those who believe in 
> these types of "authentication" mechanisms to come to the 
> OAuth working group meeting tomorrow to hear how other people 
> in the industry do authentication today. 
> 
> (Btw, I am not the first who had made the observation that IP 
> address for authentication is not such a great idea. Have a 
> look at Steve Bellovin's publication from 1989 with the title 
> "Security Problems in the TCP/IP Protocol Suite".)
> 
> * Privacy
> 
> The document cites draft-morris-privacy-considerations-03, 
> which is good, but from the writeup in Section 1.2 I had 
> gotten the impression that the authors do not believe in 
> privacy and therefore wash it away with statements like: 
> "
>    The HOST_ID does not reveal more privacy information than what the
>    source IP address does in a non-shared address environment (see
>    [I-D.morris-privacy-considerations]).
> "
> 
> Even if the authors do not believe in privacy (or and maybe 
> other  design properties as well) there may still other 
> people out there who find it important to consider it 
> particularly if it has the potential to void other IETF work.
> 
> I would like to avoid the mistake that was made with RFC 
> 6302: on one hand the authors of RFC 6302 assumed that 
> readers have no clue about networking and don't know that 
> they also have to log port numbers (in addition to IP 
> addresses) but on the other hand they assumed they will know 
> a lot about the privacy implications of logging. How likely is that? 
> 
> Ciao
> Hannes
> 
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>