Hi Charlie,

Thanks for the notes.

A few corrections:

-Billy= Brandon was Brandon Williams

-p4p is p4c

Other than = that, I think that a few action points have been identified such as submitt= ing the use case draft as hiaps draft, revising the draft to cover IPv6 cas= es.

Regards,

Behcet=A0

On Tue, Mar 4, 2014 at 8:29 AM, Char= lie Perkins <charles.perkins@earthlink.net> wrot= e:

=20 =20 =20
Hello folks,

Here are the notes that I took for the meeting today.=A0 The completeness of
my notes is inversely proportional to the degree of my participation in the
discussion; updates are solicited for points I might have missed.

Regards,
Charlie P.

On 3/4/2014 5:50 AM, Behcet Sarikaya wrote:
Folks,

We had the Bar BoF today lunch time.

Charlie took the minutes and he is going to post them soon.

Overall, it has been very productive.

We would like to thank all those who attended.

Regards,

Behcet & Dirk
_______________________________________________
hiaps mailing list
hiaps@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/hiaps
_______________________________________________
hiaps mailing list
hiaps@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/hiaps

--001a11c3cc9049127f04f3cb34e1-- From nobody Thu Mar 6 08:28:45 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132181A0208; Thu, 6 Mar 2014 08:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 J3tcQ4dnlqAA; Thu, 6 Mar 2014 08:28:37 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id CD91D1A01D5; Thu, 6 Mar 2014 08:28:20 -0800 (PST) Received: from dhcp-bc23.meeting.ietf.org (dhcp-bc23.meeting.ietf.org [31.133.188.35]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s26GSEtW024450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 6 Mar 2014 16:28:16 GMT (envelope-from joelja@bogus.com) Message-ID: <5318A21D.7020508@bogus.com> Date: Thu, 06 Mar 2014 16:28:13 +0000 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: "hiaps@ietf.org" , Internet Area , draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HQOlmiSrS5jDkW94VX2kLapeIQ74C8JAV" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Thu, 06 Mar 2014 16:28:17 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/_hO3xkoWkWWYIcaBEMSVh9P4xOE Subject: [hiaps] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 16:28:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HQOlmiSrS5jDkW94VX2kLapeIQ74C8JAV Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Greetings int-area and hiaps-mailing-list folks, I realize that this is midweek at the IETF, however this question is not far from several discussions I've had this week. I have been asked to consider AD sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenar= ios-04 In the process of considering doing so I'd like to get some input with respect to: A. The appetite for pursuing some or any of this work in existing working groups, and in particular within the INT area. B. A consensus basis for moving beyond RFC 6269 into active work in this area. C. How we address concerns raised by the IETF community expressed through draft-farrell-perpass-attack when evaluating scenarios and beginning to address requirements and solution-space. Obviously these are complex questions and I do not expect that we will arrive at answers easily nor does work on this or other drafts depend on answering them, however it's part of the dialog. Thanks joel --HQOlmiSrS5jDkW94VX2kLapeIQ74C8JAV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMYoh0ACgkQ8AA1q7Z/VrJKGACfVU2w47ZgFKN0BXajIBZ3Vv+M lDwAnRK7aBQOaBmISyPkgrY2blVg14rl =V9D3 -----END PGP SIGNATURE----- --HQOlmiSrS5jDkW94VX2kLapeIQ74C8JAV-- From nobody Thu Mar 6 10:12:07 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F9D1A0040; Thu, 6 Mar 2014 10:03:26 -0800 (PST) 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 kLG7XyUuCyzW; Thu, 6 Mar 2014 10:03:24 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 564091A0051; Thu, 6 Mar 2014 10:03:24 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id y10so3632589wgg.13 for ; Thu, 06 Mar 2014 10:03:20 -0800 (PST) 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=HAIyfI/Nc0D2vVNzIy/574i52CqveMeCKuUGxWTTvzs=; b=TTH0YALFfwBx347HPyWusb9J9HMyHGp7q4HXlznR4RRB/3gp3UhV17fWRxyAy99ffs uF6hQnI4ZGQpUPBsL2m+7UV3SI3OhGe3vtZMS4/XaM2/08H2ZCnMgXnAHEf9byi+3esy O/ngoYmqo8aRofEzVsFMkyh/g/JkihZNQBB5L0klzzFAG92j/8S+kx5VsZ/K3PTKfFuz G+LVUxhLsnXgsY8K5TQ57zP3BmTicirkYUUOXVw7RrnaupoxW7Ki9DGY75I7U45kmLGX 6Xf+5Z3o+b70vnSigVzSDnvJQZifG/JlWybSSvtt1UsWUZqwzOXCSKphW+77agB2qSYf C4tQ== X-Received: by 10.194.186.170 with SMTP id fl10mr3899582wjc.67.1394128999925; Thu, 06 Mar 2014 10:03:19 -0800 (PST) Received: from [31.133.165.224] (dhcp-a5e0.meeting.ietf.org. [31.133.165.224]) by mx.google.com with ESMTPSA id bm8sm20405964wjc.12.2014.03.06.10.03.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 10:03:18 -0800 (PST) Message-ID: <5318B86E.1040805@gmail.com> Date: Fri, 07 Mar 2014 07:03:26 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: joel jaeggli References: <5318A21D.7020508@bogus.com> In-Reply-To: <5318A21D.7020508@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/0c4QXH1HWSJ7bFE95sEw2C_HV_Q X-Mailman-Approved-At: Thu, 06 Mar 2014 10:12:05 -0800 Cc: "hiaps@ietf.org" , Internet Area , draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 18:03:26 -0000 a) Since this is fixing some of the damage done by NAT, it's really unfinished business for BEHAVE, which if iirc was a Transport Area WG. Just saying... b) The word "privacy" doesn't appear in the draft. Discussing privacy aspects is clearly essential if there is any thought of advancing this work. Actually I doubt if such a host ID is ever going to be acceptable from a privacy point of view, unless the end system is at liberty to change it at random (like RFC 4941). c) A hard-nosed argument is that since we want to sunset IPv4, it's time to stop working on ways of making NAT solutions work better. Is there anything in the use cases that can't be fixed by native IPv6? (The use case in expired draft http://tools.ietf.org/html/draft-sarikaya-fmc-prefix-sharing-usecase-01 is not at all convincing to me, especially when adding the privacy argument. It actually seems to describe a bug in 3GPP. But in any case, the draft appears to suggest mitigations.) Regards Brian On 07/03/2014 05:28, joel jaeggli wrote: > Greetings int-area and hiaps-mailing-list folks, > > I realize that this is midweek at the IETF, however this question is not > far from several discussions I've had this week. > > I have been asked to consider AD sponsoring > http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 > > In the process of considering doing so I'd like to get some input with > respect to: > > A. The appetite for pursuing some or any of this work in existing > working groups, and in particular within the INT area. > > B. A consensus basis for moving beyond RFC 6269 into active work in this > area. > > C. How we address concerns raised by the IETF community expressed > through draft-farrell-perpass-attack when evaluating scenarios and > beginning to address requirements and solution-space. > > Obviously these are complex questions and I do not expect that we will > arrive at answers easily nor does work on this or other drafts depend on > answering them, however it's part of the dialog. > > Thanks > joel > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Thu Mar 6 10:13:31 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B60B1A0168; Thu, 6 Mar 2014 10:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 nFrAqYhAucPZ; Thu, 6 Mar 2014 10:13:25 -0800 (PST) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id C35211A004C; Thu, 6 Mar 2014 10:13:25 -0800 (PST) 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 EE66E1B80EA; Thu, 6 Mar 2014 10:13:21 -0800 (PST) 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 BC5AE190043; Thu, 6 Mar 2014 10:13:21 -0800 (PST) Received: from dhcp-hotel-wifi-156-44.meeting.ietf.org (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Mar 2014 10:13:21 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <5318B86E.1040805@gmail.com> Date: Thu, 6 Mar 2014 18:13:18 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5318A21D.7020508@bogus.com> <5318B86E.1040805@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/kkcPTc6vbWKrbBxM0uRUkuj6T-U Cc: Joel Jaeggli , "hiaps@ietf.org" , Internet Area , draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 18:13:27 -0000 It also seems doubtful that this would be useful outside the carrier = network, since service providers would have to implement it and = middleboxes would have to support it, neither of which is something we = can depend on. Inside of the carrier network, solutions like A+P at = the very least are quite easy to track algorithmically, so this solution = is overkill. And of course I agree with all the points you made, Brian. From nobody Fri Mar 7 01:12:25 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1D71A012C; Thu, 6 Mar 2014 11:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 j9bNIloJTFPY; Thu, 6 Mar 2014 11:35:07 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9841A0068; Thu, 6 Mar 2014 11:35:07 -0800 (PST) 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 s26JYOx4028261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 6 Mar 2014 11:34:25 -0800 (PST) Message-ID: <5318CDC0.3030406@isi.edu> Date: Thu, 06 Mar 2014 11:34:24 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: joel jaeggli , "hiaps@ietf.org" , Internet Area , draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org References: <5318A21D.7020508@bogus.com> In-Reply-To: <5318A21D.7020508@bogus.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/hiaps/1d0j5mcUlXRfVUTsBoz0pEL9mdI X-Mailman-Approved-At: Fri, 07 Mar 2014 01:12:21 -0800 Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 19:35:09 -0000 On 3/6/2014 8:28 AM, joel jaeggli wrote: > Greetings int-area and hiaps-mailing-list folks, > > I realize that this is midweek at the IETF, however this question is not > far from several discussions I've had this week. > > I have been asked to consider AD sponsoring > http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 > > In the process of considering doing so I'd like to get some input with > respect to: > > A. The appetite for pursuing some or any of this work in existing > working groups, and in particular within the INT area. Given that draft-ietf-intarea-nat-reveal-analysis is in INT, and this document expands on that, I think this belongs in INT. > B. A consensus basis for moving beyond RFC 6269 into active work in this > area. See my response to (A). INT is already active in that area. > C. How we address concerns raised by the IETF community expressed > through draft-farrell-perpass-attack when evaluating scenarios and > beginning to address requirements and solution-space. That should definitely be addressed in this doc. Joe From nobody Fri Mar 7 01:12:27 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFD21A0157; Thu, 6 Mar 2014 11:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 5Mt21a0KDqv3; Thu, 6 Mar 2014 11:37:39 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 647571A00F2; Thu, 6 Mar 2014 11:37:39 -0800 (PST) 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 s26Jb3m5029238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 6 Mar 2014 11:37:03 -0800 (PST) Message-ID: <5318CE5E.2040705@isi.edu> Date: Thu, 06 Mar 2014 11:37:02 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Brian E Carpenter , joel jaeggli References: <5318A21D.7020508@bogus.com> <5318B86E.1040805@gmail.com> In-Reply-To: <5318B86E.1040805@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/hiaps/d6EoZg0u-uyJOF4zHedd2o-_daI X-Mailman-Approved-At: Fri, 07 Mar 2014 01:12:22 -0800 Cc: "hiaps@ietf.org" , Internet Area , draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 19:37:41 -0000 Brian, Although I don't disagree with the points below, it's useful to consider that INT is already working in this area, so I don't see either (a) or (c) as being relevant unless you expect to shift current INT docs to other WGs too. (b) just warrants an update. I disagree that privacy concerns will negate the benefits, though - a HOST ID might also be used to defeat or deny other claimed identifiers. Joe On 3/6/2014 10:03 AM, Brian E Carpenter wrote: > a) Since this is fixing some of the damage done by NAT, it's > really unfinished business for BEHAVE, which if iirc was a > Transport Area WG. Just saying... > > b) The word "privacy" doesn't appear in the draft. Discussing > privacy aspects is clearly essential if there is any thought of > advancing this work. Actually I doubt if such a host ID is ever > going to be acceptable from a privacy point of view, unless the > end system is at liberty to change it at random (like RFC 4941). > > c) A hard-nosed argument is that since we want to sunset IPv4, > it's time to stop working on ways of making NAT solutions work > better. Is there anything in the use cases that can't be fixed by > native IPv6? > > (The use case in expired draft > http://tools.ietf.org/html/draft-sarikaya-fmc-prefix-sharing-usecase-01 > is not at all convincing to me, especially when adding the privacy > argument. It actually seems to describe a bug in 3GPP. But in any case, > the draft appears to suggest mitigations.) > > Regards > Brian > > On 07/03/2014 05:28, joel jaeggli wrote: >> Greetings int-area and hiaps-mailing-list folks, >> >> I realize that this is midweek at the IETF, however this question is not >> far from several discussions I've had this week. >> >> I have been asked to consider AD sponsoring >> http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 >> >> In the process of considering doing so I'd like to get some input with >> respect to: >> >> A. The appetite for pursuing some or any of this work in existing >> working groups, and in particular within the INT area. >> >> B. A consensus basis for moving beyond RFC 6269 into active work in this >> area. >> >> C. How we address concerns raised by the IETF community expressed >> through draft-farrell-perpass-attack when evaluating scenarios and >> beginning to address requirements and solution-space. >> >> Obviously these are complex questions and I do not expect that we will >> arrive at answers easily nor does work on this or other drafts depend on >> answering them, however it's part of the dialog. >> >> Thanks >> joel >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From nobody Fri Mar 7 01:30:41 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04271A019F; Fri, 7 Mar 2014 01:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=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 otQHFbPQsKBx; Fri, 7 Mar 2014 01:30:32 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id BFCAE1A0164; Fri, 7 Mar 2014 01:30:31 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id y1so2589353lam.37 for ; Fri, 07 Mar 2014 01:30:26 -0800 (PST) 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; bh=5V+WZszJIvqaz8hCX4hi3v7P0IvjJVsehiAOqB4iP2s=; b=vfnb4VroBh78yzvQeT/tr0NJlKoAK6GDYN8F+Pj9znNo3N/grjS1O27GG1ZZDLKJnA 5HGHjT5FlkL4QIpY+jasGJe3x/O+DJIx9F4nayCzTieIQLGKBth6QIDDDy54/PUucc6U Vr7LYsXcI+ORRfKE10ngN0l3gmQ65kO72TL+mDYlegbOuOJSERV+REv7b39ki7ukopPH oSJK9DVA/VAO8yg21k36sAZxCCcRZ7/QbxCXcjQJ8VeMB4hCeQ88i1GcUUYW+yB2zSaE IVXVSWUV3hXsAOlfefM8W6fLw6D6j9MRqb5Ju4HcTdzaitwP+FZ4O5SLlGOdNRRaZ6Jd 28rA== MIME-Version: 1.0 X-Received: by 10.112.97.178 with SMTP id eb18mr1932242lbb.13.1394184626910; Fri, 07 Mar 2014 01:30:26 -0800 (PST) Received: by 10.114.176.234 with HTTP; Fri, 7 Mar 2014 01:30:26 -0800 (PST) In-Reply-To: <5318CE5E.2040705@isi.edu> References: <5318A21D.7020508@bogus.com> <5318B86E.1040805@gmail.com> <5318CE5E.2040705@isi.edu> Date: Fri, 7 Mar 2014 03:30:26 -0600 Message-ID: From: Behcet Sarikaya To: Joe Touch Content-Type: multipart/alternative; boundary=001a1133e308703b9604f400e757 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/AntEctpez_79ISQOh_QPxZrpTxE Cc: joel jaeggli , "hiaps@ietf.org" , Internet Area , Brian E Carpenter , draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 09:30:35 -0000 --001a1133e308703b9604f400e757 Content-Type: text/plain; charset=ISO-8859-1 Hi Joe, On Thu, Mar 6, 2014 at 1:37 PM, Joe Touch wrote: > Brian, > > Although I don't disagree with the points below, it's useful to consider > that INT is already working in this area, so I don't see either (a) or (c) > as being relevant unless you expect to shift current INT docs to other WGs > too. > > Respectfully disagree. There has been some time passed since then and many thing happened such as hiaps and a solution draft submission to tcpm. Use case draft contains many more use cases than was discussed before. Different use cases may require different solutions at different levels. I think it is the mystery of this century to find out where this works belongs :-). > (b) just warrants an update. I disagree that privacy concerns will negate > the benefits, though - a HOST ID might also be used to defeat or deny other > claimed identifiers. > > We identified many places for a revision in this document in an informal hiaps Bar BoF this week, the resulting document could become a completely different draft. Regards, Behcet > Joe > > > On 3/6/2014 10:03 AM, Brian E Carpenter wrote: > >> a) Since this is fixing some of the damage done by NAT, it's >> really unfinished business for BEHAVE, which if iirc was a >> Transport Area WG. Just saying... >> >> b) The word "privacy" doesn't appear in the draft. Discussing >> privacy aspects is clearly essential if there is any thought of >> advancing this work. Actually I doubt if such a host ID is ever >> going to be acceptable from a privacy point of view, unless the >> end system is at liberty to change it at random (like RFC 4941). >> >> c) A hard-nosed argument is that since we want to sunset IPv4, >> it's time to stop working on ways of making NAT solutions work >> better. Is there anything in the use cases that can't be fixed by >> native IPv6? >> >> (The use case in expired draft >> http://tools.ietf.org/html/draft-sarikaya-fmc-prefix-sharing-usecase-01 >> is not at all convincing to me, especially when adding the privacy >> argument. It actually seems to describe a bug in 3GPP. But in any case, >> the draft appears to suggest mitigations.) >> >> Regards >> Brian >> >> On 07/03/2014 05:28, joel jaeggli wrote: >> >>> Greetings int-area and hiaps-mailing-list folks, >>> >>> I realize that this is midweek at the IETF, however this question is not >>> far from several discussions I've had this week. >>> >>> I have been asked to consider AD sponsoring >>> http://tools.ietf.org/html/draft-boucadair-intarea-host- >>> identifier-scenarios-04 >>> >>> In the process of considering doing so I'd like to get some input with >>> respect to: >>> >>> A. The appetite for pursuing some or any of this work in existing >>> working groups, and in particular within the INT area. >>> >>> B. A consensus basis for moving beyond RFC 6269 into active work in this >>> area. >>> >>> C. How we address concerns raised by the IETF community expressed >>> through draft-farrell-perpass-attack when evaluating scenarios and >>> beginning to address requirements and solution-space. >>> >>> Obviously these are complex questions and I do not expect that we will >>> arrive at answers easily nor does work on this or other drafts depend on >>> answering them, however it's part of the dialog. >>> >>> Thanks >>> joel >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >>> >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >> >> > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > --001a1133e308703b9604f400e757 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Joe,

On Thu, Mar 6, 2014 at 1:37 PM, Joe Touch <touch@isi.edu> wrote:

Brian,

Although I don't disagree with the points below, it's useful to con= sider that INT is already working in this area, so I don't see either (= a) or (c) as being relevant unless you expect to shift current INT docs to = other WGs too.

Respectfully disagree.

T= here has been some time passed since then and many thing happened such as h= iaps and a solution draft submission to tcpm.

Use case dr= aft contains many more use cases than was discussed before.

Different use cases may require different solutions at different= levels.

I think it is the mystery of this century to find ou= t where this works belongs :-).

