From nobody Wed Jun 4 21:21:14 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162991A0062 for ; Wed, 4 Jun 2014 21:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsmwyaqgdOBb for ; Wed, 4 Jun 2014 21:21:11 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B061A002D for ; Wed, 4 Jun 2014 21:21:11 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-72-538f9faf0001 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 7B.22.27529.FAF9F835; Thu, 5 Jun 2014 00:37:36 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 00:20:57 -0400 From: Suresh Krishnan To: Internet Area Thread-Topic: Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 Thread-Index: Ac+AdUkItwXlXKGCQeuKFKJeAHvWjg== Date: Thu, 5 Jun 2014 04:20:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_E87B771635882B4BA20096B589152EF628724B2Ceusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyuXSPt+6G+f3BBi/3sFncmHWTxeLdgalM DkweS5b8ZPJYer2NNYApissmJTUnsyy1SN8ugSvjxvV7zAU/VCvevOtkbGBsUuxi5OSQEDCR 2PH2DguELSZx4d56ti5GLg4hgaOMEo0NvUwQzjJGidcvD4JVsQF1bNj5mQnEFhFQlXi99SIb iM0sYCfRP2MRmC0sECIxf9cSdoiaSInTb35B2XoSB59dBbNZBFQk1t5fzwxi8wr4Snz53gsW ZwS64vupNUwQM8Ulbj2ZzwRxnYDEkj3nmSFsUYmXj/+xQthKEnNeX2OGqM+X+DBrCSvETEGJ kzOfsExgFJ6FZNQsJGWzkJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYwcpcWpZbnp RgabGIFxckyCTXcH456XlocYBTgYlXh4E9T6g4VYE8uKK3MPMUpzsCiJ82rfrAoWEkhPLEnN Tk0tSC2KLyrNSS0+xMjEwSnVwFgw79C3E/vf+4iuP2WtGfPoQPqOg1/+2R2bvNeUxWHN4/rt IncTlYU0l6zoStH9mKVpuzT6/vkt2pPWRHcqSxmn9h6sffuKce7PowIVbkG6p28rNrY2M551 73tQVdXn+fdo9KUX6/bbnIn7ZRAeW3F8Bk/R/9blb5yl9zes2vGkU2iHrwrbgulKLMUZiYZa zEXFiQD3MqM1dAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/RV-Exsp8Jp21_mURevA1-g5tgLA Subject: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 04:21:13 -0000 --_000_E87B771635882B4BA20096B589152EF628724B2Ceusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This draft was originally intended to be published as an AD sponsored su= bmission from the OPS area, but the authors have expressed their interest t= o continue this work in the intarea wg given that RFC6269 and RFC6967 origi= nated here. The draft has been updated to address the issues brought up dur= ing earlier discussions on the wg mailing list and the latest version of th= e draft is available at http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenario= s-04 This call is being initiated to determine whether there is WG consensus tow= ards adoption of draft-boucadair-intarea-host-identifier-scenarios-04 as an= intarea WG draft. Please state whether or not you're in favor of the adopt= ion by replying to this email. If you are not in favor, please also state y= our objections in your response. This adoption call will complete on 2014-0= 6-19. Regards Suresh & Juan Carlos --_000_E87B771635882B4BA20096B589152EF628724B2Ceusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

   This draft was originally intended t= o be published as an AD sponsored submission from the OPS area, but the aut= hors have expressed their interest to continue this work in the intarea wg = given that RFC6269 and RFC6967 originated here. The draft has been updated to address the issues brought up during earlier= discussions on the wg mailing list and the latest version of the draft is = available at

 

http://tools.ietf.org/html/draft= -boucadair-intarea-host-identifier-scenarios-04

This call is being initiated to determine whether= there is WG consensus towards adoption of draft-boucadair-intarea-host-ide= ntifier-scenarios-04 as an intarea WG draft. Please state whether or not yo= u're in favor of the adoption by replying to this email. If you are not in favor, please also state your objections = in your response. This adoption call will complete on 2014-06-19.

 

Regards

Suresh & Juan Carlos

 

--_000_E87B771635882B4BA20096B589152EF628724B2Ceusaamb107erics_-- From nobody Thu Jun 5 04:44:48 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375F31A0049 for ; Thu, 5 Jun 2014 04:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id va00e06CSdHt for ; Thu, 5 Jun 2014 04:44:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EB9C1A003A for ; Thu, 5 Jun 2014 04:44:43 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 825061902D1; Thu, 5 Jun 2014 13:44:35 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 6204338404A; Thu, 5 Jun 2014 13:44:35 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.12]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Thu, 5 Jun 2014 13:44:35 +0200 From: To: Suresh Krishnan , Internet Area Thread-Topic: Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 Thread-Index: Ac+AdUkItwXlXKGCQeuKFKJeAHvWjgAPZSrg Date: Thu, 5 Jun 2014 11:44:34 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300139E7@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300139E7OPEXCLILM23corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.4.22118 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/WiLsSyFRro5qAH_4rMyRXul8gkA Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 11:44:46 -0000 --_000_787AE7BB302AE849A7480A190F8B93300139E7OPEXCLILM23corpor_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Suresh, Thank you for initiating this call. FWIW, the latest version is -05 not -04: http://tools.ietf.org/html/draft-b= oucadair-intarea-host-identifier-scenarios-05. Unsurprisingly, I'm supportive to see this work adopted in intarea as a com= panion effort to RFC6269 and RFC6967. Cheers, Med De : Int-area [mailto:int-area-bounces@ietf.org] De la part de Suresh Krish= nan Envoy=E9 : jeudi 5 juin 2014 06:21 =C0 : Internet Area Objet : [Int-area] Call for adoption of draft-boucadair-intarea-host-identi= fier-scenarios-04 Hi all, This draft was originally intended to be published as an AD sponsored su= bmission from the OPS area, but the authors have expressed their interest t= o continue this work in the intarea wg given that RFC6269 and RFC6967 origi= nated here. The draft has been updated to address the issues brought up dur= ing earlier discussions on the wg mailing list and the latest version of th= e draft is available at http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenario= s-04 This call is being initiated to determine whether there is WG consensus tow= ards adoption of draft-boucadair-intarea-host-identifier-scenarios-04 as an= intarea WG draft. Please state whether or not you're in favor of the adopt= ion by replying to this email. If you are not in favor, please also state y= our objections in your response. This adoption call will complete on 2014-0= 6-19. Regards Suresh & Juan Carlos --_000_787AE7BB302AE849A7480A190F8B93300139E7OPEXCLILM23corpor_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Suresh,

 

Thank you for initiating this call.

 

FWIW, the latest version is -05 not -04: http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenario= s-05.

 

Unsurprisingly, I’m supportive to see = this work adopted in intarea as a companion effort to RFC6269 and RFC6967.<= o:p>

 

Cheers,

Med

 

De : Int-area [mailto:int-area-bounces@ietf.org] De la part de Suresh Krishnan
Envoy=E9 : jeudi 5 juin 2014 06:21
=C0 : Internet Area
Objet : [Int-area] Call for adoption of draft-boucadair-intarea= -host-identifier-scenarios-04

 

Hi all,

   This draft was = originally intended to be published as an AD sponsored submission from the = OPS area, but the authors have expressed their interest to continue this wo= rk in the intarea wg given that RFC6269 and RFC6967 originated here. The draft has been updated to address the issues brought = up during earlier discussions on the wg mailing list and the latest version= of the draft is available at

 

http://tool= s.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04

 

This call is being initiated= to determine whether there is WG consensus towards adoption of draft-bouca= dair-intarea-host-identifier-scenarios-04 as an intarea WG draft. Please st= ate whether or not you're in favor of the adoption by replying to this email. If you are not in favor, please al= so state your objections in your response. This adoption call will complete= on 2014-06-19.

 

Regards

Suresh & Juan Carlos

 

--_000_787AE7BB302AE849A7480A190F8B93300139E7OPEXCLILM23corpor_-- From nobody Thu Jun 5 05:07:05 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACDC1A0074 for ; Thu, 5 Jun 2014 05:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.15 X-Spam-Level: X-Spam-Status: No, score=-15.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmjxrofDSCNu for ; Thu, 5 Jun 2014 05:07:00 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53CA51A0071 for ; Thu, 5 Jun 2014 05:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6763; q=dns/txt; s=iport; t=1401970014; x=1403179614; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=TMukXcEbF4wv0naNGFDyodWhiCdRh+VuhbJJPSMvAns=; b=UAEcpc6TyFQt3YqLL1Oy7mkUdqUf87MBoy07XqfV3JEEf4Fj1LEJltPS UY2PaGKeYZxlaXk+/T1RK9tJm8JMbzUeEpmovhf1q3IE/zNS8p20AMH/G AnDnzJuDXUT5C1ceqI//mt0gaDuLna3Mzx0VxKnG7dVfPp9Bc3ffADwAW M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAHAERckFOtJA2K/2dsb2JhbABZgkJFUliFTLQ3hw2BbgGBDRZ0giUBAQEEHRBBGwIBCBEEAQELHQcyFAkIAQEEARIIiDoN0xwXjXARAR83AYMrgRUEm1KReoM4gXY5 X-IronPort-AV: E=Sophos; i="4.98,980,1392163200"; d="scan'208,217"; a="50404363" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP; 05 Jun 2014 12:06:53 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s55C6rsA020260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jun 2014 12:06:53 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Thu, 5 Jun 2014 07:06:53 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Suresh Krishnan , Internet Area Thread-Topic: Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 Thread-Index: Ac+AdUkItwXlXKGCQeuKFKJeAHvWjgAIes6w Date: Thu, 5 Jun 2014 12:06:52 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A282C8A3D@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.67.6] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A282C8A3Dxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/EshBoCXDhjjTPryMCoK6_knPiEU Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 12:07:02 -0000 --_000_913383AAA69FF945B8F946018B75898A282C8A3Dxmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support adoption of this draft. -Tiru From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Suresh Krish= nan Sent: Thursday, June 05, 2014 9:51 AM To: Internet Area Subject: [Int-area] Call for adoption of draft-boucadair-intarea-host-ident= ifier-scenarios-04 Hi all, This draft was originally intended to be published as an AD sponsored su= bmission from the OPS area, but the authors have expressed their interest t= o continue this work in the intarea wg given that RFC6269 and RFC6967 origi= nated here. The draft has been updated to address the issues brought up dur= ing earlier discussions on the wg mailing list and the latest version of th= e draft is available at http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenario= s-04 This call is being initiated to determine whether there is WG consensus tow= ards adoption of draft-boucadair-intarea-host-identifier-scenarios-04 as an= intarea WG draft. Please state whether or not you're in favor of the adopt= ion by replying to this email. If you are not in favor, please also state y= our objections in your response. This adoption call will complete on 2014-0= 6-19. Regards Suresh & Juan Carlos --_000_913383AAA69FF945B8F946018B75898A282C8A3Dxmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support adoption of this draft.

 

-Tiru

 

From: Int-area= [mailto:int-area-bounces@ietf.org] On Behalf Of Suresh Krishnan
Sent: Thursday, June 05, 2014 9:51 AM
To: Internet Area
Subject: [Int-area] Call for adoption of draft-boucadair-intarea-hos= t-identifier-scenarios-04

 

Hi all,

   This draft was = originally intended to be published as an AD sponsored submission from the = OPS area, but the authors have expressed their interest to continue this wo= rk in the intarea wg given that RFC6269 and RFC6967 originated here. The draft has been updated to address the issues brought = up during earlier discussions on the wg mailing list and the latest version= of the draft is available at

 

http://tool= s.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04

 

This call is being initiated= to determine whether there is WG consensus towards adoption of draft-bouca= dair-intarea-host-identifier-scenarios-04 as an intarea WG draft. Please st= ate whether or not you're in favor of the adoption by replying to this email. If you are not in favor, please al= so state your objections in your response. This adoption call will complete= on 2014-06-19.

 

Regards

Suresh & Juan Carlos

 

--_000_913383AAA69FF945B8F946018B75898A282C8A3Dxmbrcdx10ciscoc_-- From nobody Thu Jun 5 05:11:32 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C9E1A0077 for ; Thu, 5 Jun 2014 05:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-3z10sY2hjS for ; Thu, 5 Jun 2014 05:11:26 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD5F11A0079 for ; Thu, 5 Jun 2014 05:11:25 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id D5BC7190278; Thu, 5 Jun 2014 14:11:16 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id B50DC38404A; Thu, 5 Jun 2014 14:11:16 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.12]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0181.006; Thu, 5 Jun 2014 14:11:16 +0200 From: To: "Tirumaleswar Reddy (tireddy)" , Suresh Krishnan , Internet Area Thread-Topic: Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 Thread-Index: Ac+AdUkItwXlXKGCQeuKFKJeAHvWjgAIes6wAAf9nGA= Date: Thu, 5 Jun 2014 12:11:16 +0000 Message-ID: <12607_1401970276_53905E64_12607_10726_1_88132E969123D14D9BD844E1CD516EDE013E6C42@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <913383AAA69FF945B8F946018B75898A282C8A3D@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A282C8A3D@xmb-rcd-x10.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_88132E969123D14D9BD844E1CD516EDE013E6C42OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.5.35719 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/mO14JDD2w7XJUBt0zEzNzJrnupI Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 12:11:28 -0000 --_000_88132E969123D14D9BD844E1CD516EDE013E6C42OPEXCLILM23corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WG, I also support the adoption of draft-boucadair-intarea-host-identifier-scen= arios-04 as an intarea WG document. Cheers, Christian. De : Int-area [mailto:int-area-bounces@ietf.org] De la part de Tirumaleswar= Reddy (tireddy) Envoy=E9 : jeudi 5 juin 2014 14:07 =C0 : Suresh Krishnan; Internet Area Objet : Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-id= entifier-scenarios-04 I support adoption of this draft. -Tiru From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Suresh Krish= nan Sent: Thursday, June 05, 2014 9:51 AM To: Internet Area Subject: [Int-area] Call for adoption of draft-boucadair-intarea-host-ident= ifier-scenarios-04 Hi all, This draft was originally intended to be published as an AD sponsored su= bmission from the OPS area, but the authors have expressed their interest t= o continue this work in the intarea wg given that RFC6269 and RFC6967 origi= nated here. The draft has been updated to address the issues brought up dur= ing earlier discussions on the wg mailing list and the latest version of th= e draft is available at http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenario= s-04 This call is being initiated to determine whether there is WG consensus tow= ards adoption of draft-boucadair-intarea-host-identifier-scenarios-04 as an= intarea WG draft. Please state whether or not you're in favor of the adopt= ion by replying to this email. If you are not in favor, please also state y= our objections in your response. This adoption call will complete on 2014-0= 6-19. Regards Suresh & Juan Carlos ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_88132E969123D14D9BD844E1CD516EDE013E6C42OPEXCLILM23corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

WG,

 

I also support the adoption of draft-boucada= ir-intarea-host-identifier-scenarios-04 as an intarea WG document.

 

Cheers,

 

Christian.

 

De : Int-area [mailto:int-area-= bounces@ietf.org] De la part de Tirumaleswar Reddy (tireddy)
Envoy=E9 : jeudi 5 juin 2014 14:07
=C0 : Suresh Krishnan; Internet Area
Objet : Re: [Int-area] Call for adoption of draft-boucadair-int= area-host-identifier-scenarios-04

 

I support adoption of this dr= aft.

 

-Tiru

 

From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Suresh Krishnan
Sent: Thursday, June 05, 2014 9:51 AM
To: Internet Area
Subject: [Int-area] Call for adoption of draft-boucadair-intarea-hos= t-identifier-scenarios-04

 

Hi all,

   This draft was originally intended to be published as an AD s= ponsored submission from the OPS area, but the authors have expressed their= interest to continue this work in the intarea wg given that RFC6269 and RFC6967 originated here. The draft has been updated= to address the issues brought up during earlier discussions on the wg mail= ing list and the latest version of the draft is available at

 

http://tools.ietf.org/html/draft-boucadair-intarea-host-i= dentifier-scenarios-04

 

This call is being initiated to determine whether there is WG consensus to= wards adoption of draft-boucadair-intarea-host-identifier-scenarios-04 as a= n intarea WG draft. Please state whether or not you're in favor of the adoption by replying to this email. If you a= re not in favor, please also state your objections in your response. This a= doption call will complete on 2014-06-19.

 

Regards

Suresh & Juan Carlos

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_88132E969123D14D9BD844E1CD516EDE013E6C42OPEXCLILM23corp_-- From nobody Thu Jun 5 05:48:33 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1681A008D; Thu, 5 Jun 2014 05:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEoc_are9Xjj; Thu, 5 Jun 2014 05:48:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B89141A008C; Thu, 5 Jun 2014 05:48:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B75BABF88; Thu, 5 Jun 2014 13:48:19 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7N3dGWLEVEWH; Thu, 5 Jun 2014 13:48:18 +0100 (IST) Received: from [10.87.48.12] (unknown [86.44.75.78]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CA24FBF38; Thu, 5 Jun 2014 13:48:17 +0100 (IST) Message-ID: <53906711.5070406@cs.tcd.ie> Date: Thu, 05 Jun 2014 13:48:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Hannes Tschofenig , int-area@ietf.org References: <539016BE.3070008@gmx.net> In-Reply-To: <539016BE.3070008@gmx.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/GMUflPzwgXzbmQlf_fasYEcgMjk Cc: "ietf-privacy@ietf.org" Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 12:48:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hiya, On 05/06/14 08:05, Hannes Tschofenig wrote: > If you want to review a document with privacy implications then > have a look at the NAT reveal / host identifier work (with > draft-boucadair-intarea-host-identifier-scenarios-04 currently in > a call for adoption). > > I had raised my concerns several times now on the mailing list and > during the meetings. I share those concerns. And adopting this without any consideration of BCP188 would fly in the face of a very recent, very thoroughly discussed, IETF consensus. For something like this, the onus ought IMO be on the proposers to have done that work before asking for adoption. Based on the draft, they clearly have not done that. We could also ask to add more use-cases: use-case#12: spy on everyone more easily, TEMPORA++ use-case#13: sell data that's even more fine-grained than clickstreams use-case#14: expose your n/w internals to help on path attackers use-case#15: track hosts from which people emit "dangerous" utterances use-case#16: block hosts from which people emit "dangerous" utterances use-case#17: charge me more for using two of my computers in my house The set of use-cases presented very much contradicts the explicit claim in the draft that no position is being taken as to the merits of this. IMO that argues strongly to not adopt this. One could also comment on the requirements that seem to require new laws of physics or are otherwise pretty odd: REQ#1: seems to require knowing from packets passing by that a device is a "trusted device" (and REQ#15 says that can be done with 16 bits;-) Hmm... are those qubits maybe? REQ#5: *all* IP packets MUST have a HOST_ID... but presumably without a flag day. Hmm... REQ#6: says this is a transport thing. Eh, why ask INT-AREA? REQ#10+REQ#11: MUST be intradomain only but MUST also be inter domain. Hmm... REQ#18: receiver MUST "enforce policies like QoS." Huh? Such a frankly bogus list of "requirements" also means that this is not something that ought be adopted in the IETF. I also think that this proposal has previously been proposed in other ways and not adopted. Such forum-shopping is yet another reason to not adopt it, and certainly not as an area wg thing without any broader IETF-wide consideration. (As an aside: having to play whack-a-mole with such repeat proposals is one of the downsides of area wgs. Not sure if anything can be done about that though.) In summary: ignoring BCP188, the selection-bias in use cases, the badly thought out "requirements" and forum shopping are all independently sufficient reasons to not adopt this. And of course that doesn't include all the other issues with potential solutions listed in RFC6967 (the reference to which is oddly to the I-D and not the RFC). My conclusion: this one ought go to /dev/null same as the previous attempts to shop the same thing into other parts of the IETF. S > > Ciao Hannes > > > -------- Original Message -------- Subject: [Int-area] Call for > adoption of draft-boucadair-intarea-host-identifier-scenarios-04 > Date: Thu, 5 Jun 2014 04:20:56 +0000 From: Suresh Krishnan > To: Internet Area > > > > > Hi all, > > This draft was originally intended to be published as an AD > sponsored submission from the OPS area, but the authors have > expressed their interest to continue this work in the intarea wg > given that RFC6269 and RFC6967 originated here. The draft has been > updated to address the issues brought up during earlier > discussions on the wg mailing list and the latest version of the > draft is available at > > > > http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 > > > This call is being initiated to determine whether there is WG > consensus towards adoption of > draft-boucadair-intarea-host-identifier-scenarios-04 as an intarea > WG draft. Please state whether or not you're in favor of the > adoption by replying to this email. If you are not in favor, please > also state your objections in your response. This adoption call > will complete on 2014-06-19. > > > > Regards > > Suresh & Juan Carlos > > > > > > > > > _______________________________________________ ietf-privacy > mailing list ietf-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-privacy > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTkGcRAAoJEC88hzaAX42iFYYIAIlJHJE1BNetIdjhDTqlTfsX w+fFwSpCfi1LzZzxYR+ZgnL96ed8QPJ/YJEb4S1jZ0u2g1+DqMbSMsuQ6aW78+WM iHfyIqO8m7Ahkk1J++/5bK3N0fbqhMjWmqs1cCa7Gg/o9RScZQiMJQef8Iju5gVN 3dnd/7riV9THntV7DQdwGC0SXp9Wfwn2i3oAqxYVpEixCxxGbQBRPIiXBcaLBP4s lr86tLPCPdXB2K4uPsuofVxL/uGBkahF6DAGjq3URcUEVi/J82XL+eB/3bLQU5XG 2Mr0LMu7v4XQ+92zCjm7UmWmiL1fcQ+M0g+5nESSP8bO3sNlFlN33+jzsEGTBRM= =TF0g -----END PGP SIGNATURE----- From nobody Thu Jun 5 06:12:07 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6D61A008D; Thu, 5 Jun 2014 06:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xl09Ux9Ze_Tb; Thu, 5 Jun 2014 06:11:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C911A008C; Thu, 5 Jun 2014 06:11:57 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 676F519039C; Thu, 5 Jun 2014 15:11:49 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 4816A384061; Thu, 5 Jun 2014 15:11:49 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.12]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Thu, 5 Jun 2014 15:11:49 +0200 From: To: Stephen Farrell , Hannes Tschofenig , "int-area@ietf.org" Thread-Topic: [ietf-privacy] NAT Reveal / Host Identifiers Thread-Index: AQHPgLx0d+zesvLV90CTjyqp9hszQZtiegWw Date: Thu, 5 Jun 2014 13:11:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330013CAF@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> In-Reply-To: <53906711.5070406@cs.tcd.ie> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.5.35719 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/BbT8SlAYcHCnJH-EVYGY8zGVYDk Cc: "ietf-privacy@ietf.org" Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 13:12:04 -0000 Hi Stephen, You referred in your message to an old version. The latest version of the d= ocument does not include any requirement, it is only an inventory of use ca= ses when problems are encountered. The latest version is available at: http= ://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05= . Some of these use cases are restricted to a single administrative domain wh= ile others span multiple domain. Privacy concerns are really important; the= se are discussed in RFC6967. The use cases are not theoretical ones, but are those where complications a= rise. Explicitly calling out security risks (including privacy ones) will b= enefit to this work. It is really helpful to understand the use cases and c= all out any potential risks rather than speculating without actual understa= nding of what the problem is. This document is the opportunity to record security and privacy concerns th= at apply to these use cases. The content of the document is not frozen. Ado= pting it as a WG document will undoubtedly enrich it and benefit from other= perspectives that those of the authors.=20 Cheers, Med >-----Message d'origine----- >De=A0: ietf-privacy [mailto:ietf-privacy-bounces@ietf.org] De la part de >Stephen Farrell >Envoy=E9=A0: jeudi 5 juin 2014 14:48 >=C0=A0: Hannes Tschofenig; int-area@ietf.org >Cc=A0: ietf-privacy@ietf.org; Zuniga, Juan Carlos >Objet=A0: Re: [ietf-privacy] NAT Reveal / Host Identifiers > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >Hiya, > >On 05/06/14 08:05, Hannes Tschofenig wrote: >> If you want to review a document with privacy implications then >> have a look at the NAT reveal / host identifier work (with >> draft-boucadair-intarea-host-identifier-scenarios-04 currently in >> a call for adoption). >> >> I had raised my concerns several times now on the mailing list and >> during the meetings. > >I share those concerns. And adopting this without any consideration >of BCP188 would fly in the face of a very recent, very thoroughly >discussed, IETF consensus. For something like this, the onus ought >IMO be on the proposers to have done that work before asking for >adoption. Based on the draft, they clearly have not done that. > >We could also ask to add more use-cases: > >use-case#12: spy on everyone more easily, TEMPORA++ >use-case#13: sell data that's even more fine-grained than clickstreams >use-case#14: expose your n/w internals to help on path attackers >use-case#15: track hosts from which people emit "dangerous" utterances >use-case#16: block hosts from which people emit "dangerous" utterances >use-case#17: charge me more for using two of my computers in my house > >The set of use-cases presented very much contradicts the explicit >claim in the draft that no position is being taken as to the merits >of this. IMO that argues strongly to not adopt this. > >One could also comment on the requirements that seem to >require new laws of physics or are otherwise pretty odd: > >REQ#1: seems to require knowing from packets passing by that >a device is a "trusted device" (and REQ#15 says that can be >done with 16 bits;-) Hmm... are those qubits maybe? > >REQ#5: *all* IP packets MUST have a HOST_ID... but presumably >without a flag day. Hmm... > >REQ#6: says this is a transport thing. Eh, why ask INT-AREA? > >REQ#10+REQ#11: MUST be intradomain only but MUST also be inter >domain. Hmm... > >REQ#18: receiver MUST "enforce policies like QoS." Huh? > >Such a frankly bogus list of "requirements" also means that >this is not something that ought be adopted in the IETF. > >I also think that this proposal has previously been proposed >in other ways and not adopted. Such forum-shopping is yet >another reason to not adopt it, and certainly not as an >area wg thing without any broader IETF-wide consideration. >(As an aside: having to play whack-a-mole with such repeat >proposals is one of the downsides of area wgs. Not sure >if anything can be done about that though.) > >In summary: ignoring BCP188, the selection-bias in use >cases, the badly thought out "requirements" and forum >shopping are all independently sufficient reasons to >not adopt this. And of course that doesn't include all >the other issues with potential solutions listed in >RFC6967 (the reference to which is oddly to the I-D and >not the RFC). > >My conclusion: this one ought go to /dev/null same as the >previous attempts to shop the same thing into other parts >of the IETF. > >S > > >> >> Ciao Hannes >> >> >> -------- Original Message -------- Subject: [Int-area] Call for >> adoption of draft-boucadair-intarea-host-identifier-scenarios-04 >> Date: Thu, 5 Jun 2014 04:20:56 +0000 From: Suresh Krishnan >> To: Internet Area >> >> >> >> >> Hi all, >> >> This draft was originally intended to be published as an AD >> sponsored submission from the OPS area, but the authors have >> expressed their interest to continue this work in the intarea wg >> given that RFC6269 and RFC6967 originated here. The draft has been >> updated to address the issues brought up during earlier >> discussions on the wg mailing list and the latest version of the >> draft is available at >> >> >> >> http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier- >scenarios-04 >> >> >> >This call is being initiated to determine whether there is WG >> consensus towards adoption of >> draft-boucadair-intarea-host-identifier-scenarios-04 as an intarea >> WG draft. Please state whether or not you're in favor of the >> adoption by replying to this email. If you are not in favor, please >> also state your objections in your response. This adoption call >> will complete on 2014-06-19. >> >> >> >> Regards >> >> Suresh & Juan Carlos >> >> >> >> >> >> >> >> >> _______________________________________________ ietf-privacy >> mailing list ietf-privacy@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-privacy >> >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1 > >iQEcBAEBAgAGBQJTkGcRAAoJEC88hzaAX42iFYYIAIlJHJE1BNetIdjhDTqlTfsX >w+fFwSpCfi1LzZzxYR+ZgnL96ed8QPJ/YJEb4S1jZ0u2g1+DqMbSMsuQ6aW78+WM >iHfyIqO8m7Ahkk1J++/5bK3N0fbqhMjWmqs1cCa7Gg/o9RScZQiMJQef8Iju5gVN >3dnd/7riV9THntV7DQdwGC0SXp9Wfwn2i3oAqxYVpEixCxxGbQBRPIiXBcaLBP4s >lr86tLPCPdXB2K4uPsuofVxL/uGBkahF6DAGjq3URcUEVi/J82XL+eB/3bLQU5XG >2Mr0LMu7v4XQ+92zCjm7UmWmiL1fcQ+M0g+5nESSP8bO3sNlFlN33+jzsEGTBRM=3D >=3DTF0g >-----END PGP SIGNATURE----- > >_______________________________________________ >ietf-privacy mailing list >ietf-privacy@ietf.org >https://www.ietf.org/mailman/listinfo/ietf-privacy From nobody Thu Jun 5 06:24:29 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF1F1A0075; Thu, 5 Jun 2014 06:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKh0lc2Ebbor; Thu, 5 Jun 2014 06:24:21 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 53E061A00C6; Thu, 5 Jun 2014 06:24:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A8814BF8B; Thu, 5 Jun 2014 14:24:14 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9jNI1DFMgvw; Thu, 5 Jun 2014 14:24:12 +0100 (IST) Received: from [10.87.48.12] (unknown [86.44.75.78]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A1B92BED0; Thu, 5 Jun 2014 14:24:12 +0100 (IST) Message-ID: <53906F7C.1090500@cs.tcd.ie> Date: Thu, 05 Jun 2014 14:24:12 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, Hannes Tschofenig , "int-area@ietf.org" References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <787AE7BB302AE849A7480A190F8B9330013CAF@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330013CAF@OPEXCLILM23.corporate.adroot.infra.ftgroup> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/sluWSZ0dcosR2I8tyPZECSP3hu0 Cc: "ietf-privacy@ietf.org" Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 13:24:24 -0000 Hi Med, On 05/06/14 14:11, mohamed.boucadair@orange.com wrote: > Hi Stephen, > > You referred in your message to an old version. That was the one for which the adoption call was issued. I guess just a typo. I looked quickly at the diff between 04 and 05 and my conclusion remains the same and most of my comment I think still apply, despite the removal of the odd requirements section. S. > The latest version of > the document does not include any requirement, it is only an > inventory of use cases when problems are encountered. The latest > version is available at: > http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05. > > Some of these use cases are restricted to a single administrative > domain while others span multiple domain. Privacy concerns are really > important; these are discussed in RFC6967. > > The use cases are not theoretical ones, but are those where > complications arise. Explicitly calling out security risks (including > privacy ones) will benefit to this work. It is really helpful to > understand the use cases and call out any potential risks rather than > speculating without actual understanding of what the problem is. > > This document is the opportunity to record security and privacy > concerns that apply to these use cases. The content of the document > is not frozen. Adopting it as a WG document will undoubtedly enrich > it and benefit from other perspectives that those of the authors. > > Cheers, Med > >> -----Message d'origine----- De : ietf-privacy >> [mailto:ietf-privacy-bounces@ietf.org] De la part de Stephen >> Farrell Envoy : jeudi 5 juin 2014 14:48 : Hannes Tschofenig; >> int-area@ietf.org Cc : ietf-privacy@ietf.org; Zuniga, Juan Carlos >> Objet : Re: [ietf-privacy] NAT Reveal / Host Identifiers >> > > Hiya, > > On 05/06/14 08:05, Hannes Tschofenig wrote: >>>> If you want to review a document with privacy implications >>>> then have a look at the NAT reveal / host identifier work >>>> (with draft-boucadair-intarea-host-identifier-scenarios-04 >>>> currently in a call for adoption). >>>> >>>> I had raised my concerns several times now on the mailing list >>>> and during the meetings. > > I share those concerns. And adopting this without any consideration > of BCP188 would fly in the face of a very recent, very thoroughly > discussed, IETF consensus. For something like this, the onus ought > IMO be on the proposers to have done that work before asking for > adoption. Based on the draft, they clearly have not done that. > > We could also ask to add more use-cases: > > use-case#12: spy on everyone more easily, TEMPORA++ use-case#13: sell > data that's even more fine-grained than clickstreams use-case#14: > expose your n/w internals to help on path attackers use-case#15: > track hosts from which people emit "dangerous" utterances > use-case#16: block hosts from which people emit "dangerous" > utterances use-case#17: charge me more for using two of my computers > in my house > > The set of use-cases presented very much contradicts the explicit > claim in the draft that no position is being taken as to the merits > of this. IMO that argues strongly to not adopt this. > > One could also comment on the requirements that seem to require new > laws of physics or are otherwise pretty odd: > > REQ#1: seems to require knowing from packets passing by that a device > is a "trusted device" (and REQ#15 says that can be done with 16 > bits;-) Hmm... are those qubits maybe? > > REQ#5: *all* IP packets MUST have a HOST_ID... but presumably without > a flag day. Hmm... > > REQ#6: says this is a transport thing. Eh, why ask INT-AREA? > > REQ#10+REQ#11: MUST be intradomain only but MUST also be inter > domain. Hmm... > > REQ#18: receiver MUST "enforce policies like QoS." Huh? > > Such a frankly bogus list of "requirements" also means that this is > not something that ought be adopted in the IETF. > > I also think that this proposal has previously been proposed in other > ways and not adopted. Such forum-shopping is yet another reason to > not adopt it, and certainly not as an area wg thing without any > broader IETF-wide consideration. (As an aside: having to play > whack-a-mole with such repeat proposals is one of the downsides of > area wgs. Not sure if anything can be done about that though.) > > In summary: ignoring BCP188, the selection-bias in use cases, the > badly thought out "requirements" and forum shopping are all > independently sufficient reasons to not adopt this. And of course > that doesn't include all the other issues with potential solutions > listed in RFC6967 (the reference to which is oddly to the I-D and not > the RFC). > > My conclusion: this one ought go to /dev/null same as the previous > attempts to shop the same thing into other parts of the IETF. > > S > > >>>> >>>> Ciao Hannes >>>> >>>> >>>> -------- Original Message -------- Subject: [Int-area] Call >>>> for adoption of >>>> draft-boucadair-intarea-host-identifier-scenarios-04 Date: >>>> Thu, 5 Jun 2014 04:20:56 +0000 From: Suresh Krishnan >>>> To: Internet Area >>>> >>>> >>>> >>>> >>>> Hi all, >>>> >>>> This draft was originally intended to be published as an AD >>>> sponsored submission from the OPS area, but the authors have >>>> expressed their interest to continue this work in the intarea >>>> wg given that RFC6269 and RFC6967 originated here. The draft >>>> has been updated to address the issues brought up during >>>> earlier discussions on the wg mailing list and the latest >>>> version of the draft is available at >>>> >>>> >>>> >>>> http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier- > >>>> scenarios-04 >>>> >>>> >>>> > This call is being initiated to determine whether there is WG >>>> consensus towards adoption of >>>> draft-boucadair-intarea-host-identifier-scenarios-04 as an >>>> intarea WG draft. Please state whether or not you're in favor >>>> of the adoption by replying to this email. If you are not in >>>> favor, please also state your objections in your response. This >>>> adoption call will complete on 2014-06-19. >>>> >>>> >>>> >>>> Regards >>>> >>>> Suresh & Juan Carlos >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ ietf-privacy >>>> mailing list ietf-privacy@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf-privacy >>>> >> >> _______________________________________________ ietf-privacy >> mailing list ietf-privacy@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-privacy > > From nobody Thu Jun 5 06:41:12 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245851A0115; Thu, 5 Jun 2014 06:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YH710-S_H7gq; Thu, 5 Jun 2014 06:41:06 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B8A1A007C; Thu, 5 Jun 2014 06:41:05 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 37D9222C2E0; Thu, 5 Jun 2014 15:40:58 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id BABDA23806E; Thu, 5 Jun 2014 15:40:57 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.12]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 5 Jun 2014 15:40:57 +0200 From: To: Stephen Farrell , Hannes Tschofenig , "int-area@ietf.org" Thread-Topic: [ietf-privacy] NAT Reveal / Host Identifiers Thread-Index: AQHPgMF2EOMu+YSq0UOrm+hs+i74mJtigfeg Date: Thu, 5 Jun 2014 13:40:57 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330013D4E@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <787AE7BB302AE849A7480A190F8B9330013CAF@OPEXCLILM23.corporate.adroot.infra.ftgroup> <53906F7C.1090500@cs.tcd.ie> In-Reply-To: <53906F7C.1090500@cs.tcd.ie> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.4.92121 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/nrT53Gl-hrYz6mn78nVYeAxcyxA Cc: "ietf-privacy@ietf.org" Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 13:41:11 -0000 Re-, I have two comments: (1)=20 If one missed the following sentences in -04 "Below is listed as set of req= uirements to be used to characterize each use case (discussed in Section 3):" and "Once this list is stabiliz= ed, each use case will be checked against these requirements.", then the requirements list can be seen as odd. I a= gree the wording is not so that clear. The initial intent was to identify t= he ones from the list that apply for each use case. That effort was abandon= ed in -05 to focus on the description of the use cases where problems are e= ncountered. (2) Privacy concerns are not ignored. A section is present in the draft to reca= ll some privacy-related issues: http://tools.ietf.org/html/draft-boucadair-= intarea-host-identifier-scenarios-05#section-15. If there are other concern= s not already covered, it will be relay helpful to explicit them.=20 The document does not include any solution discussion but focuses only on t= he description of deployment use cases where problems are encountered.=20 Cheers, Med >-----Message d'origine----- >De=A0: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >Envoy=E9=A0: jeudi 5 juin 2014 15:24 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; Hannes Tschofenig; int-area@ietf.org >Cc=A0: ietf-privacy@ietf.org; Zuniga, Juan Carlos >Objet=A0: Re: [ietf-privacy] NAT Reveal / Host Identifiers > > >Hi Med, > >On 05/06/14 14:11, mohamed.boucadair@orange.com wrote: >> Hi Stephen, >> >> You referred in your message to an old version. > >That was the one for which the adoption call was issued. I >guess just a typo. > >I looked quickly at the diff between 04 and 05 and my >conclusion remains the same and most of my comment I think >still apply, despite the removal of the odd requirements >section. > >S. > >> The latest version of >> the document does not include any requirement, it is only an >> inventory of use cases when problems are encountered. The latest >> version is available at: >> http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier- >scenarios-05. >> >> Some of these use cases are restricted to a single administrative >> domain while others span multiple domain. Privacy concerns are really >> important; these are discussed in RFC6967. >> >> The use cases are not theoretical ones, but are those where >> complications arise. Explicitly calling out security risks (including >> privacy ones) will benefit to this work. It is really helpful to >> understand the use cases and call out any potential risks rather than >> speculating without actual understanding of what the problem is. >> >> This document is the opportunity to record security and privacy >> concerns that apply to these use cases. The content of the document >> is not frozen. Adopting it as a WG document will undoubtedly enrich >> it and benefit from other perspectives that those of the authors. >> >> Cheers, Med >> >>> -----Message d'origine----- De : ietf-privacy >>> [mailto:ietf-privacy-bounces@ietf.org] De la part de Stephen >>> Farrell Envoy=E9 : jeudi 5 juin 2014 14:48 =C0 : Hannes Tschofenig; >>> int-area@ietf.org Cc : ietf-privacy@ietf.org; Zuniga, Juan Carlos >>> Objet : Re: [ietf-privacy] NAT Reveal / Host Identifiers >>> >> >> Hiya, >> >> On 05/06/14 08:05, Hannes Tschofenig wrote: >>>>> If you want to review a document with privacy implications >>>>> then have a look at the NAT reveal / host identifier work >>>>> (with draft-boucadair-intarea-host-identifier-scenarios-04 >>>>> currently in a call for adoption). >>>>> >>>>> I had raised my concerns several times now on the mailing list >>>>> and during the meetings. >> >> I share those concerns. And adopting this without any consideration >> of BCP188 would fly in the face of a very recent, very thoroughly >> discussed, IETF consensus. For something like this, the onus ought >> IMO be on the proposers to have done that work before asking for >> adoption. Based on the draft, they clearly have not done that. >> >> We could also ask to add more use-cases: >> >> use-case#12: spy on everyone more easily, TEMPORA++ use-case#13: sell >> data that's even more fine-grained than clickstreams use-case#14: >> expose your n/w internals to help on path attackers use-case#15: >> track hosts from which people emit "dangerous" utterances >> use-case#16: block hosts from which people emit "dangerous" >> utterances use-case#17: charge me more for using two of my computers >> in my house >> >> The set of use-cases presented very much contradicts the explicit >> claim in the draft that no position is being taken as to the merits >> of this. IMO that argues strongly to not adopt this. >> >> One could also comment on the requirements that seem to require new >> laws of physics or are otherwise pretty odd: >> >> REQ#1: seems to require knowing from packets passing by that a device >> is a "trusted device" (and REQ#15 says that can be done with 16 >> bits;-) Hmm... are those qubits maybe? >> >> REQ#5: *all* IP packets MUST have a HOST_ID... but presumably without >> a flag day. Hmm... >> >> REQ#6: says this is a transport thing. Eh, why ask INT-AREA? >> >> REQ#10+REQ#11: MUST be intradomain only but MUST also be inter >> domain. Hmm... >> >> REQ#18: receiver MUST "enforce policies like QoS." Huh? >> >> Such a frankly bogus list of "requirements" also means that this is >> not something that ought be adopted in the IETF. >> >> I also think that this proposal has previously been proposed in other >> ways and not adopted. Such forum-shopping is yet another reason to >> not adopt it, and certainly not as an area wg thing without any >> broader IETF-wide consideration. (As an aside: having to play >> whack-a-mole with such repeat proposals is one of the downsides of >> area wgs. Not sure if anything can be done about that though.) >> >> In summary: ignoring BCP188, the selection-bias in use cases, the >> badly thought out "requirements" and forum shopping are all >> independently sufficient reasons to not adopt this. And of course >> that doesn't include all the other issues with potential solutions >> listed in RFC6967 (the reference to which is oddly to the I-D and not >> the RFC). >> >> My conclusion: this one ought go to /dev/null same as the previous >> attempts to shop the same thing into other parts of the IETF. >> >> S >> >> >>>>> >>>>> Ciao Hannes >>>>> >>>>> >>>>> -------- Original Message -------- Subject: [Int-area] Call >>>>> for adoption of >>>>> draft-boucadair-intarea-host-identifier-scenarios-04 Date: >>>>> Thu, 5 Jun 2014 04:20:56 +0000 From: Suresh Krishnan >>>>> To: Internet Area >>>>> >>>>> >>>>> >>>>> >>>>> Hi all, >>>>> >>>>> This draft was originally intended to be published as an AD >>>>> sponsored submission from the OPS area, but the authors have >>>>> expressed their interest to continue this work in the intarea >>>>> wg given that RFC6269 and RFC6967 originated here. The draft >>>>> has been updated to address the issues brought up during >>>>> earlier discussions on the wg mailing list and the latest >>>>> version of the draft is available at >>>>> >>>>> >>>>> >>>>> http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier- >> >>>>> >scenarios-04 >>>>> >>>>> >>>>> >> This call is being initiated to determine whether there is WG >>>>> consensus towards adoption of >>>>> draft-boucadair-intarea-host-identifier-scenarios-04 as an >>>>> intarea WG draft. Please state whether or not you're in favor >>>>> of the adoption by replying to this email. If you are not in >>>>> favor, please also state your objections in your response. This >>>>> adoption call will complete on 2014-06-19. >>>>> >>>>> >>>>> >>>>> Regards >>>>> >>>>> Suresh & Juan Carlos >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ ietf-privacy >>>>> mailing list ietf-privacy@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf-privacy >>>>> >>> >>> _______________________________________________ ietf-privacy >>> mailing list ietf-privacy@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-privacy >> >> From nobody Thu Jun 5 07:58:34 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2BC1A0179 for ; Thu, 5 Jun 2014 07:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fROV0DrIuO8Z for ; Thu, 5 Jun 2014 07:58:28 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877971A015C for ; Thu, 5 Jun 2014 07:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=769; q=dns/txt; s=iport; t=1401980242; x=1403189842; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=UY8rJ6D5am7PrD/tBfsASLCrIQD/ajqkEZ9/CT7nzRU=; b=Mo7J/2DgzE7FLmM4bPh5tuoKVUVsCFcrZCWEokdwSUtc/ta83rzD3JEN Qq+7+pMeWaeAsKEbWBFX5AK5yFxEtpMRHAhuDMkx2sWdMGCCYIxHaHkRm 4mFN7lxvgwN0vnJt6XIFvvUqRe38vhpeaiIYzn1naAv+VOD2O247iX/gV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAFmEkFOtJA2K/2dsb2JhbABQCYMHgSrDBgGBDRZ0giUBAQEDAR0dRAcGAQgRBAEBAQoUCTkUCQkBBAESCIgyCNMdF413Kj6DJYEVAQOtTIF4gUCCLw X-IronPort-AV: E=Sophos;i="4.98,981,1392163200"; d="scan'208";a="50451865" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP; 05 Jun 2014 14:57:21 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s55EvLOJ004062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jun 2014 14:57:21 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 5 Jun 2014 09:57:21 -0500 From: "Tirumaleswar Reddy (tireddy)" To: S Moonesamy , "int-area@ietf.org" Thread-Topic: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 Thread-Index: Ac+AznHdse5nvnRnTqmvspwdoaYmhA== Date: Thu, 5 Jun 2014 14:57:20 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A282C8C39@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.67.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/oL-L2HhIZ8FqKy3EnaEEkQ24xGg Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 14:58:32 -0000 > -----Original Message----- > From: S Moonesamy [mailto:sm+ietf@elandsys.com] > Sent: Thursday, June 05, 2014 7:47 PM > To: Tirumaleswar Reddy (tireddy); int-area@ietf.org > Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host= - > identifier-scenarios-04 >=20 > Hi Tiru, > At 05:06 05-06-2014, Tirumaleswar Reddy (tireddy) wrote: > >I support adoption of this draft. >=20 > May I ask why you support adoption of this draft ? =20 My interest in this draft is that it helps solve the problem of identifying= host after NAT to enforce identity based policies.=20 Cheers, -Tiru FYI - I am also the co-author of the draft. > Please note that I consider > the question as a difficult one. >=20 > Regards, > S. Moonesamy From nobody Thu Jun 5 11:11:31 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30971A01CB for ; Thu, 5 Jun 2014 07:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwvaJuGaWUYU for ; Thu, 5 Jun 2014 07:30:45 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCB41A0153 for ; Thu, 5 Jun 2014 07:30:25 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.138.226]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s55ETxDK018744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2014 07:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1401978611; x=1402065011; bh=nI9Yhk75QZ1GVqi6YZnajb4RupBC3OKTvzsqdA/aZ28=; h=Date:To:From:Subject:In-Reply-To:References; b=oecb9eOAaN6mbXkFMVe3AJCUCKP3pR6IxDERqHVkSesA7+T1ClQjDg00emN7wohGO IUA6cTMikS9PJ/hzsVfX4zlktyF382BwGnewsJ5QkqkR6uXdAILVXDLjuP0nzk0dRj B67/2qFuIjo3/WMDEv/c8IgLo9R2ROenoOyq3WEU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1401978611; x=1402065011; i=@elandsys.com; bh=nI9Yhk75QZ1GVqi6YZnajb4RupBC3OKTvzsqdA/aZ28=; h=Date:To:From:Subject:In-Reply-To:References; b=jf2PEEgZ1vTNtCx+dbbzdupwDQOnvfAlr4NCWdtWV2wHthaYK1/WZFLZHYyzePT3w UfTYwBtpCgF35RdOG9IZ0/37ng1eyVC/WvdrEJFIJJohaRdymJwvni4oRVsthzh2Hh H8BaDNfcdc36PHsQlTon1FfjI1oWwvwaTJjabDXM= Message-Id: <6.2.5.6.2.20140605070603.0d7ec778@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 05 Jun 2014 07:16:36 -0700 To: "Tirumaleswar Reddy (tireddy)" , int-area@ietf.org From: S Moonesamy In-Reply-To: <913383AAA69FF945B8F946018B75898A282C8A3D@xmb-rcd-x10.cisco .com> References: <913383AAA69FF945B8F946018B75898A282C8A3D@xmb-rcd-x10.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/RTCEKJNT0RMIt0P_YsUyNR2grSE X-Mailman-Approved-At: Thu, 05 Jun 2014 11:11:00 -0700 Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 14:30:47 -0000 X-List-Received-Date: Thu, 05 Jun 2014 14:30:47 -0000 Hi Tiru, At 05:06 05-06-2014, Tirumaleswar Reddy (tireddy) wrote: >I support adoption of this draft. May I ask why you support adoption of this draft? Please note that I consider the question as a difficult one. Regards, S. Moonesamy From nobody Thu Jun 5 11:11:32 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40D51A0193 for ; Thu, 5 Jun 2014 08:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mSmV5XPwPU7 for ; Thu, 5 Jun 2014 08:29:51 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E31301A01A7 for ; Thu, 5 Jun 2014 08:28:17 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.138.226]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s55FRph4028810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2014 08:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1401982083; x=1402068483; bh=tvOTyh5w7hwCl3qUeA3or5MIaHV8MzDjgGsjdU8OxDs=; h=Date:To:From:Subject:In-Reply-To:References; b=Dg4OqOubSZraijrnefMMl5UdvrorV1uwWYWTIgzi6dAz7C7CxLLk0R/Wv+NcLHtSn e6f57zBQKw4gTThEd3+kvFVhdOfjxSgsJJRqy8aGOWzzwUFvLYg9npRZ89hYLaJGZE 3UmxqP1YQR+hJAHwVHqGY5LN0dXK+OXu6wLRuNAE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1401982083; x=1402068483; i=@elandsys.com; bh=tvOTyh5w7hwCl3qUeA3or5MIaHV8MzDjgGsjdU8OxDs=; h=Date:To:From:Subject:In-Reply-To:References; b=J7Qn9FnpJeni7SLmB7tmebKCUuxTfIob+f1PiZfEAp3SvTrNVfjAPHf6Ic6P9IEi3 a49yfXv+qGilyZ9WcP1YbdKzV51vNyqiz5RH2s6z2qJLb/37OqhLi7LF6QUTl0bK8K DXlcSGcdKc6MS6aAzUTJa7/MKI/XEI6LI6RWzssA= Message-Id: <6.2.5.6.2.20140605081321.0bda1060@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 05 Jun 2014 08:19:59 -0700 To: "Tirumaleswar Reddy (tireddy)" , int-area@ietf.org From: S Moonesamy In-Reply-To: <913383AAA69FF945B8F946018B75898A282C8C39@xmb-rcd-x10.cisco .com> References: <913383AAA69FF945B8F946018B75898A282C8C39@xmb-rcd-x10.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/xg8omhM0wNM0esGHZPQgaV0WZik X-Mailman-Approved-At: Thu, 05 Jun 2014 11:11:06 -0700 Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 15:29:52 -0000 Hi Tiru, At 07:57 05-06-2014, Tirumaleswar Reddy (tireddy) wrote: >My interest in this draft is that it helps solve the problem of >identifying host after NAT to enforce identity based policies. Ok. >FYI - I am also the co-author of the draft. I noticed that. :-) According to RFC 6967: "HOST_ID specification document(s) should explain the privacy impact of the solutions they specify, including the extent of HOST_ID uniqueness and persistence, assumptions made about the lifetime of the HOST_ID, whether and how the HOST_ID can be obfuscated or recycled, whether location information can be exposed, and the impact of the use of the HOST_ID on device or implementation fingerprinting." From draft-boucadair-intarea-host-identifier-scenarios-05: "Privacy-related considerations that apply to means to reveal a host identified are discussed in [RFC6967]. This document does not introduce additional privacy issues than those discussed in [RFC6967]." It does not look like the privacy impact has been considered by the authors of the document. HOST_ID is an identifier, which according to the use cases, can be used in many places. Anyone in the spying business would welcome such an identifier. Will the authors be taking that into consideration or is it out of scope? Regards, S. Moonesamy From nobody Thu Jun 5 13:11:50 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833AC1A0249; Thu, 5 Jun 2014 13:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ic8vAuDjV1U2; Thu, 5 Jun 2014 13:11:39 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18A21A0305; Thu, 5 Jun 2014 13:11:34 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s55KAnUX016437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Jun 2014 13:10:50 -0700 (PDT) Message-ID: <5390CEC9.3000005@isi.edu> Date: Thu, 05 Jun 2014 13:10:49 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Stephen Farrell , Hannes Tschofenig , int-area@ietf.org References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> In-Reply-To: <53906711.5070406@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/wOc4Sf--PnUf4sdWyEcJ5ayiNbs Cc: "ietf-privacy@ietf.org" Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 20:11:45 -0000 On 6/5/2014 5:48 AM, Stephen Farrell wrote: > I share those concerns. And adopting this without any consideration > of BCP188 would fly in the face of a very recent, very thoroughly > discussed, IETF consensus. That BCP thankfully includes zero RFC2119 language except the single word "should" (not capitalized) in the abstract, thus every new document is trivially compliant with its recommendations. (I really wish the IETF community cared as much about technical correctness and protocol robustness as they did about issuing that IMO largely political statement, which "flies in the face" of 40+ years of using globally-assigned, globally-unique IP addresses as endpoint identifiers as the basis of the Internet architecture). Joe From nobody Thu Jun 5 13:29:46 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A801A031C; Thu, 5 Jun 2014 13:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY8rLdcoSfMF; Thu, 5 Jun 2014 13:28:41 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D6D1A02F2; Thu, 5 Jun 2014 13:28:41 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id rr13so1600142pbb.11 for ; Thu, 05 Jun 2014 13:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=P99WJQ2CNE477EK5hdcxMeesXkK81zynHkyRVi6FauI=; b=UHydhvpQgc4WHuDWdbb3spKihV+KPP8GyHZ4zydOFrZ7nh7gIpN8beVkjEld4yzMCg sjXBdaiIPXiIAM5HdJlC86oy234giCNyVGhC5mcgEVI+beN3CoO6VLMRw0hABLIcLpB0 in4qSlgL8+pnUuRVLln00knzkstBo/I2O2iXuQ2V9KePLc6HshiWZNitoHgPeTDawxVe hI8wBO3uZfiM3qX7JRmugmB8gIp4q0n+TEsBl/cxkOeYs0jad4HXFE83I5+6SW2sP1+3 Y5BU6H+yG/B3sMm4YkfIdNBbOBXL1x3g1SJIuiZZPsEP6yLjOdQ1E3V+PdxL8uVSVgVX D+Eg== X-Received: by 10.69.10.164 with SMTP id eb4mr14280266pbd.35.1402000114875; Thu, 05 Jun 2014 13:28:34 -0700 (PDT) Received: from [192.168.178.23] (13.199.69.111.dynamic.snap.net.nz. [111.69.199.13]) by mx.google.com with ESMTPSA id bc4sm26611797pbb.2.2014.06.05.13.28.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 13:28:34 -0700 (PDT) Message-ID: <5390D2F8.6000801@gmail.com> Date: Fri, 06 Jun 2014 08:28:40 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stephen Farrell References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> In-Reply-To: <53906711.5070406@cs.tcd.ie> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/MhZHqBdgQuNKJr4d3SsyDYhp0Zs Cc: "ietf-privacy@ietf.org" , int-area@ietf.org Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 20:28:47 -0000 Stephen, On 06/06/2014 00:48, Stephen Farrell wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Hiya, > > On 05/06/14 08:05, Hannes Tschofenig wrote: >> If you want to review a document with privacy implications then >> have a look at the NAT reveal / host identifier work (with >> draft-boucadair-intarea-host-identifier-scenarios-04 currently in >> a call for adoption). >> >> I had raised my concerns several times now on the mailing list and >> during the meetings. > > I share those concerns. And adopting this without any consideration > of BCP188 would fly in the face of a very recent, very thoroughly > discussed, IETF consensus. I have to call you on that. WG adoption is not approval. It's agreement to work on a topic. It is not OK to attempt a pocket veto on adoption because you don't like the existing content. > For something like this, the onus ought > IMO be on the proposers to have done that work before asking for > adoption. Why? Where do the rules say that? As a matter of fact I tend to agree with many of your criticisms of the draft, and I like the idea (below) of adding what we might call the misuse cases. That's a discussion the intarea WG could have. Brian > Based on the draft, they clearly have not done that. > > We could also ask to add more use-cases: > > use-case#12: spy on everyone more easily, TEMPORA++ > use-case#13: sell data that's even more fine-grained than clickstreams > use-case#14: expose your n/w internals to help on path attackers > use-case#15: track hosts from which people emit "dangerous" utterances > use-case#16: block hosts from which people emit "dangerous" utterances > use-case#17: charge me more for using two of my computers in my house > > The set of use-cases presented very much contradicts the explicit > claim in the draft that no position is being taken as to the merits > of this. IMO that argues strongly to not adopt this. > > One could also comment on the requirements that seem to > require new laws of physics or are otherwise pretty odd: > > REQ#1: seems to require knowing from packets passing by that > a device is a "trusted device" (and REQ#15 says that can be > done with 16 bits;-) Hmm... are those qubits maybe? > > REQ#5: *all* IP packets MUST have a HOST_ID... but presumably > without a flag day. Hmm... > > REQ#6: says this is a transport thing. Eh, why ask INT-AREA? > > REQ#10+REQ#11: MUST be intradomain only but MUST also be inter > domain. Hmm... > > REQ#18: receiver MUST "enforce policies like QoS." Huh? > > Such a frankly bogus list of "requirements" also means that > this is not something that ought be adopted in the IETF. > > I also think that this proposal has previously been proposed > in other ways and not adopted. Such forum-shopping is yet > another reason to not adopt it, and certainly not as an > area wg thing without any broader IETF-wide consideration. > (As an aside: having to play whack-a-mole with such repeat > proposals is one of the downsides of area wgs. Not sure > if anything can be done about that though.) > > In summary: ignoring BCP188, the selection-bias in use > cases, the badly thought out "requirements" and forum > shopping are all independently sufficient reasons to > not adopt this. And of course that doesn't include all > the other issues with potential solutions listed in > RFC6967 (the reference to which is oddly to the I-D and > not the RFC). > > My conclusion: this one ought go to /dev/null same as the > previous attempts to shop the same thing into other parts > of the IETF. > > S > > >> Ciao Hannes >> >> >> -------- Original Message -------- Subject: [Int-area] Call for >> adoption of draft-boucadair-intarea-host-identifier-scenarios-04 >> Date: Thu, 5 Jun 2014 04:20:56 +0000 From: Suresh Krishnan >> To: Internet Area >> >> >> >> >> Hi all, >> >> This draft was originally intended to be published as an AD >> sponsored submission from the OPS area, but the authors have >> expressed their interest to continue this work in the intarea wg >> given that RFC6269 and RFC6967 originated here. The draft has been >> updated to address the issues brought up during earlier >> discussions on the wg mailing list and the latest version of the >> draft is available at >> >> >> >> http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 >> >> >> > This call is being initiated to determine whether there is WG >> consensus towards adoption of >> draft-boucadair-intarea-host-identifier-scenarios-04 as an intarea >> WG draft. Please state whether or not you're in favor of the >> adoption by replying to this email. If you are not in favor, please >> also state your objections in your response. This adoption call >> will complete on 2014-06-19. >> >> >> >> Regards >> >> Suresh & Juan Carlos >> >> >> >> >> >> >> >> >> _______________________________________________ ietf-privacy >> mailing list ietf-privacy@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-privacy >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJTkGcRAAoJEC88hzaAX42iFYYIAIlJHJE1BNetIdjhDTqlTfsX > w+fFwSpCfi1LzZzxYR+ZgnL96ed8QPJ/YJEb4S1jZ0u2g1+DqMbSMsuQ6aW78+WM > iHfyIqO8m7Ahkk1J++/5bK3N0fbqhMjWmqs1cCa7Gg/o9RScZQiMJQef8Iju5gVN > 3dnd/7riV9THntV7DQdwGC0SXp9Wfwn2i3oAqxYVpEixCxxGbQBRPIiXBcaLBP4s > lr86tLPCPdXB2K4uPsuofVxL/uGBkahF6DAGjq3URcUEVi/J82XL+eB/3bLQU5XG > 2Mr0LMu7v4XQ+92zCjm7UmWmiL1fcQ+M0g+5nESSP8bO3sNlFlN33+jzsEGTBRM= > =TF0g > -----END PGP SIGNATURE----- > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > . > From nobody Thu Jun 5 13:42:55 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F9F1A0278; Thu, 5 Jun 2014 13:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpsKhl33rsLe; Thu, 5 Jun 2014 13:42:50 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94A761A018E; Thu, 5 Jun 2014 13:42:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id A990A24675E; Thu, 5 Jun 2014 13:42:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-218.clppva.east.verizon.net [70.106.135.218]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id D62612467B7; Thu, 5 Jun 2014 13:42:25 -0700 (PDT) Message-ID: <5390D632.3040907@joelhalpern.com> Date: Thu, 05 Jun 2014 16:42:26 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brian E Carpenter , Stephen Farrell References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390D2F8.6000801@gmail.com> In-Reply-To: <5390D2F8.6000801@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/UnAcQkpZlu6IkbytqrpFVhmxjF8 Cc: "ietf-privacy@ietf.org" , int-area@ietf.org Subject: Re: [Int-area] [ietf-privacy] WG Adoption X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 20:42:52 -0000 Brian, in my experience working group adoption is more than the working group agreeing to work on the topic. It is generally the working group agreeing that the given document is a good basis for starting the work. Yes, there will almost always be need for improvement. Sometimes major improvement. But it is an agreement that this is a good starting point. Without commenting on the specific document, leaving out that consideration in your response to Stephen makes the discussion MUCH harder. Yours, Joel On 6/5/14, 4:28 PM, Brian E Carpenter wrote: ... > I have to call you on that. WG adoption is not approval. It's agreement > to work on a topic. It is not OK to attempt a pocket veto on adoption > because you don't like the existing content. ... From nobody Thu Jun 5 13:43:35 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A2E1A0278; Thu, 5 Jun 2014 13:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTybOCzNxueq; Thu, 5 Jun 2014 13:43:32 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4424F1A018E; Thu, 5 Jun 2014 13:43:32 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s55KgRuT023551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Jun 2014 13:42:27 -0700 (PDT) Message-ID: <5390D633.9070006@isi.edu> Date: Thu, 05 Jun 2014 13:42:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brian E Carpenter , Stephen Farrell References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390D2F8.6000801@gmail.com> In-Reply-To: <5390D2F8.6000801@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/v1LAgZcf0vKsKELvD2XLHG3kDN8 Cc: "ietf-privacy@ietf.org" , int-area@ietf.org Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 20:43:33 -0000 On 6/5/2014 1:28 PM, Brian E Carpenter wrote: ... > As a matter of fact I tend to agree with many of your criticisms > of the draft, and I like the idea (below) of adding what we might > call the misuse cases. That's a discussion the intarea WG could have. > > Brian I'd vote for WG adoption, and agree with the above with the caveat that such "misuse" should focus on: a) ways proposed mechanisms "undo" current mechanisms that *might* have been intended to preserve privacy (e.g., NATs are deployed for lots of reasons, and we never know intent per se, but privacy preservation CAN be a reason) b) ways proposed mechanisms can exceed restoring what such devices "undo" and be used to track hosts, processes, or other identities beyond what the original packet *would have already exposed*. I.e., for a device that inserts the source IP address and TCP source port for NAT traversal, it would at best be considered to 'undo' the potential privacy-creation intent of a NAT, but would NOT be considered to exceed what the original packet conveyed. Joe From nobody Thu Jun 5 14:26:47 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A591A028F; Thu, 5 Jun 2014 14:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwraDVAUr0ja; Thu, 5 Jun 2014 14:26:44 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50131A0262; Thu, 5 Jun 2014 14:26:44 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6BE781B82A8; Thu, 5 Jun 2014 14:26:38 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 567D4190064; Thu, 5 Jun 2014 14:26:38 -0700 (PDT) Received: from [10.0.10.40] (174.62.147.182) by CAS-01.WIN.NOMINUM.COM (64.89.228.131) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Jun 2014 14:26:38 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <5390D2F8.6000801@gmail.com> Date: Thu, 5 Jun 2014 17:26:37 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <1B87ABE4-1CA1-450D-BA96-3018DF39F08D@nominum.com> References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390D2F8.6000801@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [174.62.147.182] Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/SRusgKi98Wuwq-aUgiVuEhErMWQ Cc: "ietf-privacy@ietf.org" , int-area@ietf.org, Stephen Farrell Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 21:26:46 -0000 On Jun 5, 2014, at 4:28 PM, Brian E Carpenter = wrote: > I have to call you on that. WG adoption is not approval. It's = agreement > to work on a topic. It is not OK to attempt a pocket veto on adoption > because you don't like the existing content. WG adoption is a pretty heavy action. It states that the WG has = consensus to work on the document, and weighs heavily in the consensus = evaluation during WGLC. If there are problems with the document, part = of the adoption process should be the identification of those flaws and = an agreement to address them. So bringing up those flaws during the = adoption process is crucial to the process. It's also worth noting that the INTAREA working group is a special = working group, with an extremely broad charter, which is moderated by = the fact that in order for work to be done by the working group, the = Internet Area ADs have to approve the work. So needless to say I at least am watching keenly to see if Stephen's = objections are being addressed, and likely won't approve the adoption of = the work if they aren't. From nobody Thu Jun 5 15:50:40 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF1F1A0305; Thu, 5 Jun 2014 15:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqsEJsgDNUuH; Thu, 5 Jun 2014 15:50:34 -0700 (PDT) Received: from BLU004-OMC2S30.hotmail.com (blu004-omc2s30.hotmail.com [65.55.111.105]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA78C1A0301; Thu, 5 Jun 2014 15:50:33 -0700 (PDT) Received: from BLU181-W63 ([65.55.111.72]) by BLU004-OMC2S30.hotmail.com with Microsoft SMTPSVC(7.5.7601.22701); Thu, 5 Jun 2014 15:50:27 -0700 X-TMN: [2hjnQx5PyqNchoe+e8e8Ym2jjY/0Xp2/] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_d78546a1-20d0-4240-861f-245d4c3246a7_" From: Bernard Aboba To: Ted Lemon , Brian E Carpenter Date: Thu, 5 Jun 2014 15:50:26 -0700 Importance: Normal In-Reply-To: <1B87ABE4-1CA1-450D-BA96-3018DF39F08D@nominum.com> References: , <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie>, <5390D2F8.6000801@gmail.com>, <1B87ABE4-1CA1-450D-BA96-3018DF39F08D@nominum.com> MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jun 2014 22:50:27.0082 (UTC) FILETIME=[8B22FEA0:01CF8110] Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/79tvOuUaSkf4q0M5rJaDv7jFUkQ Cc: "ietf-privacy@ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 22:50:36 -0000 --_d78546a1-20d0-4240-861f-245d4c3246a7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ted said:=20 "If there are problems with the document=2C part of the adoption process sh= ould be the identification of those flaws and an agreement to address them.= So bringing up those flaws during the adoption process is crucial to the= process." [BA] I would agree that there should be an agreement to address the flaws p= rior to adoption=2C but in my experience that is often not enough. If the = flaws are major enough=2C sometimes the fixes end up being non-trivial=2C o= r even turn into an argument about the feasibility of fixing them at all. = More than once I have seen this turn into a "war of attribution" between t= he editors and the WG=2C where the editors assert that because the WG adopt= ed the document=2C they effectively endorsed the approach=2C and the WG ass= erting that they never would have adopted the document with the knowledge t= hat the flaws would remain.=20 To prevent this kind of argument down the line=2C if there is a major flaw = in a document=2C I now believe it is best to insist that it be addressed *= prior* to adoption. = --_d78546a1-20d0-4240-861f-245d4c3246a7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ted said: =3B

"If there are problems with the document=2C part of the ado= ption process should be the identification of those flaws and an agreement = to address them. So bringing up those flaws during the adoption process i= s crucial to the process."

[BA] I would agree that= there should be an agreement to address the flaws prior to adoption=2C but= in my experience that is often not enough.  =3BIf the flaws are major = enough=2C sometimes the fixes end up being non-trivial=2C or even turn into= an argument about the feasibility of fixing them at all.  =3B More tha= n once I have seen this turn into a "war of attribution" between the editor= s and the WG=2C where the editors assert that because the WG adopted the do= cument=2C they effectively endorsed the approach=2C and the WG asserting th= at they never would have adopted the document with the knowledge that the f= laws would remain. =3B

To prevent this kind of= argument down the line=2C if there is a major flaw in a document=2C I now = believe it is best to insist that it be addressed =3B =3B*prior* to adoption. =3B
= = --_d78546a1-20d0-4240-861f-245d4c3246a7_-- From nobody Thu Jun 5 15:51:40 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7E51A02B5; Thu, 5 Jun 2014 15:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id potQvuSBikrX; Thu, 5 Jun 2014 15:51:33 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4C4E1A025B; Thu, 5 Jun 2014 15:51:33 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id z10so1667929pdj.26 for ; Thu, 05 Jun 2014 15:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mIL8IXxjFc2iffj2gWTJ87ijj16vdm0+86qEN2anmlE=; b=OcdHZwZ/+WyDtwIisgHM6eXJp0ZokqZwcrCnVFCIGf5mHZKy7jNccaqFKur+3ZEvps 34uxl/1Ps1DIBVN6PQxD1togbY488zwu9KUj9AWZsqoNatzQE5kPYIXH3PstLDjeXQ3A PAonL5RbKHP0G/sML00badqmKiks9EYz7PpsvXaBh7GoLk3bsWo7/7gOp8pPXoMLfAvn AZ+C0hrxDXDtyvft5Dm8LFXIjAbgvD1+B9wct6vYgjvr7XhpbyHbtHg56LSjkekbYbVH XkHtUaJyzueiUhunThmkPvhp3hNOLKMuRgFOT4G4AmxCfK8/OK/8OmNHyEQI8t6+WkEx DzBg== X-Received: by 10.69.31.11 with SMTP id ki11mr1393781pbd.88.1402008687434; Thu, 05 Jun 2014 15:51:27 -0700 (PDT) Received: from [192.168.178.23] (13.199.69.111.dynamic.snap.net.nz. [111.69.199.13]) by mx.google.com with ESMTPSA id oa3sm27594497pbb.15.2014.06.05.15.51.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 15:51:26 -0700 (PDT) Message-ID: <5390F475.7080702@gmail.com> Date: Fri, 06 Jun 2014 10:51:33 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Joel M. Halpern" References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390D2F8.6000801@gmail.com> <5390D632.3040907@joelhalpern.com> In-Reply-To: <5390D632.3040907@joelhalpern.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/j_mFI7mjJGwt3auzcmNS-kTj4j0 Cc: "ietf-privacy@ietf.org" , int-area@ietf.org, Stephen Farrell Subject: Re: [Int-area] [ietf-privacy] WG Adoption X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 22:51:36 -0000 On 06/06/2014 08:42, Joel M. Halpern wrote: > Brian, in my experience working group adoption is more than the working > group agreeing to work on the topic. It is generally the working group > agreeing that the given document is a good basis for starting the work. > Yes, there will almost always be need for improvement. Sometimes major > improvement. But it is an agreement that this is a good starting point. > > Without commenting on the specific document, leaving out that > consideration in your response to Stephen makes the discussion MUCH harder. Well, not harder than suggesting immediate /dev/null I think. Also, there is history here (RFC6269 and RFC6967) so I think it's clear that the topic is appropriate for the WG. There is a real problem caused by NAT, compared with the theoretically normal case where the host's globally unique address is visible to all. Brian > > Yours, > Joel > > On 6/5/14, 4:28 PM, Brian E Carpenter wrote: > ... >> I have to call you on that. WG adoption is not approval. It's agreement >> to work on a topic. It is not OK to attempt a pocket veto on adoption >> because you don't like the existing content. > ... > From nobody Thu Jun 5 15:58:29 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7953E1A02CE; Thu, 5 Jun 2014 15:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7i-cZ-5iCSrJ; Thu, 5 Jun 2014 15:58:24 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13151A025B; Thu, 5 Jun 2014 15:58:24 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id jt11so1751432pbb.36 for ; Thu, 05 Jun 2014 15:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=y0pzhX90C6934DKqh1gowRsXH6ilopI8QDdJ5dDLDfA=; b=irNmusF4CjC8EB8PW7xepz0obouwqlWw4rFmzOq27CwbW/5/BpVWfMp3z6CS9ES3EH H3C49z0/Jkd6lmTTqr9wV5PgWAUQ5IR2aUyV3r0jsWLYRbYyNclK2FYrzHr9OSsQ/i+g L/b4F8secMhLqX6lQzsFWthiW0ePXPDzfEzCtlnEtAVxYZdlZN1OO9en4k98tU84i2ho woctHTVx+mxS0VS46toKizKa1Y8k0OhlnehojayE6v8cMARINWzdF0s7EjfAuoqc2dhI fi4uUYfLAbSj24UDXTvktSnnN3DrNmoBfwtStUInhApDFP55TrZTXeYrt9yj0YgCURZ7 dRxA== X-Received: by 10.68.94.66 with SMTP id da2mr1404583pbb.106.1402009098228; Thu, 05 Jun 2014 15:58:18 -0700 (PDT) Received: from [192.168.178.23] (13.199.69.111.dynamic.snap.net.nz. [111.69.199.13]) by mx.google.com with ESMTPSA id qq5sm27630827pbb.24.2014.06.05.15.58.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 15:58:17 -0700 (PDT) Message-ID: <5390F610.1040802@gmail.com> Date: Fri, 06 Jun 2014 10:58:24 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390D2F8.6000801@gmail.com> <1B87ABE4-1CA1-450D-BA96-3018DF39F08D@nominum.com> In-Reply-To: <1B87ABE4-1CA1-450D-BA96-3018DF39F08D@nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/qW1yMSTipMdPrkSCSYfOluyHkpw Cc: "ietf-privacy@ietf.org" , int-area@ietf.org, Stephen Farrell Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 22:58:26 -0000 On 06/06/2014 09:26, Ted Lemon wrote: > On Jun 5, 2014, at 4:28 PM, Brian E Carpenter wrote: >> I have to call you on that. WG adoption is not approval. It's agreement >> to work on a topic. It is not OK to attempt a pocket veto on adoption >> because you don't like the existing content. > > WG adoption is a pretty heavy action. It states that the WG has consensus to work on the document, and weighs heavily in the consensus evaluation during WGLC. If there are problems with the document, part of the adoption process should be the identification of those flaws and an agreement to address them. So bringing up those flaws during the adoption process is crucial to the process. I have no problem with that. > It's also worth noting that the INTAREA working group is a special working group, with an extremely broad charter, Indeed. So (speaking only for myself) I tend to ignore drafts aimed at the WG until they are close to adoption, because my input bit rate is limited. Brian > which is moderated by the fact that in order for work to be done by the working group, the Internet Area ADs have to approve the work. > > So needless to say I at least am watching keenly to see if Stephen's objections are being addressed, and likely won't approve the adoption of the work if they aren't. > > From nobody Thu Jun 5 16:10:24 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F58C1A02CC; Thu, 5 Jun 2014 16:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOoFBcgFntLA; Thu, 5 Jun 2014 16:10:20 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7330C1A025B; Thu, 5 Jun 2014 16:10:20 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id ma3so1754534pbc.37 for ; Thu, 05 Jun 2014 16:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aU+WvhzGjA961ToEp8Gf0JmyKKk+nSprBolXtUeVNP8=; b=YVr5ytbcx1/1/FEg6vaLdXJcD7TuTmQ69HK38c18G98D9CYRK2aXnmF4mBiluzih4A 47zbXcloRBlRY4Nw8+266FXFGScUT1hC/dsdk78IvLpMu7Y+FfFc08XRuMbnU4UAbGTt w118wwZ2SimRbh6QkjHglDTzGhqxkVK1zOwLxBu5y4jZtKkcNJWAXS7REQAt48if/guJ GF8ByLynYPl/YkNYzLkpNZ4mMaJXS6/VbXj0lFZGmZojFLaX715vWWKZ/Hn+DJsAkxxN BfiZXWr5h4sTTeLwUop8aYdHPUQuTxCAh/PMVK3u0c2B0W3A032BItGlkkFCwVbacEXC 1+gw== X-Received: by 10.68.240.5 with SMTP id vw5mr1236708pbc.113.1402009813963; Thu, 05 Jun 2014 16:10:13 -0700 (PDT) Received: from [192.168.178.23] (13.199.69.111.dynamic.snap.net.nz. [111.69.199.13]) by mx.google.com with ESMTPSA id io8sm27615127pbc.96.2014.06.05.16.10.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 16:10:13 -0700 (PDT) Message-ID: <5390F8DC.4060505@gmail.com> Date: Fri, 06 Jun 2014 11:10:20 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bernard Aboba References: , <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie>, <5390D2F8.6000801@gmail.com>, <1B87ABE4-1CA1-450D-BA96-3018DF39F08D@nominum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/6FfU7uog8_B6kfCp9IDXgk8aS6o Cc: "ietf-privacy@ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 23:10:22 -0000 One more response and then I will shut up on this issue: On 06/06/2014 10:50, Bernard Aboba wrote: > Ted said: > "If there are problems with the document, part of the adoption process should be the identification of those flaws and an agreement to address them. So bringing up those flaws during the adoption process is crucial to the process." > [BA] I would agree that there should be an agreement to address the flaws prior to adoption, but in my experience that is often not enough. If the flaws are major enough, sometimes the fixes end up being non-trivial, or even turn into an argument about the feasibility of fixing them at all. More than once I have seen this turn into a "war of attribution" between the editors and the WG, where the editors assert that because the WG adopted the document, they effectively endorsed the approach, and the WG asserting that they never would have adopted the document with the knowledge that the flaws would remain. > To prevent this kind of argument down the line, if there is a major flaw in a document, I now believe it is best to insist that it be addressed *prior* to adoption. That seems to me to be going one step further than the criteria suggested in RFC7221 (only Informational, but recently approved by the IESG) at http://tools.ietf.org/html/rfc7221#section-2.2 Specifically, it's a higher bar than the combination of * Does the document provide an acceptable platform for continued effort by the working group? and * What are the process or technical objections to adoption of the draft? If the draft is an acceptable base and the technical objections are understood, there's no reason not to proceed. And to repeat, I agree with the technical objections in this case, and with the suggestion of how to fix them. Brian From nobody Fri Jun 6 00:59:42 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8571A0376 for ; Fri, 6 Jun 2014 00:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBoMIUyIpwjj for ; Fri, 6 Jun 2014 00:59:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2CB1A00AD for ; Fri, 6 Jun 2014 00:59:36 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 1A8892DC0C4; Fri, 6 Jun 2014 09:59:29 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id EF400238055; Fri, 6 Jun 2014 09:59:28 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.12]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0181.006; Fri, 6 Jun 2014 09:59:28 +0200 From: To: S Moonesamy , "Tirumaleswar Reddy (tireddy)" , "int-area@ietf.org" Thread-Topic: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 Thread-Index: AQHPgNGdrUyltEwcTkGHOn7+FS/m0ptjp6EQ Date: Fri, 6 Jun 2014 07:59:28 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933001417F@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <913383AAA69FF945B8F946018B75898A282C8C39@xmb-rcd-x10.cisco.com> <6.2.5.6.2.20140605081321.0bda1060@resistor.net> In-Reply-To: <6.2.5.6.2.20140605081321.0bda1060@resistor.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.6.70018 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/z8B1l0abtSLX0jrEBN_bkZ8jOG8 Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 07:59:39 -0000 Hi SM, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Int-area [mailto:int-area-bounces@ietf.org] De la part de S Moonesa= my >Envoy=E9=A0: jeudi 5 juin 2014 17:20 >=C0=A0: Tirumaleswar Reddy (tireddy); int-area@ietf.org >Objet=A0: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host= - >identifier-scenarios-04 > >Hi Tiru, >At 07:57 05-06-2014, Tirumaleswar Reddy (tireddy) wrote: >>My interest in this draft is that it helps solve the problem of >>identifying host after NAT to enforce identity based policies. > >Ok. > >>FYI - I am also the co-author of the draft. > >I noticed that. :-) > >According to RFC 6967: > > "HOST_ID specification document(s) should explain the privacy impact [Med] FWIW, the scenarios draft is not a "HOST_ID specification document".= =20 > of the solutions they specify, including the extent of HOST_ID > uniqueness and persistence, assumptions made about the lifetime of > the HOST_ID, whether and how the HOST_ID can be obfuscated or > recycled, whether location information can be exposed, and the impact > of the use of the HOST_ID on device or implementation fingerprinting." > > From draft-boucadair-intarea-host-identifier-scenarios-05: > > "Privacy-related considerations that apply to means to reveal a host > identified are discussed in [RFC6967]. This document does not > introduce additional privacy issues than those discussed in > [RFC6967]." > >It does not look like the privacy impact has been considered by the >authors of the document. [Med] Having a dedicated section for privacy is a signal that we have those= issues on our radar. Our analysis at this stage is that RFC6967 includes a= decent discussion that is still valid for this use cases document. If you = think that additional concerns are to be discussed, please don't hesitate t= o share them. We will consider updating the document accordingly.=20 > >HOST_ID is an identifier, which according to the use cases, can be >used in many places. [Med] There is no mention of "HOST_ID" in this draft. Furthermore, the curr= ent text says the following: " The document does not elaborate whether explicit authentication is enabled or not." Solution-specific discussions are out of scope. The main mission of the doc= ument is to help identifying use cases where there are difficulties to enfo= rce per-host policies due to the presence of address sharing or the use of = tunnels.=20 Anyone in the spying business would welcome >such an identifier. Will the authors be taking that into >consideration or is it out of scope? [Med] Documenting misuses should be definitely in scope. Contributions are = more than welcome. > >Regards, >S. Moonesamy > >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area From nobody Fri Jun 6 01:03:32 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403D61A03FD for ; Fri, 6 Jun 2014 01:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJLHizQR0Pqd for ; Fri, 6 Jun 2014 01:03:29 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95011A03D8 for ; Fri, 6 Jun 2014 01:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2520; q=dns/txt; s=iport; t=1402041802; x=1403251402; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RyTv2QVF8IKwp6UcO6pE+6yzLHgAMTdsmFfPZmsFpaY=; b=a+qGa0gaFPDfHd15GojuvJtWQw7emjXFaznU4MM5wCEmML7VqLskmWa6 4N9tf/pkqy7/PDvY0hqgnM5xTceJS6l0uF+6IU1QVLztnAEmCLKBaeZCe mwkPY3b4UhjBQjeHGrJEvq4LICpOwkmODNqfpfwpzR4923yWCyzv60Scs g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFANF0kVOtJV2c/2dsb2JhbABQCYMNUlnDfAGBBxZ1hAMBAQEDAR0dSwQCAQgRBAEBAQoUCQcyFAkIAQEEARIIE4gfCA3MWReODio4BoMlgRYEm1eRf4F8gUCCLw X-IronPort-AV: E=Sophos;i="4.98,987,1392163200"; d="scan'208";a="50780316" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP; 06 Jun 2014 08:03:21 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s5683LTO022927 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Jun 2014 08:03:21 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Fri, 6 Jun 2014 03:03:20 -0500 From: "Tirumaleswar Reddy (tireddy)" To: S Moonesamy , "int-area@ietf.org" Thread-Topic: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 Thread-Index: Ac+AznHdse5nvnRnTqmvspwdoaYmhAABK24iACA5y1A= Date: Fri, 6 Jun 2014 08:03:19 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A282C944F@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A282C8C39@xmb-rcd-x10.cisco.com> <6.2.5.6.2.20140605081321.0bda1060@resistor.net> In-Reply-To: <6.2.5.6.2.20140605081321.0bda1060@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.55.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/V4LEchyHTkwrB44vQpyMw3Qz-Yk Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 08:03:30 -0000 > -----Original Message----- > From: S Moonesamy [mailto:sm+ietf@elandsys.com] > Sent: Thursday, June 05, 2014 8:50 PM > To: Tirumaleswar Reddy (tireddy); int-area@ietf.org > Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host= - > identifier-scenarios-04 >=20 > Hi Tiru, > At 07:57 05-06-2014, Tirumaleswar Reddy (tireddy) wrote: > >My interest in this draft is that it helps solve the problem of > >identifying host after NAT to enforce identity based policies. >=20 > Ok. >=20 > >FYI - I am also the co-author of the draft. >=20 > I noticed that. :-) >=20 > According to RFC 6967: >=20 > "HOST_ID specification document(s) should explain the privacy impact > of the solutions they specify, including the extent of HOST_ID > uniqueness and persistence, assumptions made about the lifetime of > the HOST_ID, whether and how the HOST_ID can be obfuscated or > recycled, whether location information can be exposed, and the impact > of the use of the HOST_ID on device or implementation fingerprinting.= " >=20 > From draft-boucadair-intarea-host-identifier-scenarios-05: >=20 > "Privacy-related considerations that apply to means to reveal a host > identified are discussed in [RFC6967]. This document does not > introduce additional privacy issues than those discussed in > [RFC6967]." >=20 > It does not look like the privacy impact has been considered by the autho= rs of > the document. >=20 > HOST_ID is an identifier, which according to the use cases, can be used i= n many > places. Anyone in the spying business would welcome such an identifier. = Will > the authors be taking that into consideration or is it out of scope ? The privacy impact of the use cases is within the scope of this document. T= he use cases are only listing existing problems of host identification with= NAT, in future when solutions for each of these use cases are proposed the= y should also discuss the impact on privacy. For example use cases like htt= p://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-0= 5#section-7 the host identifier is added by NAT and removed by PCEF in the = same network and thus the host identifier is not even visible to attacker s= niffing packets and for the Femtocells use case, FAP Gateway needs a mechan= ism to learn the FAP public IP address and I don't see a privacy problem in= this use case.=20 Cheers, -Tiru >=20 > Regards, > S. Moonesamy From nobody Fri Jun 6 01:11:55 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27791A0400; Fri, 6 Jun 2014 01:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCKUvdjXWlrB; Fri, 6 Jun 2014 01:11:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9271F1A03C7; Fri, 6 Jun 2014 01:11:45 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id CAD35324384; Fri, 6 Jun 2014 10:11:37 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id A6EDB35C048; Fri, 6 Jun 2014 10:11:37 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.12]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0181.006; Fri, 6 Jun 2014 10:11:37 +0200 From: To: Ted Lemon , Brian E Carpenter Thread-Topic: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers Thread-Index: AQHPgQTaDm6yLULEn0WY6FQhphp6qZtjuHew Date: Fri, 6 Jun 2014 08:11:37 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300141B4@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390D2F8.6000801@gmail.com> <1B87ABE4-1CA1-450D-BA96-3018DF39F08D@nominum.com> In-Reply-To: <1B87ABE4-1CA1-450D-BA96-3018DF39F08D@nominum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.6.70018 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/lHeFgobernMn1rzp1N25L-DfKXk Cc: "ietf-privacy@ietf.org" , "int-area@ietf.org" , Stephen Farrell Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 08:11:52 -0000 Hi Ted, As far as this document is concerned, we are open to address technical conc= erns. It will be helpful if these concerns are specific enough and hopefull= y in reference to http://tools.ietf.org/html/draft-boucadair-intarea-host-i= dentifier-scenarios-05. Adding a discussion on potential misuses can be considered to address the c= omment from Stephen if those are not redundant with the text already in htt= p://tools.ietf.org/html/rfc6967#section-3. =20 Cheers, Med >-----Message d'origine----- >De=A0: Int-area [mailto:int-area-bounces@ietf.org] De la part de Ted Lemon >Envoy=E9=A0: jeudi 5 juin 2014 23:27 >=C0=A0: Brian E Carpenter >Cc=A0: ietf-privacy@ietf.org; int-area@ietf.org; Stephen Farrell >Objet=A0: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers > >On Jun 5, 2014, at 4:28 PM, Brian E Carpenter >wrote: >> I have to call you on that. WG adoption is not approval. It's agreement >> to work on a topic. It is not OK to attempt a pocket veto on adoption >> because you don't like the existing content. > >WG adoption is a pretty heavy action. It states that the WG has consensu= s >to work on the document, and weighs heavily in the consensus evaluation >during WGLC. If there are problems with the document, part of the >adoption process should be the identification of those flaws and an >agreement to address them. So bringing up those flaws during the adoptio= n >process is crucial to the process. > >It's also worth noting that the INTAREA working group is a special working >group, with an extremely broad charter, which is moderated by the fact tha= t >in order for work to be done by the working group, the Internet Area ADs >have to approve the work. > >So needless to say I at least am watching keenly to see if Stephen's >objections are being addressed, and likely won't approve the adoption of >the work if they aren't. > >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area From nobody Fri Jun 6 03:48:47 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5171A0151; Fri, 6 Jun 2014 03:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNzu40ADjS5x; Fri, 6 Jun 2014 03:48:37 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D4FC1A0132; Fri, 6 Jun 2014 03:48:37 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CCBB51B82AF; Fri, 6 Jun 2014 03:48:30 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id B4FBC190064; Fri, 6 Jun 2014 03:48:30 -0700 (PDT) Received: from [10.0.10.40] (174.62.147.182) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Jun 2014 03:48:25 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <787AE7BB302AE849A7480A190F8B93300141B4@OPEXCLILM23.corporate.adroot.infra.ftgroup> Date: Fri, 6 Jun 2014 06:48:24 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <8A4C0802-DE9A-4ADF-AEA5-61DEC2AFB25B@nominum.com> References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390D2F8.6000801@gmail.com> <1B87ABE4-1CA1-450D-BA96-3018DF39F08D@nominum.com> <787AE7BB302AE849A7480A190F8B93300141B4@OPEXCLILM23.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [174.62.147.182] Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/xM_GrBCkwfe_QozXscy8-mUp4fo Cc: "ietf-privacy@ietf.org" , "int-area@ietf.org" , Stephen Farrell Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 10:48:39 -0000 On Jun 6, 2014, at 4:11 AM, mohamed.boucadair@orange.com wrote: > Adding a discussion on potential misuses can be considered to address = the comment from Stephen if those are not redundant with the text = already in http://tools.ietf.org/html/rfc6967#section-3. =20 The document hasn't been adopted yet, so we can avoid security issues = simply by not adopting it. Talking about what the security = considerations section might do to ameliorate the harm isn't in scope = yet. First we need to decide whether there is more harm than good done = by adopting and publishing the document! From nobody Fri Jun 6 04:41:42 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116741A0245; Fri, 6 Jun 2014 04:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOXM3l-v-O4Y; Fri, 6 Jun 2014 04:41:35 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BACA1A0279; Fri, 6 Jun 2014 04:41:35 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 1E5262641BD; Fri, 6 Jun 2014 13:41:27 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id EF659238055; Fri, 6 Jun 2014 13:41:26 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.12]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0181.006; Fri, 6 Jun 2014 13:41:26 +0200 From: To: Ted Lemon Thread-Topic: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers Thread-Index: AQHPgXTWDm6yLULEn0WY6FQhphp6qZtj82Fg Date: Fri, 6 Jun 2014 11:41:26 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933001433C@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390D2F8.6000801@gmail.com> <1B87ABE4-1CA1-450D-BA96-3018DF39F08D@nominum.com> <787AE7BB302AE849A7480A190F8B93300141B4@OPEXCLILM23.corporate.adroot.infra.ftgroup> <8A4C0802-DE9A-4ADF-AEA5-61DEC2AFB25B@nominum.com> In-Reply-To: <8A4C0802-DE9A-4ADF-AEA5-61DEC2AFB25B@nominum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.6.104820 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/rPUwiTy_bnJZgJVfvFOKfnQZVJk Cc: "ietf-privacy@ietf.org" , "int-area@ietf.org" , Stephen Farrell Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 11:41:40 -0000 Re-, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Ted Lemon [mailto:ted.lemon@nominum.com] >Envoy=E9=A0: vendredi 6 juin 2014 12:48 >=C0=A0: BOUCADAIR Mohamed IMT/OLN >Cc=A0: Brian E Carpenter; ietf-privacy@ietf.org; int-area@ietf.org; Stephe= n >Farrell >Objet=A0: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers > >On Jun 6, 2014, at 4:11 AM, mohamed.boucadair@orange.com wrote: >> Adding a discussion on potential misuses can be considered to address th= e >comment from Stephen if those are not redundant with the text already in >http://tools.ietf.org/html/rfc6967#section-3. > >The document hasn't been adopted yet, so we can avoid security issues >simply by not adopting it. [Med] I'm not sure about this Ted. There are other initiatives that try to = solve the issue for particular use cases, see for instance this effort for = HTTP: http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-10. The = rationale of the "host identifier scenarios" document is to group all use c= ases suffering from the same problem instead of focusing on one single case= . This allows having a big picture view of the problem space.=20 Talking about what the security considerations >section might do to ameliorate the harm isn't in scope yet. First we nee= d >to decide whether there is more harm than good done by adopting and >publishing the document! [Med] Fair enough.=20 From nobody Fri Jun 6 05:47:47 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1521A0074 for ; Fri, 6 Jun 2014 05:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCWLEYou_SFO for ; Fri, 6 Jun 2014 05:47:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92FC1A006D for ; Fri, 6 Jun 2014 05:47:42 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 5D9E63747C0 for ; Fri, 6 Jun 2014 14:47:34 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 47EC538404A for ; Fri, 6 Jun 2014 14:47:34 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 6 Jun 2014 14:47:33 +0200 From: To: "int-area@ietf.org" Thread-Topic: Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 Thread-Index: Ac+AdUkItwXlXKGCQeuKFKJeAHvWjgAPkBxQACxPDTAAAmezgA== Date: Fri, 6 Jun 2014 12:47:33 +0000 Message-ID: <8498_1402058854_5391B866_8498_13481_1_88CAD1D4E8773F42858B58CAA28272A014530EF1@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.6.85118 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/VTyhHpeAy4YockncNbdpkNCia7Q Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 12:47:45 -0000 I support adoption of this draft and would like to take the opportunity of = this message to remind the group about ETSI's interest for Use case#9, as e= xpressed in a Liaison Statement sent last year.=20 https://datatracker.ietf.org/liaison/1292/ BC De=A0: Int-area [mailto:int-area-bounces@ietf.org] De la part de Suresh Kri= shnan Envoy=E9=A0: jeudi 5 juin 2014 06:21 =C0=A0: Internet Area Objet=A0: [Int-area] Call for adoption of draft-boucadair-intarea-host-iden= tifier-scenarios-04 Hi all, =A0=A0 This draft was originally intended to be published as an AD sponsore= d submission from the OPS area, but the authors have expressed their intere= st to continue this work in the intarea wg given that RFC6269 and RFC6967 o= riginated here. The draft has been updated to address the issues brought up= during earlier discussions on the wg mailing list and the latest version o= f the draft is available at http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenario= s-04 This call is being initiated to determine whether there is WG consensus tow= ards adoption of draft-boucadair-intarea-host-identifier-scenarios-04 as an= intarea WG draft. Please state whether or not you're in favor of the adopt= ion by replying to this email. If you are not in favor, please also state y= our objections in your response. This adoption call will complete on 2014-0= 6-19. Regards Suresh & Juan Carlos ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Jun 6 06:01:26 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382AE1A048C for ; Fri, 6 Jun 2014 06:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSbk6J8-LEto for ; Fri, 6 Jun 2014 06:01:17 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6BA1A00BA for ; Fri, 6 Jun 2014 06:01:16 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.138.226]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s56D0oFH005170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jun 2014 06:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1402059663; x=1402146063; bh=6QUMDPvQKxapGWus9PUn7aQUv5PWOah8NRB1kkzijp4=; h=Date:To:From:Subject:In-Reply-To:References; b=09Sl5DLFdgwPmezfZgOmbQ9wseb/KyDwYPOe+Mx146Tml6ZYm1ep5P0UjE6y1b+63 RaDaNfqdG68KEfhtpWjxsUn1lMDqOZcw0Qg2oOz9iUcItH73jypnBn46SY4t7wdcdg Ovb1RLiqVKU/ZulQp+Abo6MW+bdbUjMvBBwTJqs8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1402059663; x=1402146063; i=@elandsys.com; bh=6QUMDPvQKxapGWus9PUn7aQUv5PWOah8NRB1kkzijp4=; h=Date:To:From:Subject:In-Reply-To:References; b=W97Tds1qYUYLUJRAh2I3L9t4j+5D2cHeL1Rt2RD9haTze/5vt0h7uYd2rcJ25YjUK sNUQNQLpIp8Gg7yeCKI+jrAAat3WRoYChf2lMcUGwg5pVpnt5xfaASvzKHlhwxHL62 toBJO8ndLvu343bXCpUX+HuO0OcinCSwNR9wJQJ8= Message-Id: <6.2.5.6.2.20140606042634.0baaab20@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 06 Jun 2014 05:55:40 -0700 To: mohamed.boucadair@orange.com, "Tirumaleswar Reddy (tireddy)" , int-area@ietf.org From: S Moonesamy In-Reply-To: <787AE7BB302AE849A7480A190F8B933001417F@OPEXCLILM23.corpora te.adroot.infra.ftgroup> References: <913383AAA69FF945B8F946018B75898A282C8C39@xmb-rcd-x10.cisco.com> <6.2.5.6.2.20140605081321.0bda1060@resistor.net> <787AE7BB302AE849A7480A190F8B933001417F@OPEXCLILM23.corporate.adroot.infra.ftgroup> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/sA5Kii3y2ROix-ILSTqvCvDh4V8 Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 13:01:23 -0000 Hi Med, At 00:59 06-06-2014, mohamed.boucadair@orange.com wrote: >[Med] FWIW, the scenarios draft is not a "HOST_ID specification document". [snip] >[Med] Having a dedicated section for privacy is a signal that we >have those issues on our radar. Our analysis at this stage is that >RFC6967 includes a decent discussion that is still valid for this >use cases document. If you think that additional concerns are to be >discussed, please don't hesitate to share them. We will consider >updating the document accordingly. [snip] >[Med] There is no mention of "HOST_ID" in this draft. Furthermore, >the current text says the following: >" The document does not elaborate whether explicit authentication is > enabled or not." > >Solution-specific discussions are out of scope. The main mission of >the document is to help identifying use cases where there are >difficulties to enforce per-host policies due to the presence of >address sharing or the use of tunnels. [snip] >[Med] Documenting misuses should be definitely in scope. >Contributions are more than welcome. From the above (quoted text) I understand that there are difficulties to enforce policies and those difficulties have not be discussed or addressed in IETF RFCs. The INTAREA working group previously worked on a RFC about potential solutions for revealing a host identifier. Are the potential solutions discussed in RFC 6967 inadequate? I don't think the question is out of scope given that the draft references RFC 6967. If the mission is to identify use cases, why are discussions about the use cases (see Section 2) out of scope? The lack of host identification does not affect host connectivity. This scenarios draft makes the case for the lack of host identification being the cause of problems. Do the problems affect the internet or are they limited cases? Regards, S. Moonesamy From nobody Fri Jun 6 08:22:31 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD951A016C; Fri, 6 Jun 2014 08:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xk7tgyOlKPd8; Fri, 6 Jun 2014 08:22:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id CE23C1A0160; Fri, 6 Jun 2014 08:22:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DEC42BF93; Fri, 6 Jun 2014 16:22:17 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3z_DycNCLJVt; Fri, 6 Jun 2014 16:22:17 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B3A4EBF91; Fri, 6 Jun 2014 16:22:17 +0100 (IST) Message-ID: <5391DCAA.8030907@cs.tcd.ie> Date: Fri, 06 Jun 2014 16:22:18 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brian E Carpenter References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390D2F8.6000801@gmail.com> In-Reply-To: <5390D2F8.6000801@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/jiJomYD_c425q6idjMAavkNEjYk Cc: "ietf-privacy@ietf.org" , int-area@ietf.org Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 15:22:27 -0000 I think Ted answered this but one little bit more... On 05/06/14 21:28, Brian E Carpenter wrote: > Stephen, > > On 06/06/2014 00:48, Stephen Farrell wrote: > > Hiya, > > On 05/06/14 08:05, Hannes Tschofenig wrote: >>>> If you want to review a document with privacy implications then >>>> have a look at the NAT reveal / host identifier work (with >>>> draft-boucadair-intarea-host-identifier-scenarios-04 currently in >>>> a call for adoption). >>>> >>>> I had raised my concerns several times now on the mailing list and >>>> during the meetings. > > I share those concerns. And adopting this without any consideration > of BCP188 would fly in the face of a very recent, very thoroughly > discussed, IETF consensus. > >> I have to call you on that. WG adoption is not approval. It's agreement >> to work on a topic. It is not OK to attempt a pocket veto on adoption >> because you don't like the existing content. > > For something like this, the onus ought > IMO be on the proposers to have done that work before asking for > adoption. > >> Why? Where do the rules say that? Just to clarify: I don't think we have rules that say that, nor do I have any kind of veto, I was just expressing my opinion, for this case. S >> As a matter of fact I tend to agree with many of your criticisms >> of the draft, and I like the idea (below) of adding what we might >> call the misuse cases. That's a discussion the intarea WG could have. > >> Brian > > Based on the draft, they clearly have not done that. > > We could also ask to add more use-cases: > > use-case#12: spy on everyone more easily, TEMPORA++ > use-case#13: sell data that's even more fine-grained than clickstreams > use-case#14: expose your n/w internals to help on path attackers > use-case#15: track hosts from which people emit "dangerous" utterances > use-case#16: block hosts from which people emit "dangerous" utterances > use-case#17: charge me more for using two of my computers in my house > > The set of use-cases presented very much contradicts the explicit > claim in the draft that no position is being taken as to the merits > of this. IMO that argues strongly to not adopt this. > > One could also comment on the requirements that seem to > require new laws of physics or are otherwise pretty odd: > > REQ#1: seems to require knowing from packets passing by that > a device is a "trusted device" (and REQ#15 says that can be > done with 16 bits;-) Hmm... are those qubits maybe? > > REQ#5: *all* IP packets MUST have a HOST_ID... but presumably > without a flag day. Hmm... > > REQ#6: says this is a transport thing. Eh, why ask INT-AREA? > > REQ#10+REQ#11: MUST be intradomain only but MUST also be inter > domain. Hmm... > > REQ#18: receiver MUST "enforce policies like QoS." Huh? > > Such a frankly bogus list of "requirements" also means that > this is not something that ought be adopted in the IETF. > > I also think that this proposal has previously been proposed > in other ways and not adopted. Such forum-shopping is yet > another reason to not adopt it, and certainly not as an > area wg thing without any broader IETF-wide consideration. > (As an aside: having to play whack-a-mole with such repeat > proposals is one of the downsides of area wgs. Not sure > if anything can be done about that though.) > > In summary: ignoring BCP188, the selection-bias in use > cases, the badly thought out "requirements" and forum > shopping are all independently sufficient reasons to > not adopt this. And of course that doesn't include all > the other issues with potential solutions listed in > RFC6967 (the reference to which is oddly to the I-D and > not the RFC). > > My conclusion: this one ought go to /dev/null same as the > previous attempts to shop the same thing into other parts > of the IETF. > > S > > >>>> Ciao Hannes >>>> >>>> >>>> -------- Original Message -------- Subject: [Int-area] Call for >>>> adoption of draft-boucadair-intarea-host-identifier-scenarios-04 >>>> Date: Thu, 5 Jun 2014 04:20:56 +0000 From: Suresh Krishnan >>>> To: Internet Area >>>> >>>> >>>> >>>> >>>> Hi all, >>>> >>>> This draft was originally intended to be published as an AD >>>> sponsored submission from the OPS area, but the authors have >>>> expressed their interest to continue this work in the intarea wg >>>> given that RFC6269 and RFC6967 originated here. The draft has been >>>> updated to address the issues brought up during earlier >>>> discussions on the wg mailing list and the latest version of the >>>> draft is available at >>>> >>>> >>>> >>>> http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 >>>> >>>> >>>> > This call is being initiated to determine whether there is WG >>>> consensus towards adoption of >>>> draft-boucadair-intarea-host-identifier-scenarios-04 as an intarea >>>> WG draft. Please state whether or not you're in favor of the >>>> adoption by replying to this email. If you are not in favor, please >>>> also state your objections in your response. This adoption call >>>> will complete on 2014-06-19. >>>> >>>> >>>> >>>> Regards >>>> >>>> Suresh & Juan Carlos >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ ietf-privacy >>>> mailing list ietf-privacy@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf-privacy >>>> >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >> . >> > From nobody Fri Jun 6 08:57:33 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0AB1A0080 for ; Fri, 6 Jun 2014 08:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erQLP_FQc_iQ for ; Fri, 6 Jun 2014 08:57:29 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4891A006E for ; Fri, 6 Jun 2014 08:57:29 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id j7so4073046qaq.17 for ; Fri, 06 Jun 2014 08:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=Y4ZMnRG+R0ks4lTjlKCneUhIdybBglzYwIYOkQjYsEI=; b=1CxTLSZKyJV5dabbqvHi+C91gM3z2tvE8WbX3yzaHiHTGYgR4ZtTRlJ5GcEg2T0Juw eWikH5wvkG5/ol1xRqfKG4Fn1rW5KlPCerNwQmpG/LewkIi4xJMNYzo5gBzlbj3j0ZVT RDFyOZJpg9MMor6Ep5rtZF9Ds+4uD2VUA9lggrJT59wuZOSJYXfWMzTWQomcmCgkXhDw AQq6eHgravV7TeQ5i6I9qiCD8a8uMnJQc7M+Hj+tfnYwysWmuZSgOUcTnqUkITtBiUjS BkBCYxdpcy3c3etW87/7E6Fn+BgMEYIN0rpdn2LT5WQW3o1ZqmjlYKjADI1YcD75y8ov s5kw== MIME-Version: 1.0 X-Received: by 10.140.88.112 with SMTP id s103mr9328289qgd.113.1402070242268; Fri, 06 Jun 2014 08:57:22 -0700 (PDT) Received: by 10.170.126.18 with HTTP; Fri, 6 Jun 2014 08:57:22 -0700 (PDT) In-Reply-To: <8498_1402058854_5391B866_8498_13481_1_88CAD1D4E8773F42858B58CAA28272A014530EF1@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <8498_1402058854_5391B866_8498_13481_1_88CAD1D4E8773F42858B58CAA28272A014530EF1@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Fri, 6 Jun 2014 10:57:22 -0500 Message-ID: From: Behcet Sarikaya To: bruno.chatras@orange.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/P_GorVGF-P1WyXHaitXX_HqnALE Cc: "int-area@ietf.org" Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 15:57:30 -0000 On Fri, Jun 6, 2014 at 7:47 AM, wrote: > I support adoption of this draft and would like to take the opportunity o= f this message to remind the group about ETSI's interest for Use case#9, as= expressed in a Liaison Statement sent last year. > https://datatracker.ietf.org/liaison/1292/ > +1 as co-author. Regards, Behcet > BC > > > De : Int-area [mailto:int-area-bounces@ietf.org] De la part de Suresh Kri= shnan > Envoy=C3=A9 : jeudi 5 juin 2014 06:21 > =C3=80 : Internet Area > Objet : [Int-area] Call for adoption of draft-boucadair-intarea-host-iden= tifier-scenarios-04 > > Hi all, > This draft was originally intended to be published as an AD sponsored = submission from the OPS area, but the authors have expressed their interest= to continue this work in the intarea wg given that RFC6269 and RFC6967 ori= ginated here. The draft has been updated to address the issues brought up d= uring earlier discussions on the wg mailing list and the latest version of = the draft is available at > > http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenar= ios-04 > > This call is being initiated to determine whether there is WG consensus t= owards adoption of draft-boucadair-intarea-host-identifier-scenarios-04 as = an intarea WG draft. Please state whether or not you're in favor of the ado= ption by replying to this email. If you are not in favor, please also state= your objections in your response. This adoption call will complete on 2014= -06-19. > > Regards > Suresh & Juan Carlos > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Fri Jun 6 08:59:46 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA55E1A0085; Fri, 6 Jun 2014 08:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoqXCNx7ojFY; Fri, 6 Jun 2014 08:59:36 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 53FFB1A007A; Fri, 6 Jun 2014 08:59:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 63A5ABF79; Fri, 6 Jun 2014 16:59:29 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-ynNuFVaQnZ; Fri, 6 Jun 2014 16:59:29 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CE653BF7D; Fri, 6 Jun 2014 16:59:25 +0100 (IST) Message-ID: <5391E55E.9000105@cs.tcd.ie> Date: Fri, 06 Jun 2014 16:59:26 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, Ted Lemon References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390D2F8.6000801@gmail.com> <1B87ABE4-1CA1-450D-BA96-3018DF39F08D@nominum.com> <787AE7BB302AE849A7480A190F8B93300141B4@OPEXCLILM23.corporate.adroot.infra.ftgroup> <8A4C0802-DE9A-4ADF-AEA5-61DEC2AFB25B@nominum.com> <787AE7BB302AE849A7480A190F8B933001433C@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933001433C@OPEXCLILM23.corporate.adroot.infra.ftgroup> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/_KLz7NafBiWMYP3KwrBAhZeqOgw Cc: "ietf-privacy@ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 15:59:37 -0000 Hi Med, On 06/06/14 12:41, mohamed.boucadair@orange.com wrote: > [Med] I'm not sure about this Ted. There are other initiatives that > try to solve the issue for particular use cases, see for instance > this effort for HTTP: > http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-10. The > rationale of the "host identifier scenarios" document is to group all > use cases suffering from the same problem instead of focusing on one > single case. This allows having a big picture view of the problem > space. I think XFF is actually a good example of why we ought not adopt this work. XFF is widely deployed already but somewhat flakey in terms of interop so the authors of the above draft aimed to produce a spec that just addressed interop. (*) That was adopted by an area WG without (IMO) ever really considering the privacy implications, and definitely without any effort having been made to develop a more privacy-friendly mechanism (which could have been done, again IMO) to solve what were the claimed use-cases. By the time it got to the IESG that was in practice unfixable and after some fairly painful discussions it ended up with 4 abstain ballots, including mine. [1] (For those who quite reasonably don't need to care about IESG balloting, an abstain means approximately "yuk.":-) Of course that all also pre-dated BCP188 and the last year's shenanigans so I'd hope we have learned to not keep doing that. I'd be delighted if those who could get a better solution implemented/deployed were to attempt to try to address the privacy issues with XFF but it seems that at least in that case relevant folks don't care (sufficiently;-) deeply about our privacy to go do that. S. [1] https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/ (*) To be clear: I think the authors were genuinely just trying to fix what they saw as an interop problem. From nobody Fri Jun 6 11:54:59 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5C31A0111; Fri, 6 Jun 2014 09:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKCxQ2criL_t; Fri, 6 Jun 2014 09:09:56 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A051A010D; Fri, 6 Jun 2014 09:09:56 -0700 (PDT) Received: from [85.158.136.35:33484] by server-16.bemta-5.messagelabs.com id 81/CF-19700-BC7E1935; Fri, 06 Jun 2014 16:09:47 +0000 X-Env-Sender: rob.horne@trustis.com X-Msg-Ref: server-3.tower-125.messagelabs.com!1402070976!37717041!20 X-Originating-IP: [217.28.140.9] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14622 invoked from network); 6 Jun 2014 16:09:47 -0000 Received: from smtp.hs20.net (HELO outlook.hs20.net) (217.28.140.9) by server-3.tower-125.messagelabs.com with AES256-SHA encrypted SMTP; 6 Jun 2014 16:09:47 -0000 Received: from THHSTE15D1BE5.hs20.net (192.168.251.26) by THHSTE15D1BE2.hs20.net (192.168.251.22) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 6 Jun 2014 17:09:08 +0100 Received: from THHSTE15D1BE5.hs20.net ([fe80::4064:274f:d635:873e]) by THHSTE15D1BE5.hs20.net ([fe80::4064:274f:d635:873e%15]) with mapi id 15.00.0847.030; Fri, 6 Jun 2014 17:09:08 +0100 From: "Horne, Rob" To: "touch@isi.edu" , "brian.e.carpenter@gmail.com" , "stephen.farrell@cs.tcd.ie" Thread-Topic: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers Thread-Index: AQHPgZmqH9Fs2K0LfUiEYmAeH7ZhWZti6VyAgAFWQkA= Date: Fri, 6 Jun 2014 16:09:08 +0000 Message-ID: <40d4eee108b142138e9b8c93026085fd@THHSTE15D1BE5.hs20.net> References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390D2F8.6000801@gmail.com> <5390D633.9070006@isi.edu> In-Reply-To: <5390D633.9070006@isi.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [62.6.167.196] x-exclaimer-md-config: 266e7a57-cddd-49fd-bdea-19bca6d40303 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/NlNn0cscOZGU5lvmIy_XYr07hho X-Mailman-Approved-At: Fri, 06 Jun 2014 11:54:58 -0700 Cc: "ietf-privacy@ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 16:09:58 -0000 I agree too and think Joe's outlined a good starting point to discuss "misu= se". Rob -----Original Message----- From: ietf-privacy [mailto:ietf-privacy-bounces@ietf.org] On Behalf Of Joe = Touch Sent: 05 June 2014 21:42 To: Brian E Carpenter; Stephen Farrell Cc: ietf-privacy@ietf.org; int-area@ietf.org Subject: Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers On 6/5/2014 1:28 PM, Brian E Carpenter wrote: ... > As a matter of fact I tend to agree with many of your criticisms of > the draft, and I like the idea (below) of adding what we might call > the misuse cases. That's a discussion the intarea WG could have. > > Brian I'd vote for WG adoption, and agree with the above with the caveat that suc= h "misuse" should focus on: a) ways proposed mechanisms "undo" current mechanisms that *might* have bee= n intended to preserve privacy (e.g., NATs are deployed for lots of reasons= , and we never know intent per se, but privacy preservation CAN be a reason= ) b) ways proposed mechanisms can exceed restoring what such devices "undo" a= nd be used to track hosts, processes, or other identities beyond what the o= riginal packet *would have already exposed*. I.e., for a device that inserts the source IP address and TCP source port f= or NAT traversal, it would at best be considered to 'undo' the potential pr= ivacy-creation intent of a NAT, but would NOT be considered to exceed what = the original packet conveyed. Joe _______________________________________________ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy From nobody Fri Jun 6 18:38:37 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99361A027C; Fri, 6 Jun 2014 18:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8uXY1yE22ab; Fri, 6 Jun 2014 18:38:33 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71BD31A0268; Fri, 6 Jun 2014 18:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1822; q=dns/txt; s=iport; t=1402105107; x=1403314707; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=HMfCjiiTZSrhIrc+g0B1+APPCAABuUhKn0p7rSjUT2g=; b=P8QR/5dfMFkowsMmXR21VX2VAJjf+jFBHS1JKGMhlS3rQ+GSC91KjgNd 5ZrSMfVGE0RJWxQIbMu+kUFJC7iS94HQfRFI3a+84uf2Vai48WXFk1Npb diFsIvPFxNcuywnrDGC2L7+8ySGxWzx1PU7QGgzNQO+8ZttBTH2EM3LVJ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJJsklOtJV2d/2dsb2JhbABZgw3FNgGBBRZ1hAMBAQEDATo/BQsLEgYuSQ4GExSIJgjNSheONjMHgyuBFgEDijGPbIZ2jE6DXB0 X-IronPort-AV: E=Sophos;i="4.98,992,1392163200"; d="scan'208";a="51017724" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 07 Jun 2014 01:38:26 +0000 Received: from [10.21.72.236] ([10.21.72.236]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s571cP0Y005132; Sat, 7 Jun 2014 01:38:25 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Dan Wing In-Reply-To: <5390CEC9.3000005@isi.edu> Date: Fri, 6 Jun 2014 18:38:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/bbHg1e6VRoB2QhCEzZiysKCdX10 Cc: "ietf-privacy@ietf.org" , Internet Area Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 01:38:35 -0000 On Jun 5, 2014, at 1:10 PM, Joe Touch wrote: > On 6/5/2014 5:48 AM, Stephen Farrell wrote: >> I share those concerns. And adopting this without any consideration >> of BCP188 would fly in the face of a very recent, very thoroughly >> discussed, IETF consensus. >=20 > That BCP thankfully includes zero RFC2119 language except the single = word "should" (not capitalized) in the abstract, thus every new document = is trivially compliant with its recommendations. >=20 > (I really wish the IETF community cared as much about technical = correctness and protocol robustness as they did about issuing that IMO = largely political statement, which "flies in the face" of 40+ years of = using globally-assigned, globally-unique IP addresses as endpoint = identifiers as the basis of the Internet architecture). Stephen, It seems NAPT has become IETF's privacy feature of 2014 because multiple = users are sharing one identifier (IP address and presumably randomized = ports [RFC6056], although many NAPT deployments use address ranges = because of fear of compressing log files). As a former co-chair of = BEHAVE it is refreshing to see the IETF embracing NAPT as a desirable = feature. However, if NAPT provides privacy and NAT Reveal removes it, where does = that leave a host's IPv6 source address with respect to BCP188? = Afterall, an IPv6 address is quite traceable, even with IPv6 privacy = addresses (especially as IPv6 privacy addresses are currently deployed = which only obtain a new IPv6 privacy address every 24 hours or when = attaching to a new network). If BCP188 does not prevent deployment of = IPv6, I would like to understand the additional privacy leakage of = IPv4+NAT+NAT_Reveal compared to the privacy leakage of = IPv6+privacy_address. -d From nobody Sat Jun 7 06:20:48 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E912A1A035C; Sat, 7 Jun 2014 06:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzpM-MpRaGJe; Sat, 7 Jun 2014 06:20:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8EA1A035D; Sat, 7 Jun 2014 06:20:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 20D19BF50; Sat, 7 Jun 2014 14:20:33 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpY5tvbqAAG2; Sat, 7 Jun 2014 14:20:32 +0100 (IST) Received: from [10.87.48.12] (unknown [86.42.16.21]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DD549BF4D; Sat, 7 Jun 2014 14:20:31 +0100 (IST) Message-ID: <5393119F.6050805@cs.tcd.ie> Date: Sat, 07 Jun 2014 14:20:31 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Dan Wing References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> In-Reply-To: <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/KHa4sAoaF4Q-wQhBimHIutdi90w Cc: "ietf-privacy@ietf.org" , Internet Area Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 13:20:44 -0000 Hi Dan, On 07/06/14 02:38, Dan Wing wrote: > > Stephen, > > It seems NAPT has become IETF's privacy feature of 2014 because > multiple users are sharing one identifier (IP address and presumably > randomized ports [RFC6056], although many NAPT deployments use > address ranges because of fear of compressing log files). As a > former co-chair of BEHAVE it is refreshing to see the IETF embracing > NAPT as a desirable feature. Embracing seems like significant overstatement to me, but maybe that's understandable given how calmly NAT is generally debated. NATs have both good and bad properties. The slightly better privacy is one of the good ones. Recognising that reality is neither embracing nor refreshing IMO, nor does it mean NAPT is (un)desirable overall. (That's an argument I only ever watch from the side-lines thanks:-) > However, if NAPT provides privacy and NAT Reveal removes it, where > does that leave a host's IPv6 source address with respect to BCP188? > > Afterall, an IPv6 address is quite traceable, even with IPv6 privacy > addresses (especially as IPv6 privacy addresses are currently > deployed which only obtain a new IPv6 privacy address every 24 hours > or when attaching to a new network). If BCP188 does not prevent > deployment of IPv6, I would like to understand the additional privacy > leakage of IPv4+NAT+NAT_Reveal compared to the privacy leakage of > IPv6+privacy_address. I'm frankly amazed that that's not crystal clear to anyone who has read all 2.5 non-boilerplate pages of the BCP. Or even just the last two words of the 1-line abstract (hint: those say "where possible.") Yes, source addresses leak information that affects privacy. But we do not have a practical way to mitigate that. So therefore BCP188 does not call for doing stupid stuff, nor for new laws of physics (unlike -04 of the draft we're discussing;-) Adding new identifiers with privacy impact, as proposed here, is quite different. S. PS: If someone wants to propose what they think is a practical way to mitigate the privacy issues with source addresses, please write a draft first and then start a separate thread somewhere. > > -d > From nobody Sun Jun 8 17:27:07 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999431B279A; Sun, 8 Jun 2014 17:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMd3QEqjuefq; Sun, 8 Jun 2014 17:27:04 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6A271B2799; Sun, 8 Jun 2014 17:27:04 -0700 (PDT) Received: from [192.168.1.91] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s590QD4Z010849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 8 Jun 2014 17:26:23 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=iso-8859-1 From: Joe Touch In-Reply-To: <5393119F.6050805@cs.tcd.ie> Date: Sun, 8 Jun 2014 17:26:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <82A0BCB8-F77C-4C8B-9769-BF4EE2F748A0@isi.edu> References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.2) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/aR-ibzWhkZ99_AF-1M21jO5UKFM Cc: "ietf-privacy@ietf.org" , Internet Area Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 00:27:05 -0000 On Jun 7, 2014, at 6:20 AM, Stephen Farrell = wrote: > NATs have both good and bad properties. The slightly better privacy > is one of the good ones. Better for the hosts they 'hide'; worse as a common network access = point. Consider an enterprise. There are two things we can learn about it from = IP addresses: - without a NAT, we learn about activity of individual hosts - with a NAT, we learn the common network access point If I want to track host activity - or attack a host, the former is = better. If I want to know what to DOS to take down the entire enterprise, the = latter is better. Think of it this way:=20 a NAT hides the host *at the expense* of exposing a router If we're serious about considering privacy issues, there's a LOT more = homework to be done. Joe From nobody Sun Jun 8 19:39:53 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E791E1B27B5 for ; Sun, 8 Jun 2014 19:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNDaAFKMT88o for ; Sun, 8 Jun 2014 19:39:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9B011B27B4 for ; Sun, 8 Jun 2014 19:39:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFF15510; Mon, 09 Jun 2014 02:39:46 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Jun 2014 03:39:45 +0100 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.43]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 9 Jun 2014 10:39:43 +0800 From: Xueli To: "mohamed.boucadair@orange.com" , "Suresh Krishnan" , Internet Area Thread-Topic: Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 Thread-Index: Ac+AdUkItwXlXKGCQeuKFKJeAHvWjgAPZSrgALZDlfA= Date: Mon, 9 Jun 2014 02:39:42 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B448FAF7DB@nkgeml504-mbx.china.huawei.com> References: <787AE7BB302AE849A7480A190F8B93300139E7@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300139E7@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.86] Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B448FAF7DBnkgeml504mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/exUtinvpIMa0Qdeo2MbleOwUXEQ Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 02:39:51 -0000 --_000_01FE63842C181246BBE4CF183BD159B448FAF7DBnkgeml504mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all I support the adoption of draft-boucadair-intarea-host-identifier-scenarios= -05 as an intarea WG document. Regards Li as co-author From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of mohamed.bouc= adair@orange.com Sent: Thursday, June 05, 2014 7:45 PM To: Suresh Krishnan; Internet Area Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-i= dentifier-scenarios-04 Hi Suresh, Thank you for initiating this call. FWIW, the latest version is -05 not -04: http://tools.ietf.org/html/draft-b= oucadair-intarea-host-identifier-scenarios-05. Unsurprisingly, I'm supportive to see this work adopted in intarea as a com= panion effort to RFC6269 and RFC6967. Cheers, Med De : Int-area [mailto:int-area-bounces@ietf.org] De la part de Suresh Krish= nan Envoy=E9 : jeudi 5 juin 2014 06:21 =C0 : Internet Area Objet : [Int-area] Call for adoption of draft-boucadair-intarea-host-identi= fier-scenarios-04 Hi all, This draft was originally intended to be published as an AD sponsored su= bmission from the OPS area, but the authors have expressed their interest t= o continue this work in the intarea wg given that RFC6269 and RFC6967 origi= nated here. The draft has been updated to address the issues brought up dur= ing earlier discussions on the wg mailing list and the latest version of th= e draft is available at http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenario= s-04 This call is being initiated to determine whether there is WG consensus tow= ards adoption of draft-boucadair-intarea-host-identifier-scenarios-04 as an= intarea WG draft. Please state whether or not you're in favor of the adopt= ion by replying to this email. If you are not in favor, please also state y= our objections in your response. This adoption call will complete on 2014-0= 6-19. Regards Suresh & Juan Carlos --_000_01FE63842C181246BBE4CF183BD159B448FAF7DBnkgeml504mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all

 

I support the adoption of draft-boucadair-intarea-host-identifier= -scenarios-05 as an intarea WG document.

 

Regards

Li as co-author

 

 

From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Thursday, June 05, 2014 7:45 PM
To: Suresh Krishnan; Internet Area
Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea= -host-identifier-scenarios-04

 

Hi Suresh,<= /p>

 

Thank you for initiating this= call.

 

FWIW, the latest version is -= 05 not -04: http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenario= s-05.

 

Unsurprisingly, I’m sup= portive to see this work adopted in intarea as a companion effort to RFC626= 9 and RFC6967.

 

Cheers,

Med

 

De : Int-area [mailto:int-area-bounces@ietf.org] De la part de Suresh Krishnan
Envoy=E9 : jeudi 5 juin 2014 06:21
=C0 : Internet Area
Objet : [Int-area] Call for adoption of draft-boucadair-intarea= -host-identifier-scenarios-04

 

Hi all,

   This draft was = originally intended to be published as an AD sponsored submission from the = OPS area, but the authors have expressed their interest to continue this wo= rk in the intarea wg given that RFC6269 and RFC6967 originated here. The draft has been updated to address the issues brought = up during earlier discussions on the wg mailing list and the latest version= of the draft is available at

 

http://tool= s.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04

 

This call is being initiated= to determine whether there is WG consensus towards adoption of draft-bouca= dair-intarea-host-identifier-scenarios-04 as an intarea WG draft. Please st= ate whether or not you're in favor of the adoption by replying to this email. If you are not in favor, please al= so state your objections in your response. This adoption call will complete= on 2014-06-19.

 

Regards

Suresh & Juan Carlos

 

--_000_01FE63842C181246BBE4CF183BD159B448FAF7DBnkgeml504mbxchi_-- From nobody Mon Jun 9 06:47:06 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53901A016B; Mon, 9 Jun 2014 06:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxT4H2qYsFXr; Mon, 9 Jun 2014 06:47:00 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC301A0164; Mon, 9 Jun 2014 06:47:00 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9F8D9285AB; Mon, 9 Jun 2014 13:46:59 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 82CA028596; Mon, 9 Jun 2014 13:46:59 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 791482026; Mon, 9 Jun 2014 13:46:59 +0000 (GMT) Message-ID: <5395BAD3.4040506@akamai.com> Date: Mon, 09 Jun 2014 09:46:59 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Stephen Farrell , Dan Wing References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> In-Reply-To: <5393119F.6050805@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/chjeyy2XNav9OpxzK4aJsIkfpfA Cc: "ietf-privacy@ietf.org" , Internet Area Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 13:47:02 -0000 Hi Stephen, On 06/07/2014 09:20 AM, Stephen Farrell wrote: > Adding new identifiers with privacy impact, as proposed here, is > quite different. It is not the intention of the authors for this to be a solution draft. The draft is intended to describe address sharing use cases and deployment scenarios. Would you please indicate where the draft proposes a new identifier? If you are seeing a proposal for protocol changes somewhere in the draft, editing work is required in order to either clarify or excise the associated text. Thanks, --Brandon On 06/07/2014 09:20 AM, Stephen Farrell wrote: > > Hi Dan, > > On 07/06/14 02:38, Dan Wing wrote: >> >> Stephen, >> >> It seems NAPT has become IETF's privacy feature of 2014 because >> multiple users are sharing one identifier (IP address and presumably >> randomized ports [RFC6056], although many NAPT deployments use >> address ranges because of fear of compressing log files). As a >> former co-chair of BEHAVE it is refreshing to see the IETF embracing >> NAPT as a desirable feature. > > Embracing seems like significant overstatement to me, but maybe > that's understandable given how calmly NAT is generally debated. > > NATs have both good and bad properties. The slightly better privacy > is one of the good ones. > > Recognising that reality is neither embracing nor refreshing IMO, > nor does it mean NAPT is (un)desirable overall. (That's an argument > I only ever watch from the side-lines thanks:-) > >> However, if NAPT provides privacy and NAT Reveal removes it, where >> does that leave a host's IPv6 source address with respect to BCP188? >> >> Afterall, an IPv6 address is quite traceable, even with IPv6 privacy >> addresses (especially as IPv6 privacy addresses are currently >> deployed which only obtain a new IPv6 privacy address every 24 hours >> or when attaching to a new network). If BCP188 does not prevent >> deployment of IPv6, I would like to understand the additional privacy >> leakage of IPv4+NAT+NAT_Reveal compared to the privacy leakage of >> IPv6+privacy_address. > > I'm frankly amazed that that's not crystal clear to anyone who > has read all 2.5 non-boilerplate pages of the BCP. Or even just > the last two words of the 1-line abstract (hint: those say "where > possible.") > > Yes, source addresses leak information that affects privacy. But > we do not have a practical way to mitigate that. So therefore > BCP188 does not call for doing stupid stuff, nor for new laws of > physics (unlike -04 of the draft we're discussing;-) > > Adding new identifiers with privacy impact, as proposed here, is > quite different. > > S. > > PS: If someone wants to propose what they think is a practical > way to mitigate the privacy issues with source addresses, please > write a draft first and then start a separate thread somewhere. > > >> >> -d >> > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Jun 9 07:01:25 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5231A017A; Mon, 9 Jun 2014 07:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nrv7TCI2lNqB; Mon, 9 Jun 2014 07:01:16 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5C81A017B; Mon, 9 Jun 2014 07:01:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 69AC3BE97; Mon, 9 Jun 2014 15:01:15 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKFLvIWC0MaF; Mon, 9 Jun 2014 15:01:14 +0100 (IST) Received: from [172.16.23.144] (217.64.246.155.mactelecom.net [217.64.246.155]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4E674BE79; Mon, 9 Jun 2014 15:01:14 +0100 (IST) Message-ID: <5395BE2A.6090708@cs.tcd.ie> Date: Mon, 09 Jun 2014 15:01:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brandon Williams , Dan Wing References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> <5395BAD3.4040506@akamai.com> In-Reply-To: <5395BAD3.4040506@akamai.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/e8USU_IA0Ph5aj320GoxCH48oxA Cc: "ietf-privacy@ietf.org" , Internet Area Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 14:01:18 -0000 On 09/06/14 14:46, Brandon Williams wrote: > > Would you please indicate where the draft proposes a new identifier? If > you are seeing a proposal for protocol changes somewhere in the draft, > editing work is required in order to either clarify or excise the > associated text. Fair enough that its an assumption of mine that adding some kind of identifier is required to meet the (no-longer mis-stated:-) requirements for these use-cases. But I think that is logically required, and its valid to draw obvious conclusions and its also invalid to ignore obvious conclusions. S. From nobody Mon Jun 9 07:36:09 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7151A01A0; Mon, 9 Jun 2014 07:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjQODoC-4yoO; Mon, 9 Jun 2014 07:36:06 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5A61A0198; Mon, 9 Jun 2014 07:36:06 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D0B664745E; Mon, 9 Jun 2014 14:36:04 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id C35504751A; Mon, 9 Jun 2014 14:36:04 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id AD9E22027; Mon, 9 Jun 2014 14:36:04 +0000 (GMT) Message-ID: <5395C654.1060800@akamai.com> Date: Mon, 09 Jun 2014 10:36:04 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Stephen Farrell , Dan Wing References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> <5395BAD3.4040506@akamai.com> <5395BE2A.6090708@cs.tcd.ie> In-Reply-To: <5395BE2A.6090708@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/NCjT-X-UcO1k1ZtzWW2Bd2_mJqg Cc: "ietf-privacy@ietf.org" , Internet Area Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 14:36:07 -0000 I agree that the discussions in this draft and rfc6269 at least imply that potential solutions would provide a host identifier of some sort. However, this draft does not in fact propose any such solution, and instead clearly references rfc6967, which includes a discussion of the privacy implications of host identification. In particular, that document states: HOST_ID specification document(s) should explain the privacy impact of the solutions they specify, including the extent of HOST_ID uniqueness and persistence, assumptions made about the lifetime of the HOST_ID, whether and how the HOST_ID can be obfuscated or recycled, whether location information can be exposed, and the impact of the use of the HOST_ID on device or implementation fingerprinting. [IAB-PRIVACY] provides further guidance. Considering the fact that there is already a separate solution analysis rfc that discusses privacy considerations and provides the above guidance for authors of solution drafts, what are you suggesting for the use cases draft? Thanks, --Brandon On 06/09/2014 10:01 AM, Stephen Farrell wrote: > > > On 09/06/14 14:46, Brandon Williams wrote: >> >> Would you please indicate where the draft proposes a new identifier? If >> you are seeing a proposal for protocol changes somewhere in the draft, >> editing work is required in order to either clarify or excise the >> associated text. > > Fair enough that its an assumption of mine that adding some kind of > identifier is required to meet the (no-longer mis-stated:-) > requirements for these use-cases. But I think that is logically > required, and its valid to draw obvious conclusions and its also > invalid to ignore obvious conclusions. > > S. > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Jun 9 07:40:45 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D751A01DC; Mon, 9 Jun 2014 07:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3MAByE9Jgya; Mon, 9 Jun 2014 07:40:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB9F1A01D9; Mon, 9 Jun 2014 07:40:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AD7E3BE7C; Mon, 9 Jun 2014 15:40:41 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lTgxLRJQ3kZ; Mon, 9 Jun 2014 15:40:40 +0100 (IST) Received: from [172.16.23.144] (217.64.246.155.mactelecom.net [217.64.246.155]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9D047BE49; Mon, 9 Jun 2014 15:40:40 +0100 (IST) Message-ID: <5395C768.8050401@cs.tcd.ie> Date: Mon, 09 Jun 2014 15:40:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brandon Williams , Dan Wing References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> <5395BAD3.4040506@akamai.com> <5395BE2A.6090708@cs.tcd.ie> <5395C654.1060800@akamai.com> In-Reply-To: <5395C654.1060800@akamai.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/yePNsY9uLeB7iFyOov19DXQjrG4 Cc: "ietf-privacy@ietf.org" , Internet Area Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 14:40:44 -0000 Hiya, On 09/06/14 15:36, Brandon Williams wrote: > what are you suggesting for the use cases draft? I thought I was clear. My suggestion is to not adopt it. S. From nobody Mon Jun 9 07:43:03 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D3A1A016C for ; Mon, 9 Jun 2014 06:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOHnhbr2pcXl for ; Mon, 9 Jun 2014 06:34:55 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F6E1A016B for ; Mon, 9 Jun 2014 06:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1402320894; x=2266234494; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QnbRHygrfiJK74Hh1uWrA41qTXFc1h7KevMfV/Wx18k=; b=v/rzA4w4x+MIo5ojxMXpMSwB1iT5tz759Z0Jkhb/SQeTeBq7bH0sl29ksnMNZouq 9A4BJcDeVXooGyrjkR9YBOxQ00FdENCJTNH3KlQyn/10jK7Ic16iZM/ZAJUIeCSn LctZ/lfrLQm6qNogr9Tl86DYWowSD7NNUh+tKmjzhtHXOitT+/klTC6fnsdIzDmK Ud97HafJJE2BoBtR5/173wOTTX8Ts/upkPvMnQDKAjng8v16cFxcyzgYt2UvfaZB r1WWwWR4u4laznj9Mzqy7WWt6pCoeklcxp+1sAK+k2bx/Sitw9kzmEE7ZQrmHSAY FIYSX48Q42IY1y0E0t0kTQ==; Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 10.BF.08063.EF7B5935; Mon, 9 Jun 2014 06:34:54 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay4.apple.com ([17.128.113.87]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N6W00FM0LP1DA51@local.mail-out.apple.com>; Mon, 09 Jun 2014 06:34:54 -0700 (PDT) X-AuditID: 11973e13-f79d56d000001f7f-ca-5395b7fe88c7 Received: from fenugreek.apple.com (fenugreek.apple.com [17.128.115.97]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id C9.C5.03493.108B5935; Mon, 9 Jun 2014 06:34:57 -0700 (PDT) Received: from [17.153.19.22] (unknown [17.153.19.22]) by fenugreek.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0N6W00MVZLQ38F60@fenugreek.apple.com>; Mon, 09 Jun 2014 06:34:54 -0700 (PDT) From: David Singer In-reply-to: <82A0BCB8-F77C-4C8B-9769-BF4EE2F748A0@isi.edu> Date: Mon, 09 Jun 2014 09:34:51 -0400 Message-id: <747229F0-D5EB-4262-B14C-46C860F9165C@apple.com> References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> <82A0BCB8-F77C-4C8B-9769-BF4EE2F748A0@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1878.2) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUiON3OWPff9qnBBqsOm1ocvtrAbnFj1k0W ByaPJUt+MgUwRnHZpKTmZJalFunbJXBlrJmdV7CXqWLBjfvMDYxfGbsYOTkkBEwkJm6aB2WL SVy4t56ti5GLQ0hgDpNEz9s+sASvgKDEj8n3WLoYOTiYBeQlDp6XBQkzC2hJfH/UygJR38Qk MfHjOTaYoU2TPrJDJCYzSdy7tRRqaiOTxN9zu5lAJgkLuErM/Z8M0sAmoCrxYM4xsGWcAtYS jR83sYDYLEDxo2degw1iFmhnlLjUcYQJ4iIbiYdrDjFCDF3MJPFibTfYahEBWYnG3d9YIc6Q l5jRfgKsW0LgN6vEz+sfmCcwisxC8tIshJdmIXlpASPzKkah3MTMHN3MPFO9xIKCnFS95Pzc TYyQUBfewXh6ldUhRgEORiUe3ojfU4KFWBPLiitzDzFKc7AoifMyFEwKFhJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cAYvMDrxaTrd0rvKCZzGYoejnpsOMex4n5dqMmxpWLAGA2UfnVNzt3m 5DrxqL/6v7NXfP/GJSg26Zvvyqf9i07nLrcwl0h5L1ymEc967fDGyb1KqplHP6/QtGCxnaIX pP5AqPv3KZbO7+fOvEmccHUB17zdUw7YBPpXTJw1vd5vln/f0skmt4KVWIozEg21mIuKEwE5 imsFVgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUi2FCcqMu4Y2qwQfM8FovDVxvYLW7Musni wOSxZMlPpgDGKC6blNSczLLUIn27BK6Mb1uvMhYcYKp413WXqYHxG2MXIyeHhICJRNOkj+wQ tpjEhXvr2UBsIYHJTBJdewq7GLmA7EYmib/ndjOBJJgFtCTW7zwOZvMKGEi8OQhic3AIC7hK zP2fDBJmE1CVeDDnGNh8TgFricaPm1hAbBag+NEzr9lBZjILtDNKXOo4AjVTW+LJuwusEDNt JB6uOcQIsXgxk8SLtd1gF4kIyEo07v7GCnGpvMSM9hPsExgFZiG5aRaSm2YhmbuAkXkVo0BR ak5ipYleYkFBTqpecn7uJkZwEBaG72D8t8zqEKMAB6MSD2/E7ynBQqyJZcWVuYcYJTiYlUR4 O9ZPDRbiTUmsrEotyo8vKs1JLT7EKM3BoiTOK757QrCQQHpiSWp2ampBahFMlomDU6qB8eTB iUzscz0aPuzMubLkz85Tx23N58arf3bMql17cVV67rbqR3Pe7rba+cL1cvWzZT+yhCsYa97K n2hewdoX3zP37IU97ZLGK97/8DzIsNNzVXvgDGHBg7m8t7vL7K4fbdS8tlOn3v/r5g3bZP9L yvQceR728qZa6lOjq02hjHM0jb52FBYcW6HEUpyRaKjFXFScCACemg3vPgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/TfXBM5OzA30AkCDgt8kh2nwiF5o X-Mailman-Approved-At: Mon, 09 Jun 2014 07:42:54 -0700 Cc: "ietf-privacy@ietf.org" , Internet Area , Stephen Farrell Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 13:34:57 -0000 On Jun 8, 2014, at 20:26 , Joe Touch wrote: > a NAT hides the host *at the expense* of exposing a router If I have the energy to do a DoS attack, surely I have the energy to traceroute the hosts I know to find a common routing point? David Singer Manager, Software Standards, Apple Inc. From nobody Mon Jun 9 08:31:03 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FC01A01D9; Mon, 9 Jun 2014 08:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18KHlf-nT8kY; Mon, 9 Jun 2014 08:31:01 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08ADC1A0068; Mon, 9 Jun 2014 08:31:01 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s59FUUpp009409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Jun 2014 08:30:33 -0700 (PDT) Message-ID: <5395D318.4000907@isi.edu> Date: Mon, 09 Jun 2014 08:30:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: David Singer References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> <82A0BCB8-F77C-4C8B-9769-BF4EE2F748A0@isi.edu> <747229F0-D5EB-4262-B14C-46C860F9165C@apple.com> In-Reply-To: <747229F0-D5EB-4262-B14C-46C860F9165C@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/hPZaqpBAwa8-2IalASItKIIlu48 Cc: "ietf-privacy@ietf.org" , Internet Area , Stephen Farrell Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 15:31:02 -0000 On 6/9/2014 6:34 AM, David Singer wrote: > > On Jun 8, 2014, at 20:26 , Joe Touch wrote: > >> a NAT hides the host *at the expense* of exposing a router > > If I have the energy to do a DoS attack, surely I have the energy to > traceroute the hosts I know to find a common routing point? 1) ICMPs are often blocked - either at network boundaries or inside routers themselves 2) an ICMP tells you only how your packets get to the destination; it says nothing about how other traffic gets there or the return path A NAT address tells you both directions and *cannot* be hidden except by another NAT along the same path. Joe > > David Singer > Manager, Software Standards, Apple Inc. > From nobody Mon Jun 9 09:32:27 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849951A0264; Mon, 9 Jun 2014 09:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrqSeXJ75Zi4; Mon, 9 Jun 2014 09:32:24 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 815EF1A0257; Mon, 9 Jun 2014 09:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4540; q=dns/txt; s=iport; t=1402331543; x=1403541143; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Y0e/Y6IB7c4ye31/W0rroDAI3/MGYnsh6880j/bFqlI=; b=amtZoZYqsdqx7xpmp/gMP7IC7BXTg6tcR7R5we7hBBTO5yvLrHDqORlG +7ZFV47O25JfkW1pgDbtmbCR9ipKyME1erTXA3k9e1tc77JW1Zy69kEu8 WmIupS29OgiNoOFu8wCdYf0ZeVDnJ/qjsXhzWhr9cfjrzBUELI3+FYZHn M=; X-IronPort-AV: E=Sophos;i="4.98,1003,1392163200"; d="scan'208,217";a="79655676" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 09 Jun 2014 16:32:22 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM ([10.61.203.105]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s59GWLX3023173; Mon, 9 Jun 2014 16:32:21 GMT Message-ID: <5395E195.4080007@cisco.com> Date: Mon, 09 Jun 2014 18:32:21 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Stephen Farrell , Dan Wing References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> In-Reply-To: <5393119F.6050805@cs.tcd.ie> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------060505040501030907000309" Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/GoaEK6oSmd_MGNcYZL2uU94rNcs Cc: "ietf-privacy@ietf.org" , Internet Area Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 16:32:25 -0000 This is a multi-part message in MIME format. --------------060505040501030907000309 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Stephen, On 6/7/14, 3:20 PM, Stephen Farrell wrote: > I'm frankly amazed that that's not crystal clear to anyone who > has read all 2.5 non-boilerplate pages of the BCP. Or even just > the last two words of the 1-line abstract (hint: those say "where > possible.") > > Yes, source addresses leak information that affects privacy. But > we do not have a practical way to mitigate that. So therefore > BCP188 does not call for doing stupid stuff, nor for new laws of > physics (unlike -04 of the draft we're discussing;-) > > Adding new identifiers with privacy impact, as proposed here, is > quite different. This came up today in a discussion around spam and cybersecurity with at least one major service provider who has some pretty sophisticated cbyersecurity systems. Someone mentioned CGN and how entire groups of customers are blocked when a single IP address goes bad. We even experienced this on the IAB, by the way, when its MSP got blocked by an anti-spam site due to presumably someone else misusing them. Our architecture isn't really set up for IP address sharing or hiding. If your source address is naughty, the only back pressure I have at my disposal is to block it. If enough in an address range are bad, I might block a range, even if that means some small amount of good mail being blocked. Go to a lousy SP and this is what it gets you. But does adding a header solve the problem? Not unless it is signed AND I believe the signature. And then I had better be willing to spend the processing time to sort out your good customers from your bad customers. I *might* do that if you're at a very big mail service provider, in which case I probably get very little spam, anyway. I probably won't do that if you're Joe's small time ISP, unless there is some scaling feature not yet deployed today. Eliot --------------060505040501030907000309 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Stephen,

On 6/7/14, 3:20 PM, Stephen Farrell wrote:

I'm frankly amazed that that's not crystal clear to anyone who
has read all 2.5 non-boilerplate pages of the BCP. Or even just
the last two words of the 1-line abstract (hint: those say "where
possible.")

Yes, source addresses leak information that affects privacy. But
we do not have a practical way to mitigate that. So therefore
BCP188 does not call for doing stupid stuff, nor for new laws of
physics (unlike -04 of the draft we're discussing;-)

Adding new identifiers with privacy impact, as proposed here, is
quite different.

This came up today in a discussion around spam and cybersecurity with at least one major service provider who has some pretty sophisticated cbyersecurity systems.  Someone mentioned CGN and how entire groups of customers are blocked when a single IP address goes bad.  We even experienced this on the IAB, by the way, when its MSP got blocked by an anti-spam site due to presumably someone else misusing them.  Our architecture isn't really set up for IP address sharing or hiding.  If your source address is naughty, the only back pressure I have at my disposal is to block it.  If enough in an address range are bad, I might block a range, even if that means some small amount of good mail being blocked.  Go to a lousy SP and this is what it gets you.

But does adding a header solve the problem?  Not unless it is signed AND I believe the signature.  And then I had better be willing to spend the processing time to sort out your good customers from your bad customers.  I might do that if you're at a very big mail service provider, in which case I probably get very little spam, anyway.  I probably won't do that if you're Joe's small time ISP, unless there is some scaling feature not yet deployed today.

Eliot
--------------060505040501030907000309-- From nobody Mon Jun 9 09:43:55 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FE01A01EA; Mon, 9 Jun 2014 09:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6T9-ucHtwHA; Mon, 9 Jun 2014 09:43:51 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92951A01EF; Mon, 9 Jun 2014 09:43:51 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id ABF551B8032; Mon, 9 Jun 2014 09:43:51 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 9E7B7190064; Mon, 9 Jun 2014 09:43:51 -0700 (PDT) Received: from [10.0.10.40] (174.62.147.182) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Jun 2014 09:43:51 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <5395E195.4080007@cisco.com> Date: Mon, 9 Jun 2014 12:43:47 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> <5395E195.4080007@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [174.62.147.182] Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/U5kP50rZFvlarsCNP7OcopUiTZI Cc: "ietf-privacy@ietf.org" , Internet Area , Stephen Farrell Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 16:43:55 -0000 On Jun 9, 2014, at 12:32 PM, Eliot Lear wrote: > But does adding a header solve the problem? Not unless it is signed = AND I believe the signature. And then I had better be willing to spend = the processing time to sort out your good customers from your bad = customers. I might do that if you're at a very big mail service = provider, in which case I probably get very little spam, anyway. I = probably won't do that if you're Joe's small time ISP, unless there is = some scaling feature not yet deployed today. Bingo. From nobody Mon Jun 9 12:08:17 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE0D1A02CE; Mon, 9 Jun 2014 12:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhHicYd8Xbwj; Mon, 9 Jun 2014 12:08:12 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67CF91A029F; Mon, 9 Jun 2014 12:08:12 -0700 (PDT) Received: from mbp.local (31.66.208.web-pass.com [208.66.31.202] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s59J6Cs3001227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Jun 2014 19:06:12 GMT (envelope-from joelja@bogus.com) Message-ID: <5395EBE3.3030408@bogus.com> Date: Mon, 09 Jun 2014 10:16:19 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0 MIME-Version: 1.0 To: Stephen Farrell , Brandon Williams , Dan Wing References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> <5395BAD3.4040506@akamai.com> <5395BE2A.6090708@cs.tcd.ie> In-Reply-To: <5395BE2A.6090708@cs.tcd.ie> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TOmxHNR2EjEGCDosKdeWOu7aWFuRa5ruF" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 09 Jun 2014 19:06:15 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/SmGVqyP-CgmARXaqP3N4nriFie0 Cc: "ietf-privacy@ietf.org" , Internet Area Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 19:08:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TOmxHNR2EjEGCDosKdeWOu7aWFuRa5ruF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 6/9/14, 7:01 AM, Stephen Farrell wrote: >=20 >=20 > On 09/06/14 14:46, Brandon Williams wrote: >> >> Would you please indicate where the draft proposes a new identifier? I= f >> you are seeing a proposal for protocol changes somewhere in the draft,= >> editing work is required in order to either clarify or excise the >> associated text. There are 6 citations of http://tools.ietf.org/html/rfc6967 the document doesn't exist in a vacuum where somehow how to do it has fallen off the table. given the repeated asertion that this work is useful because of external requests (etsi) and that request is in fact tied closely to a particular method it is relatively strait forward to conflate the discussion of scenarios and methods. > Fair enough that its an assumption of mine that adding some kind of > identifier is required to meet the (no-longer mis-stated:-) > requirements for these use-cases. But I think that is logically > required, and its valid to draw obvious conclusions and its also > invalid to ignore obvious conclusions. > S. >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >=20 --TOmxHNR2EjEGCDosKdeWOu7aWFuRa5ruF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOV6+MACgkQ8AA1q7Z/VrJlowCfdpZ6NkjmzcqmvzVef8EUiHNF 30oAoIib3Ln3hD0+llN+5rH0nqcjVCWz =I/o9 -----END PGP SIGNATURE----- --TOmxHNR2EjEGCDosKdeWOu7aWFuRa5ruF-- From nobody Mon Jun 9 13:11:10 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B5C1A02F4; Mon, 9 Jun 2014 13:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oC9O0SYLaWUw; Mon, 9 Jun 2014 13:10:58 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16BD21A02EE; Mon, 9 Jun 2014 13:10:58 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id fp1so5247781pdb.17 for ; Mon, 09 Jun 2014 13:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vVi6PbL5lP2amKnWh2I+Q8GWFQcUKJVxk3HtcoNeTRU=; b=KBUaw7xXLQXEuUcu2sOlsdZiM8VZJe64B0Tmo2SkPlphZeNSO+Xgu/RreaZb2bD//M CQxwGgB2TamByTPG4JYoeLfSBiOfFANHPlYhuvlTx6+JnTY75kwH1FaidxHM2s3Sa90v dBaL3vy+vITbaDGuv0CAjWISvYMqIEIAQRE5ZSYae+kjTIYBHlLGBBQzBSds+na9vcEl B7iytP4uoUHm4eFlAsjYin3WmhPMLvJ53rw8NIMBXANmYzvJp2lQWfmfDJFcOoFHjxr+ ZP5AWT7kxbUicDJ3BZ3F/IVmjPHCl+4gJVo91q61D3tOaZ+ewVPi0NxvinM9euu7KIcx 1blA== X-Received: by 10.69.19.140 with SMTP id gu12mr6808736pbd.111.1402344657774; Mon, 09 Jun 2014 13:10:57 -0700 (PDT) Received: from [192.168.178.23] (98.197.69.111.dynamic.snap.net.nz. [111.69.197.98]) by mx.google.com with ESMTPSA id it4sm65506379pbc.39.2014.06.09.13.10.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 13:10:57 -0700 (PDT) Message-ID: <539614C9.9050308@gmail.com> Date: Tue, 10 Jun 2014 08:10:49 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> <5395E195.4080007@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/RVRVBZ4VTScs_Q8rth1eEq8xdpk Cc: "ietf-privacy@ietf.org" , Internet Area , Stephen Farrell Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 20:11:06 -0000 On 10/06/2014 04:43, Ted Lemon wrote: > On Jun 9, 2014, at 12:32 PM, Eliot Lear wrote: >> But does adding a header solve the problem? Not unless it is signed AND I believe the signature. And then I had better be willing to spend the processing time to sort out your good customers from your bad customers. I might do that if you're at a very big mail service provider, in which case I probably get very little spam, anyway. I probably won't do that if you're Joe's small time ISP, unless there is some scaling feature not yet deployed today. > > Bingo. So, there are some more components of the threat analysis and the solution requirements. That's good, but I thought we were discussing whether to document the use cases. Brian From nobody Mon Jun 9 13:19:58 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6127D1A02F2; Mon, 9 Jun 2014 13:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S-Gqp-NJkFN; Mon, 9 Jun 2014 13:19:54 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECE721A0300; Mon, 9 Jun 2014 13:19:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1128; q=dns/txt; s=iport; t=1402345194; x=1403554794; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=w0KDg57jFBr0aiYdSrqdOhmn48Joy0jkAYbC+WmdhLo=; b=T24cDLXM3uIx6y1E6xxY/zpmBBgXgJK170pv11iPLmi5Q8TeWg5kbvIO IQNdJVjrpHPLQ13s8zZhhy9V7duyO1W9Tz+gtme7DdfOwkOqIvVK80HUa Um/AF5Pmr9p3L95KNgp5IREbfrSZ0fKrMnuRQ0DJHDLTVBqdiH0BgixGI k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIKAJQVllOtJssW/2dsb2JhbABZg1+DRad1AQEBAQEBBQGZEAGBKHWEAwEBAQQjVQEQCxgCAgUWCwICCQMCAQIBRQYBDAEFAgEBF4gnrC6fGReBKoQziD4BAU8HgnWBTAEDmiGTRYM+O4E5 X-IronPort-AV: E=Sophos;i="4.98,1003,1392163200"; d="scan'208";a="80500714" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 09 Jun 2014 20:19:52 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM ([10.61.201.68]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s59KJpBa028030; Mon, 9 Jun 2014 20:19:51 GMT Message-ID: <539616E7.6060305@cisco.com> Date: Mon, 09 Jun 2014 22:19:51 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brian E Carpenter , Ted Lemon References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> <5395E195.4080007@cisco.com> <539614C9.9050308@gmail.com> In-Reply-To: <539614C9.9050308@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/u_y-rxfmxVRNTXZDYKanseA85R0 Cc: "ietf-privacy@ietf.org" , Internet Area , Stephen Farrell Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 20:19:56 -0000 Just to be clear: that was SMTP. The calculus can be different for other protocols, depending on their end to end nature. SMTP is very hop by hop and it is very difficult to secure an entire path with confidence due to downgrade attack threats. https would be a horse of a different color. On 6/9/14, 10:10 PM, Brian E Carpenter wrote: > On 10/06/2014 04:43, Ted Lemon wrote: >> On Jun 9, 2014, at 12:32 PM, Eliot Lear wrote: >>> But does adding a header solve the problem? Not unless it is signed AND I believe the signature. And then I had better be willing to spend the processing time to sort out your good customers from your bad customers. I might do that if you're at a very big mail service provider, in which case I probably get very little spam, anyway. I probably won't do that if you're Joe's small time ISP, unless there is some scaling feature not yet deployed today. >> Bingo. > So, there are some more components of the threat analysis and the solution > requirements. That's good, but I thought we were discussing whether > to document the use cases. > > Brian > > From nobody Mon Jun 9 14:47:13 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566FD1A0347; Mon, 9 Jun 2014 14:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScGfLY49Fuzk; Mon, 9 Jun 2014 14:47:09 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923141A0330; Mon, 9 Jun 2014 14:47:09 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6FEED1B81BA; Mon, 9 Jun 2014 14:47:09 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 60D93190064; Mon, 9 Jun 2014 14:47:09 -0700 (PDT) Received: from [10.0.10.40] (174.62.147.182) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Jun 2014 14:47:09 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: <539614C9.9050308@gmail.com> Date: Mon, 9 Jun 2014 17:47:05 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> <5395E195.4080007@cisco.com> <539614C9.9050308@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [174.62.147.182] Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/4_ufes4GjrLExzVPM1bal3bi9Jw Cc: "ietf-privacy@ietf.org" , Internet Area , Stephen Farrell Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 21:47:11 -0000 On Jun 9, 2014, at 4:10 PM, Brian E Carpenter = wrote: > I thought we were discussing whether > to document the use cases. Is there some value in documenting the use cases? Do people have = plans? From nobody Tue Jun 10 03:30:59 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0AB31A04F6; Tue, 10 Jun 2014 03:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQRAnVyb_Yuv; Tue, 10 Jun 2014 03:30:54 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E21F81A002A; Tue, 10 Jun 2014 03:30:53 -0700 (PDT) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 10 Jun 2014 12:30:51 +0200 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by he110890 ([10.134.92.131]) with mapi; Tue, 10 Jun 2014 12:30:50 +0200 From: To: , , , Date: Tue, 10 Jun 2014 12:30:46 +0200 Thread-Topic: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers Thread-Index: Ac+EFjUJwii/Fz27Ro+jpZhjUs3c3wAd1VPg Message-ID: <05C81A773E48DD49B181B04BA21A342A2E0071B529@HE113484.emea1.cds.t-internal.com> References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> <5395BAD3.4040506@akamai.com> <5395BE2A.6090708@cs.tcd.ie> <5395EBE3.3030408@bogus.com> In-Reply-To: <5395EBE3.3030408@bogus.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/tbgRxxZaw8BHeZb62C3lyyXqiug Cc: ietf-privacy@ietf.org, int-area@ietf.org Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 10:30:58 -0000 Dear all, I would like to confirm this: As already pointed out by Bruno in http://www= .ietf.org/mail-archive/web/int-area/current/msg03904.html there is the emer= gency call use case at ETSI and beside that there are application proposals= within WGs SFC, TCPM, etc. beside other drafts which refer to RFC 6967. And although I might repeat again what has been stated many times: Intended= goal is and should be to find a solution to fulfil dedicated and real use = cases demands - respecting privacy, reducing vulnerability, strengthening p= rotection against misuse as mentioned in BCP188, and so on ... Best regards Dirk=20 -----Original Message----- From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of joel jaeggli Sent: Montag, 9. Juni 2014 19:16 To: Stephen Farrell; Brandon Williams; Dan Wing Cc: ietf-privacy@ietf.org; Internet Area Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers On 6/9/14, 7:01 AM, Stephen Farrell wrote: >=20 >=20 > On 09/06/14 14:46, Brandon Williams wrote: >> >> Would you please indicate where the draft proposes a new identifier?=20 >> If you are seeing a proposal for protocol changes somewhere in the=20 >> draft, editing work is required in order to either clarify or excise=20 >> the associated text. There are 6 citations of http://tools.ietf.org/html/rfc6967 the document doesn't exist in a vacuum where somehow how to do it has falle= n off the table. given the repeated asertion that this work is useful because of external re= quests (etsi) and that request is in fact tied closely to a particular meth= od it is relatively strait forward to conflate the discussion of scenarios = and methods. > Fair enough that its an assumption of mine that adding some kind of=20 > identifier is required to meet the (no-longer mis-stated:-)=20 > requirements for these use-cases. But I think that is logically=20 > required, and its valid to draw obvious conclusions and its also=20 > invalid to ignore obvious conclusions. > S. >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >=20 From nobody Wed Jun 11 05:21:16 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19AA1B2885 for ; Wed, 11 Jun 2014 05:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIhj8JFxwlGJ for ; Wed, 11 Jun 2014 05:21:09 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F8EC1B2889 for ; Wed, 11 Jun 2014 05:21:08 -0700 (PDT) Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 11 Jun 2014 14:20:56 +0200 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113656.emea1.cds.t-internal.com ([10.134.99.16]) with mapi; Wed, 11 Jun 2014 14:20:56 +0200 From: To: Date: Wed, 11 Jun 2014 14:20:52 +0200 Thread-Topic: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 Thread-Index: Ac+BoA8Lb6IcAswyTQ2HtmarNXa9BwDzjrJw Message-ID: <05C81A773E48DD49B181B04BA21A342A2E00822ECD@HE113484.emea1.cds.t-internal.com> References: <8498_1402058854_5391B866_8498_13481_1_88CAD1D4E8773F42858B58CAA28272A014530EF1@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/IWQU3zpdRuC1hKrpUDPQy0gb0_c Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 12:21:13 -0000 RGVhciBhbGwsDQpDb25zaWRlcmluZyB0aGUgY3VycmVudCBkaXNjdXNzaW9uIG9uIHByb3MgYW5k IGNvbnMgSSB0aGluayB0aGUgdG9waWMgb2YgTkFUIHJldmVhbCBhbmQgSG9zdF9JZCBpbiB0ZXJt cyBvZiBwcm9ibGVtIHN0YXRlbWVudHMgYW5kIHJlcXVpcmVtZW50cyB0b3dhcmRzIGEgc29sdXRp b24gc3BhY2UgaW5kZWVkIG5lZWRzIHRvIGJlIGFzc2Vzc2VkIGluIGZ1cnRoZXIgZGV0YWlsIC0g ZXNwZWNpYWxseSBzaW5jZSB0aGVyZSBhcmUgYWN0dWFsIHVzZSBjYXNlcyBpbiBoZXRlcm9nZW5l b3VzIGFjY2VzcyBhbmQgdHJhbnNwb3J0IGRvbWFpbnMgc3VjaCBhcyBwb2xpY3kgYXNzaWdubWVu dCwgZW1lcmdlbmN5IGNhbGxzLCBmdW5jdGlvbiBjaGFpbmluZywgY29udGVudCBzdHJlYW1pbmcg ZXRjLiBwcC4gDQogDQpTaW5jZSBJbnRBcmVhIFdHIElNTyBzZWVtcyB0byBiZSBhIHByb3BlciBk aXNjdXNzaW9uIGFyZW5hIEkgYW0gaW4gZmF2b3Igb2YgYWRvcHRpbmcgdGhlIGRyYWZ0Lg0KDQpC ZXN0IHJlZ2FyZHMNCkRpcmsNCg0KPiBEZSA6IEludC1hcmVhIFttYWlsdG86aW50LWFyZWEtYm91 bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBTdXJlc2ggDQo+IEtyaXNobmFuIEVudm95w6kg OiBqZXVkaSA1IGp1aW4gMjAxNCAwNjoyMSDDgCA6IEludGVybmV0IEFyZWEgT2JqZXQgOiANCj4g W0ludC1hcmVhXSBDYWxsIGZvciBhZG9wdGlvbiBvZiANCj4gZHJhZnQtYm91Y2FkYWlyLWludGFy ZWEtaG9zdC1pZGVudGlmaWVyLXNjZW5hcmlvcy0wNA0KPg0KPiBIaSBhbGwsDQo+ICAgIFRoaXMg ZHJhZnQgd2FzIG9yaWdpbmFsbHkgaW50ZW5kZWQgdG8gYmUgcHVibGlzaGVkIGFzIGFuIEFEIA0K PiBzcG9uc29yZWQgc3VibWlzc2lvbiBmcm9tIHRoZSBPUFMgYXJlYSwgYnV0IHRoZSBhdXRob3Jz IGhhdmUgZXhwcmVzc2VkIA0KPiB0aGVpciBpbnRlcmVzdCB0byBjb250aW51ZSB0aGlzIHdvcmsg aW4gdGhlIGludGFyZWEgd2cgZ2l2ZW4gdGhhdCANCj4gUkZDNjI2OSBhbmQgUkZDNjk2NyBvcmln aW5hdGVkIGhlcmUuIFRoZSBkcmFmdCBoYXMgYmVlbiB1cGRhdGVkIHRvIA0KPiBhZGRyZXNzIHRo ZSBpc3N1ZXMgYnJvdWdodCB1cCBkdXJpbmcgZWFybGllciBkaXNjdXNzaW9ucyBvbiB0aGUgd2cg DQo+IG1haWxpbmcgbGlzdCBhbmQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBpcyBh dmFpbGFibGUgYXQNCj4NCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm91Y2Fk YWlyLWludGFyZWEtaG9zdC1pZGVudGlmaWVyLXNjZQ0KPiBuYXJpb3MtMDQNCj4NCj4gVGhpcyBj YWxsIGlzIGJlaW5nIGluaXRpYXRlZCB0byBkZXRlcm1pbmUgd2hldGhlciB0aGVyZSBpcyBXRyBj b25zZW5zdXMgdG93YXJkcyBhZG9wdGlvbiBvZiBkcmFmdC1ib3VjYWRhaXItaW50YXJlYS1ob3N0 LWlkZW50aWZpZXItc2NlbmFyaW9zLTA0IGFzIGFuIGludGFyZWEgV0cgZHJhZnQuIFBsZWFzZSBz dGF0ZSB3aGV0aGVyIG9yIG5vdCB5b3UncmUgaW4gZmF2b3Igb2YgdGhlIGFkb3B0aW9uIGJ5IHJl cGx5aW5nIHRvIHRoaXMgZW1haWwuIElmIHlvdSBhcmUgbm90IGluIGZhdm9yLCBwbGVhc2UgYWxz byBzdGF0ZSB5b3VyIG9iamVjdGlvbnMgaW4geW91ciByZXNwb25zZS4gVGhpcyBhZG9wdGlvbiBj YWxsIHdpbGwgY29tcGxldGUgb24gMjAxNC0wNi0xOS4NCj4NCj4gUmVnYXJkcw0KPiBTdXJlc2gg JiBKdWFuIENhcmxvcw0KDQo= From nobody Wed Jun 11 07:24:14 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723991A05C3 for ; Wed, 11 Jun 2014 07:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PK1jsGS145Rn for ; Wed, 11 Jun 2014 07:24:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C301A0564 for ; Wed, 11 Jun 2014 07:24:09 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 3B77F18C628; Wed, 11 Jun 2014 16:24:07 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 16DE023805E; Wed, 11 Jun 2014 16:24:07 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.12]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0181.006; Wed, 11 Jun 2014 16:24:06 +0200 From: To: S Moonesamy , "Tirumaleswar Reddy (tireddy)" , "int-area@ietf.org" Thread-Topic: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 Thread-Index: AQHPgYdmps57uyqE+kanZueTrGquhZtr++Eg Date: Wed, 11 Jun 2014 14:24:06 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330016053@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <913383AAA69FF945B8F946018B75898A282C8C39@xmb-rcd-x10.cisco.com> <6.2.5.6.2.20140605081321.0bda1060@resistor.net> <787AE7BB302AE849A7480A190F8B933001417F@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6.2.5.6.2.20140606042634.0baaab20@elandnews.com> In-Reply-To: <6.2.5.6.2.20140606042634.0baaab20@elandnews.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.10.215118 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/rKMHqk7Rs8dt5ZdhZRAGMhZ8YkM Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 14:24:11 -0000 Hi SM,=20 Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: S Moonesamy [mailto:sm+ietf@elandsys.com] >Envoy=E9=A0: vendredi 6 juin 2014 14:56 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; Tirumaleswar Reddy (tireddy); int- >area@ietf.org >Objet=A0: RE: [Int-area] Call for adoption of draft-boucadair-intarea-host= - >identifier-scenarios-04 > >Hi Med, >At 00:59 06-06-2014, mohamed.boucadair@orange.com wrote: >>[Med] FWIW, the scenarios draft is not a "HOST_ID specification document"= . > >[snip] > >>[Med] Having a dedicated section for privacy is a signal that we >>have those issues on our radar. Our analysis at this stage is that >>RFC6967 includes a decent discussion that is still valid for this >>use cases document. If you think that additional concerns are to be >>discussed, please don't hesitate to share them. We will consider >>updating the document accordingly. > >[snip] > >>[Med] There is no mention of "HOST_ID" in this draft. Furthermore, >>the current text says the following: >>" The document does not elaborate whether explicit authentication is >> enabled or not." >> >>Solution-specific discussions are out of scope. The main mission of >>the document is to help identifying use cases where there are >>difficulties to enforce per-host policies due to the presence of >>address sharing or the use of tunnels. > >[snip] > >>[Med] Documenting misuses should be definitely in scope. >>Contributions are more than welcome. > > From the above (quoted text) I understand that there are >difficulties to enforce policies and those difficulties have not be >discussed or addressed in IETF RFCs. [Med] Yes.=20 The INTAREA working group >previously worked on a RFC about potential solutions for revealing a >host identifier. Are the potential solutions discussed in RFC 6967 >inadequate? [Med] The effort in RFC6967 does not ambition to pick a solution but to con= duct an analysis effort with a focus on the CGN case. That case is only one= among others defined in the scenario draft. Identify and document the use = cases is a first step to actually understand the problem we are talking abo= ut. This is a contribution to clarify the big picture of this problem space= .=20 I don't think the question is out of scope given that >the draft references RFC 6967. [Med] Privacy is not out of scope as I mentioned in a previous message. Nev= ertheless, privacy implications may depend on the targeted use case. The co= nsiderations in RFC6967 can be completed with new ones if any. > >If the mission is to identify use cases, why are discussions about >the use cases (see Section 2) out of scope? [Med] What we declared out of scope is solution-oriented aspects. We wanted= to have a very focused document. > >The lack of host identification does not affect host >connectivity. This scenarios draft makes the case for the lack of >host identification being the cause of problems. [Med] The draft focuses only on scenarios where complications arise. The pr= oblem may be abstracted from other perspective but the host identification = is a valid angle IMHO.=20 Do the problems >affect the internet or are they limited cases? [Med] Implication on connectivity depends on the use cases. For example, a = service that black list a full IP address or rate limit based on the sourc= e IP address will impact a lot of customers; access to services won't be gr= anted.=20 > >Regards, >S. Moonesamy From nobody Wed Jun 11 07:31:58 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECD21A010D; Wed, 11 Jun 2014 07:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvzB3F8LtAR2; Wed, 11 Jun 2014 07:31:41 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611371A063B; Wed, 11 Jun 2014 07:31:41 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 6D0A71B827D; Wed, 11 Jun 2014 16:31:39 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 26651C804B; Wed, 11 Jun 2014 16:31:39 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.12]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0181.006; Wed, 11 Jun 2014 16:31:39 +0200 From: To: Stephen Farrell , Ted Lemon Thread-Topic: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers Thread-Index: AQHPgaBKDm6yLULEn0WY6FQhphp6qZtr/mVw Date: Wed, 11 Jun 2014 14:31:38 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933001605D@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390D2F8.6000801@gmail.com> <1B87ABE4-1CA1-450D-BA96-3018DF39F08D@nominum.com> <787AE7BB302AE849A7480A190F8B93300141B4@OPEXCLILM23.corporate.adroot.infra.ftgroup> <8A4C0802-DE9A-4ADF-AEA5-61DEC2AFB25B@nominum.com> <787AE7BB302AE849A7480A190F8B933001433C@OPEXCLILM23.corporate.adroot.infra.ftgroup> <5391E55E.9000105@cs.tcd.ie> In-Reply-To: <5391E55E.9000105@cs.tcd.ie> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.10.215118 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/YWPyjwUxXBAEtpInDCcyXzFmLMI Cc: "ietf-privacy@ietf.org" , "int-area@ietf.org" Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 14:31:47 -0000 Hi Stephen, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >Envoy=E9=A0: vendredi 6 juin 2014 17:59 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; Ted Lemon >Cc=A0: Brian E Carpenter; ietf-privacy@ietf.org; int-area@ietf.org >Objet=A0: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers > > >Hi Med, > >On 06/06/14 12:41, mohamed.boucadair@orange.com wrote: >> [Med] I'm not sure about this Ted. There are other initiatives that >> try to solve the issue for particular use cases, see for instance >> this effort for HTTP: >> http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-10. The >> rationale of the "host identifier scenarios" document is to group all >> use cases suffering from the same problem instead of focusing on one >> single case. This allows having a big picture view of the problem >> space. > >I think XFF is actually a good example of why we ought not adopt >this work. [Med] I provided "Forward" as an example to illustrate there is a need to h= ave a big picture view rather than focusing on specific use case. This draf= t does not suggest to adopt XFF or Forward at all. There is a need to under= stand the problem space and identify deployment scenarios where encounterin= g complications. > >XFF is widely deployed already but somewhat flakey in terms of >interop so the authors of the above draft aimed to produce a spec >that just addressed interop. (*) That was adopted by an area WG >without (IMO) ever really considering the privacy implications, >and definitely without any effort having been made to develop a >more privacy-friendly mechanism (which could have been done, again >IMO) to solve what were the claimed use-cases. [Med] Wouldn't be this effort an opportunity to promote those solutions you= are advocating for? The proxy use case (not limited to HTTP) is listed as = a typical scenario. If there are other better solutions that solves your pr= ivacy concerns, why not documenting them?=20 By the time it >got to the IESG that was in practice unfixable and after some >fairly painful discussions it ended up with 4 abstain ballots, >including mine. [1] (For those who quite reasonably don't need >to care about IESG balloting, an abstain means approximately >"yuk.":-) > >Of course that all also pre-dated BCP188 and the last year's >shenanigans so I'd hope we have learned to not keep doing that. > >I'd be delighted if those who could get a better solution >implemented/deployed were to attempt to try to address the >privacy issues with XFF but it seems that at least in that >case relevant folks don't care (sufficiently;-) deeply about >our privacy to go do that. > >S. > >[1] >https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/ > >(*) To be clear: I think the authors were genuinely just >trying to fix what they saw as an interop problem. From nobody Wed Jun 11 07:38:22 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9611A0147; Wed, 11 Jun 2014 07:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EDCabqjXAWl; Wed, 11 Jun 2014 07:38:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BCE41A0127; Wed, 11 Jun 2014 07:38:18 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id ED7B32AC892; Wed, 11 Jun 2014 16:38:16 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id CD237C8058; Wed, 11 Jun 2014 16:38:16 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.12]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0181.006; Wed, 11 Jun 2014 16:38:16 +0200 From: To: Stephen Farrell , Dan Wing Thread-Topic: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers Thread-Index: AQHPglNJdwFj/1Pg2EKVA7MlkS7VwJtr/0Dg Date: Wed, 11 Jun 2014 14:38:16 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330016077@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> In-Reply-To: <5393119F.6050805@cs.tcd.ie> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.10.215118 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/HlqSzX5TIxlZcd2picMB52UfHFM Cc: "ietf-privacy@ietf.org" , Internet Area Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 14:38:20 -0000 Re-, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: ietf-privacy [mailto:ietf-privacy-bounces@ietf.org] De la part de >Stephen Farrell >Envoy=E9=A0: samedi 7 juin 2014 15:21 >=C0=A0: Dan Wing >Cc=A0: ietf-privacy@ietf.org; Internet Area; Joe Touch >Objet=A0: Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers > > >Hi Dan, > >On 07/06/14 02:38, Dan Wing wrote: >> >> Stephen, >> >> It seems NAPT has become IETF's privacy feature of 2014 because >> multiple users are sharing one identifier (IP address and presumably >> randomized ports [RFC6056], although many NAPT deployments use >> address ranges because of fear of compressing log files). As a >> former co-chair of BEHAVE it is refreshing to see the IETF embracing >> NAPT as a desirable feature. > >Embracing seems like significant overstatement to me, but maybe >that's understandable given how calmly NAT is generally debated. > >NATs have both good and bad properties. The slightly better privacy >is one of the good ones. > >Recognising that reality is neither embracing nor refreshing IMO, >nor does it mean NAPT is (un)desirable overall. (That's an argument >I only ever watch from the side-lines thanks:-) > >> However, if NAPT provides privacy and NAT Reveal removes it, where >> does that leave a host's IPv6 source address with respect to BCP188? >> >> Afterall, an IPv6 address is quite traceable, even with IPv6 privacy >> addresses (especially as IPv6 privacy addresses are currently >> deployed which only obtain a new IPv6 privacy address every 24 hours >> or when attaching to a new network). If BCP188 does not prevent >> deployment of IPv6, I would like to understand the additional privacy >> leakage of IPv4+NAT+NAT_Reveal compared to the privacy leakage of >> IPv6+privacy_address. > >I'm frankly amazed that that's not crystal clear to anyone who >has read all 2.5 non-boilerplate pages of the BCP. Or even just >the last two words of the 1-line abstract (hint: those say "where >possible.") > >Yes, source addresses leak information that affects privacy. But >we do not have a practical way to mitigate that. So therefore >BCP188 does not call for doing stupid stuff, nor for new laws of >physics (unlike -04 of the draft we're discussing;-) [Med] FWIW, this draft does not hint solutions but it aims to describe scen= arios with problems. I understand you have concerns with privacy but this i= s not an excuse to abuse and characterize this effort as "stupid". Privacy = implications should be assess on a per use case basis (see for example case= s where all involved entities belong to same administrative entity). Furthe= rmore, the document (including -04) says the following : "the document does= not elaborate whether explicit authentication is enabled or not." > >Adding new identifiers with privacy impact, as proposed here, is >quite different. [Med] I have already clarified this point: the scenario draft does not prop= ose any identifier! > >S. > >PS: If someone wants to propose what they think is a practical >way to mitigate the privacy issues with source addresses, please >write a draft first and then start a separate thread somewhere. > > >> >> -d >> > >_______________________________________________ >ietf-privacy mailing list >ietf-privacy@ietf.org >https://www.ietf.org/mailman/listinfo/ietf-privacy From nobody Wed Jun 11 07:55:03 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF281A0141; Wed, 11 Jun 2014 07:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YN5JvhSdkfYY; Wed, 11 Jun 2014 07:54:57 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1A801A0127; Wed, 11 Jun 2014 07:54:57 -0700 (PDT) Received: from [172.20.7.72] ([12.104.145.3]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s5BEsCaG001412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 Jun 2014 07:54:21 -0700 (PDT) Message-ID: <53986D94.5090801@isi.edu> Date: Wed, 11 Jun 2014 07:54:12 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Stephen Farrell , Dan Wing References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> In-Reply-To: <5393119F.6050805@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/l1Ry8q3kJqmLQu5Aoh-jfMTZMp4 Cc: "ietf-privacy@ietf.org" , Internet Area Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 14:55:00 -0000 On 6/7/2014 6:20 AM, Stephen Farrell wrote: > Yes, source addresses leak information that affects privacy. But > we do not have a practical way to mitigate that. So therefore > BCP188 does not call for doing stupid stuff, nor for new laws of > physics (unlike -04 of the draft we're discussing;-) Again, BCP188 does not *call* for doing anything. There are no SHOULD- or MUST- level requirements in that doc. Let's please not wave it in the air as if there are. Joe From nobody Wed Jun 11 08:09:35 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041111A015F; Wed, 11 Jun 2014 08:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfjyDMVRUijr; Wed, 11 Jun 2014 08:09:21 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C8F091A00F0; Wed, 11 Jun 2014 08:09:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 196FCBE5D; Wed, 11 Jun 2014 16:09:20 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mawrMWL2097g; Wed, 11 Jun 2014 16:09:18 +0100 (IST) Received: from [192.168.8.110] (217.64.246.66.mactelecom.net [217.64.246.66]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9C545BE56; Wed, 11 Jun 2014 16:09:18 +0100 (IST) Message-ID: <5398711F.1020702@cs.tcd.ie> Date: Wed, 11 Jun 2014 16:09:19 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Joe Touch , Dan Wing References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> <53986D94.5090801@isi.edu> In-Reply-To: <53986D94.5090801@isi.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/-UB3Ja9t0fo58mV8RFll7vPWuv4 Cc: "ietf-privacy@ietf.org" , Internet Area Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 15:09:30 -0000 On 11/06/14 15:54, Joe Touch wrote: > > > On 6/7/2014 6:20 AM, Stephen Farrell wrote: >> Yes, source addresses leak information that affects privacy. But >> we do not have a practical way to mitigate that. So therefore >> BCP188 does not call for doing stupid stuff, nor for new laws of >> physics (unlike -04 of the draft we're discussing;-) > > Again, BCP188 does not *call* for doing anything. There are no SHOULD- > or MUST- level requirements in that doc. Let's please not wave it in the > air as if there are. I don't buy that argument at all and didn't wave anything anywhere. BCP188 very clearly says: Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. and Those developing IETF specifications need to be able to describe how they have considered PM, and, if the attack is relevant to the work to be published, be able to justify related design decisions. This does not mean a new "pervasive monitoring considerations" section is needed in IETF documentation. It means that, if asked, there needs to be a good answer to the question "Is pervasive monitoring relevant to this work and if so, how has it been considered?" Reverting to RFC2119-keyword-lawyering is not IMO credible here. S. > > Joe > > From nobody Wed Jun 11 08:18:30 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBB61A016D; Wed, 11 Jun 2014 08:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGKFRn0F2mfe; Wed, 11 Jun 2014 08:18:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D75271A0150; Wed, 11 Jun 2014 08:18:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 25B31BE8E; Wed, 11 Jun 2014 16:18:24 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SETVGr_IJ23h; Wed, 11 Jun 2014 16:18:22 +0100 (IST) Received: from [192.168.8.110] (217.64.246.66.mactelecom.net [217.64.246.66]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4E3CBBEA0; Wed, 11 Jun 2014 16:18:22 +0100 (IST) Message-ID: <5398733E.1030805@cs.tcd.ie> Date: Wed, 11 Jun 2014 16:18:22 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, Dan Wing References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> <787AE7BB302AE849A7480A190F8B9330016077@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330016077@OPEXCLILM23.corporate.adroot.infra.ftgroup> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/uAN-5-tF3y0qKSlkeMT8BkhkUpQ Cc: "ietf-privacy@ietf.org" , Internet Area Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 15:18:27 -0000 Hiya, On 11/06/14 15:38, mohamed.boucadair@orange.com wrote: > Re-, > > Please see inline. > > Cheers, Med > >> -----Message d'origine----- De : ietf-privacy >> [mailto:ietf-privacy-bounces@ietf.org] De la part de Stephen >> Farrell Envoy : samedi 7 juin 2014 15:21 : Dan Wing Cc : >> ietf-privacy@ietf.org; Internet Area; Joe Touch Objet : Re: >> [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers >> >> >> Hi Dan, >> >> On 07/06/14 02:38, Dan Wing wrote: >>> >>> Stephen, >>> >>> It seems NAPT has become IETF's privacy feature of 2014 because >>> multiple users are sharing one identifier (IP address and >>> presumably randomized ports [RFC6056], although many NAPT >>> deployments use address ranges because of fear of compressing log >>> files). As a former co-chair of BEHAVE it is refreshing to see >>> the IETF embracing NAPT as a desirable feature. >> >> Embracing seems like significant overstatement to me, but maybe >> that's understandable given how calmly NAT is generally debated. >> >> NATs have both good and bad properties. The slightly better >> privacy is one of the good ones. >> >> Recognising that reality is neither embracing nor refreshing IMO, >> nor does it mean NAPT is (un)desirable overall. (That's an >> argument I only ever watch from the side-lines thanks:-) >> >>> However, if NAPT provides privacy and NAT Reveal removes it, >>> where does that leave a host's IPv6 source address with respect >>> to BCP188? >>> >>> Afterall, an IPv6 address is quite traceable, even with IPv6 >>> privacy addresses (especially as IPv6 privacy addresses are >>> currently deployed which only obtain a new IPv6 privacy address >>> every 24 hours or when attaching to a new network). If BCP188 >>> does not prevent deployment of IPv6, I would like to understand >>> the additional privacy leakage of IPv4+NAT+NAT_Reveal compared to >>> the privacy leakage of IPv6+privacy_address. >> >> I'm frankly amazed that that's not crystal clear to anyone who has >> read all 2.5 non-boilerplate pages of the BCP. Or even just the >> last two words of the 1-line abstract (hint: those say "where >> possible.") >> >> Yes, source addresses leak information that affects privacy. But we >> do not have a practical way to mitigate that. So therefore BCP188 >> does not call for doing stupid stuff, nor for new laws of physics >> (unlike -04 of the draft we're discussing;-) > > [Med] FWIW, this draft does not hint solutions but it aims to > describe scenarios with problems. I understand you have concerns with > privacy but this is not an excuse to abuse and characterize this > effort as "stupid". Apologies if you took it that way. What I meant was that BCP188 does not call for stupid stuff, I was not characterising the draft as stupid, but rather the assertion that BCP188 calls for such. > Privacy implications should be assess on a per > use case basis Where do I find the per-use-case analysis of privacy implications? > (see for example cases where all involved entities > belong to same administrative entity). Furthermore, the document > (including -04) says the following : "the document does not elaborate > whether explicit authentication is enabled or not." > >> >> Adding new identifiers with privacy impact, as proposed here, is >> quite different. > > [Med] I have already clarified this point: the scenario draft does > not propose any identifier! I think its unrealistic to assert that any solution is possible without such. I would be interested in reading about any proposal that did not require a new identifier. So yes, I do assert that a need for a new identifier is implicit in the draft, even if that is not stated explicitly, and would be interested in arguments as to why I'm wrong about that. S. > >> >> S. >> >> PS: If someone wants to propose what they think is a practical way >> to mitigate the privacy issues with source addresses, please write >> a draft first and then start a separate thread somewhere. >> >> >>> >>> -d >>> >> >> _______________________________________________ ietf-privacy >> mailing list ietf-privacy@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-privacy > > From nobody Wed Jun 11 08:26:48 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20F71A0150; Wed, 11 Jun 2014 08:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDAkfpiABXW2; Wed, 11 Jun 2014 08:26:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779E51A0157; Wed, 11 Jun 2014 08:26:43 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id D15153B472D; Wed, 11 Jun 2014 17:26:41 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id B1AFA180051; Wed, 11 Jun 2014 17:26:41 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.12]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Wed, 11 Jun 2014 17:26:40 +0200 From: To: Stephen Farrell , Dan Wing Thread-Topic: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers Thread-Index: AQHPhYhmcRSSJ1x6/0qkSXi0tyMNz5tsBm6g Date: Wed, 11 Jun 2014 15:26:39 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330016193@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> <787AE7BB302AE849A7480A190F8B9330016077@OPEXCLILM23.corporate.adroot.infra.ftgroup> <5398733E.1030805@cs.tcd.ie> In-Reply-To: <5398733E.1030805@cs.tcd.ie> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.10.221221 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/Yg_0X82mCDHPGZ0Z3dsadoaH0Bk Cc: "ietf-privacy@ietf.org" , Internet Area Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 15:26:46 -0000 Re-, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >Envoy=E9=A0: mercredi 11 juin 2014 17:18 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; Dan Wing >Cc=A0: ietf-privacy@ietf.org; Internet Area; Joe Touch >Objet=A0: Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers > > >Hiya, > >On 11/06/14 15:38, mohamed.boucadair@orange.com wrote: >> Re-, >> >> Please see inline. >> >> Cheers, Med >> >>> -----Message d'origine----- De : ietf-privacy >>> [mailto:ietf-privacy-bounces@ietf.org] De la part de Stephen >>> Farrell Envoy=E9 : samedi 7 juin 2014 15:21 =C0 : Dan Wing Cc : >>> ietf-privacy@ietf.org; Internet Area; Joe Touch Objet : Re: >>> [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers >>> >>> >>> Hi Dan, >>> >>> On 07/06/14 02:38, Dan Wing wrote: >>>> >>>> Stephen, >>>> >>>> It seems NAPT has become IETF's privacy feature of 2014 because >>>> multiple users are sharing one identifier (IP address and >>>> presumably randomized ports [RFC6056], although many NAPT >>>> deployments use address ranges because of fear of compressing log >>>> files). As a former co-chair of BEHAVE it is refreshing to see >>>> the IETF embracing NAPT as a desirable feature. >>> >>> Embracing seems like significant overstatement to me, but maybe >>> that's understandable given how calmly NAT is generally debated. >>> >>> NATs have both good and bad properties. The slightly better >>> privacy is one of the good ones. >>> >>> Recognising that reality is neither embracing nor refreshing IMO, >>> nor does it mean NAPT is (un)desirable overall. (That's an >>> argument I only ever watch from the side-lines thanks:-) >>> >>>> However, if NAPT provides privacy and NAT Reveal removes it, >>>> where does that leave a host's IPv6 source address with respect >>>> to BCP188? >>>> >>>> Afterall, an IPv6 address is quite traceable, even with IPv6 >>>> privacy addresses (especially as IPv6 privacy addresses are >>>> currently deployed which only obtain a new IPv6 privacy address >>>> every 24 hours or when attaching to a new network). If BCP188 >>>> does not prevent deployment of IPv6, I would like to understand >>>> the additional privacy leakage of IPv4+NAT+NAT_Reveal compared to >>>> the privacy leakage of IPv6+privacy_address. >>> >>> I'm frankly amazed that that's not crystal clear to anyone who has >>> read all 2.5 non-boilerplate pages of the BCP. Or even just the >>> last two words of the 1-line abstract (hint: those say "where >>> possible.") >>> >>> Yes, source addresses leak information that affects privacy. But we >>> do not have a practical way to mitigate that. So therefore BCP188 >>> does not call for doing stupid stuff, nor for new laws of physics >>> (unlike -04 of the draft we're discussing;-) >> >> [Med] FWIW, this draft does not hint solutions but it aims to >> describe scenarios with problems. I understand you have concerns with >> privacy but this is not an excuse to abuse and characterize this >> effort as "stupid". > >Apologies if you took it that way. What I meant was that BCP188 >does not call for stupid stuff, I was not characterising the >draft as stupid, but rather the assertion that BCP188 calls for >such. [Med] OK. > >> Privacy implications should be assess on a per >> use case basis > >Where do I find the per-use-case analysis of privacy implications? [Med] The current version cites the generic privacy considerations (RFC6967= ). Assessing the implications for each use case is in our to do list based = on the discussion we had so far. This table (from the draft) shows whether = each use case is restricted to a given administrative domain to it spans mu= ltiple ones.=20 +-------------------+------+-------------+-----------------------+ | Use Case | IPv4 | IPv6 | Single Administrative | | | |------+------| Domain | | | |Client|Server| | +-------------------+------+------+------+-----------------------+ | CGN | Yes |Yes(1)| No | No | | A+P | Yes | No | No | No | | Application Proxy | Yes |Yes(2)|Yes(2)| No | | Provider Wi-Fi | Yes | No | No | Yes | | PCC | Yes |Yes(1)| No | Yes | | Femtocells | Yes | No | No | No | | Cellular Networks | Yes |Yes(1)| No | Yes | | Overlay Networks | Yes |Yes(3)|Yes(3)| No | | Emergency Calls | Yes | Yes |Yes | No | | TDF | Yes | Yes | No | Yes | | FMC | Yes |Yes(1)| No | No | +-------------------+------+------+------------------------------+ > >> (see for example cases where all involved entities >> belong to same administrative entity). Furthermore, the document >> (including -04) says the following : "the document does not elaborate >> whether explicit authentication is enabled or not." >> >>> >>> Adding new identifiers with privacy impact, as proposed here, is >>> quite different. >> >> [Med] I have already clarified this point: the scenario draft does >> not propose any identifier! > >I think its unrealistic to assert that any solution is possible >without such. I would be interested in reading about any proposal >that did not require a new identifier. So yes, I do assert that a >need for a new identifier is implicit in the draft, even if that >is not stated explicitly, and would be interested in arguments as >to why I'm wrong about that. [Med] Here is a solution that can be used for a use case described in the d= raft: http://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-00#se= ction-4.2. As you can see, there is no identifier revealed in actual IP pac= kets issued by the connected host ;-)=20 > >S. > >> >>> >>> S. >>> >>> PS: If someone wants to propose what they think is a practical way >>> to mitigate the privacy issues with source addresses, please write >>> a draft first and then start a separate thread somewhere. >>> >>> >>>> >>>> -d >>>> >>> >>> _______________________________________________ ietf-privacy >>> mailing list ietf-privacy@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-privacy >> >> From nobody Wed Jun 11 09:15:46 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FD51A01E7; Wed, 11 Jun 2014 09:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5EqGHyQCrNU; Wed, 11 Jun 2014 09:15:43 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D1C81A01AB; Wed, 11 Jun 2014 09:15:43 -0700 (PDT) Received: from [172.20.7.72] ([12.104.145.3]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s5BGExFi015609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 Jun 2014 09:15:08 -0700 (PDT) Message-ID: <53988083.8060603@isi.edu> Date: Wed, 11 Jun 2014 09:14:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Stephen Farrell , Dan Wing References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> <53986D94.5090801@isi.edu> <5398711F.1020702@cs.tcd.ie> In-Reply-To: <5398711F.1020702@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/H5Rlr0dXX_lt4e-2pDWKsV4mGW0 Cc: "ietf-privacy@ietf.org" , Internet Area Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 16:15:44 -0000 On 6/11/2014 8:09 AM, Stephen Farrell wrote: > > > On 11/06/14 15:54, Joe Touch wrote: >> >> >> On 6/7/2014 6:20 AM, Stephen Farrell wrote: >>> Yes, source addresses leak information that affects privacy. But >>> we do not have a practical way to mitigate that. So therefore >>> BCP188 does not call for doing stupid stuff, nor for new laws of >>> physics (unlike -04 of the draft we're discussing;-) >> >> Again, BCP188 does not *call* for doing anything. There are no SHOULD- >> or MUST- level requirements in that doc. Let's please not wave it in the >> air as if there are. > > I don't buy that argument at all and didn't wave anything anywhere. > > BCP188 very clearly says: > > Pervasive monitoring is a technical attack that should be mitigated > in the design of IETF protocols, where possible. > > and > > Those developing IETF specifications need to be able to describe how > they have considered PM, and, if the attack is relevant to the work > to be published, be able to justify related design decisions. This > does not mean a new "pervasive monitoring considerations" section is > needed in IETF documentation. It means that, if asked, there needs > to be a good answer to the question "Is pervasive monitoring relevant > to this work and if so, how has it been considered?" > > Reverting to RFC2119-keyword-lawyering is not IMO credible here. That's what RFC2119 is for and how we interpret BCPs. The doc goes out of its way - as you note - to include wiggle phrases like "where possible" and by not requiring a new considerations section. Yes, it's fine to discuss it here, and I've already outlined a way forward - with the caveat that my view is "do no harm", not necessarily "fix the lack of privacy already inherent in the Internet" - at least in this doc. Joe From nobody Wed Jun 11 10:04:15 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784591A01CE; Wed, 11 Jun 2014 10:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXCG4UxmwXpL; Wed, 11 Jun 2014 10:04:11 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id AA72B1A01B7; Wed, 11 Jun 2014 10:04:11 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F1467286CD; Wed, 11 Jun 2014 17:04:10 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id DC50028634; Wed, 11 Jun 2014 17:04:10 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id BFDF38003C; Wed, 11 Jun 2014 17:04:10 +0000 (GMT) Message-ID: <53988C0A.9090200@akamai.com> Date: Wed, 11 Jun 2014 13:04:10 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: joel jaeggli , Stephen Farrell , Dan Wing References: <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> <5395BAD3.4040506@akamai.com> <5395BE2A.6090708@cs.tcd.ie> <5395EBE3.3030408@bogus.com> In-Reply-To: <5395EBE3.3030408@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/h3i-3ZnICI7vO-TgjILW3fslBsk Cc: "ietf-privacy@ietf.org" , Internet Area Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: brandon.williams@akamai.com List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 17:04:13 -0000 I agree entirely that defining host identification as a problem indicates that the authors believe a solution is called for. I also agree that the privacy impact of solution candidates must be discussed, including making a concerted effort to mitigate the possibility of those solution candidates being used for pervasive monitoring purposes. My point is simply that this draft is not intended to propose solutions or discuss solution candidates. RFC6967, which as you note is repeatedly cited, discusses solution candidates and lays out a framework for privacy discussion related to solution proposals. Future RFCs that actually propose solutions are already expected to follow the guidance from RFC6967, and the references to that RFC in this draft are meant to point to RFC6967 as the authoritative guidance. Is there some reason why you do not consider it adequate for this "use cases" draft to reference the existing and already published "potential solutions analysis" rfc? What specific content related to privacy and/or pervasive monitoring belongs in this draft that is not already present in RFC6967? Thanks, --Brandon On 06/09/2014 01:16 PM, joel jaeggli wrote: > On 6/9/14, 7:01 AM, Stephen Farrell wrote: >> >> >> On 09/06/14 14:46, Brandon Williams wrote: >>> >>> Would you please indicate where the draft proposes a new identifier? If >>> you are seeing a proposal for protocol changes somewhere in the draft, >>> editing work is required in order to either clarify or excise the >>> associated text. > > There are 6 citations of > > http://tools.ietf.org/html/rfc6967 > > the document doesn't exist in a vacuum where somehow how to do it has > fallen off the table. > > given the repeated asertion that this work is useful because of external > requests (etsi) and that request is in fact tied closely to a particular > method it is relatively strait forward to conflate the discussion of > scenarios and methods. > >> Fair enough that its an assumption of mine that adding some kind of >> identifier is required to meet the (no-longer mis-stated:-) >> requirements for these use-cases. But I think that is logically >> required, and its valid to draw obvious conclusions and its also >> invalid to ignore obvious conclusions. > >> S. >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >> > > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Jun 11 12:27:55 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8A81A0240 for ; Wed, 11 Jun 2014 12:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NBBflPGOY1m for ; Wed, 11 Jun 2014 12:27:52 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DDD1A01D6 for ; Wed, 11 Jun 2014 12:27:52 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.141.215]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s5BJRXf8021640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2014 12:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1402514866; x=1402601266; bh=XYZ38mGT/r1xNu25JNE+RR2ydkv9/PgfYjrlfU5xRzE=; h=Date:To:From:Subject:In-Reply-To:References; b=QrxANPH2D0PyiXlLoVS/lw4xR1F5twgKrspRg0oxeMBHpCIast5rTMKhLEeJgIzrk WFxrqkqNpDb38wivVC0Sk3K736mp1IMnDb206dp7c/xrVMomkPsspy7vVPsZ8/GfGR Q6bX0v7P+ktcHmyOVy1NYr6fFU5g9bOSSfLDhCY0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1402514866; x=1402601266; i=@elandsys.com; bh=XYZ38mGT/r1xNu25JNE+RR2ydkv9/PgfYjrlfU5xRzE=; h=Date:To:From:Subject:In-Reply-To:References; b=xajnCNrMD7uc5lvVwOlVyPOeSjjc5JYYz19LhgC67+EgB2NUWVN/nM3NRCqll4H/p nUiBVR7HJG6lM1K7uJl8h9iMmRQzFX7KtOt43lYFzo4HdS0HEmhEKq5aTYIuCJnu8X 2qEsBzmp9Gc4X1l3Cl3AYAXd/d5wlFW4sBFggH08= Message-Id: <6.2.5.6.2.20140611110655.0a7a54f8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Jun 2014 12:10:17 -0700 To: mohamed.boucadair@orange.com, "Tirumaleswar Reddy (tireddy)" , int-area@ietf.org From: S Moonesamy In-Reply-To: <787AE7BB302AE849A7480A190F8B9330016053@OPEXCLILM23.corpora te.adroot.infra.ftgroup> References: <913383AAA69FF945B8F946018B75898A282C8C39@xmb-rcd-x10.cisco.com> <6.2.5.6.2.20140605081321.0bda1060@resistor.net> <787AE7BB302AE849A7480A190F8B933001417F@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6.2.5.6.2.20140606042634.0baaab20@elandnews.com> <787AE7BB302AE849A7480A190F8B9330016053@OPEXCLILM23.corporate.adroot.infra.ftgroup> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/WAfuNa-XxBennxlXE8NEqmMWZps Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 19:27:53 -0000 Hi Med, At 07:24 11-06-2014, mohamed.boucadair@orange.com wrote: > The INTAREA working group > >previously worked on a RFC about potential solutions for revealing a > >host identifier. Are the potential solutions discussed in RFC 6967 > >inadequate? > >[Med] The effort in RFC6967 does not ambition to pick a solution but >to conduct an analysis effort with a focus on the CGN case. That >case is only one among others defined in the scenario draft. >Identify and document the use cases is a first step to actually >understand the problem we are talking about. This is a contribution >to clarify the big picture of this problem space. I left in my previous comment as it may be easier for the reader to understand the discussion. The previous comment mentioned "potential solutions discussed in RFC 6967". In my opinion the above response does not provide an answer to the question. You made an interesting point, i.e. clarify the big picture. I read the RFCs coming from INTAREA. There was one about "Issues with IP Address Sharing" in June 2011. There is another one about "Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments" in June 2013. Now there is a draft about "Host Identification: Use Cases". I haven't seen a discussion of that big picture on this mailing list. My understanding of the documents is that the working group is make a case (the word is used loosely) for host identification. >[Med] Privacy is not out of scope as I mentioned in a previous >message. Nevertheless, privacy implications may depend on the >targeted use case. The considerations in RFC6967 can be completed >with new ones if any. Ok. I assume that the working group has the expertise and energy to do that work. >[Med] What we declared out of scope is solution-oriented aspects. We >wanted to have a very focused document. This is what I read from the draft: "It is out of scope of this document to argue in favor or against the use cases listed in the following sub-sections." That is different from the above response. I'll wait for the Working Group Chairs to take their decision. Regards, S. Moonesamy From nobody Thu Jun 12 08:01:09 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1BA1A02B3 for ; Thu, 12 Jun 2014 01:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfUJB-nb-UiT for ; Thu, 12 Jun 2014 01:24:01 -0700 (PDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86FF81A0199 for ; Thu, 12 Jun 2014 01:23:59 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id pv20so488450lab.41 for ; Thu, 12 Jun 2014 01:23:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=i9tsZG51RasnP1RSqsvSWfkSUZ0udzNw+1jAlE2eV60=; b=bJCoHfQOLN5LGo1G1E5sYkJ/oTwGXenDkbkxgdNIKlJzWPws3RLwNZ0uMwHhO2IC7x uNCIDXErqsZqQSA06WqW8zrhkD0hheQoL3VeuPKg8xC6vHKHzBGSZA7FtT1KKQdyXYxr rboZUml+dihkLlLKaCytI9i0i9+vH/z13actN3UPc1vbaLDZKD9rcl7gm5OELT3TezR0 nLrPLRqCwhe77XhIv+BPvpNTrmzRJ8LU44Q53mPlef6mmMC0Cg3LvzbzV/9OJDzPkxAG eTGdlNFuSCHfhFhJgMmyMqdnKQVPxWo+UgcN5WXgxiJEnUt1803ITLlddxPZMzYshjsf yMwA== X-Gm-Message-State: ALoCoQnE0nmAwih86F/wGDAjlovncLXWVN+PtIHHecsoZrxK9K1nxgyMqrFl12KEkfWDLphLKgMy MIME-Version: 1.0 X-Received: by 10.112.158.101 with SMTP id wt5mr103183lbb.77.1402561438425; Thu, 12 Jun 2014 01:23:58 -0700 (PDT) Received: by 10.114.98.135 with HTTP; Thu, 12 Jun 2014 01:23:58 -0700 (PDT) Received: by 10.114.98.135 with HTTP; Thu, 12 Jun 2014 01:23:58 -0700 (PDT) Date: Thu, 12 Jun 2014 10:23:58 +0200 Message-ID: From: Chris Prince Udochukwu Njoku To: int-area@ietf.org Content-Type: multipart/alternative; boundary=001a11c33f7050372404fb9f48f2 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/ukEMFHemN-wDDNA_78uPKxHDmvA X-Mailman-Approved-At: Thu, 12 Jun 2014 08:01:08 -0700 Subject: Re: [Int-area] Call for adoption of draft... X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 08:24:06 -0000 --001a11c33f7050372404fb9f48f2 Content-Type: text/plain; charset=UTF-8 Hi, all, Agreeing to Dirk's observations, I also submit that the draft be adopted. On Jun 11, 2014 4:09 PM, wrote: > Send Int-area mailing list submissions to > int-area@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/int-area > or, via email, send a message with subject or body 'help' to > int-area-request@ietf.org > > You can reach the person managing the list at > int-area-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Int-area digest..." > > > Today's Topics: > > 1. Re: Call for adoption of > draft-boucadair-intarea-host-identifier-scenarios-04 > (Dirk.von-Hugo@telekom.de) > 2. Re: Call for adoption of > draft-boucadair-intarea-host-identifier-scenarios-04 > (mohamed.boucadair@orange.com) > 3. Re: [ietf-privacy] NAT Reveal / Host Identifiers > (mohamed.boucadair@orange.com) > 4. Re: [ietf-privacy] NAT Reveal / Host Identifiers > (mohamed.boucadair@orange.com) > 5. Re: [ietf-privacy] NAT Reveal / Host Identifiers (Joe Touch) > 6. Re: [ietf-privacy] NAT Reveal / Host Identifiers (Stephen Farrell) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 11 Jun 2014 14:20:52 +0200 > From: > To: > Subject: Re: [Int-area] Call for adoption of > draft-boucadair-intarea-host-identifier-scenarios-04 > Message-ID: > < > 05C81A773E48DD49B181B04BA21A342A2E00822ECD@HE113484.emea1.cds.t-internal.com > > > > Content-Type: text/plain; charset="utf-8" > > Dear all, > Considering the current discussion on pros and cons I think the topic of > NAT reveal and Host_Id in terms of problem statements and requirements > towards a solution space indeed needs to be assessed in further detail - > especially since there are actual use cases in heterogeneous access and > transport domains such as policy assignment, emergency calls, function > chaining, content streaming etc. pp. > > Since IntArea WG IMO seems to be a proper discussion arena I am in favor > of adopting the draft. > > Best regards > Dirk > > > De : Int-area [mailto:int-area-bounces@ietf.org] De la part de Suresh > > Krishnan Envoy? : jeudi 5 juin 2014 06:21 ? : Internet Area Objet : > > [Int-area] Call for adoption of > > draft-boucadair-intarea-host-identifier-scenarios-04 > > > > Hi all, > > This draft was originally intended to be published as an AD > > sponsored submission from the OPS area, but the authors have expressed > > their interest to continue this work in the intarea wg given that > > RFC6269 and RFC6967 originated here. The draft has been updated to > > address the issues brought up during earlier discussions on the wg > > mailing list and the latest version of the draft is available at > > > > http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-sce > > narios-04 > > > > This call is being initiated to determine whether there is WG consensus > towards adoption of draft-boucadair-intarea-host-identifier-scenarios-04 as > an intarea WG draft. Please state whether or not you're in favor of the > adoption by replying to this email. If you are not in favor, please also > state your objections in your response. This adoption call will complete on > 2014-06-19. > > > > Regards > > Suresh & Juan Carlos > > > ------------------------------ > > Message: 2 > Date: Wed, 11 Jun 2014 14:24:06 +0000 > From: > To: S Moonesamy , "Tirumaleswar Reddy (tireddy)" > , "int-area@ietf.org" > Subject: Re: [Int-area] Call for adoption of > draft-boucadair-intarea-host-identifier-scenarios-04 > Message-ID: > > <787AE7BB302AE849A7480A190F8B9330016053@OPEXCLILM23.corporate.adroot.infra.ftgroup > > > > Content-Type: text/plain; charset="iso-8859-1" > > Hi SM, > > Please see inline. > > Cheers, > Med > > >-----Message d'origine----- > >De?: S Moonesamy [mailto:sm+ietf@elandsys.com] > >Envoy??: vendredi 6 juin 2014 14:56 > >??: BOUCADAIR Mohamed IMT/OLN; Tirumaleswar Reddy (tireddy); int- > >area@ietf.org > >Objet?: RE: [Int-area] Call for adoption of draft-boucadair-intarea-host- > >identifier-scenarios-04 > > > >Hi Med, > >At 00:59 06-06-2014, mohamed.boucadair@orange.com wrote: > >>[Med] FWIW, the scenarios draft is not a "HOST_ID specification > document". > > > >[snip] > > > >>[Med] Having a dedicated section for privacy is a signal that we > >>have those issues on our radar. Our analysis at this stage is that > >>RFC6967 includes a decent discussion that is still valid for this > >>use cases document. If you think that additional concerns are to be > >>discussed, please don't hesitate to share them. We will consider > >>updating the document accordingly. > > > >[snip] > > > >>[Med] There is no mention of "HOST_ID" in this draft. Furthermore, > >>the current text says the following: > >>" The document does not elaborate whether explicit authentication is > >> enabled or not." > >> > >>Solution-specific discussions are out of scope. The main mission of > >>the document is to help identifying use cases where there are > >>difficulties to enforce per-host policies due to the presence of > >>address sharing or the use of tunnels. > > > >[snip] > > > >>[Med] Documenting misuses should be definitely in scope. > >>Contributions are more than welcome. > > > > From the above (quoted text) I understand that there are > >difficulties to enforce policies and those difficulties have not be > >discussed or addressed in IETF RFCs. > > [Med] Yes. > > The INTAREA working group > >previously worked on a RFC about potential solutions for revealing a > >host identifier. Are the potential solutions discussed in RFC 6967 > >inadequate? > > [Med] The effort in RFC6967 does not ambition to pick a solution but to > conduct an analysis effort with a focus on the CGN case. That case is only > one among others defined in the scenario draft. Identify and document the > use cases is a first step to actually understand the problem we are talking > about. This is a contribution to clarify the big picture of this problem > space. > > I don't think the question is out of scope given that > >the draft references RFC 6967. > > [Med] Privacy is not out of scope as I mentioned in a previous message. > Nevertheless, privacy implications may depend on the targeted use case. The > considerations in RFC6967 can be completed with new ones if any. > > > > >If the mission is to identify use cases, why are discussions about > >the use cases (see Section 2) out of scope? > > [Med] What we declared out of scope is solution-oriented aspects. We > wanted to have a very focused document. > > > > >The lack of host identification does not affect host > >connectivity. This scenarios draft makes the case for the lack of > >host identification being the cause of problems. > > [Med] The draft focuses only on scenarios where complications arise. The > problem may be abstracted from other perspective but the host > identification is a valid angle IMHO. > > Do the problems > >affect the internet or are they limited cases? > > [Med] Implication on connectivity depends on the use cases. For example, a > service that black list a full IP address or rate limit based on the > source IP address will impact a lot of customers; access to services won't > be granted. > > > > >Regards, > >S. Moonesamy > > > > ------------------------------ > > Message: 3 > Date: Wed, 11 Jun 2014 14:31:38 +0000 > From: > To: Stephen Farrell , Ted Lemon > > Cc: "ietf-privacy@ietf.org" , > "int-area@ietf.org" > Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers > Message-ID: > > <787AE7BB302AE849A7480A190F8B933001605D@OPEXCLILM23.corporate.adroot.infra.ftgroup > > > > Content-Type: text/plain; charset="iso-8859-1" > > Hi Stephen, > > Please see inline. > > Cheers, > Med > > >-----Message d'origine----- > >De?: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > >Envoy??: vendredi 6 juin 2014 17:59 > >??: BOUCADAIR Mohamed IMT/OLN; Ted Lemon > >Cc?: Brian E Carpenter; ietf-privacy@ietf.org; int-area@ietf.org > >Objet?: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers > > > > > >Hi Med, > > > >On 06/06/14 12:41, mohamed.boucadair@orange.com wrote: > >> [Med] I'm not sure about this Ted. There are other initiatives that > >> try to solve the issue for particular use cases, see for instance > >> this effort for HTTP: > >> http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-10. The > >> rationale of the "host identifier scenarios" document is to group all > >> use cases suffering from the same problem instead of focusing on one > >> single case. This allows having a big picture view of the problem > >> space. > > > >I think XFF is actually a good example of why we ought not adopt > >this work. > > [Med] I provided "Forward" as an example to illustrate there is a need to > have a big picture view rather than focusing on specific use case. This > draft does not suggest to adopt XFF or Forward at all. There is a need to > understand the problem space and identify deployment scenarios where > encountering complications. > > > > >XFF is widely deployed already but somewhat flakey in terms of > >interop so the authors of the above draft aimed to produce a spec > >that just addressed interop. (*) That was adopted by an area WG > >without (IMO) ever really considering the privacy implications, > >and definitely without any effort having been made to develop a > >more privacy-friendly mechanism (which could have been done, again > >IMO) to solve what were the claimed use-cases. > > [Med] Wouldn't be this effort an opportunity to promote those solutions > you are advocating for? The proxy use case (not limited to HTTP) is listed > as a typical scenario. If there are other better solutions that solves your > privacy concerns, why not documenting them? > > By the time it > >got to the IESG that was in practice unfixable and after some > >fairly painful discussions it ended up with 4 abstain ballots, > >including mine. [1] (For those who quite reasonably don't need > >to care about IESG balloting, an abstain means approximately > >"yuk.":-) > > > >Of course that all also pre-dated BCP188 and the last year's > >shenanigans so I'd hope we have learned to not keep doing that. > > > >I'd be delighted if those who could get a better solution > >implemented/deployed were to attempt to try to address the > >privacy issues with XFF but it seems that at least in that > >case relevant folks don't care (sufficiently;-) deeply about > >our privacy to go do that. > > > >S. > > > >[1] > > > https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/ > > > >(*) To be clear: I think the authors were genuinely just > >trying to fix what they saw as an interop problem. > > > > ------------------------------ > > Message: 4 > Date: Wed, 11 Jun 2014 14:38:16 +0000 > From: > To: Stephen Farrell , Dan Wing > > Cc: "ietf-privacy@ietf.org" , Internet Area > > Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers > Message-ID: > > <787AE7BB302AE849A7480A190F8B9330016077@OPEXCLILM23.corporate.adroot.infra.ftgroup > > > > Content-Type: text/plain; charset="iso-8859-1" > > Re-, > > Please see inline. > > Cheers, > Med > > >-----Message d'origine----- > >De?: ietf-privacy [mailto:ietf-privacy-bounces@ietf.org] De la part de > >Stephen Farrell > >Envoy??: samedi 7 juin 2014 15:21 > >??: Dan Wing > >Cc?: ietf-privacy@ietf.org; Internet Area; Joe Touch > >Objet?: Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers > > > > > >Hi Dan, > > > >On 07/06/14 02:38, Dan Wing wrote: > >> > >> Stephen, > >> > >> It seems NAPT has become IETF's privacy feature of 2014 because > >> multiple users are sharing one identifier (IP address and presumably > >> randomized ports [RFC6056], although many NAPT deployments use > >> address ranges because of fear of compressing log files). As a > >> former co-chair of BEHAVE it is refreshing to see the IETF embracing > >> NAPT as a desirable feature. > > > >Embracing seems like significant overstatement to me, but maybe > >that's understandable given how calmly NAT is generally debated. > > > >NATs have both good and bad properties. The slightly better privacy > >is one of the good ones. > > > >Recognising that reality is neither embracing nor refreshing IMO, > >nor does it mean NAPT is (un)desirable overall. (That's an argument > >I only ever watch from the side-lines thanks:-) > > > >> However, if NAPT provides privacy and NAT Reveal removes it, where > >> does that leave a host's IPv6 source address with respect to BCP188? > >> > >> Afterall, an IPv6 address is quite traceable, even with IPv6 privacy > >> addresses (especially as IPv6 privacy addresses are currently > >> deployed which only obtain a new IPv6 privacy address every 24 hours > >> or when attaching to a new network). If BCP188 does not prevent > >> deployment of IPv6, I would like to understand the additional privacy > >> leakage of IPv4+NAT+NAT_Reveal compared to the privacy leakage of > >> IPv6+privacy_address. > > > >I'm frankly amazed that that's not crystal clear to anyone who > >has read all 2.5 non-boilerplate pages of the BCP. Or even just > >the last two words of the 1-line abstract (hint: those say "where > >possible.") > > > >Yes, source addresses leak information that affects privacy. But > >we do not have a practical way to mitigate that. So therefore > >BCP188 does not call for doing stupid stuff, nor for new laws of > >physics (unlike -04 of the draft we're discussing;-) > > [Med] FWIW, this draft does not hint solutions but it aims to describe > scenarios with problems. I understand you have concerns with privacy but > this is not an excuse to abuse and characterize this effort as "stupid". > Privacy implications should be assess on a per use case basis (see for > example cases where all involved entities belong to same administrative > entity). Furthermore, the document (including -04) says the following : > "the document does not elaborate whether explicit authentication is enabled > or not." > > > > >Adding new identifiers with privacy impact, as proposed here, is > >quite different. > > [Med] I have already clarified this point: the scenario draft does not > propose any identifier! > > > > >S. > > > >PS: If someone wants to propose what they think is a practical > >way to mitigate the privacy issues with source addresses, please > >write a draft first and then start a separate thread somewhere. > > > > > >> > >> -d > >> > > > >_______________________________________________ > >ietf-privacy mailing list > >ietf-privacy@ietf.org > >https://www.ietf.org/mailman/listinfo/ietf-privacy > > > > ------------------------------ > > Message: 5 > Date: Wed, 11 Jun 2014 07:54:12 -0700 > From: Joe Touch > To: Stephen Farrell , Dan Wing > > Cc: "ietf-privacy@ietf.org" , Internet Area > > Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers > Message-ID: <53986D94.5090801@isi.edu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > On 6/7/2014 6:20 AM, Stephen Farrell wrote: > > Yes, source addresses leak information that affects privacy. But > > we do not have a practical way to mitigate that. So therefore > > BCP188 does not call for doing stupid stuff, nor for new laws of > > physics (unlike -04 of the draft we're discussing;-) > > Again, BCP188 does not *call* for doing anything. There are no SHOULD- > or MUST- level requirements in that doc. Let's please not wave it in the > air as if there are. > > Joe > > > > ------------------------------ > > Message: 6 > Date: Wed, 11 Jun 2014 16:09:19 +0100 > From: Stephen Farrell > To: Joe Touch , Dan Wing > Cc: "ietf-privacy@ietf.org" , Internet Area > > Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers > Message-ID: <5398711F.1020702@cs.tcd.ie> > Content-Type: text/plain; charset=ISO-8859-1 > > > > On 11/06/14 15:54, Joe Touch wrote: > > > > > > On 6/7/2014 6:20 AM, Stephen Farrell wrote: > >> Yes, source addresses leak information that affects privacy. But > >> we do not have a practical way to mitigate that. So therefore > >> BCP188 does not call for doing stupid stuff, nor for new laws of > >> physics (unlike -04 of the draft we're discussing;-) > > > > Again, BCP188 does not *call* for doing anything. There are no SHOULD- > > or MUST- level requirements in that doc. Let's please not wave it in the > > air as if there are. > > I don't buy that argument at all and didn't wave anything anywhere. > > BCP188 very clearly says: > > Pervasive monitoring is a technical attack that should be mitigated > in the design of IETF protocols, where possible. > > and > > Those developing IETF specifications need to be able to describe how > they have considered PM, and, if the attack is relevant to the work > to be published, be able to justify related design decisions. This > does not mean a new "pervasive monitoring considerations" section is > needed in IETF documentation. It means that, if asked, there needs > to be a good answer to the question "Is pervasive monitoring relevant > to this work and if so, how has it been considered?" > > Reverting to RFC2119-keyword-lawyering is not IMO credible here. > > S. > > > > > > > Joe > > > > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > > > ------------------------------ > > End of Int-area Digest, Vol 107, Issue 12 > ***************************************** > --001a11c33f7050372404fb9f48f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi, all,

Agreeing to Dirk's observations, I also submit that the draft be ado= pted.

On Jun 11, 2014 4:09 PM, <int-area-request@ietf.org> wrote:
Send Int-area mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 int-area@i= etf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/int-are= a
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 in= t-area-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 int-= area-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Int-area digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: Call for adoption of
=C2=A0 =C2=A0 =C2=A0 draft-boucadair-intarea-host-identifier-scenarios-04 =C2=A0 =C2=A0 =C2=A0 (Dirk.von-= Hugo@telekom.de)
=C2=A0 =C2=A02. Re: Call for adoption of
=C2=A0 =C2=A0 =C2=A0 draft-boucadair-intarea-host-identifier-scenarios-04 =C2=A0 =C2=A0 =C2=A0 (moham= ed.boucadair@orange.com)
=C2=A0 =C2=A03. Re: [ietf-privacy] NAT Reveal / Host Identifiers
=C2=A0 =C2=A0 =C2=A0 (moham= ed.boucadair@orange.com)
=C2=A0 =C2=A04. Re: [ietf-privacy] =C2=A0 NAT Reveal / Host Identifiers
=C2=A0 =C2=A0 =C2=A0 (moham= ed.boucadair@orange.com)
=C2=A0 =C2=A05. Re: [ietf-privacy] NAT Reveal / Host Identifiers (Joe Touch= )
=C2=A0 =C2=A06. Re: [ietf-privacy] NAT Reveal / Host Identifiers (Stephen F= arrell)


----------------------------------------------------------------------

Message: 1
Date: Wed, 11 Jun 2014 14:20:52 +0200
From: <Dirk.von-Hugo@telekom= .de>
To: <int-area@ietf.org>
Subject: Re: [Int-area] Call for adoption of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-boucadair-intarea-host-identifier-scenari= os-04
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <05C81A773E48DD49B181B0= 4BA21A342A2E00822ECD@HE113484.emea1.cds.t-internal.com>

Content-Type: text/plain; charset=3D"utf-8"

Dear all,
Considering the current discussion on pros and cons I think the topic of NA= T reveal and Host_Id in terms of problem statements and requirements toward= s a solution space indeed needs to be assessed in further detail - especial= ly since there are actual use cases in heterogeneous access and transport d= omains such as policy assignment, emergency calls, function chaining, conte= nt streaming etc. pp.

Since IntArea WG IMO seems to be a proper discussion arena I am in favor of= adopting the draft.

Best regards
Dirk

> De : Int-area [mailto:int= -area-bounces@ietf.org] De la part de Suresh
> Krishnan Envoy? : jeudi 5 juin 2014 06:21 ? : Internet Area Objet : > [Int-area] Call for adoption of
> draft-boucadair-intarea-host-identifier-scenarios-04
>
> Hi all,
> =C2=A0 =C2=A0This draft was originally intended to be published as an = AD
> sponsored submission from the OPS area, but the authors have expressed=
> their interest to continue this work in the intarea wg given that
> RFC6269 and RFC6967 originated here. The draft has been updated to
> address the issues brought up during earlier discussions on the wg
> mailing list and the latest version of the draft is available at
>
> http://tools.ietf.org/html/draft-boucadair-i= ntarea-host-identifier-sce
> narios-04
>
> This call is being initiated to determine whether there is WG consensu= s towards adoption of draft-boucadair-intarea-host-identifier-scenarios-04 = as an intarea WG draft. Please state whether or not you're in favor of = the adoption by replying to this email. If you are not in favor, please als= o state your objections in your response. This adoption call will complete = on 2014-06-19.
>
> Regards
> Suresh & Juan Carlos


------------------------------

Message: 2
Date: Wed, 11 Jun 2014 14:24:06 +0000
From: <mohamed.boucadair= @orange.com>
To: S Moonesamy <sm+ietf@eland= sys.com>, "Tirumaleswar Reddy (tireddy)"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <tiredd= y@cisco.com>, "int-area@ie= tf.org" <int-area@ietf.org= >
Subject: Re: [Int-area] Call for adoption of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-boucadair-intarea-host-identifier-scenari= os-04
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <787AE7BB302AE849A7480A190F8B9330016053@OPEX= CLILM23.corporate.adroot.infra.ftgroup>

Content-Type: text/plain; charset=3D"iso-8859-1"

Hi SM,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De?: S Moonesamy [mailto:sm+i= etf@elandsys.com]
>Envoy??: vendredi 6 juin 2014 14:56
>??: BOUCADAIR Mohamed IMT/OLN; Tirumaleswar Reddy (tireddy); int-
>area@ietf.org
>Objet?: RE: [Int-area] Call for adoption of draft-boucadair-intarea-hos= t-
>identifier-scenarios-04
>
>Hi Med,
>At 00:59 06-06-2014, mo= hamed.boucadair@orange.com wrote:
>>[Med] FWIW, the scenarios draft is not a "HOST_ID specificatio= n document".
>
>[snip]
>
>>[Med] Having a dedicated section for privacy is a signal that we >>have those issues on our radar. Our analysis at this stage is that<= br> >>RFC6967 includes a decent discussion that is still valid for this >>use cases document. If you think that additional concerns are to be=
>>discussed, please don't hesitate to share them. We will conside= r
>>updating the document accordingly.
>
>[snip]
>
>>[Med] There is no mention of "HOST_ID" in this draft. Fur= thermore,
>>the current text says the following:
>>" =C2=A0 The document does not elaborate whether explicit auth= entication is
>> =C2=A0 =C2=A0enabled or not."
>>
>>Solution-specific discussions are out of scope. The main mission of=
>>the document is to help identifying use cases where there are
>>difficulties to enforce per-host policies due to the presence of >>address sharing or the use of tunnels.
>
>[snip]
>
>>[Med] Documenting misuses should be definitely in scope.
>>Contributions are more than welcome.
>
> From the above (quoted text) I understand that there are
>difficulties to enforce policies and those difficulties have not be
>discussed or addressed in IETF RFCs.

[Med] Yes.

=C2=A0 The INTAREA working group
>previously worked on a RFC about potential solutions for revealing a >host identifier. =C2=A0 Are the potential solutions discussed in RFC 69= 67
>inadequate?

[Med] The effort in RFC6967 does not ambition to pick a solution but to con= duct an analysis effort with a focus on the CGN case. That case is only one= among others defined in the scenario draft. Identify and document the use = cases is a first step to actually understand the problem we are talking abo= ut. This is a contribution to clarify the big picture of this problem space= .

=C2=A0 I don't think the question is out of scope given that
>the draft references RFC 6967.

[Med] Privacy is not out of scope as I mentioned in a previous message. Nev= ertheless, privacy implications may depend on the targeted use case. The co= nsiderations in RFC6967 can be completed with new ones if any.

>
>If the mission is to identify use cases, why are discussions about
>the use cases (see Section 2) out of scope?

[Med] What we declared out of scope is solution-oriented aspects. We wanted= to have a very focused document.

>
>The lack of host identification does not affect host
>connectivity. =C2=A0This scenarios draft makes the case for the lack of=
>host identification being the cause of problems.

[Med] The draft focuses only on scenarios where complications arise. The pr= oblem may be abstracted from other perspective but the host identification = is a valid angle IMHO.

=C2=A0 Do the problems
>affect the internet or are they limited cases?

[Med] Implication on connectivity depends on the use cases. For example, a = service that black list a full IP address =C2=A0or rate limit based on the = source IP address will impact a lot of customers; access to services won= 9;t be granted.

>
>Regards,
>S. Moonesamy



------------------------------

Message: 3
Date: Wed, 11 Jun 2014 14:31:38 +0000
From: <mohamed.boucadair= @orange.com>
To: Stephen Farrell <stephe= n.farrell@cs.tcd.ie>, Ted Lemon
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <te= d.lemon@nominum.com>
Cc: "ietf-privacy@ietf.org" <ietf-privacy@ietf.org<= /a>>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "
int-= area@ietf.org" <int-area@i= etf.org>
Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <787AE7BB302AE849A7480A190F8B933001605D@OPEX= CLILM23.corporate.adroot.infra.ftgroup>

Content-Type: text/plain; charset=3D"iso-8859-1"

Hi Stephen,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De?: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
>Envoy??: vendredi 6 juin 2014 17:59
>??: BOUCADAIR Mohamed IMT/OLN; Ted Lemon
>Cc?: Brian E Carpenter; ietf-p= rivacy@ietf.org; int-area@ietf.org=
>Objet?: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers
>
>
>Hi Med,
>
>On 06/06/14 12:41, moha= med.boucadair@orange.com wrote:
>> [Med] I'm not sure about this Ted. There are other initiatives= that
>> try to solve the issue for particular use cases, see for instance<= br> >> this effort for HTTP:
>> http://tools.ietf.org/html/draft-ietf-appsawg-h= ttp-forwarded-10. The
>> rationale of the "host identifier scenarios" document is= to group all
>> use cases suffering from the same problem instead of focusing on o= ne
>> single case. This allows having a big picture view of the problem<= br> >> space.
>
>I think XFF is actually a good example of why we ought not adopt
>this work.

[Med] I provided "Forward" as an example to illustrate there is a= need to have a big picture view rather than focusing on specific use case.= This draft does not suggest to adopt XFF or Forward at all. There is a nee= d to understand the problem space and identify deployment scenarios where e= ncountering complications.

>
>XFF is widely deployed already but somewhat flakey in terms of
>interop so the authors of the above draft aimed to produce a spec
>that just addressed interop. (*) That was adopted by an area WG
>without (IMO) ever really considering the privacy implications,
>and definitely without any effort having been made to develop a
>more privacy-friendly mechanism (which could have been done, again
>IMO) to solve what were the claimed use-cases.

[Med] Wouldn't be this effort an opportunity to promote those solutions= you are advocating for? The proxy use case (not limited to HTTP) is listed= as a typical scenario. If there are other better solutions that solves you= r privacy concerns, why not documenting them?

=C2=A0By the time it
>got to the IESG that was in practice unfixable and after some
>fairly painful discussions it ended up with 4 abstain ballots,
>including mine. [1] (For those who quite reasonably don't need
>to care about IESG balloting, an abstain means approximately
>"yuk.":-)
>
>Of course that all also pre-dated BCP188 and the last year's
>shenanigans so I'd hope we have learned to not keep doing that.
>
>I'd be delighted if those who could get a better solution
>implemented/deployed were to attempt to try to address the
>privacy issues with XFF but it seems that at least in that
>case relevant folks don't care (sufficiently;-) deeply about
>our privacy to go do that.
>
>S.
>
>[1]
>https://datatracker.ietf.org/doc/draft-ie= tf-appsawg-http-forwarded/ballot/
>
>(*) To be clear: I think the authors were genuinely just
>trying to fix what they saw as an interop problem.



------------------------------

Message: 4
Date: Wed, 11 Jun 2014 14:38:16 +0000
From: <mohamed.boucadair= @orange.com>
To: Stephen Farrell <stephe= n.farrell@cs.tcd.ie>, Dan Wing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <dwing@ci= sco.com>
Cc: "ietf-privacy@ietf.org" <ietf-privacy@ietf.org<= /a>>, Internet Area
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <
int-ar= ea@ietf.org>
Subject: Re: [Int-area] [ietf-privacy] =C2=A0 NAT Reveal / Host Identifiers=
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <787AE7BB302AE849A7480A190F8B9330016077@OPEX= CLILM23.corporate.adroot.infra.ftgroup>

Content-Type: text/plain; charset=3D"iso-8859-1"

Re-,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De?: ietf-privacy [mailto:ietf-privacy-bounces@ietf.org] De la part de
>Stephen Farrell
>Envoy??: samedi 7 juin 2014 15:21
>??: Dan Wing
>Cc?: ietf-privacy@ietf.org= ; Internet Area; Joe Touch
>Objet?: Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
>
>
>Hi Dan,
>
>On 07/06/14 02:38, Dan Wing wrote:
>>
>> Stephen,
>>
>> It seems NAPT has become IETF's privacy feature of 2014 becaus= e
>> multiple users are sharing one identifier (IP address and presumab= ly
>> randomized ports [RFC6056], although many NAPT deployments use
>> address ranges because of fear of compressing log files). =C2=A0As= a
>> former co-chair of BEHAVE it is refreshing to see the IETF embraci= ng
>> NAPT as a desirable feature.
>
>Embracing seems like significant overstatement to me, but maybe
>that's understandable given how calmly NAT is generally debated. >
>NATs have both good and bad properties. The slightly better privacy
>is one of the good ones.
>
>Recognising that reality is neither embracing nor refreshing IMO,
>nor does it mean NAPT is (un)desirable overall. (That's an argument=
>I only ever watch from the side-lines thanks:-)
>
>> However, if NAPT provides privacy and NAT Reveal removes it, where=
>> does that leave a host's IPv6 source address with respect to B= CP188?
>>
>> Afterall, an IPv6 address is quite traceable, even with IPv6 priva= cy
>> addresses (especially as IPv6 privacy addresses are currently
>> deployed which only obtain a new IPv6 privacy address every 24 hou= rs
>> or when attaching to a new network). =C2=A0If BCP188 does not prev= ent
>> deployment of IPv6, I would like to understand the additional priv= acy
>> leakage of IPv4+NAT+NAT_Reveal compared to the privacy leakage of<= br> >> IPv6+privacy_address.
>
>I'm frankly amazed that that's not crystal clear to anyone who<= br> >has read all 2.5 non-boilerplate pages of the BCP. Or even just
>the last two words of the 1-line abstract (hint: those say "where<= br> >possible.")
>
>Yes, source addresses leak information that affects privacy. But
>we do not have a practical way to mitigate that. So therefore
>BCP188 does not call for doing stupid stuff, nor for new laws of
>physics (unlike -04 of the draft we're discussing;-)

[Med] FWIW, this draft does not hint solutions but it aims to describe scen= arios with problems. I understand you have concerns with privacy but this i= s not an excuse to abuse and characterize this effort as "stupid"= . Privacy implications should be assess on a per use case basis (see for ex= ample cases where all involved entities belong to same administrative entit= y). Furthermore, the document (including -04) says the following : "th= e document does not elaborate whether explicit authentication is enabled or= not."

>
>Adding new identifiers with privacy impact, as proposed here, is
>quite different.

[Med] I have already clarified this point: the scenario draft does not prop= ose any identifier!

>
>S.
>
>PS: If someone wants to propose what they think is a practical
>way to mitigate the privacy issues with source addresses, please
>write a draft first and then start a separate thread somewhere.
>
>
>>
>> -d
>>
>
>_______________________________________________
>ietf-privacy mailing list
>ietf-privacy@ietf.org
>https://www.ietf.org/mailman/listinfo/ietf-privacy



------------------------------

Message: 5
Date: Wed, 11 Jun 2014 07:54:12 -0700
From: Joe Touch <touch@isi.edu><= br> To: Stephen Farrell <stephe= n.farrell@cs.tcd.ie>, Dan Wing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <dwing@ci= sco.com>
Cc: "ietf-privacy@ietf.org" <ietf-privacy@ietf.org<= /a>>, Internet Area
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <
int-ar= ea@ietf.org>
Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers
Message-ID: <53986D94.509080= 1@isi.edu>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed



On 6/7/2014 6:20 AM, Stephen Farrell wrote:
> Yes, source addresses leak information that affects privacy. But
> we do not have a practical way to mitigate that. So therefore
> BCP188 does not call for doing stupid stuff, nor for new laws of
> physics (unlike -04 of the draft we're discussing;-)

Again, BCP188 does not *call* for doing anything. There are no SHOULD-
or MUST- level requirements in that doc. Let's please not wave it in th= e
air as if there are.

Joe



------------------------------

Message: 6
Date: Wed, 11 Jun 2014 16:09:19 +0100
From: Stephen Farrell <step= hen.farrell@cs.tcd.ie>
To: Joe Touch <touch@isi.edu>, D= an Wing <dwing@cisco.com>
Cc: "ietf-privacy@ietf.org" <ietf-privacy@ietf.org<= /a>>, Internet Area
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <
int-ar= ea@ietf.org>
Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers
Message-ID: <5398711F.1020= 702@cs.tcd.ie>
Content-Type: text/plain; charset=3DISO-8859-1



On 11/06/14 15:54, Joe Touch wrote:
>
>
> On 6/7/2014 6:20 AM, Stephen Farrell wrote:
>> Yes, source addresses leak information that affects privacy. But >> we do not have a practical way to mitigate that. So therefore
>> BCP188 does not call for doing stupid stuff, nor for new laws of >> physics (unlike -04 of the draft we're discussing;-)
>
> Again, BCP188 does not *call* for doing anything. There are no SHOULD-=
> or MUST- level requirements in that doc. Let's please not wave it = in the
> air as if there are.

I don't buy that argument at all and didn't wave anything anywhere.=

BCP188 very clearly says:

=C2=A0 =C2=A0Pervasive monitoring is a technical attack that should be miti= gated
=C2=A0 =C2=A0in the design of IETF protocols, where possible.

and

=C2=A0 =C2=A0Those developing IETF specifications need to be able to descri= be how
=C2=A0 =C2=A0they have considered PM, and, if the attack is relevant to the= work
=C2=A0 =C2=A0to be published, be able to justify related design decisions. = =C2=A0This
=C2=A0 =C2=A0does not mean a new "pervasive monitoring considerations&= quot; section is
=C2=A0 =C2=A0needed in IETF documentation. =C2=A0It means that, if asked, t= here needs
=C2=A0 =C2=A0to be a good answer to the question "Is pervasive monitor= ing relevant
=C2=A0 =C2=A0to this work and if so, how has it been considered?"

Reverting to RFC2119-keyword-lawyering is not IMO credible here.

S.



>
> Joe
>
>



------------------------------

Subject: Digest Footer

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


------------------------------

End of Int-area Digest, Vol 107, Issue 12
*****************************************
--001a11c33f7050372404fb9f48f2-- From nobody Thu Jun 12 08:21:08 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05C01A0370 for ; Thu, 12 Jun 2014 08:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_WcEkIxlwNH for ; Thu, 12 Jun 2014 08:21:04 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A9B1A0263 for ; Thu, 12 Jun 2014 08:21:04 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4B7391B8035 for ; Thu, 12 Jun 2014 08:21:04 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 413F1190064; Thu, 12 Jun 2014 08:21:04 -0700 (PDT) Received: from [10.0.10.40] (174.62.147.182) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Jun 2014 08:21:04 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Thu, 12 Jun 2014 11:21:02 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <950F28EA-85ED-4FDC-8F3E-389E32BB758E@nominum.com> References: To: Chris Prince Udochukwu Njoku X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [174.62.147.182] Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/FrmnqpCcQGq0Mym1JDooB6rsAUM Cc: int-area@ietf.org Subject: Re: [Int-area] Call for adoption of draft... X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 15:21:06 -0000 On Jun 12, 2014, at 4:23 AM, Chris Prince Udochukwu Njoku = wrote: > Agreeing to Dirk's observations, I also submit that the draft be = adopted. FWIW, messages of this sort in a consensus call have no value to the = chairs or to the AD. If you think it should be supported, please = explain why, or what you say won't make any difference. E.g., "I want = this because it will help me in the following way" would be helpful. = If you just want to express solidarity, that is of course perfectly = fine! :) From nobody Thu Jun 12 23:57:18 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C734E1B28E4 for ; Thu, 12 Jun 2014 23:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xi10tTjnmI3s for ; Thu, 12 Jun 2014 23:57:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807D81B28C7 for ; Thu, 12 Jun 2014 23:57:14 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 5D74F3B4662; Fri, 13 Jun 2014 08:57:12 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 417F338405A; Fri, 13 Jun 2014 08:57:12 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.12]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 13 Jun 2014 08:57:12 +0200 From: To: S Moonesamy , "Tirumaleswar Reddy (tireddy)" , "int-area@ietf.org" Thread-Topic: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 Thread-Index: AQHPhas+O57vsiksyUuajXTQoAb5lptujL3A Date: Fri, 13 Jun 2014 06:57:12 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330016D6E@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <913383AAA69FF945B8F946018B75898A282C8C39@xmb-rcd-x10.cisco.com> <6.2.5.6.2.20140605081321.0bda1060@resistor.net> <787AE7BB302AE849A7480A190F8B933001417F@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6.2.5.6.2.20140606042634.0baaab20@elandnews.com> <787AE7BB302AE849A7480A190F8B9330016053@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6.2.5.6.2.20140611110655.0a7a54f8@elandnews.com> In-Reply-To: <6.2.5.6.2.20140611110655.0a7a54f8@elandnews.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.13.41819 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/5oauancQPJtQv5bS24llRpw_RXI Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 06:57:17 -0000 Hi SM, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: S Moonesamy [mailto:sm+ietf@elandsys.com] >Envoy=E9=A0: mercredi 11 juin 2014 21:10 >=C0=A0: BOUCADAIR Mohamed IMT/OLN; Tirumaleswar Reddy (tireddy); int- >area@ietf.org >Objet=A0: RE: [Int-area] Call for adoption of draft-boucadair-intarea-host= - >identifier-scenarios-04 > >Hi Med, >At 07:24 11-06-2014, mohamed.boucadair@orange.com wrote: >> The INTAREA working group >> >previously worked on a RFC about potential solutions for revealing a >> >host identifier. Are the potential solutions discussed in RFC 6967 >> >inadequate? >> >>[Med] The effort in RFC6967 does not ambition to pick a solution but >>to conduct an analysis effort with a focus on the CGN case. That >>case is only one among others defined in the scenario draft. >>Identify and document the use cases is a first step to actually >>understand the problem we are talking about. This is a contribution >>to clarify the big picture of this problem space. > >I left in my previous comment as it may be easier for the reader to >understand the discussion. > >The previous comment mentioned "potential solutions discussed in RFC >6967". In my opinion the above response does not provide an answer >to the question. [Med] The analysis of the solutions discussed in RFC6967 was drawn with a p= articular focus on "Carrier-Grade NAT (CGN), application proxies, or Addres= s plus Port (A+P)." (Excerpt from RFC6967) + an ** Internet-wide ** scope. = Some parts of that analysis is "inappropriate" for some cases that are rest= ricted to ** a single administrative domain **. For example, using an IP op= tion is not a viable solution for the Internet-wide cases, but this option = can be investigated further for the single domain case.=20 > >You made an interesting point, i.e. clarify the big picture. I read >the RFCs coming from INTAREA. There was one about "Issues with IP >Address Sharing" in June 2011. There is another one about "Analysis >of Potential Solutions for Revealing a Host Identifier (HOST_ID) in >Shared Address Deployments" in June 2013. Now there is a draft about >"Host Identification: Use Cases". I haven't seen a discussion of >that big picture on this mailing list. My understanding of the >documents is that the working group is make a case (the word is used >loosely) for host identification. [Med] The documents produced so far by intarea focus on address sharing (re= ad CGNs, A+P). The scenarios draft aims to provide the big picture view by = gathering a list of cases that suffer from similar problems that we abstrac= ted as "host identification problem". The inventory of these cases is IMHO = useful to understand the problem space and avoid restricting it to the sing= le CGN case. It also provides a tool to rationalize the solution design eff= ort: For example, the current situation is that one who reads RFC7239 won't= be able to link it effort to RFC6967!=20 > >>[Med] Privacy is not out of scope as I mentioned in a previous >>message. Nevertheless, privacy implications may depend on the >>targeted use case. The considerations in RFC6967 can be completed >>with new ones if any. > >Ok. I assume that the working group has the expertise and energy to >do that work. > >>[Med] What we declared out of scope is solution-oriented aspects. We >>wanted to have a very focused document. > >This is what I read from the draft: > > "It is out of scope of this document to argue in favor or against the > use cases listed in the following sub-sections." [Med] The current version of the scenarios draft includes some cases that c= an be considered as deployment-specific (see for instance the case of offer= ing Provider Wi-Fi by re-using CPE resources "Use Case#4"). These case are = listed because authors are aware of such plans: a concrete example "Use Cas= e#4" corresponds to what is mentioned in slide 12 of www.3gpp.org/ftp/works= hop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-11046.zip. The sentence you quoted is = a warning that the authors are not taking position for these deployments.=20 > >That is different from the above response. > >I'll wait for the Working Group Chairs to take their decision. > >Regards, >S. Moonesamy From nobody Sat Jun 14 10:39:36 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC52A1B2971 for ; Sat, 14 Jun 2014 10:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KP_G_Nc_p7uX for ; Sat, 14 Jun 2014 10:39:32 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 549401B292E for ; Sat, 14 Jun 2014 10:39:32 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.141.167]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s5EHdF7G022968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jun 2014 10:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1402767570; x=1402853970; bh=mDHUcrNyjkGC04VOhlRczDF5F1BitXkanKuXmtKE+Zs=; h=Date:To:From:Subject:In-Reply-To:References; b=1fEvXFrS0A4TuX++yLkqicBHXoQ8d+aAp+46pbBarILrr7GNCRfxQ0yNGae1/yxMR mShoE6r1PbcZX5QlmSrPXwUgXQDv1Zn6mf5N+u6iwBHdiBgRthfCHwlprXH97HxqjO 5mn7pnZxpXsizZXhDQNN8pMIZAW3H+qnxf9iASU0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1402767570; x=1402853970; i=@elandsys.com; bh=mDHUcrNyjkGC04VOhlRczDF5F1BitXkanKuXmtKE+Zs=; h=Date:To:From:Subject:In-Reply-To:References; b=4STsVxT/Apo9JZ1ImBlK5wBgviV/2ChAJlFpbMz+ZKzJhBUYPYMZ2JROjXXlAyKTS rnus7mtSxB6bRgMCocw5LEx5/zV0xS/tL6SMj2MrRQ11MgSadCu9Cy/wiLC5rofd3/ HdNIwx5D8K80kUNaAsxdBn9so9l+KZuvS4B0VLWw= Message-Id: <6.2.5.6.2.20140614064644.0b879570@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 14 Jun 2014 08:31:12 -0700 To: mohamed.boucadair@orange.com, int-area@ietf.org From: S Moonesamy In-Reply-To: <787AE7BB302AE849A7480A190F8B9330016D6E@OPEXCLILM23.corpora te.adroot.infra.ftgroup> References: <913383AAA69FF945B8F946018B75898A282C8C39@xmb-rcd-x10.cisco.com> <6.2.5.6.2.20140605081321.0bda1060@resistor.net> <787AE7BB302AE849A7480A190F8B933001417F@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6.2.5.6.2.20140606042634.0baaab20@elandnews.com> <787AE7BB302AE849A7480A190F8B9330016053@OPEXCLILM23.corporate.adroot.infra.ftgroup> <6.2.5.6.2.20140611110655.0a7a54f8@elandnews.com> <787AE7BB302AE849A7480A190F8B9330016D6E@OPEXCLILM23.corporate.adroot.infra.ftgroup> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/FQsxWDizP8rXWIAYaaHxifoX2Ho Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 17:39:35 -0000 Hi Med, Thanks for the response. At 23:57 12-06-2014, mohamed.boucadair@orange.com wrote: >[Med] The documents produced so far by intarea focus on address >sharing (read CGNs, A+P). The scenarios draft aims to provide the >big picture view by gathering a list of cases that suffer from >similar problems that we abstracted as "host identification >problem". The inventory of these cases is IMHO useful to understand >the problem space and avoid restricting it to the single CGN case. >It also provides a tool to rationalize the solution design effort: >For example, the current situation is that one who reads RFC7239 >won't be able to link it effort to RFC6967! RFC 7239 has some history. :-) In my opinion the effort for that RFC was unrelated to RFC 6967. I took a quick look at the (public) discussion about that document before writing this. Anyway, there is a little omission in that document which could have been a security issue if the publication of that document was requested after October 2013. >[Med] The current version of the scenarios draft includes some cases >that can be considered as deployment-specific (see for instance the >case of offering Provider Wi-Fi by re-using CPE resources "Use >Case#4"). These case are listed because authors are aware of such >plans: a concrete example "Use Case#4" corresponds to what is >mentioned in slide 12 of >www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-11046.zip. > The sentence you quoted is a warning that the authors are not >taking position for these deployments. I hope that the WG Chairs won't use Section 2 to restrict the discussions. The Call for adoption ( http://www.ietf.org/mail-archive/web/int-area/current/msg03879.html ) is scanty on the details. Regards, S. Moonesamy From nobody Mon Jun 16 02:50:00 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29211B2A87 for ; Mon, 16 Jun 2014 02:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pk8rXy7qU5-N for ; Mon, 16 Jun 2014 02:49:57 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE2D1B29B5 for ; Mon, 16 Jun 2014 02:49:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.141.9]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s5G9ncYe023897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2014 02:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1402912193; x=1402998593; bh=MtS+bE+zzE+/a6tGojrnkbsAuwl7gLIcIW7s3UVhszk=; h=Date:To:From:Subject:Cc; b=c6A83IgGk7iZBATeZI7UpX0V1I2O4BhEMv1/s1JfsL5IwaMibCN9xX1YqK7KZPYLk SeZ5YJ5zZR060px52QNjOB4E7W8bUYR9H3bjWwrxUWYbJK5tdTi0STiCajJ+Yusg2V q9v5SdWXXjQWHspVBrv+32sw97NZHMj3t+N2daj0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1402912193; x=1402998593; i=@elandsys.com; bh=MtS+bE+zzE+/a6tGojrnkbsAuwl7gLIcIW7s3UVhszk=; h=Date:To:From:Subject:Cc; b=SYG6yHUnRsVT/g33DXS4NkoYHfc5Ieh+gX85l1lNG0lbOW5gVYlXWh5jX0AP6Es3q GysprOTwTPScvXy/rOGqcXogBt4TmU3dAcA9dkFI8rz+TKTQzG4PsBDoCTBeta2LLu KmNEaxJX01JpdEcHgq+rxsrSKVNwCm8Yj6xd+E5c= Message-Id: <6.2.5.6.2.20140616024123.0ba53310@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 16 Jun 2014 02:47:57 -0700 To: Alain Durand , Igor Gashinsky , Donn Lee , Scott Sheppard From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/uIvwbV0W4r8QhMfq1n5f5m32gO0 Cc: Linus Nordberg , int-area@ietf.org Subject: [Int-area] Logging Recommendations for Internet-Facing Servers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 09:49:59 -0000 Hello, In the wake of the revelations about surveillance there has been some concerns about RFC 6302. I would be grateful if the authors of RFC 6302 could review the comments at http://www.ietf.org/mail-archive/web/ietf-privacy/current/msg00454.html and provide some feedback. Regards, S. Moonesamy From nobody Mon Jun 16 03:27:51 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728B61B2B91 for ; Mon, 16 Jun 2014 03:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLF6ltV3ERNp for ; Mon, 16 Jun 2014 03:27:48 -0700 (PDT) Received: from mail-we0-x243.google.com (mail-we0-x243.google.com [IPv6:2a00:1450:400c:c03::243]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F7C31B2B54 for ; Mon, 16 Jun 2014 03:27:47 -0700 (PDT) Received: by mail-we0-f195.google.com with SMTP id q58so1802635wes.6 for ; Mon, 16 Jun 2014 03:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=oOkY6Fda1fdpVlgrJmE3iQ/WrWYyub/EpPsyH2kUBWY=; b=Bw3qQrt6JP6KTIcxjku+hLk1jfPWvqKQ+PYvTxz01/IgRmUaEKVPLhqGuCh6UXflGh xp/rD7wx4vYpqdUF93s4c3w9k01PmxYROZhoLuRF7rm8QCTfSP/dxQBRJBMbMcSnscvg P0xAP14uNFMIGZZkpRlx8lzlY1l6NXXCrwc2rl4/zwZvDoMOu4yAvCCHHgkSddono6BT Sugf212IghUFRJvwR60ZJZZzbRAJGVLbKSQLxgXYfiOeTBXgdxQ/s+6JeLE5nV4mIA8U BLOvrVJL+mDqPoA56q9wX/PzztzBL7dOC7qRGhQO+fAPP447Jn8tad6a2wfy1DM3fLFa HfmQ== MIME-Version: 1.0 X-Received: by 10.180.160.205 with SMTP id xm13mr26451730wib.13.1402914465795; Mon, 16 Jun 2014 03:27:45 -0700 (PDT) Received: by 10.194.104.138 with HTTP; Mon, 16 Jun 2014 03:27:45 -0700 (PDT) Date: Mon, 16 Jun 2014 15:57:45 +0530 Message-ID: From: Prashanth Patil To: int-area@ietf.org Content-Type: multipart/alternative; boundary=047d7b62494e6252ac04fbf17a02 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/xH1FQRXYE2Ai1C5XHB07uj2MP_A Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 10:27:49 -0000 --047d7b62494e6252ac04fbf17a02 Content-Type: text/plain; charset=UTF-8 I'm in favor of adopting this draft. The document describes relevant use-cases for identifying hosts behind NAT, which is useful when considering solutions. -Prashanth -----Original Message----- *From:* Int-area [mailto:int-area-bounces at ietf.org] *On Behalf Of *Suresh Krishnan *Sent:* Thursday, June 05, 2014 9:51 AM *To:* Internet Area *Subject:* [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 Hi all, This draft was originally intended to be published as an AD sponsored submission from the OPS area, but the authors have expressed their interest to continue this work in the intarea wg given that RFC6269 and RFC6967 originated here. The draft has been updated to address the issues brought up during earlier discussions on the wg mailing list and the latest version of the draft is available at http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 This call is being initiated to determine whether there is WG consensus towards adoption of draft-boucadair-intarea-host-identifier-scenarios-04 as an intarea WG draft. Please state whether or not you're in favor of the adoption by replying to this email. If you are not in favor, please also state your objections in your response. This adoption call will complete on 2014-06-19. Regards Suresh & Juan Carlos --047d7b62494e6252ac04fbf17a02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm in favor of adoptin=
g this draft. The document describes relevant use-cases for identifying hos=
ts behind NAT, which is useful when considering solutions.

-Prashanth
-----Original Messa=
ge-----

From:=C2=A0Int-area [mailto:int= -area-bounces at ietf.org]=C2=A0On Behalf Of=C2=A0Suresh = Krishnan
Sent:=C2=A0Thursday, June 05, 2014 9:51 AMTo:=C2=A0Internet Area
Subject:<= span class=3D"">=C2=A0
[Int-area] Call for adoption of draft-boucadai= r-intarea-host-identifier-scenarios-04

=C2=A0

Hi all,

=C2=A0=C2=A0 This draft was originally intended to be published as an AD = sponsored submission from the OPS area, but the authors have expressed thei= r interest to continue this work in the intarea wg given that RFC6269 and R= FC6967 originated here. The draft has been updated to address the issues br= ought up during earlier discussions on the wg mailing list and the latest v= ersion of the draft is available at

=C2=A0

http://tools.ietf.org/html/draft-boucad= air-intarea-host-identifier-scenarios-04

=C2=A0

This call is being initiated to determine whether there is WG consensus t= owards adoption of draft-boucadair-intarea-host-identifier-scenarios-04 as = an intarea WG draft. Please state whether or not you're in favor of the= adoption by replying to this email. If you are not in favor, please also s= tate your objections in your response. This adoption call will complete on = 2014-06-19.

=C2=A0

Regards

Suresh & Juan Carlos

--047d7b62494e6252ac04fbf17a02-- From nobody Mon Jun 16 08:25:57 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC46D1A00B0 for ; Mon, 16 Jun 2014 08:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQlFqzK63Ri3 for ; Mon, 16 Jun 2014 08:25:53 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C95661A00A8 for ; Mon, 16 Jun 2014 08:25:52 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.141.9]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s5GFOw4f017552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2014 08:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1402932318; x=1403018718; bh=+BqxW+KUd8j8qkeVpGuYaTpSy/WaWtK+OHs0wxd2Sao=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3GnzKJVIawersT+IGGTGdFNaEfds5n7MkxrS7wykjDGkradIWN9D3Ym6ZAsPfeBr+ APyov9nm7ID30e7uvRFZUY6yWVa1AhbX4uii1RZusZXzVL31a3/ZRWbXmnKstVLlVZ NdMfWq+VBfZbmrb5D1lM9msQLfPR2pi8bWKfoQVY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1402932318; x=1403018718; i=@elandsys.com; bh=+BqxW+KUd8j8qkeVpGuYaTpSy/WaWtK+OHs0wxd2Sao=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3eJJjE9IT7fA1QHIq33HLJn8lQUpCZW5oE7ItIuM6BK+3DQs5UDbwlQ8xoUJxuyA5 w0e0DiYND6fmREd+hXTP6zEa/Hm0UQKL+sDUJVknsAhZZG9iRiaAd6pSVl6SLDluhd Y1fkvPu/Wdzrs5Am8EI5EqGaZ/J/uBIwEHhN1+YM= Message-Id: <6.2.5.6.2.20140616073720.0ab69b38@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 16 Jun 2014 08:21:44 -0700 To: "SHEPPARD, SCOTT" , Alain Durand , Igor Gashinsky , Donn Lee , Scott Sheppard From: S Moonesamy In-Reply-To: <8292A630AF4BC647B64BBD5097388209094628A5@GAALPA1MSGUSRAF.I TServices.sbc.com> References: <6.2.5.6.2.20140616024123.0ba53310@elandnews.com> <8292A630AF4BC647B64BBD5097388209094628A5@GAALPA1MSGUSRAF.ITServices.sbc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/Xb7VzDoSqAxU_EhMW4ZHQzTZcAQ Cc: int-area@ietf.org Subject: Re: [Int-area] Logging Recommendations for Internet-Facing Servers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 15:25:55 -0000 Hi Scott, At 06:49 16-06-2014, SHEPPARD, SCOTT wrote: >Can you be more specific in your concern? >" there has been some concerns about RFC 6302" > >I am willing to have a go but more focused guidance is needed here. There was a thread at http://www.ietf.org/mail-archive/web/perpass/current/msg00212.html My interpretation of the BCP is that it recommends saving information so that users can be tracked without taking into consideration the privacy implications. The BCP states that "data-retention policies are out of scope for [the] document". It can be argued that the IETF is recommending a best practice which is surveillance-friendly. My suggestion would be to give some thought to the privacy implications, get some (public) discussion about the matter and decide about the next steps. Regards, S. Moonesamy From nobody Mon Jun 16 14:13:29 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0A91A023C for ; Mon, 16 Jun 2014 14:13:27 -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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qU75b7JBN7Xo for ; Mon, 16 Jun 2014 14:13:24 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 662A51A0236 for ; Mon, 16 Jun 2014 14:13:24 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id fb1so2468607pad.0 for ; Mon, 16 Jun 2014 14:13:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=eS2bnQ3lEaPf7T4NDBlsKw1CAnXEJa6KYwSj2W6zTpA=; b=Yxol+oK6XGinFf85WvVCLs7sLSB+BXb2EQriuTwdFuFZo0GIPepJnhqgyIkFxHFpjJ RQNfPny2fawImyzEZeYJZSk0ed8t7t7a2KtgbG+MdWVt7V5N5IOK48vyefbH7lvvxtUo FyJvqucDiTyEGdGO1LvSC1XyfKevL4oTP07Tm7D6CkrPVXh1ca2MgIhnrigAZM8Ch7/F NDOJMlM22UaJdSmeWpkAEBDAlthfEYXCKm7NoPcah3n+FR+hRHnqg3cK70Xcd8c3Dri+ upqGyXaGiKVfhRfte+WQmo3tU9kD+j0vHY7VVB3DUFHJZfQnXiv+/x6Drdn9+zrMXysg 109Q== X-Gm-Message-State: ALoCoQmdMkzRYgJ85JCANvVwb+gGTMNuVvyBuNlIYFWQjAov9l0Da8fk/fm9YZSh9aqawUGEZf7Y X-Received: by 10.66.132.36 with SMTP id or4mr4749429pab.42.1402953204116; Mon, 16 Jun 2014 14:13:24 -0700 (PDT) Received: from [10.0.1.3] (c-24-6-168-86.hsd1.ca.comcast.net. [24.6.168.86]) by mx.google.com with ESMTPSA id tr2sm31755142pab.26.2014.06.16.14.13.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Jun 2014 14:13:23 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_63C10DC2-2898-43E1-A0EB-8781864AF206"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: David Conrad In-Reply-To: Date: Mon, 16 Jun 2014 14:13:20 -0700 Message-Id: References: To: Prashanth Patil X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/eGY2f_kquuZS_daBF-G0SSAymLQ Cc: int-area@ietf.org Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 21:13:27 -0000 --Apple-Mail=_63C10DC2-2898-43E1-A0EB-8781864AF206 Content-Type: multipart/alternative; boundary="Apple-Mail=_4F00B491-23B1-4743-98F7-81EA61DEC5F7" --Apple-Mail=_4F00B491-23B1-4743-98F7-81EA61DEC5F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm also in favor of adopting the draft. Regards, -drc On Jun 16, 2014, at 3:27 AM, Prashanth Patil = wrote: > I'm in favor of adopting this draft. The document describes relevant = use-cases for identifying hosts behind NAT, which is useful when = considering solutions. >=20 >=20 > -Prashanth > -----Original Message----- > From: Int-area [mailto:int-area-bounces at ietf.org] On Behalf Of = Suresh Krishnan > Sent: Thursday, June 05, 2014 9:51 AM > To: Internet Area > Subject: [Int-area] Call for adoption of = draft-boucadair-intarea-host-identifier-scenarios-04 >=20 > =20 > Hi all, >=20 > This draft was originally intended to be published as an AD = sponsored submission from the OPS area, but the authors have expressed = their interest to continue this work in the intarea wg given that = RFC6269 and RFC6967 originated here. The draft has been updated to = address the issues brought up during earlier discussions on the wg = mailing list and the latest version of the draft is available at >=20 > =20 > = http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenari= os-04 >=20 > =20 > This call is being initiated to determine whether there is WG = consensus towards adoption of = draft-boucadair-intarea-host-identifier-scenarios-04 as an intarea WG = draft. Please state whether or not you're in favor of the adoption by = replying to this email. If you are not in favor, please also state your = objections in your response. This adoption call will complete on = 2014-06-19. >=20 > =20 > Regards >=20 > Suresh & Juan Carlos >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area --Apple-Mail=_4F00B491-23B1-4743-98F7-81EA61DEC5F7 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii I'm also in favor of adopting the draft.

Regards,
-drc

On Jun 16, 2014, at 3:27 AM, Prashanth Patil <ppatil.ietf@gmail.com> wrote:

I'm in favor of adopting this draft. The document describes relevant use-cases for identifying hosts behind NAT, which is useful when considering solutions.

-Prashanth
-----Original Message-----

From: Int-area [mailto:int-area-bounces at ietf.org] On Behalf Of Suresh Krishnan
Sent: Thursday, June 05, 2014 9:51 AM
To: Internet Area
Subject: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04

 

Hi all,

   This draft was originally intended to be published as an AD sponsored submission from the OPS area, but the authors have expressed their interest to continue this work in the intarea wg given that RFC6269 and RFC6967 originated here. The draft has been updated to address the issues brought up during earlier discussions on the wg mailing list and the latest version of the draft is available at

 

http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04

 

This call is being initiated to determine whether there is WG consensus towards adoption of draft-boucadair-intarea-host-identifier-scenarios-04 as an intarea WG draft. Please state whether or not you're in favor of the adoption by replying to this email. If you are not in favor, please also state your objections in your response. This adoption call will complete on 2014-06-19.

 

Regards

Suresh & Juan Carlos

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

--Apple-Mail=_4F00B491-23B1-4743-98F7-81EA61DEC5F7-- --Apple-Mail=_63C10DC2-2898-43E1-A0EB-8781864AF206 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTn13wAAoJENV6ebf0/4rXV+oIALxr7ouCVyLOh5TOjJG3yB9K p7PRkUAGoeHRGV+zgh2bIpUq5QQ0ajBDMYUA8t+Robb5k1auLBMG5DSWnbFptny9 Dx/OSfF6tFIupbHV6fZpQMGnFD+4sM58O+EaI3839w8my6HE4P8iWgoGqB4MICoT v4ApJt2pPhl2J4RJv1L7QzdCHPqwqOZHpS0YxV4757Pz+uUAMaSUj8OA6MT/RtfT ERpR8b0gZtRgkvI28EOD0MepT2uhvS5MiO0fNmXLD58tzuXKUZyf1Ja62J0So70N HaTICvDA7cOsEWu8zI5255sRfchR3LwGruHZCU7ytNHtI4awfKKhJ45r7kd9e2M= =WcUS -----END PGP SIGNATURE----- --Apple-Mail=_63C10DC2-2898-43E1-A0EB-8781864AF206-- From nobody Tue Jun 17 05:58:01 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0571A0381 for ; Tue, 17 Jun 2014 05:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6Y9BDppKA_9 for ; Tue, 17 Jun 2014 05:57:52 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03461A0375 for ; Tue, 17 Jun 2014 05:57:51 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 3410F264253; Tue, 17 Jun 2014 14:57:50 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 009AE27C07C; Tue, 17 Jun 2014 14:57:50 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.12]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Tue, 17 Jun 2014 14:57:49 +0200 From: To: S Moonesamy , Alain Durand , Igor Gashinsky , Donn Lee , Scott Sheppard Thread-Topic: [Int-area] Logging Recommendations for Internet-Facing Servers Thread-Index: AQHPiUhcvUuzYw7mVEmJNSnOQhb3WZt1QHNQ Date: Tue, 17 Jun 2014 12:57:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330018425@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <6.2.5.6.2.20140616024123.0ba53310@elandnews.com> In-Reply-To: <6.2.5.6.2.20140616024123.0ba53310@elandnews.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.17.120320 Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/gUsGTT4PZ92E6ulSMWogVckFdho Cc: Linus Nordberg , "int-area@ietf.org" Subject: Re: [Int-area] Logging Recommendations for Internet-Facing Servers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 12:57:57 -0000 Hi SM, RFC6302 should be positioned in its context: i.e., how to meet regulatory r= equirements in some countries when address sharing is in use. A discussion = on the background (with a concise discussion on solution flavors and some h= ints on time duration to store log data) is available at: http://tools.ietf= .org/html/rfc6269#section-12 and http://tools.ietf.org/html/rfc6269#section= -13.1. The reco in RFC6302 aims to ease handling abuse claims and avoid revealing = the identity of a large number of subscribers. FYI, the penal procedure in = France has been updated in August 2013 to take into account address sharing= in particular, see for instance http://www.legifrance.gouv.fr/affichCodeAr= ticle.do?idArticle=3DLEGIARTI000028053220&cidTexte=3DLEGITEXT000006071154 w= here "additional information" should be provided in addition to the IP addr= ess for abuse claims). Privacy-related considerations and other side effects of storing IP address= es (including IP tracking) should be discussed IMHO independently of RFC630= 2. For example, the concrete case led by the CNIL in France: http://www.cni= l.fr/linstitution/actualite/article/article/ip-tracking-conclusions-de-lenq= uete-conjointe-menee-par-la-cnil-et-la-dgccrf/?tx_ttnews[backPid]=3D91&cHas= h=3D6c52ebf7fc988c0c7fe49410c4e69342.=20 Cheers, Med >-----Message d'origine----- >De=A0: Int-area [mailto:int-area-bounces@ietf.org] De la part de S Moonesa= my >Envoy=E9=A0: lundi 16 juin 2014 11:48 >=C0=A0: Alain Durand; Igor Gashinsky; Donn Lee; Scott Sheppard >Cc=A0: Linus Nordberg; int-area@ietf.org >Objet=A0: [Int-area] Logging Recommendations for Internet-Facing Servers > >Hello, > >In the wake of the revelations about surveillance there has been some >concerns about RFC 6302. I would be grateful if the authors of RFC >6302 could review the comments at >http://www.ietf.org/mail-archive/web/ietf-privacy/current/msg00454.html >and provide some feedback. > >Regards, >S. Moonesamy > >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area From nobody Tue Jun 17 07:59:01 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFBA1A0029 for ; Mon, 16 Jun 2014 06:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98T2hqwVg73O for ; Mon, 16 Jun 2014 06:49:50 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 865521A002E for ; Mon, 16 Jun 2014 06:49:48 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id cf5fe935.2b3fcd52b940.5812738.00-2428.16256132.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 16 Jun 2014 13:49:48 +0000 (UTC) X-MXL-Hash: 539ef5fc32cb6db6-96d68df8195a3eb297ad1ec0ddf92d4e98bf51ac Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id ce5fe935.0.5812569.00-2068.16255615.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 16 Jun 2014 13:49:46 +0000 (UTC) X-MXL-Hash: 539ef5fa7be8114b-6b4fad43cd460e0e0125dbc3575a2d8cd97d64b5 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5GDnW0p000650; Mon, 16 Jun 2014 09:49:32 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5GDnR8J000600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2014 09:49:28 -0400 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (GAALPA1MSGHUB9D.itservices.sbc.com [130.8.36.90]) by alpi133.aldc.att.com (RSA Interceptor); Mon, 16 Jun 2014 13:49:20 GMT Received: from GAALPA1MSGUSRAF.ITServices.sbc.com ([169.254.6.40]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.03.0174.001; Mon, 16 Jun 2014 09:49:20 -0400 From: "SHEPPARD, SCOTT" To: S Moonesamy , Alain Durand , Igor Gashinsky , Donn Lee , Scott Sheppard Thread-Topic: Logging Recommendations for Internet-Facing Servers Thread-Index: AQHPiUhYOawrDqtSa0WGCiVbPeYIxZtzwIUw Date: Mon, 16 Jun 2014 13:49:20 +0000 Message-ID: <8292A630AF4BC647B64BBD5097388209094628A5@GAALPA1MSGUSRAF.ITServices.sbc.com> References: <6.2.5.6.2.20140616024123.0ba53310@elandnews.com> In-Reply-To: <6.2.5.6.2.20140616024123.0ba53310@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.236.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=OMyQK1mB c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=Ug-TAP4kQqYA:10 a=ofMgfj31e3cA:10 a=hgubIOLJz70A:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=wPPvXI8NAAAA:8 a=48vgC7mUAAAA:8 a=6h9VOnCHJl68XYS] X-AnalysisOut: [HBhMA:9 a=CjuIK1q_8ugA:10 a=DswvqmXAlqEA:10 a=6twC2c18jGIA] X-AnalysisOut: [:10 a=2mDhba3wg4UA:10 a=7Nb30phM6KoA:10 a=JedbxzJ0HZAA:10 ] X-AnalysisOut: [a=Hz7IrDYlS0cA:10 a=pOcSzP0BEVkA:10 a=lZB815dzVvQA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/3rmdWrlJ2MSrczCU2y8jJVxOAWg X-Mailman-Approved-At: Tue, 17 Jun 2014 07:58:59 -0700 Cc: Linus Nordberg , "int-area@ietf.org" Subject: Re: [Int-area] Logging Recommendations for Internet-Facing Servers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 13:50:04 -0000 Hello Can you be more specific in your concern? " there has been some concerns about RFC 6302" I am willing to have a go but more focused guidance is needed here.=20 Peace Scott Sheppard LMTS AT&T ATS IPNSG=20 404 499 5539 desk 732 861 3383 cell ss6667@att.com email Two messages Authentic power is service - Pope Francis=20 Sillyness is Essential - The Three Stooges Both are important=20 This e-mail and any files transmitted with it are the property Of the AT&T companies, are confidential, and are intended solely For the use of the individual or entity to whom this e-mail is=20 Addressed. If you are not the one of the named recipients or=20 Otherwise have reason to believe that you have received this Message in error, please notify the sender at (732) 420-0965 and=20 Delete this message immediately from your computer. Any other Use, retention, dissemination, forwarding, printing, or copying Of this e-mail is strictly prohibited. -----Original Message----- From: S Moonesamy [mailto:sm+ietf@elandsys.com]=20 Sent: Monday, June 16, 2014 5:48 AM To: Alain Durand; Igor Gashinsky; Donn Lee; Scott Sheppard Cc: int-area@ietf.org; Linus Nordberg Subject: Logging Recommendations for Internet-Facing Servers Hello, In the wake of the revelations about surveillance there has been some=20 concerns about RFC 6302. I would be grateful if the authors of RFC=20 6302 could review the comments at=20 http://www.ietf.org/mail-archive/web/ietf-privacy/current/msg00454.html=20 and provide some feedback. Regards, S. Moonesamy From nobody Tue Jun 17 07:59:10 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14AE51A0025 for ; Tue, 17 Jun 2014 07:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9fELffPP8CE for ; Tue, 17 Jun 2014 07:37:32 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBF841A0002 for ; Tue, 17 Jun 2014 07:37:30 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id aa250a35.2b3f72a9a940.6526158.00-2431.18268485.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 17 Jun 2014 14:37:30 +0000 (UTC) X-MXL-Hash: 53a052aa7e1f148b-d3bc42dd7574d90e00ce5d791dce6c98a381d78c Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 69250a35.0.6525708.00-2221.18267192.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 17 Jun 2014 14:37:22 +0000 (UTC) X-MXL-Hash: 53a052a21cf3565d-2243d0e9a736197eb2fab977709d95443db2ee84 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5HEb9iY006264; Tue, 17 Jun 2014 10:37:09 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5HEb0j9005965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jun 2014 10:37:01 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (GAALPA1MSGHUB9C.itservices.sbc.com [130.8.36.89]) by alpi131.aldc.att.com (RSA Interceptor); Tue, 17 Jun 2014 14:36:50 GMT Received: from GAALPA1MSGUSRAF.ITServices.sbc.com ([169.254.6.40]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.03.0174.001; Tue, 17 Jun 2014 10:36:50 -0400 From: "SHEPPARD, SCOTT" To: "mohamed.boucadair@orange.com" , S Moonesamy , Igor Gashinsky , Donn Lee , Scott Sheppard , "alain.durand@me.com" Thread-Topic: [Int-area] Logging Recommendations for Internet-Facing Servers Thread-Index: AQHPiUhYOawrDqtSa0WGCiVbPeYIxZt1h/cA///WP2A= Date: Tue, 17 Jun 2014 14:36:50 +0000 Message-ID: <8292A630AF4BC647B64BBD509738820909462E3F@GAALPA1MSGUSRAF.ITServices.sbc.com> References: <6.2.5.6.2.20140616024123.0ba53310@elandnews.com> <787AE7BB302AE849A7480A190F8B9330018425@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330018425@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.204.104.113] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=OMyQK1mB c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=Fb9rBCq8oXkA:10 a=ofMgfj31e3cA:10 a=jaRjaomdIKgA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 a=nfdo3q8sAAAA:8 ] X-AnalysisOut: [a=W_ckQWI9AAAA:8 a=tperLt4SMB9uEP9AkhUA:9 a=wPNLvfGTeEIA:1] X-AnalysisOut: [0 a=DswvqmXAlqEA:10 a=6twC2c18jGIA:10 a=2mDhba3wg4UA:10 a=] X-AnalysisOut: [7Nb30phM6KoA:10 a=JedbxzJ0HZAA:10 a=Hz7IrDYlS0cA:10 a=oAXR] X-AnalysisOut: [_kdF8uMA:10 a=lZB815dzVvQA:10 a=_9qSGt5iiLdEEKXx:21 a=MpW_] X-AnalysisOut: [wR34AYoxqmvJ:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/DuBOHkBuj1aVUI6NDudy2M0gyng X-Mailman-Approved-At: Tue, 17 Jun 2014 07:59:00 -0700 Cc: Linus Nordberg , "int-area@ietf.org" Subject: Re: [Int-area] Logging Recommendations for Internet-Facing Servers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 14:37:42 -0000 Folks=20 To close this for now.=20 I see no compelling reason to change the BCP RFC 6302.=20 Privacy is important. But equally so is the need to protect our customers, = ourselves and the population against cyber criminals and they are legion. T= here is a compelling need for Law Enforcement Agencies and Governments to k= now some information about traffic as it relates to criminal and military a= cts (state sponsored cyber espionage etc.,). It is up to the civil authorit= ies to define what is "acceptable reach" for the above agencies actions. It= is up to us as citizens to then hold the civil authorities accountable at = least in the US.=20 This is far beyond an IETF discussion.=20 Peace Scott Sheppard LMTS AT&T ATS IPNSG=20 404 499 5539 desk 732 861 3383 cell ss6667@att.com email Two messages Authentic power is service - Pope Francis=20 Sillyness is Essential - The Three Stooges Both are important=20 This e-mail and any files transmitted with it are the property Of the AT&T companies, are confidential, and are intended solely For the use of the individual or entity to whom this e-mail is=20 Addressed. If you are not the one of the named recipients or=20 Otherwise have reason to believe that you have received this Message in error, please notify the sender at (732) 420-0965 and=20 Delete this message immediately from your computer. Any other Use, retention, dissemination, forwarding, printing, or copying Of this e-mail is strictly prohibited. -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: Tuesday, June 17, 2014 8:58 AM To: S Moonesamy; Alain Durand; Igor Gashinsky; Donn Lee; Scott Sheppard Cc: Linus Nordberg; int-area@ietf.org Subject: RE: [Int-area] Logging Recommendations for Internet-Facing Servers Hi SM, RFC6302 should be positioned in its context: i.e., how to meet regulatory r= equirements in some countries when address sharing is in use. A discussion = on the background (with a concise discussion on solution flavors and some h= ints on time duration to store log data) is available at: http://tools.ietf= .org/html/rfc6269#section-12 and http://tools.ietf.org/html/rfc6269#section= -13.1. The reco in RFC6302 aims to ease handling abuse claims and avoid revealing = the identity of a large number of subscribers. FYI, the penal procedure in = France has been updated in August 2013 to take into account address sharing= in particular, see for instance http://www.legifrance.gouv.fr/affichCodeAr= ticle.do?idArticle=3DLEGIARTI000028053220&cidTexte=3DLEGITEXT000006071154 w= here "additional information" should be provided in addition to the IP addr= ess for abuse claims). Privacy-related considerations and other side effects of storing IP address= es (including IP tracking) should be discussed IMHO independently of RFC630= 2. For example, the concrete case led by the CNIL in France: http://www.cni= l.fr/linstitution/actualite/article/article/ip-tracking-conclusions-de-lenq= uete-conjointe-menee-par-la-cnil-et-la-dgccrf/?tx_ttnews[backPid]=3D91&cHas= h=3D6c52ebf7fc988c0c7fe49410c4e69342.=20 Cheers, Med >-----Message d'origine----- >De=A0: Int-area [mailto:int-area-bounces@ietf.org] De la part de S Moonesa= my >Envoy=E9=A0: lundi 16 juin 2014 11:48 >=C0=A0: Alain Durand; Igor Gashinsky; Donn Lee; Scott Sheppard >Cc=A0: Linus Nordberg; int-area@ietf.org >Objet=A0: [Int-area] Logging Recommendations for Internet-Facing Servers > >Hello, > >In the wake of the revelations about surveillance there has been some >concerns about RFC 6302. I would be grateful if the authors of RFC >6302 could review the comments at >http://www.ietf.org/mail-archive/web/ietf-privacy/current/msg00454.html >and provide some feedback. > >Regards, >S. Moonesamy > >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area From nobody Tue Jun 17 13:06:14 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124AE1A00DF for ; Tue, 17 Jun 2014 13:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9VtKfl2fxkH for ; Tue, 17 Jun 2014 13:06:04 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7491A017B for ; Tue, 17 Jun 2014 13:05:48 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.146.13]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s5HK5S5J004005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jun 2014 13:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1403035541; x=1403121941; bh=53dy6JFO5vAxsflNLMn2UqBd7VVFCpLEwkA3M9lQRc8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3GzQGrSU8cUpFQ7FOO9iyFoxe8/aD4J3gyVftfwP2eDGnQoDxkEAnJppR6AzBdTYv Y+iQC6EDF0LVwuWTWIASUoT1Zhp15LJgpTiKWsT6er7zGtB4RWqw8FDvOtGN/L4PKH v7YSEpjsf+K8i9fF7chMLJsmWL2Se1oU+XJgCghg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1403035541; x=1403121941; i=@elandsys.com; bh=53dy6JFO5vAxsflNLMn2UqBd7VVFCpLEwkA3M9lQRc8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=SBFtlAKs5Twm74CiCK+qvxapCVU8R9TVMx8dOJsltmJJYpGSDlMzmf+Egm8TQzPvf di+Cci7tDI6GEApH6u3VK4wOEZKYZShjfWakRvuR2EjdzWE9j//8IYQID9W/zkRlmv +ywhuVYftAbh2Go5PL4FFN7KQgStPGCYTb+452BM= Message-Id: <6.2.5.6.2.20140617112211.0bb1a980@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 17 Jun 2014 11:58:40 -0700 To: Suresh Krishnan , Juan-Carlos =?iso-8859-1?Q?Z=FA=F1iga?= From: S Moonesamy In-Reply-To: <8292A630AF4BC647B64BBD509738820909462E3F@GAALPA1MSGUSRAF.I TServices.sbc.com> References: <6.2.5.6.2.20140616024123.0ba53310@elandnews.com> <787AE7BB302AE849A7480A190F8B9330018425@OPEXCLILM23.corporate.adroot.infra.ftgroup> <8292A630AF4BC647B64BBD509738820909462E3F@GAALPA1MSGUSRAF.ITServices.sbc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/pzAK8pwP6wfe6ayAsPFn-H1GGRA Cc: Scott Sheppard , int-area@ietf.org Subject: Re: [Int-area] Logging Recommendations for Internet-Facing Servers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 20:06:07 -0000 Hi Suresh, Juan-Carlos, At 07:36 17-06-2014, SHEPPARD, SCOTT wrote: >To close this for now. > >I see no compelling reason to change the BCP RFC 6302. > >Privacy is important. But equally so is the need to protect our >customers, ourselves and the population against cyber criminals and >they are legion. There is a compelling need for Law Enforcement >Agencies and Governments to know some information about traffic as >it relates to criminal and military acts (state sponsored cyber >espionage etc.,). It is up to the civil authorities to define what >is "acceptable reach" for the above agencies actions. It is up to us >as citizens to then hold the civil authorities accountable at least in the US. > >This is far beyond an IETF discussion. The following in an excerpt of a message posted by the IAB Chair to ietf@ietf.org in 2013: "1. The IETF is willing to respond to the pervasive surveillance attack? Overwhelming YES. Silence for NO. 2. Pervasive surveillance is an attack, and the IETF needs to adjust our threat model to consider it when developing standards track specifications. Very strong YES. Silence for NO." Some persons raised concerns about those hums. I would not ignore the concerns of those persons or argue that they have to agree to the excerpt quoted above. There was a four-weeks Last Call for RFC 7258. Several persons raised concerns about the document. I would not argue that they have to agree to RFC 7258. I would like to have your opinion about which points (see quoted message) are appropriate or inappropriate for INTAREA discussion. Regards, S. Moonesamy From nobody Tue Jun 17 13:28:17 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC21A1A0169 for ; Tue, 17 Jun 2014 13:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCXlz5Px_Hec for ; Tue, 17 Jun 2014 13:28:14 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 086A81A0166 for ; Tue, 17 Jun 2014 13:28:14 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s5HKR9F2020210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 17 Jun 2014 13:27:09 -0700 (PDT) Message-ID: <53A0A49D.9040202@isi.edu> Date: Tue, 17 Jun 2014 13:27:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: S Moonesamy , Suresh Krishnan , =?ISO-8859-1?Q?Juan-Carlos_Z=FA=F1iga?= References: <6.2.5.6.2.20140616024123.0ba53310@elandnews.com> <787AE7BB302AE849A7480A190F8B9330018425@OPEXCLILM23.corporate.adroot.infra.ftgroup> <8292A630AF4BC647B64BBD509738820909462E3F@GAALPA1MSGUSRAF.ITServices.sbc.com> <6.2.5.6.2.20140617112211.0bb1a980@elandnews.com> In-Reply-To: <6.2.5.6.2.20140617112211.0bb1a980@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/DwtBFEsZeDLbqm7I3E5nUYO36iM Cc: Scott Sheppard , int-area@ietf.org Subject: Re: [Int-area] Logging Recommendations for Internet-Facing Servers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 20:28:17 -0000 On 6/17/2014 11:58 AM, S Moonesamy wrote: ... > Some persons raised concerns about those hums. Hums aren't votes. It might represent those in attendance - but not everyone attends meetings in general or plenaries in specific. The key to understanding a BCP is its 2119-language. Because there wasn't any in RFC 7258 (2119 isn't even cited), there was nothing to really object to. Joe From nobody Tue Jun 17 13:34:29 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3348E1A016B for ; Tue, 17 Jun 2014 13:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.551 X-Spam-Level: X-Spam-Status: No, score=-4.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rasN1UPSnO5b for ; Tue, 17 Jun 2014 13:34:23 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750051A0168 for ; Tue, 17 Jun 2014 13:34:22 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id e46a0a35.2ba82b80b940.4843194.00-2434.12414842.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 17 Jun 2014 20:34:22 +0000 (UTC) X-MXL-Hash: 53a0a64e274722ef-c6b5382ee027e1820126f52eec4cbbbcacb58891 Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id f36a0a35.0.4843037.00-2326.12414395.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 17 Jun 2014 20:34:19 +0000 (UTC) X-MXL-Hash: 53a0a64b2e22462b-a33cbfb80b5eb4e951498a9421b36a6de70e3058 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5HKY6Ho018419; Tue, 17 Jun 2014 16:34:07 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5HKY1DS018334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jun 2014 16:34:02 -0400 Received: from GAALPA1MSGHUB9A.ITServices.sbc.com (GAALPA1MSGHUB9A.itservices.sbc.com [130.8.36.87]) by alpi132.aldc.att.com (RSA Interceptor); Tue, 17 Jun 2014 20:33:48 GMT Received: from GAALPA1MSGUSRAF.ITServices.sbc.com ([169.254.6.40]) by GAALPA1MSGHUB9A.ITServices.sbc.com ([130.8.36.87]) with mapi id 14.03.0174.001; Tue, 17 Jun 2014 16:33:48 -0400 From: "SHEPPARD, SCOTT" To: S Moonesamy , Suresh Krishnan , =?iso-8859-1?Q?Juan-Carlos_Z=FA=F1iga?= Thread-Topic: [Int-area] Logging Recommendations for Internet-Facing Servers Thread-Index: AQHPimeJjb6IbTesrUmSr8bliEscrZt1vt/g Date: Tue, 17 Jun 2014 20:33:47 +0000 Message-ID: <8292A630AF4BC647B64BBD50973882090946307D@GAALPA1MSGUSRAF.ITServices.sbc.com> References: <6.2.5.6.2.20140616024123.0ba53310@elandnews.com> <787AE7BB302AE849A7480A190F8B9330018425@OPEXCLILM23.corporate.adroot.infra.ftgroup> <8292A630AF4BC647B64BBD509738820909462E3F@GAALPA1MSGUSRAF.ITServices.sbc.com> <6.2.5.6.2.20140617112211.0bb1a980@elandnews.com> In-Reply-To: <6.2.5.6.2.20140617112211.0bb1a980@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.204.104.113] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Ro1y2laK c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=Fb9rBCq8oXkA:10 a=ofMgfj31e3cA:10 a=jaRjaomdIKgA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=wPPvXI8NAAAA:8 a=48vgC7mUAAAA:8 a=tnvV_-ysobBY2L0] X-AnalysisOut: [J6DEA:9 a=wPNLvfGTeEIA:10 a=DswvqmXAlqEA:10 a=6twC2c18jGIA] X-AnalysisOut: [:10 a=2mDhba3wg4UA:10 a=7Nb30phM6KoA:10 a=Hz7IrDYlS0cA:10 ] X-AnalysisOut: [a=pOcSzP0BEVkA:10 a=lZB815dzVvQA:10 a=fqmVbpKOml3tncJp:21 ] X-AnalysisOut: [a=k4qXlG_-biuP39rL:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/6bRi8n21T45RZP_etWoSVGCnjbc Cc: Scott Sheppard , "int-area@ietf.org" , "alain.durand@me.com" Subject: Re: [Int-area] Logging Recommendations for Internet-Facing Servers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 20:34:27 -0000 S. Moonesamy I am not going to debate with you. "Pervasive surveillance is an attack". T= o me this is a debate : Resolved: Pervasive surveillance is an attack. I will read and, if needed, comment where appropriate with interest RFC 725= 8 with a technical not political view. =20 I thank you for bringing this to my attention.=20 As I am work, I will not respond any further from my work address. I will c= reate an email alias for this discussion and distribute it. I do welcome th= e discussion.=20 Peace Scott Sheppard LMTS AT&T ATS IPNSG=20 404 499 5539 desk 732 861 3383 cell ss6667@att.com email Two messages Authentic power is service - Pope Francis=20 Sillyness is Essential - The Three Stooges Both are important=20 This e-mail and any files transmitted with it are the property Of the AT&T companies, are confidential, and are intended solely For the use of the individual or entity to whom this e-mail is=20 Addressed. If you are not the one of the named recipients or=20 Otherwise have reason to believe that you have received this Message in error, please notify the sender at (732) 420-0965 and=20 Delete this message immediately from your computer. Any other Use, retention, dissemination, forwarding, printing, or copying Of this e-mail is strictly prohibited. -----Original Message----- From: S Moonesamy [mailto:sm+ietf@elandsys.com]=20 Sent: Tuesday, June 17, 2014 2:59 PM To: Suresh Krishnan; Juan-Carlos Z=FA=F1iga Cc: int-area@ietf.org; Scott Sheppard Subject: RE: [Int-area] Logging Recommendations for Internet-Facing Servers Hi Suresh, Juan-Carlos, At 07:36 17-06-2014, SHEPPARD, SCOTT wrote: >To close this for now. > >I see no compelling reason to change the BCP RFC 6302. > >Privacy is important. But equally so is the need to protect our=20 >customers, ourselves and the population against cyber criminals and=20 >they are legion. There is a compelling need for Law Enforcement=20 >Agencies and Governments to know some information about traffic as=20 >it relates to criminal and military acts (state sponsored cyber=20 >espionage etc.,). It is up to the civil authorities to define what=20 >is "acceptable reach" for the above agencies actions. It is up to us=20 >as citizens to then hold the civil authorities accountable at least in the= US. > >This is far beyond an IETF discussion. The following in an excerpt of a message posted by the IAB Chair to=20 ietf@ietf.org in 2013: "1. The IETF is willing to respond to the pervasive surveillance attack? Overwhelming YES. Silence for NO. 2. Pervasive surveillance is an attack, and the IETF needs to=20 adjust our threat model to consider it when developing standards track specifications. Very strong YES. Silence for NO." Some persons raised concerns about those hums. I would not ignore=20 the concerns of those persons or argue that they have to agree to the=20 excerpt quoted above. There was a four-weeks Last Call for RFC=20 7258. Several persons raised concerns about the document. I would=20 not argue that they have to agree to RFC 7258. I would like to have your opinion about which points (see quoted=20 message) are appropriate or inappropriate for INTAREA discussion. Regards, S. Moonesamy =20 From nobody Tue Jun 17 13:47:55 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473291A0110 for ; Tue, 17 Jun 2014 13:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9brj_Mh0bxjb for ; Tue, 17 Jun 2014 13:47:53 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80FC1A010F for ; Tue, 17 Jun 2014 13:47:52 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-c2-53a055e25601 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 98.AF.11744.2E550A35; Tue, 17 Jun 2014 16:51:14 +0200 (CEST) Received: from [142.133.113.185] (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.87) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 17 Jun 2014 16:47:44 -0400 Message-ID: <53A0A96E.3050006@ericsson.com> Date: Tue, 17 Jun 2014 16:47:42 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "SHEPPARD, SCOTT" , "mohamed.boucadair@orange.com" , S Moonesamy , Igor Gashinsky , Donn Lee , Scott Sheppard , "alain.durand@me.com" References: <6.2.5.6.2.20140616024123.0ba53310@elandnews.com> <787AE7BB302AE849A7480A190F8B9330018425@OPEXCLILM23.corporate.adroot.infra.ftgroup> <8292A630AF4BC647B64BBD509738820909462E3F@GAALPA1MSGUSRAF.ITServices.sbc.com> In-Reply-To: <8292A630AF4BC647B64BBD509738820909462E3F@GAALPA1MSGUSRAF.ITServices.sbc.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [147.117.188.8] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyuXRPuO6j0AXBBq+uiVv0zljCbvHv53xW i8YvE1ksbsy6yWKx5dp3dovDb5+yW1xpVbd41X+T1eLSiRVsDpweL/vnMHrce/ORyWNi8zt2 jyVLfjJ5vDhf4TGn4z67R8uzk2wed1b9YgzgiOKySUnNySxLLdK3S+DKmHBlKkvBPO6KfZu+ szQwNnN2MXJySAiYSPyY1cQKYYtJXLi3nq2LkYtDSOAoo0TLk3vMEM52Romm43fAqngFtCXW XJ8DZrMIqEos+bsEzGYDmrRh52cmEFtUIEyi/cJMZoh6QYmTM5+wgAwSEVjEJDH92yRGkASz QKDEvtVtbCC2sIC3ROvF5awQ2+4zSqy7tZYFJMEpECVx/NcUZogGW4kLc66zQNjyEtvfzgGL CwloSmxd8x3qB0WJF8d/Mk1gFJqFZPksJO2zkLQvYGRexchRWpxalptuZLiJERgxxyTYHHcw LvhkeYhRgINRiYf3geeCYCHWxLLiytxDjNIcLErivJrV84KFBNITS1KzU1MLUovii0pzUosP MTJxcEo1MDJwZ7B+fJlXLWEWePGGgtesmx5PHC4/qci5eMH9XpGcy5FNXa84/s7pvrJ1zxKl rhavC41ezHFSYlyZukoBB0sStOfMnLb9+4sr2Rsuuu+9q6HDYmhq8rAgvPLI6uR7jLdk3v6K zius+f7ps/FzIbOd+4tf+d355+i5+qvrgpbWl1fm7K8TnK/EUpyRaKjFXFScCAARzQtAeQIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/m0-EXSoxNcvGpMpuTuSI3H8vgoY Cc: Linus Nordberg , "int-area@ietf.org" Subject: Re: [Int-area] Logging Recommendations for Internet-Facing Servers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 20:47:54 -0000 Hi Scott, (with Chair hat on) On 06/17/2014 10:36 AM, SHEPPARD, SCOTT wrote: > Folks > > To close this for now. > > I see no compelling reason to change the BCP RFC 6302. Thanks for providing your opinion. I think opinions from operators are extremely useful and helpful. > > Privacy is important. But equally so is the need to protect our customers, ourselves and the population against cyber criminals and they are legion. There is a compelling need for Law Enforcement Agencies and Governments to know some information about traffic as it relates to criminal and military acts (state sponsored cyber espionage etc.,). It is up to the civil authorities to define what is "acceptable reach" for the above agencies actions. It is up to us as citizens to then hold the civil authorities accountable at least in the US. > > This is far beyond an IETF discussion. I think there is a delicate balance between protecting the users' privacy and implementing the operators' requirements for traceability. If by "far beyond an IETF discussion" you mean that recommendations from the IETF are only one consideration among many for real life deployments, I fully agree with you. But what the IETF publishes as a BCP is within the purview of the IETF, and it is entirely reasonable for people to initiate discussion on whether the recommendations in RFC6302 are current in light of RFC7258. Thanks Suresh From nobody Tue Jun 17 14:17:36 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0B21A0174 for ; Tue, 17 Jun 2014 14:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raQijB8vh-15 for ; Tue, 17 Jun 2014 14:17:32 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EBA31A0170 for ; Tue, 17 Jun 2014 14:17:32 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-2a-53a05cdb4b7d Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 13.21.11744.BDC50A35; Tue, 17 Jun 2014 17:20:59 +0200 (CEST) Received: from [142.133.113.185] (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.78) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 17 Jun 2014 17:17:30 -0400 Message-ID: <53A0B06C.1090604@ericsson.com> Date: Tue, 17 Jun 2014 17:17:32 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: S Moonesamy , =?ISO-8859-1?Q?Juan-Carlos_Z=FA?= =?ISO-8859-1?Q?=F1iga?= References: <6.2.5.6.2.20140616024123.0ba53310@elandnews.com> <787AE7BB302AE849A7480A190F8B9330018425@OPEXCLILM23.corporate.adroot.infra.ftgroup> <8292A630AF4BC647B64BBD509738820909462E3F@GAALPA1MSGUSRAF.ITServices.sbc.com> <6.2.5.6.2.20140617112211.0bb1a980@elandnews.com> In-Reply-To: <6.2.5.6.2.20140617112211.0bb1a980@elandnews.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [147.117.188.8] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyuXSPn+7tmAXBBnOPWVrcmHWTxeLdgalM Flda1S1e9d9kdWDxeNk/h9Hj3puPTB5Llvxk8lh6vY01gCWKyyYlNSezLLVI3y6BK+No0we2 gnv8FZueTmFrYFzF08XIySEhYCLR9PYJM4QtJnHh3no2EFtI4CijxP39fF2MXED2dkaJvYu+ giV4BbQl+nesYQGxWQRUJWZv6mYHsdmABm3Y+ZkJxBYVCJNovzCTGaJeUOLkzCcsIINEBDoY JR7+esEIkmAWcJD4cHIZWIOwgLdE68XlrBDbJjJJTLl8AaiDg4NTwE5i1vJMiHpbiQtzrrNA 2PIS29/OYYa4VFNi65rvrBAfKEq8OP6TaQKj0Cwku2chaZ+FpH0BI/MqRo7S4tSy3HQjw02M wKA+JsHmuINxwSfLQ4wCHIxKPLwPPBcEC7EmlhVX5h5ilOZgURLn1ayeFywkkJ5YkpqdmlqQ WhRfVJqTWnyIkYmDU6qBccULPf7C8PxQpU0Bnae/qKcvn7bd41FCcsmWrwaqu0+fT740fdH9 GVcOLxKwz2ad27JYtpspyNRAoCFwxuYVoo+rLbTmKGXaxM+I9o882cC35MPDB7Orm+0LDm+/ zraGobbqpPT//G6WHeuuL7i3lo/7UZa/9qPO2UVb/q/aF68otjg10W6uvBJLcUaioRZzUXEi AOF87B1LAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/AxBeAIARiGpHGIykyQGUON11G4k Cc: Scott Sheppard , int-area@ietf.org Subject: Re: [Int-area] Logging Recommendations for Internet-Facing Servers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 21:17:33 -0000 Hi SM, On 06/17/2014 02:58 PM, S Moonesamy wrote: > Hi Suresh, Juan-Carlos, > At 07:36 17-06-2014, SHEPPARD, SCOTT wrote: >> To close this for now. >> >> I see no compelling reason to change the BCP RFC 6302. >> >> Privacy is important. But equally so is the need to protect our >> customers, ourselves and the population against cyber criminals and >> they are legion. There is a compelling need for Law Enforcement >> Agencies and Governments to know some information about traffic as it >> relates to criminal and military acts (state sponsored cyber espionage >> etc.,). It is up to the civil authorities to define what is >> "acceptable reach" for the above agencies actions. It is up to us as >> citizens to then hold the civil authorities accountable at least in >> the US. >> >> This is far beyond an IETF discussion. > > The following in an excerpt of a message posted by the IAB Chair to > ietf@ietf.org in 2013: > > "1. The IETF is willing to respond to the pervasive surveillance attack? > > Overwhelming YES. Silence for NO. > > 2. Pervasive surveillance is an attack, and the IETF needs to adjust > our threat model > to consider it when developing standards track specifications. > > Very strong YES. Silence for NO." > > Some persons raised concerns about those hums. I would not ignore the > concerns of those persons or argue that they have to agree to the > excerpt quoted above. There was a four-weeks Last Call for RFC 7258. > Several persons raised concerns about the document. I would not argue > that they have to agree to RFC 7258. > > I would like to have your opinion about which points (see quoted > message) are appropriate or inappropriate for INTAREA discussion. As intarea was the wg that produced RFC6302, any discussions regarding issues you want to bring up regarding that document are perfectly appropriate on this mailing list. Please go ahead and continue the discussion. Thanks Suresh From nobody Tue Jun 17 14:24:40 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FA01A0168 for ; Tue, 17 Jun 2014 14:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.501 X-Spam-Level: X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeSpcJ8Cf_mu for ; Tue, 17 Jun 2014 14:24:26 -0700 (PDT) Received: from office.denic.de (office.denic.de [81.91.160.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F79F1A017C for ; Tue, 17 Jun 2014 14:24:26 -0700 (PDT) Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtp id 1Wx0rg-0001nL-KA; Tue, 17 Jun 2014 23:24:24 +0200 Received: from localhost by x27.adm.denic.de with local id 1Wx0rg-0003eK-Fl; Tue, 17 Jun 2014 23:24:24 +0200 Date: Tue, 17 Jun 2014 23:24:24 +0200 From: Peter Koch To: int-area@ietf.org Message-ID: <20140617212424.GV6928@x28.adm.denic.de> Mail-Followup-To: int-area@ietf.org References: <6.2.5.6.2.20140616024123.0ba53310@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20140616024123.0ba53310@elandnews.com> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/fIMDfhZK-E1SA2HB3NQ2tHHDVu0 Subject: Re: [Int-area] Logging Recommendations for Internet-Facing Servers X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 21:24:29 -0000 SM, > In the wake of the revelations about surveillance there has been some > concerns about RFC 6302. I would be grateful if the authors of RFC > 6302 could review the comments at > http://www.ietf.org/mail-archive/web/ietf-privacy/current/msg00454.html > and provide some feedback. not one of the authors, but still: the document basically says that _if_ you log, you ought to log port numbers (and timestamps) in addition to IP addresses. The question whether to log (the _if_ above) is, in my reading, and hindsight, addressed (by way of abstention) by the paragraph starting: Discussions about data-retention policies are out of scope for this document. [...] Of course, RFC 6302 is easily read as the IETF recommending "full" logging. I doubt that it is in the best interest of the IETF to be misinterpreted that lightly, but that was already the fact in June 2011. Changing the message to "IP address and timestamp might not be sufficient to identify a system or user" and not calling it a "BCP" has an odd chance of mitigating the misunderstandings. An IETF position on "do or do not log" is likely irrelevant given (competing, conflicting) regulatory requirements and legislation/court rulings on data protection. -Peter From nobody Thu Jun 19 15:38:45 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF421A0320 for ; Thu, 19 Jun 2014 15:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPbuRm2ePHvl for ; Thu, 19 Jun 2014 15:38:40 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECDDD1A0183 for ; Thu, 19 Jun 2014 15:38:39 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A83E9215D8 for ; Thu, 19 Jun 2014 18:38:38 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Thu, 19 Jun 2014 18:38:38 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:message-id:mime-version:content-type; s=mesmtp; bh=KvA4Nbd8gi1JNk0t42SDB2e3dt8=; b=ifQpx5PJ/VPFF9yXVw4/NR0YwEcv uGZqfl/ynvcqq8L+FIAlSsR3icf3w/PtsSNTKbb7j12p07mIbhohcvG29znQ1DKr eH+jBzh1rLdTP/PbD6MkBEoQa0TyKWEXWdPtZSHIleKVBVe2YbTAJwuXisulYO5d X1ENVH72Hg8CHEw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:message-id :mime-version:content-type; s=smtpout; bh=KvA4Nbd8gi1JNk0t42SDB2 e3dt8=; b=enKMZEqkdo6Hl8Fe68xF9hcXEUN3dgbHps5AXhLWxUkVXUNvfTUpOC N5FXUpU4FSyo2mW/Iv85yOooqiZXPa1pGsBdexGNRkZtwQFjusZ9kQ36IvtJoqR6 SVkszgKyBntfjQIFWGGbnoiBsbIjrjcxQS1mpJuPOPs3CeHsByTos= X-Sasl-enc: L3jP5f3znOQeQ07PWTAySVogvoaRJOT9TTRLwCiGGTuq 1403217517 Received: from [171.68.18.56] (unknown [171.68.18.56]) by mail.messagingengine.com (Postfix) with ESMTPA id 9C81BC00005; Thu, 19 Jun 2014 18:38:36 -0400 (EDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Thu, 19 Jun 2014 15:38:30 -0700 From: Alissa Cooper To: Suresh Krishnan , Internet Area Message-ID: Thread-Topic: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3486037117_89378581" Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/bp-sAl9q9OSdCmbElShsDzH7b0I Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 22:38:44 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3486037117_89378581 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I guess it is a feature of area WGs that the sequence of work items is not well-defined in advance of taking up any particular work items, nor are those work items correlated to WG milestones (I looked at the intarea milestones, dated to 2010, so I assume milestones are not used in this group). In the case of the host ID work, this seems particularly unfortunate. I don=E2=80=99t think it=E2=80=99s often the case that a draft outlining solutions is published in advance of a draft that describes use cases for those solutions, but that seems to be the direction of the effort here. And I think this conflation of problems, what the draft in question calls =E2=80=9Cus= e cases,=E2=80=9D and solutions is creating a source of tension here. The list of =E2=80=9Cuse cases=E2=80=9D in this draft mixes a number of different thing= s: some of them are architectures that introduce address sharing; some of them are technologies that introduce address sharing; and others are functions/services that may be hampered by the presence of address sharing. The draft further contains a list of problems observed in the presence of address sharing (in section 1). Under the assumption that it is useful to publish a =E2=80=9Cuse cases=E2=80=9D draft for the purpose of determining whether a particular future solution proposal addresses one or more use cases, I thin= k the confusion in this draft may actually make that task harder rather than easier. Another issue stems from the way the root problem is described in this draft: "the issue of uniquely identifying a host.=E2=80=9D This is a description = of a solution, not a problem. The kinds of problems that I see in the draft are, e.g., =E2=80=9CI want to apply a traffic management policy to a user and I can=E2=80=99t,=E2=80=9D =E2=80=9CI want to know the source of an emergency call and I can=E2=80=99t= figure it out,=E2=80=9D or =E2=80=9CI want to blacklist one subscriber without affecting other= s.=E2=80=9D Not all of these problems will be served by =E2=80=9Cuniquely identifying a host,= =E2=80=9D some of them already have domain- or application-specific solutions, and some of them are not legitimate problems IMO (e.g., using source IP address as an authenticator). Teasing the separate problems out from each other would help to understand where a generic solution might be necessary and where existing solutions are already sufficient. To me what would be useful here would be a document that points out new problems beyond those identified in RFC 6269 that arise in address-sharing or tunneled architectures not already contemplated in that document. If there aren=E2=80=99t new problems, then I=E2=80=99m not sure why 6269 is not considered= a sufficient description of the problem space. If there are new problems, the= n between RFC 6269 and the new draft there would be a fairly comprehensive list of them documented, and that could provide a foundation for figuring out how to solve some or all of them, whether some of them have existing solutions, and how potential new solutions relate to embedding a unique hos= t identifier at the network or transport layer. Alissa > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Suresh Kri= shnan > Sent: Thursday, June 05, 2014 9:51 AM > To: Internet Area > Subject: [Int-area] Call for adoption of > draft-boucadair-intarea-host-identifier-scenarios-04 > =20 > Hi all, > This draft was originally intended to be published as an AD sponsored > submission from the OPS area, but the authors have expressed their intere= st to > continue this work in the intarea wg given that RFC6269 and RFC6967 origi= nated > here. The draft has been updated to address the issues brought up during > earlier discussions on the wg mailing list and the latest version of the = draft > is available at > =20 >=20 http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenario= s-0> 4 > =20 > This call is being initiated to determine whether there is WG consensus > towards adoption of draft-boucadair-intarea-host-identifier-scenarios-04 = as an > intarea WG draft. Please state whether or not you're in favor of the adop= tion > by replying to this email. If you are not in favor, please also state you= r > objections in your response. This adoption call will complete on 2014-06-= 19. > =20 > Regards > Suresh & Juan Carlos > =20 --B_3486037117_89378581 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
I guess it is a featu= re of area WGs that the sequence of work items is not well-defined in advanc= e of taking up any particular work items, nor are those work items correlate= d to WG milestones (I looked at the intarea milestones, dated to 2010, so I = assume milestones are not used in this group). In the case of the host ID wo= rk, this seems particularly unfortunate. I don’t think it’s ofte= n the case that a draft outlining solutions is published in advance of a dra= ft that describes use cases for those solutions, but that seems to be the di= rection of the effort here. And I think this conflation of problems, what th= e draft in question calls “use cases,” and solutions is creating= a source of tension here.

The list of R= 20;use cases” in this draft mixes a number of different things: some o= f them are architectures that introduce address sharing; some of them are te= chnologies that introduce address sharing; and others are functions/services= that may be hampered by the presence of address sharing. The draft further = contains a list of problems observed in the presence of address sharing (in = section 1). Under the assumption that it is useful to publish a “use c= ases” draft for the purpose of determining whether a particular future= solution proposal addresses one or more use cases, I think the confusion in= this draft may actually make that task harder rather than easier.

Another issue stems from= the way the root problem is described in this draft: "the issue of uniquely identifying a host. This is a description of a solution, not a problem. = The kinds of problems that I see in the draft are, e.g., “= I want to apply a traffic management policy to= a user and I cant,”= ; I want to know the source of an emergency call and I can’<= span style=3D"font-size: 1em;">t figure it out,” or I wan= t to blacklist one subscriber without affecting others. Not all of these problems will be served by&nbs= p;uniquely identifying a host, some of them already have do= main- or application-specific solutions, and some of them are not legitimate= problems IMO (e.g., using source IP address as an authenticator). Teasing t= he separate problems out from each other would help to understand where a ge= neric solution might be necessary and where existing solutions are already s= ufficient.

To me what would be useful= here would be a document that points out new problems beyond those identifi= ed in RFC 6269 that arise in address-sharing or tunneled architectures not a= lready contemplated in that document. If there aren’t new problems, th= en I’m not sure why 6269 is not considered a sufficient description of= the problem space. If there are new problems, then between RFC 6269 and the= new draft there would be a fairly comprehensive list of them documented, an= d that could provide a foundation for figuring out how to solve some or all = of them, whether some of them have existing solutions, and how potential new= solutions relate to embedding a unique host identifier at the network or tr= ansport layer.

Alissa


<= b>From: Int-a= rea [mailto:int-area-bounces@ietf= .org] On Behalf Of Suresh Krishnan
Sent: Thursday, June 05, 2014= 9:51 AM
To: Internet Area
Subject: [Int-area] Call for = adoption of draft-boucadair-intarea-host-identifier-scenarios-04<= /span>

&= nbsp;

Hi all,

   This draft was originally inten= ded to be published as an AD sponsored submission from the OPS area, but the= authors have expressed their interest to continue this work in the intarea = wg given that RFC6269 and RFC6967 originated here. The draft has been updated= to address the issues brought up during earlier discussions on the wg maili= ng list and the latest version of the draft is available at

<= o:p> 

http://tools.ietf.org/html/draft-boucadai= r-intarea-host-identifier-scenarios-04

 <= /span>

This call is being initiated to determine whether there is WG consensus = towards adoption of draft-boucadair-intarea-host-identifier-scenarios-04 as = an intarea WG draft. Please state whether or not you're in favor of the adoption by replying to this email. If you a= re not in favor, please also state your objections in your response. This ad= option call will complete on 2014-06-19.

 

Regards

Suresh & Juan Carlos

 

--B_3486037117_89378581-- From nobody Thu Jun 19 21:41:37 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2671A04F6 for ; Thu, 19 Jun 2014 21:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QeyK_4EtDmS for ; Thu, 19 Jun 2014 21:41:33 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494C31A04B7 for ; Thu, 19 Jun 2014 21:41:33 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-0e-53a36a3b509c Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 41.7D.27529.B3A63A35; Fri, 20 Jun 2014 00:54:52 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Fri, 20 Jun 2014 00:41:31 -0400 From: Suresh Krishnan To: Alissa Cooper , Internet Area Thread-Topic: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 Thread-Index: AQHPjA85d6Wh8FQ8+EWiGuHm0y/l1w== Date: Fri, 20 Jun 2014 04:41:31 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyuXRPrK5N1uJgg5Y1QhbTz/xltLgx6yaL A5PHlycvmTyWLPnJFMAUxWWTkpqTWZZapG+XwJWx5Lx5wUmhinWPzjA3MP7m62Lk5JAQMJG4 /nAWI4QtJnHh3nq2LkYuDiGBo4wSt0/uYIJwljNKnNvXzApSxQbUsWHnZyYQW0TAQ+L+s13s ILawQLLEhI7XQDYHUDxFou25IkSJnsT+p+fBylkEVCUm3VoBZvMK+EpM/9LMAmILAdWcaN4P FmcEOuL7qTVgNrOAuMStJ/OZII4TkFiy5zwzhC0q8fLxP1YIW0lizutrzBD1BhLvz82HsrUl li18zQyxS1Di5MwnLBMYRWYhGTsLScssJC2zkLQsYGRZxchRWpxalptuZLCJERjyxyTYdHcw 7nlpeYhRgINRiYf3wZtFwUKsiWXFlbmHGKU5WJTEeWfVzgsWEkhPLEnNTk0tSC2KLyrNSS0+ xMjEwSnVwOjguzvM23y3yvbHN3N/OIpe3BH67piQsL+w17Rf3/supx20j+CYN82z9ETatQZG vvTv1zhlOsR8nyd9fnz87e3ijqVfu143LnQOZ3vGpO9Uc72M6Y7uW7NNK83q7S/dSS/7+ODA E8HemKnaoe0P+w7q1Vhv1ytf5TBb4GjOpnWe93h21B144KjEUpyRaKjFXFScCAAygaolWgIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/zjZBcinW6IfaAPB5z671mn73MuY Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 04:41:35 -0000 Hi Alissa,=0A= =0A= On 06/19/2014 06:38 PM, Alissa Cooper wrote:=0A= > I guess it is a feature of area WGs that the sequence of work items is=0A= > not well-defined in advance of taking up any particular work items, nor= =0A= > are those work items correlated to WG milestones (I looked at the=0A= > intarea milestones, dated to 2010, so I assume milestones are not used=0A= > in this group).=0A= =0A= Yes. This is correct. The intarea working group does not have any =0A= defined milestones. Most of the work we take up is one-off kind of items = =0A= and these are not really anticipated ahead of time.=0A= =0A= =0A= > In the case of the host ID work, this seems particularly=0A= > unfortunate. I don=92t think it=92s often the case that a draft outlining= =0A= > solutions is published in advance of a draft that describes use cases=0A= > for those solutions, but that seems to be the direction of the effort=0A= > here.=0A= =0A= Yes. It is unfortunate. When the draft that became RFC6967 was taken up =0A= in intarea, it was fairly controversial (as is all work in this space) =0A= and no further work was anticipated. The draft in question was =0A= originally going through an AD sponsored route (Joel Jaeggli - OPS). =0A= Joel posted in intarea to get some opinions on this draft since RFC6269 =0A= and RFC6967 were produced here. Based on the ensuing discussion Joel =0A= felt that the draft was better pursued in intarea.=0A= =0A= =0A= =0A= > To me what would be useful here would be a document that points out new= =0A= > problems beyond those identified in RFC 6269 that arise in=0A= > address-sharing or tunneled architectures not already contemplated in=0A= > that document. If there aren=92t new problems, then I=92m not sure why 62= 69=0A= > is not considered a sufficient description of the problem space. If=0A= > there are new problems, then between RFC 6269 and the new draft there=0A= > would be a fairly comprehensive list of them documented, and that could= =0A= > provide a foundation for figuring out how to solve some or all of them,= =0A= > whether some of them have existing solutions, and how potential new=0A= > solutions relate to embedding a unique host identifier at the network or= =0A= > transport layer.=0A= =0A= I think this is a good idea.=0A= =0A= Regards=0A= Suresh=0A= =0A= From nobody Tue Jun 24 17:09:00 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BCE1B29D9 for ; Tue, 24 Jun 2014 17:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYtirQCKcPbV for ; Tue, 24 Jun 2014 17:08:55 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 180D41B29DE for ; Tue, 24 Jun 2014 17:08:55 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-35-53a9c196aca1 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 36.DA.27529.691C9A35; Tue, 24 Jun 2014 20:21:11 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Tue, 24 Jun 2014 20:08:47 -0400 From: Suresh Krishnan To: Internet Area Thread-Topic: Conclusion of adoption call for draft-boucadair-intarea-host-identifier-scenarios Thread-Index: Ac+QCaHWy+LSch/gS9+rue0pgZs5Qw== Date: Wed, 25 Jun 2014 00:08:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyuXSPt+70gyuDDXrjLG7MusniwOixZMlP pgDGKC6blNSczLLUIn27BK6MD3fb2Qr+MlUsnlHbwLiBqYuRk0NCwESi5dIERghbTOLCvfVs XYxcHEICRxklfr2ZxQzhLGeUmLF7L1gVG1DHhp2fwbpFBFQlXm+9yAZiCwvESJx4uoAVIp4o 8WT3Q5YuRg4gW09izlRhkDALUPn9iU1grbwCvhLtJ9+B2YxAi7+fWgNmMwuIS9x6Mh/qOAGJ JXvOM0PYohIvH/9jhbCVJD7+ns8OUa8jsWD3JzYIW1ti2cLXzBDzBSVOznzCMoFReBaSsbOQ tMxC0jILScsCRpZVjBylxalluelGBpsYgUF8TIJNdwfjnpeWhxgFOBiVeHgVfFYGC7EmlhVX 5h5ilOZgURLnnVU7L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY1pNTeTejz+ZjhdvyzyS KKD8/eWEybulLrCcF2i+Pq9JYVnGdy1+81anr3u+zpwg9lyofafOD4FLu+Tjv3beYzt73Leo a/L08x8CE17Mstsdt3SN2u2S1jiT7UFJ9vHRjzYsktbafEy8wd840z1q2673j1pu3X5TUBZw //vK/EvPs43eu/JdzlNiKc5INNRiLipOBABI8w6lQwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/vTnagCvYyD44ZoNzvjHjlRVhvZs Subject: [Int-area] Conclusion of adoption call for draft-boucadair-intarea-host-identifier-scenarios X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 00:08:56 -0000 Hi all,=0A= =0A= We have gone through all the messages and unfortunately we do not see=0A= wg consensus for adoption. There have been some issues that were brought=0A= forward during the adoption call. It would be great we can continue=0A= discussing the draft on the list and try to work on the issues.=0A= =0A= Thanks=0A= Suresh and Juan Carlos=0A= =0A= =0A= =0A= From nobody Tue Jun 24 17:15:29 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BB51B29DA for ; Tue, 24 Jun 2014 17:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qS9vH3GAnsV for ; Tue, 24 Jun 2014 17:15:24 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9F61B29D9 for ; Tue, 24 Jun 2014 17:15:24 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-af-53a9c0ad5184 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 9C.94.11744.DA0C9A35; Tue, 24 Jun 2014 20:17:18 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Tue, 24 Jun 2014 20:15:22 -0400 From: Suresh Krishnan To: "int-area@ietf.org" Thread-Topic: Call for agenda items at IETF90 intarea meeting Thread-Index: Ac+QCo2BhG64jjgzQqmSh1NLSuYDPw== Date: Wed, 25 Jun 2014 00:15:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyuXSPn+66AyuDDeZu57a4Mesmi8W7A1OZ HJg8liz5yeSx9HobawBTFJdNSmpOZllqkb5dAlfG307dgi0sFTcmeTcw7mHuYuTkkBAwkXj9 pRHKFpO4cG89WxcjF4eQwFFGia0Nc5ghnOWMEmsWPmYFqWID6tiw8zMTiC0ioC2x/8kBFhCb WcBOon/GIjYQW1jAQuLqovdsEDW2Ei/W3gCq4QCy9SQ670WAhFkEVCW2PL8I1sor4Cvxb9Mb dhCbEeiI76fWMEGMFJe49WQ+E8RxAhJL9pyHOlRU4uXjf6wQtpLEx9/z2SHqdSQW7P7EBmFr Syxb+JoZYr6gxMmZT1gmMIrMQjJ2FpKWWUhaZiFpWcDIsoqRo7Q4tSw33chwEyMw4I9JsDnu YFzwyfIQowAHoxIPr4LPymAh1sSy4srcQ4zSHCxK4rya1fOChQTSE0tSs1NTC1KL4otKc1KL DzEycXBKNTA2Mkq8C3vncEPt49U9TxmmL2oziWU7z8k2d1d+qMrWd59C1kk/O8iyWuDQwmJP jk3T3nj47ayyb5zJoXT7tc81X/Hk686LNiaz1zY/XWC2VuvAwtcyjSpSypGTItgNzV9qxfz5 zcb25ZKX7bHTdfcPr537TzynflerTM2DLXUmG3JCexmW369UYinOSDTUYi4qTgQA410uYFkC AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/IbLv7zhYPHUAHx3Pm_QRf15BTHs Subject: [Int-area] Call for agenda items at IETF90 intarea meeting X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 00:15:26 -0000 Hi all,=0A= The intarea WG will be meeting at the Toronto IETF in a two hour slot = =0A= and we are in the process of setting the agenda. Please send us your =0A= request for slots to intarea-chairs@tools.ietf.org detailing=0A= =0A= * Name of the draft=0A= * Short description of why you think the item needs to be discussed in =0A= the intarea meeting=0A= * Whether the draft has already been presented or will be presented in =0A= some other wg/bof.=0A= =0A= Thanks=0A= Suresh and Juan Carlos=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= From nobody Wed Jun 25 14:05:35 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212DD1A04FA; Wed, 25 Jun 2014 14:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpoQP8N0Di_Z; Wed, 25 Jun 2014 14:05:29 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4CA51A046A; Wed, 25 Jun 2014 14:05:29 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 503555660A68; Wed, 25 Jun 2014 21:05:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYvbCKdwnQR6; Wed, 25 Jun 2014 23:04:55 +0200 (CEST) Received: from kopoli (tmo-106-125.customers.d1-online.com [80.187.106.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id CE8A0566091C; Wed, 25 Jun 2014 23:04:54 +0200 (CEST) From: "Hosnieh Rafiee" To: Date: Wed, 25 Jun 2014 23:04:51 +0200 Message-ID: <002101cf90b9$1c329420$5497bc60$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+QuRmCr0ZMTfBtT0mixW1KecDBsw== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/5qSYC1BnIwRuA0ePwt9Dmfu0AjY Cc: Int-area@ietf.org Subject: [Int-area] please review CGA-TSIG X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 21:05:31 -0000 Hello, We actually put all our efforts to change the document thoroughly and not only consider the IPv4 scenario that was comment of some people in mailinglist but also we expand the DNS privacy section and explained it in more detail (no need to change the protocol.) http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-08 So, any more comments? Any more feedback? do you think it is now a good acceptable version? :-) Best, Hosnieh From nobody Thu Jun 26 13:51:46 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345B71B2F10 for ; Thu, 26 Jun 2014 13:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.551 X-Spam-Level: X-Spam-Status: No, score=-4.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFWTZO102sje for ; Thu, 26 Jun 2014 13:51:40 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B3F1B2F09 for ; Thu, 26 Jun 2014 13:51:39 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 3BB045660A68 for ; Thu, 26 Jun 2014 20:51:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCIQzcujP_Oy for ; Thu, 26 Jun 2014 22:51:06 +0200 (CEST) Received: from kopoli (tmo-101-104.customers.d1-online.com [80.187.101.104]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 7B9F6566098D for ; Thu, 26 Jun 2014 22:51:02 +0200 (CEST) From: "Hosnieh Rafiee" To: References: <002101cf90b9$1c329420$5497bc60$@rozanak.com> <53ABDDFA.1010506@redbarn.org> In-Reply-To: <53ABDDFA.1010506@redbarn.org> Date: Thu, 26 Jun 2014 22:50:48 +0200 Message-ID: <000601cf9180$57e858c0$07b90a40$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFV/a6wXtmKUaP5LrUCeoStZAbqGgG4V7qmnGlBn9A= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/7v-x-gFkpTG6ITMf0N40YwbADHI Subject: Re: [Int-area] [DNSOP] please review CGA-TSIG X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 20:51:42 -0000 I'm just forwarding Vixie's message. Since some folks in intarea are not the member of DNSOP. Thank you, Best, Hosnieh ---------------------------------------------------------------------------- ------------ thank you. i am not a member of the int-area@ mailing list, so please forward this reply to that forum. see below. The TSIG keys, which are manually exchanged between a group of hosts, need to be maintained in a secure manner. tsig keys have no needs. i suggest "must be maintained" here. or to assure a Slave Server that the zone transfer is from the original Master Server and that it has not been corrupted. or as an access control method to permit AXFR/IXFR only when a shared TSIG key is present. Handling this shared secret in a secure manner and exchanging it does not appear to be easy. This is especially true if the IP addresses are dynamic or the shared secret is exposed to the attacker. this is nonsequitur. either give a reference for what "does not appear to be" observed, or simply note that out of band key exchange by sneaker-net does not scale and was never expected to. also, _what_ ip addresses? you've not introduced that concept before referencing it. this document proposes two algorithms which support both IPv4 and IPv6 scenarios. does each of the two support both protocols? if not, the above wording is wrong. perhaps you mean "two algorithms, one for IPv4, and one for IPv6." This document updates the following sections in TSIG document: ... those details should not be in the Introduction section. There are several different methods where DNS records can become compromised. Some examples of methods are DNS Spoofing; DNS Amplification Attacks; Resolver Source IP Spoofing; Unauthorized DNS Update; User Privacy Attack; and Human Intervention. this Problem Statement is grossly inadequate to motivate the proposal you've submitted. consider the User Privacy Attack scenario. the thing that you'd like to hide is the q-tuple, since the response is public information. only the requester's interest in a particular q-tuple at a particular time is worth protecting. we end up having to encrypt the response not because the response itself is sensitive but because a response will implicate a q-tuple which is sensitive. in the stub-to-recursive data path, existing data mining is not occuring in-channel, but at the endpoints. A/V products instrument end-system resolvers to learn and sometimes intercept or redirect DNS transactions. that isn't a problem -- users who don't want it to happen can't stop it with encryption, but they can stop it by uninstalling the A/V. at the other end, an RDNS often participates in some kind of passive DNS collection effort for security analytics purposes, and that is again not the problem being stated here -- because that's happening outside the channel where encryption would do any good. asking for dns path protection end-to-end from stub to authority, such that the RDNS did not know the q-tuple, raises the questions of how could it cache or reuse anything, how could DNS function without caching and reuse, and how could the RDNS route a query to an ADNS without knowing the q-name. yet you're proposing hop-by-hop channel encryption. there is no stated justification for who that helps or how. only if a user wants to use a distant RDNS like opendns or googledns would a form of channel encryption that prevented the user's ISP and other intervening ISP's (or national security agencies in the wide-area data path) be useful. if that's the value you intend to add then you should say so -- after contextualizing it and defining your taxonomy. Disadvantages: - Offline generation of the signature DNSSEC [RFC6840] needs manual step for the configuration. For instance, when a DNSSEC needs to sign the zone offline. offline generation is not a disadvantage. dnssec makes it optional, and offers it because it is a desirable feature. moreover you appear not to know about SIG(0) which worries me since that ought to have been part of any reasonable background check on this topic before writing a proposal as fundamental as this one. - IP spoofing The public key verification in DNSSEC creates a chicken-and- egg situation. In other words, the key for verifying messages should be obtained from the DNSSEC server itself. This is why a query requester needs to verify the key. If this does not happen, DNSSEC is vulnerable to an IP spoofing attack. this is completely wrong, as in, 100% counter-factual. i stopped reading this draft at the end of section 1. it appears not to be worth my time to read the rest of it. i am frankly astonished that anyone would produce text and ideas at this low quality level and then ask others to review it with the invitation: "do you think it is now a good acceptable version?" my answer is not just "no" or "of course not" but rather "you should know better than to ask, given the document as it is." vixie From nobody Thu Jun 26 14:47:42 2014 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EAD1B2F4A; Thu, 26 Jun 2014 01:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iHLY-i1L45A; Thu, 26 Jun 2014 01:46:50 -0700 (PDT) Received: from ss.vix.su (ss.vix.su [IPv6:2001:559:8000:cb::2]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819E71B2CED; Thu, 26 Jun 2014 01:46:50 -0700 (PDT) Received: from [IPv6:2001:559:8000:cb:25c6:e0db:911:4e8e] (unknown [IPv6:2001:559:8000:cb:25c6:e0db:911:4e8e]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ss.vix.su (Postfix) with ESMTPSA id 1FE9AEBC9A; Thu, 26 Jun 2014 08:46:49 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <53ABDDFA.1010506@redbarn.org> Date: Thu, 26 Jun 2014 01:46:50 -0700 From: Paul Vixie User-Agent: Postbox 3.0.10 (Windows/20140526) MIME-Version: 1.0 To: Hosnieh Rafiee References: <002101cf90b9$1c329420$5497bc60$@rozanak.com> In-Reply-To: <002101cf90b9$1c329420$5497bc60$@rozanak.com> X-Enigmail-Version: 1.2.3 Content-Type: multipart/alternative; boundary="------------080701050601040707060605" Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/FL1XX2YCyNblfyNexX2lCa2ifp0 X-Mailman-Approved-At: Thu, 26 Jun 2014 14:47:40 -0700 Cc: DNSOP@ietf.org, Int-area@ietf.org Subject: Re: [Int-area] [DNSOP] please review CGA-TSIG X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 08:46:53 -0000 This is a multi-part message in MIME format. --------------080701050601040707060605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hosnieh Rafiee wrote: > Hello, > > We actually put all our efforts to change the document thoroughly and not > only consider the IPv4 scenario that was comment of some people in > mailinglist but also we expand the DNS privacy section and explained it in > more detail (no need to change the protocol.) > http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-08 thank you. i am not a member of the int-area@ mailing list, so please forward this reply to that forum. > > So, any more comments? Any more feedback? do you think it is now a good > acceptable version? :-) see below. > The TSIG keys, which are manually > exchanged between a group of hosts, need to be maintained in a secure > manner. tsig keys have no needs. i suggest "must be maintained" here. > or to assure a Slave Server that the zone transfer is from > the original Master Server and that it has not been corrupted. or as an access control method to permit AXFR/IXFR only when a shared TSIG key is present. > Handling this shared secret in a secure manner and exchanging it does > not appear to be easy. This is especially true if the IP addresses > are dynamic or the shared secret is exposed to the attacker. this is nonsequitur. either give a reference for what "does not appear to be" observed, or simply note that out of band key exchange by sneaker-net does not scale and was never expected to. also, _what_ ip addresses? you've not introduced that concept before referencing it. > this document proposes two > algorithms which support both IPv4 and IPv6 scenarios. does each of the two support both protocols? if not, the above wording is wrong. perhaps you mean "two algorithms, one for IPv4, and one for IPv6." > This document updates the > following sections in TSIG document: ... those details should not be in the Introduction section. > There are several different methods where DNS records can become > compromised. Some examples of methods are DNS Spoofing; DNS > Amplification Attacks; Resolver Source IP Spoofing; Unauthorized DNS > Update; User Privacy Attack; and Human Intervention. this Problem Statement is grossly inadequate to motivate the proposal you've submitted. consider the User Privacy Attack scenario. the thing that you'd like to hide is the q-tuple, since the response is public information. only the requester's interest in a particular q-tuple at a particular time is worth protecting. we end up having to encrypt the response not because the response itself is sensitive but because a response will implicate a q-tuple which is sensitive. in the stub-to-recursive data path, existing data mining is not occuring in-channel, but at the endpoints. A/V products instrument end-system resolvers to learn and sometimes intercept or redirect DNS transactions. that isn't a problem -- users who don't want it to happen can't stop it with encryption, but they can stop it by uninstalling the A/V. at the other end, an RDNS often participates in some kind of passive DNS collection effort for security analytics purposes, and that is again not the problem being stated here -- because that's happening outside the channel where encryption would do any good. asking for dns path protection end-to-end from stub to authority, such that the RDNS did not know the q-tuple, raises the questions of how could it cache or reuse anything, how could DNS function without caching and reuse, and how could the RDNS route a query to an ADNS without knowing the q-name. yet you're proposing hop-by-hop channel encryption. there is no stated justification for who that helps or how. only if a user wants to use a distant RDNS like opendns or googledns would a form of channel encryption that prevented the user's ISP and other intervening ISP's (or national security agencies in the wide-area data path) be useful. if that's the value you intend to add then you should say so -- after contextualizing it and defining your taxonomy. > Disadvantages: > > - Offline generation of the signature > > DNSSEC [RFC6840 ] needs manual step for the configuration. For > instance, when a DNSSEC needs to sign the zone offline. offline generation is not a disadvantage. dnssec makes it optional, and offers it because it is a desirable feature. moreover you appear not to know about SIG(0) which worries me since that ought to have been part of any reasonable background check on this topic before writing a proposal as fundamental as this one. > - IP spoofing > > The public key verification in DNSSEC creates a chicken-and- egg > situation. In other words, the key for verifying messages should be > obtained from the DNSSEC server itself. This is why a query requester > needs to verify the key. > > If this does not happen, DNSSEC is vulnerable to an IP spoofing > attack. this is completely wrong, as in, 100% counter-factual. i stopped reading this draft at the end of section 1. it appears not to be worth my time to read the rest of it. i am frankly astonished that anyone would produce text and ideas at this low quality level and then ask others to review it with the invitation: "do you think it is now a good acceptable version?" my answer is not just "no" or "of course not" but rather "you should know better than to ask, given the document as it is." vixie --------------080701050601040707060605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hosnieh Rafiee wrote:
Hello,

We actually put all our efforts to change the document thoroughly and not
only consider the IPv4 scenario that was comment of some people in
mailinglist but also we expand the DNS privacy section and explained it in
more detail (no need to change the protocol.)
      http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-08

thank you. i am not a member of the int-area@ mailing list, so please forward this reply to that forum.


So, any more comments? Any more feedback?  do you think it is now a good
acceptable version?   :-) 

see below.

The TSIG keys, which are manually
   exchanged between a group of hosts, need to be maintained in a secure
   manner.

tsig keys have no needs. i suggest "must be maintained" here.

or to assure a Slave Server that the zone transfer is from
   the original Master Server and that it has not been corrupted.

or as an access control method to permit AXFR/IXFR only when a shared TSIG key is present.

Handling this shared secret in a secure manner and exchanging it does
   not appear to be easy. This is especially true if the IP addresses
   are dynamic or the shared secret is exposed to the attacker.

this is nonsequitur. either give a reference for what "does not appear to be" observed, or simply note that out of band key exchange by sneaker-net does not scale and was never expected to. also, _what_ ip addresses? you've not introduced that concept before referencing it.

this document proposes two
   algorithms which support both IPv4 and IPv6 scenarios.

does each of the two support both protocols? if not, the above wording is wrong. perhaps you mean "two algorithms, one for IPv4, and one for IPv6."

This document updates the
   following sections in TSIG document: ...

those details should not be in the Introduction section.

There are several different methods where DNS records can become
   compromised. Some examples of methods are DNS Spoofing; DNS
   Amplification Attacks; Resolver Source IP Spoofing; Unauthorized DNS
   Update; User Privacy Attack; and Human Intervention.

this Problem Statement is grossly inadequate to motivate the proposal you've submitted.

consider the User Privacy Attack scenario. the thing that you'd like to hide is the q-tuple, since the response is public information. only the requester's interest in a particular q-tuple at a particular time is worth protecting. we end up having to encrypt the response not because the response itself is sensitive but because a response will implicate a q-tuple which is sensitive.

in the stub-to-recursive data path, existing data mining is not occuring in-channel, but at the endpoints. A/V products instrument end-system resolvers to learn and sometimes intercept or redirect DNS transactions. that isn't a problem -- users who don't want it to happen can't stop it with encryption, but they can stop it by uninstalling the A/V. at the other end, an RDNS often participates in some kind of passive DNS collection effort for security analytics purposes, and that is again not the problem being stated here -- because that's happening outside the channel where encryption would do any good. asking for dns path protection end-to-end from stub to authority, such that the RDNS did not know the q-tuple, raises the questions of how could it cache or reuse anything, how could DNS function without caching and reuse, and how could the RDNS route a query to an ADNS without knowing the q-name.

yet you're proposing hop-by-hop channel encryption. there is no stated justification for who that helps or how. only if a user wants to use a distant RDNS like opendns or googledns would a form of channel encryption that prevented the user's ISP and other intervening ISP's (or national security agencies in the wide-area data path) be useful. if that's the value you intend to add then you should say so -- after contextualizing it and defining your taxonomy.

   Disadvantages:

   - Offline generation of the signature

   DNSSEC [RFC6840] needs manual step for the configuration. For
   instance, when a DNSSEC needs to sign the zone offline.

offline generation is not a disadvantage. dnssec makes it optional, and offers it because it is a desirable feature.

moreover you appear not to know about SIG(0) which worries me since that ought to have been part of any reasonable background check on this topic before writing a proposal as fundamental as this one.

   - IP spoofing

   The public key verification in DNSSEC creates a chicken-and- egg
   situation. In other words, the key for verifying messages should be
   obtained from the DNSSEC server itself. This is why a query requester
   needs to verify the key.

   If this does not happen, DNSSEC is vulnerable to an IP spoofing
   attack.

this is completely wrong, as in, 100% counter-factual.

i stopped reading this draft at the end of section 1. it appears not to be worth my time to read the rest of it. i am frankly astonished that anyone would produce text and ideas at this low quality level and then ask others to review it with the invitation: "do you think it is now a good acceptable version?" my answer is not just "no" or "of course not" but rather "you should know better than to ask, given the document as it is."

vixie










--------------080701050601040707060605--


From nobody Thu Jun 26 15:19:33 2014
Return-Path: 
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61ACE1B2FC6; Thu, 26 Jun 2014 15:19:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgEJOGPB3OgW; Thu, 26 Jun 2014 15:19:22 -0700 (PDT)
Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C441A1B2FA5; Thu, 26 Jun 2014 15:19:21 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 699985660A68; Thu, 26 Jun 2014 22:19:19 +0000 (UTC)
X-Virus-Scanned: amavisd-new at rozanak.com
Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YpdkaP44Iyq; Fri, 27 Jun 2014 00:18:36 +0200 (CEST)
Received: from kopoli (tmo-101-104.customers.d1-online.com [80.187.101.104]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 05515566098D; Fri, 27 Jun 2014 00:18:21 +0200 (CEST)
From: "Hosnieh Rafiee" 
To: "'Paul Vixie'" 
Date: Fri, 27 Jun 2014 00:18:18 +0200
Message-ID: <000a01cf918c$893589f0$9ba09dd0$@rozanak.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01CF919D.4CC6BE60"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac+RjIZ3+6kAoUhTT8KXyN455pcw4g==
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/int-area/xgCj0rM8p8mm5a8U1vmlk5RA1XY
Cc: DNSOP@ietf.org, Int-area@ietf.org
Subject: [Int-area] please review CGA-TSIG
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Internet Area Mailing List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jun 2014 22:19:29 -0000

This is a multipart message in MIME format.

------=_NextPart_000_000B_01CF919D.4CC6BE60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Paul,

 

Thanks for your review and your comments. 

Please find my responses inline.

 

 

 

>thank you. i am not a member of the int-area@ mailing list, so please
forward this reply to that forum.

 

I forwarded your message to Intarea.

 

>>The TSIG keys, which are manually

   exchanged between a group of hosts, need to be maintained in a secure

   manner.

 

>tsig keys have no needs. i suggest "must be maintained" here.

 

Ok, will consider it.

 

>or to assure a Slave Server that the zone transfer is from

   the original Master Server and that it has not been corrupted.

 

>or as an access control method to permit AXFR/IXFR only when a shared TSIG
key is present.

 

What that sentence means is that the master zone file is not maliciously
modified. 

 

>>Handling this shared secret in a secure manner and exchanging it does

   not appear to be easy. This is especially true if the IP addresses

   are dynamic or the shared secret is exposed to the attacker.

 

>this is nonsequitur. either give a reference for what "does not appear to
be" observed, or simply note that out of band key exchange by sneaker-net
does not scale and was never expected to. also, _what_ ip addresses? you've
not introduced that concept before referencing it.

 

I suggest that you check it yourself in a lab since even theoretically what
was explained is correct. Check the case where one of your nodes that has
this shared secret is compromised then see the changes need to be done in
the configuration of x number of nodes. This was an old discussion with
people who already implemented DNSSEC protocol.

If you have only two nodes, maybe not a big effort but if you have 10 to 100
nodes to update values on the Server then you're in trouble. Now consider
the near future with thousands of Virtual nodes in the clouds that want to
update a value on virtual DNS server. I don't think it is a fun even for the
first time to exchange the keys between these hosts manually to be secured. 

 

 

>>this document proposes two

   algorithms which support both IPv4 and IPv6 scenarios.

 

>does each of the two support both protocols? if not, the above wording is
wrong. perhaps you mean "two algorithms, one for IPv4, and one for IPv6."

 

This is where I say, you haven't read the document even the first parts and
just glance it and some words grab your attention and then you try to review
only a few lines of those sections that you found those words. All your
comments show this lack of deep review. It is two algorithms, one for both
DNS privacy and secure authentication and one for only secure authentication
in case DNS privacy is not important.

 

 

>>This document updates the

   following sections in TSIG document: ...

 

>those details should not be in the Introduction section.

 

This was a comment received from one of reviewer. JFYI, this document up to
now had several DNS expert reviewers with different taste. So, one said it
should be explained there and you say no. The story is now like the story of
the boy, the man and the donkey.

Probably I have to leave it to RFC editor decision.

 

>>There are several different methods where DNS records can become

   >>compromised. Some examples of methods are DNS Spoofing; DNS

   >>Amplification Attacks; Resolver Source IP Spoofing; Unauthorized DNS

  >> Update; User Privacy Attack; and Human Intervention.

 

>this Problem Statement is grossly inadequate to motivate the proposal
you've submitted.

 

Really! please show me a method that can prevent for example, DNS
amplification among the current available approaches. DNSSEC can do this? I
believe not! TSIG can do this? Hum..And about spoofing, what efforts should
be done for preventing the nodes from spoofing, for DNSSEC please refer to
my response below!

 

At first those problems had also a short description but we thought that we
are sending it to DNS experts and all knows about the description of these
attacks. If someone also doesn't know, he can refer to the RFC that gathered
all these attacks. 

 

>consider the User Privacy Attack scenario. the thing that you'd like to
hide is the q-tuple, since the response is public information. only the
requester's interest in a particular q-tuple at a particular time is worth
protecting. we end up having to >encrypt the response not because the
response itself is sensitive but because a response will implicate a q-tuple
which is sensitive.

 

If you're interested, only encrypt the part you like! I considered the
encryption of the whole message without changing the protocol by only adding
a new header to the encryption message. Because I think every section of DNS
protocol can contain critical information. It is not just the question, it
is also the additional section and so on. 

 

>in the stub-to-recursive data path, existing data mining is not occuring
in-channel, but at the endpoints. A/V products instrument end-system
resolvers to learn and sometimes intercept or redirect DNS transactions.
that isn't a problem -- users >who don't want it to happen can't stop it
with encryption, but they can stop it by uninstalling the A/V. at the other
end, an RDNS often participates in some kind of passive DNS collection
effort for security analytics purposes, and that is again not >the problem
being stated here -- because that's happening outside the channel where
encryption would do any good. asking for dns path protection end-to-end from
stub to authority, such that the RDNS did not know the q-tuple, raises the
>questions of how could it cache or reuse anything, how could DNS function
without caching and reuse, and how could the RDNS route a query to an ADNS
without knowing the q-name.

 

 

Whatever you explained here are considered as a use case scenario that I
explained some of these use case scenarios in the document.  If you have
read the document, that unfortunately you haven't, you would find out that
like all security mechanisms, when DNS server receives a message with
CGA-TSIG option there, then it first follows the verification step and if it
is necessary based on the algorithm in use, it decrypts the message. in this
stage it knows what was the question and what it needs to be done with this
message.  So, it is not a mysterious as you explained it here.

 

 

>yet you're proposing hop-by-hop channel encryption. there is no stated
justification for who that helps or how. only if a user wants to use a
distant RDNS like opendns or googledns would a form of channel encryption
that prevented the user's ISP and other intervening ISP's (or national
security agencies in the wide-area data path) be useful. if that's the value
you intend to add then you should say so -- after contextualizing it and
defining your taxonomy.

 

I have never explained in any part of the document that the communication is
hope by hope! The stub resolver send a message securely to the recursive
resolver. This recursive resolver can be even in the other networks. I even
explained in the document that in case you cannot trust the resolver in a
network, then you can easily set your home recursive or the one who you
trust manually. This algorithm knows how to handle it securely.  Not sure
where did you bring "hope by hope" word! . The encryption can be done
end-to-end as long as both end nodes support  this approach. 

And about encryption level, it encrypts all the DNS message but adding a new
header with a few information for only recognized by the DNS server. If you
don't need encryption, then you can only use secure authentication. 

 

>offline generation is not a disadvantage. dnssec makes it optional, and
offers it because it is a desirable feature.

 

Not desirable feature when you want to have dynamic updates or handle
thousands of anonymous nodes on the internet for DNS privacy. This is not a
fun!

 

>moreover you appear not to know about SIG(0) which worries me since that
ought to have been part of any reasonable background check on this topic
before writing a proposal as fundamental as this one.

 

It appears that you don't know the differences between SIG(0) and TSIG and
as I explained before, you only got some words from the document and then
try to find opposite words for that :-) . I clearly explained in the
document that this draft does nothing with TSIG and it only uses TSIG as a
carrier protocol to avoid any changes to DNS protocol since for TSIG it is
easy to add a new extension by registering it in IANA. But it addresses the
problems exist with TSIG or other DNS mechanisms.

 

And you also did not get the idea that the purpose is both security and
privacy, and automation as much as possible. This is what you cannot find in
SIG(0)! The similarity is that only SIG(0) use public key cryptography but
nothing more . 

 

 

>>   - IP spoofing

 

>>  The public key verification in DNSSEC creates a chicken-and- egg

>>  situation. In other words, the key for verifying messages should be

>>  obtained from the DNSSEC server itself. This is why a query requester

  >> needs to verify the key.

 

>>  If this does not happen, DNSSEC is vulnerable to an IP spoofing

>>  attack.

 

>this is completely wrong, as in, 100% counter-factual.

 

Sorry, you're wrong! What is clearly say there is that when the node does
not check the key up to the root then the DNSSEC is vulnerable to spoofing
since there is no binding between the key and the IP address of DNSSEC
server. Please show me this binding. It appears that I cannot see it! 

You either need to manually set these bindings or hard copy it on the node.
In both case, how do you know that your node is not compromised and if this
done what!

 

Show me the proof before you say 100% incorrect! 

 

 

Best,

Hosnieh

 

 

 


------=_NextPart_000_000B_01CF919D.4CC6BE60
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear = Paul,

 

Thanks for your review and your comments. =

Please find my responses = inline.

 

 

 

>thank you. i am not a member of the int-area@ = mailing list, so please forward this reply to that = forum.

 

I forwarded your message to = Intarea.

 

>>The TSIG keys, which are = manually

   exchanged = between a group of hosts, need to be maintained in a = secure

   = manner.

 

>tsig keys have no needs. i suggest "must = be maintained" here.

 

Ok, = will consider it.

 

>or = to assure a Slave Server that the zone transfer is from

   the original Master Server and that it = has not been corrupted.

 

>or = as an access control method to permit AXFR/IXFR only when a shared TSIG = key is present.

 

What = that sentence means is that the master zone file is not maliciously = modified.

 

>>Handling this shared secret in a secure = manner and exchanging it does

   not appear to be easy. This is = especially true if the IP addresses

   are dynamic or the shared secret is = exposed to the attacker.

 

>this is nonsequitur. either give a reference = for what "does not appear to be" observed, or simply note that = out of band key exchange by sneaker-net does not scale and was never = expected to. also, _what_ ip addresses? you've not introduced that = concept before referencing it.

 

I = suggest that you check it yourself in a lab since even theoretically = what was explained is correct. Check the case where one of your nodes = that has this shared secret is compromised then see the changes need to = be done in the configuration of x number of nodes. This was an old = discussion with people who already implemented DNSSEC = protocol.

If you have only two = nodes, maybe not a big effort but if you have 10 to 100 nodes to update = values on the Server then you're in trouble. Now consider the near = future with thousands of Virtual nodes in the clouds that want to update = a value on virtual DNS server. I don't think it is a fun even for the = first time to exchange the keys between these hosts manually to be = secured.

 

 

>>this document proposes two

   algorithms which support both IPv4 and = IPv6 scenarios.

 

>does each of the two support both protocols? if = not, the above wording is wrong. perhaps you mean "two algorithms, = one for IPv4, and one for IPv6."

 

This = is where I say, you haven’t read the document even the first parts = and just glance it and some words grab your attention and then you try = to review only a few lines of those sections that you found those words. = All your comments show this lack of deep review. It is two algorithms, = one for both DNS privacy and secure authentication and one for only = secure authentication in case DNS privacy is not = important.

 

 

>>This document updates the

   following sections in TSIG document: = ...

 

>those details should not be in the Introduction = section.

 

This was a comment received from one of reviewer. = JFYI, this document up to now had several DNS expert reviewers with = different taste. So, one said it should be explained there and you say = no. The story is now like the story of the boy, the man and the = donkey.

Probably I have to leave = it to RFC editor decision.

 

>>There are several different methods where = DNS records can become

   >>compromised. Some examples of = methods are DNS Spoofing; DNS

   >>Amplification Attacks; = Resolver Source IP Spoofing; Unauthorized DNS

  >> Update; User Privacy Attack; and = Human Intervention.

 

>this Problem Statement is grossly inadequate to = motivate the proposal you've submitted.

 

Really! please show me a method that can prevent = for example, DNS amplification among the current available approaches. = DNSSEC can do this? I believe not! TSIG can do this? Hum..And about = spoofing, what efforts should be done for preventing the nodes from = spoofing, for DNSSEC please refer to my response below!

 

At = first those problems had also a short description but we thought that we = are sending it to DNS experts and all knows about the description of = these attacks. If someone also doesn’t know, he can refer to the = RFC that gathered all these attacks.

 

>consider the User Privacy Attack scenario. the = thing that you'd like to hide is the q-tuple, since the response is = public information. only the requester's interest in a particular = q-tuple at a particular time is worth protecting. we end up having to = >encrypt the response not because the response itself is sensitive = but because a response will implicate a q-tuple which is = sensitive.

 

If you’re interested, only encrypt the part = you like! I considered the encryption of the whole message without = changing the protocol by only adding a new header to the encryption = message. Because I think every section of DNS protocol can contain = critical information. It is not just the question, it is also the = additional section and so on.

 

>in = the stub-to-recursive data path, existing data mining is not occuring = in-channel, but at the endpoints. A/V products instrument end-system = resolvers to learn and sometimes intercept or redirect DNS transactions. = that isn't a problem -- users >who don't want it to happen can't stop = it with encryption, but they can stop it by uninstalling the A/V. at the = other end, an RDNS often participates in some kind of passive DNS = collection effort for security analytics purposes, and that is again not = >the problem being stated here -- because that's happening outside = the channel where encryption would do any good. asking for dns path = protection end-to-end from stub to authority, such that the RDNS did not = know the q-tuple, raises the >questions of how could it cache or = reuse anything, how could DNS function without caching and reuse, and = how could the RDNS route a query to an ADNS without knowing the = q-name.

 

 

Whatever you explained here are considered as a use = case scenario that I explained some of these use case scenarios in the = document.  If you have read the document, that unfortunately you = haven’t, you would find out that like all security mechanisms, = when DNS server receives a message with CGA-TSIG option there, then it = first follows the verification step and if it is necessary based on the = algorithm in use, it decrypts the message. in this stage it knows what = was the question and what it needs to be done with this message. =  So, it is not a mysterious as you explained it = here.

 

 

>yet you're proposing hop-by-hop channel = encryption. there is no stated justification for who that helps or how. = only if a user wants to use a distant RDNS like opendns or googledns = would a form of channel encryption that prevented the user's ISP and = other intervening ISP's (or national security agencies in the wide-area = data path) be useful. if that's the value you intend to add then you = should say so -- after contextualizing it and defining your = taxonomy.

 

I have never explained in any part of the document = that the communication is hope by hope! The stub resolver send a message = securely to the recursive resolver. This recursive resolver can be even = in the other networks. I even explained in the document that in case you = cannot trust the resolver in a network, then you can easily set your = home recursive or the one who you trust manually. This algorithm knows = how to handle it securely.  Not sure where did you bring = “hope by hope” word! . The encryption can be done end-to-end = as long as both end nodes support  this approach.

And about encryption level, it encrypts all the DNS = message but adding a new header with a few information for only = recognized by the DNS server. If you don’t need encryption, then = you can only use secure authentication.

 

>offline generation is not a disadvantage. = dnssec makes it optional, and offers it because it is a desirable = feature.

 

Not desirable feature when you want to have dynamic = updates or handle thousands of anonymous nodes on the internet for DNS = privacy. This is not a fun!

 

>moreover you appear not to know about SIG(0) = which worries me since that ought to have been part of any reasonable = background check on this topic before writing a proposal as fundamental = as this one.

 

It = appears that you don't know the differences between SIG(0) and TSIG and = as I explained before, you only got some words from the document and = then try to find opposite words for that :-) . I clearly explained in = the document that this draft does nothing with TSIG and it only uses = TSIG as a carrier protocol to avoid any changes to DNS protocol since = for TSIG it is easy to add a new extension by registering it in IANA. = But it addresses the problems exist with TSIG or other DNS = mechanisms.

 

And = you also did not get the idea that the purpose is both security and = privacy, and automation as much as possible. This is what you cannot = find in SIG(0)! The similarity is that only SIG(0) use public key = cryptography but nothing more .

 

 

>>   - IP spoofing

 

= >>  The public key verification in DNSSEC creates a = chicken-and- egg

>>  = situation. In other words, the key for verifying messages should = be

>>  obtained from = the DNSSEC server itself. This is why a query requester

  >> needs to verify the = key.

 

>>  If this does not happen, DNSSEC is = vulnerable to an IP spoofing

= >>  attack.

 

>this is completely wrong, as in, 100% = counter-factual.

 

Sorry, = you're wrong! What is clearly say there is that when the node does not = check the key up to the root then the DNSSEC is vulnerable to spoofing = since there is no binding between the key and the IP address of DNSSEC = server. Please show me this binding. It appears that I cannot see it! =

You either need to manually set = these bindings or hard copy it on the node. In both case, how do you = know that your node is not compromised and if this done = what!

 

Show me the proof before you say 100% incorrect! =

 

 

Best,

Hosnieh

 

 

 

------=_NextPart_000_000B_01CF919D.4CC6BE60--