From nobody Sun Nov 2 12:45:17 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 5C7DF1A0396 for ; Sun, 2 Nov 2014 12:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.206 X-Spam-Level: X-Spam-Status: No, score=0.206 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.594] 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 X5e9sYUXCtDU for ; Sun, 2 Nov 2014 12:45:13 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 563181A039F for ; Sun, 2 Nov 2014 12:45:13 -0800 (PST) Received: from mb-aye.local (50-0-150-57.dsl.static.fusionbroadband.com [50.0.150.57]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id sA2KitEq027524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 2 Nov 2014 20:44:59 GMT (envelope-from joelja@bogus.com) Message-ID: <5456954C.7010306@bogus.com> Date: Sun, 02 Nov 2014 12:34:20 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, "sarikaya@ieee.org" References: <545067B6.4020704@bogus.com> <5450F1B2.9070604@akamai.com> <787AE7BB302AE849A7480A190F8B93301C0A81@OPEXCLILM23.corporate.adroot.infra.ftgroup> <545100BE.7090604@bogus.com> <54515DDA.3060500@bogus.com> <787AE7BB302AE849A7480A190F8B93301C37D5@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93301C37D5@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ChQa47qtcqX3vtfOFW6s320FClbDcHnTl" Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/9KRVClB-0w4Sqvmn1H-x5VepmOg Cc: "hiaps@ietf.org" , Brandon Williams Subject: Re: [hiaps] some discussion in the press... 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: Sun, 02 Nov 2014 20:45:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ChQa47qtcqX3vtfOFW6s320FClbDcHnTl Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 10/31/14 9:03 AM, mohamed.boucadair@orange.com wrote: > Hi Behcet, >=20 > I'm still supportive of this work and actually I'd like to see some > concrete progress. Saying that, I'm not sure Joel is asking for > another BoF but perhaps I'm wrong here. I'm not. somebody should reread the thread if they believe that. > Just like the "panic" with pervasive monitoring, there are several > mailing lists that are alarmed with injection of the identifiers. > These practices are not new but these are "panic" cycles... The side > effect of it is that these alarming news can pollute the HOST_ID work > despite the fact that we are not asking for unique/stable identifiers > nor asking to leak/reveal any customer ID, profile ID, etc. >=20 > BTW, there IETF documents that already documents some practices of > injecting identifiers, see for instance: > http://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-01#section-= 3.3 > that is more close to what Joel shared in this list. >=20 > Cheers, Med >=20 > -----Message d'origine----- De : Behcet Sarikaya > [mailto:sarikaya2012@gmail.com] Envoy=E9 : jeudi 30 octobre 2014 20:04 = > =C0 : joel jaeggli Cc : hiaps@ietf.org; BOUCADAIR Mohamed IMT/OLN; > Brandon Williams Objet : Re: [hiaps] some discussion in the press... >=20 > Hi Med, Brandon, >=20 > Last time Med was on paternity leave and he could help. Brandon > found out about hiaps late. >=20 > Now, it is time for you two to say something regarding >=20 >> a bof proposal that addresses the scope and privacy/pervasive >> monitoring concerns and which has a critical mass of effort behind >> it might certainly be worthy of consideration as bof. >=20 >=20 > Regards, >=20 > Behcet On Wed, Oct 29, 2014 at 4:36 PM, joel jaeggli > wrote: >> On 10/29/14 9:51 AM, Behcet Sarikaya wrote: >>> Hi Joel, >>>=20 >>> On Wed, Oct 29, 2014 at 9:59 AM, joel jaeggli >>> wrote: >>>> On 10/29/14 7:10 AM, mohamed.boucadair@orange.com wrote: >>>>> Hi Brian, >>>>>=20 >>>>> I echo your comment. >>>>>=20 >>>>> None of the proposals inventoried in the HOST_ID effort is >>>>> trying to do the same thing as X-UIDH header. Moreover, none >>>>> of these proposals is endorsing the following headers (but >>>>> not limited to) nor aims at revealing a customer ID, account >>>>> ID, profile ID, etc.: >>>>>=20 >>>>> HTTP_MSISDN, HTTP_X_MSISDN, HTTP_X_UP_CALLING_LINE_ID,=20 >>>>> HTTP_X_NOKIA_MSISDN, HTTP_X_HTS_CLID, HTTP_X_MSP_CLID,=20 >>>>> HTTP_X_NX_CLID, HTTP__RAPMIN, HTTP_X_WAP_MSISDN, HTTP_COOKIE, >>>>> HTTP_X_UP_LSID, HTTP_X_H3G_MSISDN, HTTP_X_JINNY_CID, >>>>> HTTP_X_NETWORK_INFO, ... >>>>>=20 >>>>> Cheers, Med >>>>>=20 >>>>> -----Message d'origine----- De : hiaps >>>>> [mailto:hiaps-bounces@ietf.org] De la part de Brandon >>>>> Williams Envoy=E9 : mercredi 29 octobre 2014 14:55 =C0 : joel >>>>> jaeggli; hiaps@ietf.org Objet : Re: [hiaps] some discussion >>>>> in the press... >>>>>=20 >>>>> Agreed. Inserting a publicly visible user identifier is a bad >>>>> idea. That's why all the proposals that have come from people >>>>> on the hiaps list (to the best of my knowledge) have focused >>>>> on relaying _host_ identifiers that are already publicly >>>>> visible (generally the public IP address) through to the >>>>> other side of middleboxes that are hiding such publicly >>>>> visible identifiers. If there are proposals out there that=20 >>>>> violate this principle, I agree entirely that they should be >>>>> abandoned. >>>>=20 >>>> imho one of the assumptions I see in the work is that the host=20 >>>> identifier being relayed was previosuly not publicly visible, >>>> hence the need for hostid injection. That applies to nat >>>> translation for example it also applies to differentating >>>> between prefix sharing UE's in IPV6 by something other than >>>> source address. >>>>=20 >>>> http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-s= cenarios-07 >>>> >>>>=20 http://tools.ietf.org/html/rfc6269 >>>>=20 >>>> that's part of the reason for hiaps bof proposal to consider >>>> the problem of securing such an identifier from differentiation >>>> by surveillance. >>>=20 >>> Absolutely. >>>=20 >>> Should we revive the bof effort? >>=20 >> you didn't hear me say that. I think you know where we left it. >>=20 >> From my vantage point a bof proposal that addresses the scope and=20 >> privacy/pervasive monitoring concerns and which has a critical mass >> of effort behind it might certainly be worthy of consideration as >> bof. >>=20 >>> I think that doing the standardization related to hosted in >>> hiaps rather than intarea is the right way to go for IETF. >>=20 >> We created this mailing list to have a place to discuss host=20 >> identification, we can use it for that or we can get rid of it. >>=20 >>> Behcet >>>>=20 >>>>> --Brandon >>>>>=20 >>>>> On 10/29/2014 12:06 AM, joel jaeggli wrote: >>>>>> this is pretty much exactly what I would have expected from >>>>>> injection on the wire of an identity token... >>>>>>=20 >>>>>> http://webpolicy.org/2014/10/24/how-verizons-advertising-header-wo= rks/ >>>>>> >>>>>> >>>>>>=20 http://www.wired.com/2014/10/verizons-perma-cookie/ >>>>>>=20 >>>>>> http://www.forbes.com/sites/kashmirhill/2014/10/28/att-says-its-te= sting-unkillable-tracker-on-customers-smartphones/ >>>>>> >>>>> >>>> >>>> >>>> >>>> >>>>>>=20 _______________________________________________ >>>> hiaps mailing list hiaps@ietf.org=20 >>>> https://www.ietf.org/mailman/listinfo/hiaps >>>>=20 >>>=20 >>> _______________________________________________ hiaps mailing >>> list hiaps@ietf.org https://www.ietf.org/mailman/listinfo/hiaps >>>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ hiaps mailing list=20 >> hiaps@ietf.org https://www.ietf.org/mailman/listinfo/hiaps --ChQa47qtcqX3vtfOFW6s320FClbDcHnTl 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 iEYEARECAAYFAlRWlU0ACgkQ8AA1q7Z/VrII9gCdFDjWngcNAUpsBK8yit8EwTW2 qdgAniBT07QxkEeGYqI4U2Dt9GwcCFIe =SRnu -----END PGP SIGNATURE----- --ChQa47qtcqX3vtfOFW6s320FClbDcHnTl-- From nobody Mon Nov 3 07:31:39 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 766C31A02F1 for ; Mon, 3 Nov 2014 07:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOHPjiIexY-u for ; Mon, 3 Nov 2014 07:31:36 -0800 (PST) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD621A0273 for ; Mon, 3 Nov 2014 07:31:36 -0800 (PST) Received: by mail-yh0-f43.google.com with SMTP id f73so1169131yha.16 for ; Mon, 03 Nov 2014 07:31:35 -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:content-transfer-encoding; bh=cOjY3aenN1pL1iIBq1KAfO96HItbjity+GUR6kzaX/U=; b=wOmgUbKQINFC8QDGfETwMoGRyo7sH2uFkn57IeqPVwNad0XiLArFwAdueX1cu12DSf 7Eg00snlosk2ngu2fkcOogv9VeqZ4txrAGqGfDTv+cI6D1K9ZkJzJ6iiNe3OuB+kTbAr GjVI4bypXurSlnh6LEAcZfB0tuHonTL4bs8seuDxbQHlbEPBS1j10TCMF/2FKrZiYORV UMQ5TJdP5XApFiX9AjASYridKBRDDLp32tJUDDb6gj6p6TdvL4nmfyhn7FQoqvbaBlTk CWcUr1xhSU0P+kg04V8z6rKQ0e5O3SxEh5y9X63iHq7YdVbGwvoK+7e3Dz6rLtCi97pQ PMwA== MIME-Version: 1.0 X-Received: by 10.170.121.207 with SMTP id n198mr33818004ykb.89.1415028695722; Mon, 03 Nov 2014 07:31:35 -0800 (PST) Received: by 10.170.71.198 with HTTP; Mon, 3 Nov 2014 07:31:35 -0800 (PST) In-Reply-To: <5456954C.7010306@bogus.com> References: <545067B6.4020704@bogus.com> <5450F1B2.9070604@akamai.com> <787AE7BB302AE849A7480A190F8B93301C0A81@OPEXCLILM23.corporate.adroot.infra.ftgroup> <545100BE.7090604@bogus.com> <54515DDA.3060500@bogus.com> <787AE7BB302AE849A7480A190F8B93301C37D5@OPEXCLILM23.corporate.adroot.infra.ftgroup> <5456954C.7010306@bogus.com> Date: Mon, 3 Nov 2014 09:31:35 -0600 Message-ID: From: Behcet Sarikaya To: joel jaeggli Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/4Q700whuDRjQ6_hfi_1YIydmzv8 Cc: "hiaps@ietf.org" , Mohamed Boucadair , Brandon Williams Subject: Re: [hiaps] some discussion in the press... 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, 03 Nov 2014 15:31:38 -0000 On Sun, Nov 2, 2014 at 2:34 PM, joel jaeggli wrote: > On 10/31/14 9:03 AM, mohamed.boucadair@orange.com wrote: >> Hi Behcet, >> >> I'm still supportive of this work and actually I'd like to see some >> concrete progress. Saying that, I'm not sure Joel is asking for >> another BoF but perhaps I'm wrong here. > > I'm not. somebody should reread the thread if they believe that. Understood. The point is hiaps list has been around for some time. I think that Joel was indicating that maybe it should be decided whether to close this list or to continue the discussions. If the latter is chosen, that is something that would lead to going to another BoF, or whatever is decided as the next step. Joel, is this correct? We need to clarify this as a number of people may jump in as a result. Regards, Behcet > >> Just like the "panic" with pervasive monitoring, there are several >> mailing lists that are alarmed with injection of the identifiers. >> These practices are not new but these are "panic" cycles... The side >> effect of it is that these alarming news can pollute the HOST_ID work >> despite the fact that we are not asking for unique/stable identifiers >> nor asking to leak/reveal any customer ID, profile ID, etc. >> >> BTW, there IETF documents that already documents some practices of >> injecting identifiers, see for instance: >> http://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-01#section-3= .3 >> that is more close to what Joel shared in this list. >> >> Cheers, Med >> >> -----Message d'origine----- De : Behcet Sarikaya >> [mailto:sarikaya2012@gmail.com] Envoy=C3=A9 : jeudi 30 octobre 2014 20:0= 4 >> =C3=80 : joel jaeggli Cc : hiaps@ietf.org; BOUCADAIR Mohamed IMT/OLN; >> Brandon Williams Objet : Re: [hiaps] some discussion in the press... >> >> Hi Med, Brandon, >> >> Last time Med was on paternity leave and he could help. Brandon >> found out about hiaps late. >> >> Now, it is time for you two to say something regarding >> >>> a bof proposal that addresses the scope and privacy/pervasive >>> monitoring concerns and which has a critical mass of effort behind >>> it might certainly be worthy of consideration as bof. >> >> >> Regards, >> >> Behcet On Wed, Oct 29, 2014 at 4:36 PM, joel jaeggli >> wrote: >>> On 10/29/14 9:51 AM, Behcet Sarikaya wrote: >>>> Hi Joel, >>>> >>>> On Wed, Oct 29, 2014 at 9:59 AM, joel jaeggli >>>> wrote: >>>>> On 10/29/14 7:10 AM, mohamed.boucadair@orange.com wrote: >>>>>> Hi Brian, >>>>>> >>>>>> I echo your comment. >>>>>> >>>>>> None of the proposals inventoried in the HOST_ID effort is >>>>>> trying to do the same thing as X-UIDH header. Moreover, none >>>>>> of these proposals is endorsing the following headers (but >>>>>> not limited to) nor aims at revealing a customer ID, account >>>>>> ID, profile ID, etc.: >>>>>> >>>>>> HTTP_MSISDN, HTTP_X_MSISDN, HTTP_X_UP_CALLING_LINE_ID, >>>>>> HTTP_X_NOKIA_MSISDN, HTTP_X_HTS_CLID, HTTP_X_MSP_CLID, >>>>>> HTTP_X_NX_CLID, HTTP__RAPMIN, HTTP_X_WAP_MSISDN, HTTP_COOKIE, >>>>>> HTTP_X_UP_LSID, HTTP_X_H3G_MSISDN, HTTP_X_JINNY_CID, >>>>>> HTTP_X_NETWORK_INFO, ... >>>>>> >>>>>> Cheers, Med >>>>>> >>>>>> -----Message d'origine----- De : hiaps >>>>>> [mailto:hiaps-bounces@ietf.org] De la part de Brandon >>>>>> Williams Envoy=C3=A9 : mercredi 29 octobre 2014 14:55 =C3=80 : joel >>>>>> jaeggli; hiaps@ietf.org Objet : Re: [hiaps] some discussion >>>>>> in the press... >>>>>> >>>>>> Agreed. Inserting a publicly visible user identifier is a bad >>>>>> idea. That's why all the proposals that have come from people >>>>>> on the hiaps list (to the best of my knowledge) have focused >>>>>> on relaying _host_ identifiers that are already publicly >>>>>> visible (generally the public IP address) through to the >>>>>> other side of middleboxes that are hiding such publicly >>>>>> visible identifiers. If there are proposals out there that >>>>>> violate this principle, I agree entirely that they should be >>>>>> abandoned. >>>>> >>>>> imho one of the assumptions I see in the work is that the host >>>>> identifier being relayed was previosuly not publicly visible, >>>>> hence the need for hostid injection. That applies to nat >>>>> translation for example it also applies to differentating >>>>> between prefix sharing UE's in IPV6 by something other than >>>>> source address. >>>>> >>>>> http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-sc= enarios-07 >>>>> >>>>> > http://tools.ietf.org/html/rfc6269 >>>>> >>>>> that's part of the reason for hiaps bof proposal to consider >>>>> the problem of securing such an identifier from differentiation >>>>> by surveillance. >>>> >>>> Absolutely. >>>> >>>> Should we revive the bof effort? >>> >>> you didn't hear me say that. I think you know where we left it. >>> >>> From my vantage point a bof proposal that addresses the scope and >>> privacy/pervasive monitoring concerns and which has a critical mass >>> of effort behind it might certainly be worthy of consideration as >>> bof. >>> >>>> I think that doing the standardization related to hosted in >>>> hiaps rather than intarea is the right way to go for IETF. >>> >>> We created this mailing list to have a place to discuss host >>> identification, we can use it for that or we can get rid of it. >>> >>>> Behcet >>>>> >>>>>> --Brandon >>>>>> >>>>>> On 10/29/2014 12:06 AM, joel jaeggli wrote: >>>>>>> this is pretty much exactly what I would have expected from >>>>>>> injection on the wire of an identity token... >>>>>>> >>>>>>> http://webpolicy.org/2014/10/24/how-verizons-advertising-header-wor= ks/ >>>>>>> >>>>>>> >>>>>>> > http://www.wired.com/2014/10/verizons-perma-cookie/ >>>>>>> >>>>>>> http://www.forbes.com/sites/kashmirhill/2014/10/28/att-says-its-tes= ting-unkillable-tracker-on-customers-smartphones/ >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>> > _______________________________________________ >>>>> hiaps mailing list hiaps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/hiaps >>>>> >>>> >>>> _______________________________________________ hiaps mailing >>>> list hiaps@ietf.org https://www.ietf.org/mailman/listinfo/hiaps >>>> >>> >>> >>> >>> >>> _______________________________________________ hiaps mailing list >>> hiaps@ietf.org https://www.ietf.org/mailman/listinfo/hiaps > > > > From nobody Tue Nov 4 06:18:03 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 515111A6F0E for ; Tue, 4 Nov 2014 06:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.444 X-Spam-Level: X-Spam-Status: No, score=-4.444 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 596VsnhMC6S1 for ; Tue, 4 Nov 2014 06:17:58 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE82F1A8780 for ; Tue, 4 Nov 2014 06:17:57 -0800 (PST) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail11.telekom.de with ESMTP; 04 Nov 2014 15:17:55 +0100 X-IronPort-AV: E=Sophos;i="5.07,313,1413237600"; d="scan'208";a="160877618" Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 04 Nov 2014 15:17:54 +0100 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 4 Nov 2014 15:17:54 +0100 From: To: , Date: Tue, 4 Nov 2014 15:17:53 +0100 Thread-Topic: [hiaps] some discussion in the press... Thread-Index: Ac/3e0WwT+BSadtyRzmAZNiQMnltSwAut09A Message-ID: <05C81A773E48DD49B181B04BA21A342A2E5EA932D9@HE113484.emea1.cds.t-internal.com> References: <545067B6.4020704@bogus.com> <5450F1B2.9070604@akamai.com> <787AE7BB302AE849A7480A190F8B93301C0A81@OPEXCLILM23.corporate.adroot.infra.ftgroup> <545100BE.7090604@bogus.com> <54515DDA.3060500@bogus.com> <787AE7BB302AE849A7480A190F8B93301C37D5@OPEXCLILM23.corporate.adroot.infra.ftgroup> <5456954C.7010306@bogus.com> In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/cmSUTZNGkN-rkwlPZmXZVWW43cw Cc: hiaps@ietf.org, mohamed.boucadair@orange.com, brandon.williams@akamai.com Subject: Re: [hiaps] some discussion in the press... 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, 04 Nov 2014 14:18:01 -0000 RGVhciBhbGwsDQpSZWdhcmRpbmcgdGhlIHBvdGVudGlhbCBkaWZmZXJlbnRseSBpbnRlcnByZXRh YmxlIHBvc3RpbmdzIG9uIHRoaXMgbGlzdCBJTUhPIHRoZSBqb2Igb2YgdGhlIE1MIHNob3VsZCBi ZSB0byBlbmFibGUgZGlzY3Vzc2lvbiBvbiBpc3N1ZXMgd2l0aCBuZXcgYW5kIGV4aXN0aW5nIGlk ZW50aXRpZXMgKHdoaWNoIG1pZ2h0IGFsc28gaW5jbHVkZSBzZXJ2aWNlIG9yIHNlc3Npb24gSURz IGJlc2lkZSBob3N0IElEcyBJTU8pLg0KIA0KTWFpbiBhc3BlY3RzIGFyZSBvZiBjb3Vyc2UgdXNl ZnVsbmVzcyBpbiBlbmFibGluZyAobmV3KSBzZXJ2aWNlcyBhbmQgaW1wcm92aW5nIHNlcnZpY2Ug cGVyZm9ybWFuY2UgdmlhIChuZXcpIG5ldHdvcmtzIC0gYnV0IGEgdG9waWMgb2YgYWRlcXVhdGUg aW1wb3J0YW5jZSBpcyBob3cgdG8gcHJldmVudCB0aGVpciBtaXMtdXNlIGluIHRlcm1zIG9mIGlu Y3JlYXNlZCBzZWN1cml0eSB0aHJlYXRzLCBhdHRhY2sgcHJvYmFiaWxpdHkgYW5kIGZyZXF1ZW5j eSwgZGVjcmVhc2VkIHByaXZhY3kgYW5kIHNvIG9uIC0gYXMgaXMgc3ViamVjdCBvZiB0aGUgbGlu a3Mgd2l0aGluIHRoZSBvcmlnaW5hbCB0aHJlYWQuDQoNClBlcnNvbmFsbHkgSSB0aGluayB0aGF0 IHdpdGggaW5jcmVhc2VkIGhldGVyb2dlbmVpdHkgb2YgbmV0d29ya3MsIGRldmljZXMsIHNlcnZp Y2VzLCBhcHBsaWNhdGlvbiBzY2VuYXJpb3MgZXRjLiB0aGUgZGVtYW5kIGZvciBkaWZmZXJlbnRp YXRpb24gKGFuZCB0aGVyZWZvcmUgcG90ZW50aWFsIG5ldyBmbGFncywgb3B0aW9ucywgaWRlbnRp dGllcyBldGMuKSB3aWxsIGdyb3cgdG8gZ3JhbnQgZnVsZmlsbWVudCBvZiAodXNlciBhbmQgb3Bl cmF0b3IpIGV4cGVjdGF0aW9ucyB0b3dhcmRzIG5leHQgZ2VuZXJhdGlvbiBjb21tdW5pY2F0aW9u IChhbHNvIGR1YmJlZCBhcyBiZXlvbmQgNEcpLiANCg0KVGhlcmVmb3JlIHdlIHNob3VsZCBrZWVw IG9uIGRpc2N1c3NpbmcgaWRlbnRpdHkgaXNzdWVzIC0gZS5nLiBoZXJlIC4uLiA7LSkNCg0KV2hl dGhlciB0aGlzIHdvdWxkIHJlc3VsdCBpbiBhIGNhbGwgZm9yIGEgbmV3L3Jldml2ZWQgQm9GIHNl ZW1zIHRvIG1lIHRvIGJlIGFub3RoZXIgcXVlc3Rpb24gdG8gYmUgcmFpc2VkIG9ubHkgYWZ0ZXIg dGhlIHdlbGwta25vd24gY3JpdGVyaWEgYXJlIGZ1bGZpbGxlZCAoc2VlIGUuZy4gcmZjNTQzNCkg YW5kIHdlIHNob3VsZCBub3QgaGF2ZSBzdWNoIGEgcHJlc3N1cmUgZm9yIHRoZSBjdXJyZW50IGRp c2N1c3Npb25zIC4uLiANCg0KanVzdCBteSAyIENlbnRzIC0gaWYgeW91IGRpc2FncmVlIHBsZWFz ZSBzcGVhayB1cCANCg0KVGhhbmtzIQ0KQmVzdCByZWdhcmRzDQpEaXJrDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBoaWFwcyBbbWFpbHRvOmhpYXBzLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBCZWhjZXQgU2FyaWtheWENClNlbnQ6IE1vbnRhZywgMy4gTm92ZW1i ZXIgMjAxNCAxNjozMg0KVG86IGpvZWwgamFlZ2dsaQ0KQ2M6IGhpYXBzQGlldGYub3JnOyBNb2hh bWVkIEJvdWNhZGFpcjsgQnJhbmRvbiBXaWxsaWFtcw0KU3ViamVjdDogUmU6IFtoaWFwc10gc29t ZSBkaXNjdXNzaW9uIGluIHRoZSBwcmVzcy4uLg0KDQpPbiBTdW4sIE5vdiAyLCAyMDE0IGF0IDI6 MzQgUE0sIGpvZWwgamFlZ2dsaSA8am9lbGphQGJvZ3VzLmNvbT4gd3JvdGU6DQo+IE9uIDEwLzMx LzE0IDk6MDMgQU0sIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+PiBIaSBC ZWhjZXQsDQo+Pg0KPj4gSSdtIHN0aWxsIHN1cHBvcnRpdmUgb2YgdGhpcyB3b3JrIGFuZCBhY3R1 YWxseSBJJ2QgbGlrZSB0byBzZWUgc29tZSANCj4+IGNvbmNyZXRlIHByb2dyZXNzLiBTYXlpbmcg dGhhdCwgSSdtIG5vdCBzdXJlIEpvZWwgaXMgYXNraW5nIGZvciANCj4+IGFub3RoZXIgQm9GIGJ1 dCBwZXJoYXBzIEknbSB3cm9uZyBoZXJlLg0KPg0KPiBJJ20gbm90LiAgc29tZWJvZHkgc2hvdWxk IHJlcmVhZCB0aGUgdGhyZWFkIGlmIHRoZXkgYmVsaWV2ZSB0aGF0Lg0KDQpVbmRlcnN0b29kLg0K DQpUaGUgcG9pbnQgaXMgaGlhcHMgbGlzdCBoYXMgYmVlbiBhcm91bmQgZm9yIHNvbWUgdGltZS4g SSB0aGluayB0aGF0IEpvZWwgd2FzIGluZGljYXRpbmcgdGhhdCBtYXliZSBpdCBzaG91bGQgYmUg ZGVjaWRlZCB3aGV0aGVyIHRvIGNsb3NlIHRoaXMgbGlzdCBvciB0byBjb250aW51ZSB0aGUgZGlz Y3Vzc2lvbnMuIElmIHRoZSBsYXR0ZXIgaXMgY2hvc2VuLCB0aGF0IGlzIHNvbWV0aGluZyB0aGF0 IHdvdWxkIGxlYWQgdG8gZ29pbmcgdG8gYW5vdGhlciBCb0YsIG9yIHdoYXRldmVyIGlzIGRlY2lk ZWQgYXMgdGhlIG5leHQgc3RlcC4NCg0KSm9lbCwgaXMgdGhpcyBjb3JyZWN0Pw0KDQpXZSBuZWVk IHRvIGNsYXJpZnkgdGhpcyBhcyBhIG51bWJlciBvZiBwZW9wbGUgbWF5IGp1bXAgaW4gYXMgYSBy ZXN1bHQuDQoNClJlZ2FyZHMsDQoNCkJlaGNldA0KDQoNCj4NCj4+IEp1c3QgbGlrZSB0aGUgInBh bmljIiB3aXRoIHBlcnZhc2l2ZSBtb25pdG9yaW5nLCB0aGVyZSBhcmUgc2V2ZXJhbCANCj4+IG1h aWxpbmcgbGlzdHMgdGhhdCBhcmUgYWxhcm1lZCB3aXRoIGluamVjdGlvbiBvZiB0aGUgaWRlbnRp ZmllcnMuDQo+PiBUaGVzZSBwcmFjdGljZXMgYXJlIG5vdCBuZXcgYnV0IHRoZXNlIGFyZSAicGFu aWMiIGN5Y2xlcy4uLiBUaGUgc2lkZSANCj4+IGVmZmVjdCBvZiBpdCBpcyB0aGF0IHRoZXNlIGFs YXJtaW5nIG5ld3MgY2FuIHBvbGx1dGUgdGhlIEhPU1RfSUQgd29yayANCj4+IGRlc3BpdGUgdGhl IGZhY3QgdGhhdCB3ZSBhcmUgbm90IGFza2luZyBmb3IgdW5pcXVlL3N0YWJsZSBpZGVudGlmaWVy cyANCj4+IG5vciBhc2tpbmcgdG8gbGVhay9yZXZlYWwgYW55IGN1c3RvbWVyIElELCBwcm9maWxl IElELCBldGMuDQo+Pg0KPj4gQlRXLCB0aGVyZSBJRVRGIGRvY3VtZW50cyB0aGF0IGFscmVhZHkg ZG9jdW1lbnRzIHNvbWUgcHJhY3RpY2VzIG9mIA0KPj4gaW5qZWN0aW5nIGlkZW50aWZpZXJzLCBz ZWUgZm9yIGluc3RhbmNlOg0KPj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1zZmMtdXNlLWNhc2UtbW9iaWxpdHktMDEjc2VjdGlvDQo+PiBuLTMuMyB0aGF0IGlzIG1vcmUg Y2xvc2UgdG8gd2hhdCBKb2VsIHNoYXJlZCBpbiB0aGlzIGxpc3QuDQo+Pg0KPj4gQ2hlZXJzLCBN ZWQNCj4+DQo+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0gRGUgOiBCZWhjZXQgU2FyaWth eWEgDQo+PiBbbWFpbHRvOnNhcmlrYXlhMjAxMkBnbWFpbC5jb21dIEVudm95w6kgOiBqZXVkaSAz MCBvY3RvYnJlIDIwMTQgMjA6MDQgDQo+PiDDgCA6IGpvZWwgamFlZ2dsaSBDYyA6IGhpYXBzQGll dGYub3JnOyBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyANCj4+IEJyYW5kb24gV2lsbGlhbXMg T2JqZXQgOiBSZTogW2hpYXBzXSBzb21lIGRpc2N1c3Npb24gaW4gdGhlIHByZXNzLi4uDQo+Pg0K Pj4gSGkgTWVkLCBCcmFuZG9uLA0KPj4NCj4+IExhc3QgdGltZSBNZWQgd2FzIG9uIHBhdGVybml0 eSBsZWF2ZSBhbmQgaGUgY291bGQgaGVscC4gQnJhbmRvbiBmb3VuZCANCj4+IG91dCBhYm91dCBo aWFwcyBsYXRlLg0KPj4NCj4+IE5vdywgaXQgaXMgdGltZSBmb3IgeW91IHR3byB0byBzYXkgc29t ZXRoaW5nIHJlZ2FyZGluZw0KPj4NCj4+PiBhIGJvZiBwcm9wb3NhbCB0aGF0IGFkZHJlc3NlcyB0 aGUgc2NvcGUgYW5kIHByaXZhY3kvcGVydmFzaXZlIA0KPj4+IG1vbml0b3JpbmcgY29uY2VybnMg YW5kIHdoaWNoIGhhcyBhIGNyaXRpY2FsIG1hc3Mgb2YgZWZmb3J0IGJlaGluZCANCj4+PiBpdCBt aWdodCBjZXJ0YWlubHkgYmUgd29ydGh5IG9mIGNvbnNpZGVyYXRpb24gYXMgYm9mLg0KPj4NCj4+ DQo+PiBSZWdhcmRzLA0KPj4NCj4+IEJlaGNldCBPbiBXZWQsIE9jdCAyOSwgMjAxNCBhdCA0OjM2 IFBNLCBqb2VsIGphZWdnbGkgDQo+PiA8am9lbGphQGJvZ3VzLmNvbT4gd3JvdGU6DQo+Pj4gT24g MTAvMjkvMTQgOTo1MSBBTSwgQmVoY2V0IFNhcmlrYXlhIHdyb3RlOg0KPj4+PiBIaSBKb2VsLA0K Pj4+Pg0KPj4+PiBPbiBXZWQsIE9jdCAyOSwgMjAxNCBhdCA5OjU5IEFNLCBqb2VsIGphZWdnbGkg PGpvZWxqYUBib2d1cy5jb20+DQo+Pj4+IHdyb3RlOg0KPj4+Pj4gT24gMTAvMjkvMTQgNzoxMCBB TSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4+Pj4+PiBIaSBCcmlhbiwN Cj4+Pj4+Pg0KPj4+Pj4+IEkgZWNobyB5b3VyIGNvbW1lbnQuDQo+Pj4+Pj4NCj4+Pj4+PiBOb25l IG9mIHRoZSBwcm9wb3NhbHMgaW52ZW50b3JpZWQgaW4gdGhlIEhPU1RfSUQgZWZmb3J0IGlzIHRy eWluZyANCj4+Pj4+PiB0byBkbyB0aGUgc2FtZSB0aGluZyBhcyBYLVVJREggaGVhZGVyLiBNb3Jl b3Zlciwgbm9uZSBvZiB0aGVzZSANCj4+Pj4+PiBwcm9wb3NhbHMgaXMgZW5kb3JzaW5nIHRoZSBm b2xsb3dpbmcgaGVhZGVycyAoYnV0IG5vdCBsaW1pdGVkIHRvKSANCj4+Pj4+PiBub3IgYWltcyBh dCByZXZlYWxpbmcgYSBjdXN0b21lciBJRCwgYWNjb3VudCBJRCwgcHJvZmlsZSBJRCwgDQo+Pj4+ Pj4gZXRjLjoNCj4+Pj4+Pg0KPj4+Pj4+IEhUVFBfTVNJU0ROLCBIVFRQX1hfTVNJU0ROLCBIVFRQ X1hfVVBfQ0FMTElOR19MSU5FX0lELCANCj4+Pj4+PiBIVFRQX1hfTk9LSUFfTVNJU0ROLCBIVFRQ X1hfSFRTX0NMSUQsIEhUVFBfWF9NU1BfQ0xJRCwgDQo+Pj4+Pj4gSFRUUF9YX05YX0NMSUQsIEhU VFBfX1JBUE1JTiwgSFRUUF9YX1dBUF9NU0lTRE4sIEhUVFBfQ09PS0lFLCANCj4+Pj4+PiBIVFRQ X1hfVVBfTFNJRCwgSFRUUF9YX0gzR19NU0lTRE4sIEhUVFBfWF9KSU5OWV9DSUQsIA0KPj4+Pj4+ IEhUVFBfWF9ORVRXT1JLX0lORk8sIC4uLg0KPj4+Pj4+DQo+Pj4+Pj4gQ2hlZXJzLCBNZWQNCj4+ Pj4+Pg0KPj4+Pj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLSBEZSA6IGhpYXBzIA0KPj4+ Pj4+IFttYWlsdG86aGlhcHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBCcmFuZG9u IFdpbGxpYW1zIA0KPj4+Pj4+IEVudm95w6kgOiBtZXJjcmVkaSAyOSBvY3RvYnJlIDIwMTQgMTQ6 NTUgw4AgOiBqb2VsIGphZWdnbGk7IA0KPj4+Pj4+IGhpYXBzQGlldGYub3JnIE9iamV0IDogUmU6 IFtoaWFwc10gc29tZSBkaXNjdXNzaW9uIGluIHRoZSANCj4+Pj4+PiBwcmVzcy4uLg0KPj4+Pj4+ DQo+Pj4+Pj4gQWdyZWVkLiBJbnNlcnRpbmcgYSBwdWJsaWNseSB2aXNpYmxlIHVzZXIgaWRlbnRp ZmllciBpcyBhIGJhZCANCj4+Pj4+PiBpZGVhLiBUaGF0J3Mgd2h5IGFsbCB0aGUgcHJvcG9zYWxz IHRoYXQgaGF2ZSBjb21lIGZyb20gcGVvcGxlIG9uIA0KPj4+Pj4+IHRoZSBoaWFwcyBsaXN0ICh0 byB0aGUgYmVzdCBvZiBteSBrbm93bGVkZ2UpIGhhdmUgZm9jdXNlZCBvbiANCj4+Pj4+PiByZWxh eWluZyBfaG9zdF8gaWRlbnRpZmllcnMgdGhhdCBhcmUgYWxyZWFkeSBwdWJsaWNseSB2aXNpYmxl IA0KPj4+Pj4+IChnZW5lcmFsbHkgdGhlIHB1YmxpYyBJUCBhZGRyZXNzKSB0aHJvdWdoIHRvIHRo ZSBvdGhlciBzaWRlIG9mIA0KPj4+Pj4+IG1pZGRsZWJveGVzIHRoYXQgYXJlIGhpZGluZyBzdWNo IHB1YmxpY2x5IHZpc2libGUgaWRlbnRpZmllcnMuIElmIA0KPj4+Pj4+IHRoZXJlIGFyZSBwcm9w b3NhbHMgb3V0IHRoZXJlIHRoYXQgdmlvbGF0ZSB0aGlzIHByaW5jaXBsZSwgSSANCj4+Pj4+PiBh Z3JlZSBlbnRpcmVseSB0aGF0IHRoZXkgc2hvdWxkIGJlIGFiYW5kb25lZC4NCj4+Pj4+DQo+Pj4+ PiBpbWhvIG9uZSBvZiB0aGUgYXNzdW1wdGlvbnMgSSBzZWUgaW4gdGhlIHdvcmsgaXMgdGhhdCB0 aGUgaG9zdCANCj4+Pj4+IGlkZW50aWZpZXIgYmVpbmcgcmVsYXllZCB3YXMgcHJldmlvc3VseSBu b3QgcHVibGljbHkgdmlzaWJsZSwgDQo+Pj4+PiBoZW5jZSB0aGUgbmVlZCBmb3IgaG9zdGlkIGlu amVjdGlvbi4gIFRoYXQgYXBwbGllcyB0byBuYXQgDQo+Pj4+PiB0cmFuc2xhdGlvbiBmb3IgZXhh bXBsZSBpdCBhbHNvICBhcHBsaWVzIHRvIGRpZmZlcmVudGF0aW5nIGJldHdlZW4gDQo+Pj4+PiBw cmVmaXggc2hhcmluZyBVRSdzIGluIElQVjYgYnkgc29tZXRoaW5nIG90aGVyIHRoYW4gc291cmNl IA0KPj4+Pj4gYWRkcmVzcy4NCj4+Pj4+DQo+Pj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1ib3VjYWRhaXItaW50YXJlYS1ob3N0LWlkZW50aWZpZXINCj4+Pj4+IC1zY2VuYXJp b3MtMDcNCj4+Pj4+DQo+Pj4+Pg0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MjY5 DQo+Pj4+Pg0KPj4+Pj4gdGhhdCdzIHBhcnQgb2YgdGhlIHJlYXNvbiBmb3IgaGlhcHMgYm9mIHBy b3Bvc2FsIHRvIGNvbnNpZGVyIHRoZSANCj4+Pj4+IHByb2JsZW0gb2Ygc2VjdXJpbmcgc3VjaCBh biBpZGVudGlmaWVyIGZyb20gZGlmZmVyZW50aWF0aW9uIGJ5IA0KPj4+Pj4gc3VydmVpbGxhbmNl Lg0KPj4+Pg0KPj4+PiBBYnNvbHV0ZWx5Lg0KPj4+Pg0KPj4+PiBTaG91bGQgd2UgcmV2aXZlIHRo ZSBib2YgZWZmb3J0Pw0KPj4+DQo+Pj4geW91IGRpZG4ndCBoZWFyIG1lIHNheSB0aGF0LiBJIHRo aW5rIHlvdSBrbm93IHdoZXJlIHdlIGxlZnQgaXQuDQo+Pj4NCj4+PiBGcm9tIG15IHZhbnRhZ2Ug cG9pbnQgYSBib2YgcHJvcG9zYWwgdGhhdCBhZGRyZXNzZXMgdGhlIHNjb3BlIGFuZCANCj4+PiBw cml2YWN5L3BlcnZhc2l2ZSBtb25pdG9yaW5nIGNvbmNlcm5zIGFuZCB3aGljaCBoYXMgYSBjcml0 aWNhbCBtYXNzIA0KPj4+IG9mIGVmZm9ydCBiZWhpbmQgaXQgbWlnaHQgY2VydGFpbmx5IGJlIHdv cnRoeSBvZiBjb25zaWRlcmF0aW9uIGFzIA0KPj4+IGJvZi4NCj4+Pg0KPj4+PiBJIHRoaW5rIHRo YXQgZG9pbmcgdGhlIHN0YW5kYXJkaXphdGlvbiByZWxhdGVkIHRvIGhvc3RlZCBpbiBoaWFwcyAN Cj4+Pj4gcmF0aGVyIHRoYW4gaW50YXJlYSBpcyB0aGUgcmlnaHQgd2F5IHRvIGdvIGZvciBJRVRG Lg0KPj4+DQo+Pj4gV2UgY3JlYXRlZCB0aGlzIG1haWxpbmcgbGlzdCB0byBoYXZlIGEgcGxhY2Ug dG8gZGlzY3VzcyBob3N0IA0KPj4+IGlkZW50aWZpY2F0aW9uLCB3ZSBjYW4gdXNlIGl0IGZvciB0 aGF0IG9yIHdlIGNhbiBnZXQgcmlkIG9mIGl0Lg0KPj4+DQo+Pj4+IEJlaGNldA0KPj4+Pj4NCj4+ Pj4+PiAtLUJyYW5kb24NCj4+Pj4+Pg0KPj4+Pj4+IE9uIDEwLzI5LzIwMTQgMTI6MDYgQU0sIGpv ZWwgamFlZ2dsaSB3cm90ZToNCj4+Pj4+Pj4gdGhpcyBpcyBwcmV0dHkgbXVjaCBleGFjdGx5IHdo YXQgSSB3b3VsZCBoYXZlIGV4cGVjdGVkIGZyb20gDQo+Pj4+Pj4+IGluamVjdGlvbiBvbiB0aGUg d2lyZSBvZiBhbiBpZGVudGl0eSB0b2tlbi4uLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBodHRwOi8vd2Vi cG9saWN5Lm9yZy8yMDE0LzEwLzI0L2hvdy12ZXJpem9ucy1hZHZlcnRpc2luZy1oZWFkZXItDQo+ Pj4+Pj4+IHdvcmtzLw0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPiBodHRwOi8vd3d3Lndp cmVkLmNvbS8yMDE0LzEwL3Zlcml6b25zLXBlcm1hLWNvb2tpZS8NCj4+Pj4+Pj4NCj4+Pj4+Pj4g aHR0cDovL3d3dy5mb3JiZXMuY29tL3NpdGVzL2thc2htaXJoaWxsLzIwMTQvMTAvMjgvYXR0LXNh eXMtaXRzLQ0KPj4+Pj4+PiB0ZXN0aW5nLXVua2lsbGFibGUtdHJhY2tlci1vbi1jdXN0b21lcnMt c21hcnRwaG9uZXMvDQo+Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+ DQo+Pj4+Pj4+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+PiBoaWFwcyBtYWlsaW5nIGxpc3QgaGlhcHNAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaGlhcHMNCj4+Pj4+DQo+Pj4+DQo+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIGhpYXBzIG1h aWxpbmcgbGlzdCANCj4+Pj4gaGlhcHNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9oaWFwcw0KPj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gaGlhcHMgbWFpbGluZyBs aXN0IA0KPj4+IGhpYXBzQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaGlhcHMNCj4NCj4NCj4NCj4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCmhpYXBzIG1haWxpbmcgbGlzdA0KaGlhcHNAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaGlhcHMNCg== From nobody Tue Nov 4 07:48:58 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 E15BF1A8A8C for ; Tue, 4 Nov 2014 07:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJ1NHI37r-zZ for ; Tue, 4 Nov 2014 07:48:56 -0800 (PST) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D71E1A8A85 for ; Tue, 4 Nov 2014 07:48:56 -0800 (PST) Received: by mail-yh0-f54.google.com with SMTP id 29so7957999yhl.41 for ; Tue, 04 Nov 2014 07:48:55 -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=c32qH0RpnDjtsTKXhtSnu92XuCG5lnZ2haNoaLimFec=; b=AnxWFaRlAmhGUFQXiCIJ6dzyzPGwAGJcdnm5oBhqiUsZ8cgqRHzssT5dUyDIcl661W hUfeX8jqu1GnUDLhJt3Q8we0wGan5l6YZ5W7vScEH4yJ+26vy0x2DRYz61uTS6QE2F4t cIj8TpNQ2HnWPWug3l4HU6bQsCdNT/n9OPRrSrOZgyjIH0sNz0RRgR5ZTzCkwcsE9ZB9 S7P0ifxkmlZj9cbzeyp+5GpKSLZ2jgHhY3YhPZQZYa2DU7Wn7gShvpKgUpotldRUY6kQ s7SmGVVPjDgP8a+lTfiymjELmc/FZnuBxCbfGDIPI1BVdPyY24PwI7HU1jI1CT7rgBeq tJ9A== MIME-Version: 1.0 X-Received: by 10.170.151.137 with SMTP id s131mr40075276ykc.91.1415116134956; Tue, 04 Nov 2014 07:48:54 -0800 (PST) Received: by 10.170.71.198 with HTTP; Tue, 4 Nov 2014 07:48:54 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Nov 2014 09:48:54 -0600 Message-ID: From: Behcet Sarikaya To: "hiaps@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/Q4WisOR_ViEfPAaH-YgLiV7nMG0 Cc: Mohamed Boucadair , Brandon Williams , "Dirk.von-Hugo@telekom.de" Subject: Re: [hiaps] work to do 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: Tue, 04 Nov 2014 15:48:57 -0000 Hi all, If I understood Dirk's mail, it seems like he is saying that we should first work on a security analysis of host identifiers. So I suggest having Threat analysis as the first step. Is there a draft that covers similar issues? Maybe we can start with that. Otherwise we discuss with the intent of outputting a draft. Regards, Behcet On Thu, Oct 30, 2014 at 2:35 PM, Behcet Sarikaya wrote: > Hi all, > > I tried to dress up things to do in hostid below as follows: > > - requirements > > - updated solution analysis > > - solution(s) given the fact that we have diverse set of use cases, > one size fits all type of a single solution may not be the way to go. > > Regards, > > Behcet From nobody Thu Nov 6 01:51: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 ED58B1A1AB6 for ; Thu, 6 Nov 2014 01:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.444 X-Spam-Level: X-Spam-Status: No, score=-4.444 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 b-AchgH6ewdA for ; Thu, 6 Nov 2014 01:51:45 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 640BC1A1AB5 for ; Thu, 6 Nov 2014 01:51:45 -0800 (PST) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail41.telekom.de with ESMTP; 06 Nov 2014 10:51:43 +0100 X-IronPort-AV: E=Sophos;i="5.07,324,1413237600"; d="scan'208";a="560010462" Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 06 Nov 2014 10:51:42 +0100 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113656.emea1.cds.t-internal.com ([10.134.99.16]) with mapi; Thu, 6 Nov 2014 10:51:42 +0100 From: To: , Date: Thu, 6 Nov 2014 10:51:40 +0100 Thread-Topic: work to do Thread-Index: Ac/4RtwqPoVDNAF4R1SGjFLXtvu/8wBWht6g Message-ID: <05C81A773E48DD49B181B04BA21A342A2E5EA93C73@HE113484.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/RLYhaEWWvERPRVatQzi_4Qpd6wU Cc: mohamed.boucadair@orange.com, brandon.williams@akamai.com Subject: Re: [hiaps] work to do 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 Nov 2014 09:51:48 -0000 SGkgQmVoY2V0LA0KTm90IGV4YWN0bHkgLSBJIGp1c3Qgd2FudGVkIHRvIHNheSB0aGF0IHRoZSBw cml2YWN5IGlzc3VlcyBhcmUgYXMgaW1wb3J0YW50IGFzIHRoZSBvdGhlciB0b3BpY3MgbGlrZSBz Y29wZSBhbmQgcHJvYmxlbSBzdGF0ZW1lbnQuDQpCdXQgSSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBs b29rIGF0IGV4aXN0aW5nIGRyYWZ0cyAuLi4gDQpBIHF1aWNrIGxvb2sgYXQgdmVyeSByZWNlbnQg SS1EcyBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zdGlyLXJmYzQ0NzRi aXMtMDIgcmVsYXRlZCB0byBTSVAgYW5kIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1iYWtlci1vcGVuc3RhY2stcmJhYy1mZWRlcmF0ZWQtaWRlbnRpdHktMDAgbWlnaHQgaGVscCwg YnV0IG1vcmUgZGV0YWlsZWQgaW52ZXN0aWdhdGlvbnMgd291bGQgYmUgdXNlZnVsIC4uLiANClZv bHVudGVlcnMgd2VsY29tZSA7LSkNCg0KQmVzdCByZWdhcmRzDQpEaXJrDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogQmVoY2V0IFNhcmlrYXlhIFttYWlsdG86c2FyaWtheWEyMDEy QGdtYWlsLmNvbV0gDQpTZW50OiBEaWVuc3RhZywgNC4gTm92ZW1iZXIgMjAxNCAxNjo0OQ0KVG86 IGhpYXBzQGlldGYub3JnDQpDYzogTW9oYW1lZCBCb3VjYWRhaXI7IEJyYW5kb24gV2lsbGlhbXM7 IHZvbiBIdWdvLCBEaXJrDQpTdWJqZWN0OiBSZTogd29yayB0byBkbw0KDQpIaSBhbGwsDQoNCklm IEkgdW5kZXJzdG9vZCBEaXJrJ3MgbWFpbCwgaXQgc2VlbXMgbGlrZSBoZSBpcyBzYXlpbmcgdGhh dCB3ZSBzaG91bGQgZmlyc3Qgd29yayBvbiBhIHNlY3VyaXR5IGFuYWx5c2lzIG9mIGhvc3QgaWRl bnRpZmllcnMuDQoNClNvIEkgc3VnZ2VzdCBoYXZpbmcNCg0KDQpUaHJlYXQgYW5hbHlzaXMNCmFz IHRoZSBmaXJzdCBzdGVwLg0KDQpJcyB0aGVyZSBhIGRyYWZ0IHRoYXQgY292ZXJzIHNpbWlsYXIg aXNzdWVzPyBNYXliZSB3ZSBjYW4gc3RhcnQgd2l0aCB0aGF0LiBPdGhlcndpc2Ugd2UgZGlzY3Vz cyB3aXRoIHRoZSBpbnRlbnQgb2Ygb3V0cHV0dGluZyBhIGRyYWZ0Lg0KDQpSZWdhcmRzLA0KDQpC ZWhjZXQNCg0KT24gVGh1LCBPY3QgMzAsIDIwMTQgYXQgMjozNSBQTSwgQmVoY2V0IFNhcmlrYXlh IDxzYXJpa2F5YTIwMTJAZ21haWwuY29tPiB3cm90ZToNCj4gIEhpIGFsbCwNCj4NCj4gSSB0cmll ZCB0byBkcmVzcyB1cCB0aGluZ3MgdG8gZG8gaW4gaG9zdGlkIGJlbG93IGFzIGZvbGxvd3M6DQo+ DQo+IC0gcmVxdWlyZW1lbnRzDQo+DQo+IC0gdXBkYXRlZCBzb2x1dGlvbiBhbmFseXNpcw0KPg0K PiAtIHNvbHV0aW9uKHMpIGdpdmVuIHRoZSBmYWN0IHRoYXQgd2UgaGF2ZSBkaXZlcnNlIHNldCBv ZiB1c2UgY2FzZXMsIA0KPiBvbmUgc2l6ZSBmaXRzIGFsbCB0eXBlIG9mIGEgc2luZ2xlIHNvbHV0 aW9uIG1heSBub3QgYmUgdGhlIHdheSB0byBnby4NCj4NCj4gUmVnYXJkcywNCj4NCj4gQmVoY2V0 DQo= From nobody Thu Nov 6 07:30:13 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 70DB41A890F for ; Thu, 6 Nov 2014 07:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhE7tEufqWDS for ; Thu, 6 Nov 2014 07:30:11 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E1531A8901 for ; Thu, 6 Nov 2014 07:30:11 -0800 (PST) Received: by mail-yk0-f169.google.com with SMTP id 131so1400319ykp.14 for ; Thu, 06 Nov 2014 07:30:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=HvwFyh+useiaj2kzq1WkmsHjMdkE8NEK8WnNDzb7Vp8=; b=Ffbhgx+Opp7KJ2GmKp18w4rrqCS0cdBdjKWwhtLtHAB0I26ZIxhBTWpmrzmuhIIr5c ZbS+kLGwNh55k2XQeqiU9SZRiznZctHPA1qbP92OBbKKZjFAIx3pWkXJOMWjx/ZA+1Ok VQnQHguAmJn+lZChUY4RxBRi1WXLN6/8peHPuAU/N3dWRTA5OIVUsHjN3TcApvIjEu/F OZDG9VNF4Za0RRANww3zvhJnGw4xXo0tLeAKosy1OtKIbteO1qTevMbkASi4EvThnQWn nxJ7b0xCchjv36WqEQiZboHZnrq8EqRd0LQ7NG+nZO4h6B6YMfXX7UjCSR7YrIYzNr7L qWZQ== MIME-Version: 1.0 X-Received: by 10.170.58.2 with SMTP id a2mr5347730yka.78.1415287810747; Thu, 06 Nov 2014 07:30:10 -0800 (PST) Received: by 10.170.71.198 with HTTP; Thu, 6 Nov 2014 07:30:10 -0800 (PST) Date: Thu, 6 Nov 2014 09:30:10 -0600 Message-ID: From: Behcet Sarikaya To: "hiaps@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/0kQcwlxB7FxGSG1Mpm9H8ePAxJ0 Subject: [hiaps] Side Meeting at IETF 91 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: Thu, 06 Nov 2014 15:30:12 -0000 Hi Folks, We plan on having a side meeting to discuss recent developments in Honolulu. Time and place will be announced once we get there. If you are attending IETF 91, please plan on being there! Regards, Behcet From nobody Fri Nov 7 07:41: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 18DC01A86E6 for ; Fri, 7 Nov 2014 07:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0aWWTShbmWN for ; Fri, 7 Nov 2014 07:41:06 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F0201A1BA4 for ; Fri, 7 Nov 2014 07:41:06 -0800 (PST) Received: by mail-yk0-f173.google.com with SMTP id 20so2374933yks.4 for ; Fri, 07 Nov 2014 07:41:05 -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=EUbPwnCMieBtHZcJa7mH0xamXJloUyIX4skPOBJMKN8=; b=HRTaTnLKf/yBhiokDHqln87Mpoegc1b2iMSi70oKaKn3zcOzqKIfKmosAgctAGnms2 SoFx3VjNtEjZPFQ4BAKLGsqVR6u7I7AIsr9V/eC7DIVIGEhbWm0TjdlxQK/KehpYJwiI roRv947vcT102d0ufTN5DF+aeCO7PbN3PZDPfVif22MtaLRe5nOFoIUTVa4KA/rXwyyE 6e5ipm5+RcSOM1A04fVTBaeXumoJOvm90zEri2c0xtnd4jI8QRrxDflnghOmqJVfNU2n CdLZ63FZg/7QtWe18R1hiecw9MAlE/CAyHdd3d+E+OcQ7MUP3p6hfMh+ETRjj2CSccFZ eeaQ== MIME-Version: 1.0 X-Received: by 10.170.205.4 with SMTP id w4mr13177758yke.62.1415374865750; Fri, 07 Nov 2014 07:41:05 -0800 (PST) Received: by 10.170.71.198 with HTTP; Fri, 7 Nov 2014 07:41:05 -0800 (PST) In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2E5EA93C73@HE113484.emea1.cds.t-internal.com> References: <05C81A773E48DD49B181B04BA21A342A2E5EA93C73@HE113484.emea1.cds.t-internal.com> Date: Fri, 7 Nov 2014 09:41:05 -0600 Message-ID: From: Behcet Sarikaya To: "Dirk.von-Hugo@telekom.de" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/aRUjbbO_IDq0jaoP_zeeb-iyccE Cc: "hiaps@ietf.org" , Mohamed Boucadair , Brandon Williams Subject: Re: [hiaps] work to do 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 Nov 2014 15:41:08 -0000 Hi Dirk, all, Reading your mail I came to understand a common misunderstanding on our activity. In fact what we are trying to do is already done in IPv6: every packet in IPv6 carries a public source address. Even in IPv4 in some cases it is done. I think privacy and security issues over which there is so much noise are related to the long lived host identifiers like MSISDN which is your phone number, as Med said. I don't remember anyone complaining on privacy / security issues on the very basic way IPv6 works. This leads me to say that Med initially made an innocent mistake in selecting host id which can easily be mistaken for other host identifiers. Unfortunately this mistake has been hitting us like a boomerang. My view of the way out is to change the name. I think we should call host addresses and NOT host ids. So maybe we should NOT use hiaps but use haaps or host address and prefix sharing issues. This is a small change and we can easily carry this over on our work, drafts, etc. What do you think? Regards, Behcet On Thu, Nov 6, 2014 at 3:51 AM, wrote: > Hi Behcet, > Not exactly - I just wanted to say that the privacy issues are as important as the other topics like scope and problem statement. > But I agree that we should look at existing drafts ... > A quick look at very recent I-Ds https://tools.ietf.org/html/draft-ietf-stir-rfc4474bis-02 related to SIP and https://tools.ietf.org/html/draft-baker-openstack-rbac-federated-identity-00 might help, but more detailed investigations would be useful ... > Volunteers welcome ;-) > > Best regards > Dirk > -----Original Message----- > From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > Sent: Dienstag, 4. November 2014 16:49 > To: hiaps@ietf.org > Cc: Mohamed Boucadair; Brandon Williams; von Hugo, Dirk > Subject: Re: work to do > > Hi all, > > If I understood Dirk's mail, it seems like he is saying that we should first work on a security analysis of host identifiers. > > So I suggest having > > > Threat analysis > as the first step. > > Is there a draft that covers similar issues? Maybe we can start with that. Otherwise we discuss with the intent of outputting a draft. > > Regards, > > Behcet > > On Thu, Oct 30, 2014 at 2:35 PM, Behcet Sarikaya wrote: >> Hi all, >> >> I tried to dress up things to do in hostid below as follows: >> >> - requirements >> >> - updated solution analysis >> >> - solution(s) given the fact that we have diverse set of use cases, >> one size fits all type of a single solution may not be the way to go. >> >> Regards, >> >> Behcet > _______________________________________________ > hiaps mailing list > hiaps@ietf.org > https://www.ietf.org/mailman/listinfo/hiaps From nobody Fri Nov 7 09:10:09 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 3222D1AD392 for ; Fri, 7 Nov 2014 09:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 YYOKxWSpjEzE for ; Fri, 7 Nov 2014 09:10:01 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A56741AD3A4 for ; Fri, 7 Nov 2014 09:10:01 -0800 (PST) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id sA7H9ust062293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 7 Nov 2014 17:09:57 GMT (envelope-from joelja@bogus.com) Message-ID: <545CFCCE.8010902@bogus.com> Date: Fri, 07 Nov 2014 09:09:34 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: sarikaya@ieee.org, "Dirk.von-Hugo@telekom.de" References: <05C81A773E48DD49B181B04BA21A342A2E5EA93C73@HE113484.emea1.cds.t-internal.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9O7807CsuhtD2al7NgFCELUWmxrjbGv0M" Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/FXer2w82QX1pnGiqTvBXs0Xs17I Cc: "hiaps@ietf.org" , Mohamed Boucadair , Brandon Williams Subject: Re: [hiaps] work to do 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 Nov 2014 17:10:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9O7807CsuhtD2al7NgFCELUWmxrjbGv0M Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/7/14 7:41 AM, Behcet Sarikaya wrote: > Hi Dirk, all, >=20 > Reading your mail I came to understand a common misunderstanding on > our activity. >=20 > In fact what we are trying to do is already done in IPv6: every packet > in IPv6 carries a public source address. Even in IPv4 in some cases it > is done. >=20 > I think privacy and security issues over which there is so much noise > are related to the long lived host identifiers like MSISDN which is > your phone number, as Med said. I don't remember anyone complaining on > privacy / security issues on the very basic way IPv6 works. Well. There's a reason why hosts are generating privacy addresses. Back when they all encoded their mac addresses in the host field as modified eui64 and allowed that to be stable across subnets, a locally significant but unique identifier was leaking into the internet. That was addressed and to wit if you have a host identity problem with the v6 addressing architecture that exists today it's because you cannot distinguish between hosts purely on the basis of source address within a shared prefix. everytime I close the lid on the laptop or it goes to sleep I use a new source address even though for example I use the same v4 address because my lease still holds. inet6 2601:9:####:####:####:####:####:#### prefixlen 64 autoconf inet6 2601:9:####:####:159a:c4b1:4efd:21a2 prefixlen 64 autoconf tempora= ry =2E.. inet6 2601:9:####:####:a96e:3bcd:b861:ee69 prefixlen 64 autoconf tempora= ry > This leads me to say that Med initially made an innocent mistake in > selecting host id which can easily be mistaken for other host > identifiers. Unfortunately this mistake has been hitting us like a > boomerang. I'm not sure I consider 6967 to be a mistake. http://tools.ietf.org/html/rfc6967#section-3 > My view of the way out is to change the name. > I think we should call host addresses and NOT host ids. not all the proposals involve addresses they are all identifiers. > So maybe we should NOT use hiaps but use haaps or host address and > prefix sharing issues. This is a small change and we can easily carry > this over on our work, drafts, etc. >=20 > What do you think? >=20 > Regards, >=20 > Behcet >=20 >=20 > On Thu, Nov 6, 2014 at 3:51 AM, wrote: >> Hi Behcet, >> Not exactly - I just wanted to say that the privacy issues are as impo= rtant as the other topics like scope and problem statement. >> But I agree that we should look at existing drafts ... >> A quick look at very recent I-Ds https://tools.ietf.org/html/draft-iet= f-stir-rfc4474bis-02 related to SIP and https://tools.ietf.org/html/draft= -baker-openstack-rbac-federated-identity-00 might help, but more detailed= investigations would be useful ... >> Volunteers welcome ;-) >> >> Best regards >> Dirk >> -----Original Message----- >> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >> Sent: Dienstag, 4. November 2014 16:49 >> To: hiaps@ietf.org >> Cc: Mohamed Boucadair; Brandon Williams; von Hugo, Dirk >> Subject: Re: work to do >> >> Hi all, >> >> If I understood Dirk's mail, it seems like he is saying that we should= first work on a security analysis of host identifiers. >> >> So I suggest having >> >> >> Threat analysis >> as the first step. >> >> Is there a draft that covers similar issues? Maybe we can start with t= hat. Otherwise we discuss with the intent of outputting a draft. >> >> Regards, >> >> Behcet >> >> On Thu, Oct 30, 2014 at 2:35 PM, Behcet Sarikaya wrote: >>> Hi all, >>> >>> I tried to dress up things to do in hostid below as follows: >>> >>> - requirements >>> >>> - updated solution analysis >>> >>> - solution(s) given the fact that we have diverse set of use cases, >>> one size fits all type of a single solution may not be the way to go.= >>> >>> Regards, >>> >>> Behcet >> _______________________________________________ >> hiaps mailing list >> hiaps@ietf.org >> https://www.ietf.org/mailman/listinfo/hiaps >=20 > _______________________________________________ > hiaps mailing list > hiaps@ietf.org > https://www.ietf.org/mailman/listinfo/hiaps >=20 --9O7807CsuhtD2al7NgFCELUWmxrjbGv0M 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 iEYEARECAAYFAlRc/NAACgkQ8AA1q7Z/VrK1rQCeOM9Eg7NA1GZr0qYTqIge8sy0 6I4An3m6gDRqitopinpz2IhBnf7hkr8n =fYUV -----END PGP SIGNATURE----- --9O7807CsuhtD2al7NgFCELUWmxrjbGv0M-- From nobody Sun Nov 9 12:37:05 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 C7F571A86E1 for ; Sun, 9 Nov 2014 12:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 QAvo1SgGxlWJ for ; Sun, 9 Nov 2014 12:37:01 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA9861A01AA for ; Sun, 9 Nov 2014 12:37:01 -0800 (PST) Received: from dhcp-a39e.meeting.ietf.org (dhcp-a39e.meeting.ietf.org [31.133.163.158]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id sA9KatkZ076696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 9 Nov 2014 20:36:56 GMT (envelope-from joelja@bogus.com) Message-ID: <545FD066.3090007@bogus.com> Date: Sun, 09 Nov 2014 10:36:54 -1000 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: Behcet Sarikaya References: <05C81A773E48DD49B181B04BA21A342A2E5EA93C73@HE113484.emea1.cds.t-internal.com> <545CFCCE.8010902@bogus.com> <50073658-B05F-40CB-B991-DD88706CFF66@gmail.com> In-Reply-To: <50073658-B05F-40CB-B991-DD88706CFF66@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IrCaDuGsM43BNXobPE3SfF81JWCMFHKke" Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/O7nQCTcSKEMs2mHT8-dFvfRRgzM Cc: "hiaps@ietf.org" , "sarikaya@ieee.org" , Mohamed Boucadair , Brandon Williams , "Dirk.von-Hugo@telekom.de" Subject: Re: [hiaps] work to do 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: Sun, 09 Nov 2014 20:37:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IrCaDuGsM43BNXobPE3SfF81JWCMFHKke Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/9/14 10:30 AM, Behcet Sarikaya wrote: > In all cases we are dealing with addresses IPv4 or v6. > They could be public or random or privacy addresses=20 >=20 > So I think host address use is justified. a 16 bit field is not an ip address. > Regards >=20 > Behcet=20 >=20 > Sent from my iPhone >=20 >> On Nov 7, 2014, at 7:09 AM, joel jaeggli wrote: >> >>> On 11/7/14 7:41 AM, Behcet Sarikaya wrote: >>> Hi Dirk, all, >>> >>> Reading your mail I came to understand a common misunderstanding on >>> our activity. >>> >>> In fact what we are trying to do is already done in IPv6: every packe= t >>> in IPv6 carries a public source address. Even in IPv4 in some cases i= t >>> is done. >>> >>> I think privacy and security issues over which there is so much noise= >>> are related to the long lived host identifiers like MSISDN which is >>> your phone number, as Med said. I don't remember anyone complaining o= n >>> privacy / security issues on the very basic way IPv6 works. >> >> Well. There's a reason why hosts are generating privacy addresses. Ba= ck >> when they all encoded their mac addresses in the host field as modifi= ed >> eui64 and allowed that to be stable across subnets, a locally >> significant but unique identifier was leaking into the internet. That >> was addressed and to wit if you have a host identity problem with the = v6 >> addressing architecture that exists today it's because you cannot >> distinguish between hosts purely on the basis of source address within= a >> shared prefix. >> >> everytime I close the lid on the laptop or it goes to sleep I use a ne= w >> source address even though for example I use the same v4 address becau= se >> my lease still holds. >> >> inet6 2601:9:####:####:####:####:####:#### prefixlen 64 autoconf >> inet6 2601:9:####:####:159a:c4b1:4efd:21a2 prefixlen 64 autoconf te= mporary >> ... >> >> inet6 2601:9:####:####:a96e:3bcd:b861:ee69 prefixlen 64 autoconf te= mporary >> >>> This leads me to say that Med initially made an innocent mistake in >>> selecting host id which can easily be mistaken for other host >>> identifiers. Unfortunately this mistake has been hitting us like a >>> boomerang. >> >> I'm not sure I consider 6967 to be a mistake. >> >> http://tools.ietf.org/html/rfc6967#section-3 >> >>> My view of the way out is to change the name. >>> I think we should call host addresses and NOT host ids. >> >> not all the proposals involve addresses they are all identifiers. >> >>> So maybe we should NOT use hiaps but use haaps or host address and >>> prefix sharing issues. This is a small change and we can easily carry= >>> this over on our work, drafts, etc. >>> >>> What do you think? >>> >>> Regards, >>> >>> Behcet >>> >>> >>>> On Thu, Nov 6, 2014 at 3:51 AM, wrote: >>>> Hi Behcet, >>>> Not exactly - I just wanted to say that the privacy issues are as im= portant as the other topics like scope and problem statement. >>>> But I agree that we should look at existing drafts ... >>>> A quick look at very recent I-Ds https://tools.ietf.org/html/draft-i= etf-stir-rfc4474bis-02 related to SIP and https://tools.ietf.org/html/dra= ft-baker-openstack-rbac-federated-identity-00 might help, but more detail= ed investigations would be useful ... >>>> Volunteers welcome ;-) >>>> >>>> Best regards >>>> Dirk >>>> -----Original Message----- >>>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>>> Sent: Dienstag, 4. November 2014 16:49 >>>> To: hiaps@ietf.org >>>> Cc: Mohamed Boucadair; Brandon Williams; von Hugo, Dirk >>>> Subject: Re: work to do >>>> >>>> Hi all, >>>> >>>> If I understood Dirk's mail, it seems like he is saying that we shou= ld first work on a security analysis of host identifiers. >>>> >>>> So I suggest having >>>> >>>> >>>> Threat analysis >>>> as the first step. >>>> >>>> Is there a draft that covers similar issues? Maybe we can start with= that. Otherwise we discuss with the intent of outputting a draft. >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>>>> On Thu, Oct 30, 2014 at 2:35 PM, Behcet Sarikaya wrote: >>>>> Hi all, >>>>> >>>>> I tried to dress up things to do in hostid below as follows: >>>>> >>>>> - requirements >>>>> >>>>> - updated solution analysis >>>>> >>>>> - solution(s) given the fact that we have diverse set of use cases,= >>>>> one size fits all type of a single solution may not be the way to g= o. >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>> _______________________________________________ >>>> hiaps mailing list >>>> hiaps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/hiaps >>> >>> _______________________________________________ >>> hiaps mailing list >>> hiaps@ietf.org >>> https://www.ietf.org/mailman/listinfo/hiaps >> >> >=20 --IrCaDuGsM43BNXobPE3SfF81JWCMFHKke 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 iEYEARECAAYFAlRf0GYACgkQ8AA1q7Z/VrJB2wCfayuZlkxVzTbEjBlUCMhL1xVL oWAAn1jxJNt9RDuWnkBO90bd84ZUth54 =Wo4R -----END PGP SIGNATURE----- --IrCaDuGsM43BNXobPE3SfF81JWCMFHKke-- From nobody Sun Nov 9 23:21:02 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 88D821A6F58 for ; Sun, 9 Nov 2014 12:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fewDtW0AB4bd for ; Sun, 9 Nov 2014 12:32:54 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6CD11A8035 for ; Sun, 9 Nov 2014 12:32:53 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id a1so7366491wgh.20 for ; Sun, 09 Nov 2014 12:32:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1YYyFTgFz/KLqHNHMMDY3107Vc/ggwBKGo/UYwIyh1U=; b=qhG7YPxin0jP7czGS8njK9fEI3eX1zxkYnwjXdz1ZqgVRgwh9x08PJKE3Zw/U/og9B GPKaJ42D9GSOOPViYeXH3Z0UfpxoeNrhz+Hk1Zrw2Mhnl8nN+JwIc1fTT5Vdi/TYl8Nw NxxQzxSU3NZDCC6zNU6yamEpZMmp4joBkOhm5bVkIEFpW7g26PGHOct/MNpPMjBIIMb6 Rf0v3kPLmWsiJcOgnf1C9d7KXMJMwPxRA16HWLDy2fK6qdzeldz62JwBGzBdoZzywkjf W37mS4nrDtdDKNehn+82pvx6H+QT1cf6/eTrJvgIqMLX4wHW0HaQebPMEfYC+HmQRMgM Mc2Q== X-Received: by 10.194.203.201 with SMTP id ks9mr35856729wjc.105.1415565172460; Sun, 09 Nov 2014 12:32:52 -0800 (PST) Received: from ?IPv6:2001:67c:370:136:281c:ee2a:ffe9:9736? ([2001:67c:370:136:281c:ee2a:ffe9:9736]) by mx.google.com with ESMTPSA id fi10sm10403481wic.12.2014.11.09.12.32.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Nov 2014 12:32:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Behcet Sarikaya X-Mailer: iPhone Mail (12B411) In-Reply-To: <545CFCCE.8010902@bogus.com> Date: Sun, 9 Nov 2014 10:30:01 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <50073658-B05F-40CB-B991-DD88706CFF66@gmail.com> References: <05C81A773E48DD49B181B04BA21A342A2E5EA93C73@HE113484.emea1.cds.t-internal.com> <545CFCCE.8010902@bogus.com> To: joel jaeggli Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/L_PMbhObPJszEQlsCd9_e6fp2dg X-Mailman-Approved-At: Sun, 09 Nov 2014 23:20:53 -0800 Cc: "hiaps@ietf.org" , "sarikaya@ieee.org" , Mohamed Boucadair , Brandon Williams , "Dirk.von-Hugo@telekom.de" Subject: Re: [hiaps] work to do 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: Sun, 09 Nov 2014 20:32:55 -0000 In all cases we are dealing with addresses IPv4 or v6. They could be public or random or privacy addresses=20 So I think host address use is justified. Regards Behcet=20 Sent from my iPhone > On Nov 7, 2014, at 7:09 AM, joel jaeggli wrote: >=20 >> On 11/7/14 7:41 AM, Behcet Sarikaya wrote: >> Hi Dirk, all, >>=20 >> Reading your mail I came to understand a common misunderstanding on >> our activity. >>=20 >> In fact what we are trying to do is already done in IPv6: every packet >> in IPv6 carries a public source address. Even in IPv4 in some cases it >> is done. >>=20 >> I think privacy and security issues over which there is so much noise >> are related to the long lived host identifiers like MSISDN which is >> your phone number, as Med said. I don't remember anyone complaining on >> privacy / security issues on the very basic way IPv6 works. >=20 > Well. There's a reason why hosts are generating privacy addresses. Back > when they all encoded their mac addresses in the host field as modified > eui64 and allowed that to be stable across subnets, a locally > significant but unique identifier was leaking into the internet. That > was addressed and to wit if you have a host identity problem with the v6 > addressing architecture that exists today it's because you cannot > distinguish between hosts purely on the basis of source address within a > shared prefix. >=20 > everytime I close the lid on the laptop or it goes to sleep I use a new > source address even though for example I use the same v4 address because > my lease still holds. >=20 > inet6 2601:9:####:####:####:####:####:#### prefixlen 64 autoconf > inet6 2601:9:####:####:159a:c4b1:4efd:21a2 prefixlen 64 autoconf tempor= ary > ... >=20 > inet6 2601:9:####:####:a96e:3bcd:b861:ee69 prefixlen 64 autoconf tempor= ary >=20 >> This leads me to say that Med initially made an innocent mistake in >> selecting host id which can easily be mistaken for other host >> identifiers. Unfortunately this mistake has been hitting us like a >> boomerang. >=20 > I'm not sure I consider 6967 to be a mistake. >=20 > http://tools.ietf.org/html/rfc6967#section-3 >=20 >> My view of the way out is to change the name. >> I think we should call host addresses and NOT host ids. >=20 > not all the proposals involve addresses they are all identifiers. >=20 >> So maybe we should NOT use hiaps but use haaps or host address and >> prefix sharing issues. This is a small change and we can easily carry >> this over on our work, drafts, etc. >>=20 >> What do you think? >>=20 >> Regards, >>=20 >> Behcet >>=20 >>=20 >>> On Thu, Nov 6, 2014 at 3:51 AM, wrote: >>> Hi Behcet, >>> Not exactly - I just wanted to say that the privacy issues are as import= ant as the other topics like scope and problem statement. >>> But I agree that we should look at existing drafts ... >>> A quick look at very recent I-Ds https://tools.ietf.org/html/draft-ietf-= stir-rfc4474bis-02 related to SIP and https://tools.ietf.org/html/draft-bake= r-openstack-rbac-federated-identity-00 might help, but more detailed investi= gations would be useful ... >>> Volunteers welcome ;-) >>>=20 >>> Best regards >>> Dirk >>> -----Original Message----- >>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>> Sent: Dienstag, 4. November 2014 16:49 >>> To: hiaps@ietf.org >>> Cc: Mohamed Boucadair; Brandon Williams; von Hugo, Dirk >>> Subject: Re: work to do >>>=20 >>> Hi all, >>>=20 >>> If I understood Dirk's mail, it seems like he is saying that we should f= irst work on a security analysis of host identifiers. >>>=20 >>> So I suggest having >>>=20 >>>=20 >>> Threat analysis >>> as the first step. >>>=20 >>> Is there a draft that covers similar issues? Maybe we can start with tha= t. Otherwise we discuss with the intent of outputting a draft. >>>=20 >>> Regards, >>>=20 >>> Behcet >>>=20 >>>> On Thu, Oct 30, 2014 at 2:35 PM, Behcet Sarikaya wrote: >>>> Hi all, >>>>=20 >>>> I tried to dress up things to do in hostid below as follows: >>>>=20 >>>> - requirements >>>>=20 >>>> - updated solution analysis >>>>=20 >>>> - solution(s) given the fact that we have diverse set of use cases, >>>> one size fits all type of a single solution may not be the way to go. >>>>=20 >>>> Regards, >>>>=20 >>>> Behcet >>> _______________________________________________ >>> hiaps mailing list >>> hiaps@ietf.org >>> https://www.ietf.org/mailman/listinfo/hiaps >>=20 >> _______________________________________________ >> hiaps mailing list >> hiaps@ietf.org >> https://www.ietf.org/mailman/listinfo/hiaps >=20 >=20 From nobody Sun Nov 9 23:21:08 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 47DA41A8029 for ; Sun, 9 Nov 2014 12:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQf10pCgkwQx for ; Sun, 9 Nov 2014 12:38:32 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 710071A01AA for ; Sun, 9 Nov 2014 12:38:32 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id lf10so6834503pab.4 for ; Sun, 09 Nov 2014 12:38:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:content-transfer-encoding:from:mime-version:subject :date:message-id:references:cc:in-reply-to:to; bh=1YYyFTgFz/KLqHNHMMDY3107Vc/ggwBKGo/UYwIyh1U=; b=LDvpxQwfwMESj/0v3XN6XtWh3QW4yqJDHpk4CibGKJgOwpQWP6fw4hveWqtqRjeLuV iBY03MA550zIDovFldAm8WSoBL3AbzFN+Sha0/B1o777AzyQXBlVEw4Kiaztdyy59vL2 JHOK9cSwkZQ8vaj3sBE9ZhR46HtIO5oAf5I6O9S70SJy830JWWKUGPtS52trMK30vWu1 ADJvx9A6fXkLN5Y9gW/7HeIuQ2wta43uKQc+MYAuIqvnO11EJoXe/es1WUB1qcQvQPsF TigXA97+cNBg4Cp7pko22KXxDmef7BJY7E1Rp/CUH/gc6udrZcDuPs6aXS3Cwrr8Mdvv 9oqw== X-Received: by 10.70.43.229 with SMTP id z5mr27179787pdl.25.1415565511779; Sun, 09 Nov 2014 12:38:31 -0800 (PST) Received: from [10.76.217.168] ([166.170.49.115]) by mx.google.com with ESMTPSA id ft2sm14565457pbb.15.2014.11.09.12.38.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Nov 2014 12:38:31 -0800 (PST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Behcet Sarikaya Mime-Version: 1.0 (1.0) Date: Sun, 9 Nov 2014 10:30:01 -1000 Message-Id: <50073658-B05F-40CB-B991-DD88706CFF66@gmail.com> References: <05C81A773E48DD49B181B04BA21A342A2E5EA93C73@HE113484.emea1.cds.t-internal.com> <545CFCCE.8010902@bogus.com> In-Reply-To: <545CFCCE.8010902@bogus.com> To: joel jaeggli X-Mailer: iPhone Mail (12B411) Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/L_PMbhObPJszEQlsCd9_e6fp2dg X-Mailman-Approved-At: Sun, 09 Nov 2014 23:20:53 -0800 Cc: "hiaps@ietf.org" , "sarikaya@ieee.org" , Mohamed Boucadair , Brandon Williams , "Dirk.von-Hugo@telekom.de" Subject: Re: [hiaps] work to do 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: Sun, 09 Nov 2014 20:38:34 -0000 In all cases we are dealing with addresses IPv4 or v6. They could be public or random or privacy addresses=20 So I think host address use is justified. Regards Behcet=20 Sent from my iPhone > On Nov 7, 2014, at 7:09 AM, joel jaeggli wrote: >=20 >> On 11/7/14 7:41 AM, Behcet Sarikaya wrote: >> Hi Dirk, all, >>=20 >> Reading your mail I came to understand a common misunderstanding on >> our activity. >>=20 >> In fact what we are trying to do is already done in IPv6: every packet >> in IPv6 carries a public source address. Even in IPv4 in some cases it >> is done. >>=20 >> I think privacy and security issues over which there is so much noise >> are related to the long lived host identifiers like MSISDN which is >> your phone number, as Med said. I don't remember anyone complaining on >> privacy / security issues on the very basic way IPv6 works. >=20 > Well. There's a reason why hosts are generating privacy addresses. Back > when they all encoded their mac addresses in the host field as modified > eui64 and allowed that to be stable across subnets, a locally > significant but unique identifier was leaking into the internet. That > was addressed and to wit if you have a host identity problem with the v6 > addressing architecture that exists today it's because you cannot > distinguish between hosts purely on the basis of source address within a > shared prefix. >=20 > everytime I close the lid on the laptop or it goes to sleep I use a new > source address even though for example I use the same v4 address because > my lease still holds. >=20 > inet6 2601:9:####:####:####:####:####:#### prefixlen 64 autoconf > inet6 2601:9:####:####:159a:c4b1:4efd:21a2 prefixlen 64 autoconf tempor= ary > ... >=20 > inet6 2601:9:####:####:a96e:3bcd:b861:ee69 prefixlen 64 autoconf tempor= ary >=20 >> This leads me to say that Med initially made an innocent mistake in >> selecting host id which can easily be mistaken for other host >> identifiers. Unfortunately this mistake has been hitting us like a >> boomerang. >=20 > I'm not sure I consider 6967 to be a mistake. >=20 > http://tools.ietf.org/html/rfc6967#section-3 >=20 >> My view of the way out is to change the name. >> I think we should call host addresses and NOT host ids. >=20 > not all the proposals involve addresses they are all identifiers. >=20 >> So maybe we should NOT use hiaps but use haaps or host address and >> prefix sharing issues. This is a small change and we can easily carry >> this over on our work, drafts, etc. >>=20 >> What do you think? >>=20 >> Regards, >>=20 >> Behcet >>=20 >>=20 >>> On Thu, Nov 6, 2014 at 3:51 AM, wrote: >>> Hi Behcet, >>> Not exactly - I just wanted to say that the privacy issues are as import= ant as the other topics like scope and problem statement. >>> But I agree that we should look at existing drafts ... >>> A quick look at very recent I-Ds https://tools.ietf.org/html/draft-ietf-= stir-rfc4474bis-02 related to SIP and https://tools.ietf.org/html/draft-bake= r-openstack-rbac-federated-identity-00 might help, but more detailed investi= gations would be useful ... >>> Volunteers welcome ;-) >>>=20 >>> Best regards >>> Dirk >>> -----Original Message----- >>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>> Sent: Dienstag, 4. November 2014 16:49 >>> To: hiaps@ietf.org >>> Cc: Mohamed Boucadair; Brandon Williams; von Hugo, Dirk >>> Subject: Re: work to do >>>=20 >>> Hi all, >>>=20 >>> If I understood Dirk's mail, it seems like he is saying that we should f= irst work on a security analysis of host identifiers. >>>=20 >>> So I suggest having >>>=20 >>>=20 >>> Threat analysis >>> as the first step. >>>=20 >>> Is there a draft that covers similar issues? Maybe we can start with tha= t. Otherwise we discuss with the intent of outputting a draft. >>>=20 >>> Regards, >>>=20 >>> Behcet >>>=20 >>>> On Thu, Oct 30, 2014 at 2:35 PM, Behcet Sarikaya wrote: >>>> Hi all, >>>>=20 >>>> I tried to dress up things to do in hostid below as follows: >>>>=20 >>>> - requirements >>>>=20 >>>> - updated solution analysis >>>>=20 >>>> - solution(s) given the fact that we have diverse set of use cases, >>>> one size fits all type of a single solution may not be the way to go. >>>>=20 >>>> Regards, >>>>=20 >>>> Behcet >>> _______________________________________________ >>> hiaps mailing list >>> hiaps@ietf.org >>> https://www.ietf.org/mailman/listinfo/hiaps >>=20 >> _______________________________________________ >> hiaps mailing list >> hiaps@ietf.org >> https://www.ietf.org/mailman/listinfo/hiaps >=20 >=20 From nobody Sun Nov 9 23:24: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 6B5081A8943 for ; Sun, 9 Nov 2014 23:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3nJPvo3sC6i for ; Sun, 9 Nov 2014 23:24:01 -0800 (PST) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65E841A892C for ; Sun, 9 Nov 2014 23:24:01 -0800 (PST) Received: by mail-yh0-f47.google.com with SMTP id i57so432983yha.34 for ; Sun, 09 Nov 2014 23:24:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=Et/aI5GjlZf8UH674St+Ym0oFgjDgqdKSexAtB5tzdI=; b=kYsxMfVBYp/nReLBQNEd0IHbzfiFPLtILK3DBj5ca//1veI5BRaEp9T0o7j/zcXudA 77CxicD7yo2EiU1gZmA7TrKM8B1mCbUQeL6XU9DDqNiV1N6fPdx7r5z9Mu2I/mOoKVu9 ZYMGWzecJlC8sWOSKq7TTXe+GTmAYgwIqSTVkxGXIv5/aONpioBTPX5V8CTW/j4Q+nL6 KuLJllM93Pao5IdylcEZyg3xze46/il6HCQlVJOXcMb5weFNd09VDUvfKbYz8/IziKJN wmyAmT+f54Nn4F+CgRdUUFjTpAE0O4LUgMqd2rfUqqfU2YUVlcrMBL2BpNNymM38wKgZ /CRw== MIME-Version: 1.0 X-Received: by 10.236.229.165 with SMTP id h35mr26917785yhq.129.1415604240671; Sun, 09 Nov 2014 23:24:00 -0800 (PST) Received: by 10.170.71.198 with HTTP; Sun, 9 Nov 2014 23:24:00 -0800 (PST) Date: Mon, 10 Nov 2014 01:24:00 -0600 Message-ID: From: Behcet Sarikaya To: "hiaps@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/kBOkEATl1FcGkD3Z4G2BHIYnFfA Subject: [hiaps] Side Meeting 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 Nov 2014 07:24:02 -0000 Hi all, Side meeting will take place on Wednesday at 11:45 - 12:30 Room: Lehua which is around the registration desk area. See you all there. Regards, Behcet From nobody Sun Nov 9 23:28:22 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 09F9F1A8947 for ; Sun, 9 Nov 2014 23:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFZV-VEdrmh0 for ; Sun, 9 Nov 2014 23:28:19 -0800 (PST) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 533791A00BE for ; Sun, 9 Nov 2014 23:28:19 -0800 (PST) Received: by mail-yh0-f52.google.com with SMTP id f73so1767638yha.39 for ; Sun, 09 Nov 2014 23:28:18 -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:content-transfer-encoding; bh=WSHxqt6EdyG3btoA5lEDG0YXD5KgOQ6Cvhb07b+KX6w=; b=HZUmM2KveilBUoTgaHihIMsaEyMVH3kPlspMWYBqny8EQWhpvR9kCO8GI/+7L7P4An DIlfhrgqH5g94X66jZAVvNDMtt7bcFyniUrY8llw8iyO9T11a8B7yZQooivoQiwhI2r6 kyRBWHARelVJ11dwON376wSLKSHd30LdbGRKu4L3OxiZnX5f62gIxwzgTPA/fKyu2MJG DkwaDALDciVg/V5hL/gJqJ/cLYUc45hUDfI6jd8tYeF/Z2Uxk8qjHekBvY/HlgTd0C+A fznEwmtBHZ9sejUoWcqsJgVm+CaLpEKURz7bEBteGhbaSXg7a7CgQ+kAdkLqPn7oN+zA C2MQ== MIME-Version: 1.0 X-Received: by 10.236.229.165 with SMTP id h35mr26932725yhq.129.1415604498654; Sun, 09 Nov 2014 23:28:18 -0800 (PST) Received: by 10.170.71.198 with HTTP; Sun, 9 Nov 2014 23:28:18 -0800 (PST) In-Reply-To: <545FD066.3090007@bogus.com> References: <05C81A773E48DD49B181B04BA21A342A2E5EA93C73@HE113484.emea1.cds.t-internal.com> <545CFCCE.8010902@bogus.com> <50073658-B05F-40CB-B991-DD88706CFF66@gmail.com> <545FD066.3090007@bogus.com> Date: Mon, 10 Nov 2014 01:28:18 -0600 Message-ID: From: Behcet Sarikaya To: joel jaeggli Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/mn3YDXGy9RIIkOMD-LJGFN5XvCs Cc: "hiaps@ietf.org" , Mohamed Boucadair , Brandon Williams , "Dirk.von-Hugo@telekom.de" Subject: Re: [hiaps] work to do 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 Nov 2014 07:28:21 -0000 On Sun, Nov 9, 2014 at 2:36 PM, joel jaeggli wrote: > On 11/9/14 10:30 AM, Behcet Sarikaya wrote: >> In all cases we are dealing with addresses IPv4 or v6. >> They could be public or random or privacy addresses >> >> So I think host address use is justified. > > a 16 bit field is not an ip address. I think Med or Brandon should say something here, to my knowledge it is part of an address. Regards, Behcet > >> Regards >> >> Behcet >> >> Sent from my iPhone >> >>> On Nov 7, 2014, at 7:09 AM, joel jaeggli wrote: >>> >>>> On 11/7/14 7:41 AM, Behcet Sarikaya wrote: >>>> Hi Dirk, all, >>>> >>>> Reading your mail I came to understand a common misunderstanding on >>>> our activity. >>>> >>>> In fact what we are trying to do is already done in IPv6: every packet >>>> in IPv6 carries a public source address. Even in IPv4 in some cases it >>>> is done. >>>> >>>> I think privacy and security issues over which there is so much noise >>>> are related to the long lived host identifiers like MSISDN which is >>>> your phone number, as Med said. I don't remember anyone complaining on >>>> privacy / security issues on the very basic way IPv6 works. >>> >>> Well. There's a reason why hosts are generating privacy addresses. Bac= k >>> when they all encoded their mac addresses in the host field as modifie= d >>> eui64 and allowed that to be stable across subnets, a locally >>> significant but unique identifier was leaking into the internet. That >>> was addressed and to wit if you have a host identity problem with the v= 6 >>> addressing architecture that exists today it's because you cannot >>> distinguish between hosts purely on the basis of source address within = a >>> shared prefix. >>> >>> everytime I close the lid on the laptop or it goes to sleep I use a new >>> source address even though for example I use the same v4 address becaus= e >>> my lease still holds. >>> >>> inet6 2601:9:####:####:####:####:####:#### prefixlen 64 autoconf >>> inet6 2601:9:####:####:159a:c4b1:4efd:21a2 prefixlen 64 autoconf tem= porary >>> ... >>> >>> inet6 2601:9:####:####:a96e:3bcd:b861:ee69 prefixlen 64 autoconf tem= porary >>> >>>> This leads me to say that Med initially made an innocent mistake in >>>> selecting host id which can easily be mistaken for other host >>>> identifiers. Unfortunately this mistake has been hitting us like a >>>> boomerang. >>> >>> I'm not sure I consider 6967 to be a mistake. >>> >>> http://tools.ietf.org/html/rfc6967#section-3 >>> >>>> My view of the way out is to change the name. >>>> I think we should call host addresses and NOT host ids. >>> >>> not all the proposals involve addresses they are all identifiers. >>> >>>> So maybe we should NOT use hiaps but use haaps or host address and >>>> prefix sharing issues. This is a small change and we can easily carry >>>> this over on our work, drafts, etc. >>>> >>>> What do you think? >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>>> >>>>> On Thu, Nov 6, 2014 at 3:51 AM, wrote: >>>>> Hi Behcet, >>>>> Not exactly - I just wanted to say that the privacy issues are as imp= ortant as the other topics like scope and problem statement. >>>>> But I agree that we should look at existing drafts ... >>>>> A quick look at very recent I-Ds https://tools.ietf.org/html/draft-ie= tf-stir-rfc4474bis-02 related to SIP and https://tools.ietf.org/html/draft-= baker-openstack-rbac-federated-identity-00 might help, but more detailed in= vestigations would be useful ... >>>>> Volunteers welcome ;-) >>>>> >>>>> Best regards >>>>> Dirk >>>>> -----Original Message----- >>>>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>>>> Sent: Dienstag, 4. November 2014 16:49 >>>>> To: hiaps@ietf.org >>>>> Cc: Mohamed Boucadair; Brandon Williams; von Hugo, Dirk >>>>> Subject: Re: work to do >>>>> >>>>> Hi all, >>>>> >>>>> If I understood Dirk's mail, it seems like he is saying that we shoul= d first work on a security analysis of host identifiers. >>>>> >>>>> So I suggest having >>>>> >>>>> >>>>> Threat analysis >>>>> as the first step. >>>>> >>>>> Is there a draft that covers similar issues? Maybe we can start with = that. Otherwise we discuss with the intent of outputting a draft. >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>>> >>>>>> On Thu, Oct 30, 2014 at 2:35 PM, Behcet Sarikaya wrote: >>>>>> Hi all, >>>>>> >>>>>> I tried to dress up things to do in hostid below as follows: >>>>>> >>>>>> - requirements >>>>>> >>>>>> - updated solution analysis >>>>>> >>>>>> - solution(s) given the fact that we have diverse set of use cases, >>>>>> one size fits all type of a single solution may not be the way to go= . >>>>>> >>>>>> Regards, >>>>>> >>>>>> Behcet >>>>> _______________________________________________ >>>>> hiaps mailing list >>>>> hiaps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/hiaps >>>> >>>> _______________________________________________ >>>> hiaps mailing list >>>> hiaps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/hiaps >>> >>> >> > > From nobody Tue Nov 11 11:57:56 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 D21F11A8A1C for ; Tue, 11 Nov 2014 11:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeRAP2OYkILS for ; Tue, 11 Nov 2014 11:57:48 -0800 (PST) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886221A7010 for ; Tue, 11 Nov 2014 11:57:44 -0800 (PST) Received: by mail-yh0-f42.google.com with SMTP id b6so6088478yha.1 for ; Tue, 11 Nov 2014 11:57:43 -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=Ctk2W+4sHRo7HHRlC5CxYgBSkWN77ls+uAaMaslYIIA=; b=ECzFP8E76uE6SZFFuphsncFzLKzlvr7oD5K8EKf9hJJp83tIUcwDLzOkUq7K6BFMwx CWctxK/aLvnOwCPI/VxCRYiXIiCKtND2qAJ9ikvUBYp7c6Sgw5E+D1JnIvQUKw080AgW GI6LpEUOdUvGSQryOZH7f9GS7rIF9iPGk96usJrAW9NgFLC50eQeB/z84Fw2pVIUjgtT CwcWdX+uE2QagUUgQToQPTL0AvlnLRvAA/0+eCS5XdDTo1QN8Ctlp/784fJq7i43l15x kuEG3ctcKJGyKKSTYgkSDKHsbb6cAKsk6gW3qjhIOtlCtXcKmmnVAdjusw6+TL4v/GCI 2Mew== MIME-Version: 1.0 X-Received: by 10.236.202.232 with SMTP id d68mr11096210yho.113.1415735863693; Tue, 11 Nov 2014 11:57:43 -0800 (PST) Received: by 10.170.71.198 with HTTP; Tue, 11 Nov 2014 11:57:43 -0800 (PST) In-Reply-To: <545CFCCE.8010902@bogus.com> References: <05C81A773E48DD49B181B04BA21A342A2E5EA93C73@HE113484.emea1.cds.t-internal.com> <545CFCCE.8010902@bogus.com> Date: Tue, 11 Nov 2014 13:57:43 -0600 Message-ID: From: Behcet Sarikaya To: joel jaeggli Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/U1CJPkrgx_SD4ndhCzByRyWW0og Cc: "hiaps@ietf.org" , Mohamed Boucadair , Brandon Williams , "Dirk.von-Hugo@telekom.de" Subject: Re: [hiaps] work to do 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: Tue, 11 Nov 2014 19:57:50 -0000 On Fri, Nov 7, 2014 at 11:09 AM, joel jaeggli wrote: > On 11/7/14 7:41 AM, Behcet Sarikaya wrote: >> Hi Dirk, all, >> >> Reading your mail I came to understand a common misunderstanding on >> our activity. >> >> In fact what we are trying to do is already done in IPv6: every packet >> in IPv6 carries a public source address. Even in IPv4 in some cases it >> is done. >> >> I think privacy and security issues over which there is so much noise >> are related to the long lived host identifiers like MSISDN which is >> your phone number, as Med said. I don't remember anyone complaining on >> privacy / security issues on the very basic way IPv6 works. > > Well. There's a reason why hosts are generating privacy addresses. Back > when they all encoded their mac addresses in the host field as modified > eui64 and allowed that to be stable across subnets, a locally > significant but unique identifier was leaking into the internet. That > was addressed and to wit if you have a host identity problem with the v6 > addressing architecture that exists today it's because you cannot > distinguish between hosts purely on the basis of source address within a > shared prefix. > > everytime I close the lid on the laptop or it goes to sleep I use a new > source address even though for example I use the same v4 address because > my lease still holds. > > inet6 2601:9:####:####:####:####:####:#### prefixlen 64 autoconf > inet6 2601:9:####:####:159a:c4b1:4efd:21a2 prefixlen 64 autoconf temporary > ... > > inet6 2601:9:####:####:a96e:3bcd:b861:ee69 prefixlen 64 autoconf temporary > Maybe this gives us another use case for host address/ids? >> This leads me to say that Med initially made an innocent mistake in >> selecting host id which can easily be mistaken for other host >> identifiers. Unfortunately this mistake has been hitting us like a >> boomerang. > > I'm not sure I consider 6967 to be a mistake. > > http://tools.ietf.org/html/rfc6967#section-3 > >> My view of the way out is to change the name. >> I think we should call host addresses and NOT host ids. > > not all the proposals involve addresses they are all identifiers. > >> So maybe we should NOT use hiaps but use haaps or host address and >> prefix sharing issues. This is a small change and we can easily carry >> this over on our work, drafts, etc. >> >> What do you think? >> >> Regards, >> >> Behcet >> >> >> On Thu, Nov 6, 2014 at 3:51 AM, wrote: >>> Hi Behcet, >>> Not exactly - I just wanted to say that the privacy issues are as important as the other topics like scope and problem statement. >>> But I agree that we should look at existing drafts ... >>> A quick look at very recent I-Ds https://tools.ietf.org/html/draft-ietf-stir-rfc4474bis-02 related to SIP and https://tools.ietf.org/html/draft-baker-openstack-rbac-federated-identity-00 might help, but more detailed investigations would be useful ... >>> Volunteers welcome ;-) >>> >>> Best regards >>> Dirk >>> -----Original Message----- >>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>> Sent: Dienstag, 4. November 2014 16:49 >>> To: hiaps@ietf.org >>> Cc: Mohamed Boucadair; Brandon Williams; von Hugo, Dirk >>> Subject: Re: work to do >>> >>> Hi all, >>> >>> If I understood Dirk's mail, it seems like he is saying that we should first work on a security analysis of host identifiers. >>> >>> So I suggest having >>> >>> >>> Threat analysis >>> as the first step. >>> >>> Is there a draft that covers similar issues? Maybe we can start with that. Otherwise we discuss with the intent of outputting a draft. >>> >>> Regards, >>> >>> Behcet >>> >>> On Thu, Oct 30, 2014 at 2:35 PM, Behcet Sarikaya wrote: >>>> Hi all, >>>> >>>> I tried to dress up things to do in hostid below as follows: >>>> >>>> - requirements >>>> >>>> - updated solution analysis >>>> >>>> - solution(s) given the fact that we have diverse set of use cases, >>>> one size fits all type of a single solution may not be the way to go. >>>> >>>> Regards, >>>> >>>> Behcet >>> _______________________________________________ >>> hiaps mailing list >>> hiaps@ietf.org >>> https://www.ietf.org/mailman/listinfo/hiaps >> >> _______________________________________________ >> hiaps mailing list >> hiaps@ietf.org >> https://www.ietf.org/mailman/listinfo/hiaps >> > > From nobody Tue Nov 11 12:00:19 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 CFDA51A8A7A for ; Tue, 11 Nov 2014 12:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deLOMtIwIuFa for ; Tue, 11 Nov 2014 12:00:15 -0800 (PST) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C491A8A59 for ; Tue, 11 Nov 2014 12:00:15 -0800 (PST) Received: by mail-yh0-f52.google.com with SMTP id f73so392597yha.39 for ; Tue, 11 Nov 2014 12:00:14 -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:content-transfer-encoding; bh=1ib5KOVaU7UzdQQGCeB1tPCXZDNN8AwWjPiOZDnT0fQ=; b=keP+7M4Yk9nusse5K6SU6V0sdFpvnky61+MUFkv1/e+ihTTo3SZPdjv0z+Kp8DLCKI cHR0dPS1iqDGli8eLGAraCctuUWYJ8UGBM4ynZm6Bw2+NwbPoYUdatXeCrq6LopahOUn 7iw9bgkmak9Ve2eV+B12PP5P+/ybBCTvtj7guC67ACqLcJJs0CduFtyXsZRNHq38crd6 Ha9api0cN9hGx3a6STW9LvwBX+qjPb5kHpGMoG49z39ghGljIpCERMmoE1jF5LvMfndT c7EliG6CxO5t8LmalInGsa+4u4pO2cVBqPEWwqhAPyMYZixHf90rY+hnaGzFYVvhSxRD D7aA== MIME-Version: 1.0 X-Received: by 10.236.24.161 with SMTP id x21mr39343142yhx.96.1415736014393; Tue, 11 Nov 2014 12:00:14 -0800 (PST) Received: by 10.170.71.198 with HTTP; Tue, 11 Nov 2014 12:00:14 -0800 (PST) In-Reply-To: <545FD066.3090007@bogus.com> References: <05C81A773E48DD49B181B04BA21A342A2E5EA93C73@HE113484.emea1.cds.t-internal.com> <545CFCCE.8010902@bogus.com> <50073658-B05F-40CB-B991-DD88706CFF66@gmail.com> <545FD066.3090007@bogus.com> Date: Tue, 11 Nov 2014 14:00:14 -0600 Message-ID: From: Behcet Sarikaya To: joel jaeggli Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/40rAFzzH3a-rcmiULHmIUweFfz4 Cc: "hiaps@ietf.org" , Mohamed Boucadair , Brandon Williams , "Dirk.von-Hugo@telekom.de" Subject: Re: [hiaps] work to do 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: Tue, 11 Nov 2014 20:00:18 -0000 On Sun, Nov 9, 2014 at 2:36 PM, joel jaeggli wrote: > On 11/9/14 10:30 AM, Behcet Sarikaya wrote: >> In all cases we are dealing with addresses IPv4 or v6. >> They could be public or random or privacy addresses >> >> So I think host address use is justified. > > a 16 bit field is not an ip address. RFC 6967 mentions this: the lower 16 bits of an IPv4 address So it is not an ip address by itself (of course) but it is part of an addre= ss. > >> Regards >> >> Behcet >> >> Sent from my iPhone >> >>> On Nov 7, 2014, at 7:09 AM, joel jaeggli wrote: >>> >>>> On 11/7/14 7:41 AM, Behcet Sarikaya wrote: >>>> Hi Dirk, all, >>>> >>>> Reading your mail I came to understand a common misunderstanding on >>>> our activity. >>>> >>>> In fact what we are trying to do is already done in IPv6: every packet >>>> in IPv6 carries a public source address. Even in IPv4 in some cases it >>>> is done. >>>> >>>> I think privacy and security issues over which there is so much noise >>>> are related to the long lived host identifiers like MSISDN which is >>>> your phone number, as Med said. I don't remember anyone complaining on >>>> privacy / security issues on the very basic way IPv6 works. >>> >>> Well. There's a reason why hosts are generating privacy addresses. Bac= k >>> when they all encoded their mac addresses in the host field as modifie= d >>> eui64 and allowed that to be stable across subnets, a locally >>> significant but unique identifier was leaking into the internet. That >>> was addressed and to wit if you have a host identity problem with the v= 6 >>> addressing architecture that exists today it's because you cannot >>> distinguish between hosts purely on the basis of source address within = a >>> shared prefix. >>> >>> everytime I close the lid on the laptop or it goes to sleep I use a new >>> source address even though for example I use the same v4 address becaus= e >>> my lease still holds. >>> >>> inet6 2601:9:####:####:####:####:####:#### prefixlen 64 autoconf >>> inet6 2601:9:####:####:159a:c4b1:4efd:21a2 prefixlen 64 autoconf tem= porary >>> ... >>> >>> inet6 2601:9:####:####:a96e:3bcd:b861:ee69 prefixlen 64 autoconf tem= porary >>> >>>> This leads me to say that Med initially made an innocent mistake in >>>> selecting host id which can easily be mistaken for other host >>>> identifiers. Unfortunately this mistake has been hitting us like a >>>> boomerang. >>> >>> I'm not sure I consider 6967 to be a mistake. >>> >>> http://tools.ietf.org/html/rfc6967#section-3 >>> >>>> My view of the way out is to change the name. >>>> I think we should call host addresses and NOT host ids. >>> >>> not all the proposals involve addresses they are all identifiers. >>> >>>> So maybe we should NOT use hiaps but use haaps or host address and >>>> prefix sharing issues. This is a small change and we can easily carry >>>> this over on our work, drafts, etc. >>>> >>>> What do you think? >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>>> >>>>> On Thu, Nov 6, 2014 at 3:51 AM, wrote: >>>>> Hi Behcet, >>>>> Not exactly - I just wanted to say that the privacy issues are as imp= ortant as the other topics like scope and problem statement. >>>>> But I agree that we should look at existing drafts ... >>>>> A quick look at very recent I-Ds https://tools.ietf.org/html/draft-ie= tf-stir-rfc4474bis-02 related to SIP and https://tools.ietf.org/html/draft-= baker-openstack-rbac-federated-identity-00 might help, but more detailed in= vestigations would be useful ... >>>>> Volunteers welcome ;-) >>>>> >>>>> Best regards >>>>> Dirk >>>>> -----Original Message----- >>>>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>>>> Sent: Dienstag, 4. November 2014 16:49 >>>>> To: hiaps@ietf.org >>>>> Cc: Mohamed Boucadair; Brandon Williams; von Hugo, Dirk >>>>> Subject: Re: work to do >>>>> >>>>> Hi all, >>>>> >>>>> If I understood Dirk's mail, it seems like he is saying that we shoul= d first work on a security analysis of host identifiers. >>>>> >>>>> So I suggest having >>>>> >>>>> >>>>> Threat analysis >>>>> as the first step. >>>>> >>>>> Is there a draft that covers similar issues? Maybe we can start with = that. Otherwise we discuss with the intent of outputting a draft. >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>>> >>>>>> On Thu, Oct 30, 2014 at 2:35 PM, Behcet Sarikaya wrote: >>>>>> Hi all, >>>>>> >>>>>> I tried to dress up things to do in hostid below as follows: >>>>>> >>>>>> - requirements >>>>>> >>>>>> - updated solution analysis >>>>>> >>>>>> - solution(s) given the fact that we have diverse set of use cases, >>>>>> one size fits all type of a single solution may not be the way to go= . >>>>>> >>>>>> Regards, >>>>>> >>>>>> Behcet >>>>> _______________________________________________ >>>>> hiaps mailing list >>>>> hiaps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/hiaps >>>> >>>> _______________________________________________ >>>> hiaps mailing list >>>> hiaps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/hiaps >>> >>> >> > > From nobody Tue Nov 11 12:45:29 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 6FF2C1A8FD6 for ; Tue, 11 Nov 2014 12:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.773 X-Spam-Level: X-Spam-Status: No, score=-3.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 sE2op9-A0-8d for ; Tue, 11 Nov 2014 12:45:25 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 045B61A9088 for ; Tue, 11 Nov 2014 12:45:22 -0800 (PST) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5A839286CD for ; Tue, 11 Nov 2014 20:45:22 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 47E74286C8 for ; Tue, 11 Nov 2014 20:45:22 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 3A58D204B for ; Tue, 11 Nov 2014 20:45:22 +0000 (GMT) Message-ID: <54627562.2080901@akamai.com> Date: Tue, 11 Nov 2014 15:45:22 -0500 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 CC: "hiaps@ietf.org" References: <05C81A773E48DD49B181B04BA21A342A2E5EA93C73@HE113484.emea1.cds.t-internal.com> <545CFCCE.8010902@bogus.com> <50073658-B05F-40CB-B991-DD88706CFF66@gmail.com> <545FD066.3090007@bogus.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/wWkgl7D-dEwQLe3sRG1XXMqeSDY Subject: Re: [hiaps] work to do 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 Nov 2014 20:45:27 -0000 On 11/11/2014 03:00 PM, Behcet Sarikaya wrote: > On Sun, Nov 9, 2014 at 2:36 PM, joel jaeggli wrote: >> On 11/9/14 10:30 AM, Behcet Sarikaya wrote: >>> In all cases we are dealing with addresses IPv4 or v6. >>> They could be public or random or privacy addresses >>> >>> So I think host address use is justified. >> >> a 16 bit field is not an ip address. > > RFC 6967 mentions this: > > > the lower 16 bits of an IPv4 > address > > So it is not an ip address by itself (of course) but it is part of an address. > You are referring to examples presented in RFC6967, not a statement of requirements. The same example text refers to some non-address options too (VLAN ID, VRF ID, or subscriber ID). I think it's clear from the thread that at least some of us think that we need to be more careful than this list of examples suggests (e.g. I would not support a spec that intends to use subscriber ID as a HOST_ID value and would expect to see language in a solution RFC that prohibits such identifiers.). In other words, RFC6967 is not a solution spec and should not be considered as such. It is an analysis document intended to help assess a particular category of solution and for this reason it may contain unaddressed security and/or privacy issues. --Brandon > > >> >>> Regards >>> >>> Behcet >>> >>> Sent from my iPhone >>> >>>> On Nov 7, 2014, at 7:09 AM, joel jaeggli wrote: >>>> >>>>> On 11/7/14 7:41 AM, Behcet Sarikaya wrote: >>>>> Hi Dirk, all, >>>>> >>>>> Reading your mail I came to understand a common misunderstanding on >>>>> our activity. >>>>> >>>>> In fact what we are trying to do is already done in IPv6: every packet >>>>> in IPv6 carries a public source address. Even in IPv4 in some cases it >>>>> is done. >>>>> >>>>> I think privacy and security issues over which there is so much noise >>>>> are related to the long lived host identifiers like MSISDN which is >>>>> your phone number, as Med said. I don't remember anyone complaining on >>>>> privacy / security issues on the very basic way IPv6 works. >>>> >>>> Well. There's a reason why hosts are generating privacy addresses. Back >>>> when they all encoded their mac addresses in the host field as modified >>>> eui64 and allowed that to be stable across subnets, a locally >>>> significant but unique identifier was leaking into the internet. That >>>> was addressed and to wit if you have a host identity problem with the v6 >>>> addressing architecture that exists today it's because you cannot >>>> distinguish between hosts purely on the basis of source address within a >>>> shared prefix. >>>> >>>> everytime I close the lid on the laptop or it goes to sleep I use a new >>>> source address even though for example I use the same v4 address because >>>> my lease still holds. >>>> >>>> inet6 2601:9:####:####:####:####:####:#### prefixlen 64 autoconf >>>> inet6 2601:9:####:####:159a:c4b1:4efd:21a2 prefixlen 64 autoconf temporary >>>> ... >>>> >>>> inet6 2601:9:####:####:a96e:3bcd:b861:ee69 prefixlen 64 autoconf temporary >>>> >>>>> This leads me to say that Med initially made an innocent mistake in >>>>> selecting host id which can easily be mistaken for other host >>>>> identifiers. Unfortunately this mistake has been hitting us like a >>>>> boomerang. >>>> >>>> I'm not sure I consider 6967 to be a mistake. >>>> >>>> http://tools.ietf.org/html/rfc6967#section-3 >>>> >>>>> My view of the way out is to change the name. >>>>> I think we should call host addresses and NOT host ids. >>>> >>>> not all the proposals involve addresses they are all identifiers. >>>> >>>>> So maybe we should NOT use hiaps but use haaps or host address and >>>>> prefix sharing issues. This is a small change and we can easily carry >>>>> this over on our work, drafts, etc. >>>>> >>>>> What do you think? >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>>> >>>>> >>>>>> On Thu, Nov 6, 2014 at 3:51 AM, wrote: >>>>>> Hi Behcet, >>>>>> Not exactly - I just wanted to say that the privacy issues are as important as the other topics like scope and problem statement. >>>>>> But I agree that we should look at existing drafts ... >>>>>> A quick look at very recent I-Ds https://tools.ietf.org/html/draft-ietf-stir-rfc4474bis-02 related to SIP and https://tools.ietf.org/html/draft-baker-openstack-rbac-federated-identity-00 might help, but more detailed investigations would be useful ... >>>>>> Volunteers welcome ;-) >>>>>> >>>>>> Best regards >>>>>> Dirk >>>>>> -----Original Message----- >>>>>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>>>>> Sent: Dienstag, 4. November 2014 16:49 >>>>>> To: hiaps@ietf.org >>>>>> Cc: Mohamed Boucadair; Brandon Williams; von Hugo, Dirk >>>>>> Subject: Re: work to do >>>>>> >>>>>> Hi all, >>>>>> >>>>>> If I understood Dirk's mail, it seems like he is saying that we should first work on a security analysis of host identifiers. >>>>>> >>>>>> So I suggest having >>>>>> >>>>>> >>>>>> Threat analysis >>>>>> as the first step. >>>>>> >>>>>> Is there a draft that covers similar issues? Maybe we can start with that. Otherwise we discuss with the intent of outputting a draft. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Behcet >>>>>> >>>>>>> On Thu, Oct 30, 2014 at 2:35 PM, Behcet Sarikaya wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I tried to dress up things to do in hostid below as follows: >>>>>>> >>>>>>> - requirements >>>>>>> >>>>>>> - updated solution analysis >>>>>>> >>>>>>> - solution(s) given the fact that we have diverse set of use cases, >>>>>>> one size fits all type of a single solution may not be the way to go. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Behcet >>>>>> _______________________________________________ >>>>>> hiaps mailing list >>>>>> hiaps@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/hiaps >>>>> >>>>> _______________________________________________ >>>>> hiaps mailing list >>>>> hiaps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/hiaps >>>> >>>> >>> >> >> -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Tue Nov 11 15:10:21 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 CC1EA1A1B6B for ; Tue, 11 Nov 2014 15:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWeMK9zqEsYj for ; Tue, 11 Nov 2014 15:10:16 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA7B1A1B11 for ; Tue, 11 Nov 2014 15:10:15 -0800 (PST) Received: by mail-yk0-f177.google.com with SMTP id 19so500857ykq.8 for ; Tue, 11 Nov 2014 15:10:15 -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=PxiDbl2KEygkFspVgmjgwplmPCDpBVnew3OxJeUHpyY=; b=t7gT3LmlBVDpvAh51gYsz0NZPIYUAF7CbO9YU8wHLKc+5fanlaByfOpC4+K4g/1RiL +HyP5MDIQyhLBxtohFMj25Fyl+dfAhiZNVNMvOHuUNwm4mYqPw58FjxBvokskwA+b6bO BbZ0X+0VECZGlbLrP6wZ6trcu6GE9kD7wLOwWRKiv/e292ULPx02K0OSt+JdrqaOz3c3 1n+KT3ydFNKqKZhqjHXqKCYXwn5Qz+Sfn4rTU9aanzb7mWicE2zrrXE1YrMgg3CzvDiB Sp5rrxae0si3m/BUvehDXDO9PkwaMvMY7HJ8dfWnBuw9AKMOYYT8x2FDSe7u2aIUznbZ jYtQ== MIME-Version: 1.0 X-Received: by 10.170.56.12 with SMTP id 12mr5286265yky.86.1415747415220; Tue, 11 Nov 2014 15:10:15 -0800 (PST) Received: by 10.170.71.198 with HTTP; Tue, 11 Nov 2014 15:10:15 -0800 (PST) In-Reply-To: <5462751C.6010001@akamai.com> References: <05C81A773E48DD49B181B04BA21A342A2E5EA93C73@HE113484.emea1.cds.t-internal.com> <545CFCCE.8010902@bogus.com> <50073658-B05F-40CB-B991-DD88706CFF66@gmail.com> <545FD066.3090007@bogus.com> <5462751C.6010001@akamai.com> Date: Tue, 11 Nov 2014 17:10:15 -0600 Message-ID: From: Behcet Sarikaya To: Brandon Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/tY6_j8ASi-rFdAfmQo0tKfFeODI Cc: joel jaeggli , "hiaps@ietf.org" , Mohamed Boucadair , "Dirk.von-Hugo@telekom.de" Subject: Re: [hiaps] work to do 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: Tue, 11 Nov 2014 23:10:18 -0000 On Tue, Nov 11, 2014 at 2:44 PM, Brandon Williams wrote: > On 11/11/2014 03:00 PM, Behcet Sarikaya wrote: >> >> On Sun, Nov 9, 2014 at 2:36 PM, joel jaeggli wrote: >>> >>> On 11/9/14 10:30 AM, Behcet Sarikaya wrote: >>>> >>>> In all cases we are dealing with addresses IPv4 or v6. >>>> They could be public or random or privacy addresses >>>> >>>> So I think host address use is justified. >>> >>> >>> a 16 bit field is not an ip address. >> >> >> RFC 6967 mentions this: >> >> >> the lower 16 bits of an IPv4 >> address >> >> So it is not an ip address by itself (of course) but it is part of an >> address. >> > > You are referring to examples presented in RFC6967, not a statement of > requirements. The same example text refers to some non-address options too > (VLAN ID, VRF ID, or subscriber ID). I think it's clear from the thread that > at least some of us think that we need to be more careful than this list of > examples suggests (e.g. I would not support a spec that intends to use > subscriber ID as a HOST_ID value and would expect to see language in a > solution RFC that prohibits such identifiers.). > > In other words, RFC6967 is not a solution spec and should not be considered > as such. It is an analysis document intended to help assess a particular > category of solution and for this reason it may contain unaddressed security > and/or privacy issues. > Absolutely. At the beginning of this thread, we mentioned requirements as the first in things to do. Regards, Behcet > --Brandon > > >> >> >>> >>>> Regards >>>> >>>> Behcet >>>> >>>> Sent from my iPhone >>>> >>>>> On Nov 7, 2014, at 7:09 AM, joel jaeggli wrote: >>>>> >>>>>> On 11/7/14 7:41 AM, Behcet Sarikaya wrote: >>>>>> Hi Dirk, all, >>>>>> >>>>>> Reading your mail I came to understand a common misunderstanding on >>>>>> our activity. >>>>>> >>>>>> In fact what we are trying to do is already done in IPv6: every packet >>>>>> in IPv6 carries a public source address. Even in IPv4 in some cases it >>>>>> is done. >>>>>> >>>>>> I think privacy and security issues over which there is so much noise >>>>>> are related to the long lived host identifiers like MSISDN which is >>>>>> your phone number, as Med said. I don't remember anyone complaining on >>>>>> privacy / security issues on the very basic way IPv6 works. >>>>> >>>>> >>>>> Well. There's a reason why hosts are generating privacy addresses. >>>>> Back >>>>> when they all encoded their mac addresses in the host field as >>>>> modified >>>>> eui64 and allowed that to be stable across subnets, a locally >>>>> significant but unique identifier was leaking into the internet. That >>>>> was addressed and to wit if you have a host identity problem with the >>>>> v6 >>>>> addressing architecture that exists today it's because you cannot >>>>> distinguish between hosts purely on the basis of source address within >>>>> a >>>>> shared prefix. >>>>> >>>>> everytime I close the lid on the laptop or it goes to sleep I use a new >>>>> source address even though for example I use the same v4 address >>>>> because >>>>> my lease still holds. >>>>> >>>>> inet6 2601:9:####:####:####:####:####:#### prefixlen 64 autoconf >>>>> inet6 2601:9:####:####:159a:c4b1:4efd:21a2 prefixlen 64 autoconf >>>>> temporary >>>>> ... >>>>> >>>>> inet6 2601:9:####:####:a96e:3bcd:b861:ee69 prefixlen 64 autoconf >>>>> temporary >>>>> >>>>>> This leads me to say that Med initially made an innocent mistake in >>>>>> selecting host id which can easily be mistaken for other host >>>>>> identifiers. Unfortunately this mistake has been hitting us like a >>>>>> boomerang. >>>>> >>>>> >>>>> I'm not sure I consider 6967 to be a mistake. >>>>> >>>>> http://tools.ietf.org/html/rfc6967#section-3 >>>>> >>>>>> My view of the way out is to change the name. >>>>>> I think we should call host addresses and NOT host ids. >>>>> >>>>> >>>>> not all the proposals involve addresses they are all identifiers. >>>>> >>>>>> So maybe we should NOT use hiaps but use haaps or host address and >>>>>> prefix sharing issues. This is a small change and we can easily carry >>>>>> this over on our work, drafts, etc. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Behcet >>>>>> >>>>>> >>>>>>> On Thu, Nov 6, 2014 at 3:51 AM, wrote: >>>>>>> Hi Behcet, >>>>>>> Not exactly - I just wanted to say that the privacy issues are as >>>>>>> important as the other topics like scope and problem statement. >>>>>>> But I agree that we should look at existing drafts ... >>>>>>> A quick look at very recent I-Ds >>>>>>> https://tools.ietf.org/html/draft-ietf-stir-rfc4474bis-02 related to SIP and >>>>>>> https://tools.ietf.org/html/draft-baker-openstack-rbac-federated-identity-00 >>>>>>> might help, but more detailed investigations would be useful ... >>>>>>> Volunteers welcome ;-) >>>>>>> >>>>>>> Best regards >>>>>>> Dirk >>>>>>> -----Original Message----- >>>>>>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>>>>>> Sent: Dienstag, 4. November 2014 16:49 >>>>>>> To: hiaps@ietf.org >>>>>>> Cc: Mohamed Boucadair; Brandon Williams; von Hugo, Dirk >>>>>>> Subject: Re: work to do >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> If I understood Dirk's mail, it seems like he is saying that we >>>>>>> should first work on a security analysis of host identifiers. >>>>>>> >>>>>>> So I suggest having >>>>>>> >>>>>>> >>>>>>> Threat analysis >>>>>>> as the first step. >>>>>>> >>>>>>> Is there a draft that covers similar issues? Maybe we can start with >>>>>>> that. Otherwise we discuss with the intent of outputting a draft. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Behcet >>>>>>> >>>>>>>> On Thu, Oct 30, 2014 at 2:35 PM, Behcet Sarikaya >>>>>>>> wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I tried to dress up things to do in hostid below as follows: >>>>>>>> >>>>>>>> - requirements >>>>>>>> >>>>>>>> - updated solution analysis >>>>>>>> >>>>>>>> - solution(s) given the fact that we have diverse set of use cases, >>>>>>>> one size fits all type of a single solution may not be the way to >>>>>>>> go. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Behcet >>>>>>> >>>>>>> _______________________________________________ >>>>>>> hiaps mailing list >>>>>>> hiaps@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/hiaps >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> hiaps mailing list >>>>>> hiaps@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/hiaps >>>>> >>>>> >>>>> >>>> >>> >>> > > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Nov 12 07:19:43 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 586391A1B18 for ; Wed, 12 Nov 2014 07:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBcCFWesMoIU for ; Wed, 12 Nov 2014 07:19:32 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08301A1AFB for ; Wed, 12 Nov 2014 07:19:29 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id CDFFF2640EC; Wed, 12 Nov 2014 16:19:27 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id A5E194C063; Wed, 12 Nov 2014 16:19:27 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.57]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Wed, 12 Nov 2014 16:19:27 +0100 From: To: joel jaeggli , Behcet Sarikaya Thread-Topic: [hiaps] work to do Thread-Index: AQHP+q2tjX8l86O1aUOMUee7qNQiApxYscCAgAAB7ACABG47cA== Date: Wed, 12 Nov 2014 15:19:27 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93301D52EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <05C81A773E48DD49B181B04BA21A342A2E5EA93C73@HE113484.emea1.cds.t-internal.com> <545CFCCE.8010902@bogus.com> <50073658-B05F-40CB-B991-DD88706CFF66@gmail.com> <545FD066.3090007@bogus.com> In-Reply-To: <545FD066.3090007@bogus.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.12.80623 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/4jcIUPaZ1o5CcSiO4NMaahCWn18 Cc: "hiaps@ietf.org" , "sarikaya@ieee.org" , Brandon Williams , "Dirk.von-Hugo@telekom.de" Subject: Re: [hiaps] work to do 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 Nov 2014 15:19:39 -0000 Hi Behcet, all, HOST_ID as initially defined in intarea document is not an IP address. RFC6= 967 says explicitly the following: " due to address sharing, servers need extra information beyond the source IP address to differentiate the sending host. We call this information the HOST_ID."=20 And the following: "Because the HOST_ID is used by a remote server to sort out the packets by sending host, the HOST_ID must be unique to each host under the same shared IP address, where possible. In the case where only the Home Gateway is revealed to the operator side of the translation function, the HOST_ID need only be unique to the Home Gateway. The HOST_ID does not need to be globally unique. Of course, the combination of the (public) IP source address and the identifier (i.e., HOST_ID) ends up being unique. If the HOST_ID is conveyed at the IP level, all packets will have to bear the identifier. If it is conveyed at a higher connection- oriented level, the identifier is only needed once in the session establishment phase (for instance, a TCP three-way handshake), then all packets received in this session will be attributed to the HOST_ID designated during the session opening." Cheers, Med -----Message d'origine----- De=A0: hiaps [mailto:hiaps-bounces@ietf.org] De la part de joel jaeggli Envoy=E9=A0: dimanche 9 novembre 2014 21:37 =C0=A0: Behcet Sarikaya Cc=A0: hiaps@ietf.org; sarikaya@ieee.org; BOUCADAIR Mohamed IMT/OLN; Brando= n Williams; Dirk.von-Hugo@telekom.de Objet=A0: Re: [hiaps] work to do On 11/9/14 10:30 AM, Behcet Sarikaya wrote: > In all cases we are dealing with addresses IPv4 or v6. > They could be public or random or privacy addresses=20 >=20 > So I think host address use is justified. a 16 bit field is not an ip address. > Regards >=20 > Behcet=20 >=20 > Sent from my iPhone >=20 >> On Nov 7, 2014, at 7:09 AM, joel jaeggli wrote: >> >>> On 11/7/14 7:41 AM, Behcet Sarikaya wrote: >>> Hi Dirk, all, >>> >>> Reading your mail I came to understand a common misunderstanding on >>> our activity. >>> >>> In fact what we are trying to do is already done in IPv6: every packet >>> in IPv6 carries a public source address. Even in IPv4 in some cases it >>> is done. >>> >>> I think privacy and security issues over which there is so much noise >>> are related to the long lived host identifiers like MSISDN which is >>> your phone number, as Med said. I don't remember anyone complaining on >>> privacy / security issues on the very basic way IPv6 works. >> >> Well. There's a reason why hosts are generating privacy addresses. Back >> when they all encoded their mac addresses in the host field as modified >> eui64 and allowed that to be stable across subnets, a locally >> significant but unique identifier was leaking into the internet. That >> was addressed and to wit if you have a host identity problem with the v6 >> addressing architecture that exists today it's because you cannot >> distinguish between hosts purely on the basis of source address within a >> shared prefix. >> >> everytime I close the lid on the laptop or it goes to sleep I use a new >> source address even though for example I use the same v4 address because >> my lease still holds. >> >> inet6 2601:9:####:####:####:####:####:#### prefixlen 64 autoconf >> inet6 2601:9:####:####:159a:c4b1:4efd:21a2 prefixlen 64 autoconf temp= orary >> ... >> >> inet6 2601:9:####:####:a96e:3bcd:b861:ee69 prefixlen 64 autoconf temp= orary >> >>> This leads me to say that Med initially made an innocent mistake in >>> selecting host id which can easily be mistaken for other host >>> identifiers. Unfortunately this mistake has been hitting us like a >>> boomerang. >> >> I'm not sure I consider 6967 to be a mistake. >> >> http://tools.ietf.org/html/rfc6967#section-3 >> >>> My view of the way out is to change the name. >>> I think we should call host addresses and NOT host ids. >> >> not all the proposals involve addresses they are all identifiers. >> >>> So maybe we should NOT use hiaps but use haaps or host address and >>> prefix sharing issues. This is a small change and we can easily carry >>> this over on our work, drafts, etc. >>> >>> What do you think? >>> >>> Regards, >>> >>> Behcet >>> >>> >>>> On Thu, Nov 6, 2014 at 3:51 AM, wrote: >>>> Hi Behcet, >>>> Not exactly - I just wanted to say that the privacy issues are as impo= rtant as the other topics like scope and problem statement. >>>> But I agree that we should look at existing drafts ... >>>> A quick look at very recent I-Ds https://tools.ietf.org/html/draft-iet= f-stir-rfc4474bis-02 related to SIP and https://tools.ietf.org/html/draft-b= aker-openstack-rbac-federated-identity-00 might help, but more detailed inv= estigations would be useful ... >>>> Volunteers welcome ;-) >>>> >>>> Best regards >>>> Dirk >>>> -----Original Message----- >>>> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>>> Sent: Dienstag, 4. November 2014 16:49 >>>> To: hiaps@ietf.org >>>> Cc: Mohamed Boucadair; Brandon Williams; von Hugo, Dirk >>>> Subject: Re: work to do >>>> >>>> Hi all, >>>> >>>> If I understood Dirk's mail, it seems like he is saying that we should= first work on a security analysis of host identifiers. >>>> >>>> So I suggest having >>>> >>>> >>>> Threat analysis >>>> as the first step. >>>> >>>> Is there a draft that covers similar issues? Maybe we can start with t= hat. Otherwise we discuss with the intent of outputting a draft. >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>>>> On Thu, Oct 30, 2014 at 2:35 PM, Behcet Sarikaya wrote: >>>>> Hi all, >>>>> >>>>> I tried to dress up things to do in hostid below as follows: >>>>> >>>>> - requirements >>>>> >>>>> - updated solution analysis >>>>> >>>>> - solution(s) given the fact that we have diverse set of use cases, >>>>> one size fits all type of a single solution may not be the way to go. >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>> _______________________________________________ >>>> hiaps mailing list >>>> hiaps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/hiaps >>> >>> _______________________________________________ >>> hiaps mailing list >>> hiaps@ietf.org >>> https://www.ietf.org/mailman/listinfo/hiaps >> >> >=20 From nobody Wed Nov 12 07:28:21 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 8B2E61A19FB for ; Wed, 12 Nov 2014 07:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCvk9Bx5qE4x for ; Wed, 12 Nov 2014 07:28:15 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82C61A1AE4 for ; Wed, 12 Nov 2014 07:28:14 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 23D7C324670 for ; Wed, 12 Nov 2014 16:28:13 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 05BE5238077 for ; Wed, 12 Nov 2014 16:28:13 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.57]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0210.002; Wed, 12 Nov 2014 16:28:12 +0100 From: To: "hiaps@ietf.org" Thread-Topic: Other Built-in Demux Identifiers: The QUIC Approach Thread-Index: Ac/+jUOIuGwxujI1S0KEgp2CXegP8Q== Date: Wed, 12 Nov 2014 15:28:12 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93301D5310@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93301D5310OPEXCLILM23corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.12.80623 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/xwxcyUVRjYNCNK_lmtf6J7LVn8k Subject: [hiaps] Other Built-in Demux Identifiers: The QUIC Approach 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 Nov 2014 15:28:18 -0000 --_000_787AE7BB302AE849A7480A190F8B93301D5310OPEXCLILM23corpor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, FWIW, QUIC is proposing a unique identifier to demux connections bound to t= he same IP address. "Given that NAT services can vary the WAN-visible source-port over the life= time of a connection (via unbinding, and rebinding), it is clear that sourc= e-IP address and source-port are strictly insufficient to define a connecti= on. We overcome any such confusion by using a CID (Connection IDentifier) w= hich generally persists for the lifetime of the connection. A CID is a pse= udo randomly generated nonce [size is currently set at 64 bits], that is ex= pected to be universally unique. The CID is usually proposed in the first = UDP packet sent by a client to a server, and is present explicitly or impli= citly in all future packets that are exchanged for the lifetime of the conn= ection. It is the defining key for the connection. A server can use this CID as a key to identify the specific connection from= among many inbound connections sending UDP packets to a single server port= . The CID is also used by the server to resurrect the current session encr= yption context for use with AEAD (Authenticated Encryption with Associated = Data). That context conceptually includes an encryption key, as well as an= authentication key. (Note: mutable portions of the packet, such as source= -port, etc., are not included in the Associated Data authentication)." More information can be found here: https://docs.google.com/document/d/1RNH= kx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/mobilebasic?pli=3D1 Note CID is universally unique. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93301D5310OPEXCLILM23corpor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

FWIW, QUIC is proposing a unique identifier= to demux connections bound to the same IP address.

 

“Given that NAT services can vary the= WAN-visible source-port over the lifetime of a connection (via unbinding, = and rebinding), it is clear that source-IP address and source-port are strictly insufficient to define a connection. We overcome = any such confusion by using a CID (Connection IDentifier) which generally p= ersists for the lifetime of the connection.  A CID is a pseudo randoml= y generated nonce [size is currently set at 64 bits], that is expected to be universally unique.  The CID = is usually proposed in the first UDP packet sent by a client to a server, a= nd is present explicitly or implicitly in all future packets that are excha= nged for the lifetime of the connection.  It is the defining key for the connection.

 

A server can use this CID as a key to ident= ify the specific connection from among many inbound connections sending UDP= packets to a single server port.  The CID is also used by the server to resurrect the current session encryption context for= use with AEAD (Authenticated Encryption with Associated Data).  That = context conceptually includes an encryption key, as well as an authenticati= on key.  (Note: mutable portions of the packet, such as source-port, etc., are not included in the Associated Data= authentication).”

 

More information can be found here: https://docs.goo= gle.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/mobilebasic= ?pli=3D1

 

Note CID is universally unique.<= /span>

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93301D5310OPEXCLILM23corpor_-- From nobody Wed Nov 12 07:43:36 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 66F9C1A1B18 for ; Wed, 12 Nov 2014 07:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3nLb-tzj9cv for ; Wed, 12 Nov 2014 07:43:33 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46B301A1AB2 for ; Wed, 12 Nov 2014 07:43:32 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 8B548374055; Wed, 12 Nov 2014 16:43:30 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 67976C8085; Wed, 12 Nov 2014 16:43:30 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.57]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0210.002; Wed, 12 Nov 2014 16:43:30 +0100 From: To: "sarikaya@ieee.org" , "Dirk.von-Hugo@telekom.de" Thread-Topic: [hiaps] work to do Thread-Index: AQHP+qE/r9K21t3eiU6u6w1x/no3tpxdJgMg Date: Wed, 12 Nov 2014 15:43:30 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93301D5340@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <05C81A773E48DD49B181B04BA21A342A2E5EA93C73@HE113484.emea1.cds.t-internal.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.12.65124 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/tVVbcwrtRmwbtYqAABLvqX4GFpY Cc: "hiaps@ietf.org" , Brandon Williams Subject: Re: [hiaps] work to do 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 Nov 2014 15:43:35 -0000 SGkgQmVoY2V0LA0KDQpXZSBoYXZlIGNob3NlbiBIT1NUX0lEIG9uIHB1cnBvc2UgdG8gZXhwbGlj aXRseSBzaG93IHRoYXQgd2UgYXJlIGFza2luZyBmb3IgYSB1c2VyIGlkZW50aWZpZXIgb3IgYSBz dWJzY3JpYmVyIGlkZW50aWZpZXIuIFdoYXQgaXMgbmVlZGVkIGlzIGEgKiogZGVtdXggaW5mb3Jt YXRpb24gdG8gdW5hbWJpZ3VvdXNseSBkaXN0aW5ndWlzaCBhIGhvc3QgYW1vbmcgdGhvc2Ugc2hh cmluZyB0aGUgc2FtZSBJUCBhZGRyZXNzICoqLiBXaGV0aGVyIHRoYXQgaWRlbnRpZmllciBpcyBh IHNvbWUgYml0cyBvZiBhbiBJUHY0IGFkZHJlc3Mgb3IgSVB2NiBwcmVmaXggaXMgYWN0dWFsbHkg ZGVwbG95bWVudC1zcGVjaWZpYy4NCg0KV2UgY291bGQgdXNlIEhPU1RfTkFUX0lEIGJ1dCB0aGlz IHdvdWxkIG5vdCB3b3JrIHRvbyBnaXZlbiB0aGF0IHRoZSBkZW11eCBpc3N1ZSBpcyB2YWxpZCBm b3Igb3RoZXIgbm9uLU5BVCBjb250ZXh0cyBzdWNoIGFzIEErUCwgYXBwbGljYXRpb24gcHJveGll cywgZXRjLg0KDQpUaGUgZGVtdXggaXMgbm90IG5lY2Vzc2FyaWx5IGFuIGludGVybmFsIElQIGFk ZHJlc3MgYXMgaXQgd291bGQgYmUgYXNzdW1lZCBieSBYRkYgZm9yIGluc3RhbmNlLiBUaGluayBh Ym91dCB0aGUgRFMtTGl0ZSBjb250ZXh0IHdoZXJlIHRoZSBzYW1lIGludGVybmFsIElQdjQgYWRk cmVzcyB3aWxsIGJlIGNvbW1vbiB0byBzZXZlcmFsIERTLUxpdGUgc2VydmljZWQgbmV0d29ya3Mu DQoNCkNoZWVycywNCk1lZA0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IEJl aGNldCBTYXJpa2F5YSBbbWFpbHRvOnNhcmlrYXlhMjAxMkBnbWFpbC5jb21dIA0KRW52b3nDqcKg OiB2ZW5kcmVkaSA3IG5vdmVtYnJlIDIwMTQgMTY6NDENCsOAwqA6IERpcmsudm9uLUh1Z29AdGVs ZWtvbS5kZQ0KQ2PCoDogaGlhcHNAaWV0Zi5vcmc7IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47 IEJyYW5kb24gV2lsbGlhbXMNCk9iamV0wqA6IFJlOiBbaGlhcHNdIHdvcmsgdG8gZG8NCg0KSGkg RGlyaywgYWxsLA0KDQpSZWFkaW5nIHlvdXIgbWFpbCBJICBjYW1lIHRvIHVuZGVyc3RhbmQgYSBj b21tb24gbWlzdW5kZXJzdGFuZGluZyBvbg0Kb3VyIGFjdGl2aXR5Lg0KDQpJbiBmYWN0IHdoYXQg d2UgYXJlIHRyeWluZyB0byBkbyBpcyBhbHJlYWR5IGRvbmUgaW4gSVB2NjogZXZlcnkgcGFja2V0 DQppbiBJUHY2IGNhcnJpZXMgYSBwdWJsaWMgc291cmNlIGFkZHJlc3MuIEV2ZW4gaW4gSVB2NCBp biBzb21lIGNhc2VzIGl0DQppcyBkb25lLg0KDQpJIHRoaW5rIHByaXZhY3kgYW5kIHNlY3VyaXR5 IGlzc3VlcyBvdmVyIHdoaWNoIHRoZXJlIGlzIHNvIG11Y2ggbm9pc2UNCmFyZSByZWxhdGVkIHRv IHRoZSBsb25nIGxpdmVkIGhvc3QgaWRlbnRpZmllcnMgbGlrZSBNU0lTRE4gd2hpY2ggaXMNCnlv dXIgcGhvbmUgbnVtYmVyLCBhcyBNZWQgc2FpZC4gSSBkb24ndCByZW1lbWJlciBhbnlvbmUgY29t cGxhaW5pbmcgb24NCnByaXZhY3kgLyBzZWN1cml0eSBpc3N1ZXMgb24gdGhlIHZlcnkgYmFzaWMg d2F5IElQdjYgd29ya3MuDQoNClRoaXMgbGVhZHMgbWUgdG8gc2F5IHRoYXQgTWVkIGluaXRpYWxs eSBtYWRlIGFuIGlubm9jZW50IG1pc3Rha2UgaW4NCnNlbGVjdGluZyBob3N0IGlkIHdoaWNoIGNh biBlYXNpbHkgYmUgbWlzdGFrZW4gZm9yIG90aGVyIGhvc3QNCmlkZW50aWZpZXJzLiBVbmZvcnR1 bmF0ZWx5IHRoaXMgbWlzdGFrZSBoYXMgYmVlbiBoaXR0aW5nIHVzIGxpa2UgYQ0KYm9vbWVyYW5n Lg0KDQpNeSB2aWV3IG9mIHRoZSB3YXkgb3V0IGlzIHRvIGNoYW5nZSB0aGUgbmFtZS4NCkkgdGhp bmsgd2Ugc2hvdWxkIGNhbGwgaG9zdCBhZGRyZXNzZXMgYW5kIE5PVCBob3N0IGlkcy4NClNvIG1h eWJlIHdlIHNob3VsZCBOT1QgdXNlIGhpYXBzIGJ1dCB1c2UgaGFhcHMgb3IgaG9zdCBhZGRyZXNz IGFuZA0KcHJlZml4IHNoYXJpbmcgaXNzdWVzLiBUaGlzIGlzIGEgc21hbGwgY2hhbmdlIGFuZCB3 ZSBjYW4gZWFzaWx5IGNhcnJ5DQp0aGlzIG92ZXIgb24gb3VyIHdvcmssIGRyYWZ0cywgZXRjLg0K DQpXaGF0IGRvIHlvdSB0aGluaz8NCg0KUmVnYXJkcywNCg0KQmVoY2V0DQoNCg0KT24gVGh1LCBO b3YgNiwgMjAxNCBhdCAzOjUxIEFNLCAgPERpcmsudm9uLUh1Z29AdGVsZWtvbS5kZT4gd3JvdGU6 DQo+IEhpIEJlaGNldCwNCj4gTm90IGV4YWN0bHkgLSBJIGp1c3Qgd2FudGVkIHRvIHNheSB0aGF0 IHRoZSBwcml2YWN5IGlzc3VlcyBhcmUgYXMgaW1wb3J0YW50IGFzIHRoZSBvdGhlciB0b3BpY3Mg bGlrZSBzY29wZSBhbmQgcHJvYmxlbSBzdGF0ZW1lbnQuDQo+IEJ1dCBJIGFncmVlIHRoYXQgd2Ug c2hvdWxkIGxvb2sgYXQgZXhpc3RpbmcgZHJhZnRzIC4uLg0KPiBBIHF1aWNrIGxvb2sgYXQgdmVy eSByZWNlbnQgSS1EcyBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zdGly LXJmYzQ0NzRiaXMtMDIgcmVsYXRlZCB0byBTSVAgYW5kIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1iYWtlci1vcGVuc3RhY2stcmJhYy1mZWRlcmF0ZWQtaWRlbnRpdHktMDAgbWln aHQgaGVscCwgYnV0IG1vcmUgZGV0YWlsZWQgaW52ZXN0aWdhdGlvbnMgd291bGQgYmUgdXNlZnVs IC4uLg0KPiBWb2x1bnRlZXJzIHdlbGNvbWUgOy0pDQo+DQo+IEJlc3QgcmVnYXJkcw0KPiBEaXJr DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJlaGNldCBTYXJpa2F5YSBb bWFpbHRvOnNhcmlrYXlhMjAxMkBnbWFpbC5jb21dDQo+IFNlbnQ6IERpZW5zdGFnLCA0LiBOb3Zl bWJlciAyMDE0IDE2OjQ5DQo+IFRvOiBoaWFwc0BpZXRmLm9yZw0KPiBDYzogTW9oYW1lZCBCb3Vj YWRhaXI7IEJyYW5kb24gV2lsbGlhbXM7IHZvbiBIdWdvLCBEaXJrDQo+IFN1YmplY3Q6IFJlOiB3 b3JrIHRvIGRvDQo+DQo+IEhpIGFsbCwNCj4NCj4gSWYgSSB1bmRlcnN0b29kIERpcmsncyBtYWls LCBpdCBzZWVtcyBsaWtlIGhlIGlzIHNheWluZyB0aGF0IHdlIHNob3VsZCBmaXJzdCB3b3JrIG9u IGEgc2VjdXJpdHkgYW5hbHlzaXMgb2YgaG9zdCBpZGVudGlmaWVycy4NCj4NCj4gU28gSSBzdWdn ZXN0IGhhdmluZw0KPg0KPg0KPiBUaHJlYXQgYW5hbHlzaXMNCj4gYXMgdGhlIGZpcnN0IHN0ZXAu DQo+DQo+IElzIHRoZXJlIGEgZHJhZnQgdGhhdCBjb3ZlcnMgc2ltaWxhciBpc3N1ZXM/IE1heWJl IHdlIGNhbiBzdGFydCB3aXRoIHRoYXQuIE90aGVyd2lzZSB3ZSBkaXNjdXNzIHdpdGggdGhlIGlu dGVudCBvZiBvdXRwdXR0aW5nIGEgZHJhZnQuDQo+DQo+IFJlZ2FyZHMsDQo+DQo+IEJlaGNldA0K Pg0KPiBPbiBUaHUsIE9jdCAzMCwgMjAxNCBhdCAyOjM1IFBNLCBCZWhjZXQgU2FyaWtheWEgPHNh cmlrYXlhMjAxMkBnbWFpbC5jb20+IHdyb3RlOg0KPj4gIEhpIGFsbCwNCj4+DQo+PiBJIHRyaWVk IHRvIGRyZXNzIHVwIHRoaW5ncyB0byBkbyBpbiBob3N0aWQgYmVsb3cgYXMgZm9sbG93czoNCj4+ DQo+PiAtIHJlcXVpcmVtZW50cw0KPj4NCj4+IC0gdXBkYXRlZCBzb2x1dGlvbiBhbmFseXNpcw0K Pj4NCj4+IC0gc29sdXRpb24ocykgZ2l2ZW4gdGhlIGZhY3QgdGhhdCB3ZSBoYXZlIGRpdmVyc2Ug c2V0IG9mIHVzZSBjYXNlcywNCj4+IG9uZSBzaXplIGZpdHMgYWxsIHR5cGUgb2YgYSBzaW5nbGUg c29sdXRpb24gbWF5IG5vdCBiZSB0aGUgd2F5IHRvIGdvLg0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0K Pj4gQmVoY2V0DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IGhpYXBzIG1haWxpbmcgbGlzdA0KPiBoaWFwc0BpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2hpYXBzDQo= From nobody Wed Nov 12 11:31:24 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 9AD631A6F2D for ; Wed, 12 Nov 2014 11:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuS1EZBDgg4L for ; Wed, 12 Nov 2014 11:31:16 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 583241A19E8 for ; Wed, 12 Nov 2014 11:31:16 -0800 (PST) Received: by mail-yk0-f178.google.com with SMTP id 79so1349158ykr.37 for ; Wed, 12 Nov 2014 11:31:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=/pjxpMXg2Ota9HSP8o1hJ+BSn8dz7YOOm/j+jjNs2Dg=; b=Rr/g4yPL87HeznM+krQIfn+6vOT/WpJpgEqVx2VbaSX1ZEkOYDzZdRvFI/ngjZOeqB SF0BDhh5c/woC7iG6IBtmLk273xzslRIhu01Iz1WrkmFkkpQ+EDRW34v0zBjbf0Tv6PB hurfltRL0EurtrXBca6Ou61zS0J0wMIkV2f0ZC5AYXE7j+PYD6BmYvu2IJgAiuFbty/1 pzhXcumVXQogYyQ1hcdgzkh0rQf5MLR1hBxIfRAbgVYJ+7seYoXjZPniP4zLLHOo8D3/ KaqGWG1CdcDeYy0Kv7AozUKIttGC09oR0J1QYBguxaXw43qdJ0dIriOoeefLlbrF1sZA l3WQ== MIME-Version: 1.0 X-Received: by 10.236.202.232 with SMTP id d68mr4838182yho.113.1415820675710; Wed, 12 Nov 2014 11:31:15 -0800 (PST) Received: by 10.170.71.198 with HTTP; Wed, 12 Nov 2014 11:31:15 -0800 (PST) Date: Wed, 12 Nov 2014 13:31:15 -0600 Message-ID: From: Behcet Sarikaya To: "hiaps@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/0l73vMcT3di2k3vtwFVD3ezGDJo Subject: [hiaps] REMINDER Side Meeting 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: Wed, 12 Nov 2014 19:31:20 -0000 Please note that Side meeting will take place today at 11:45 - 12:30 Room: Lehua which is around the registration area in Mid-Pacific conference center.. See you all there. Regards, Behcet From nobody Thu Nov 13 13:26: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 5DB891AD5F9 for ; Thu, 13 Nov 2014 13:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZsZ5NYEsAWq for ; Thu, 13 Nov 2014 13:26:37 -0800 (PST) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 246301AD637 for ; Thu, 13 Nov 2014 13:24:45 -0800 (PST) Received: by mail-yh0-f47.google.com with SMTP id f73so246036yha.6 for ; Thu, 13 Nov 2014 13:24:44 -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:content-transfer-encoding; bh=vMkf9+KrK522iQS2uPjVjqj/4r7VM9aWOkguHLmdiRg=; b=pPGZbcHcUXitOnMgj5fXBQeUPbRAPun6ZeTHa1mNhDu7bwo4otcNro0FPOUew29hgO odBDPwRt66GaCdtfdvDY14phWGnPwQsvh4FnSYTqsjsxp1pKCHvCPVlOEXjkIiGANEbr P1t3ho/vFsxPIzWQLxu4lN+eYFZLNuv/AAO/xmSA6huVRXKurAgXPSW1gI/3+aa6oDW7 gN82cCGa1KrgGWKTjwOT8d48nHRDz44MNS/F4gT1aNUu4k0ltLky827kx6rJldKl8iVz d3wh0MeXjW0z/cIm6+jFzdLj+osqTooOacS9dNFGLKTTEc6Gz/v3/KIy7Do/rqvsk8ua 1eXw== MIME-Version: 1.0 X-Received: by 10.170.115.132 with SMTP id h126mr5871355ykb.2.1415913884434; Thu, 13 Nov 2014 13:24:44 -0800 (PST) Received: by 10.170.71.198 with HTTP; Thu, 13 Nov 2014 13:24:44 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B93301D5310@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93301D5310@OPEXCLILM23.corporate.adroot.infra.ftgroup> Date: Thu, 13 Nov 2014 15:24:44 -0600 Message-ID: From: Behcet Sarikaya To: Mohamed Boucadair Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/P3eWgW-02etxkScNXHKRqbu7qq4 Cc: "hiaps@ietf.org" Subject: Re: [hiaps] Other Built-in Demux Identifiers: The QUIC Approach 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: Thu, 13 Nov 2014 21:26:38 -0000 On Wed, Nov 12, 2014 at 9:28 AM, wrote: > Hi all, > > > > FWIW, QUIC is proposing a unique identifier to demux connections bound to > the same IP address. > > > > =E2=80=9CGiven that NAT services can vary the WAN-visible source-port ove= r the > lifetime of a connection (via unbinding, and rebinding), it is clear that > source-IP address and source-port are strictly insufficient to define a > connection. We overcome any such confusion by using a CID (Connection > IDentifier) which generally persists for the lifetime of the connection. = A > CID is a pseudo randomly generated nonce [size is currently set at 64 bit= s], > that is expected to be universally unique. The CID is usually proposed i= n > the first UDP packet sent by a client to a server, and is present explici= tly > or implicitly in all future packets that are exchanged for the lifetime o= f > the connection. It is the defining key for the connection. > > > > A server can use this CID as a key to identify the specific connection fr= om > among many inbound connections sending UDP packets to a single server por= t. > The CID is also used by the server to resurrect the current session > encryption context for use with AEAD (Authenticated Encryption with > Associated Data). That context conceptually includes an encryption key, = as > well as an authentication key. (Note: mutable portions of the packet, su= ch > as source-port, etc., are not included in the Associated Data > authentication).=E2=80=9D > > > > More information can be found here: > https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRF= UoVD34/mobilebasic?pli=3D1 > > > > Note CID is universally unique. > Yes but QUIC is designed as connection identifier and as such it does not seem to be appropriate to use it as host identifier. Regards, Behcet > > > Cheers, > > Med > > > _______________________________________________ > hiaps mailing list > hiaps@ietf.org > https://www.ietf.org/mailman/listinfo/hiaps > From nobody Thu Nov 13 17:50:39 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 E05201A015F for ; Thu, 13 Nov 2014 17:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Wts-o4gBS6Y for ; Thu, 13 Nov 2014 17:50:30 -0800 (PST) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D90711A000B for ; Thu, 13 Nov 2014 17:50:29 -0800 (PST) Received: by mail-yh0-f42.google.com with SMTP id b6so8558432yha.29 for ; Thu, 13 Nov 2014 17:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=2JMiBD1MMU2jqf5vRE/FFRvtsQV3jmMTUi20/NnjPKY=; b=YtV/ka6N9vidOi0Z9YKS55Zx0iRroRERGAM0uS/Vlce8MUZteKpYoPAZXOrwDeGmJy Q3AUQ9KBMfFJvmB/w0uQ1iiJx56KErpaM3rX/PMokUhIBRNpX41oYVDLPYfcHRZ1cA9H 4f1QkKUNOY/gJp1ggDr6MZkp/s0SeyRrCgAt30DmRppnvKDmtBTFm1rIc2w/hxxbGvIk AzwNJuFD/zJdb/AXw5+iJ96VZFfkGYcamnbGWyIRBoPbUpUPNpGcA+WtH10Yx54wy96P wfKzN+brnUviAiwBNEmTrSKcAJpgVpA/V8P5EH+P5wGWlzJJ1gXHivPoDjzKfH1CiFFH /jLQ== MIME-Version: 1.0 X-Received: by 10.236.47.195 with SMTP id t43mr6922274yhb.33.1415929829204; Thu, 13 Nov 2014 17:50:29 -0800 (PST) Received: by 10.170.71.198 with HTTP; Thu, 13 Nov 2014 17:50:29 -0800 (PST) Date: Thu, 13 Nov 2014 19:50:29 -0600 Message-ID: From: Behcet Sarikaya To: Mohamed Boucadair Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/6k5_a-1PqW_IuU5MYCLhqkn-taY Cc: joel jaeggli , "hiaps@ietf.org" , Dan Wing , Brandon Williams , "Dirk.von-Hugo@telekom.de" Subject: [hiaps] Side meeting 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, 14 Nov 2014 01:50:32 -0000 Hi all, Regarding the side meeting, we had a chat with Dan Wing, Tiru, et al. It seems like host id/address activity should better direct itself towards out-of-band solutions rather than inband as discussed in RFC 6967. Out-of-band solutions can avoid a lot of the issues IETF is concerned about and may give us an opportunity to do consensus oriented work. Of course the applicability of such an out-of-band solution could be a bit limited but I think that the solution could be OK for most of the use cases we have. So I wanted to start a discussion on this direction. Regards, Behcet From nobody Thu Nov 13 19:29:17 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 D5E2A1A6EE7 for ; Thu, 13 Nov 2014 19:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.795 X-Spam-Level: X-Spam-Status: No, score=-14.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 WxuHuxqGF82K for ; Thu, 13 Nov 2014 19:29:13 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B40881A6EF2 for ; Thu, 13 Nov 2014 19:29:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=866; q=dns/txt; s=iport; t=1415935754; x=1417145354; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=B3ULWmK1g0zWVDxRm8n4RlRpIUgu629+Lk88nY2DvFQ=; b=WLOMQbV0NlOTA9YBO79vcoL/PKqcJBTXlrV9MMMgzBsHIZSR/tcv69+m lX3BK/Z3fLc+qtDKJ3H3OCpt/iNt5QD5pvuE3xjyZkIyTS06PF/oK3SEq lzslq0uPHSs0rhD94PEYOcbifZTWVYw7wjys8gjgrtX6oTXZ2Ge2F9FDQ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAFR2ZVStJV2Q/2dsb2JhbABbgw5VWc0Fh04CgSEWAQEBAQF9hAMBAQMBOj8FCwtGITYZG4gRAwkJDcoHDYZYAQEBAQEBAQMBAQEBAQEBFwSOZIFmJTMHFoMXgR4FlyKFF4ITkAWGdYQgGTABgQWBRQEBAQ X-IronPort-AV: E=Sophos;i="5.07,382,1413244800"; d="scan'208";a="96514925" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-2.cisco.com with ESMTP; 14 Nov 2014 03:29:13 +0000 Received: from sjc-vpn2-249.cisco.com (sjc-vpn2-249.cisco.com [10.21.112.249]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sAE3T9DP024698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Nov 2014 03:29:10 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Thu, 13 Nov 2014 17:29:07 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/Iyxm70pf5LHoxJ5Ta2eeRt33fgg Cc: joel jaeggli , "hiaps@ietf.org" , Mohamed Boucadair , Brandon Williams , "Dirk.von-Hugo@telekom.de" Subject: Re: [hiaps] Side meeting 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, 14 Nov 2014 03:29:15 -0000 On Nov 13, 2014, at 3:50 PM, Behcet Sarikaya = wrote: > Hi all, >=20 > Regarding the side meeting, we had a chat with Dan Wing, Tiru, et al. > It seems like host id/address activity should better direct itself > towards out-of-band solutions rather than inband as discussed in RFC > 6967. RFC6967 describes an out-of-band mechanism in its Section 4.9, = https://tools.ietf.org/html/rfc6967#section-4.9 -d > Out-of-band solutions can avoid a lot of the issues IETF is concerned > about and may give us an opportunity to do consensus oriented work. >=20 > Of course the applicability of such an out-of-band solution could be a > bit limited but I think that the solution could be OK for most of the > use cases we have. >=20 > So I wanted to start a discussion on this direction. >=20 > Regards, >=20 > Behcet From nobody Fri Nov 14 11:35: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 888591A8F44 for ; Fri, 14 Nov 2014 11:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B89-k9a4yqSq for ; Fri, 14 Nov 2014 11:35:42 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587131A8F40 for ; Fri, 14 Nov 2014 11:35:42 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id rl12so18767555iec.10 for ; Fri, 14 Nov 2014 11:35:41 -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:content-transfer-encoding; bh=ctf5oab1+ifqwB5zNMlTxlBQPkxPiQu3K5MxEDurZUk=; b=HTNKBevGVMxikeclEdnnT8lm0tpttmFey0Z0zJ/AUT8nofZhelN1HMhR8d8+YmWkFc gibP9yQ4MHC3weKZB+9qJIFKfTbnf2NtZp0LGNN492hKNzWj3fPoXXra2JQojtngMKxV wZeMkO22o5jcK8uFuo0YLOccqPkmpkuGXWOYSP5cB0Y9I/El4M6uMoZfPQK4Jvkn6dha IvJIzNLcFHW5w1rPRjWQkBE+RQhqD4w2uM2fRCvqe567SeTJEC8nMoCROWAfE1ME+rGp E4f+a8qIN/qCIkutrWuLZbSvkb+fzsQQ0osAQgBAD7DGZZAdHEqMmEdTuvRxdBVyNO+P yu3w== MIME-Version: 1.0 X-Received: by 10.50.111.226 with SMTP id il2mr8308938igb.10.1415993741629; Fri, 14 Nov 2014 11:35:41 -0800 (PST) Received: by 10.107.40.17 with HTTP; Fri, 14 Nov 2014 11:35:41 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Nov 2014 13:35:41 -0600 Message-ID: From: Behcet Sarikaya To: =?UTF-8?B?8J+Uk0RhbiBXaW5n?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/ht0H-DHhxQvTSSDLb04brLqD2u8 Cc: joel jaeggli , "hiaps@ietf.org" , Mohamed Boucadair , Brandon Williams , "Dirk.von-Hugo@telekom.de" Subject: Re: [hiaps] Side meeting 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, 14 Nov 2014 19:35:44 -0000 On Thu, Nov 13, 2014 at 9:29 PM, =F0=9F=94=93Dan Wing wro= te: > > On Nov 13, 2014, at 3:50 PM, Behcet Sarikaya wro= te: > >> Hi all, >> >> Regarding the side meeting, we had a chat with Dan Wing, Tiru, et al. >> It seems like host id/address activity should better direct itself >> towards out-of-band solutions rather than inband as discussed in RFC >> 6967. > > RFC6967 describes an out-of-band mechanism in its Section 4.9, https://to= ols.ietf.org/html/rfc6967#section-4.9 > Yes. The discussion is too ident centric and ident is tcp based. I think there is a lot to do in this area. Regards, Behcet > -d > >> Out-of-band solutions can avoid a lot of the issues IETF is concerned >> about and may give us an opportunity to do consensus oriented work. >> >> Of course the applicability of such an out-of-band solution could be a >> bit limited but I think that the solution could be OK for most of the >> use cases we have. >> >> So I wanted to start a discussion on this direction. >> >> Regards, >> >> Behcet > From nobody Wed Nov 19 10:21:57 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 2E27D1A19FC for ; Wed, 19 Nov 2014 10:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOZpfN3mPl-o for ; Wed, 19 Nov 2014 10:21:54 -0800 (PST) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4F31A0006 for ; Wed, 19 Nov 2014 10:21:54 -0800 (PST) Received: by mail-yh0-f43.google.com with SMTP id z6so545702yhz.30 for ; Wed, 19 Nov 2014 10:21:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=VSuErYSW8owdOymzN9yxSb7aptmd0/rAYQI4vIO5ivM=; b=WNkmEiBC2cxeYW18Tgd4EFNOb9/hqVcib/9Rz2CbxnQk/xtnyBWvJpNkyVVnqySAYa +5U+CwDmN+bjtJWs6eeCTI9Y+U4jRZAexawAifGpCdH7GFPa4Hwy1J/E4SX5n+57EMkK FFUZrFJZUUk5jOJPsIzvkyhUS8B8p/s4HbAUuInblDvZT2ATyd/JV/ZYA22t31GanbhV gjTvAb2pfpyQFxV2WSOjGPUhUQBIw0glfAcTNLutJO8j5XrQxsqlCJL0gY8Sn88LeX3m RPZetN40Lx1y890Hf2GNwcOeIJUaXxiM1CLENi3fKDv1XcLUvuSPdRkxUE5B+tQIuHA0 OQTw== MIME-Version: 1.0 X-Received: by 10.170.214.6 with SMTP id g6mr19862156ykf.34.1416421313921; Wed, 19 Nov 2014 10:21:53 -0800 (PST) Received: by 10.170.71.198 with HTTP; Wed, 19 Nov 2014 10:21:53 -0800 (PST) Date: Wed, 19 Nov 2014 12:21:53 -0600 Message-ID: From: Behcet Sarikaya To: "hiaps@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/hiaps/8xds4t0rttzgmpEUe66RdPwlAok Subject: [hiaps] Service Function Chaining and Host Address/Id 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: Wed, 19 Nov 2014 18:21:56 -0000 Hi all, Host Address/Id issue is coming up in newer contexts such as Service Function Chaining. For more info, please check this expired draft: https://tools.ietf.org/html/draft-sarikaya-sfc-address-sharing-in-sfc-00 More use cases can be added to the ones reported in the above draft. I think that out-of-band solution approach will also be OK in such contexts. Regards, Behcet