=A0

(b) just warrants an update. I disagree that privacy concerns will negate t= he benefits, though - a HOST ID might also be used to defeat or deny other = claimed identifiers.

We identified many places for a revisio= n in this document in an informal hiaps Bar BoF this week, the resulting do= cument could become a completely different draft.

Regards= ,

Behcet

Joe

On 3/6/2014 10:03 AM, Brian E Carpenter wrote:

a) Since this is fixing some of the damage done by NAT, it's
really unfinished business for BEHAVE, which if iirc was a
Transport Area WG. Just saying...

b) The word "privacy" doesn't appear in the draft. Discussing=
privacy aspects is clearly essential if there is any thought of
advancing this work. Actually I doubt if such a host ID is ever
going to be acceptable from a privacy point of view, unless the
end system is at liberty to change it at random (like RFC 4941).

c) A hard-nosed argument is that since we want to sunset IPv4,
it's time to stop working on ways of making NAT solutions work
better. Is there anything in the use cases that can't be fixed by
native IPv6?

(The use case in expired draft
http://tools.ietf.org/html/draft-sarikaya= -fmc-prefix-sharing-usecase-01
is not at all convincing to me, especially when adding the privacy
argument. It actually seems to describe a bug in 3GPP. But in any case,
the draft appears to suggest mitigations.)

Regards
=A0 =A0 Brian

On 07/03/2014 05:28, joel jaeggli wrote:

Greetings int-area and hiaps-mailing-list folks,

I realize that this is midweek at the IETF, however this question is not far from several discussions I've had this week.

I have been asked to consider AD sponsoring
http://tools.ietf.org/html/draft-= boucadair-intarea-host-identifier-scenarios-04

In the process of =A0considering doing so I'd like to get some input wi= th
respect to:

A. The appetite for pursuing some or any of this work in existing
working groups, and in particular within the INT area.

B. A consensus basis for moving beyond RFC 6269 into active work in this area.

C. How we address concerns raised by the IETF community expressed
through =A0draft-farrell-perpass-attack when evaluating scenarios and
beginning to address requirements and solution-space.

Obviously these are complex questions and I do not expect that we will
arrive at answers easily nor does work on this or other drafts depend on answering them, however it's part of the dialog.

Thanks
joel

-------------------------------------------------------------= -----------

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

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

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

--001a1133e308703b9604f400e757-- From nobody Fri Mar 7 01:41:50 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3D01A0164; Fri, 7 Mar 2014 01:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 dTVr-vvqQsfF; Fri, 7 Mar 2014 01:41:47 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6151A0158; Fri, 7 Mar 2014 01:41:47 -0800 (PST) Received: from dhcp-ba8c.meeting.ietf.org (dhcp-ba8c.meeting.ietf.org [31.133.186.140]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s279fZHm030187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 7 Mar 2014 09:41:37 GMT (envelope-from joelja@bogus.com) Message-ID: <5319944F.4050805@bogus.com> Date: Fri, 07 Mar 2014 09:41:35 +0000 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Thunderbird/27.0 MIME-Version: 1.0 To: sarikaya@ieee.org, Joe Touch References: <5318A21D.7020508@bogus.com> <5318B86E.1040805@gmail.com> <5318CE5E.2040705@isi.edu> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mdjIW00CDKdIoVbSKV6j8Cb1PdGs67rpk" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Fri, 07 Mar 2014 09:41:39 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/tdhXGnjVDcVKutH-n-GlLvWTbQI Cc: "hiaps@ietf.org" , Internet Area , Brian E Carpenter , draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 09:41:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mdjIW00CDKdIoVbSKV6j8Cb1PdGs67rpk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 3/7/14, 9:30 AM, Behcet Sarikaya wrote: > Hi Joe, >=20 >=20 >=20 > On Thu, Mar 6, 2014 at 1:37 PM, Joe Touch wrote: >=20 >> Brian, >> >> Although I don't disagree with the points below, it's useful to consid= er >> that INT is already working in this area, so I don't see either (a) or= (c) >> as being relevant unless you expect to shift current INT docs to other= WGs >> too. >> >> > Respectfully disagree. > There has been some time passed since then and many thing happened such= as > hiaps and a solution draft submission to tcpm. hiaps is not a chartered activity in the IETF. it is a mailing list, not a working group. --mdjIW00CDKdIoVbSKV6j8Cb1PdGs67rpk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMZlE8ACgkQ8AA1q7Z/VrKm/gCfWvajhS0XkFlMAiplaEJ52XXu ticAnRXBXBmp9+6zCZMp4+sv6aWPe+Lu =8CFw -----END PGP SIGNATURE----- --mdjIW00CDKdIoVbSKV6j8Cb1PdGs67rpk-- From nobody Fri Mar 7 01:49:16 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744A41A0255; Fri, 7 Mar 2014 01:42:28 -0800 (PST) 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 3ShVZdqhTVus; Fri, 7 Mar 2014 01:42:26 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id DE5A51A0292; Fri, 7 Mar 2014 01:42:23 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id wo20so3714190obc.22 for ; Fri, 07 Mar 2014 01:42:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PUxFjqLcZPTX3wGDob9U72V0v67MEnCU1nFbdxii8LE=; b=TfiUJUMGxKVAnVhVj7zIQDbSRmKGmew3vVPB/ZCZm8bSn4ZCkOqqkYRu+ksysRiXjt wj3QwRReM6aWlKmfo1UPGeKZUZAp0+Jj3GDKw4TZT8c2Lal5AyjCzpNSUbzw9dNHRf3q ubbMFak8GepNk5vn9xlyVj30l/pTdOO4wBMA46Y7jma0cwOJMSbBQj+L2y9tz3EugnJb ifNCB2lzyrzXPCeIQBqpAF6obRtQPANF2qnN6lnMOl08+0Y8oGWrVnYv2mW2q+BZC08a NMonyaUJNbSyToNJxtNMVaoZTiMbtWy17XyfYKnGRTXLzDO/E5E1kujZ2PEADAq/fnzc FL4A== X-Received: by 10.60.58.72 with SMTP id o8mr9886227oeq.23.1394185339734; Fri, 07 Mar 2014 01:42:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Fri, 7 Mar 2014 01:41:59 -0800 (PST) In-Reply-To: <5318A21D.7020508@bogus.com> References: <5318A21D.7020508@bogus.com> From: Scott Brim Date: Fri, 7 Mar 2014 09:41:59 +0000 Message-ID: To: joel jaeggli Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/nDgFASzrCLMXN6uJDsLEfLdb64c X-Mailman-Approved-At: Fri, 07 Mar 2014 01:49:13 -0800 Cc: "hiaps@ietf.org" , Internet Area , draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 09:42:28 -0000 On Thu, Mar 6, 2014 at 4:28 PM, joel jaeggli wrote: > C. How we address concerns raised by the IETF community expressed > through draft-farrell-perpass-attack when evaluating scenarios and > beginning to address requirements and solution-space. http://tools.ietf.org/html/rfc6967#section-3 says that a host-id will be generated anew any time the endpoint IP address changes. In fact it seems that if the host can regenerate at will, the host-id will change at least that often. Therefore I don't believe this introduces any new privacy issues. By the way, it's nice to see that the session layer has a home in the Internet Area. swb From nobody Fri Mar 7 10:58:42 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD4C1A01E4; Fri, 7 Mar 2014 10:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 lZrXVhWe7pEu; Fri, 7 Mar 2014 10:58:36 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id B0C351A0104; Fri, 7 Mar 2014 10:58:36 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s27IvV4u006149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 7 Mar 2014 10:57:31 -0800 (PST) Message-ID: <531A169D.6000900@isi.edu> Date: Fri, 07 Mar 2014 10:57:33 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: sarikaya@ieee.org References: <5318A21D.7020508@bogus.com> <5318B86E.1040805@gmail.com> <5318CE5E.2040705@isi.edu> In-Reply-To: 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/hiaps/gfecZcu66E_f5HlwKDLAsUE8BK8 Cc: joel jaeggli , "hiaps@ietf.org" , Internet Area , Brian E Carpenter , draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 18:58:38 -0000 On 3/7/2014 1:30 AM, Behcet Sarikaya wrote: > Hi Joe, > > > > On Thu, Mar 6, 2014 at 1:37 PM, Joe Touch > wrote: > > Brian, > > Although I don't disagree with the points below, it's useful to > consider that INT is already working in this area, so I don't see > either (a) or (c) as being relevant unless you expect to shift > current INT docs to other WGs too. > > > Respectfully disagree. > There has been some time passed since then and many thing happened such > as hiaps and a solution draft submission to tcpm. IMO: TCMP - TCP *minor* mods. TSVWG - TCP major mods or mods that affect multiple transports (IMO this should). INT - endpoint IDs, except specific solutions like HIP and mobility BEHAVE - changes local to how NATs work > Use case draft contains many more use cases than was discussed before. > Different use cases may require different solutions at different levels. > I think it is the mystery of this century to find out where this works > belongs :-). If it is then IMO you need to consider splitting it into separate docs. Joe From nobody Fri Mar 7 12:31:35 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DD61A02A8; Fri, 7 Mar 2014 12:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 Ozd262aguzCZ; Fri, 7 Mar 2014 12:31:27 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id CA8B81A0270; Fri, 7 Mar 2014 12:31:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3090; q=dns/txt; s=iport; t=1394224283; x=1395433883; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=yVDd8vuO60V9I/WhjqpaZ3oBNd/rnuaBOKBXNB3wlkE=; b=C/YazWmGQlG2QO+vQgT1gVMwYhHqJMj+c2eiO9cFJDh41e0AHyKBVbGx 4c871zjggrSAsLRTvo8hhKWQn4oxQ3MklVCIkGp/6jXICYGcu8lyZTTlZ 3fzNhFQYvrOTSHBlEW1Xgg6GSXn6JPJMnE3jli4S7iKgC6rHrO+9AH3O8 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAOIrGlOrRDoI/2dsb2JhbABagwY7wgaBFhZ0giUBAQEDAQEBATc0CwULCxgjCyEGMAYTFAeHSgMJBw7JDA2HBReMRIFkMweDJIEUBJZWgW2BMosxhUiBb4E+PQ X-IronPort-AV: E=Sophos;i="4.97,610,1389744000"; d="scan'208";a="107811463" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 07 Mar 2014 20:31:23 +0000 Received: from sjc-vpn1-413.cisco.com (sjc-vpn1-413.cisco.com [10.21.97.157]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s27KVLL1011694; Fri, 7 Mar 2014 20:31:22 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: <5318B86E.1040805@gmail.com> Date: Fri, 7 Mar 2014 20:31:22 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <2CF311E1-929B-4847-A98E-BC495B526D5E@cisco.com> References: <5318A21D.7020508@bogus.com> <5318B86E.1040805@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/ZG3FYzSlOVlvZM-Fp7YB9B2jQaE Cc: joel jaeggli , "hiaps@ietf.org" , Internet Area , draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 20:31:31 -0000 On Mar 6, 2014, at 6:03 PM, Brian E Carpenter = wrote: > a) Since this is fixing some of the damage done by NAT, it's > really unfinished business for BEHAVE, which if iirc was a > Transport Area WG. Just saying... >=20 > b) The word "privacy" doesn't appear in the draft. Discussing > privacy aspects is clearly essential if there is any thought of > advancing this work. Actually I doubt if such a host ID is ever > going to be acceptable from a privacy point of view, unless the > end system is at liberty to change it at random (like RFC 4941). I interpret your statement to mean that address sharing is a desirable = security property. If that interpretation is correct, where does that = leave IPv6? > c) A hard-nosed argument is that since we want to sunset IPv4, > it's time to stop working on ways of making NAT solutions work > better. Is there anything in the use cases that can't be fixed by > native IPv6? Yes, attackers won't move to IPv6 if IPv4 provides them a superior way = to hide their activities. There are attackers already using IPv4 CGN to = obfuscate themselves. -d >=20 > (The use case in expired draft > = http://tools.ietf.org/html/draft-sarikaya-fmc-prefix-sharing-usecase-01 > is not at all convincing to me, especially when adding the privacy > argument. It actually seems to describe a bug in 3GPP. But in any = case, > the draft appears to suggest mitigations.) >=20 > Regards > Brian >=20 > On 07/03/2014 05:28, joel jaeggli wrote: >> Greetings int-area and hiaps-mailing-list folks, >>=20 >> I realize that this is midweek at the IETF, however this question is = not >> far from several discussions I've had this week. >>=20 >> I have been asked to consider AD sponsoring >> = http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenari= os-04 >>=20 >> In the process of considering doing so I'd like to get some input = with >> respect to: >>=20 >> A. The appetite for pursuing some or any of this work in existing >> working groups, and in particular within the INT area. >>=20 >> B. A consensus basis for moving beyond RFC 6269 into active work in = this >> area. >>=20 >> C. How we address concerns raised by the IETF community expressed >> through draft-farrell-perpass-attack when evaluating scenarios and >> beginning to address requirements and solution-space. >>=20 >> Obviously these are complex questions and I do not expect that we = will >> arrive at answers easily nor does work on this or other drafts depend = on >> answering them, however it's part of the dialog. >>=20 >> Thanks >> joel >>=20 >>=20 >>=20 >> = ------------------------------------------------------------------------ >>=20 >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Fri Mar 7 23:03:38 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8ECD1A01F2; Fri, 7 Mar 2014 23:03:31 -0800 (PST) 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 Ca2Fk69095-a; Fri, 7 Mar 2014 23:03:29 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5A70F1A01E5; Fri, 7 Mar 2014 23:03:29 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id p61so6019909wes.41 for ; Fri, 07 Mar 2014 23:03:24 -0800 (PST) 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=i3K9sNSntGs+yx483QB8swQpDYU1oTQnga/dC8YWc+g=; b=waKMjlfEsYkZ4Rs832VmikfDmLb8TjUzbKGzZ57yeqXKhnRvzcE8xYJgNlbN6lPTcS tIaAea+kWzdJ2jviANAIfkNmJlyyrVXQ9KjRhZRntiIzBE2j7cA7SxxL5QJfny6kaUz2 0MTxnpnkPklbPAKDpgfj5KOGlPg9FRzD0kY+H2D8Wxr0Dag3OzQ4xs3HHMQhgjrVfkO/ OW8XhyO/Hy6Xq5laIz6hyc74TWl4k9A0lhSWycHhOWhvV7oJIMmarnDjyFC71r+tjEbE 76OhaBozWtd56z11Kphv7ywQOyFP9Qd2jqrqZCFXd9o7X6X/Vrdt6QDoIjd9GIkqCbNU 0x/Q== X-Received: by 10.180.7.130 with SMTP id j2mr1642575wia.25.1394262204303; Fri, 07 Mar 2014 23:03:24 -0800 (PST) Received: from [10.207.202.195] ([109.144.234.112]) by mx.google.com with ESMTPSA id bm8sm21456509wjc.12.2014.03.07.23.03.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Mar 2014 23:03:23 -0800 (PST) Message-ID: <531AC0C6.1000203@gmail.com> Date: Sat, 08 Mar 2014 20:03:34 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing References: <5318A21D.7020508@bogus.com> <5318B86E.1040805@gmail.com> <2CF311E1-929B-4847-A98E-BC495B526D5E@cisco.com> In-Reply-To: <2CF311E1-929B-4847-A98E-BC495B526D5E@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/55wtUkBl7BueefxBS0_SZsPbbhc Cc: joel jaeggli , "hiaps@ietf.org" , Internet Area , draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 07:03:32 -0000 Dan, On 08/03/2014 09:31, Dan Wing wrote: > On Mar 6, 2014, at 6:03 PM, Brian E Carpenter wrote: > >> a) Since this is fixing some of the damage done by NAT, it's >> really unfinished business for BEHAVE, which if iirc was a >> Transport Area WG. Just saying... >> >> b) The word "privacy" doesn't appear in the draft. Discussing >> privacy aspects is clearly essential if there is any thought of >> advancing this work. Actually I doubt if such a host ID is ever >> going to be acceptable from a privacy point of view, unless the >> end system is at liberty to change it at random (like RFC 4941). > > I interpret your statement to mean that address sharing is a desirable security property. If that interpretation is correct, where does that leave IPv6? I'm not sure where you found that in what I wrote. I think that address sharing is undesirable from every point of view; I suppose it might reduce the risk of layer 3 based tracking of users, but that's certainly not what I meant. IPv6 with RFC 4941 (which appears to be deployed in the vast majority of IPv6 clients today) is fine from this point of view. I don't see any difference in privacy effect between a randomly-changing shared-IPv4 Host ID and a randomly-changing IPv6 address. >> c) A hard-nosed argument is that since we want to sunset IPv4, >> it's time to stop working on ways of making NAT solutions work >> better. Is there anything in the use cases that can't be fixed by >> native IPv6? > > Yes, attackers won't move to IPv6 if IPv4 provides them a superior way to hide their activities. There are attackers already using IPv4 CGN to obfuscate themselves. Attackers will move to IPv6 when their targets do so. I guess such attackers will find RFC 4941 useful too. What's good for the privacy of legitimate users is also good for the privacy of attackers. Brian > -d > > >> (The use case in expired draft >> http://tools.ietf.org/html/draft-sarikaya-fmc-prefix-sharing-usecase-01 >> is not at all convincing to me, especially when adding the privacy >> argument. It actually seems to describe a bug in 3GPP. But in any case, >> the draft appears to suggest mitigations.) >> >> Regards >> Brian >> >> On 07/03/2014 05:28, joel jaeggli wrote: >>> Greetings int-area and hiaps-mailing-list folks, >>> >>> I realize that this is midweek at the IETF, however this question is not >>> far from several discussions I've had this week. >>> >>> I have been asked to consider AD sponsoring >>> http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 >>> >>> In the process of considering doing so I'd like to get some input with >>> respect to: >>> >>> A. The appetite for pursuing some or any of this work in existing >>> working groups, and in particular within the INT area. >>> >>> B. A consensus basis for moving beyond RFC 6269 into active work in this >>> area. >>> >>> C. How we address concerns raised by the IETF community expressed >>> through draft-farrell-perpass-attack when evaluating scenarios and >>> beginning to address requirements and solution-space. >>> >>> Obviously these are complex questions and I do not expect that we will >>> arrive at answers easily nor does work on this or other drafts depend on >>> answering them, however it's part of the dialog. >>> >>> Thanks >>> joel >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > > . > From nobody Mon Mar 10 08:16:10 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACD91A0111; Fri, 7 Mar 2014 13:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 rI0AYfdR2pmK; Fri, 7 Mar 2014 13:47:13 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4551A0114; Fri, 7 Mar 2014 13:47:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3803; q=dns/txt; s=iport; t=1394228824; x=1395438424; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=VAMVQ1vsom+uTpfzVf783YXl8SBtbx8UdXs6HuFPyhU=; b=PLaThKfW9KEj+0hxQ0YBjIusoyeUG1HF+jVpFp6/sDdszWuIxy0wZyNV rTpBBV9pB7erBTJIAgQWNh6VhluduCIRVXBoNN4Ber/NSA+etVWzJ30ns E6F43tA4sO6HvuZcSbmfx9C+MmghsofB9ZqkEHDhsz8RVvYNGe5kke8Tl Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAOM9GlOtJXG9/2dsb2JhbABagwY7V8EvgRgWdIIlAQEBBAEBATc0CxIBCBgeBSwGCyUCBAENBRQHh0oDEQ3IfQ2HBReMRIIXB4Q4BJZWgW2BMosxhUiBb4E+gis X-IronPort-AV: E=Sophos;i="4.97,610,1389744000"; d="scan'208";a="308908664" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 07 Mar 2014 21:46:51 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s27Lkpdb007078 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Mar 2014 21:46:51 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Fri, 7 Mar 2014 15:46:50 -0600 From: "Reinaldo Penno (repenno)" To: "Dan Wing (dwing)" , Brian E Carpenter Thread-Topic: [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 Thread-Index: AQHPOkQzjf1CMpEzwkWdDy31zqoz5prWB3SA Date: Fri, 7 Mar 2014 21:46:51 +0000 Message-ID: In-Reply-To: <2CF311E1-929B-4847-A98E-BC495B526D5E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.116.43] Content-Type: text/plain; charset="us-ascii" Content-ID: <019BF8D951EDE54790C5BD82E543ED1D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/f36L8PGCh7rbTALmvuvm0olzUh8 X-Mailman-Approved-At: Mon, 10 Mar 2014 08:16:08 -0700 Cc: "hiaps@ietf.org" , Internet Area , "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 21:47:15 -0000 There are several paid VPN services that provide anonymity through addresses sharing. This is becoming more and more popular these days. It is public to public translation where you get a shared IP address on purpose. This is not for attack purposes but just to reduce tracking by third-parties.=20 I would think that people interested in these services will continue to use them but public IPv6 to public IPv6. On 3/7/14, 12:31 PM, "Dan Wing (dwing)" wrote: > >On Mar 6, 2014, at 6:03 PM, Brian E Carpenter > wrote: > >> a) Since this is fixing some of the damage done by NAT, it's >> really unfinished business for BEHAVE, which if iirc was a >> Transport Area WG. Just saying... >>=20 >> b) The word "privacy" doesn't appear in the draft. Discussing >> privacy aspects is clearly essential if there is any thought of >> advancing this work. Actually I doubt if such a host ID is ever >> going to be acceptable from a privacy point of view, unless the >> end system is at liberty to change it at random (like RFC 4941). > >I interpret your statement to mean that address sharing is a desirable >security property. If that interpretation is correct, where does that >leave IPv6? > > >> c) A hard-nosed argument is that since we want to sunset IPv4, >> it's time to stop working on ways of making NAT solutions work >> better. Is there anything in the use cases that can't be fixed by >> native IPv6? > >Yes, attackers won't move to IPv6 if IPv4 provides them a superior way to >hide their activities. There are attackers already using IPv4 CGN to >obfuscate themselves. > >-d > > >>=20 >> (The use case in expired draft >> http://tools.ietf.org/html/draft-sarikaya-fmc-prefix-sharing-usecase-01 >> is not at all convincing to me, especially when adding the privacy >> argument. It actually seems to describe a bug in 3GPP. But in any case, >> the draft appears to suggest mitigations.) >>=20 >> Regards >> Brian >>=20 >> On 07/03/2014 05:28, joel jaeggli wrote: >>> Greetings int-area and hiaps-mailing-list folks, >>>=20 >>> I realize that this is midweek at the IETF, however this question is >>>not >>> far from several discussions I've had this week. >>>=20 >>> I have been asked to consider AD sponsoring >>>=20 >>>http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scena >>>rios-04 >>>=20 >>> In the process of considering doing so I'd like to get some input with >>> respect to: >>>=20 >>> A. The appetite for pursuing some or any of this work in existing >>> working groups, and in particular within the INT area. >>>=20 >>> B. A consensus basis for moving beyond RFC 6269 into active work in >>>this >>> area. >>>=20 >>> C. How we address concerns raised by the IETF community expressed >>> through draft-farrell-perpass-attack when evaluating scenarios and >>> beginning to address requirements and solution-space. >>>=20 >>> Obviously these are complex questions and I do not expect that we will >>> arrive at answers easily nor does work on this or other drafts depend >>>on >>> answering them, however it's part of the dialog. >>>=20 >>> Thanks >>> joel >>>=20 >>>=20 >>>=20 >>>=20 >>>------------------------------------------------------------------------ >>>=20 >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >>=20 >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area From nobody Mon Mar 10 09:05:11 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC071A04C8; Mon, 10 Mar 2014 09:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=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 Ar4yQDMlX71h; Mon, 10 Mar 2014 09:04:57 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 518181A04C1; Mon, 10 Mar 2014 09:04:57 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id 10so4782259lbg.35 for ; Mon, 10 Mar 2014 09:04:51 -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; bh=twkbswDQPoc9L5AYbHDEebS6RQpAk4OcEVyfvVYKAvI=; b=i2F9vtnsYs4601v8SDkd1091Lz5f4gYtxWT2P8TxW5izs0lNT4Pt5K4CjPAfQrTG3Z h9TeFVZSzWfFd7NYEQNx5QR7a4Bti1xkBMqboQpO2st637xxEVQmite8cSSd7hMD8cc6 3f35w/lqLMccpajSIn1Pi9oC5SHU71D9Td4paH0xN+CKqe85+b5gqPWwRlbBf2tyFCLs D8RDFOxj5DHn6LgUNEJMBccUVvhWG3o0gmktKVnt96JWd5W3GHctPGadKN811BZwU2G/ 0zDZTC3KGkr9ia7x2K47N2u0PkgA8nbwMSXXknRR7AemqBkZ47wBmVR42lxRhqzBjcmq 86eQ== MIME-Version: 1.0 X-Received: by 10.112.55.99 with SMTP id r3mr94470lbp.54.1394467491265; Mon, 10 Mar 2014 09:04:51 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Mon, 10 Mar 2014 09:04:51 -0700 (PDT) In-Reply-To: <531A169D.6000900@isi.edu> References: <5318A21D.7020508@bogus.com> <5318B86E.1040805@gmail.com> <5318CE5E.2040705@isi.edu> <531A169D.6000900@isi.edu> Date: Mon, 10 Mar 2014 11:04:51 -0500 Message-ID: From: Behcet Sarikaya To: Joe Touch Content-Type: multipart/alternative; boundary=001a11c3e73a77c05304f442c383 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/dDWHfeeSIWHPyVDmfR7cKPagFl4 Cc: joel jaeggli , "hiaps@ietf.org" , Internet Area , Brian E Carpenter , draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 16:05:00 -0000 --001a11c3e73a77c05304f442c383 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 7, 2014 at 12:57 PM, Joe Touch wrote: > > > On 3/7/2014 1:30 AM, Behcet Sarikaya wrote: > >> Hi Joe, >> >> >> >> On Thu, Mar 6, 2014 at 1:37 PM, Joe Touch > > wrote: >> >> Brian, >> >> Although I don't disagree with the points below, it's useful to >> consider that INT is already working in this area, so I don't see >> either (a) or (c) as being relevant unless you expect to shift >> current INT docs to other WGs too. >> >> >> Respectfully disagree. >> There has been some time passed since then and many thing happened such >> as hiaps and a solution draft submission to tcpm. >> > > IMO: > > TCMP - TCP *minor* mods. > > TSVWG - TCP major mods or mods that affect multiple transports (IMO this > should). > > INT - endpoint IDs, except specific solutions like HIP and mobility > > BEHAVE - changes local to how NATs work > > Or a different group? > > Use case draft contains many more use cases than was discussed before. >> Different use cases may require different solutions at different levels. >> I think it is the mystery of this century to find out where this works >> belongs :-). >> > > If it is then IMO you need to consider splitting it into separate docs. > > Well, this could be one option. I think right now, requirements should be split into a separate doc. For the use cases, we need to do solution analysis work. Without such work it is difficult to establish that we need different solutions for different use cases. Behcet > Joe > --001a11c3e73a77c05304f442c383 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Mar 7, 2014 at 12:57 PM, Joe Touch <touch@isi.edu> wrote:

On 3/7/2014 1:30 AM, Behcet Sarikaya wrote:

Hi Joe,

On Thu, Mar 6, 2014 at 1:37 PM, Joe Touch <touch@isi.edu
<mailto:touch@isi.edu= >> wrote:

=A0 =A0 Brian,

=A0 =A0 Although I don't disagree with the points below, it's usefu= l to
=A0 =A0 consider that INT is already working in this area, so I don't s= ee
=A0 =A0 either (a) or (c) as being relevant unless you expect to shift
=A0 =A0 current INT docs to other WGs too.

Respectfully disagree.
There has been some time passed since then and many thing happened such
as hiaps and a solution draft submission to tcpm.

IMO:

TCMP - TCP *minor* mods.

TSVWG - TCP major mods or mods that affect multiple transports (IMO this sh= ould).

INT - endpoint IDs, except specific solutions like HIP and mobility

BEHAVE - changes local to how NATs work

Or a different group?
=A0

Use case draft contains many more use cases than was discussed before.
Different use cases may require different solutions at different levels. I think it is the mystery of this century to find out where this works
belongs :-).

If it is then IMO you need to consider splitting it into separate docs.

Well, this could be one = option.
I think right now, requirements should be split into a separate= doc.
For the use cases, we need to do solution analysis work= .

Without such work it is difficult to establish that we need diff= erent solutions for different use cases.

Behcet
Joe

--001a11c3e73a77c05304f442c383-- From nobody Mon Mar 10 09:34:31 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48781A0552; Mon, 10 Mar 2014 09:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, HTML_MESSAGE=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 i5Ikc7s95NXh; Mon, 10 Mar 2014 09:34:27 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 51D811A04C5; Mon, 10 Mar 2014 09:34:27 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id ec20so4760084lab.39 for ; Mon, 10 Mar 2014 09:34:21 -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; bh=0M4+COyJbLNCvJEsfYlVy5sy6CtagGOtK7gGQ2/w/4E=; b=OMPmXmwUjE9A1cMkhNHMKp+9pyM0D6ZYUVaO/1yTkx47vuZoaWhy5taFHl2/93nFu1 XT4QrVTAGNwroZg42abnb3iQnxwZmSm1WEwbbKp1RcLjB2xDOCEu8fWW16aumxbnZWY4 r5K99E/xlFbMFWXYFwZn6NcC4x/rbLQP7wcbGEQqAfQkXKmsZ9C4iiv+bVzBV9Ghypy0 OiOQw1bRt4vGtLtW0H58HNMFPOxap1pTQRBK+iyO+vajet3+wbH738UXzGFFhXEoWfvM 3o7xaQkfR/rnxESWkwi13PCq79GQLDd7rODwJRYH49IOLyIQVFrYimhA2VN+VZmksgHX xasg== MIME-Version: 1.0 X-Received: by 10.152.234.130 with SMTP id ue2mr23982517lac.0.1394469261284; Mon, 10 Mar 2014 09:34:21 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Mon, 10 Mar 2014 09:34:21 -0700 (PDT) In-Reply-To: <5318B86E.1040805@gmail.com> References: <5318A21D.7020508@bogus.com> <5318B86E.1040805@gmail.com> Date: Mon, 10 Mar 2014 11:34:21 -0500 Message-ID: From: Behcet Sarikaya To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a113484bcf8191c04f4432c65 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/0oTcIrai3HE8eBdVNZDEBwxdY-E Cc: joel jaeggli , "hiaps@ietf.org" , Internet Area , draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 16:34:29 -0000 --001a113484bcf8191c04f4432c65 Content-Type: text/plain; charset=ISO-8859-1 Hi Brian, On Thu, Mar 6, 2014 at 12:03 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > a) Since this is fixing some of the damage done by NAT, it's > really unfinished business for BEHAVE, which if iirc was a > Transport Area WG. Just saying... > > b) The word "privacy" doesn't appear in the draft. Discussing > privacy aspects is clearly essential if there is any thought of > advancing this work. Actually I doubt if such a host ID is ever > going to be acceptable from a privacy point of view, unless the > end system is at liberty to change it at random (like RFC 4941). > > Scott Brim said there are no privacy issues. > c) A hard-nosed argument is that since we want to sunset IPv4, > it's time to stop working on ways of making NAT solutions work > better. Is there anything in the use cases that can't be fixed by > native IPv6? > > Brandon could better address this, I think. > (The use case in expired draft > http://tools.ietf.org/html/draft-sarikaya-fmc-prefix-sharing-usecase-01 > is not at all convincing to me, especially when adding the privacy > argument. It actually seems to describe a bug in 3GPP. But in any case, > the draft appears to suggest mitigations.) > > It is kind of a bug in 3GPP, but remember that 3GPP makes protocols for their own hosts called UEs. While here we are talking about fixed hosts. This is what is called fixed mobile convergence, or policy for convergence, to add more acronyms to the discussion. Regarding privacy, in this use case, the communication is one hop and the edge router already knows about the host, it is connected. So the privacy property is not the same in this use case. Regards, Behcet > Regards > Brian > > On 07/03/2014 05:28, joel jaeggli wrote: > > Greetings int-area and hiaps-mailing-list folks, > > > > I realize that this is midweek at the IETF, however this question is not > > far from several discussions I've had this week. > > > > I have been asked to consider AD sponsoring > > > http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 > > > > In the process of considering doing so I'd like to get some input with > > respect to: > > > > A. The appetite for pursuing some or any of this work in existing > > working groups, and in particular within the INT area. > > > > B. A consensus basis for moving beyond RFC 6269 into active work in this > > area. > > > > C. How we address concerns raised by the IETF community expressed > > through draft-farrell-perpass-attack when evaluating scenarios and > > beginning to address requirements and solution-space. > > > > Obviously these are complex questions and I do not expect that we will > > arrive at answers easily nor does work on this or other drafts depend on > > answering them, however it's part of the dialog. > > > > Thanks > > joel > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > --001a113484bcf8191c04f4432c65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Brian,

On Thu, Mar 6, 2014 at 12:03 PM, Brian E Carpenter= <brian.e.carpenter@gmail.com> wrote:

a) Since this is fixing some of the damage d= one by NAT, it's
really unfinished business for BEHAVE, which if iirc was a
Transport Area WG. Just saying...

b) The word "privacy" doesn't appear in the draft. Discussing=
privacy aspects is clearly essential if there is any thought of
advancing this work. Actually I doubt if such a host ID is ever
going to be acceptable from a privacy point of view, unless the
end system is at liberty to change it at random (like RFC 4941).

Scott Brim said there are no privacy i= ssues.
=A0

c) A hard-nosed argument is that since we want to sunset IPv4,
it's time to stop working on ways of making NAT solutions work
better. Is there anything in the use cases that can't be fixed by
native IPv6?

Brandon could better address this, I t= hink.
=A0

(The use case in expired draft
http://tools.ietf.org/html/draft-sarikaya-fmc-pr= efix-sharing-usecase-01
is not at all convincing to me, especially when adding the privacy
argument. It actually seems to describe a bug in 3GPP. But in any case,
the draft appears to suggest mitigations.)

It is kind of a bug in 3GPP, but remem= ber that 3GPP makes protocols for their own hosts called UEs. While here we= are talking about fixed hosts.

This is what is called fixed = mobile convergence, or policy for convergence, to add more acronyms to the = discussion.

Regarding privacy, in this use case, the communication is on= e hop and the edge router already knows about the host, it is connected.

So the privacy property is not the same in this use case.

Regards,

Behcet

Regards
=A0 =A0Brian

On 07/03/2014 05:28, joel jaeggli wrote:
> Greetings int-area and hiaps-mailing-list folks,
>
> I realize that this is midweek at the IETF, however this question is n= ot
> far from several discussions I've had this week.
>
> I have been asked to consider AD sponsoring
> http://tools.ietf.org/html/draft-bo= ucadair-intarea-host-identifier-scenarios-04
>
> In the process of =A0considering doing so I'd like to get some inp= ut with
> respect to:
>
> A. The appetite for pursuing some or any of this work in existing
> working groups, and in particular within the INT area.
>
> B. A consensus basis for moving beyond RFC 6269 into active work in th= is
> area.
>
> C. How we address concerns raised by the IETF community expressed
> through =A0draft-farrell-perpass-attack when evaluating scenarios and<= br> > beginning to address requirements and solution-space.
>
> Obviously these are complex questions and I do not expect that we will=
> arrive at answers easily nor does work on this or other drafts depend = on
> answering them, however it's part of the dialog.
>
> Thanks
> joel
>
>
>

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

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

--001a113484bcf8191c04f4432c65-- From nobody Mon Mar 10 09:57:16 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF6C1A0648; Mon, 10 Mar 2014 09:57:12 -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 bdb6b7KpSHGW; Mon, 10 Mar 2014 09:57:09 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2BB1A064D; Mon, 10 Mar 2014 09:57:09 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id i7so7372465oag.33 for ; Mon, 10 Mar 2014 09:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=13kvGh5UO/qgjXEEsxUZU0ezcwcjRdF0FJuy9KGdJqI=; b=ZzpmP21QGj98A3plgar2dck7YKnoJ8inpDc3uYaW24BdJiPsLnJW1RPkqf41e8oAAk AtFRxmlDX3bFuERYKKdwdwAiro6rID+iFRELSYQQvwUe5obgUbKCuk/uTfsEtLsdWoqn Ykbc4ROKeeu/d2zOoB5pHYC7ek4XEtQ1tj1VyaHmhIuSz900Tz5AWa/uQ3V8mIpuTMbE EjF6ERQZpplOnZPi674fwpdbb8t2gI4a9qzOlvaQJOwxBSSJQIjeVnKxUPafXPTF1j7Q ijxrtfUI7cztlzaXF37zWhSuYJKMtHESCQju0bFwDuW0zHv7tNsgx7KvEOQ1oZdeLbTh ZF9A== X-Received: by 10.182.246.39 with SMTP id xt7mr29476729obc.16.1394470623337; Mon, 10 Mar 2014 09:57:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Mon, 10 Mar 2014 09:56:43 -0700 (PDT) In-Reply-To: References: <5318A21D.7020508@bogus.com> <5318B86E.1040805@gmail.com> From: Scott Brim Date: Mon, 10 Mar 2014 12:56:43 -0400 Message-ID: To: sarikaya@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/5lqkOCRKg4IUgY4kPPpE8yiciSg Cc: "hiaps@ietf.org" , Internet Area , Brian E Carpenter , draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 16:57:12 -0000 On Mon, Mar 10, 2014 at 12:34 PM, Behcet Sarikaya wrote: > Hi Brian, > > On Thu, Mar 6, 2014 at 12:03 PM, Brian E Carpenter > wrote: >> >> a) Since this is fixing some of the damage done by NAT, it's >> really unfinished business for BEHAVE, which if iirc was a >> Transport Area WG. Just saying... >> >> b) The word "privacy" doesn't appear in the draft. Discussing >> privacy aspects is clearly essential if there is any thought of >> advancing this work. Actually I doubt if such a host ID is ever >> going to be acceptable from a privacy point of view, unless the >> end system is at liberty to change it at random (like RFC 4941). > > Scott Brim said there are no privacy issues. I said I don't believe this introduces any NEW privacy issues, as long as host-ids change at least as often as IP addresses. I hope you will get other opinions. I just might be wrong, eh? Scott From nobody Mon Mar 10 10:05:49 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8531A055D; Mon, 10 Mar 2014 10:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 9u3e61Xjbzk7; Mon, 10 Mar 2014 10:05:25 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 251321A0535; Mon, 10 Mar 2014 10:05:25 -0700 (PDT) Received: from [75.208.87.150] (150.sub-75-208-87.myvzw.com [75.208.87.150]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s2AH4IQr017514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 10 Mar 2014 10:04:28 -0700 (PDT) Message-ID: <531DF094.3090607@isi.edu> Date: Mon, 10 Mar 2014 10:04:20 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Scott Brim , sarikaya@ieee.org References: <5318A21D.7020508@bogus.com> <5318B86E.1040805@gmail.com> In-Reply-To: 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/hiaps/tS5jzEdPybT6Ojq2tSkWlYz71gY Cc: "hiaps@ietf.org" , Internet Area , draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 17:05:37 -0000 On 3/10/2014 9:56 AM, Scott Brim wrote: > On Mon, Mar 10, 2014 at 12:34 PM, Behcet Sarikaya > wrote: >> Hi Brian, >> >> On Thu, Mar 6, 2014 at 12:03 PM, Brian E Carpenter >> wrote: >>> >>> a) Since this is fixing some of the damage done by NAT, it's >>> really unfinished business for BEHAVE, which if iirc was a >>> Transport Area WG. Just saying... >>> >>> b) The word "privacy" doesn't appear in the draft. Discussing >>> privacy aspects is clearly essential if there is any thought of >>> advancing this work. Actually I doubt if such a host ID is ever >>> going to be acceptable from a privacy point of view, unless the >>> end system is at liberty to change it at random (like RFC 4941). >> >> Scott Brim said there are no privacy issues. > > I said I don't believe this introduces any NEW privacy issues, as long > as host-ids change at least as often as IP addresses. I hope you will > get other opinions. I just might be wrong, eh? Host-IDs might change a lot less often - to retain a persistent ID across such changes - or more often. I don't think we can or should assume either one. We might assume that it should be under app-layer control, at which point the ball's in the user's court as to how to manage their own privacy. That's worth pointing out, but AFAICT unless there's active user management to the contrary it can't be worse than an IP address wuold have been (but it might defeat a network edge from trying to protect internal users/services). Joe From nobody Mon Mar 10 10:16:50 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CB91A0654; Mon, 10 Mar 2014 10:16:42 -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 SUbMyb-oCVvC; Mon, 10 Mar 2014 10:16:36 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id D21991A055D; Mon, 10 Mar 2014 10:16:35 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id i4so7283386oah.38 for ; Mon, 10 Mar 2014 10:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5ff3LetrigS4hXYx0vU24ze/OgXmqiBgQVG2Z3KOB9M=; b=bhkuvNtk4RldH0KGGH1MP9PEUZH0SNmFgwesIGGn44EcnwJt5A4nhyU53rLT7g3WoE xpuR5aX191rt7sk9mRHoLulhfyqN9El/S8RYkWlqjV209lEchpPol7z+i35aF71PZ6Kl +36cip87orhXQcLw9pFQrfnccJLzq0FPWd1V2f9x3JG/Y2BnA/i0Hnsy6MXwpInh6bqS yxr/kr1qENRb2LFv8S142brqx3C6rzHyCX2sjMpZzbe3MhIPG1I88gAMfDetyKOhluAj FfPU2IXbhsCf/rd7GoL/QKL+Hs357haYLRhJzzKWm+gnXEbt8EIQ5XAQSrbrdda27ofx OF7Q== MIME-Version: 1.0 X-Received: by 10.182.153.226 with SMTP id vj2mr29944838obb.26.1394471790442; Mon, 10 Mar 2014 10:16:30 -0700 (PDT) Received: by 10.182.48.9 with HTTP; Mon, 10 Mar 2014 10:16:30 -0700 (PDT) Received: by 10.182.48.9 with HTTP; Mon, 10 Mar 2014 10:16:30 -0700 (PDT) In-Reply-To: <531DF094.3090607@isi.edu> References: <5318A21D.7020508@bogus.com> <5318B86E.1040805@gmail.com> <531DF094.3090607@isi.edu> Date: Mon, 10 Mar 2014 13:16:30 -0400 Message-ID: From: Scott Brim To: Joe Touch Content-Type: multipart/alternative; boundary=089e013d0dc0b839a004f443c3fd Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/ZxOfl1nUdYkDuNBVNWhSP2USyS4 Cc: draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org, sarikaya@ieee.org, Internet Area , hiaps@ietf.org Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 17:16:43 -0000 --089e013d0dc0b839a004f443c3fd Content-Type: text/plain; charset=ISO-8859-1 Joe, http:// tools.ietf.org / html /rfc6967#section-3 says that a host-id will be generated anew any time the endpoint IP address changes, perhaps more often. Is that wrong? It's hard to do a privacy audit if the behavior isn't agreed on. On Mar 10, 2014 1:05 PM, "Joe Touch" wrote: > > > On 3/10/2014 9:56 AM, Scott Brim wrote: > >> On Mon, Mar 10, 2014 at 12:34 PM, Behcet Sarikaya >> wrote: >> >>> Hi Brian, >>> >>> On Thu, Mar 6, 2014 at 12:03 PM, Brian E Carpenter >>> wrote: >>> >>>> >>>> a) Since this is fixing some of the damage done by NAT, it's >>>> really unfinished business for BEHAVE, which if iirc was a >>>> Transport Area WG. Just saying... >>>> >>>> b) The word "privacy" doesn't appear in the draft. Discussing >>>> privacy aspects is clearly essential if there is any thought of >>>> advancing this work. Actually I doubt if such a host ID is ever >>>> going to be acceptable from a privacy point of view, unless the >>>> end system is at liberty to change it at random (like RFC 4941). >>>> >>> >>> Scott Brim said there are no privacy issues. >>> >> >> I said I don't believe this introduces any NEW privacy issues, as long >> as host-ids change at least as often as IP addresses. I hope you will >> get other opinions. I just might be wrong, eh? >> > > Host-IDs might change a lot less often - to retain a persistent ID across > such changes - or more often. > > I don't think we can or should assume either one. We might assume that it > should be under app-layer control, at which point the ball's in the user's > court as to how to manage their own privacy. > > That's worth pointing out, but AFAICT unless there's active user > management to the contrary it can't be worse than an IP address wuold have > been (but it might defeat a network edge from trying to protect internal > users/services). > > Joe > --089e013d0dc0b839a004f443c3fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Joe, http://tools= .ietf.org /= html /rfc6967#section-3=A0say= s that a host-id will be generated anew any time the endpoint IP address ch= anges, perhaps more often.

Is that wrong? It's hard to do a privacy audit if the be= havior isn't agreed on.

On Mar 10, 2014 1:05 PM, "Joe Touch" &= lt;touch@isi.edu> wrote:

On 3/10/2014 9:56 AM, Scott Brim wrote:

On Mon, Mar 10, 2014 at 12:34 PM, Behcet Sarikaya
<sarikaya201= 2@gmail.com> wrote:

Hi Brian,

On Thu, Mar 6, 2014 at 12:03 PM, Brian E Carpenter
<brian.= e.carpenter@gmail.com> wrote:

a) Since this is fixing some of the damage done by NAT, it's
really unfinished business for BEHAVE, which if iirc was a
Transport Area WG. Just saying...

b) The word "privacy" doesn't appear in the draft. Discussing=
privacy aspects is clearly essential if there is any thought of
advancing this work. Actually I doubt if such a host ID is ever
going to be acceptable from a privacy point of view, unless the
end system is at liberty to change it at random (like RFC 4941).

Scott Brim said there are no privacy issues.

I said I don't believe this introduces any NEW privacy issues, as long<= br> as host-ids change at least as often as IP addresses. I hope you will
get other opinions. I just might be wrong, eh?

Host-IDs might change a lot less often - to retain a persistent ID across s= uch changes - or more often.

I don't think we can or should assume either one. We might assume that = it should be under app-layer control, at which point the ball's in the = user's court as to how to manage their own privacy.

That's worth pointing out, but AFAICT unless there's active user ma= nagement to the contrary it can't be worse than an IP address wuold hav= e been (but it might defeat a network edge from trying to protect internal = users/services).

Joe

--089e013d0dc0b839a004f443c3fd-- From nobody Mon Mar 10 10:45:50 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5BF1A064F; Mon, 10 Mar 2014 10:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 5cTd6RCPzd-U; Mon, 10 Mar 2014 10:45:44 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 79B341A0642; Mon, 10 Mar 2014 10:45:44 -0700 (PDT) Received: from [75.208.87.150] (150.sub-75-208-87.myvzw.com [75.208.87.150]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s2AHiNhZ024439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 10 Mar 2014 10:44:33 -0700 (PDT) Message-ID: <531DF9F9.2090205@isi.edu> Date: Mon, 10 Mar 2014 10:44:25 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Scott Brim References: <5318A21D.7020508@bogus.com> <5318B86E.1040805@gmail.com> <531DF094.3090607@isi.edu> In-Reply-To: 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/hiaps/B21O56P8LXOszvA5qcOmKnMwYc8 Cc: draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org, sarikaya@ieee.org, Internet Area , hiaps@ietf.org Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 17:45:46 -0000 On 3/10/2014 10:16 AM, Scott Brim wrote: > Joe, http:// > tools.ietf.org > / > html > /rfc6967#section-3 > says that a host-id will > be generated anew any time the endpoint IP address changes, perhaps more > often. I believe you're referring to: "... a distinct HOST_ID may be used by the address- sharing function when the host reboots or gets a new internal IP address." That's not a requirement; it's an example. This doc is a survey; no one rule applies everywhere. > Is that wrong? It's hard to do a privacy audit if the behavior isn't > agreed on. Again, it's a survey. An audit would apply to a given approach. Joe From nobody Tue Mar 11 08:50:26 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A2F1A0780; Tue, 11 Mar 2014 08:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 yTfAD0JMWAKS; Tue, 11 Mar 2014 08:50:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4412C1A0779; Tue, 11 Mar 2014 08:50:18 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id C328222C56E; Tue, 11 Mar 2014 16:50:11 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id A03DF27C067; Tue, 11 Mar 2014 16:50:11 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Tue, 11 Mar 2014 16:50:11 +0100 From: To: Brian E Carpenter , joel jaeggli Date: Tue, 11 Mar 2014 16:50:09 +0100 Thread-Topic: [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 Thread-Index: Ac85ZmS9zBpPI4pQQJa9Yf5R4SzlpAD0+XYA Message-ID: <94C682931C08B048B7A8645303FDC9F36F503EE1B7@PUEXCB1B.nanterre.francetelecom.fr> References: <5318A21D.7020508@bogus.com> <5318B86E.1040805@gmail.com> In-Reply-To: <5318B86E.1040805@gmail.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.11.95118 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/listPgl98G0dgBl8OM_1luZXIZg Cc: "hiaps@ietf.org" , Internet Area , "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 15:50:20 -0000 Hi Brian, Please see inline.=20 Cheers, Med >-----Message d'origine----- >De=A0: Int-area [mailto:int-area-bounces@ietf.org] De la part de Brian E >Carpenter >Envoy=E9=A0: jeudi 6 mars 2014 19:03 >=C0=A0: joel jaeggli >Cc=A0: hiaps@ietf.org; Internet Area; draft-boucadair-intarea-host- >identifier-scenarios@tools.ietf.org >Objet=A0: Re: [Int-area] request to consider sponsoring >http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier- >scenarios-04 > >a) Since this is fixing some of the damage done by NAT, it's >really unfinished business for BEHAVE, which if iirc was a >Transport Area WG. Just saying... [Med] It is not only about NAT but address sharing in general (including A+= P and proxies). Issues are also encountered when tunnels are in use. > >b) The word "privacy" doesn't appear in the draft. Discussing >privacy aspects is clearly essential if there is any thought of >advancing this work. Actually I doubt if such a host ID is ever >going to be acceptable from a privacy point of view, unless the >end system is at liberty to change it at random (like RFC 4941). [Med] A pointer to http://tools.ietf.org/html/rfc6967#section-3 can be adde= d to the draft.=20 > >c) A hard-nosed argument is that since we want to sunset IPv4, >it's time to stop working on ways of making NAT solutions work >better. Is there anything in the use cases that can't be fixed by >native IPv6? [Med] The document includes some cases involving IPv6 (e.g., proxies, NPTv6= , NAT64). See the table in http://tools.ietf.org/html/draft-boucadair-intar= ea-host-identifier-scenarios-04#section-4.2. The text can be made more clea= rer.=20 > >(The use case in expired draft >http://tools.ietf.org/html/draft-sarikaya-fmc-prefix-sharing-usecase-01 >is not at all convincing to me, especially when adding the privacy >argument. It actually seems to describe a bug in 3GPP. But in any case, >the draft appears to suggest mitigations.) > >Regards > Brian > >On 07/03/2014 05:28, joel jaeggli wrote: >> Greetings int-area and hiaps-mailing-list folks, >> >> I realize that this is midweek at the IETF, however this question is not >> far from several discussions I've had this week. >> >> I have been asked to consider AD sponsoring >> http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier- >scenarios-04 >> >> In the process of considering doing so I'd like to get some input with >> respect to: >> >> A. The appetite for pursuing some or any of this work in existing >> working groups, and in particular within the INT area. >> >> B. A consensus basis for moving beyond RFC 6269 into active work in this >> area. >> >> C. How we address concerns raised by the IETF community expressed >> through draft-farrell-perpass-attack when evaluating scenarios and >> beginning to address requirements and solution-space. >> >> Obviously these are complex questions and I do not expect that we will >> arrive at answers easily nor does work on this or other drafts depend on >> answering them, however it's part of the dialog. >> >> Thanks >> joel >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area From nobody Tue Mar 11 09:08:06 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D5F1A0774; Tue, 11 Mar 2014 09:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 1LqiaUVaxvFx; Tue, 11 Mar 2014 09:08:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1431A048F; Tue, 11 Mar 2014 09:07:57 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 6EC8E2ACAA7; Tue, 11 Mar 2014 17:07:51 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 5063F180051; Tue, 11 Mar 2014 17:07:51 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Tue, 11 Mar 2014 17:07:50 +0100 From: To: Ted Lemon , Brian E Carpenter Date: Tue, 11 Mar 2014 17:07:49 +0100 Thread-Topic: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 Thread-Index: Ac85Z8ZjSmDLvNDeSCy7edsI5gmY8wD2zuwg Message-ID: <94C682931C08B048B7A8645303FDC9F36F503EE1DC@PUEXCB1B.nanterre.francetelecom.fr> References: <5318A21D.7020508@bogus.com> <5318B86E.1040805@gmail.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.11.95118 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/yfLZyULzy9ruEwipqv0j794j_iM Cc: Joel Jaeggli , "hiaps@ietf.org" , Internet Area , "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 16:08:02 -0000 Hi Ted, It is out of scope of the document to specify solutions but to enumerate th= e set of cases where issues will be encountered. The use cases identified s= o far are not specific to a given administrative domain as captured in http= ://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04= #section-4.2=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 | Given these use cases, operational considerations such as the performance i= mpact induced by a solution to convey host_id should be taken into account.= These impacts are solution-specific an deployment-sceptic. For cases where functional elements belonging to several administrative dom= ains are involved, standardized means are key. Cheers, Med >-----Message d'origine----- >De=A0: hiaps [mailto:hiaps-bounces@ietf.org] De la part de Ted Lemon >Envoy=E9=A0: jeudi 6 mars 2014 19:13 >=C0=A0: Brian E Carpenter >Cc=A0: Joel Jaeggli; hiaps@ietf.org; Internet Area; draft-boucadair-intare= a- >host-identifier-scenarios@tools.ietf.org >Objet=A0: Re: [hiaps] [Int-area] request to consider sponsoring >http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier- >scenarios-04 > >It also seems doubtful that this would be useful outside the carrier >network, since service providers would have to implement it and middleboxe= s >would have to support it, neither of which is something we can depend on. >Inside of the carrier network, solutions like A+P at the very least are >quite easy to track algorithmically, so this solution is overkill. > >And of course I agree with all the points you made, Brian. > >_______________________________________________ >hiaps mailing list >hiaps@ietf.org >https://www.ietf.org/mailman/listinfo/hiaps From nobody Wed Mar 12 03:48:40 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51F71A0947; Wed, 12 Mar 2014 03:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 vWopZN-Ixu2w; Wed, 12 Mar 2014 03:48:33 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 9284D1A094F; Wed, 12 Mar 2014 03:48:31 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 7A0B52AC4E5; Wed, 12 Mar 2014 11:48:20 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 5D0A6C8068; Wed, 12 Mar 2014 11:48:20 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Wed, 12 Mar 2014 11:48:20 +0100 From: To: Joe Touch , Scott Brim Date: Wed, 12 Mar 2014 11:48:18 +0100 Thread-Topic: [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 Thread-Index: Ac88iJG6VI+qAYoaQ6C41J9XxI9txQBVtN1A Message-ID: <94C682931C08B048B7A8645303FDC9F36F503EE33A@PUEXCB1B.nanterre.francetelecom.fr> References: <5318A21D.7020508@bogus.com> <5318B86E.1040805@gmail.com> <531DF094.3090607@isi.edu> <531DF9F9.2090205@isi.edu> In-Reply-To: <531DF9F9.2090205@isi.edu> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/fjxPrzxhfy8cYMsm-3zGctv6dTM Cc: "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" , Internet Area , "hiaps@ietf.org" Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 10:48:36 -0000 Hi Scott, all, In addition to what is mentioned by Joe, RFC6967 provides some recommendati= ons: ".. the following design considerations are to be taken into account: o It is recommended that HOST_IDs be limited to providing local uniqueness rather than global uniqueness. o The address-sharing function should not use permanent HOST_ID values." A detailed audit should be conducted for specific solutions. These solution= s should follow the guidelines provided in RFC6967: " 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. " draft-boucadair-intarea-host-identifier-scenarios does not specify a soluti= on but enumerate use cases in which host identification issues are encounte= red. Citing privacy considerations discussed RFC6967 would be fine.=20 Cheers, Med >-----Message d'origine----- >De=A0: Int-area [mailto:int-area-bounces@ietf.org] De la part de Joe Touch >Envoy=E9=A0: lundi 10 mars 2014 18:44 >=C0=A0: Scott Brim >Cc=A0: draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org; >Internet Area; hiaps@ietf.org >Objet=A0: Re: [Int-area] request to consider sponsoring >http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier- >scenarios-04 > > > >On 3/10/2014 10:16 AM, Scott Brim wrote: >> Joe, http:// >> tools.ietf.org >> / >> html >> /rfc6967#section-3 >> says that a host-id will >> be generated anew any time the endpoint IP address changes, perhaps more >> often. > >I believe you're referring to: > > "... a distinct HOST_ID may be used by the address- > sharing function when the host reboots or gets a new internal IP > address." > >That's not a requirement; it's an example. This doc is a survey; no one >rule applies everywhere. > >> Is that wrong? It's hard to do a privacy audit if the behavior isn't >> agreed on. > >Again, it's a survey. An audit would apply to a given approach. > >Joe > >_______________________________________________ >Int-area mailing list >Int-area@ietf.org >https://www.ietf.org/mailman/listinfo/int-area From nobody Wed Mar 12 08:18:07 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB001A09BA; Wed, 12 Mar 2014 08:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.999 X-Spam-Level: X-Spam-Status: No, score=-8.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 0urdCuAS4Omt; Wed, 12 Mar 2014 08:17:55 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id C136D1A09B4; Wed, 12 Mar 2014 08:17:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4352; q=dns/txt; s=iport; t=1394637469; x=1395847069; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=HCV2axHMt4elgGEw+6fzOIyQ1RB9pgRDeErzkh3XX00=; b=W4X/r5vgCFl5QnVmfgY8wRz/hILvZBLtXn6AE6dHkKtq+mupLJl4AEuV xuNwaQcR/031dCQ2Pfk4WSNVmnBREUNvNF1do0f7TM+oZ5EvY/4ZmZrpx QpZBCwE8mXsfZY6XeY/aU+QuoWSHOE4rYlxkU3RhNrGCmAnae454C1BRT Y=; X-IronPort-AV: E=Sophos;i="4.97,638,1389744000"; d="scan'208";a="26899886" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by alln-iport-5.cisco.com with ESMTP; 12 Mar 2014 15:17:48 +0000 Received: from [10.21.79.5] ([10.21.79.5]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2CFGx04018410; Wed, 12 Mar 2014 15:17:47 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: Date: Wed, 12 Mar 2014 00:38:58 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3B0178C3-442C-42CB-9CEE-12F5A0312965@cisco.com> References: To: Reinaldo Penno (repenno) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/PnrNM7bCjbt9s9wBvzoUcCPYn-0 Cc: "hiaps@ietf.org" , Internet Area , Brian E Carpenter , "draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org" Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 15:18:00 -0000 On Mar 7, 2014, at 9:46 PM, Reinaldo Penno (repenno) = wrote: > There are several paid VPN services that provide anonymity through > addresses sharing. This is becoming more and more popular these days. >=20 > It is public to public translation where you get a shared IP address = on > purpose. This is not for attack purposes but just to reduce tracking = by > third-parties.=20 >=20 > I would think that people interested in these services will continue = to > use them but public IPv6 to public IPv6. Sure, and those services won't log and won't emit any of the identifiers = in RFC6967. draft-boucadair-intarea-host-identifier-scenarios is trying to explain = when such an identifier is useful; not when it isn't useful. -d >=20 > On 3/7/14, 12:31 PM, "Dan Wing (dwing)" wrote: >=20 >>=20 >> On Mar 6, 2014, at 6:03 PM, Brian E Carpenter >> wrote: >>=20 >>> a) Since this is fixing some of the damage done by NAT, it's >>> really unfinished business for BEHAVE, which if iirc was a >>> Transport Area WG. Just saying... >>>=20 >>> b) The word "privacy" doesn't appear in the draft. Discussing >>> privacy aspects is clearly essential if there is any thought of >>> advancing this work. Actually I doubt if such a host ID is ever >>> going to be acceptable from a privacy point of view, unless the >>> end system is at liberty to change it at random (like RFC 4941). >>=20 >> I interpret your statement to mean that address sharing is a = desirable >> security property. If that interpretation is correct, where does = that >> leave IPv6? >>=20 >>=20 >>> c) A hard-nosed argument is that since we want to sunset IPv4, >>> it's time to stop working on ways of making NAT solutions work >>> better. Is there anything in the use cases that can't be fixed by >>> native IPv6? >>=20 >> Yes, attackers won't move to IPv6 if IPv4 provides them a superior = way to >> hide their activities. There are attackers already using IPv4 CGN to >> obfuscate themselves. >>=20 >> -d >>=20 >>=20 >>>=20 >>> (The use case in expired draft >>> = http://tools.ietf.org/html/draft-sarikaya-fmc-prefix-sharing-usecase-01 >>> is not at all convincing to me, especially when adding the privacy >>> argument. It actually seems to describe a bug in 3GPP. But in any = case, >>> the draft appears to suggest mitigations.) >>>=20 >>> Regards >>> Brian >>>=20 >>> On 07/03/2014 05:28, joel jaeggli wrote: >>>> Greetings int-area and hiaps-mailing-list folks, >>>>=20 >>>> I realize that this is midweek at the IETF, however this question = is >>>> not >>>> far from several discussions I've had this week. >>>>=20 >>>> I have been asked to consider AD sponsoring >>>>=20 >>>> = http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scena >>>> rios-04 >>>>=20 >>>> In the process of considering doing so I'd like to get some input = with >>>> respect to: >>>>=20 >>>> A. The appetite for pursuing some or any of this work in existing >>>> working groups, and in particular within the INT area. >>>>=20 >>>> B. A consensus basis for moving beyond RFC 6269 into active work in >>>> this >>>> area. >>>>=20 >>>> C. How we address concerns raised by the IETF community expressed >>>> through draft-farrell-perpass-attack when evaluating scenarios and >>>> beginning to address requirements and solution-space. >>>>=20 >>>> Obviously these are complex questions and I do not expect that we = will >>>> arrive at answers easily nor does work on this or other drafts = depend >>>> on >>>> answering them, however it's part of the dialog. >>>>=20 >>>> Thanks >>>> joel >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> = ------------------------------------------------------------------------ >>>>=20 >>>> _______________________________________________ >>>> Int-area mailing list >>>> Int-area@ietf.org >>>> https://www.ietf.org/mailman/listinfo/int-area >>>=20 >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >>=20 >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >=20 From nobody Wed Mar 12 08:18:10 2014 Return-Path: X-Original-To: hiaps@ietfa.amsl.com Delivered-To: hiaps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A841A074B; Wed, 12 Mar 2014 08:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.999 X-Spam-Level: X-Spam-Status: No, score=-13.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 h5Vz-K4oO92v; Wed, 12 Mar 2014 08:17:59 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 926781A09B8; Wed, 12 Mar 2014 08:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4829; q=dns/txt; s=iport; t=1394637470; x=1395847070; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=0pwElwBxHfNz/dWu2QriRLvD3kEnEtctamwGgQt8rIw=; b=HtRzDyg+vahJmLNVNXN19rQZHvCheDXPgHP8TpokAeR+w6yXudvdUBSC DI9nCBoaNH3ieYfjmT/kONFAz86e+qjVGApQdfBPbP13SllyZXR9f3ZLC hwuPEiJeEoxSFY1NXE0loqo9kbPMgiAeQuk4eBsR1isImrt9d4zrZhNGv M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAIZ5IFOrRDoH/2dsb2JhbABagwY7un2HLoEcFnSCJQEBAQMBAQEBNy0HCwULCxgjCyEGMAYTFAeHSgMJBw7LTA2GMBeMRYFkMweDJIEUBJZYgW2BMoUahhmFSIFvgT49 X-IronPort-AV: E=Sophos;i="4.97,638,1389744000"; d="scan'208";a="309799120" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-7.cisco.com with ESMTP; 12 Mar 2014 15:17:49 +0000 Received: from [10.21.79.5] ([10.21.79.5]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2CFGx05018410; Wed, 12 Mar 2014 15:17:48 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: <531AC0C6.1000203@gmail.com> Date: Wed, 12 Mar 2014 00:45:32 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5318A21D.7020508@bogus.com> <5318B86E.1040805@gmail.com> <2CF311E1-929B-4847-A98E-BC495B526D5E@cisco.com> <531AC0C6.1000203@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/kenUOIXsUp1PpgIzDVQ-C7XHEkQ Cc: joel jaeggli , "hiaps@ietf.org" , Internet Area , draft-boucadair-intarea-host-identifier-scenarios@tools.ietf.org Subject: Re: [hiaps] [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 X-BeenThere: hiaps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Host Identification, Address and Prefix Sharing in Wi-Fi Access \(hiaps\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 15:18:06 -0000 On Mar 8, 2014, at 7:03 AM, Brian E Carpenter = wrote: > Dan, >=20 > On 08/03/2014 09:31, Dan Wing wrote: >> On Mar 6, 2014, at 6:03 PM, Brian E Carpenter = wrote: >>=20 >>> a) Since this is fixing some of the damage done by NAT, it's >>> really unfinished business for BEHAVE, which if iirc was a >>> Transport Area WG. Just saying... >>>=20 >>> b) The word "privacy" doesn't appear in the draft. Discussing >>> privacy aspects is clearly essential if there is any thought of >>> advancing this work. Actually I doubt if such a host ID is ever >>> going to be acceptable from a privacy point of view, unless the >>> end system is at liberty to change it at random (like RFC 4941). >>=20 >> I interpret your statement to mean that address sharing is a = desirable security property. If that interpretation is correct, where = does that leave IPv6? >=20 > I'm not sure where you found that in what I wrote. The authors can probably pull or copy text from RFC6967's Section 3 and = its Security Considerations. > I think that address > sharing is undesirable from every point of view; I suppose it > might reduce the risk of layer 3 based tracking of users, > but that's certainly not what I meant. Address sharing does reduce the risk of layer 3 tracking. Combined with = port randomization between subscribers ("NAPT"), it can do a pretty = helpful job if that is the intent. > IPv6 with RFC 4941 (which > appears to be deployed in the vast majority of IPv6 clients today) > is fine from this point of view. Not really. But that is a different discussion; perhaps we should have = that discussion somewhere. > I don't see any difference in > privacy effect between a randomly-changing shared-IPv4 Host ID and > a randomly-changing IPv6 address. The difference is scope: can the traffic be identified to a single home = (IPv6 /64 address; IPv4 /32 address; or a PSTN telephone number), or can = the traffic only be identified to a region within a city (HTTP caching = proxy; carrier grade NAT). >>> c) A hard-nosed argument is that since we want to sunset IPv4, >>> it's time to stop working on ways of making NAT solutions work >>> better. Is there anything in the use cases that can't be fixed by >>> native IPv6? >>=20 >> Yes, attackers won't move to IPv6 if IPv4 provides them a superior = way to hide their activities. There are attackers already using IPv4 = CGN to obfuscate themselves. >=20 > Attackers will move to IPv6 when their targets do so. I guess > such attackers will find RFC 4941 useful too. What's good for > the privacy of legitimate users is also good for the privacy > of attackers. -d > Brian >=20 >> -d >>=20 >>=20 >>> (The use case in expired draft >>> = http://tools.ietf.org/html/draft-sarikaya-fmc-prefix-sharing-usecase-01 >>> is not at all convincing to me, especially when adding the privacy >>> argument. It actually seems to describe a bug in 3GPP. But in any = case, >>> the draft appears to suggest mitigations.) >>>=20 >>> Regards >>> Brian >>>=20 >>> On 07/03/2014 05:28, joel jaeggli wrote: >>>> Greetings int-area and hiaps-mailing-list folks, >>>>=20 >>>> I realize that this is midweek at the IETF, however this question = is not >>>> far from several discussions I've had this week. >>>>=20 >>>> I have been asked to consider AD sponsoring >>>> = http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenari= os-04 >>>>=20 >>>> In the process of considering doing so I'd like to get some input = with >>>> respect to: >>>>=20 >>>> A. The appetite for pursuing some or any of this work in existing >>>> working groups, and in particular within the INT area. >>>>=20 >>>> B. A consensus basis for moving beyond RFC 6269 into active work in = this >>>> area. >>>>=20 >>>> C. How we address concerns raised by the IETF community expressed >>>> through draft-farrell-perpass-attack when evaluating scenarios and >>>> beginning to address requirements and solution-space. >>>>=20 >>>> Obviously these are complex questions and I do not expect that we = will >>>> arrive at answers easily nor does work on this or other drafts = depend on >>>> answering them, however it's part of the dialog. >>>>=20 >>>> Thanks >>>> joel >>>>=20 >>>>=20 >>>>=20 >>>> = ------------------------------------------------------------------------ >>>>=20 >>>> _______________________________________________ >>>> Int-area mailing list >>>> Int-area@ietf.org >>>> https://www.ietf.org/mailman/listinfo/int-area >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >>=20 >> . >>=20