From ietf@meetecho.com Wed Aug 1 13:47:00 2012 Return-Path: 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 8E2B711E828E for ; Wed, 1 Aug 2012 13:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 h1AyyyeQ91ag for ; Wed, 1 Aug 2012 13:46:59 -0700 (PDT) Received: from smtplq04.aruba.it (smtplqs-out18.aruba.it [62.149.158.58]) by ietfa.amsl.com (Postfix) with SMTP id 0DAD211E819B for ; Wed, 1 Aug 2012 13:46:58 -0700 (PDT) Received: (qmail 13257 invoked by uid 89); 1 Aug 2012 20:46:56 -0000 Received: from unknown (HELO smtp4.aruba.it) (62.149.158.224) by smtplq04.aruba.it with SMTP; 1 Aug 2012 20:46:56 -0000 Received: (qmail 4007 invoked by uid 89); 1 Aug 2012 20:46:56 -0000 Received: from unknown (HELO ?130.129.21.177?) (alex@meetecho.com@130.129.21.177) by smtp4.ad.aruba.it with ESMTPA; 1 Aug 2012 20:46:55 -0000 Message-ID: <501995BB.1090600@meetecho.com> Date: Wed, 01 Aug 2012 22:46:51 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: int-area@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Subject: [Int-area] Meetecho support for INTAREA WG X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 20:47:00 -0000 Hi all, a virtual room has been reserved on the Meetecho system for Wednesday's INTAREA WG meeting session. Access to the on-line session (including audio and video streams) will be available at: http://www.meetecho.com/ietf84/intarea The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. Remote participants might also send their own voice to the room, if they want to, by either calling a landline phone number, or using our embedded VoIP applet (in this last case they are *strongly* advised to use a headset). A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf84 Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From dwing@cisco.com Mon Aug 6 17:29:28 2012 Return-Path: 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 D17C821F84C9 for ; Mon, 6 Aug 2012 17:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.489 X-Spam-Level: X-Spam-Status: No, score=-110.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 ktfL4FO5z0Ev for ; Mon, 6 Aug 2012 17:29:28 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0B23621F84CF for ; Mon, 6 Aug 2012 17:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4094; q=dns/txt; s=iport; t=1344299368; x=1345508968; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=WKO8CfLoFMxXzXlClNSGRomSWY0bzJF6+U5u/TN6GP4=; b=cxHXq3w0f4vXSuelIsgA8aPhoUeDXOE7H6IzbkP3UG+GXtIoB/femEaI +AzaAszzE3nxPyXa9mXIskt84mY6zLzdobhjNHLaiwx1u3PR7zSA3IIUD zTQWcLQuZsLPAqSqMQOwTYoUFMieX3FX62VWrMJbdyFBt1EBcaOIwSR2i s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUJACFgIFCrRDoI/2dsb2JhbABFqhqOKgQEgQOBB4IgAQEBAwEICgEKDRA/BQcBAwIJDgECBAEBAScHGSMKCQgBAQQTCxAHh2UFDJsQoDiLSgGGbAOITYUNiQONEoFmgn+BPw X-IronPort-AV: E=Sophos;i="4.77,723,1336348800"; d="scan'208";a="54276424" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 07 Aug 2012 00:29:27 +0000 Received: from dwingWS (sjc-vpn3-793.cisco.com [10.21.67.25]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q770TRNP018194; Tue, 7 Aug 2012 00:29:27 GMT From: "Dan Wing" To: "'Wesley Eddy'" References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <5009A9A3.4050407@ericsson.com> <94C682931C08B048B7A8645303FDC9F36E4A17E2D2@PUEXCB1B.nanterre.francetelecom.fr> <50118D83.9010704@mti-systems.com> <098e01cd6c22$2adce560$8096b020$@com> <50139472.9000901@mti-systems.com> In-Reply-To: <50139472.9000901@mti-systems.com> Date: Mon, 6 Aug 2012 17:29:27 -0700 Message-ID: <089a01cd7433$b4062c70$1c128550$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1skoJBUHKTK3ZwSo+m2K+pX1eidgHoG2XA Content-Language: en-us Cc: 'Internet Area' , 'Behcet Sarikaya' Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 00:29:28 -0000 > -----Original Message----- > From: Wesley Eddy [mailto:wes@mti-systems.com] > Sent: Saturday, July 28, 2012 12:28 AM > To: Dan Wing > Cc: sarikaya@ieee.org; 'Internet Area'; 'Behcet Sarikaya' > Subject: Re: [Int-area] Completion of working group last call for > draft-ietf-intarea-nat-reveal-analysis-02 > > On 7/27/2012 2:03 PM, Dan Wing wrote: > >> -----Original Message----- > >> From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] > On > >> Behalf Of Wesley Eddy > >> Sent: Thursday, July 26, 2012 11:34 AM > >> To: sarikaya@ieee.org > >> Cc: Internet Area; Behcet Sarikaya > >> Subject: Re: [Int-area] Completion of working group last call for > >> draft-ietf-intarea-nat-reveal-analysis-02 > >> > >> On 7/26/2012 1:08 PM, Behcet Sarikaya wrote: > >>> On Thu, Jul 26, 2012 at 3:25 AM, > >> wrote: > >>>> Dear Suresh, all, > >>>> > >>>> After reading received comments, the major point we need to > discuss > >> is whether the WG wants to remove Section 3.3 or maintain it. I'm > >> waiting for a feedback from the WG for the direction to take. I will > >> implement any change requested by the WG. > >>>> > >>> > >>> Section 3.3 seems to give preference to one specific solution, as > >> such > >>> it is against the whole spirit of this document. > >>> > >>> I suggest removing it. > >>> > >> > >> > >> +1 > >> > >> In fact, I suggest that the draft should clearly say that it's > >> doubtful whether a solution actually *needs* to be identified and > >> recommended, especially ones that are implemented awkwardly in other > >> layers. > > > > I can't make technical sense of which of the 8 approaches are > "awkward," in > > your analysis. I have my own analysis, but the document does not do > an > > evaluation on "awkwardness". > > > > > > The underlying problem was identified in Section 13.1 "Abuse Logging > and > > Penalty Boxes" of RFC6269, "Issues with IP Address Sharing", > > http://tools.ietf.org/html/rfc6269#section-13.1. That was an INTAREA > > document. > > > > Hence, that is why the analysis document is also an INTAREA document. > > > > > > My view is the penalty box problem described in Section 13.1 of > RFC6269 is > > real. My view is the penalty box problem will continue to grow so > long as > > there are IPv4-accessible servers and so long as there are IPv6 > clients > > (NAT64) or IPv4 clients accessing those IPv4 servers. There appear > to be > > different views on the size and trajectory of the problem (getting > worse > > versus getting better). Perhaps discussing those views would be > beneficial. > > > > > Hi Dan - The problem is real because there are bits of > deployed code built on an assumption that was good maybe > 12 years ago, that IP addresses could be tied to users or > machines. Since this is totally broken now, the solution > is to get rid of them and use the proper identifiers for > whatever it is that these system are trying to do. During the INTAREA presentation, one suggestion I heard was a separate protocol (ident-like). I will submit an I-D towards that end, which I am dusting off from 2010 when I first considered ident and discarded it for a variety of reasons. Do you have additional suggestions on how to accomplish convey an identifer? > Building > kludges in other layers to supplement the IP address is > not the answer. We do have a long history of crossing layers, as much as we pretend we don't do that -- ARP, IPv6 changing UDP checksum requirements compared to IPv4, incorporation of IP addresses for referrals in dozens of protocols (partially due to lack of a name service). > Since the analysis in the document already indicates that > each of the 8 solutions has non-starter properties to them, > I consider that to make them pretty "awkward". Recommending > any of them is like saying "this is the best tasting crap > we could find." Yeah, awkwardness happens a lot with address sharing. I also wish it was different. -d From internet-drafts@ietf.org Tue Aug 7 06:51:55 2012 Return-Path: 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 419CD21F86EE; Tue, 7 Aug 2012 06:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 uy8nNAwBqI+P; Tue, 7 Aug 2012 06:51:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3389B21F86DA; Tue, 7 Aug 2012 06:51:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120807135153.6655.82736.idtracker@ietfa.amsl.com> Date: Tue, 07 Aug 2012 06:51:53 -0700 Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 13:51:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Area Working Group Working Group= of the IETF. Title : Analysis of Solution Candidates to Reveal a Host Identif= ier (HOST_ID) in Shared Address Deployments Author(s) : Mohamed Boucadair Joe Touch Pierre Levis Reinaldo Penno Filename : draft-ietf-intarea-nat-reveal-analysis-03.txt Pages : 22 Date : 2012-08-07 Abstract: This document analyzes a set of solution candidates to mitigate some of the issues encountered when address sharing is used. In particular, this document focuses on means to reveal a host identifier (HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier must be unique to each host under the same shared IP address. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-nat-reveal-analysis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Tue Aug 7 06:56:58 2012 Return-Path: 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 D684721F870A for ; Tue, 7 Aug 2012 06:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 mYg-PHTtFyId for ; Tue, 7 Aug 2012 06:56:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 18A9221F86D1 for ; Tue, 7 Aug 2012 06:56:57 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 541773B4220 for ; Tue, 7 Aug 2012 15:56:57 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 3D5E4238048 for ; Tue, 7 Aug 2012 15:56:57 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Tue, 7 Aug 2012 15:56:44 +0200 From: To: "int-area@ietf.org" Date: Tue, 7 Aug 2012 15:56:43 +0200 Thread-Topic: I-D Action: draft-ietf-intarea-nat-reveal-analysis-03.txt Thread-Index: Ac10o9NWT5DVEbAsQ7yzW0ZfFs7FzwAABGhA Message-ID: <94C682931C08B048B7A8645303FDC9F36E4CD3028F@PUEXCB1B.nanterre.francetelecom.fr> References: <20120807135153.6655.82736.idtracker@ietfa.amsl.com> In-Reply-To: <20120807135153.6655.82736.idtracker@ietfa.amsl.com> 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.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.7.101815 Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 13:56:59 -0000 Dear all, The main changes are: * Remove the recommendation text * Add a new solution using an out-of-band mechanism (IDENT) * Add a reference to A+P * Several editorial changes to integrate the comments received during WGLC A diff link is provided below.=20 Cheers, Med >-----Message d'origine----- >De : i-d-announce-bounces@ietf.org=20 >[mailto:i-d-announce-bounces@ietf.org] De la part de=20 >internet-drafts@ietf.org >Envoy=E9 : mardi 7 ao=FBt 2012 15:52 >=C0 : i-d-announce@ietf.org >Cc : int-area@ietf.org >Objet : I-D Action: draft-ietf-intarea-nat-reveal-analysis-03.txt > > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. > This draft is a work item of the Internet Area Working Group=20 >Working Group of the IETF. > > Title : Analysis of Solution Candidates to=20 >Reveal a Host Identifier (HOST_ID) in Shared Address Deployments > Author(s) : Mohamed Boucadair > Joe Touch > Pierre Levis > Reinaldo Penno > Filename : draft-ietf-intarea-nat-reveal-analysis-03.txt > Pages : 22 > Date : 2012-08-07 > >Abstract: > This document analyzes a set of solution candidates to mitigate some > of the issues encountered when address sharing is used. In > particular, this document focuses on means to reveal a host > identifier (HOST_ID) when a Carrier Grade NAT (CGN) or application > proxies are involved in the path. This host identifier must be > unique to each host under the same shared IP address. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-03 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-nat-reveal- >analysis-03 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >= From ietf@meetecho.com Tue Aug 7 15:40:10 2012 Return-Path: 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 E8E5121F86E5 for ; Tue, 7 Aug 2012 15:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.751 X-Spam-Level: X-Spam-Status: No, score=0.751 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 ygusdnR4wRNE for ; Tue, 7 Aug 2012 15:40:10 -0700 (PDT) Received: from smtplq03.aruba.it (smtplqs-out18.aruba.it [62.149.158.58]) by ietfa.amsl.com (Postfix) with SMTP id C539221F86EA for ; Tue, 7 Aug 2012 15:40:09 -0700 (PDT) Received: (qmail 15695 invoked by uid 89); 7 Aug 2012 22:40:07 -0000 Received: from unknown (HELO smtp4.aruba.it) (62.149.158.224) by smtplq03.aruba.it with SMTP; 7 Aug 2012 22:40:07 -0000 Received: (qmail 4336 invoked by uid 89); 7 Aug 2012 22:40:07 -0000 Received: from unknown (HELO ?192.168.1.154?) (alex@meetecho.com@87.11.150.210) by smtp4.ad.aruba.it with ESMTPA; 7 Aug 2012 22:40:07 -0000 Message-ID: <50219938.7000706@meetecho.com> Date: Wed, 08 Aug 2012 00:39:52 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "int-area@ietf.org" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Subject: [Int-area] Meetecho session recording available X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 22:40:11 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of INTAREA session at IETF-84 is available. You can watch it by accessing the following URL: http://ietf84.conf.meetecho.com/index.php/Recorded_Sessions#IETF84_INTAREA For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From touch@isi.edu Wed Aug 8 07:50:37 2012 Return-Path: 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 C5AD921F8535 for ; Wed, 8 Aug 2012 07:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.071 X-Spam-Level: X-Spam-Status: No, score=-103.071 tagged_above=-999 required=5 tests=[AWL=-0.472, 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 yT4zi9XwH9U3 for ; Wed, 8 Aug 2012 07:50:37 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 0A52621F84FC for ; Wed, 8 Aug 2012 07:50:37 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q78Enr5m029731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Aug 2012 07:49:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <089a01cd7433$b4062c70$1c128550$@com> Date: Wed, 8 Aug 2012 07:49:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <5009A9A3.4050407@ericsson.com> <94C682931C08B048B7A8645303FDC9F36E4A17E2D2@PUEXCB1B.nanterre.francetelecom.fr> <50118D83.9010704@mti-systems.com> <098e01cd6c22$2adce560$8096b020$@com> <50139472.9000901@mti-systems.com> <089a01cd7433$b4062c70$1c128550$@com> To: Dan Wing X-Mailer: Apple Mail (2.1278) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: 'Internet Area' , 'Behcet Sarikaya' Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 14:50:37 -0000 On Aug 6, 2012, at 5:29 PM, Dan Wing wrote: > ... > During the INTAREA presentation, one suggestion I heard was > a separate protocol (ident-like). I will submit an I-D towards > that end, which I am dusting off from 2010 when I first=20 > considered ident and discarded it for a variety of reasons. >=20 > Do you have additional suggestions on how to accomplish convey > an identifer? There are two separate problems: - establishing an identity and pairing it with a tag - getting that tag into connections so each connection can be correlated = back to the identity This draft focuses on the second step. The first is either trivial (with = cooperating entities) or needs to be inferred if possible (with = non-cooperating/legacy entities). It doesn't matter whether the entity = is a person or a machine in general, though this draft focuses on = machine entities. Any out-of-band mechanism shares the fate of "ident" in this doc, as = noted in Sec 5.9, though. Is there a point to generating another = solution in that space? Joe From scott.brim@gmail.com Wed Aug 8 08:02:37 2012 Return-Path: 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 A102F21F8659 for ; Wed, 8 Aug 2012 08:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.594 X-Spam-Level: X-Spam-Status: No, score=-103.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 e1ByhYWvE4EE for ; Wed, 8 Aug 2012 08:02:37 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6F121F84A1 for ; Wed, 8 Aug 2012 08:02:37 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so1594366pbb.31 for ; Wed, 08 Aug 2012 08:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=l/AMBR7jA5aN8p1Zl0cVqnaf7ksf9KdpeLyBOpLJhdo=; b=iHPbU+2DKZnhdCUped4+BXPyT3aigzzvjNohSCTrCqsnUGLKqqiUWs70/nFINHkJJk VtGgk3Kb6N9KMtOpjTvJ9yRjGyR7j9opZgE1PP2Vgiq95HPqQoe6OKoYBb3DKU2TqbTF au/oNcIn4RX1sTYUjwh2cW/H1bulJ/QD7SKsfelFqrWkaYxkZ79PS9RAR3wzT6i234ip hPec4otVb88qwwyflOkWmgmqZdy6KCVqarhgCVJIud2HXQQwyVuOFVTUpDpHJM2msiem GHQbEyEPwJ3z6HjNMy9Pz3/qPj74pH2I94LYtKmhlnH1+G3K5w8IvE7EUKBuD/1zHgHz pESw== Received: by 10.68.218.103 with SMTP id pf7mr37465025pbc.67.1344438156915; Wed, 08 Aug 2012 08:02:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.48.231 with HTTP; Wed, 8 Aug 2012 08:02:16 -0700 (PDT) In-Reply-To: References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <5009A9A3.4050407@ericsson.com> <94C682931C08B048B7A8645303FDC9F36E4A17E2D2@PUEXCB1B.nanterre.francetelecom.fr> <50118D83.9010704@mti-systems.com> <098e01cd6c22$2adce560$8096b020$@com> <50139472.9000901@mti-systems.com> <089a01cd7433$b4062c70$1c128550$@com> From: Scott Brim Date: Wed, 8 Aug 2012 11:02:16 -0400 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Cc: Internet Area , Behcet Sarikaya Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 15:02:37 -0000 On Wed, Aug 8, 2012 at 10:49 AM, Joe Touch wrote: > > On Aug 6, 2012, at 5:29 PM, Dan Wing wrote: > >> ... >> During the INTAREA presentation, one suggestion I heard was >> a separate protocol (ident-like). I will submit an I-D towards >> that end, which I am dusting off from 2010 when I first >> considered ident and discarded it for a variety of reasons. >> >> Do you have additional suggestions on how to accomplish convey >> an identifer? > > > There are two separate problems: > > - establishing an identity and pairing it with a tag > > - getting that tag into connections so each connection can be correlated back to the identity 3) making sure that not everyone can associate the identity with that tag. From dwing@cisco.com Wed Aug 8 08:30:58 2012 Return-Path: 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 0BEFF11E80ED for ; Wed, 8 Aug 2012 08:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.495 X-Spam-Level: X-Spam-Status: No, score=-110.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 lUPfX3VpgaN1 for ; Wed, 8 Aug 2012 08:30:51 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 867D821F8587 for ; Wed, 8 Aug 2012 08:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1313; q=dns/txt; s=iport; t=1344439851; x=1345649451; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=iG7K5/eA+roifz406gZ2X+ldMK34VDkPRPZiiQYEnMo=; b=Iwg/V6GIh3sq64v5eLmYzkpJwKckipSbhtcvBwwo/yZDC+aFSQN3ivvg g7xh6ftCa8bGXmgIQ6ti2QzHBqpO7lm5PkkjOxbl9vSLccRc1qmwiwwI9 vpIYDegXGmAZgOSd5Eu0SxCjEkDkUnXquedOjqfrzpQu4vk1EqfNgQwpo 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQJAH6FIlCrRDoI/2dsb2JhbAA8CQ6qCY4/BAR+gQeCIAEBAQQICgEKDRA/DAEDAgkPAgQBAQEnBxkIGwoJCAEBBAESCxeHXAMLmnCWZA2JTootZRGGTwOIToUMhhyMXYMfgWaCJlk X-IronPort-AV: E=Sophos;i="4.77,733,1336348800"; d="scan'208";a="51331340" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 08 Aug 2012 15:30:51 +0000 Received: from dwingWS (sjc-vpn4-1372.cisco.com [10.21.85.91]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q78FUo99000902; Wed, 8 Aug 2012 15:30:50 GMT From: "Dan Wing" To: "'Scott Brim'" , "'Joe Touch'" References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <5009A9A3.4050407@ericsson.com> <94C682931C08B048B7A8645303FDC9F36E4A17E2D2@PUEXCB1B.nanterre.francetelecom.fr> <50118D83.9010704@mti-systems.com> <098e01cd6c22$2adce560$8096b020$@com> <50139472.9000901@mti-systems.com> <089a01cd7433$b4062c70$1c128550$@com> In-Reply-To: Date: Wed, 8 Aug 2012 08:30:51 -0700 Message-ID: <0e0e01cd757a$cb343a70$619caf50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac11duCyFmvikYmgRcaAulBkiGd4zAAA2wTQ Content-Language: en-us Cc: 'Internet Area' , 'Behcet Sarikaya' Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 15:30:58 -0000 > -----Original Message----- > From: Scott Brim [mailto:scott.brim@gmail.com] > Sent: Wednesday, August 08, 2012 8:02 AM > To: Joe Touch > Cc: Dan Wing; Internet Area; Behcet Sarikaya > Subject: Re: [Int-area] Completion of working group last call for > draft-ietf-intarea-nat-reveal-analysis-02 > > On Wed, Aug 8, 2012 at 10:49 AM, Joe Touch wrote: > > > > On Aug 6, 2012, at 5:29 PM, Dan Wing wrote: > > > >> ... > >> During the INTAREA presentation, one suggestion I heard was > >> a separate protocol (ident-like). I will submit an I-D towards > >> that end, which I am dusting off from 2010 when I first > >> considered ident and discarded it for a variety of reasons. > >> > >> Do you have additional suggestions on how to accomplish convey > >> an identifer? > > > > > > There are two separate problems: > > > > - establishing an identity and pairing it with a tag > > > > - getting that tag into connections so each connection can be > correlated back to the identity > > 3) making sure that not everyone can associate the identity with that > tag. Scott, Today's Internet users, which are not sharing addresses with other users, are sending an uniquely-identifyable identifier to every Internet server they use: their unique IP address. -d From touch@isi.edu Wed Aug 8 09:08:48 2012 Return-Path: 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 8485221F8702 for ; Wed, 8 Aug 2012 09:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.032 X-Spam-Level: X-Spam-Status: No, score=-103.032 tagged_above=-999 required=5 tests=[AWL=-0.433, 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 xdvi15J1BpdP for ; Wed, 8 Aug 2012 09:08:48 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0499A21F86FF for ; Wed, 8 Aug 2012 09:08:47 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q78G8CVB021515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Aug 2012 09:08:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Joe Touch In-Reply-To: Date: Wed, 8 Aug 2012 09:08:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <18E43FE2-563B-4EFE-AD7B-285F98794DFF@isi.edu> References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <5009A9A3.4050407@ericsson.com> <94C682931C08B048B7A8645303FDC9F36E4A17E2D2@PUEXCB1B.nanterre.francetelecom.fr> <50118D83.9010704@mti-systems.com> <098e01cd6c22$2adce560$8096b020$@com> <50139472.9000901@mti-systems.com> <089a01cd7433$b4062c70$1c128550$@com> To: Scott Brim X-Mailer: Apple Mail (2.1278) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Internet Area , Behcet Sarikaya Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:08:48 -0000 On Aug 8, 2012, at 8:02 AM, Scott Brim wrote: > On Wed, Aug 8, 2012 at 10:49 AM, Joe Touch wrote: >>=20 >> On Aug 6, 2012, at 5:29 PM, Dan Wing wrote: >>=20 >>> ... >>> During the INTAREA presentation, one suggestion I heard was >>> a separate protocol (ident-like). I will submit an I-D towards >>> that end, which I am dusting off from 2010 when I first >>> considered ident and discarded it for a variety of reasons. >>>=20 >>> Do you have additional suggestions on how to accomplish convey >>> an identifer? >>=20 >>=20 >> There are two separate problems: >>=20 >> - establishing an identity and pairing it with a tag >>=20 >> - getting that tag into connections so each connection can be = correlated back to the identity >=20 > 3) making sure that not everyone can associate the identity with that = tag. or forge it, etc. Yes, there are numerous conditions on the two steps = above. I tend to think of these as steps (as above) and conditions on = the steps. Joe= From touch@isi.edu Wed Aug 8 09:10:49 2012 Return-Path: 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 211D021F861F for ; Wed, 8 Aug 2012 09:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.998 X-Spam-Level: X-Spam-Status: No, score=-102.998 tagged_above=-999 required=5 tests=[AWL=-0.399, 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 xmqLTbbu--wa for ; Wed, 8 Aug 2012 09:10:48 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3C35421F861A for ; Wed, 8 Aug 2012 09:10:48 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q78G9YsK021947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Aug 2012 09:10:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <0e0e01cd757a$cb343a70$619caf50$@com> Date: Wed, 8 Aug 2012 09:09:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <10662386-12AB-4140-A5B9-E4F77D2BF46D@isi.edu> References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <5009A9A3.4050407@ericsson.com> <94C682931C08B048B7A8645303FDC9F36E4A17E2D2@PUEXCB1B.nanterre.francetelecom.fr> <50118D83.9010704@mti-systems.com> <098e01cd6c22$2adce560$8096b020$@com> <50139472.9000901@mti-systems.com> <089a01cd7433$b4062c70$1c128550$@com> <0e0e01cd757a$cb343a70$619caf50$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1278) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: 'Internet Area' , 'Behcet Sarikaya' Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:10:49 -0000 On Aug 8, 2012, at 8:30 AM, Dan Wing wrote: >> 3) making sure that not everyone can associate the identity with that >> tag. >=20 > Scott, >=20 > Today's Internet users, which are not sharing addresses with other = users, > are sending an uniquely-identifyable identifier to every Internet = server > they use: their unique IP address. =20 Given how IP addresses are used today, an address alone is insufficient = to indicate a host. That's the whole point of this doc. Addresses and ports together sometimes do, but not in all cases. Other = IDs are required - again, the conclusion of this doc. Out-of-band IDs are problematic for many reasons, again as per Sec 5.9 Joe From wes@mti-systems.com Wed Aug 8 20:25:52 2012 Return-Path: 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 948DC21F855B for ; Wed, 8 Aug 2012 20:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 NiBvkr21rC18 for ; Wed, 8 Aug 2012 20:25:52 -0700 (PDT) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id F0A2B21F855A for ; Wed, 8 Aug 2012 20:25:51 -0700 (PDT) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q793PpKr015438 for ; Wed, 8 Aug 2012 23:25:51 -0400 Authentication-Results: cm-omr11 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [69.81.143.209] ([69.81.143.209:31301] helo=[192.168.1.113]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id FC/A6-32544-EBD23205; Wed, 08 Aug 2012 23:25:51 -0400 Message-ID: <50232DAF.7060702@mti-systems.com> Date: Wed, 08 Aug 2012 23:25:35 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Dan Wing References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <5009A9A3.4050407@ericsson.com> <94C682931C08B048B7A8645303FDC9F36E4A17E2D2@PUEXCB1B.nanterre.francetelecom.fr> <50118D83.9010704@mti-systems.com> <098e01cd6c22$2adce560$8096b020$@com> <50139472.9000901@mti-systems.com> <089a01cd7433$b4062c70$1c128550$@com> <0e0e01cd757a$cb343a70$619caf50$@com> In-Reply-To: <0e0e01cd757a$cb343a70$619caf50$@com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Internet Area' , 'Behcet Sarikaya' Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 03:25:52 -0000 On 8/8/2012 11:30 AM, Dan Wing wrote: > Today's Internet users, which are not sharing addresses with other users, > are sending an uniquely-identifyable identifier to every Internet server > they use: their unique IP address. Users don't have IP addresses. Machines do. Which are we trying to identify again? I think the distinction is important since the relation between users and devices can be one-to-many, or many-to-one, and certainly isn't one-to-one, even if we went back in time when the relation between end-host machines and addresses might have been closer to one-to-one. I also don't think user and subscriber are synonyms for many purposes, though some of the reveal-analysis seems to be more oriented towards identifying the access network subscriber. That subscriber generally may have quite a few users and machines behind them. -- Wes Eddy MTI Systems From dwing@cisco.com Thu Aug 9 10:07:48 2012 Return-Path: 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 62AB121F87A5 for ; Thu, 9 Aug 2012 10:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.503 X-Spam-Level: X-Spam-Status: No, score=-110.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 30yiZ2qWkBKm for ; Thu, 9 Aug 2012 10:07:47 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id BC0A521F87A1 for ; Thu, 9 Aug 2012 10:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2883; q=dns/txt; s=iport; t=1344532067; x=1345741667; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=AOKXHRoCYj7s3b+Ic0xFt3YLL209gIWiTF4rRvJOHQQ=; b=dcsEDAhchBGFyhhTJWtrR7pHptkuP33KMkAK/g994jjnWFKpKrUC0SeL JN+nTUPrfNLztYp1M6LHf5cqCkC4t9zEEdyYVDh2GVutm3pzLQV8XnlhT ElLQ31yZfO9pieSNpm/mPV2g1ibSsKtEztw308D/zOhNCbrnNndw2uHnV k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIJAIzgI1CrRDoI/2dsb2JhbAA7CqogjkQEBHaBB4IgAQEBAwEICgEKDRA4BwUHAQMCCQ4BAgQBAQEWARAHGSMKCQgBAQQTCxeHZQWbB6Btiw8QgzQBgx8DiE6FDJYYgWaCf4E4 X-IronPort-AV: E=Sophos;i="4.77,741,1336348800"; d="scan'208";a="51446653" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 09 Aug 2012 17:07:47 +0000 Received: from dwingWS (sjc-vpn7-1991.cisco.com [10.21.151.199]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q79H7baI023470; Thu, 9 Aug 2012 17:07:47 GMT From: "Dan Wing" To: "'Wesley Eddy'" References: <4FD206D3.3010200@ericsson.com> <4FEB2D67.1010901@ericsson.com> <5009A9A3.4050407@ericsson.com> <94C682931C08B048B7A8645303FDC9F36E4A17E2D2@PUEXCB1B.nanterre.francetelecom.fr> <50118D83.9010704@mti-systems.com> <098e01cd6c22$2adce560$8096b020$@com> <50139472.9000901@mti-systems.com> <089a01cd7433$b4062c70$1c128550$@com> <0e0e01cd757a$cb343a70$619caf50$@com> <50232DAF.7060702@mti-systems.com> In-Reply-To: <50232DAF.7060702@mti-systems.com> Date: Thu, 9 Aug 2012 10:07:08 -0700 Message-ID: <03cc01cd7651$7f5a3820$7e0ea860$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac113q2jlHAJQOEFTHie3+VbfZ9iXgAarwqA Content-Language: en-us Cc: 'Internet Area' , 'Behcet Sarikaya' Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 17:07:48 -0000 > -----Original Message----- > From: Wesley Eddy [mailto:wes@mti-systems.com] > Sent: Wednesday, August 08, 2012 8:26 PM > To: Dan Wing > Cc: 'Scott Brim'; 'Joe Touch'; 'Internet Area'; 'Behcet Sarikaya' > Subject: Re: [Int-area] Completion of working group last call for > draft-ietf-intarea-nat-reveal-analysis-02 > > On 8/8/2012 11:30 AM, Dan Wing wrote: > > Today's Internet users, which are not sharing addresses with other > users, > > are sending an uniquely-identifyable identifier to every Internet > server > > they use: their unique IP address. > > Users don't have IP addresses. Machines do. Which are > we trying to identify again? I think the distinction > is important since the relation between users and devices > can be one-to-many, or many-to-one, and certainly isn't > one-to-one, even if we went back in time when the > relation between end-host machines and addresses might > have been closer to one-to-one. > > I also don't think user and subscriber are synonyms for > many purposes, though some of the reveal-analysis seems to > be more oriented towards identifying the access network > subscriber. RFC6269 section 13.1 mixes the term 'subscriber' itself: When an abuse is reported today, it is usually done in the form: IPv4 address X has done something bad at time T0. This is not enough information to uniquely identify the subscriber responsible for the ........................................^^^^^^^^^^ abuse when that IPv4 address is shared by more than one subscriber. ...........................................................^^^^^^^^^^ Second and more likely is that one user who fails a number of login ......................................^^^^ attempts may block out other users who have not made any previous ................................^^^^^ attempts but who will now fail on their first attempt. > That subscriber generally may have quite a few users > and machines behind them. draft-ietf-intarea-nat-reveal-analysis is not analyzing that problem. Today's IP address penalty boxes do not attempt to distinguish between the hacker son at home doing a dictionary attack against a mailserver and the mom trying to legitimately login to that same mailserver. The mailserver will protect itself from the dictionary attack by putting that offending IP address into a penalty box. The different problem that draft-ietf-intarea-nat-reveal-analysis is analyzing is when multiple subscribers can no longer be individually identified by their IP address because of IP address sharing. This means the hacker son (in the scenario in the previous paragraph) can now deny service to everyone else sharing that same IP address, which could be dozens or hundreds of subscribers. We might replace 'hacker son' with 'compromised host'. -d From suresh.krishnan@ericsson.com Fri Aug 17 14:26:24 2012 Return-Path: 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 07DA011E80E3 for ; Fri, 17 Aug 2012 14:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.575 X-Spam-Level: X-Spam-Status: No, score=-106.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaCbWL1XW2Nh for ; Fri, 17 Aug 2012 14:26:23 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 881B411E80D1 for ; Fri, 17 Aug 2012 14:26:23 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q7HLQakg028044 for ; Fri, 17 Aug 2012 16:27:01 -0500 Received: from [142.133.112.80] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.264.1; Fri, 17 Aug 2012 17:26:19 -0400 Message-ID: <502EB6FA.5060903@ericsson.com> Date: Fri, 17 Aug 2012 17:26:18 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Internet Area X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: [Int-area] Minutes from IETF 84 available X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 21:26:24 -0000 Hi all, The minutes from the intarea WG meeting at IETF84 are available on the proceedings site. Thanks to Linda Dunbar for taking the minutes. http://www.ietf.org/proceedings/84/minutes/minutes-84-intarea.txt If there are any inaccuracies or omissions in the minutes, please let us know by Friday August 31, 2012. Thanks Suresh & Julien From jmh@joelhalpern.com Mon Aug 20 13:52:19 2012 Return-Path: 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 9AE3221F8617 for ; Mon, 20 Aug 2012 13:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.355 X-Spam-Level: X-Spam-Status: No, score=-102.355 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPuSDHpef9S8 for ; Mon, 20 Aug 2012 13:52:19 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4FC21F858A for ; Mon, 20 Aug 2012 13:52:19 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id ADEC7A30FE for ; Mon, 20 Aug 2012 13:52:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 38B1A1C9E76 for ; Mon, 20 Aug 2012 13:52:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-71-161-50-78.clppva.btas.verizon.net [71.161.50.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 89E511C9E74 for ; Mon, 20 Aug 2012 13:52:16 -0700 (PDT) Message-ID: <5032A37E.7040604@joelhalpern.com> Date: Mon, 20 Aug 2012 16:52:14 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Internet Area Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Int-area] Nat Reveal Analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 20:52:19 -0000 My thanks to the authors for submitting a revised version of draft-ietf-intarea-nat-reveal-analysis-03. I have looked at this document, and have a few comments. First, thank you for removing the explicit recommendation. I find section 2.1 on IPv6 applicability somewhat confusing. The most common technique I know of for topology hiding, NPT66, does so in a fashion that does not conflate identities. As such, it is not obvious that there is an IPv6 problem. It seems that this short section should either be removed or elaborated. Minor: Is there a reason that the analysis in section 5 is in a different order than the columns of the table in section 4? It would help the reader if they proceeded in the same order. Also, did the authors consider reversing the order of sections 4 and 5? In trying to read the very useful summary at the end of section 4, I found that I kept needing to read ahead to section 5, and then go back to the summary. In the description in 5.1 of the IP-ID function, it seemed to me that the server would need to know in all cases whether or not this is being used. I can imagine mechanisms to provide that information. But the text implies that only some variants of IP-ID need such additional information. Am I missing some obvious reason why it is not always necessary? Nit: Is section 4.1 (requirements on the solution) really privacy related recommendations? Would it make sense to call it that, and maybe move it into section 3 (privacy)? I believe the concerns raised above can be easily addressed, and once done this document seems to be ready for advancement. Yours, Joel M. Halpern From mohamed.boucadair@orange.com Mon Aug 20 22:35:37 2012 Return-Path: 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 8593A11E80E4 for ; Mon, 20 Aug 2012 22:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZ4y-jPI0mh5 for ; Mon, 20 Aug 2012 22:35:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B401011E80DF for ; Mon, 20 Aug 2012 22:35:36 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 5FC8F18CB0D; Tue, 21 Aug 2012 07:35:35 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 43268238048; Tue, 21 Aug 2012 07:35:35 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 21 Aug 2012 07:35:14 +0200 From: To: "Joel M. Halpern" , Internet Area Date: Tue, 21 Aug 2012 07:35:13 +0200 Thread-Topic: [Int-area] Nat Reveal Analysis Thread-Index: Ac1/Faezlo56zoNRQO+3+dKlBjU9YgARlMZQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E52298959@PUEXCB1B.nanterre.francetelecom.fr> References: <5032A37E.7040604@joelhalpern.com> In-Reply-To: <5032A37E.7040604@joelhalpern.com> 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.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.21.10322 Subject: Re: [Int-area] Nat Reveal Analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 05:35:37 -0000 Dear Joel, Thank you for the review.=20 Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : int-area-bounces@ietf.org=20 >[mailto:int-area-bounces@ietf.org] De la part de Joel M. Halpern >Envoy=E9 : lundi 20 ao=FBt 2012 22:52 >=C0 : Internet Area >Objet : [Int-area] Nat Reveal Analysis > >My thanks to the authors for submitting a revised version of=20 >draft-ietf-intarea-nat-reveal-analysis-03. > >I have looked at this document, and have a few comments. >First, thank you for removing the explicit recommendation. > >I find section 2.1 on IPv6 applicability somewhat confusing. The most=20 >common technique I know of for topology hiding, NPT66, does so in a=20 >fashion that does not conflate identities. As such, it is not obvious=20 >that there is an IPv6 problem. It seems that this short=20 >section should=20 >either be removed or elaborated. Med: I updated the text as follows: OLD: Some of the issues mentioned in Section 2 are independent of IPv4 vs. IPv6. Even in IPv6, address sharing can be used for a variety of reasons (e.g., to hide network topology, to defeat hosts from offering network services directly, etc.). NEW: Some of the issues mentioned in Section 2 are independent of IPv4 vs. IPv6. Even in IPv6, address sharing can be used for a variety of reasons (e.g., to hide network topology, to defeat hosts from offering network services directly, etc.). An example is an NPTv6 translator [RFC6296] using a prefix longer than /56 for its algorithmic address mapping. In such context, if a remote server enforces policies (e.g., blacklist a misbehaving user) based on the first 48 or 56 bits, several IPv6 hosts will be impacted. Is the new text better? > > >Minor: > Is there a reason that the analysis in section 5 is in a=20 >different=20 >order than the columns of the table in section 4? It would help the=20 >reader if they proceeded in the same order. Med: The table is updated to follow the same order as in Section 5. The ord= er is Section 5 follows the protocol layering.=20 > Also, did the authors consider reversing the order of sections 4=20 >and 5? In trying to read the very useful summary at the end=20 >of section=20 >4, I found that I kept needing to read ahead to section 5, and then go=20 >back to the summary. Med: I reversed the order of these 2 sections in my local copy. The new ToC= is: 4. Detailed Solutions Analysis . . . . . . . . . . . . . . . . . 7 5. Solutions Analysis: Synthesis . . . . . . . . . . . . . . . . 15 > > In the description in 5.1 of the IP-ID function, it seemed to me=20 >that the server would need to know in all cases whether or not this is=20 >being used. I can imagine mechanisms to provide that=20 >information. But=20 >the text implies that only some variants of IP-ID need such additional=20 >information. Am I missing some obvious reason why it is not always=20 >necessary? Med: The advert mechanism is needed for all schemes. I updated the text to = avoid that confusion. OLD: A variant of this approach relies upon the format of certain packets, such as TCP SYN, where the IP-ID can be modified to contain a 16 bit HOST_ID. Address sharing devices performing this function would require to indicate they are performing this function out of band, possibly using a special DNS record. NEW: A variant of this approach relies upon the format of certain packets, such as TCP SYN, where the IP-ID can be modified to contain a 16 bit HOST_ID. Address sharing devices performing this function would require to indicate they are performing this function out of band, possibly using a special DNS record. > >Nit: Is section 4.1 (requirements on the solution) really privacy=20 >related recommendations? Would it make sense to call it that,=20 >and maybe=20 >move it into section 3 (privacy)? Med: Done. The updated ToC is now: 3. HOST_ID and Privacy . . . . . . . . . . . . . . . . . . . . . 6 3.1. Privacy-related Requirements . . . . . . . . . . . . . . . 7 > >I believe the concerns raised above can be easily addressed, and once=20 >done this document seems to be ready for advancement. Med: Thanks. > >Yours, >Joel M. Halpern >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area >= From brian@innovationslab.net Tue Aug 21 05:35:08 2012 Return-Path: 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 F20B821F863B for ; Tue, 21 Aug 2012 05:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPIaFlPeTAJu for ; Tue, 21 Aug 2012 05:35:06 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8C46021F8621 for ; Tue, 21 Aug 2012 05:35:06 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 38A3E88099; Tue, 21 Aug 2012 05:35:06 -0700 (PDT) Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id E1DE4130017; Tue, 21 Aug 2012 05:35:05 -0700 (PDT) Message-ID: <503380B8.6050708@innovationslab.net> Date: Tue, 21 Aug 2012 08:36:08 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: int-area@ietf.org, "int-ads@tools.ietf.org" References: <4FFB5F28.2040704@innovationslab.net> In-Reply-To: <4FFB5F28.2040704@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Int-area] Working group summaries X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 12:35:08 -0000 All, As noted below, we now have WG summaries being submitted after each meeting. The summaries submitted for IETF 84 are available at: http://trac.tools.ietf.org/area/int/trac/wiki/IETF84 I want to thank the 15 pairs of WG chairs that submitted their summaries in a timely manner. Of the 17 Internet Area WGs that met in Vancouver, only two have not provided summaries to date. If you have any comments or feedback on these summaries, do not hesitate to contact the ADs. Regards, Brian On 7/9/12 6:46 PM, Brian Haberman wrote: > All, > With the Internet Area being large (25 Working Groups) and > diverse, it can be time consuming for participants to track the > activities that may affect them. To help keep people up to date, we > have asked the chairs of each WG within the area to generate a brief > update on their WG's progress. These updates will be done at the end of > each IETF meeting and posted to the INT Area wiki > (http://trac.tools.ietf.org/area/int/trac/wiki). > > The goal of these summaries is not to give an in-depth assessment > of all the happenings within a WG. Rather, it should be a set of > highlights that may be of interest to people not actively involved in > the WG. We hope that these reports will be useful to the INT Area > community. > > Regards, > Brian & Ralph > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From jmh@joelhalpern.com Tue Aug 21 06:49:09 2012 Return-Path: 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 C5A3521F8600 for ; Tue, 21 Aug 2012 06:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.354 X-Spam-Level: X-Spam-Status: No, score=-102.354 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sumMAne5qnJI for ; Tue, 21 Aug 2012 06:49:09 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1FC21F85AD for ; Tue, 21 Aug 2012 06:49:09 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id AE83C558011 for ; Tue, 21 Aug 2012 06:49:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 7B3071C08F9; Tue, 21 Aug 2012 06:49:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-71-161-50-78.clppva.btas.verizon.net [71.161.50.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id BA82E1C079B; Tue, 21 Aug 2012 06:49:04 -0700 (PDT) Message-ID: <503391CE.2080908@joelhalpern.com> Date: Tue, 21 Aug 2012 09:49:02 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <5032A37E.7040604@joelhalpern.com> <94C682931C08B048B7A8645303FDC9F36E52298959@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E52298959@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Internet Area Subject: Re: [Int-area] Nat Reveal Analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 13:49:09 -0000 Thank you for your prompt attention. I have removed the agreed items. I am still confused by the proposed new IPv6 text. The text says that if a server uses short prefixes it will apply the policy too coarsely. On the one hand, that is true even if NPT66 is not used. On the other, the solution is already present. Use the full 128 bits. This does not require any new mechanisms. Yours, Joel On 8/21/2012 1:35 AM, mohamed.boucadair@orange.com wrote: > Dear Joel, > > Thank you for the review. > > Please see inline. > Cheers, > Med > >> -----Message d'origine----- >> De : int-area-bounces@ietf.org >> [mailto:int-area-bounces@ietf.org] De la part de Joel M. Halpern >> Envoyé : lundi 20 août 2012 22:52 >> À : Internet Area >> Objet : [Int-area] Nat Reveal Analysis >> >> My thanks to the authors for submitting a revised version of >> draft-ietf-intarea-nat-reveal-analysis-03. >> >> I have looked at this document, and have a few comments. >> First, thank you for removing the explicit recommendation. >> >> I find section 2.1 on IPv6 applicability somewhat confusing. The most >> common technique I know of for topology hiding, NPT66, does so in a >> fashion that does not conflate identities. As such, it is not obvious >> that there is an IPv6 problem. It seems that this short >> section should >> either be removed or elaborated. > > Med: I updated the text as follows: > > OLD: > > Some of the issues mentioned in Section 2 are independent of IPv4 vs. > IPv6. Even in IPv6, address sharing can be used for a variety of > reasons (e.g., to hide network topology, to defeat hosts from > offering network services directly, etc.). > > NEW: > > Some of the issues mentioned in Section 2 are independent of IPv4 vs. > IPv6. Even in IPv6, address sharing can be used for a variety of > reasons (e.g., to hide network topology, to defeat hosts from > offering network services directly, etc.). > > An example is an NPTv6 translator [RFC6296] using a prefix longer > than /56 for its algorithmic address mapping. In such context, if a > remote server enforces policies (e.g., blacklist a misbehaving user) > based on the first 48 or 56 bits, several IPv6 hosts will be > impacted. > > Is the new text better? From mohamed.boucadair@orange.com Tue Aug 21 07:55:05 2012 Return-Path: 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 8DEBD21F8668 for ; Tue, 21 Aug 2012 07:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKl6zaqKZ8p3 for ; Tue, 21 Aug 2012 07:55:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7952821F865C for ; Tue, 21 Aug 2012 07:55:04 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 9196E2647FD; Tue, 21 Aug 2012 16:55:03 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 7585135C045; Tue, 21 Aug 2012 16:55:03 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Tue, 21 Aug 2012 16:54:43 +0200 From: To: "Joel M. Halpern" Date: Tue, 21 Aug 2012 16:54:41 +0200 Thread-Topic: [Int-area] Nat Reveal Analysis Thread-Index: Ac1/o7DlV05Sg5ATSMy4QZMmJweFqQAAYHkQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E52298B41@PUEXCB1B.nanterre.francetelecom.fr> References: <5032A37E.7040604@joelhalpern.com> <94C682931C08B048B7A8645303FDC9F36E52298959@PUEXCB1B.nanterre.francetelecom.fr> <503391CE.2080908@joelhalpern.com> In-Reply-To: <503391CE.2080908@joelhalpern.com> 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.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.21.142415 Cc: Internet Area Subject: Re: [Int-area] Nat Reveal Analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 14:55:05 -0000 Re-, If /128 is used to enforce the policies then there is no issue at all. =20 The point is that using /128 to black list a spammer for instance is not ef= ficient; that's why it is likely servers will use the first 64 bits (or eve= n /56) to install a filter....the damage can be restricted to a home premis= es or a large number of customers when NPTv6 is used or any other deploymen= t context requiring the share the first 64 bits. Does this makes sense to you? Cheers, Med >-----Message d'origine----- >De : Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 >Envoy=E9 : mardi 21 ao=FBt 2012 15:49 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Internet Area >Objet : Re: [Int-area] Nat Reveal Analysis > >Thank you for your prompt attention. >I have removed the agreed items. >I am still confused by the proposed new IPv6 text. >The text says that if a server uses short prefixes it will apply the=20 >policy too coarsely. >On the one hand, that is true even if NPT66 is not used. >On the other, the solution is already present. Use the full 128 bits.=20 >This does not require any new mechanisms. > >Yours, >Joel > >On 8/21/2012 1:35 AM, mohamed.boucadair@orange.com wrote: >> Dear Joel, >> >> Thank you for the review. >> >> Please see inline. >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : int-area-bounces@ietf.org >>> [mailto:int-area-bounces@ietf.org] De la part de Joel M. Halpern >>> Envoy=E9 : lundi 20 ao=FBt 2012 22:52 >>> =C0 : Internet Area >>> Objet : [Int-area] Nat Reveal Analysis >>> >>> My thanks to the authors for submitting a revised version of >>> draft-ietf-intarea-nat-reveal-analysis-03. >>> >>> I have looked at this document, and have a few comments. >>> First, thank you for removing the explicit recommendation. >>> >>> I find section 2.1 on IPv6 applicability somewhat=20 >confusing. The most >>> common technique I know of for topology hiding, NPT66, does so in a >>> fashion that does not conflate identities. As such, it is=20 >not obvious >>> that there is an IPv6 problem. It seems that this short >>> section should >>> either be removed or elaborated. >> >> Med: I updated the text as follows: >> >> OLD: >> >> Some of the issues mentioned in Section 2 are=20 >independent of IPv4 vs. >> IPv6. Even in IPv6, address sharing can be used for a variety of >> reasons (e.g., to hide network topology, to defeat hosts from >> offering network services directly, etc.). >> >> NEW: >> >> Some of the issues mentioned in Section 2 are=20 >independent of IPv4 vs. >> IPv6. Even in IPv6, address sharing can be used for a variety of >> reasons (e.g., to hide network topology, to defeat hosts from >> offering network services directly, etc.). >> >> An example is an NPTv6 translator [RFC6296] using a prefix longer >> than /56 for its algorithmic address mapping. In such=20 >context, if a >> remote server enforces policies (e.g., blacklist a=20 >misbehaving user) >> based on the first 48 or 56 bits, several IPv6 hosts will be >> impacted. >> >> Is the new text better? >= From jmh@joelhalpern.com Tue Aug 21 08:10:46 2012 Return-Path: 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 0029021F8759 for ; Tue, 21 Aug 2012 08:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.353 X-Spam-Level: X-Spam-Status: No, score=-102.353 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6YM6FItXgpV for ; Tue, 21 Aug 2012 08:10:45 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC7221F875A for ; Tue, 21 Aug 2012 08:10:45 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 3422D5582A1 for ; Tue, 21 Aug 2012 08:10:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id E97F71BD3443; Tue, 21 Aug 2012 08:10:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-71-161-50-78.clppva.btas.verizon.net [71.161.50.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 10F291BD3440; Tue, 21 Aug 2012 08:10:41 -0700 (PDT) Message-ID: <5033A4F0.7030908@joelhalpern.com> Date: Tue, 21 Aug 2012 11:10:40 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <5032A37E.7040604@joelhalpern.com> <94C682931C08B048B7A8645303FDC9F36E52298959@PUEXCB1B.nanterre.francetelecom.fr> <503391CE.2080908@joelhalpern.com> <94C682931C08B048B7A8645303FDC9F36E52298B41@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E52298B41@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Internet Area Subject: Re: [Int-area] Nat Reveal Analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:10:46 -0000 I am sorry, but I am not following. Yes, 128 bits is long, and a large set. But if the spammers are using lots of different identities, then the server has to find some way to keep track of them. If the set is too small, then different users will collide. There are well-known techniques for looking up an ID in a large set of IDs. We are not talking about black-lists, since the IDs used by a translator are not stable and distributable. In fact, given the privacy issues and non-permanent ID behavior that is recommended by the draft, non of the IDs can be used as any form of black-list that is shareable and has significant lifespan. Solving the persistent IP v6 spammer identification problem seems to be a VERY different problem from solving the transient subscriber identification to deal with short-term misbehavior and / or collision. Yours, Joel On 8/21/2012 10:54 AM, mohamed.boucadair@orange.com wrote: > Re-, > > If /128 is used to enforce the policies then there is no issue at all. > > The point is that using /128 to black list a spammer for instance is not efficient; that's why it is likely servers will use the first 64 bits (or even /56) to install a filter....the damage can be restricted to a home premises or a large number of customers when NPTv6 is used or any other deployment context requiring the share the first 64 bits. > > Does this makes sense to you? > > Cheers, > Med > >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Envoyé : mardi 21 août 2012 15:49 >> À : BOUCADAIR Mohamed OLNC/NAD/TIP >> Cc : Internet Area >> Objet : Re: [Int-area] Nat Reveal Analysis >> >> Thank you for your prompt attention. >> I have removed the agreed items. >> I am still confused by the proposed new IPv6 text. >> The text says that if a server uses short prefixes it will apply the >> policy too coarsely. >> On the one hand, that is true even if NPT66 is not used. >> On the other, the solution is already present. Use the full 128 bits. >> This does not require any new mechanisms. >> >> Yours, >> Joel >> >> On 8/21/2012 1:35 AM, mohamed.boucadair@orange.com wrote: >>> Dear Joel, >>> >>> Thank you for the review. >>> >>> Please see inline. >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : int-area-bounces@ietf.org >>>> [mailto:int-area-bounces@ietf.org] De la part de Joel M. Halpern >>>> Envoyé : lundi 20 août 2012 22:52 >>>> À : Internet Area >>>> Objet : [Int-area] Nat Reveal Analysis >>>> >>>> My thanks to the authors for submitting a revised version of >>>> draft-ietf-intarea-nat-reveal-analysis-03. >>>> >>>> I have looked at this document, and have a few comments. >>>> First, thank you for removing the explicit recommendation. >>>> >>>> I find section 2.1 on IPv6 applicability somewhat >> confusing. The most >>>> common technique I know of for topology hiding, NPT66, does so in a >>>> fashion that does not conflate identities. As such, it is >> not obvious >>>> that there is an IPv6 problem. It seems that this short >>>> section should >>>> either be removed or elaborated. >>> >>> Med: I updated the text as follows: >>> >>> OLD: >>> >>> Some of the issues mentioned in Section 2 are >> independent of IPv4 vs. >>> IPv6. Even in IPv6, address sharing can be used for a variety of >>> reasons (e.g., to hide network topology, to defeat hosts from >>> offering network services directly, etc.). >>> >>> NEW: >>> >>> Some of the issues mentioned in Section 2 are >> independent of IPv4 vs. >>> IPv6. Even in IPv6, address sharing can be used for a variety of >>> reasons (e.g., to hide network topology, to defeat hosts from >>> offering network services directly, etc.). >>> >>> An example is an NPTv6 translator [RFC6296] using a prefix longer >>> than /56 for its algorithmic address mapping. In such >> context, if a >>> remote server enforces policies (e.g., blacklist a >> misbehaving user) >>> based on the first 48 or 56 bits, several IPv6 hosts will be >>> impacted. >>> >>> Is the new text better? >> From mohamed.boucadair@orange.com Tue Aug 21 08:13:40 2012 Return-Path: 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 6F28321F86B8 for ; Tue, 21 Aug 2012 08:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucIXcGrL-Mcn for ; Tue, 21 Aug 2012 08:13:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id BE9CE21F86B1 for ; Tue, 21 Aug 2012 08:13:38 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id F39D0264C6F; Tue, 21 Aug 2012 17:13:37 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D99E035C045; Tue, 21 Aug 2012 17:13:37 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Tue, 21 Aug 2012 17:13:17 +0200 From: To: "Joel M. Halpern" Date: Tue, 21 Aug 2012 17:13:15 +0200 Thread-Topic: [Int-area] Nat Reveal Analysis Thread-Index: Ac1/rxgPVbU8aMsoTKGQIBmBWMQLCgAADbSg Message-ID: <94C682931C08B048B7A8645303FDC9F36E52298B59@PUEXCB1B.nanterre.francetelecom.fr> References: <5032A37E.7040604@joelhalpern.com> <94C682931C08B048B7A8645303FDC9F36E52298959@PUEXCB1B.nanterre.francetelecom.fr> <503391CE.2080908@joelhalpern.com> <94C682931C08B048B7A8645303FDC9F36E52298B41@PUEXCB1B.nanterre.francetelecom.fr> <5033A4F0.7030908@joelhalpern.com> In-Reply-To: <5033A4F0.7030908@joelhalpern.com> 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.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.21.142415 Cc: Internet Area Subject: Re: [Int-area] Nat Reveal Analysis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:13:40 -0000 Re-, I think this needs to be discussed in a dedicated paper. I will remove that= text so that the nat reveal draft be IPv4-specific.=20 Cheers, Med=20 >-----Message d'origine----- >De : Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 >Envoy=E9 : mardi 21 ao=FBt 2012 17:11 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Internet Area >Objet : Re: [Int-area] Nat Reveal Analysis > >I am sorry, but I am not following. > >Yes, 128 bits is long, and a large set. >But if the spammers are using lots of different identities, then the=20 >server has to find some way to keep track of them. If the set is too=20 >small, then different users will collide. >There are well-known techniques for looking up an ID in a large set of=20 >IDs. We are not talking about black-lists, since the IDs used by a=20 >translator are not stable and distributable. > >In fact, given the privacy issues and non-permanent ID=20 >behavior that is=20 >recommended by the draft, non of the IDs can be used as any form of=20 >black-list that is shareable and has significant lifespan. > >Solving the persistent IP v6 spammer identification problem=20 >seems to be=20 >a VERY different problem from solving the transient subscriber=20 >identification to deal with short-term misbehavior and / or collision. > >Yours, >Joel > >On 8/21/2012 10:54 AM, mohamed.boucadair@orange.com wrote: >> Re-, >> >> If /128 is used to enforce the policies then there is no=20 >issue at all. >> >> The point is that using /128 to black list a spammer for=20 >instance is not efficient; that's why it is likely servers=20 >will use the first 64 bits (or even /56) to install a=20 >filter....the damage can be restricted to a home premises or a=20 >large number of customers when NPTv6 is used or any other=20 >deployment context requiring the share the first 64 bits. >> >> Does this makes sense to you? >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Envoy=E9 : mardi 21 ao=FBt 2012 15:49 >>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>> Cc : Internet Area >>> Objet : Re: [Int-area] Nat Reveal Analysis >>> >>> Thank you for your prompt attention. >>> I have removed the agreed items. >>> I am still confused by the proposed new IPv6 text. >>> The text says that if a server uses short prefixes it will apply the >>> policy too coarsely. >>> On the one hand, that is true even if NPT66 is not used. >>> On the other, the solution is already present. Use the=20 >full 128 bits. >>> This does not require any new mechanisms. >>> >>> Yours, >>> Joel >>> >>> On 8/21/2012 1:35 AM, mohamed.boucadair@orange.com wrote: >>>> Dear Joel, >>>> >>>> Thank you for the review. >>>> >>>> Please see inline. >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : int-area-bounces@ietf.org >>>>> [mailto:int-area-bounces@ietf.org] De la part de Joel M. Halpern >>>>> Envoy=E9 : lundi 20 ao=FBt 2012 22:52 >>>>> =C0 : Internet Area >>>>> Objet : [Int-area] Nat Reveal Analysis >>>>> >>>>> My thanks to the authors for submitting a revised version of >>>>> draft-ietf-intarea-nat-reveal-analysis-03. >>>>> >>>>> I have looked at this document, and have a few comments. >>>>> First, thank you for removing the explicit recommendation. >>>>> >>>>> I find section 2.1 on IPv6 applicability somewhat >>> confusing. The most >>>>> common technique I know of for topology hiding, NPT66,=20 >does so in a >>>>> fashion that does not conflate identities. As such, it is >>> not obvious >>>>> that there is an IPv6 problem. It seems that this short >>>>> section should >>>>> either be removed or elaborated. >>>> >>>> Med: I updated the text as follows: >>>> >>>> OLD: >>>> >>>> Some of the issues mentioned in Section 2 are >>> independent of IPv4 vs. >>>> IPv6. Even in IPv6, address sharing can be used for=20 >a variety of >>>> reasons (e.g., to hide network topology, to defeat hosts from >>>> offering network services directly, etc.). >>>> >>>> NEW: >>>> >>>> Some of the issues mentioned in Section 2 are >>> independent of IPv4 vs. >>>> IPv6. Even in IPv6, address sharing can be used for=20 >a variety of >>>> reasons (e.g., to hide network topology, to defeat hosts from >>>> offering network services directly, etc.). >>>> >>>> An example is an NPTv6 translator [RFC6296] using a=20 >prefix longer >>>> than /56 for its algorithmic address mapping. In such >>> context, if a >>>> remote server enforces policies (e.g., blacklist a >>> misbehaving user) >>>> based on the first 48 or 56 bits, several IPv6 hosts will be >>>> impacted. >>>> >>>> Is the new text better? >>> >= From internet-drafts@ietf.org Tue Aug 21 08:18:54 2012 Return-Path: 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 6C12E21F8773; Tue, 21 Aug 2012 08:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmhRj3Ov8f2j; Tue, 21 Aug 2012 08:18:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D969521F8775; Tue, 21 Aug 2012 08:18:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120821151853.1746.67428.idtracker@ietfa.amsl.com> Date: Tue, 21 Aug 2012 08:18:53 -0700 Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:18:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Area Working Group Working Group= of the IETF. Title : Analysis of Solution Candidates to Reveal a Host Identif= ier (HOST_ID) in Shared Address Deployments Author(s) : Mohamed Boucadair Joe Touch Pierre Levis Reinaldo Penno Filename : draft-ietf-intarea-nat-reveal-analysis-04.txt Pages : 22 Date : 2012-08-21 Abstract: This document analyzes a set of solution candidates to mitigate some of the issues encountered when address sharing is used. In particular, this document focuses on means to reveal a host identifier (HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier must be unique to each host under the same shared IP address. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-nat-reveal-analysis-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Tue Aug 21 08:22:50 2012 Return-Path: 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 7D79C21F84C4 for ; Tue, 21 Aug 2012 08:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.055 X-Spam-Level: X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZKap-8rLntP for ; Tue, 21 Aug 2012 08:22:49 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2428F21F844B for ; Tue, 21 Aug 2012 08:22:49 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 83A82264CEC for ; Tue, 21 Aug 2012 17:22:36 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 62F98238048 for ; Tue, 21 Aug 2012 17:22:36 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Tue, 21 Aug 2012 17:22:15 +0200 From: To: "int-area@ietf.org" Date: Tue, 21 Aug 2012 17:22:13 +0200 Thread-Topic: I-D Action: draft-ietf-intarea-nat-reveal-analysis-04.txt Thread-Index: Ac1/sEj8ZW6xdtVeSuCpDKNtHw/pjgAAEfxw Message-ID: <94C682931C08B048B7A8645303FDC9F36E52298B68@PUEXCB1B.nanterre.francetelecom.fr> References: <20120821151853.1746.67428.idtracker@ietfa.amsl.com> In-Reply-To: <20120821151853.1746.67428.idtracker@ietfa.amsl.com> 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.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.21.150322 Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 15:22:50 -0000 Re-, This version integrates the comments from J. Halpern. Many thanks to Joel f= or the review.=20 A diff is provided below to see the changes. Cheers, Med >-----Message d'origine----- >De : i-d-announce-bounces@ietf.org=20 >[mailto:i-d-announce-bounces@ietf.org] De la part de=20 >internet-drafts@ietf.org >Envoy=E9 : mardi 21 ao=FBt 2012 17:19 >=C0 : i-d-announce@ietf.org >Cc : int-area@ietf.org >Objet : I-D Action: draft-ietf-intarea-nat-reveal-analysis-04.txt > > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. > This draft is a work item of the Internet Area Working Group=20 >Working Group of the IETF. > > Title : Analysis of Solution Candidates to=20 >Reveal a Host Identifier (HOST_ID) in Shared Address Deployments > Author(s) : Mohamed Boucadair > Joe Touch > Pierre Levis > Reinaldo Penno > Filename : draft-ietf-intarea-nat-reveal-analysis-04.txt > Pages : 22 > Date : 2012-08-21 > >Abstract: > This document analyzes a set of solution candidates to mitigate some > of the issues encountered when address sharing is used. In > particular, this document focuses on means to reveal a host > identifier (HOST_ID) when a Carrier Grade NAT (CGN) or application > proxies are involved in the path. This host identifier must be > unique to each host under the same shared IP address. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-04 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-nat-reveal- >analysis-04 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >= From jmh@joelhalpern.com Tue Aug 21 09:05:35 2012 Return-Path: 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 3B9C421F86D4 for ; Tue, 21 Aug 2012 09:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03CAlZbLTGQC for ; Tue, 21 Aug 2012 09:05:34 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id BCA2F21F866D for ; Tue, 21 Aug 2012 09:05:34 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id D865F55815A for ; Tue, 21 Aug 2012 09:05:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 38E891C04AC; Tue, 21 Aug 2012 09:05:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-71-161-50-78.clppva.btas.verizon.net [71.161.50.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 2197E1C006F; Tue, 21 Aug 2012 09:05:30 -0700 (PDT) Message-ID: <5033B1C8.2020901@joelhalpern.com> Date: Tue, 21 Aug 2012 12:05:28 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <20120821151853.1746.67428.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36E52298B68@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E52298B68@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:05:35 -0000 Thank you Med. These changes resolve all of my concerns. Yours, Joel On 8/21/2012 11:22 AM, mohamed.boucadair@orange.com wrote: > Re-, > > This version integrates the comments from J. Halpern. Many thanks to Joel for the review. > > A diff is provided below to see the changes. > > > Cheers, > Med > >> -----Message d'origine----- >> De : i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] De la part de >> internet-drafts@ietf.org >> Envoyé : mardi 21 août 2012 17:19 >> À : i-d-announce@ietf.org >> Cc : int-area@ietf.org >> Objet : I-D Action: draft-ietf-intarea-nat-reveal-analysis-04.txt >> >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> This draft is a work item of the Internet Area Working Group >> Working Group of the IETF. >> >> Title : Analysis of Solution Candidates to >> Reveal a Host Identifier (HOST_ID) in Shared Address Deployments >> Author(s) : Mohamed Boucadair >> Joe Touch >> Pierre Levis >> Reinaldo Penno >> Filename : draft-ietf-intarea-nat-reveal-analysis-04.txt >> Pages : 22 >> Date : 2012-08-21 >> >> Abstract: >> This document analyzes a set of solution candidates to mitigate some >> of the issues encountered when address sharing is used. In >> particular, this document focuses on means to reveal a host >> identifier (HOST_ID) when a Carrier Grade NAT (CGN) or application >> proxies are involved in the path. This host identifier must be >> unique to each host under the same shared IP address. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-04 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-nat-reveal- >> analysis-04 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >