From dwing@cisco.com Wed Aug 1 13:26:25 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA69221F88D5 for ; Wed, 1 Aug 2012 13:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.484 X-Spam-Level: X-Spam-Status: No, score=-110.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBZf7USMEMMv for ; Wed, 1 Aug 2012 13:26:25 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2CE21F8836 for ; Wed, 1 Aug 2012 13:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1118; q=dns/txt; s=iport; t=1343852785; x=1345062385; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=BICipMU7IgY6xb4NgSWg5Awcfh1xBarz4hrnE9sMtcM=; b=Oxa/VjMpMi/XtYbtYdjjH1Ks8lmao9oGqUJe4oGhDi6usq62KP3JuaII Iqm9fTGVXXJCjF9t8DGjLRYt44kKfBedsvRIejs3n4pqAqRuXNM/wK3Yj IWRi8W1KAmAudJd+gMgANYEmHltSMAdxUNyYuj8MbYEkNSklseaFqwXJk E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFALePGVCrRDoH/2dsb2JhbABFqVqPN4EHgiABAQEECAoBFxA/DAEDAgkPAgQBASgHGSMKCQgCBAESCxAHh2oMnGegQASLSYcJA4hNhQyWFYFmgn8 X-IronPort-AV: E=Sophos;i="4.77,696,1336348800"; d="scan'208";a="51226342" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 01 Aug 2012 20:26:24 +0000 Received: from dwingWS (sjc-vpn7-1177.cisco.com [10.21.148.153]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q71KQO8h003903; Wed, 1 Aug 2012 20:26:24 GMT From: "Dan Wing" To: "'Zhangdacheng \(Dacheng\)'" , References: In-Reply-To: Date: Wed, 1 Aug 2012 13:26:24 -0700 Message-ID: <0a1301cd7023$ebd1bd90$c37538b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNbwnvoZws8buZFUaBTiMDCJuBl5dFaJnQ Content-Language: en-us Cc: 'Margaret Wasserman' Subject: Re: [pcp] About selecting a key management for PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 20:26:26 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Zhangdacheng (Dacheng) > Sent: Tuesday, July 31, 2012 3:51 AM > To: pcp@ietf.org > Cc: Margaret Wasserman > Subject: [pcp] About selecting a key management for PCP > > Hi, All: > > We have a discussion about the selection of a key management mechanism > for PCP, but there is not a conclusion yet. Basically, people focus on > two solutions, using PANA or generating an in-band authenticaiton > mchanism for PCP (actually a simplified PANA). Now, there is a new > draft draft-ohba-pcp-pana-00, which tries to specify the first one. So, > maybe it is the right time to raise this disucssion again and decide > the key management solution for PCP eventually. Yes, we need to conclude on the PCP authentication mechanism. I have high hopes for the comparison of approaches that is in PCP's agenda, https://datatracker.ietf.org/meeting/84/agenda/pcp, 1555-xxxx Comparison of PCP Authentication approaches (Margaret Wasserman, ??) Document: draft-ietf-pcp-authentication-00 -d From alper.yegin@yegin.org Thu Aug 2 05:32:20 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFD721F8A1D for ; Thu, 2 Aug 2012 05:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXfhYJMD0I0P for ; Thu, 2 Aug 2012 05:32:20 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 0855E21F88C4 for ; Thu, 2 Aug 2012 05:32:20 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Lnxom-1TPdgW0oS8-00gObw; Thu, 02 Aug 2012 08:32:12 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: Date: Thu, 2 Aug 2012 15:32:06 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0096E801-3D17-4751-981A-67A46B96F739@yegin.org> References: To: Zhangdacheng (Dacheng) X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:GMw2YNkCZyB1wA5itlfjnuQmueOqsJRhT8mWp6rkZtf xFgWRTwwbaVEDWT6zELIEXkP+rtk5AoNZjefWQ96DwUVfz66eT 0lq5pBBRomkjb/Vzayp2YR7EmUH5faqxsRECOrVG/4cdZp1S2R W+JCLI5FJEEY15+4vC6Yhg3D9oQb17YgtrIHm/ZHRm46wPnxmD 0UGKZsY7qynoXCS3AL9dpxf+fD8OGHKzYoAjyE2n5mQ6s+8w+M EhnTIsM7ChYIL4wXZKVSn8DETfV0Ugurp1FvImkl2sE5DorNM6 azmOWkRyTVK260NrRRYwiaqmO0WLaSZZvzWfRSFA9VR7cLKo/H a/kUDcIiUzeng044z1lxk1V7/z/HQKvhWAovadb3FTUZwuvGrT +t2BJT0qQl72w== Cc: Margaret Wasserman , "pcp@ietf.org" Subject: Re: [pcp] About selecting a key management for PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 12:32:20 -0000 > an in-band authenticaiton mchanism for PCP (actually a simplified = PANA). It's not simplified=85. It's basically growing PANA (an EAPoUDP = transport) within PCP. A redundant work that'd result in more complexity = than keeping two simple protocols separate. This "oh I'll just carry EAP = over my favorite protocol (e.g., DHCP!), and it'd be sooo simple" was = tried before and failed miserably. PCP and its key management are two = separate issues that deserve two separate protocols (similar to IKE and = IPsec being separate). I don't see any value in cobbling them up, which = is more like a PPP-style approach -- all-in-one.=20 Alper On Jul 31, 2012, at 1:50 PM, Zhangdacheng (Dacheng) wrote: > Hi, All: >=20 > We have a discussion about the selection of a key management mechanism = for PCP, but there is not a conclusion yet. Basically, people focus on = two solutions, using PANA or generating an in-band authenticaiton = mchanism for PCP (actually a simplified PANA). Now, there is a new draft = draft-ohba-pcp-pana-00, which tries to specify the first one. So, maybe = it is the right time to raise this disucssion again and decide the key = management solution for PCP eventually. >=20 > Cheers >=20 > Dacheng > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From zhangdacheng@huawei.com Thu Aug 2 07:58:42 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD5B11E80C5 for ; Thu, 2 Aug 2012 07:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=-3.823, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxKHwUsx9pkk for ; Thu, 2 Aug 2012 07:58:42 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id F0F4111E8072 for ; Thu, 2 Aug 2012 07:58:41 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIQ11316; Thu, 02 Aug 2012 06:58:41 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 2 Aug 2012 07:56:53 -0700 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 2 Aug 2012 07:56:58 -0700 Received: from SZXEML528-MBX.china.huawei.com ([169.254.4.120]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Thu, 2 Aug 2012 22:56:52 +0800 From: "Zhangdacheng (Dacheng)" To: Alper Yegin Thread-Topic: [pcp] About selecting a key management for PCP Thread-Index: AQHNbwnvoZws8buZFUaBTiMDCJuBl5dF8XcAgACsKsI= Date: Thu, 2 Aug 2012 14:56:51 +0000 Message-ID: References: , <0096E801-3D17-4751-981A-67A46B96F739@yegin.org> In-Reply-To: <0096E801-3D17-4751-981A-67A46B96F739@yegin.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.45] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Margaret Wasserman , "pcp@ietf.org" Subject: [pcp] =?gb2312?b?tPC4tDogIEFib3V0IHNlbGVjdGluZyBhIGtleSBtYW5hZ2Vt?= =?gb2312?b?ZW50IGZvciBQQ1A=?= X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 14:58:42 -0000 Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kt6K8/sjLOiBBbHBlciBZ ZWdpbiBbYWxwZXIueWVnaW5AeWVnaW4ub3JnXQq3osvNyrG85DogMjAxMsTqONTCMsjVIDIwOjMy CrW9OiBaaGFuZ2RhY2hlbmcgKERhY2hlbmcpCkNjOiBwY3BAaWV0Zi5vcmc7IE1hcmdhcmV0IFdh c3Nlcm1hbgrW98ziOiBSZTogW3BjcF0gQWJvdXQgc2VsZWN0aW5nIGEga2V5IG1hbmFnZW1lbnQg Zm9yIFBDUAoKPiBhbiBpbi1iYW5kIGF1dGhlbnRpY2FpdG9uIG1jaGFuaXNtIGZvciBQQ1AgKGFj dHVhbGx5IGEgc2ltcGxpZmllZCBQQU5BKS4KCgo+SXQncyBub3Qgc2ltcGxpZmllZKGtLiBJdCdz IGJhc2ljYWxseSBncm93aW5nIFBBTkEgKGFuIEVBUG9VRFAgdHJhbnNwb3J0KSB3aXRoaW4gUENQ LiBBIHJlZHVuZGFudCB3b3JrIHRoYXQnZCA+cmVzdWx0IGluIG1vcmUgY29tcGxleGl0eSB0aGFu IGtlZXBpbmcgdHdvIHNpbXBsZSBwcm90b2NvbHMgc2VwYXJhdGUuIFRoaXMgIm9oIEknbGwganVz dCBjYXJyeSBFQVAgb3ZlciBteSBmYXZvcml0ZSA+cHJvdG9jb2wgKGUuZy4sIERIQ1AhKSwgYW5k IGl0J2QgYmUgc29vbyBzaW1wbGUiIHdhcyB0cmllZCBiZWZvcmUgYW5kIGZhaWxlZCBtaXNlcmFi bHkuICBQQ1AgYW5kIGl0cyBrZXkgPm1hbmFnZW1lbnQgYXJlIHR3byBzZXBhcmF0ZSBpc3N1ZXMg dGhhdCBkZXNlcnZlIHR3byBzZXBhcmF0ZSBwcm90b2NvbHMgKHNpbWlsYXIgdG8gSUtFIGFuZCBJ UHNlYyBiZWluZyA+c2VwYXJhdGUpLiBJIGRvbid0IHNlZSBhbnkgdmFsdWUgaW4gY29iYmxpbmcg dGhlbSB1cCwgd2hpY2ggaXMgbW9yZSBsaWtlIGEgUFBQLXN0eWxlIGFwcHJvYWNoIC0tIGFsbC1p bi1vbmUuCgoKCk1heWJlIG15IGJhZCBFbmdsaXNoIGNhdXNlcyBjb25mdXNpb24uIFNvcnJ5IGZv ciB0aGF0LiBUaGUgInNpbXBsaWZpZWQiIGhlcmUgbWVhbnMgd2UgY2FuIHJlbW92ZSB0aGUgcmVk dW5kYW50IGZ1bmN0aW9ucyBvZiBQQU5BIGFuZCBvbmx5IGtlZXAgdGhlIG5lY2Vzc2FyeSBwYXJ0 LiBUaGF0IGlzIGV4YWN0bHkgd2hhdCB3ZSBhcmUgdHJ5aW5nIHRvIGRvIGluIHRoZSBwY3AgYXV0 aGVudGljYXRpb24gZHJhZnQuCgpJbiBhZGRpdGlvbiwgeW91IHJlbWluZCBtZSBvbmUgdGhpbmcu IEthcnAgV0cgaXMgdHJ5aW5nIHRvIHVzZSBJS0V2MiB0byBwcm92aWRlIGtleSBtYW5hZ2VtZW50 IGZvciB1bmljYXN0IHJvdXRpbmcgcHJvdG9jb2xzLiBJZiBvdXIgV0cgZGVjaWRlIHRvIHNlbGVj dCBhIHNlcGVyYXRlZCBBS00gc29sdXRpb24uIERvIHlvdSB0aGluayBpdCBpcyBhIGdvb2QgaWRl YSB0byBib3Jyb3cgdGhlaXIgd29yayB0byBzZWN1cmUgUENQPwoKQ2hlZXJzCgpEYWNoZW5nCgpB bHBlcgoK From alper.yegin@yegin.org Thu Aug 2 14:09:42 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BAD11E814B for ; Thu, 2 Aug 2012 14:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jbm+5LFUee+R for ; Thu, 2 Aug 2012 14:09:41 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 1535A11E814E for ; Thu, 2 Aug 2012 14:09:41 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MQROe-1TMDyc0oyS-00UTXY; Thu, 02 Aug 2012 17:09:39 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=GB2312 From: Alper Yegin In-Reply-To: Date: Fri, 3 Aug 2012 00:09:19 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1F8B57B5-BE4D-44C5-BA3A-E0EC3BA7FFCD@yegin.org> References: , <0096E801-3D17-4751-981A-67A46B96F739@yegin.org> To: "Zhangdacheng (Dacheng)" X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:JLdD6cX1a66dWu33pqzGYm2xGElTTTDVXpHa4T66N/B f4rKkBCnDhMYDsA9SOFQQhHLhy1nfm+myVp/l/+HFSZCnudhvr +2Z0qsAjNxWvHQwsUOPaJju+hmOmtJ2ntHxsQhL1CJjBguhVrj 1ZfKY/yMwdjMfjW7Ue5nx2yzFuDpVnk7ZYqPOCikX64bzlIyCW eqlZqQhgE3gYepv/40zXWfGouBWKAh7KWKiyM9AO6q17MIsany 7Wd0TtDYSemsMo8mrcpN1BM33GJfDFqAMrehaPA7hlBxFUe5Mp 5JRnIdNBYHXWIXdD8POIxXHwTEOm6KSOnP3g9Sf0j4EIcsCzgh DtutZPOQcgBtU3BEYcvNyPcipgBAHtMS8wMz/oN3KOqBC+pMdt ygPfmOmDzQkyQ== Cc: Margaret Wasserman , "pcp@ietf.org" Subject: Re: [pcp] About selecting a key management for PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:09:42 -0000 >> an in-band authenticaiton mchanism for PCP (actually a simplified = PANA). >=20 >=20 >> It's not simplified=A1=AD. It's basically growing PANA (an EAPoUDP = transport) within PCP. A redundant work that'd >result in more = complexity than keeping two simple protocols separate. This "oh I'll = just carry EAP over my favorite >protocol (e.g., DHCP!), and it'd be = sooo simple" was tried before and failed miserably. PCP and its key = >management are two separate issues that deserve two separate protocols = (similar to IKE and IPsec being >separate). I don't see any value in = cobbling them up, which is more like a PPP-style approach -- all-in-one. >=20 >=20 >=20 > Maybe my bad English causes confusion. Sorry for that. The = "simplified" here means we can remove the redundant functions of PANA = and only keep the necessary part. That is exactly what we are trying to = do in the pcp authentication draft. >=20 We can certainly profile PANA to to not use those unnecessary parts = (IP-reconfig bit=A1=AD just a bit, don't use it). > In addition, you remind me one thing. Karp WG is trying to use IKEv2 = to provide key management for unicast routing protocols. If our WG = decide to select a separated AKM > solution. Do you think it is a good idea to borrow their work to = secure PCP? >=20 Sure, it's a candidate. (Though, IMHO, IKEv2 is so IPsec-specific, using = it for keying other protocols is a stretch). Alper > Cheers >=20 > Dacheng >=20 > Alper >=20 From alper.yegin@yegin.org Thu Aug 2 14:31:16 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7C921E8045 for ; Thu, 2 Aug 2012 14:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2t1ABP6wNta for ; Thu, 2 Aug 2012 14:31:15 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 5452521E803A for ; Thu, 2 Aug 2012 14:31:15 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LmK8A-1TVYiw0dzW-00ZvWs; Thu, 02 Aug 2012 17:31:14 -0400 From: Alper Yegin Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_112AFBF4-8E94-46FB-8363-9D57285D5171" Date: Fri, 3 Aug 2012 00:30:56 +0300 In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> To: pcp@ietf.org References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Message-Id: <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:W8KVJR4TyY9Fc3CVU69yQ+aecUEQq063URjF7XLkPnF qgCrjI5uaZL3s3+W8c86oIZztTHs8ePY23NZZQKF+Tiuv+cWA2 oCl3Ll3iXjGg01xhxZv/7f3KTeZmk+U67BugE47gp6GoWMCa6t K/6PTkyuaZeO+/VXC/WthEwUHOuDgmzPoxgqfX7RHTP5I9Swun 9fVDFeyTQnjpiEHIV5PaV/sCNAswr+PlsKvhPz9XQvqMBfCdZ4 GMWXm+zt/XNYsGgqe5m+W8aJnWWcJ8V9g1wI1Li+tFp5JUTi33 8eB+VFfRKNf1grf06wkA5wFaCeFb2ij/9emPUBd5hzDO2U85Xw 7VQUY0UwJ3Lj8Z+2wa6pKislJpPucKiyOCylsb6QrlyLqMVKcj AzDC6NVyZn7jA== Subject: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:31:16 -0000 --Apple-Mail=_112AFBF4-8E94-46FB-8363-9D57285D5171 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 http://www.ietf.org/proceedings/84/slides/slides-84-pcp-10.pdf Ah, isn't it odd that this beauty contest is run by one of the = contestants? This material should have been prepared and presented by a = neutral party.=20 One important question: With this proposal, are the authors advocating = each protocol should come with their own in-band key management, more = specifically embedding an EAP transport? > what's the big deal of using the same port vs different port? Is = jamming all in the same port is a benefit? > "TLS is in-band" - There's standalone use of TLS as "a separate" KMP. RFC 5705 is driven = by the fact that some other protocols need to use TLS as a "separate = KMP".=20 - TLS is basically "transport layer security", something that sits below = the protocol one would be trying to secure. We are not doing that. =20 > are the EAP and PCP state machines compatible? If marrying two = protocols, one needs to pay attention to this. This was one of the = reasons why EAPoDHCP did not work. > Does the EAP-over-PCP satisfy the "EAP lower layer requirements" as = stated in RFC 3848? I had asked this question but don't remember seeing = any response. > "Possible in-band optimization". Is this documented anywhere? It's not = easy to understand how it works by looking at this slide. > PANA RFC 5191 was published in 2008, not 2011. It's adopted by Zigbee = IP, ETSI TISPAN, and also ETSI M2M. Aside from two open-source = implementations, multiple commercial implementations have successfully = passed interop events in Zigbee Alliance.=20 >=20 Need to specify the portions of PANA that don=92t need to be implemented in a PCP PANA Client and Server (such as IP Address reconfiguration) >> this is just a single bit flag. We don't use it, and that's all we = need to do about it. Need to specify/describe interface between PANA and PCP elements >> this is an implementation issue, like how the other spec implementors = would need to define the interface between the EAP and PCP for passing = keys, etc. Need to specify how the PANA client finds the correct PANA Server for = PCP Authentication (may be passed from PCP client?) >> PCP server the the PAA are the same node. =20 --Apple-Mail=_112AFBF4-8E94-46FB-8363-9D57285D5171 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Ah, isn't it odd that this beauty contest is run by one of = the contestants? This material should have been prepared and presented = by a neutral party. 

One important question: = With this proposal, are the authors advocating each protocol should come = with their own in-band key management, more specifically embedding an = EAP transport?


> what's the = big deal of using the same port vs different port? Is jamming all in the = same port is a benefit?

> "TLS is = in-band"

- There's standalone use of TLS as "a = separate" KMP. RFC 5705 is driven by the fact that some other protocols = need to use TLS as a "separate KMP". 
- TLS is basically = "transport layer security", something that sits below the protocol one = would be trying to secure. We are not doing that. =  


> are the EAP and PCP = state machines compatible? If marrying two protocols, one needs to pay = attention to this. This was one of the reasons why EAPoDHCP did not = work.

> Does the EAP-over-PCP satisfy the = "EAP lower layer requirements" as stated in RFC 3848? I had asked this = question but don't remember seeing any = response.

> "Possible in-band optimization". = Is this documented anywhere? It's not easy to understand how it works by = looking at this slide.

> PANA RFC 5191 was = published in 2008, not 2011. It's adopted by Zigbee IP, ETSI TISPAN, and = also ETSI M2M. Aside from two open-source implementations, multiple = commercial implementations have successfully passed interop events in = Zigbee Alliance. 

> 
=09 =09 =09
  • Need to specify the portions of PANA that don=92t need to be = implemented

    in a PCP PANA Client = and Server (such as IP Address reconfiguration)

    Need to specify/describe interface = between PANA and PCP elements

    >> this is an implementation = issue, like how the other spec implementors would need to define the = interface between the EAP and PCP for passing keys, = etc.

  • Need to specify how the PANA = client finds the correct PANA Server for PCP Authentication (may be passed from PCP = client?)

    >> PCP server the the PAA are the = same node.




     

=



= --Apple-Mail=_112AFBF4-8E94-46FB-8363-9D57285D5171-- From mrw@lilacglade.org Thu Aug 2 15:35:00 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B60421F8A7B for ; Thu, 2 Aug 2012 15:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.748 X-Spam-Level: X-Spam-Status: No, score=-95.748 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2jYobOLBX+9 for ; Thu, 2 Aug 2012 15:34:57 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-76-251.compute-1.amazonaws.com [23.21.76.251]) by ietfa.amsl.com (Postfix) with ESMTP id A3F5C21F8A77 for ; Thu, 2 Aug 2012 15:34:57 -0700 (PDT) Received: from dhcp-16b6.meeting.ietf.org (permutation-city.suchdamage.org [69.25.196.28]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 3B12E20020; Thu, 2 Aug 2012 18:34:06 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-28-567469001 From: Margaret Wasserman In-Reply-To: <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> Date: Thu, 2 Aug 2012 18:34:48 -0400 Message-Id: <059E1EA3-AEBC-43A6-B76A-9AEDBA55286F@lilacglade.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 22:35:00 -0000 --Apple-Mail-28-567469001 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Alper, I am not entirely clear on what parts of these messages came from you or = what parts you are replying to... If I miss something you would like me = to answer, please let me know. On Aug 2, 2012, at 5:30 PM, Alper Yegin wrote: > http://www.ietf.org/proceedings/84/slides/slides-84-pcp-10.pdf >=20 > Ah, isn't it odd that this beauty contest is run by one of the = contestants? This material should have been prepared and presented by a = neutral party.=20 There was a meeting between the available authors of both drafts this = morning, and we worked together to make the slides reflect a fair = comparison of the two approaches. > One important question: With this proposal, are the authors advocating = each protocol should come with their own in-band key management, more = specifically embedding an EAP transport? With which proposal? I do, personally, think it is valid that there would be several = different protocols that use EAP directly for authentication. I think = there already are... > > what's the big deal of using the same port vs different port? Is = jamming all in the same port is a benefit? Having a protocol that relies on two ports (like the PCP Port and a PANA = port) is more complex, operationally, because it requires that any = intermediate firewalls or middleboxes be configured to pass both = protocols in order for authenticated PCP to function properly. =20 No one has indicated that this is a big deal, as far as I know. It is = one specific difference between two proposals that are, in many ways, = quite similar. There are other differences, as well, such as the fact = that PANA has running code and the non-EAP portions of the in-band = approach do not. Need to specify the portions of PANA that don=92t need to be implemented >=20 > in a PCP PANA Client and Server (such as IP Address reconfiguration) >=20 > >> this is just a single bit flag. We don't use it, and that's all we = need to do about it. One of the questions I have is: What happens if a PANA Client that is trying to get authentication for = PCP talks to a PANA Server that does Network Access authentication but = _not_ PCP authentication... The newest proposal (draft-ohba) does not = indicate that any flag or value will be included in the PANA = authentication request that indicates that the request is for Network = Access authentication or PCP Authentication, so how will the PANA server = know which to authenticate, and how will the client know what it has = been authenticated _for_? > Need to specify/describe interface between PANA and PCP elements >=20 > >> this is an implementation issue, like how the other spec = implementors would need to define the interface between the EAP and PCP = for passing keys, etc. >=20 Even in the case (as described in draft-ohba) where these elements run = on a single system, it is necessary to specify what information is = passed between these elements and what portion of it is passed in the = PCP authentication options. This is necessary, in order to ensure that = the PANA authentication is properly bound to a PCP request. Without = specifying that information, it isn't possible to know that a particular = PCP request/response has been properly bound to a particular PANA = authentication. > Need to specify how the PANA client finds the correct PANA Server for = PCP Authentication (may be passed from PCP client?) > >> PCP server the the PAA are the same node. You have suggested that a huge advantage of using PANA for this = application is that there could be code reuse with existing PANA = implementations. Existing PANA implementations don't find their PAA by = looking at their PCP Server address... They also don't have any notion = (as far as I can tell) of a "client" that is invoking them to initiate = authentication, or of a client and server to whom they should = communicate the security association information after they negotiate = it. If the PCP client does not _tell_ PANA the address of the PCP = Server to which it intends to send a request, how will the PANA client = know? Margaret --Apple-Mail-28-567469001 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Ah, isn't it odd that this beauty contest is run by one of = the contestants? This material should have been prepared and presented = by a neutral party. 

There was a = meeting between the available authors of both drafts this morning, and = we worked together to make the slides reflect a fair comparison of the = two approaches.

One important question: = With this proposal, are the authors advocating each protocol should come = with their own in-band key management, more specifically embedding an = EAP transport?

With which = proposal?

I do, personally, think it is valid = that there would be several different protocols that use EAP directly = for authentication.  I think there already = are...

> what's the big deal of using the same = port vs different port? Is jamming all in the same port is a = benefit?

Having a protocol that = relies on two ports (like the PCP Port and a PANA port) is more complex, = operationally, because it requires that any intermediate firewalls or = middleboxes be configured to pass both protocols in order for = authenticated PCP to function properly. =  

No one has indicated that this is a big = deal, as far as I know.  It is one specific difference between two = proposals that are, in many ways, quite similar.  There are other = differences, as well, such as the fact that PANA has running code and = the non-EAP portions of the in-band approach do not.
Need to specify the portions = of PANA that don=92t need to be implemented
  • in a PCP PANA Client and Server (such as IP Address = reconfiguration)

    >> this is just a single bit flag. We don't = use it, and that's all we need to do about = it.
One of the questions I have = is:

What happens if a PANA Client that is = trying to get authentication for PCP talks to a PANA Server that does = Network Access authentication but _not_ PCP authentication...  The = newest proposal (draft-ohba) does not indicate that any flag or value = will be included in the PANA authentication request that indicates that = the request is for Network Access authentication or PCP Authentication, = so how will the PANA server know which to authenticate, and how will the = client know what it has been authenticated _for_?
  • Need to specify/describe interface = between PANA and PCP elements

    >> this is an implementation = issue, like how the other spec implementors would need to define the = interface between the EAP and PCP for passing keys, = etc.

Even in the = case (as described in draft-ohba) where these elements run on a single = system, it is necessary to specify what information is passed between = these elements and what portion of it is passed in the PCP = authentication options.  This is necessary, in order to ensure that = the PANA authentication is properly bound to a PCP request. =  Without specifying that information, it isn't possible to know = that a particular PCP request/response has been properly bound to a = particular PANA authentication.
  • Need to specify how the PANA client finds the correct PANA = Server for PCP Authentication (may be passed from PCP client?)
  • >> PCP server the the PAA are the = same = node.
You = have suggested that a huge advantage of using PANA for this application = is that there could be code reuse with existing PANA implementations. =  Existing PANA implementations don't find their PAA by looking at = their PCP Server address...  They also don't have any notion (as = far as I can tell) of a "client" that is invoking them to initiate = authentication, or of a client and server to whom they should = communicate the security association information after they negotiate = it.   If the PCP client does not _tell_ PANA the address of the PCP = Server to which it intends to send a request, how will the PANA client = know?

Margaret


= --Apple-Mail-28-567469001-- From tireddy@cisco.com Thu Aug 2 16:09:46 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2332111E8185 for ; Thu, 2 Aug 2012 16:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qJc1NfnfsmM for ; Thu, 2 Aug 2012 16:09:45 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF6611E819F for ; Thu, 2 Aug 2012 16:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=2218; q=dns/txt; s=iport; t=1343948982; x=1345158582; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zlDJ/PuSK2OtB2Vf0ERGr/3ikwbq41DrdAKRrmdWUgs=; b=Is2CkAVl3GBkuPsscJbsdvZQqPmHxgB5q7llEeAFXx6h890rJnpuSL3m wvoNlDwBnNiXrhOVo4HrwjZUtFRQJz7SXEgQSzzRqDrl75RATOkwRHuV4 FHRYL+0/ufrfv6AwZ42y7W8vswsMiUtUXlicFNB6z+lSVkenAyPx/y7i8 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMQHG1CtJV2c/2dsb2JhbABFuRuBB4IgAQEBBAEBAQ8BJzQLDAQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0FCBMHh2sLnHqgQgSLSoYkYAOjboFmgl8 X-IronPort-AV: E=Sophos;i="4.77,703,1336348800"; d="scan'208";a="108023637" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 02 Aug 2012 23:09:42 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q72N9fBq005317 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 23:09:41 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.184]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 18:09:41 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Alper Yegin , Zhangdacheng Thread-Topic: [pcp] About selecting a key management for PCP Thread-Index: AQHNcOC218fvGJ0NYUKgflZIXMWXkZdHIstQ Date: Thu, 2 Aug 2012 23:09:41 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1476F137@xmb-rcd-x10.cisco.com> References: <0096E801-3D17-4751-981A-67A46B96F739@yegin.org> In-Reply-To: <0096E801-3D17-4751-981A-67A46B96F739@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.77.246] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.000 x-tm-as-result: No--56.482000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Margaret Wasserman , "pcp@ietf.org" Subject: Re: [pcp] About selecting a key management for PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:09:46 -0000 Hi - These are couple of questions, I had raised in the meeting 1)If let's say the application is using both STUN and PCP. In STUN it can u= se long term credentials generate key (RFC 5389 section 15.4) This brings in complexity of using two different mechanisms. Is it possible= to make it more flexible ? So that the application can either opt for long term credential approach si= milar to STUN or go with PANA ? 2)How will PCP authentication work b/w PCP proxy and PCP server ? --Tiru. > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Thursday, August 02, 2012 6:32 AM > To: Zhangdacheng > Cc: Margaret Wasserman; pcp@ietf.org > Subject: Re: [pcp] About selecting a key management for PCP >=20 > > an in-band authenticaiton mchanism for PCP (actually a simplified > PANA). >=20 >=20 > It's not simplified.... It's basically growing PANA (an EAPoUDP > transport) within PCP. A redundant work that'd result in more > complexity than keeping two simple protocols separate. This "oh I'll > just carry EAP over my favorite protocol (e.g., DHCP!), and it'd be > sooo simple" was tried before and failed miserably. PCP and its key > management are two separate issues that deserve two separate protocols > (similar to IKE and IPsec being separate). I don't see any value in > cobbling them up, which is more like a PPP-style approach -- all-in- > one. >=20 > Alper >=20 >=20 >=20 > On Jul 31, 2012, at 1:50 PM, Zhangdacheng (Dacheng) wrote: >=20 > > Hi, All: > > > > We have a discussion about the selection of a key management > mechanism for PCP, but there is not a conclusion yet. Basically, people > focus on two solutions, using PANA or generating an in-band > authenticaiton mchanism for PCP (actually a simplified PANA). Now, > there is a new draft draft-ohba-pcp-pana-00, which tries to specify the > first one. So, maybe it is the right time to raise this disucssion > again and decide the key management solution for PCP eventually. > > > > Cheers > > > > Dacheng > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp >=20 From internet-drafts@ietf.org Fri Aug 3 02:46:41 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4FD21F8D59; Fri, 3 Aug 2012 02:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.091 X-Spam-Level: X-Spam-Status: No, score=-102.091 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTnZ2NrCrKQs; Fri, 3 Aug 2012 02:46:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918C921F8D42; Fri, 3 Aug 2012 02:46:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120803094640.5799.608.idtracker@ietfa.amsl.com> Date: Fri, 03 Aug 2012 02:46:40 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-upnp-igd-interworking-02.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 09:46:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Port Control Protocol Working Group of th= e IETF. Title : Universal Plug and Play (UPnP) Internet Gateway Device (= IGD)-Port Control Protocol (PCP) Interworking Function Author(s) : Mohamed Boucadair Francis Dupont Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-upnp-igd-interworking-02.txt Pages : 23 Date : 2012-08-03 Abstract: This document specifies the behavior of the UPnP IGD (Internet Gateway Device)/PCP Interworking Function. An UPnP IGD-PCP Interworking Function (IGD-PCP IWF) is required to be embedded in CP routers to allow for transparent NAT control in environments where UPnP IGD is used in the LAN side and PCP in the external side of the CP router. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-upnp-igd-interworking There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-upnp-igd-interworking-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-upnp-igd-interworking-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Fri Aug 3 02:49:01 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C64221F8D53 for ; Fri, 3 Aug 2012 02:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_RAND_LETTRS4=0.799, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXo7T3GMQt6K for ; Fri, 3 Aug 2012 02:49:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8E92F21F8D4B for ; Fri, 3 Aug 2012 02:49:00 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 6C2132645FD for ; Fri, 3 Aug 2012 11:48:59 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 5495D238056 for ; Fri, 3 Aug 2012 11:48:59 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 3 Aug 2012 11:48:49 +0200 From: To: "pcp@ietf.org" Date: Fri, 3 Aug 2012 11:48:48 +0200 Thread-Topic: [pcp] I-D Action: draft-ietf-pcp-upnp-igd-interworking-02.txt Thread-Index: Ac1xXODfTkU8FxfARgGb/AYQFtAwZwAAAuOg Message-ID: <94C682931C08B048B7A8645303FDC9F36E4BF54C1F@PUEXCB1B.nanterre.francetelecom.fr> References: <20120803094640.5799.608.idtracker@ietfa.amsl.com> In-Reply-To: <20120803094640.5799.608.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.3.71527 Subject: Re: [pcp] I-D Action: draft-ietf-pcp-upnp-igd-interworking-02.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 09:49:01 -0000 Dear all, This version integrates the comments received during the WGLC + some other = corrections.=20 See the diff below for more details. Cheers, Med=20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de internet-drafts@ietf.org >Envoy=E9 : vendredi 3 ao=FBt 2012 11:47 >=C0 : i-d-announce@ietf.org >Cc : pcp@ietf.org >Objet : [pcp] I-D Action: draft-ietf-pcp-upnp-igd-interworking-02.txt > > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. > This draft is a work item of the Port Control Protocol=20 >Working Group of the IETF. > > Title : Universal Plug and Play (UPnP)=20 >Internet Gateway Device (IGD)-Port Control Protocol (PCP)=20 >Interworking Function > Author(s) : Mohamed Boucadair > Francis Dupont > Reinaldo Penno > Dan Wing > Filename : draft-ietf-pcp-upnp-igd-interworking-02.txt > Pages : 23 > Date : 2012-08-03 > >Abstract: > This document specifies the behavior of the UPnP IGD (Internet > Gateway Device)/PCP Interworking Function. An UPnP IGD-PCP > Interworking Function (IGD-PCP IWF) is required to be embedded in CP > routers to allow for transparent NAT control in environments where > UPnP IGD is used in the LAN side and PCP in the external side of the > CP router. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-pcp-upnp-igd-interworking > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-pcp-upnp-igd-interworking-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-upnp-igd-interw >orking-02 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp >= From repenno@cisco.com Fri Aug 3 10:45:10 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B2721F8D60 for ; Fri, 3 Aug 2012 10:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxutv36r16ul for ; Fri, 3 Aug 2012 10:45:10 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0390F21F8D38 for ; Fri, 3 Aug 2012 10:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=1188; q=dns/txt; s=iport; t=1344015906; x=1345225506; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=kk9Nae9fIKJKLWVBXcL+tu1KXuB3KjYGtVRLNPPkFbQ=; b=XQJvnamLKXfZP+N4k0K1vVcFHWWYcmSDktvx6BnXp7sK3W3kWWAuBngM rwUW5RXe8XnnUPRsWkn2MNCVeyiJPDh4xzHzB+7wxpdXAvBoNdf3rTKQ/ emn2X/AkrCca7rXY3nJJdH18u+YREa1r2vVWVvuOs789LhHdY3cTEMnNX g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANMNHFCtJXHB/2dsb2JhbABFuS6BB4InEgEnUQE+QicENYdrmzyBKKAikkwDlUqOJ4Fmgl8 X-IronPort-AV: E=Sophos;i="4.77,707,1336348800"; d="scan'208";a="108292621" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 03 Aug 2012 17:44:51 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q73HimQP020055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 3 Aug 2012 17:44:48 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.162]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Fri, 3 Aug 2012 12:44:47 -0500 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: Comments on draft-ietf-pcp-dhcp-03 Thread-Index: AQHNcZ+sIMSFRn6eBkOpyqHfeftPVA== Date: Fri, 3 Aug 2012 17:44:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.65.204] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.002 x-tm-as-result: No--30.952200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <13649D7BF269C14DB914645C540C1A81@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] Comments on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 17:45:11 -0000 After reviewing draft-ietf-pcp-dhcp-03 I believe there are some things I believe we need to tie up. When a PCP Client contacts PCP Servers in parallel, say, IPx1, IPy1 and IPz1 as mentioned in draft and all respond then: 1 - What happens to the state in y1 and z1 if PCP Client chooses x1 to communicate? Probably let it age out or delete mappings. 2 - If there is a failure on x1 and PCP Client decides to communicate with y1, there might be some 'leftover' mappings for internal IP:port (see 1). PCP Client will need to delete or reuse existing state in y1. Important to notice that there is no way to guarantee that PCP Server will allocate same external IP:ports. 3 - I guess it is assumed that if PCP Server is co-located with NAT, if x1 fails, traffic (PCP and data) will be diverted to y1. 4 - Related (2). The draft says that when a PCP Server is unreachable (say, y1) PCP Client will continue to try to communicate even though other PCP Server are available. The only way to 'communicate' is sending a request, which might create state. So, when y1 is back up. y1 might allocate a different external IP:port than other server. Thanks, Reinaldo From dthaler@microsoft.com Fri Aug 3 10:53:21 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B4021F8E01 for ; Fri, 3 Aug 2012 10:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.595 X-Spam-Level: X-Spam-Status: No, score=-104.595 tagged_above=-999 required=5 tests=[AWL=0.804, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpzMMKsZNIwS for ; Fri, 3 Aug 2012 10:53:20 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 2E09521F8D65 for ; Fri, 3 Aug 2012 10:53:20 -0700 (PDT) Received: from mail212-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 3 Aug 2012 17:53:18 +0000 Received: from mail212-va3 (localhost [127.0.0.1]) by mail212-va3-R.bigfish.com (Postfix) with ESMTP id B659E8C0367; Fri, 3 Aug 2012 17:53:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz9371I542M1432I4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail212-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail212-va3 (localhost.localdomain [127.0.0.1]) by mail212-va3 (MessageSwitch) id 1344016397751114_23828; Fri, 3 Aug 2012 17:53:17 +0000 (UTC) Received: from VA3EHSMHS015.bigfish.com (unknown [10.7.14.253]) by mail212-va3.bigfish.com (Postfix) with ESMTP id A9ACB9E0046; Fri, 3 Aug 2012 17:53:17 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS015.bigfish.com (10.7.99.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 3 Aug 2012 17:53:16 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.309.3; Fri, 3 Aug 2012 17:53:12 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.309.3; Fri, 3 Aug 2012 10:53:12 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Fri, 3 Aug 2012 10:53:12 -0700 From: Dave Thaler To: "Reinaldo Penno (repenno)" , "pcp@ietf.org" Thread-Topic: Comments on draft-ietf-pcp-dhcp-03 Thread-Index: AQHNcZ+sIMSFRn6eBkOpyqHfeftPVJdIXN9Q Date: Fri, 3 Aug 2012 17:53:11 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B7380B2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [pcp] Comments on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 17:53:21 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Reinaldo Penno (repenno) > Sent: Friday, August 03, 2012 10:45 AM > To: pcp@ietf.org > Subject: [pcp] Comments on draft-ietf-pcp-dhcp-03 >=20 > After reviewing draft-ietf-pcp-dhcp-03 I believe there are some things I > believe we need to tie up. I agree. > When a PCP Client contacts PCP Servers in parallel, say, IPx1, IPy1 and > IPz1 as mentioned in draft and all respond then: >=20 > 1 - What happens to the state in y1 and z1 if PCP Client chooses x1 to > communicate? Probably let it age out or delete mappings. What do you mean by "chooses x1"? if we're talking about MAP (for a listening application) do you mean when x, y, and y are all NATs rather than FWs, and the client app can only deal with one external IP address? If they're firewalls (so the external IP address/port isn't different), or if the client app can deal with multiple external IP/ports, then I don't th= ink it would choose one. =20 > 2 - If there is a failure on x1 and PCP Client decides to communicate wit= h y1, > there might be some 'leftover' mappings for internal IP:port (see 1). > PCP Client will need to delete or reuse existing state in y1. Important t= o > notice that there is no way to guarantee that PCP Server will allocate sa= me > external IP:ports. >=20 > 3 - I guess it is assumed that if PCP Server is co-located with NAT, if x= 1 fails, > traffic (PCP and data) will be diverted to y1. Unclear which model you're referring to (different external IP:port or same external IP:port), can you clarify your question? =20 > 4 - Related (2). The draft says that when a PCP Server is unreachable (sa= y, y1) > PCP Client will continue to try to communicate even though other PCP Serv= er > are available. The only way to 'communicate' is sending a request, which > might create state. So, when y1 is back up. y1 might allocate a different > external IP:port than other server. >=20 > Thanks, >=20 > Reinaldo >=20 >=20 >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From repenno@cisco.com Fri Aug 3 11:18:27 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE39F21F8E1B for ; Fri, 3 Aug 2012 11:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pO7sbHyWmVN8 for ; Fri, 3 Aug 2012 11:18:25 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E9D2921F8E04 for ; Fri, 3 Aug 2012 11:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=3420; q=dns/txt; s=iport; t=1344017905; x=1345227505; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Keozv4c7QSdYpKYv8L99yNX599QnNIssvWdrlUOu3CQ=; b=GFC3hMi1Bv58/tU8vRv8Zvgcxu0YpdJBoNdGUSyvZ9QsNE64nhhbA+vQ 8FsIfq82dmskRkDuKIEFQrngAOnAm0C0IMO6JJD8cPEguoMNePxGZrMKW eDcjCno2mZYd3cTqidqZJtwrHH6w/jNNzfGU1kcTmUQcCTrfW6lVUwAtL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFYVHFCtJV2d/2dsb2JhbABFuS6BB4IgAQEBAwEBAQEPASc0FwYBCA4DBAEBHwkuCxQJCAIEARIih2UGC5xhoBoEi0iHBAOVSo4ngWaCXw X-IronPort-AV: E=Sophos;i="4.77,707,1336348800"; d="scan'208";a="108284510" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 03 Aug 2012 18:18:24 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q73IIOi3012245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Aug 2012 18:18:24 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.162]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0283.003; Fri, 3 Aug 2012 13:18:24 -0500 From: "Reinaldo Penno (repenno)" To: Dave Thaler , "pcp@ietf.org" Thread-Topic: Comments on draft-ietf-pcp-dhcp-03 Thread-Index: AQHNcZ+sIMSFRn6eBkOpyqHfeftPVJdIXN9Q///nFoA= Date: Fri, 3 Aug 2012 18:18:23 +0000 Message-ID: In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B7380B2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.123.24] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.002 x-tm-as-result: No--49.788600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <4F713907AEC2074692EFB30E8D0D5411@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Comments on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 18:18:27 -0000 On 8/3/12 10:53 AM, "Dave Thaler" wrote: >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of >> Reinaldo Penno (repenno) >> Sent: Friday, August 03, 2012 10:45 AM >> To: pcp@ietf.org >> Subject: [pcp] Comments on draft-ietf-pcp-dhcp-03 >>=20 >> After reviewing draft-ietf-pcp-dhcp-03 I believe there are some things I >> believe we need to tie up. > >I agree. > >> When a PCP Client contacts PCP Servers in parallel, say, IPx1, IPy1 and >> IPz1 as mentioned in draft and all respond then: >>=20 >> 1 - What happens to the state in y1 and z1 if PCP Client chooses x1 to >> communicate? Probably let it age out or delete mappings. > >What do you mean by "chooses x1"? That's what we find in section 6.2 >if we're talking about MAP (for a >listening application) do you mean when x, y, and y >are all NATs rather than FWs, and the client app can only deal with one >external IP address? The draft says as soon as one PCP Server responds successfully it sticks to it. So, I'm assuming other PCP Server are not contacted further and mappings will time out or need to be deleted. As a side effect why would an app get 3 external IP:ports for the same purpose and consume three times the state. It seems to me a side effect of the wording more than something the app really needs. > >If they're firewalls (so the external IP address/port isn't different), or >if the client app can deal with multiple external IP/ports, then I don't >think >it would choose one. What's the use case for three? Anyway, this exchange is telling in light of "Once the PCP Client has successfully received a response from a PCP Server on that interface, it sends subsequent PCP requests to that same server until that PCP Server becomes non-responsive," >=20 >> 2 - If there is a failure on x1 and PCP Client decides to communicate >>with y1, >> there might be some 'leftover' mappings for internal IP:port (see 1). >> PCP Client will need to delete or reuse existing state in y1. Important >>to >> notice that there is no way to guarantee that PCP Server will allocate >>same >> external IP:ports. >>=20 >> 3 - I guess it is assumed that if PCP Server is co-located with NAT, if >>x1 fails, >> traffic (PCP and data) will be diverted to y1. > >Unclear which model you're referring to (different external IP:port or >same external IP:port), can you clarify your question? The app needs one external IP:port to announce on the external world through, say, DynDDNS client. Why it would need three _different_? If it needs them, fine, not sure about use case. But if it gets 3 as a collateral effect of the bootstrap procedure there is no way to guarantee they will be the same. >=20 >> 4 - Related (2). The draft says that when a PCP Server is unreachable >>(say, y1) >> PCP Client will continue to try to communicate even though other PCP >>Server >> are available. The only way to 'communicate' is sending a request, >>which >> might create state. So, when y1 is back up. y1 might allocate a >>different >> external IP:port than other server. >>=20 >> Thanks, >>=20 >> Reinaldo >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > > From dthaler@microsoft.com Fri Aug 3 13:29:55 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD17021E8042 for ; Fri, 3 Aug 2012 13:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.103 X-Spam-Level: X-Spam-Status: No, score=-103.103 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7-uH4Ul3fZB for ; Fri, 3 Aug 2012 13:29:55 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0738921E8040 for ; Fri, 3 Aug 2012 13:29:48 -0700 (PDT) Received: from mail13-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Fri, 3 Aug 2012 20:29:48 +0000 Received: from mail13-ch1 (localhost [127.0.0.1]) by mail13-ch1-R.bigfish.com (Postfix) with ESMTP id 45D8880137; Fri, 3 Aug 2012 20:29:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VS-31(zzbb2dI98dI9371I146fI542M1432I4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail13-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail13-ch1 (localhost.localdomain [127.0.0.1]) by mail13-ch1 (MessageSwitch) id 1344025786228362_950; Fri, 3 Aug 2012 20:29:46 +0000 (UTC) Received: from CH1EHSMHS037.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.249]) by mail13-ch1.bigfish.com (Postfix) with ESMTP id 35A2B2004B; Fri, 3 Aug 2012 20:29:46 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS037.bigfish.com (10.43.69.246) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 3 Aug 2012 20:29:45 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.309.3; Fri, 3 Aug 2012 20:29:42 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0309.003; Fri, 3 Aug 2012 13:29:41 -0700 From: Dave Thaler To: "Reinaldo Penno (repenno)" , "pcp@ietf.org" Thread-Topic: Comments on draft-ietf-pcp-dhcp-03 Thread-Index: AQHNcZ+sIMSFRn6eBkOpyqHfeftPVJdIXN9Q///nFoCAAERGIA== Date: Fri, 3 Aug 2012 20:29:41 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B73881F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B7380B2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [pcp] Comments on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 20:29:56 -0000 Responding on list for benefit of others, although we already talked in person... > -----Original Message----- > From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] > Sent: Friday, August 03, 2012 11:18 AM > To: Dave Thaler; pcp@ietf.org > Subject: Re: Comments on draft-ietf-pcp-dhcp-03 >=20 > On 8/3/12 10:53 AM, "Dave Thaler" wrote: >=20 > >> -----Original Message----- > >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > >> Reinaldo Penno (repenno) > >> Sent: Friday, August 03, 2012 10:45 AM > >> To: pcp@ietf.org > >> Subject: [pcp] Comments on draft-ietf-pcp-dhcp-03 > >> > >> After reviewing draft-ietf-pcp-dhcp-03 I believe there are some > >> things I believe we need to tie up. > > > >I agree. > > > >> When a PCP Client contacts PCP Servers in parallel, say, IPx1, IPy1 > >> and > >> IPz1 as mentioned in draft and all respond then: > >> > >> 1 - What happens to the state in y1 and z1 if PCP Client chooses x1 > >> to communicate? Probably let it age out or delete mappings. > > > >What do you mean by "chooses x1"? >=20 > That's what we find in section 6.2 Yes but the text is lacking, as this exchange shows. > >if we're talking about MAP (for a > >listening application) do you mean when x, y, and y are all NATs rather > >than FWs, and the client app can only deal with one external IP > >address? >=20 > The draft says as soon as one PCP Server responds successfully it sticks = to it. > So, I'm assuming other PCP Server are not contacted further and mappings > will time out or need to be deleted. >=20 > As a side effect why would an app get 3 external IP:ports for the same > purpose and consume three times the state. It seems to me a side effect o= f > the wording more than something the app really needs. Two reasons (cases): a) there's different networks it's providing the same service on, e.g. via the Internet and via some other network. b) for failover purposes. For example, if it uses SRV records, it'd have 3 SRV records. If one NAT goes down, the other end will automatically use a different IP:port pair (which might be via a different ISP). Oth= erwise the failover time is capped at the TTL of the SRV record, and we know DNS TTLs below around 30 seconds aren't respected by many DNS servers. So having multiple records provides sub-30-second failover. > >If they're firewalls (so the external IP address/port isn't different), > >or if the client app can deal with multiple external IP/ports, then I > >don't think it would choose one. >=20 > What's the use case for three?=20 Answered above. Note I'm not saying three is appropriate in all cases. Only that there is a use case, and the choice is up to the client, which is the only entity that knows the use case. > Anyway, this exchange is telling in light of >=20 > "Once the PCP Client has successfully > received a response from a PCP Server on that interface, it sends > subsequent PCP requests to that same server until that PCP Server > becomes non-responsive," >=20 > > > >> 2 - If there is a failure on x1 and PCP Client decides to communicate > >>with y1, there might be some 'leftover' mappings for internal IP:port > >>(see 1). > >> PCP Client will need to delete or reuse existing state in y1. > >>Important to notice that there is no way to guarantee that PCP Server > >>will allocate same external IP:ports. > >> > >> 3 - I guess it is assumed that if PCP Server is co-located with NAT, > >>if > >>x1 fails, > >> traffic (PCP and data) will be diverted to y1. > > > >Unclear which model you're referring to (different external IP:port or > >same external IP:port), can you clarify your question? >=20 > The app needs one external IP:port to announce on the external world > through, say, DynDDNS client. Why it would need three _different_? If it > needs them, fine, not sure about use case. But if it gets 3 as a collater= al effect > of the bootstrap procedure there is no way to guarantee they will be the > same. Answered above. -Dave =20 > >> 4 - Related (2). The draft says that when a PCP Server is unreachable > >>(say, y1) PCP Client will continue to try to communicate even though > >>other PCP Server are available. The only way to 'communicate' is > >>sending a request, which might create state. So, when y1 is back up. > >>y1 might allocate a different external IP:port than other server. > >> > >> Thanks, > >> > >> Reinaldo=20 From tireddy@cisco.com Sun Aug 5 14:45:50 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C36E21F849B for ; Sun, 5 Aug 2012 14:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDryNz4uKHGS for ; Sun, 5 Aug 2012 14:45:48 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8188621F8499 for ; Sun, 5 Aug 2012 14:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=6624; q=dns/txt; s=iport; t=1344203148; x=1345412748; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=XspJblJb8zl7izbmxsmb/cYem9M365DlxZYoQCAzCMg=; b=RKN2EBfG0579INi6gcuZ7BKD0NNAuKEJixCnn48yG2+XTGtgra7bNY1T rjCAIBAk4P3OS7peXz/1o4Oltbo9vaHxsHV32X3keqy2pEPxqXTZIn86f bVqooGMaUpmbcj0kfxKrIyuv4nMjhoF9szE4KbYqx9pL+hx4nXIbMQ0J2 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFzoHlCtJV2Z/2dsb2JhbABEuT2BB4IgAQEBBBIBJ0sEAgEIDgMEAQEBChQJBzIUCQgCBAESCBqHawubMp50i0qGJGADll2NEoFmgl8 X-IronPort-AV: E=Sophos;i="4.77,715,1336348800"; d="scan'208";a="108653783" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 05 Aug 2012 21:45:48 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q75LjlmZ021210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 5 Aug 2012 21:45:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Sun, 5 Aug 2012 16:45:47 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Dave Thaler , "Reinaldo Penno (repenno)" , "pcp@ietf.org" Thread-Topic: [pcp] Comments on draft-ietf-pcp-dhcp-03 Thread-Index: AQHNcnNckAHLzaHHt0W3VNgj76hdP5dLnPPQ Date: Sun, 5 Aug 2012 21:45:46 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1477C15D@xmb-rcd-x10.cisco.com> References: <9B57C850BB53634CACEC56EF4853FF653B7380B2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B73881F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B73881F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.83.244] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19088.001 x-tm-as-result: No--63.618700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Comments on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 21:45:50 -0000 Hi - I think we need to clarify in the draft when multiple PCP server names/IP a= ddresses will be returned by the DHCP server, for example like multi-homing= case. Considering various other cases other than multi-homing=20 [1]In High Availability mode of NAT/Firewall devices (Active/Passive Mode),= PCP client still gets just one IP address. [2] For example in the draft http://tools.ietf.org/html/draft-rpcw-pcp-pmip= v6-serv-discovery-00 where selected traffic is offload at the local access = network. Mobile Node is provided only the PCP server address in the Local A= ccess Network and MAG decides if the PCP request will be handled by Home ne= twork or Local Access Network. [3] In Enterprise use case there could be two to three different possibilit= ies a)All the traffic from the branches tunneled back to the head office where = there is a NAT/Firewall device. b)Split Tunneling - In this case branch site itself would have NAT/Firewall= to handle traffic to Internet.=20 How will the DHCP server be populated with the right Firewall/NAT IP addres= ses in this case ? [4] Finally we will also need to solve the problem with just IPv6 (NPTv6, Firew= all) where there is no DHCPv6 server. >From RFC6106 "RA-based DNS configuration is a useful alternative in networks where an IP= v6 host's address is auto-configured through IPv6 stateless address auto-configuration and where there is either no DHCPv6 infrastructu= re at all or some hosts do not have a DHCPv6 client" --Tiru. > -----Original Message----- > From: Dave Thaler [mailto:dthaler@microsoft.com] > Sent: Friday, August 03, 2012 2:30 PM > To: Reinaldo Penno (repenno); pcp@ietf.org > Subject: Re: [pcp] Comments on draft-ietf-pcp-dhcp-03 >=20 > Responding on list for benefit of others, although we already > talked in person... >=20 > > -----Original Message----- > > From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] > > Sent: Friday, August 03, 2012 11:18 AM > > To: Dave Thaler; pcp@ietf.org > > Subject: Re: Comments on draft-ietf-pcp-dhcp-03 > > > > On 8/3/12 10:53 AM, "Dave Thaler" wrote: > > > > >> -----Original Message----- > > >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf > Of > > >> Reinaldo Penno (repenno) > > >> Sent: Friday, August 03, 2012 10:45 AM > > >> To: pcp@ietf.org > > >> Subject: [pcp] Comments on draft-ietf-pcp-dhcp-03 > > >> > > >> After reviewing draft-ietf-pcp-dhcp-03 I believe there are some > > >> things I believe we need to tie up. > > > > > >I agree. > > > > > >> When a PCP Client contacts PCP Servers in parallel, say, IPx1, > IPy1 > > >> and > > >> IPz1 as mentioned in draft and all respond then: > > >> > > >> 1 - What happens to the state in y1 and z1 if PCP Client chooses > x1 > > >> to communicate? Probably let it age out or delete mappings. > > > > > >What do you mean by "chooses x1"? > > > > That's what we find in section 6.2 >=20 > Yes but the text is lacking, as this exchange shows. >=20 > > >if we're talking about MAP (for a > > >listening application) do you mean when x, y, and y are all NATs > rather > > >than FWs, and the client app can only deal with one external IP > > >address? > > > > The draft says as soon as one PCP Server responds successfully it > sticks to it. > > So, I'm assuming other PCP Server are not contacted further and > mappings > > will time out or need to be deleted. > > > > As a side effect why would an app get 3 external IP:ports for the > same > > purpose and consume three times the state. It seems to me a side > effect of > > the wording more than something the app really needs. >=20 > Two reasons (cases): > a) there's different networks it's providing the same service on, e.g. > via the Internet and via some other network. > b) for failover purposes. For example, if it uses SRV records, it'd > have > 3 SRV records. If one NAT goes down, the other end will > automatically > use a different IP:port pair (which might be via a different ISP). > Otherwise > the failover time is capped at the TTL of the SRV record, and we > know > DNS TTLs below around 30 seconds aren't respected by many DNS > servers. > So having multiple records provides sub-30-second failover. >=20 > > >If they're firewalls (so the external IP address/port isn't > different), > > >or if the client app can deal with multiple external IP/ports, then > I > > >don't think it would choose one. > > > > What's the use case for three? >=20 > Answered above. Note I'm not saying three is appropriate in all > cases. > Only that there is a use case, and the choice is up to the client, > which is the only entity that knows the use case. >=20 > > Anyway, this exchange is telling in light of > > > > "Once the PCP Client has successfully > > received a response from a PCP Server on that interface, it sends > > subsequent PCP requests to that same server until that PCP Server > > becomes non-responsive," > > > > > > > >> 2 - If there is a failure on x1 and PCP Client decides to > communicate > > >>with y1, there might be some 'leftover' mappings for internal > IP:port > > >>(see 1). > > >> PCP Client will need to delete or reuse existing state in y1. > > >>Important to notice that there is no way to guarantee that PCP > Server > > >>will allocate same external IP:ports. > > >> > > >> 3 - I guess it is assumed that if PCP Server is co-located with > NAT, > > >>if > > >>x1 fails, > > >> traffic (PCP and data) will be diverted to y1. > > > > > >Unclear which model you're referring to (different external IP:port > or > > >same external IP:port), can you clarify your question? > > > > The app needs one external IP:port to announce on the external world > > through, say, DynDDNS client. Why it would need three _different_? If > it > > needs them, fine, not sure about use case. But if it gets 3 as a > collateral effect > > of the bootstrap procedure there is no way to guarantee they will be > the > > same. >=20 > Answered above. >=20 > -Dave >=20 > > >> 4 - Related (2). The draft says that when a PCP Server is > unreachable > > >>(say, y1) PCP Client will continue to try to communicate even > though > > >>other PCP Server are available. The only way to 'communicate' is > > >>sending a request, which might create state. So, when y1 is back > up. > > >>y1 might allocate a different external IP:port than other server. > > >> > > >> Thanks, > > >> > > >> Reinaldo >=20 >=20 From dwing@cisco.com Mon Aug 6 11:01:22 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D63821F85C9 for ; Mon, 6 Aug 2012 11:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.489 X-Spam-Level: X-Spam-Status: No, score=-110.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACxd6O2rTW7B for ; Mon, 6 Aug 2012 11:01:18 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 89A6121E805E for ; Mon, 6 Aug 2012 11:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3490; q=dns/txt; s=iport; t=1344276078; x=1345485678; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=oD8gG37ihfXcslafUSjMl+tsoLczOa0RT1UgJYnzcUg=; b=D+K1Z6Q44rF+cc9lFB7dzm+RzGPnrPVBxA1mHhKOyIP70F1ZJ7F+ueoj /RcfZ7EsbYKjiZA9MBf4zCW+bJ28TF9qwme+UmFWuahKfkg69T7SH2QnL p/9JobV7LPOFXRR9YWa4zq8/kliXARp1IXkd2pD254BK/MwSoD2oosxwZ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAH8FIFCrRDoG/2dsb2JhbABFqhGPNoEHgiABAQECAQEICgEXEEsBAwIJDwIEAQEoBxkjCgkIAQEEARIJAheHZQUMmnKNY5I4i0qHBAOITYUNiQONEoFmgn8 X-IronPort-AV: E=Sophos;i="4.77,720,1336348800"; d="scan'208";a="51131292" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 06 Aug 2012 18:01:11 +0000 Received: from dwingWS (sjc-vpn6-84.cisco.com [10.21.120.84]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q76I1BAB016868; Mon, 6 Aug 2012 18:01:11 GMT From: "Dan Wing" To: "'Alper Yegin'" , References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> In-Reply-To: <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> Date: Mon, 6 Aug 2012 11:01:11 -0700 Message-ID: <067d01cd73fd$765a6c50$630f44f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1w9ilAavIR1gn8SpS9wUE6Ojd5XQDBpoQg Content-Language: en-us Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 18:01:22 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Alper Yegin > Sent: Thursday, August 02, 2012 2:31 PM > To: pcp@ietf.org > Subject: [pcp] Comparison of PCP authentication > > http://www.ietf.org/proceedings/84/slides/slides-84-pcp-10.pdf > > Ah, isn't it odd that this beauty contest is run by one of the > contestants? This material should have been prepared and presented by a > neutral party. > > One important question: With this proposal, are the authors advocating > each protocol should come with their own in-band key management, more > specifically embedding an EAP transport? > > > > what's the big deal of using the same port vs different port? Is > jamming all in the same port is a benefit? > > > "TLS is in-band" > > - There's standalone use of TLS as "a separate" KMP. RFC 5705 is driven > by the fact that some other protocols need to use TLS as a "separate > KMP". > - TLS is basically "transport layer security", something that sits > below the protocol one would be trying to secure. We are not doing > that. To throw another TLS thing into the mix: DTLS-SRTP [RFC5764] uses the (D)TLS handshake to encrypt SRTP and is pretty well aligned with what we want for PCP -- we want a key exchange and then run the PCP protocol natively. DTLS-SRTP has a normal DTLS handshake, followed by SRTP packets that appear normal on the wire (that is, the packets are RFC3711 packets which have their RTP headers in the clear). It does this over the same socket, because the first byte indicates if the packet is DTLS, SRTP, or STUN (ICE), http://tools.ietf.org/html/rfc5764#section-5.1.2. At the meeting, I suggested we consider if PANA and PCP could be similarly demux'd. Stuart suggested using some sort of GRE- like header if they cannot be demux'd. Either approach would eliminate one of the objections of PANA, specifically its use of a separate port. -d > > are the EAP and PCP state machines compatible? If marrying two > protocols, one needs to pay attention to this. This was one of the > reasons why EAPoDHCP did not work. > > > Does the EAP-over-PCP satisfy the "EAP lower layer requirements" as > stated in RFC 3848? I had asked this question but don't remember seeing > any response. > > > "Possible in-band optimization". Is this documented anywhere? It's > not easy to understand how it works by looking at this slide. > > > PANA RFC 5191 was published in 2008, not 2011. It's adopted by Zigbee > IP, ETSI TISPAN, and also ETSI M2M. Aside from two open-source > implementations, multiple commercial implementations have successfully > passed interop events in Zigbee Alliance. > > > > > * Need to specify the portions of PANA that don't need to be > implemented > > in a PCP PANA Client and Server (such as IP Address > reconfiguration) > > > >> this is just a single bit flag. We don't use it, and that's > all we need to do about it. > * Need to specify/describe interface between PANA and PCP elements > > >> this is an implementation issue, like how the other spec > implementors would need to define the interface between the EAP and PCP > for passing keys, etc. > > * Need to specify how the PANA client finds the correct PANA Server > for PCP Authentication (may be passed from PCP client?) > > >> PCP server the the PAA are the same node. > > > > > > > > > > > From alper.yegin@yegin.org Mon Aug 6 12:43:57 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3808521E80AA for ; Mon, 6 Aug 2012 12:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4WBitxahuSp for ; Mon, 6 Aug 2012 12:43:56 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 03EBD21E80A8 for ; Mon, 6 Aug 2012 12:43:56 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LxxbI-1TmBbm2AvE-015fTW; Mon, 06 Aug 2012 15:43:54 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_1B242084-C018-40F8-B07A-73FC1C6C3E7A" From: Alper Yegin In-Reply-To: <067d01cd73fd$765a6c50$630f44f0$@com> Date: Mon, 6 Aug 2012 22:43:35 +0300 Message-Id: References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:F/LRtvADEgE8h7V6v3PenzRstMCo6Anm+wxuCEaZxmn 5b2W3kP9piltqQDPnOFQr/1RSFh3lqa4jqK7ISgMLN8rVvtjzT EVn1n7dZG9SPdBiu1IEjqZkjlTnwOJ2akZyTwlQcpXPzdvuUdS dxZcLrC/qJnVQ9Vd4kcVVH1LmtEREHmuKG/2BX2lc2d3KoYUhr OAleoXw7wchhcgKXmUkwPINzxyLuJFnHW6Gz5STuzt4VJC9rP7 EfYs769un0GncUtGio1CB0dQtMoHr4+6eOCRxMvOrL3ONxpwt5 ch72CkGgsHroj4LJiEvz+RIoht6FLP1lgjHggXvUHJNVdubcSO dsdSzZ50hjKtmVpyvJ6mA383Ss2XNsAKe1BJ50URJSAygGpSaz 10+9Tf285L/+w== Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 19:43:57 -0000 --Apple-Mail=_1B242084-C018-40F8-B07A-73FC1C6C3E7A Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii PANA: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- Reserved This 16-bit field is reserved for future use. It MUST be set to zero and ignored by the receiver. PCP: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version = 2 |R| Opcode | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested Lifetime (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | PCP Client's IP Address (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : (optional) Opcode-specific information : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : (optional) PCP Options : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ First octet can be used for demux'ing. Alper On Aug 6, 2012, at 9:01 PM, Dan Wing wrote: >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of >> Alper Yegin >> Sent: Thursday, August 02, 2012 2:31 PM >> To: pcp@ietf.org >> Subject: [pcp] Comparison of PCP authentication >> >> http://www.ietf.org/proceedings/84/slides/slides-84-pcp-10.pdf >> >> Ah, isn't it odd that this beauty contest is run by one of the >> contestants? This material should have been prepared and presented by a >> neutral party. >> >> One important question: With this proposal, are the authors advocating >> each protocol should come with their own in-band key management, more >> specifically embedding an EAP transport? >> >> >>> what's the big deal of using the same port vs different port? Is >> jamming all in the same port is a benefit? >> >>> "TLS is in-band" >> >> - There's standalone use of TLS as "a separate" KMP. RFC 5705 is driven >> by the fact that some other protocols need to use TLS as a "separate >> KMP". >> - TLS is basically "transport layer security", something that sits >> below the protocol one would be trying to secure. We are not doing >> that. > > To throw another TLS thing into the mix: > > DTLS-SRTP [RFC5764] uses the (D)TLS handshake to encrypt SRTP and is > pretty well aligned with what we want for PCP -- we want a key > exchange and then run the PCP protocol natively. DTLS-SRTP has a > normal DTLS handshake, followed by SRTP packets that appear normal > on the wire (that is, the packets are RFC3711 packets which have > their RTP headers in the clear). It does this over the same socket, > because the first byte indicates if the packet is DTLS, SRTP, or > STUN (ICE), http://tools.ietf.org/html/rfc5764#section-5.1.2. > > At the meeting, I suggested we consider if PANA and PCP could > be similarly demux'd. Stuart suggested using some sort of GRE- > like header if they cannot be demux'd. Either approach would > eliminate one of the objections of PANA, specifically its use > of a separate port. > > -d > > > >>> are the EAP and PCP state machines compatible? If marrying two >> protocols, one needs to pay attention to this. This was one of the >> reasons why EAPoDHCP did not work. >> >>> Does the EAP-over-PCP satisfy the "EAP lower layer requirements" as >> stated in RFC 3848? I had asked this question but don't remember seeing >> any response. >> >>> "Possible in-band optimization". Is this documented anywhere? It's >> not easy to understand how it works by looking at this slide. >> >>> PANA RFC 5191 was published in 2008, not 2011. It's adopted by Zigbee >> IP, ETSI TISPAN, and also ETSI M2M. Aside from two open-source >> implementations, multiple commercial implementations have successfully >> passed interop events in Zigbee Alliance. >> >>> >> >> * Need to specify the portions of PANA that don't need to be >> implemented >> >> in a PCP PANA Client and Server (such as IP Address >> reconfiguration) >> >> >> >> this is just a single bit flag. We don't use it, and that's >> all we need to do about it. >> * Need to specify/describe interface between PANA and PCP elements >> >> >> this is an implementation issue, like how the other spec >> implementors would need to define the interface between the EAP and PCP >> for passing keys, etc. >> >> * Need to specify how the PANA client finds the correct PANA Server >> for PCP Authentication (may be passed from PCP client?) >> >> >> PCP server the the PAA are the same node. >> >> >> >> >> >> >> >> >> >> >> > > --Apple-Mail=_1B242084-C018-40F8-B07A-73FC1C6C3E7A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 
    0                   1                   =
2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Flags             |         Message Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Session Identifier                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  AVPs ...
   =
+-+-+-+-+-+-+-+-+-+-+-+-+-

   Reserved

      This 16-bit field is reserved for future use.  It MUST be set to
      zero and ignored by the =
receiver.



<= div>
PCP:

      0                   1                 =
  2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Version =3D 2  |R|   Opcode    |         Reserved              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Requested Lifetime (32 bits)                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |            PCP Client's IP Address (128 bits)                 |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) Opcode-specific information            :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) PCP Options                            :
     :                                                               :
     =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


First octet can be used for = demux'ing.

Alper





On Aug 6, 2012, at 9:01 = PM, Dan Wing wrote:

-----Original = Message-----
From: pcp-bounces@ietf.org = [mailto:pcp-bounces@ietf.org] On Behalf Of
Alper Yegin
Sent: = Thursday, August 02, 2012 2:31 PM
To: pcp@ietf.org
Subject: [pcp] Comparison of PCP = authentication

ht= tp://www.ietf.org/proceedings/84/slides/slides-84-pcp-10.pdf

Ah, isn't it odd that this beauty contest is run by one of = the
contestants? This material = should have been prepared and presented by a
neutral party.

One important = question: With this proposal, are the authors = advocating
each protocol = should come with their own in-band key management, = more
specifically embedding an = EAP transport?


what's the big deal of using the same port vs different = port? Is
jamming = all in the same port is a benefit?

"TLS is in-band"

- There's = standalone use of TLS as "a separate" KMP. RFC 5705 is = driven
by the fact that some = other protocols need to use TLS as a = "separate
KMP".
- TLS is = basically "transport layer security", something that = sits
below the protocol one = would be trying to secure. We are not doing
that.

To throw another TLS thing into = the mix:

DTLS-SRTP [RFC5764] uses the (D)TLS handshake to encrypt = SRTP and is
pretty well aligned with what we want for PCP -- we want = a key
exchange and then run the PCP protocol natively. =  DTLS-SRTP has a
normal DTLS handshake, followed by SRTP = packets that appear normal
on the wire (that is, the packets are = RFC3711 packets which have
their RTP headers in the clear).  It = does this over the same socket,
because the first byte indicates if = the packet is DTLS, SRTP, or
STUN (ICE), http://tools.iet= f.org/html/rfc5764#section-5.1.2.

At the meeting, I suggested = we consider if PANA and PCP could
be similarly demux'd.  Stuart = suggested using some sort of GRE-
like header if they cannot be = demux'd.  Either approach would
eliminate one of the objections = of PANA, specifically its use
of a separate = port.

-d



are the EAP and PCP state machines compatible? If marrying = two
protocols, = one needs to pay attention to this. This was one of = the
reasons why EAPoDHCP did = not work.

Does the EAP-over-PCP satisfy the "EAP lower layer = requirements" as
stated in RFC 3848? I had asked this question but don't = remember seeing
any = response.

"Possible in-band optimization". Is this documented = anywhere? It's
not = easy to understand how it works by looking at this = slide.

PANA RFC 5191 was published in 2008, not 2011. It's = adopted by Zigbee
IP, ETSI TISPAN, and also ETSI M2M. Aside from two = open-source
implementations, = multiple commercial implementations have = successfully
passed interop = events in Zigbee Alliance.



* Need to = specify the portions of PANA that don't need to = be
implemented

in a PCP = PANA Client and Server (such as IP Address
reconfiguration)


>> = this is just a single bit flag. We don't use it, and = that's
all we need to do about = it.
* Need to = specify/describe interface between PANA and PCP = elements

>> = this is an implementation issue, like how the other = spec
implementors would need = to define the interface between the EAP and = PCP
for passing keys, = etc.

* Need to = specify how the PANA client finds the correct PANA = Server
for PCP Authentication = (may be passed from PCP client?)

>> = PCP server the the PAA are the same node.














= --Apple-Mail=_1B242084-C018-40F8-B07A-73FC1C6C3E7A-- From mrw@lilacglade.org Mon Aug 6 13:02:57 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D74A21F84D8 for ; Mon, 6 Aug 2012 13:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.443 X-Spam-Level: X-Spam-Status: No, score=-95.443 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8+0JbLxFumw for ; Mon, 6 Aug 2012 13:02:56 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-76-251.compute-1.amazonaws.com [23.21.76.251]) by ietfa.amsl.com (Postfix) with ESMTP id D74C121F84C4 for ; Mon, 6 Aug 2012 13:02:55 -0700 (PDT) Received: from lilac-too.home (permutation-city.suchdamage.org [69.25.196.28]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id E7DCB2002D; Mon, 6 Aug 2012 16:01:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4-903953692 From: Margaret Wasserman In-Reply-To: Date: Mon, 6 Aug 2012 16:02:53 -0400 Message-Id: <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 20:02:57 -0000 --Apple-Mail-4-903953692 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Alper, Thanks for your help with this! While it would work to demultiplex on = the first byte, as you indicate, there is a bit more to defining a = demultiplexing solution than this... Since this is UDP, there is nothing that inherently binds the PANA = authentication to a particular (set of) PCP request(s). So, we will = need to make sure that the information passed in the authentication = option is sufficient for the sever to securely determine that the client = sending a the PCP request is the same client that initiated the PANA = exchange and vice versa, just as we would need to do if PANA and PCP = were run on separate ports. I don't think this will be difficult, we = just need to make sure that we achieve it. Do you know what existing PANA implementations will do if the "Reserved" = field at the start of the packet is non-zero?=20 We should also consider the trade-offs between a demultiplexing approach = (which allows us to run PANA and PCP separately over a single port), and = an encapsulation approach (PANA encapsulated in PCP). A demultiplexing = approach is somewhat cleaner, in that we can process the whole message = as a PANA or PCP message. But, the encapsulation approach would allow = us to gain some optimization by piggy-backing the first (and possibly = the final?) messages of the PANA exchange in the original PCP request = (and response?) to cut down on the number of messages needed to create a = secure mapping. Since the PCP exchange may happen as part of client = connection set-up (while a user is waiting), cutting down on the number = of messages exchanged could be valuable. As discussed at the PCP meeting in Vancouver, we will be writing up both = of these approaches soon, for further discussion on an interim phone = call. Margaret On Aug 6, 2012, at 3:43 PM, Alper Yegin wrote: >=20 > PANA: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Flags | Message Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Session Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AVPs ... > +-+-+-+-+-+-+-+-+-+-+-+-+- >=20 > Reserved >=20 > This 16-bit field is reserved for future use. It MUST be set to > zero and ignored by the receiver. >=20 >=20 >=20 >=20 > PCP: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version =3D 2 |R| Opcode | Reserved = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Requested Lifetime (32 bits) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | PCP Client's IP Address (128 bits) | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : : > : (optional) Opcode-specific information : > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : : > : (optional) PCP Options : > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 > First octet can be used for demux'ing. >=20 > Alper >=20 >=20 >=20 >=20 >=20 > On Aug 6, 2012, at 9:01 PM, Dan Wing wrote: >=20 >>> -----Original Message----- >>> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf = Of >>> Alper Yegin >>> Sent: Thursday, August 02, 2012 2:31 PM >>> To: pcp@ietf.org >>> Subject: [pcp] Comparison of PCP authentication >>>=20 >>> http://www.ietf.org/proceedings/84/slides/slides-84-pcp-10.pdf >>>=20 >>> Ah, isn't it odd that this beauty contest is run by one of the >>> contestants? This material should have been prepared and presented = by a >>> neutral party. >>>=20 >>> One important question: With this proposal, are the authors = advocating >>> each protocol should come with their own in-band key management, = more >>> specifically embedding an EAP transport? >>>=20 >>>=20 >>>> what's the big deal of using the same port vs different port? Is >>> jamming all in the same port is a benefit? >>>=20 >>>> "TLS is in-band" >>>=20 >>> - There's standalone use of TLS as "a separate" KMP. RFC 5705 is = driven >>> by the fact that some other protocols need to use TLS as a "separate >>> KMP". >>> - TLS is basically "transport layer security", something that sits >>> below the protocol one would be trying to secure. We are not doing >>> that. >>=20 >> To throw another TLS thing into the mix: >>=20 >> DTLS-SRTP [RFC5764] uses the (D)TLS handshake to encrypt SRTP and is >> pretty well aligned with what we want for PCP -- we want a key >> exchange and then run the PCP protocol natively. DTLS-SRTP has a=20 >> normal DTLS handshake, followed by SRTP packets that appear normal=20 >> on the wire (that is, the packets are RFC3711 packets which have >> their RTP headers in the clear). It does this over the same socket, >> because the first byte indicates if the packet is DTLS, SRTP, or >> STUN (ICE), http://tools.ietf.org/html/rfc5764#section-5.1.2. >>=20 >> At the meeting, I suggested we consider if PANA and PCP could >> be similarly demux'd. Stuart suggested using some sort of GRE- >> like header if they cannot be demux'd. Either approach would=20 >> eliminate one of the objections of PANA, specifically its use=20 >> of a separate port. >>=20 >> -d >>=20 >>=20 >>=20 >>>> are the EAP and PCP state machines compatible? If marrying two >>> protocols, one needs to pay attention to this. This was one of the >>> reasons why EAPoDHCP did not work. >>>=20 >>>> Does the EAP-over-PCP satisfy the "EAP lower layer requirements" as >>> stated in RFC 3848? I had asked this question but don't remember = seeing >>> any response. >>>=20 >>>> "Possible in-band optimization". Is this documented anywhere? It's >>> not easy to understand how it works by looking at this slide. >>>=20 >>>> PANA RFC 5191 was published in 2008, not 2011. It's adopted by = Zigbee >>> IP, ETSI TISPAN, and also ETSI M2M. Aside from two open-source >>> implementations, multiple commercial implementations have = successfully >>> passed interop events in Zigbee Alliance. >>>=20 >>>>=20 >>>=20 >>> * Need to specify the portions of PANA that don't need to be >>> implemented >>>=20 >>> in a PCP PANA Client and Server (such as IP Address >>> reconfiguration) >>>=20 >>>=20 >>> >> this is just a single bit flag. We don't use it, and that's >>> all we need to do about it. >>> * Need to specify/describe interface between PANA and PCP elements >>>=20 >>> >> this is an implementation issue, like how the other spec >>> implementors would need to define the interface between the EAP and = PCP >>> for passing keys, etc. >>>=20 >>> * Need to specify how the PANA client finds the correct PANA = Server >>> for PCP Authentication (may be passed from PCP client?) >>>=20 >>> >> PCP server the the PAA are the same node. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp --Apple-Mail-4-903953692 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

We should also = consider the trade-offs between a demultiplexing approach (which allows = us to run PANA and PCP separately over a single port), and an = encapsulation approach (PANA encapsulated in PCP).  A = demultiplexing approach is somewhat cleaner, in that we can process the = whole message as a PANA or PCP message.  But, the encapsulation = approach would allow us to gain some optimization by piggy-backing the = first (and possibly the final?) messages of the PANA exchange in the = original PCP request (and response?) to cut down on the number of = messages needed to create a secure mapping.  Since the PCP exchange = may happen as part of client connection set-up (while a user is = waiting), cutting down on the number of messages exchanged could be = valuable.

As discussed at the PCP meeting in = Vancouver, we will be writing up both of these approaches soon, for = further discussion on an interim phone = call.

Margaret


=
On Aug 6, 2012, at 3:43 PM, Alper Yegin wrote:

    0                   1                   =
2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Flags             |         Message Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Session Identifier                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  AVPs ...
   =
+-+-+-+-+-+-+-+-+-+-+-+-+-

   Reserved

      This 16-bit field is reserved for future use.  It MUST be set to
      zero and ignored by the =
receiver.



<= div>
PCP:

      0                   1                 =
  2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Version =3D 2  |R|   Opcode    |         Reserved              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Requested Lifetime (32 bits)                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |            PCP Client's IP Address (128 bits)                 |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) Opcode-specific information            :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) PCP Options                            :
     :                                                               :
     =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


First octet can be used for = demux'ing.

Alper





On Aug 6, 2012, at 9:01 = PM, Dan Wing wrote:

-----Original = Message-----
From: pcp-bounces@ietf.org = [mailto:pcp-bounces@ietf.org] On Behalf Of
Alper Yegin
Sent: = Thursday, August 02, 2012 2:31 PM
To: pcp@ietf.org
Subject: [pcp] Comparison of PCP = authentication

ht= tp://www.ietf.org/proceedings/84/slides/slides-84-pcp-10.pdf

Ah, isn't it odd that this beauty contest is run by one of = the
contestants? This material = should have been prepared and presented by a
neutral party.

One important = question: With this proposal, are the authors = advocating
each protocol = should come with their own in-band key management, = more
specifically embedding an = EAP transport?


what's the big deal of using the same port vs different = port? Is
jamming = all in the same port is a benefit?

"TLS is in-band"

- There's = standalone use of TLS as "a separate" KMP. RFC 5705 is = driven
by the fact that some = other protocols need to use TLS as a = "separate
KMP".
- TLS is = basically "transport layer security", something that = sits
below the protocol one = would be trying to secure. We are not doing
that.

To throw another TLS thing into = the mix:

DTLS-SRTP [RFC5764] uses the (D)TLS handshake to encrypt = SRTP and is
pretty well aligned with what we want for PCP -- we want = a key
exchange and then run the PCP protocol natively. =  DTLS-SRTP has a
normal DTLS handshake, followed by SRTP = packets that appear normal
on the wire (that is, the packets are = RFC3711 packets which have
their RTP headers in the clear).  It = does this over the same socket,
because the first byte indicates if = the packet is DTLS, SRTP, or
STUN (ICE), http://tools.iet= f.org/html/rfc5764#section-5.1.2.

At the meeting, I suggested = we consider if PANA and PCP could
be similarly demux'd.  Stuart = suggested using some sort of GRE-
like header if they cannot be = demux'd.  Either approach would
eliminate one of the objections = of PANA, specifically its use
of a separate = port.

-d



are the EAP and PCP state machines compatible? If marrying = two
protocols, = one needs to pay attention to this. This was one of = the
reasons why EAPoDHCP did = not work.

Does the EAP-over-PCP satisfy the "EAP lower layer = requirements" as
stated in RFC 3848? I had asked this question but don't = remember seeing
any = response.

"Possible in-band optimization". Is this documented = anywhere? It's
not = easy to understand how it works by looking at this = slide.

PANA RFC 5191 was published in 2008, not 2011. It's = adopted by Zigbee
IP, ETSI TISPAN, and also ETSI M2M. Aside from two = open-source
implementations, = multiple commercial implementations have = successfully
passed interop = events in Zigbee Alliance.



* Need to = specify the portions of PANA that don't need to = be
implemented

in a PCP = PANA Client and Server (such as IP Address
reconfiguration)


>> = this is just a single bit flag. We don't use it, and = that's
all we need to do about = it.
* Need to = specify/describe interface between PANA and PCP = elements

>> = this is an implementation issue, like how the other = spec
implementors would need = to define the interface between the EAP and = PCP
for passing keys, = etc.

* Need to = specify how the PANA client finds the correct PANA = Server
for PCP Authentication = (may be passed from PCP client?)

>> = PCP server the the PAA are the same node.














= _______________________________________________
pcp mailing = list
pcp@ietf.org
https://www.ietf.org/mail= man/listinfo/pcp

= --Apple-Mail-4-903953692-- From dwing@cisco.com Mon Aug 6 14:19:05 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A1F21E8082 for ; Mon, 6 Aug 2012 14:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.191 X-Spam-Level: X-Spam-Status: No, score=-110.191 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hRmCU70I2JY for ; Mon, 6 Aug 2012 14:19:04 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 681D121E804D for ; Mon, 6 Aug 2012 14:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=9139; q=dns/txt; s=iport; t=1344287944; x=1345497544; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=eQ64rywq1gp3hlTudeJzRgYXs8c/cdYoGczAO3U2/X4=; b=Tg5XBw/+ozVMuVfssLfVotPItVRW/KqqmYBaQuKbp6NPJyEhCIg75Lyc TRJ4ZuguxsJ0O3vcOl1eeW6QhBwTilH/Ct87x7sBFiOz5Ltc76EVerDss mx0iOe7GPINX5JJ4gI9ccCz2cKeNZlCqCky87JBOoRw0DsNrDvKlGJ/v6 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPMzIFCrRDoH/2dsb2JhbABFqhKPNoEHgiABAQEDAQEBAQUKARcQMgIIAwUHAQMCCQ4BAgQBAQEnBxkOFQoJCAEBBAESCQIQB4dlBQybCI1jkkOLSocEA4hNhQ2JA40SgWaCfw X-IronPort-AV: E=Sophos;i="4.77,720,1336348800"; d="scan'208";a="51150360" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 06 Aug 2012 21:19:01 +0000 Received: from dwingWS (sjc-vpn3-793.cisco.com [10.21.67.25]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q76LJ1Ux002133; Mon, 6 Aug 2012 21:19:01 GMT From: "Dan Wing" To: "'Margaret Wasserman'" , "'Alper Yegin'" References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> In-Reply-To: <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> Date: Mon, 6 Aug 2012 14:19:00 -0700 Message-ID: <075301cd7419$19557dd0$4c007970$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac10DnhIECfuuNknRVyqZBU7iOOwuwACmqDw Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 21:19:05 -0000 > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@lilacglade.org] > Sent: Monday, August 06, 2012 1:03 PM > To: Alper Yegin > Cc: Dan Wing; pcp@ietf.org > Subject: Re: [pcp] Comparison of PCP authentication > > > Hi Alper, > > Thanks for your help with this! While it would work to demultiplex on > the first byte, as you indicate, there is a bit more to defining a > demultiplexing solution than this... > > Since this is UDP, there is nothing that inherently binds the PANA > authentication to a particular (set of) PCP request(s). So, we will > need to make sure that the information passed in the authentication > option is sufficient for the sever to securely determine that the > client sending a the PCP request is the same client that initiated the > PANA exchange and vice versa, just as we would need to do if PANA and > PCP were run on separate ports. I don't think this will be difficult, > we just need to make sure that we achieve it. > > Do you know what existing PANA implementations will do if the > "Reserved" field at the start of the packet is non-zero? Also, if an update to PANA allows 0b00000010 in that first octet, we will have a problem. It would be safer if we assign the last two bits in that first octet of PANA to must-be-zero. Perhaps via an Errata against the PANA spec, if we decide this is the best solution. > We should also consider the trade-offs between a demultiplexing > approach (which allows us to run PANA and PCP separately over a single > port), and an encapsulation approach (PANA encapsulated in PCP). A > demultiplexing approach is somewhat cleaner, in that we can process the > whole message as a PANA or PCP message. But, the encapsulation > approach would allow us to gain some optimization by piggy-backing the > first (and possibly the final?) messages of the PANA exchange in the > original PCP request (and response?) to cut down on the number of > messages needed to create a secure mapping. How many messages are we talking about (5?), and how much reduction could we see (reduction from 5 to 3??). > Since the PCP exchange may > happen as part of client connection set-up (while a user is waiting), > cutting down on the number of messages exchanged could be valuable. > > As discussed at the PCP meeting in Vancouver, we will be writing up > both of these approaches soon, for further discussion on an interim > phone call. Looking forward to that. -d > Margaret > > > On Aug 6, 2012, at 3:43 PM, Alper Yegin wrote: > > > > PANA: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 > 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > | Reserved | Message Length > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > | Flags | Message Type > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > | Session Identifier > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > | Sequence Number > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > | AVPs ... > +-+-+-+-+-+-+-+-+-+-+-+-+- > > > Reserved > > This 16-bit field is reserved for future use. It MUST be > set to > zero and ignored by the receiver. > > > > > PCP: > > > 0 1 2 > 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > | Version = 2 |R| Opcode | Reserved > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > | Requested Lifetime (32 bits) > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > | > | > | PCP Client's IP Address (128 bits) > | > | > | > | > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > : > : > : (optional) Opcode-specific information > : > : > : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > : > : > : (optional) PCP Options > : > : > : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > > > First octet can be used for demux'ing. > > Alper > > > > > > On Aug 6, 2012, at 9:01 PM, Dan Wing wrote: > > > -----Original Message----- > > > From: pcp-bounces@ietf.org [mailto:pcp- > bounces@ietf.org] On Behalf Of > > > Alper Yegin > > > Sent: Thursday, August 02, 2012 2:31 PM > > > To: pcp@ietf.org > > > Subject: [pcp] Comparison of PCP authentication > > > > http://www.ietf.org/proceedings/84/slides/slides-84- > pcp-10.pdf > > > > Ah, isn't it odd that this beauty contest is run by > one of the > > > contestants? This material should have been prepared > and presented by a > > > neutral party. > > > > One important question: With this proposal, are the > authors advocating > > > each protocol should come with their own in-band key > management, more > > > specifically embedding an EAP transport? > > > > > what's the big deal of using the same port vs > different port? Is > > > jamming all in the same port is a benefit? > > > > "TLS is in-band" > > > > - There's standalone use of TLS as "a separate" KMP. > RFC 5705 is driven > > > by the fact that some other protocols need to use TLS > as a "separate > > > KMP". > > > - TLS is basically "transport layer security", > something that sits > > > below the protocol one would be trying to secure. We > are not doing > > > that. > > > > To throw another TLS thing into the mix: > > DTLS-SRTP [RFC5764] uses the (D)TLS handshake to encrypt > SRTP and is > pretty well aligned with what we want for PCP -- we want a > key > exchange and then run the PCP protocol natively. DTLS-SRTP > has a > normal DTLS handshake, followed by SRTP packets that appear > normal > on the wire (that is, the packets are RFC3711 packets which > have > their RTP headers in the clear). It does this over the > same socket, > because the first byte indicates if the packet is DTLS, > SRTP, or > STUN (ICE), http://tools.ietf.org/html/rfc5764#section- > 5.1.2. > > At the meeting, I suggested we consider if PANA and PCP > could > be similarly demux'd. Stuart suggested using some sort of > GRE- > like header if they cannot be demux'd. Either approach > would > eliminate one of the objections of PANA, specifically its > use > of a separate port. > > -d > > > > > > are the EAP and PCP state machines compatible? > If marrying two > > > protocols, one needs to pay attention to this. This > was one of the > > > reasons why EAPoDHCP did not work. > > > > Does the EAP-over-PCP satisfy the "EAP lower > layer requirements" as > > > stated in RFC 3848? I had asked this question but > don't remember seeing > > > any response. > > > > "Possible in-band optimization". Is this > documented anywhere? It's > > > not easy to understand how it works by looking at > this slide. > > > > PANA RFC 5191 was published in 2008, not 2011. > It's adopted by Zigbee > > > IP, ETSI TISPAN, and also ETSI M2M. Aside from two > open-source > > > implementations, multiple commercial implementations > have successfully > > > passed interop events in Zigbee Alliance. > > > > > > * Need to specify the portions of PANA that don't > need to be > > > implemented > > > > in a PCP PANA Client and Server (such as IP Address > > > reconfiguration) > > > > > >> this is just a single bit flag. We don't use it, > and that's > > > all we need to do about it. > > > * Need to specify/describe interface between PANA and > PCP elements > > > > >> this is an implementation issue, like how the > other spec > > > implementors would need to define the interface > between the EAP and PCP > > > for passing keys, etc. > > > > * Need to specify how the PANA client finds the > correct PANA Server > > > for PCP Authentication (may be passed from PCP > client?) > > > > >> PCP server the the PAA are the same node. > > > > > > > > > > > > > > > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > > From jhw@apple.com Mon Aug 6 16:03:22 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39AD21F846B for ; Mon, 6 Aug 2012 16:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.544 X-Spam-Level: X-Spam-Status: No, score=-110.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA9O7Nw1tgQO for ; Mon, 6 Aug 2012 16:03:22 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDE721F8470 for ; Mon, 6 Aug 2012 16:03:21 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M8C0042SW0AIJU9@mail-out.apple.com> for pcp@ietf.org; Mon, 06 Aug 2012 16:03:16 -0700 (PDT) X-AuditID: 11807137-b7f626d0000059a0-53-50204d33d6e5 Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 6D.75.22944.43D40205; Mon, 06 Aug 2012 16:03:16 -0700 (PDT) From: james woodyatt In-reply-to: <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> Date: Mon, 06 Aug 2012 16:03:15 -0700 Message-id: References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> To: pcp@ietf.org X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42IRPMjroGviqxBgsOoOr8XkY79ZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8WfWLuaCwzwVCz6tY25g7OLsYuTkkBAwkVjfd5wRwhaTuHBv PVsXIxeHkMBsJolnT++xgCSYBbQkbvx7yQRi8wroScxunwMWFxYwlphyaSNYnE1AReLb5btg NqeAk8SGxk3MIDYLUPzB/C2MEHO0JZYtfM0MMcdGon9vFzvEslVMEg/vbwIrEhEQkPi9+jIT xEWyEt8Pn2ebwMg3C8kds5DcMQvJ3AWMzKsYBYtScxIrDc30EgsKclL1kvNzNzGCgqmh0HwH 4/a/cocYBTgYlXh4KzgUAoRYE8uKK3MPMUpwMCuJ8DIxAIV4UxIrq1KL8uOLSnNSiw8xSnOw KInz/l0uFCAkkJ5YkpqdmlqQWgSTZeLglGpgVAzpe5og1z1LaGq+87yj4vXBQbwdV5ZVJzD8 XHCdZd77tfZWP2+c0C0rm3ya2TTrRXbR5Qq396tcee/pTHq11bvSe6Z+iGor8wvtx4qZvi2S RcGnQpQ+bF93/sqT7mwGw4dXt5nfKixPmnxh46lbu3nME0RWLZ+3sIjPoLsva0Xiq02tYT+e KbEUZyQaajEXFScCAHapTkciAgAA Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 23:03:23 -0000 On Aug 6, 2012, at 13:02 , Margaret Wasserman wrote: > > Do you know what existing PANA implementations will do if the "Reserved" field at the start of the packet is non-zero? A related question might be what existing NAT-PMP implementations will do if they receive a message containing a PANA packet. Assuming they comply with I-D.cheshire-nat-pmp-03, they will interpret the first two octets of a PANA message as an announcement request, and they will reply with the announcement response message shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers = 0 | OP = 128 + 0 | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds Since Start of Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | External IP Address (a.b.c.d) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If a PCP server needs to implement NAT-PMP too, then it can easily distinguish a NAT-PMP announcement request from a PANA message, but one wonders if a PANA client expecting to authenticate to such a server can deal with replies from a NAT-PMP server that knows nothing about either PCP or NAT-PMP. -- james woodyatt member of technical staff, core os networking From mrw@lilacglade.org Mon Aug 6 16:07:57 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A51021F8605 for ; Mon, 6 Aug 2012 16:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.706 X-Spam-Level: X-Spam-Status: No, score=-95.706 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5K3nzsMePzV for ; Mon, 6 Aug 2012 16:07:56 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-76-251.compute-1.amazonaws.com [23.21.76.251]) by ietfa.amsl.com (Postfix) with ESMTP id A0A0A21F85A3 for ; Mon, 6 Aug 2012 16:07:56 -0700 (PDT) Received: from lilac-too.home (permutation-city.suchdamage.org [69.25.196.28]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 92A5D2002D; Mon, 6 Aug 2012 19:06:55 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-5-915054956 From: Margaret Wasserman In-Reply-To: <075301cd7419$19557dd0$4c007970$@com> Date: Mon, 6 Aug 2012 19:07:54 -0400 Message-Id: References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <075301cd7419$19557dd0$4c007970$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 23:07:57 -0000 --Apple-Mail-5-915054956 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 6, 2012, at 5:19 PM, Dan Wing wrote: >=20 > Also, if an update to PANA allows 0b00000010 in that first octet, we = will > have a problem. It would be safer if we assign the last two bits in = that > first octet of PANA to must-be-zero. Perhaps via an Errata against = the PANA > spec, if we decide this is the best solution. Good point Dan. We will mention this in the updated draft (the one with = the three choices), just so we don't lose track of it. >> But, the encapsulation >> approach would allow us to gain some optimization by piggy-backing = the >> first (and possibly the final?) messages of the PANA exchange in the >> original PCP request (and response?) to cut down on the number of >> messages needed to create a secure mapping.=20 >=20 > How many messages are we talking about (5?), and how much reduction=20 > could we see (reduction from 5 to 3??). I think we are talking about ~7 messages, cut down to 5 or 6... I = realize that is a fairly small optimization, as a percentage, but = security folks do go to fairly significant ends to cut out round trips, = when possible, to make people less averse to adopting security = solutions. I don't know how many of those steps are lock-step... This = is something I will try to look into and provide more information about = for the interim meeting. I'm hoping we'll have more time to go over the = trade-offs in detail on a call than we did in the meeting (when we only = had ~25 minutes). Margaret --Apple-Mail-5-915054956 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Also, if an = update to PANA allows 0b00000010 in that first octet, we will
have a = problem.  It would be safer if we assign the last two bits in = that
first octet of PANA to must-be-zero.  Perhaps via an Errata = against the PANA
spec, if we decide this is the best = solution.

Good point Dan.  We = will mention this in the updated draft (the one with the three choices), = just so we don't lose track of it.

  But, the = encapsulation
approach would allow us to = gain some optimization by piggy-backing the
first (and possibly the final?) messages of the PANA = exchange in the
original PCP = request (and response?) to cut down on the number = of
messages needed to create a = secure mapping.

How many messages are we talking = about (5?), and how much reduction
could we see (reduction from 5 to = 3??).

I think we are talking about = ~7 messages, cut down to 5 or 6...  I realize that is a fairly = small optimization, as a percentage, but security folks do go to fairly = significant ends to cut out round trips, when possible, to make people = less averse to adopting security solutions.  I don't know how many = of those steps are lock-step... This is something I will try to look = into and provide more information about for the interim meeting. =  I'm hoping we'll have more time to go over the trade-offs in = detail on a call than we did in the meeting (when we only had ~25 = minutes).

Margaret

= --Apple-Mail-5-915054956-- From mrw@lilacglade.org Mon Aug 6 16:09:13 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A5821F8666 for ; Mon, 6 Aug 2012 16:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.707 X-Spam-Level: X-Spam-Status: No, score=-95.707 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivWuu6M5bpAZ for ; Mon, 6 Aug 2012 16:09:13 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-76-251.compute-1.amazonaws.com [23.21.76.251]) by ietfa.amsl.com (Postfix) with ESMTP id E980F21F865F for ; Mon, 6 Aug 2012 16:09:12 -0700 (PDT) Received: from lilac-too.home (permutation-city.suchdamage.org [69.25.196.28]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 55AB82002D; Mon, 6 Aug 2012 19:08:12 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: Date: Mon, 6 Aug 2012 19:09:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <34A0574C-A57A-487F-B302-D0EA24C0E93E@lilacglade.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> To: james woodyatt X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 23:09:13 -0000 Another important point to consider, James. Thanks! Margaret On Aug 6, 2012, at 7:03 PM, james woodyatt wrote: > On Aug 6, 2012, at 13:02 , Margaret Wasserman = wrote: >>=20 >> Do you know what existing PANA implementations will do if the = "Reserved" field at the start of the packet is non-zero?=20 >=20 > A related question might be what existing NAT-PMP implementations will = do if they receive a message containing a PANA packet. Assuming they = comply with I-D.cheshire-nat-pmp-03, they will interpret the first two = octets of a PANA message as an announcement request, and they will reply = with the announcement response message shown below. >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vers =3D 0 | OP =3D 128 + 0 | Result Code = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Seconds Since Start of Epoch | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | External IP Address (a.b.c.d) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > If a PCP server needs to implement NAT-PMP too, then it can easily = distinguish a NAT-PMP announcement request from a PANA message, but one = wonders if a PANA client expecting to authenticate to such a server can = deal with replies from a NAT-PMP server that knows nothing about either = PCP or NAT-PMP. >=20 >=20 > -- > james woodyatt > member of technical staff, core os networking >=20 >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From hartmans@painless-security.com Mon Aug 6 16:46:45 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F0E11E80A5 for ; Mon, 6 Aug 2012 16:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.337 X-Spam-Level: * X-Spam-Status: No, score=1.337 tagged_above=-999 required=5 tests=[AWL=-2.951, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-0dS77u1Z0I for ; Mon, 6 Aug 2012 16:46:44 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-76-251.compute-1.amazonaws.com [23.21.76.251]) by ietfa.amsl.com (Postfix) with ESMTP id C7F0811E8087 for ; Mon, 6 Aug 2012 16:46:44 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E0CEB2002D; Mon, 6 Aug 2012 19:45:43 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5E47E420E; Mon, 6 Aug 2012 19:46:38 -0400 (EDT) From: Sam Hartman To: Margaret Wasserman References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <075301cd7419$19557dd0$4c007970$@com> Date: Mon, 06 Aug 2012 19:46:38 -0400 In-Reply-To: (Margaret Wasserman's message of "Mon, 6 Aug 2012 19:07:54 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 23:46:45 -0000 I actually don't think you can gain much value from encapsulation. The issue is that you'll need to resend the PCP request once you have a key available. At least in the case where the client wants authentication, you cannot save a half round trip through encapsulation. From yoshihiro.ohba@toshiba.co.jp Mon Aug 6 18:00:05 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C91721F86BD for ; Mon, 6 Aug 2012 18:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.789 X-Spam-Level: X-Spam-Status: No, score=-5.789 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPzrtB18LA0V for ; Mon, 6 Aug 2012 18:00:04 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id CF3C521F86BB for ; Mon, 6 Aug 2012 18:00:03 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q77102Wm018896 for ; Tue, 7 Aug 2012 10:00:02 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q771011P007993 for pcp@ietf.org; Tue, 7 Aug 2012 10:00:01 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id LAA07981; Tue, 7 Aug 2012 10:00:01 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q77100re013578 for ; Tue, 7 Aug 2012 10:00:01 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q77100AA019749; Tue, 7 Aug 2012 10:00:00 +0900 (JST) Received: from [133.199.17.237] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0M8D00IW61FZFZ60@mail.po.toshiba.co.jp> for pcp@ietf.org; Tue, 07 Aug 2012 10:00:00 +0900 (JST) Date: Tue, 07 Aug 2012 09:59:59 +0900 From: Yoshihiro Ohba In-reply-to: <075301cd7419$19557dd0$4c007970$@com> To: pcp@ietf.org Message-id: <5020688F.4060004@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <075301cd7419$19557dd0$4c007970$@com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 01:00:05 -0000 RFC5191-conformant PANA implementations will ignore the "Reserved" field. If we specify a new use of PANA "Reserved" field, it cannot be an Errata because it is not a specification error. It needs to be a new RFC that updates RFC 5191. On the other hand, if we update RFC 5191 (in which WG?), then we probably need to think more generally so that the update is beneficial not only for PCP but also other protocols (such as STUN?) that can potentially benefit from PANA-based in-band key management. Yoshihiro Ohba (2012/08/07 6:19), Dan Wing wrote: >> -----Original Message----- >> From: Margaret Wasserman [mailto:mrw@lilacglade.org] >> Sent: Monday, August 06, 2012 1:03 PM >> To: Alper Yegin >> Cc: Dan Wing; pcp@ietf.org >> Subject: Re: [pcp] Comparison of PCP authentication >> >> >> Hi Alper, >> >> Thanks for your help with this! While it would work to demultiplex on >> the first byte, as you indicate, there is a bit more to defining a >> demultiplexing solution than this... >> >> Since this is UDP, there is nothing that inherently binds the PANA >> authentication to a particular (set of) PCP request(s). So, we will >> need to make sure that the information passed in the authentication >> option is sufficient for the sever to securely determine that the >> client sending a the PCP request is the same client that initiated the >> PANA exchange and vice versa, just as we would need to do if PANA and >> PCP were run on separate ports. I don't think this will be difficult, >> we just need to make sure that we achieve it. >> >> Do you know what existing PANA implementations will do if the >> "Reserved" field at the start of the packet is non-zero? > > Also, if an update to PANA allows 0b00000010 in that first octet, we will > have a problem. It would be safer if we assign the last two bits in that > first octet of PANA to must-be-zero. Perhaps via an Errata against the PANA > spec, if we decide this is the best solution. > >> We should also consider the trade-offs between a demultiplexing >> approach (which allows us to run PANA and PCP separately over a single >> port), and an encapsulation approach (PANA encapsulated in PCP). A >> demultiplexing approach is somewhat cleaner, in that we can process the >> whole message as a PANA or PCP message. But, the encapsulation >> approach would allow us to gain some optimization by piggy-backing the >> first (and possibly the final?) messages of the PANA exchange in the >> original PCP request (and response?) to cut down on the number of >> messages needed to create a secure mapping. > > How many messages are we talking about (5?), and how much reduction > could we see (reduction from 5 to 3??). > >> Since the PCP exchange may >> happen as part of client connection set-up (while a user is waiting), >> cutting down on the number of messages exchanged could be valuable. >> >> As discussed at the PCP meeting in Vancouver, we will be writing up >> both of these approaches soon, for further discussion on an interim >> phone call. > > Looking forward to that. > > -d > > >> Margaret >> >> >> On Aug 6, 2012, at 3:43 PM, Alper Yegin wrote: >> >> >> >> PANA: >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 >> 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> | Reserved | Message Length >> | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> | Flags | Message Type >> | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> | Session Identifier >> | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> | Sequence Number >> | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+ >> | AVPs ... >> +-+-+-+-+-+-+-+-+-+-+-+-+- >> >> >> Reserved >> >> This 16-bit field is reserved for future use. It MUST be >> set to >> zero and ignored by the receiver. >> >> >> >> >> PCP: >> >> >> 0 1 2 >> 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 >> 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> | Version = 2 |R| Opcode | Reserved >> | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> | Requested Lifetime (32 bits) >> | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> | >> | >> | PCP Client's IP Address (128 bits) >> | >> | >> | >> | >> | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> : >> : >> : (optional) Opcode-specific information >> : >> : >> : >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> : >> : >> : (optional) PCP Options >> : >> : >> : >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> +-+-+ >> >> >> First octet can be used for demux'ing. >> >> Alper >> >> >> >> >> >> On Aug 6, 2012, at 9:01 PM, Dan Wing wrote: >> >> >> -----Original Message----- >> >> >> From: pcp-bounces@ietf.org [mailto:pcp- >> bounces@ietf.org] On Behalf Of >> >> >> Alper Yegin >> >> >> Sent: Thursday, August 02, 2012 2:31 PM >> >> >> To: pcp@ietf.org >> >> >> Subject: [pcp] Comparison of PCP authentication >> >> >> >> http://www.ietf.org/proceedings/84/slides/slides-84- >> pcp-10.pdf >> >> >> >> Ah, isn't it odd that this beauty contest is run by >> one of the >> >> >> contestants? This material should have been prepared >> and presented by a >> >> >> neutral party. >> >> >> >> One important question: With this proposal, are the >> authors advocating >> >> >> each protocol should come with their own in-band key >> management, more >> >> >> specifically embedding an EAP transport? >> >> >> >> >> what's the big deal of using the same port > vs >> different port? Is >> >> >> jamming all in the same port is a benefit? >> >> >> >> "TLS is in-band" >> >> >> >> - There's standalone use of TLS as "a separate" KMP. >> RFC 5705 is driven >> >> >> by the fact that some other protocols need to use > TLS >> as a "separate >> >> >> KMP". >> >> >> - TLS is basically "transport layer security", >> something that sits >> >> >> below the protocol one would be trying to secure. We >> are not doing >> >> >> that. >> >> >> >> To throw another TLS thing into the mix: >> >> DTLS-SRTP [RFC5764] uses the (D)TLS handshake to encrypt >> SRTP and is >> pretty well aligned with what we want for PCP -- we want a >> key >> exchange and then run the PCP protocol natively. DTLS-SRTP >> has a >> normal DTLS handshake, followed by SRTP packets that appear >> normal >> on the wire (that is, the packets are RFC3711 packets which >> have >> their RTP headers in the clear). It does this over the >> same socket, >> because the first byte indicates if the packet is DTLS, >> SRTP, or >> STUN (ICE), http://tools.ietf.org/html/rfc5764#section- >> 5.1.2. >> >> At the meeting, I suggested we consider if PANA and PCP >> could >> be similarly demux'd. Stuart suggested using some sort of >> GRE- >> like header if they cannot be demux'd. Either approach >> would >> eliminate one of the objections of PANA, specifically its >> use >> of a separate port. >> >> -d >> >> >> >> >> >> are the EAP and PCP state machines > compatible? >> If marrying two >> >> >> protocols, one needs to pay attention to this. This >> was one of the >> >> >> reasons why EAPoDHCP did not work. >> >> >> >> Does the EAP-over-PCP satisfy the "EAP lower >> layer requirements" as >> >> >> stated in RFC 3848? I had asked this question but >> don't remember seeing >> >> >> any response. >> >> >> >> "Possible in-band optimization". Is this >> documented anywhere? It's >> >> >> not easy to understand how it works by looking at >> this slide. >> >> >> >> PANA RFC 5191 was published in 2008, not > 2011. >> It's adopted by Zigbee >> >> >> IP, ETSI TISPAN, and also ETSI M2M. Aside from two >> open-source >> >> >> implementations, multiple commercial implementations >> have successfully >> >> >> passed interop events in Zigbee Alliance. >> >> >> >> >> >> * Need to specify the portions of PANA that don't >> need to be >> >> >> implemented >> >> >> >> in a PCP PANA Client and Server (such as IP Address >> >> >> reconfiguration) >> >> >> >> >> >> this is just a single bit flag. We don't use it, >> and that's >> >> >> all we need to do about it. >> >> >> * Need to specify/describe interface between PANA > and >> PCP elements >> >> >> >> >> this is an implementation issue, like how the >> other spec >> >> >> implementors would need to define the interface >> between the EAP and PCP >> >> >> for passing keys, etc. >> >> >> >> * Need to specify how the PANA client finds the >> correct PANA Server >> >> >> for PCP Authentication (may be passed from PCP >> client?) >> >> >> >> >> PCP server the the PAA are the same node. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >> >> > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From dthaler@microsoft.com Mon Aug 6 18:34:45 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0789321F8691 for ; Mon, 6 Aug 2012 18:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=-1.297, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SXWBjjFvkvj for ; Mon, 6 Aug 2012 18:34:44 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id D67F121F867F for ; Mon, 6 Aug 2012 18:34:43 -0700 (PDT) Received: from mail56-ch1-R.bigfish.com (10.43.68.235) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Tue, 7 Aug 2012 01:34:42 +0000 Received: from mail56-ch1 (localhost [127.0.0.1]) by mail56-ch1-R.bigfish.com (Postfix) with ESMTP id AF14A3002C5; Tue, 7 Aug 2012 01:34:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VS-31(zzbb2dI98dI9371I146fI542M1432I4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail56-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail56-ch1 (localhost.localdomain [127.0.0.1]) by mail56-ch1 (MessageSwitch) id 134430328128187_13122; Tue, 7 Aug 2012 01:34:41 +0000 (UTC) Received: from CH1EHSMHS005.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail56-ch1.bigfish.com (Postfix) with ESMTP id 0501A3800F8; Tue, 7 Aug 2012 01:34:41 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 7 Aug 2012 01:34:40 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 7 Aug 2012 01:34:39 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.309.3; Mon, 6 Aug 2012 18:34:39 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Mon, 6 Aug 2012 18:34:39 -0700 From: Dave Thaler To: "Tirumaleswar Reddy (tireddy)" , "Reinaldo Penno (repenno)" , "pcp@ietf.org" Thread-Topic: [pcp] Comments on draft-ietf-pcp-dhcp-03 Thread-Index: AQHNcZ+sIMSFRn6eBkOpyqHfeftPVJdIXN9Q///nFoCAAERGIIADsTUAgAFcHhA= Date: Tue, 7 Aug 2012 01:34:38 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B73D410@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B7380B2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B73881F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <913383AAA69FF945B8F946018B75898A1477C15D@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A1477C15D@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [pcp] Comments on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 01:34:45 -0000 > -----Original Message----- > From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > Sent: Sunday, August 5, 2012 2:46 PM > To: Dave Thaler; Reinaldo Penno (repenno); pcp@ietf.org > Subject: RE: [pcp] Comments on draft-ietf-pcp-dhcp-03 >=20 > Hi - >=20 > I think we need to clarify in the draft when multiple PCP server names/IP > addresses will be returned by the DHCP server, for example like multi-hom= ing > case. A small number of examples might be nice, but I don't think it can ever be = complete, and so we shouldn't try to enumerate all possible cases. > Considering various other cases other than multi-homing >=20 > [1]In High Availability mode of NAT/Firewall devices (Active/Passive Mode= ), > PCP client still gets just one IP address. >=20 > [2] For example in the draft http://tools.ietf.org/html/draft-rpcw-pcp-pm= ipv6- > serv-discovery-00 where selected traffic is offload at the local access n= etwork. > Mobile Node is provided only the PCP server address in the Local Access > Network and MAG decides if the PCP request will be handled by Home networ= k > or Local Access Network. >=20 > [3] In Enterprise use case there could be two to three different possibil= ities >=20 > a)All the traffic from the branches tunneled back to the head office wher= e > there is a NAT/Firewall device. >=20 > b)Split Tunneling - In this case branch site itself would have NAT/Firewa= ll to > handle traffic to Internet. > How will the DHCP server be populated with the right Firewall/NAT IP > addresses in this case ? >=20 > [4] > Finally we will also need to solve the problem with just IPv6 (NPTv6, Fir= ewall) > where there is no DHCPv6 server. > From RFC6106 > "RA-based DNS configuration is a useful alternative in networks where an = IPv6 > host's address is auto-configured through IPv6 stateless address auto- > configuration and where there is either no DHCPv6 infrastructure at all o= r > some hosts do not have a DHCPv6 client" I (with no hats) disagree that a no-DHCPv6 server case needs to be solved b= y this WG. -Dave =20 > --Tiru. >=20 > > -----Original Message----- > > From: Dave Thaler [mailto:dthaler@microsoft.com] > > Sent: Friday, August 03, 2012 2:30 PM > > To: Reinaldo Penno (repenno); pcp@ietf.org > > Subject: Re: [pcp] Comments on draft-ietf-pcp-dhcp-03 > > > > Responding on list for benefit of others, although we already talked > > in person... > > > > > -----Original Message----- > > > From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] > > > Sent: Friday, August 03, 2012 11:18 AM > > > To: Dave Thaler; pcp@ietf.org > > > Subject: Re: Comments on draft-ietf-pcp-dhcp-03 > > > > > > On 8/3/12 10:53 AM, "Dave Thaler" wrote: > > > > > > >> -----Original Message----- > > > >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On > > > >> Behalf > > Of > > > >> Reinaldo Penno (repenno) > > > >> Sent: Friday, August 03, 2012 10:45 AM > > > >> To: pcp@ietf.org > > > >> Subject: [pcp] Comments on draft-ietf-pcp-dhcp-03 > > > >> > > > >> After reviewing draft-ietf-pcp-dhcp-03 I believe there are some > > > >> things I believe we need to tie up. > > > > > > > >I agree. > > > > > > > >> When a PCP Client contacts PCP Servers in parallel, say, IPx1, > > IPy1 > > > >> and > > > >> IPz1 as mentioned in draft and all respond then: > > > >> > > > >> 1 - What happens to the state in y1 and z1 if PCP Client chooses > > x1 > > > >> to communicate? Probably let it age out or delete mappings. > > > > > > > >What do you mean by "chooses x1"? > > > > > > That's what we find in section 6.2 > > > > Yes but the text is lacking, as this exchange shows. > > > > > >if we're talking about MAP (for a > > > >listening application) do you mean when x, y, and y are all NATs > > rather > > > >than FWs, and the client app can only deal with one external IP > > > >address? > > > > > > The draft says as soon as one PCP Server responds successfully it > > sticks to it. > > > So, I'm assuming other PCP Server are not contacted further and > > mappings > > > will time out or need to be deleted. > > > > > > As a side effect why would an app get 3 external IP:ports for the > > same > > > purpose and consume three times the state. It seems to me a side > > effect of > > > the wording more than something the app really needs. > > > > Two reasons (cases): > > a) there's different networks it's providing the same service on, e.g. > > via the Internet and via some other network. > > b) for failover purposes. For example, if it uses SRV records, it'd > > have > > 3 SRV records. If one NAT goes down, the other end will > > automatically > > use a different IP:port pair (which might be via a different ISP). > > Otherwise > > the failover time is capped at the TTL of the SRV record, and we > > know > > DNS TTLs below around 30 seconds aren't respected by many DNS > > servers. > > So having multiple records provides sub-30-second failover. > > > > > >If they're firewalls (so the external IP address/port isn't > > different), > > > >or if the client app can deal with multiple external IP/ports, then > > I > > > >don't think it would choose one. > > > > > > What's the use case for three? > > > > Answered above. Note I'm not saying three is appropriate in all > > cases. > > Only that there is a use case, and the choice is up to the client, > > which is the only entity that knows the use case. > > > > > Anyway, this exchange is telling in light of > > > > > > "Once the PCP Client has successfully > > > received a response from a PCP Server on that interface, it sends > > > subsequent PCP requests to that same server until that PCP Server > > > becomes non-responsive," > > > > > > > > > > >> 2 - If there is a failure on x1 and PCP Client decides to > > communicate > > > >>with y1, there might be some 'leftover' mappings for internal > > IP:port > > > >>(see 1). > > > >> PCP Client will need to delete or reuse existing state in y1. > > > >>Important to notice that there is no way to guarantee that PCP > > Server > > > >>will allocate same external IP:ports. > > > >> > > > >> 3 - I guess it is assumed that if PCP Server is co-located with > > NAT, > > > >>if > > > >>x1 fails, > > > >> traffic (PCP and data) will be diverted to y1. > > > > > > > >Unclear which model you're referring to (different external IP:port > > or > > > >same external IP:port), can you clarify your question? > > > > > > The app needs one external IP:port to announce on the external world > > > through, say, DynDDNS client. Why it would need three _different_? > > > If > > it > > > needs them, fine, not sure about use case. But if it gets 3 as a > > collateral effect > > > of the bootstrap procedure there is no way to guarantee they will be > > the > > > same. > > > > Answered above. > > > > -Dave > > > > > >> 4 - Related (2). The draft says that when a PCP Server is > > unreachable > > > >>(say, y1) PCP Client will continue to try to communicate even > > though > > > >>other PCP Server are available. The only way to 'communicate' is > > > >>sending a request, which might create state. So, when y1 is back > > up. > > > >>y1 might allocate a different external IP:port than other server. > > > >> > > > >> Thanks, > > > >> > > > >> Reinaldo > > > > >=20 From tireddy@cisco.com Mon Aug 6 19:10:24 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE5121F84EB for ; Mon, 6 Aug 2012 19:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrnGetOm0uQN for ; Mon, 6 Aug 2012 19:10:19 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9A84C21F8661 for ; Mon, 6 Aug 2012 19:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=8403; q=dns/txt; s=iport; t=1344305418; x=1345515018; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZH9129EABGKOAysXO/lekAJJJ36lgGz0aPHk7hByFjA=; b=kc7QbToPcmGHZ904frUc5jQ+Gr7GIJzhl6sdH7aYyCLJmFIPEapxzQ2y fEqzjZcclRiqxvAnX4NvzuV91WLADtokJk4wF2ilNuLUcK6HeBpXqhdXZ dUNTvMeVt3mdzdV0V3Yt7P+Z/ych2tIzzhQGb8Y1TbYbHwMsa8bo8EKap g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJV4IFCtJXHB/2dsb2JhbABFuVGBB4IgAQEBAwESASdEBwQCAQgOAwQBAQEKFAkHMhQJCAIEARIIGodlBgubFaBBi0qGDWADll2NEoFmgl8 X-IronPort-AV: E=Sophos;i="4.77,724,1336348800"; d="scan'208";a="109019059" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 07 Aug 2012 02:10:18 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q772AH6g011205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Aug 2012 02:10:17 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Mon, 6 Aug 2012 21:10:17 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Dave Thaler , "Reinaldo Penno (repenno)" , "pcp@ietf.org" Thread-Topic: [pcp] Comments on draft-ietf-pcp-dhcp-03 Thread-Index: AQHNcnNckAHLzaHHt0W3VNgj76hdP5dLnPPQgAJLlQD//64KoA== Date: Tue, 7 Aug 2012 02:10:17 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1477DD69@xmb-rcd-x10.cisco.com> References: <9B57C850BB53634CACEC56EF4853FF653B7380B2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B73881F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <913383AAA69FF945B8F946018B75898A1477C15D@xmb-rcd-x10.cisco.com> <9B57C850BB53634CACEC56EF4853FF653B73D410@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B73D410@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.78.199] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19090.001 x-tm-as-result: No--65.078600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Comments on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 02:10:24 -0000 > A small number of examples might be nice, but I don't think it can ever > be complete, > and so we shouldn't try to enumerate all possible cases. Yes, we need some examples. --Tiru. > -----Original Message----- > From: Dave Thaler [mailto:dthaler@microsoft.com] > Sent: Tuesday, August 07, 2012 7:05 AM > To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); > pcp@ietf.org > Subject: RE: [pcp] Comments on draft-ietf-pcp-dhcp-03 >=20 > > -----Original Message----- > > From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > > Sent: Sunday, August 5, 2012 2:46 PM > > To: Dave Thaler; Reinaldo Penno (repenno); pcp@ietf.org > > Subject: RE: [pcp] Comments on draft-ietf-pcp-dhcp-03 > > > > Hi - > > > > I think we need to clarify in the draft when multiple PCP server > names/IP > > addresses will be returned by the DHCP server, for example like > multi-homing > > case. >=20 > A small number of examples might be nice, but I don't think it can ever > be complete, > and so we shouldn't try to enumerate all possible cases. >=20 > > Considering various other cases other than multi-homing > > > > [1]In High Availability mode of NAT/Firewall devices (Active/Passive > Mode), > > PCP client still gets just one IP address. > > > > [2] For example in the draft http://tools.ietf.org/html/draft-rpcw- > pcp-pmipv6- > > serv-discovery-00 where selected traffic is offload at the local > access network. > > Mobile Node is provided only the PCP server address in the Local > Access > > Network and MAG decides if the PCP request will be handled by Home > network > > or Local Access Network. > > > > [3] In Enterprise use case there could be two to three different > possibilities > > > > a)All the traffic from the branches tunneled back to the head office > where > > there is a NAT/Firewall device. > > > > b)Split Tunneling - In this case branch site itself would have > NAT/Firewall to > > handle traffic to Internet. > > How will the DHCP server be populated with the right Firewall/NAT IP > > addresses in this case ? > > > > [4] > > Finally we will also need to solve the problem with just IPv6 (NPTv6, > Firewall) > > where there is no DHCPv6 server. > > From RFC6106 > > "RA-based DNS configuration is a useful alternative in networks where > an IPv6 > > host's address is auto-configured through IPv6 stateless address > auto- > > configuration and where there is either no DHCPv6 infrastructure at > all or > > some hosts do not have a DHCPv6 client" >=20 > I (with no hats) disagree that a no-DHCPv6 server case needs to be > solved by this WG. >=20 > -Dave >=20 > > --Tiru. > > > > > -----Original Message----- > > > From: Dave Thaler [mailto:dthaler@microsoft.com] > > > Sent: Friday, August 03, 2012 2:30 PM > > > To: Reinaldo Penno (repenno); pcp@ietf.org > > > Subject: Re: [pcp] Comments on draft-ietf-pcp-dhcp-03 > > > > > > Responding on list for benefit of others, although we already > talked > > > in person... > > > > > > > -----Original Message----- > > > > From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] > > > > Sent: Friday, August 03, 2012 11:18 AM > > > > To: Dave Thaler; pcp@ietf.org > > > > Subject: Re: Comments on draft-ietf-pcp-dhcp-03 > > > > > > > > On 8/3/12 10:53 AM, "Dave Thaler" wrote: > > > > > > > > >> -----Original Message----- > > > > >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On > > > > >> Behalf > > > Of > > > > >> Reinaldo Penno (repenno) > > > > >> Sent: Friday, August 03, 2012 10:45 AM > > > > >> To: pcp@ietf.org > > > > >> Subject: [pcp] Comments on draft-ietf-pcp-dhcp-03 > > > > >> > > > > >> After reviewing draft-ietf-pcp-dhcp-03 I believe there are > some > > > > >> things I believe we need to tie up. > > > > > > > > > >I agree. > > > > > > > > > >> When a PCP Client contacts PCP Servers in parallel, say, IPx1, > > > IPy1 > > > > >> and > > > > >> IPz1 as mentioned in draft and all respond then: > > > > >> > > > > >> 1 - What happens to the state in y1 and z1 if PCP Client > chooses > > > x1 > > > > >> to communicate? Probably let it age out or delete mappings. > > > > > > > > > >What do you mean by "chooses x1"? > > > > > > > > That's what we find in section 6.2 > > > > > > Yes but the text is lacking, as this exchange shows. > > > > > > > >if we're talking about MAP (for a > > > > >listening application) do you mean when x, y, and y are all NATs > > > rather > > > > >than FWs, and the client app can only deal with one external IP > > > > >address? > > > > > > > > The draft says as soon as one PCP Server responds successfully it > > > sticks to it. > > > > So, I'm assuming other PCP Server are not contacted further and > > > mappings > > > > will time out or need to be deleted. > > > > > > > > As a side effect why would an app get 3 external IP:ports for the > > > same > > > > purpose and consume three times the state. It seems to me a side > > > effect of > > > > the wording more than something the app really needs. > > > > > > Two reasons (cases): > > > a) there's different networks it's providing the same service on, > e.g. > > > via the Internet and via some other network. > > > b) for failover purposes. For example, if it uses SRV records, > it'd > > > have > > > 3 SRV records. If one NAT goes down, the other end will > > > automatically > > > use a different IP:port pair (which might be via a different > ISP). > > > Otherwise > > > the failover time is capped at the TTL of the SRV record, and we > > > know > > > DNS TTLs below around 30 seconds aren't respected by many DNS > > > servers. > > > So having multiple records provides sub-30-second failover. > > > > > > > >If they're firewalls (so the external IP address/port isn't > > > different), > > > > >or if the client app can deal with multiple external IP/ports, > then > > > I > > > > >don't think it would choose one. > > > > > > > > What's the use case for three? > > > > > > Answered above. Note I'm not saying three is appropriate in all > > > cases. > > > Only that there is a use case, and the choice is up to the client, > > > which is the only entity that knows the use case. > > > > > > > Anyway, this exchange is telling in light of > > > > > > > > "Once the PCP Client has successfully > > > > received a response from a PCP Server on that interface, it > sends > > > > subsequent PCP requests to that same server until that PCP > Server > > > > becomes non-responsive," > > > > > > > > > > > > > >> 2 - If there is a failure on x1 and PCP Client decides to > > > communicate > > > > >>with y1, there might be some 'leftover' mappings for internal > > > IP:port > > > > >>(see 1). > > > > >> PCP Client will need to delete or reuse existing state in y1. > > > > >>Important to notice that there is no way to guarantee that PCP > > > Server > > > > >>will allocate same external IP:ports. > > > > >> > > > > >> 3 - I guess it is assumed that if PCP Server is co-located > with > > > NAT, > > > > >>if > > > > >>x1 fails, > > > > >> traffic (PCP and data) will be diverted to y1. > > > > > > > > > >Unclear which model you're referring to (different external > IP:port > > > or > > > > >same external IP:port), can you clarify your question? > > > > > > > > The app needs one external IP:port to announce on the external > world > > > > through, say, DynDDNS client. Why it would need three > _different_? > > > > If > > > it > > > > needs them, fine, not sure about use case. But if it gets 3 as a > > > collateral effect > > > > of the bootstrap procedure there is no way to guarantee they will > be > > > the > > > > same. > > > > > > Answered above. > > > > > > -Dave > > > > > > > >> 4 - Related (2). The draft says that when a PCP Server is > > > unreachable > > > > >>(say, y1) PCP Client will continue to try to communicate even > > > though > > > > >>other PCP Server are available. The only way to 'communicate' > is > > > > >>sending a request, which might create state. So, when y1 is > back > > > up. > > > > >>y1 might allocate a different external IP:port than other > server. > > > > >> > > > > >> Thanks, > > > > >> > > > > >> Reinaldo > > > > > > > > >=20 From zhangdacheng@huawei.com Mon Aug 6 20:52:58 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A2C21F86A7 for ; Mon, 6 Aug 2012 20:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.942 X-Spam-Level: X-Spam-Status: No, score=-4.942 tagged_above=-999 required=5 tests=[AWL=1.657, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0-C6gIqjdHI for ; Mon, 6 Aug 2012 20:52:57 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFA021F86A4 for ; Mon, 6 Aug 2012 20:52:57 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIO77089; Mon, 06 Aug 2012 19:52:57 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 6 Aug 2012 20:50:31 -0700 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 6 Aug 2012 20:50:30 -0700 Received: from SZXEML528-MBX.china.huawei.com ([169.254.4.120]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 7 Aug 2012 11:50:25 +0800 From: "Zhangdacheng (Dacheng)" To: Sam Hartman , Margaret Wasserman Thread-Topic: [pcp] Comparison of PCP authentication Thread-Index: AQHNdC241F5Ai0qa4kawmCOKzP6BvpdNsgiw Date: Tue, 7 Aug 2012 03:50:24 +0000 Message-ID: References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <075301cd7419$19557dd0$4c007970$@com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pcp@ietf.org" Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 03:52:58 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Sam > Hartman > Sent: Tuesday, August 07, 2012 7:47 AM > To: Margaret Wasserman > Cc: pcp@ietf.org > Subject: Re: [pcp] Comparison of PCP authentication >=20 > I actually don't think you can gain much value from encapsulation. > The issue is that you'll need to resend the PCP request once you have a > key available. >=20 > At least in the case where the client wants authentication, you cannot > save a half round trip through encapsulation. I think in the same way. We used to mention this in the authentication draf= t. There is a concern of this approach. If a server have to maintain additi= on information before the success of authentication, the server may be more= vulnerable to DOS attack. Attackers can send fake authentication requests = appending PCP requests in order to consume the server's memory resources. > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From alper.yegin@yegin.org Tue Aug 7 00:49:20 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8FA21F858E for ; Tue, 7 Aug 2012 00:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gy3bKAcxNysm for ; Tue, 7 Aug 2012 00:49:20 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 4C53521F853D for ; Tue, 7 Aug 2012 00:49:20 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MDyul-1SyQbe35DT-00GuxU; Tue, 07 Aug 2012 03:49:18 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> Date: Tue, 7 Aug 2012 10:48:58 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <241D4228-E4FE-454A-9C3B-CA34C16D666E@yegin.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> To: Margaret Wasserman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:np7hQOHKe/hKhvfv5tfeXNOwhvyqnoNUjcevSIx9RO6 bIC6RPw8piPYgmRLi1GpuRDJRG1WJEmx2anYxN0HkclvxMtLVV IWtfS0MFcAte/jpvsycg7RMa+6tNsQ/095y26hRzB/2RynjrAJ 0cecgyNAv1dR7XHnRb8gm6fzlRz35Oxaz9c1DvinOfsQ3D4gMP OojdsWXmPmR4kW2bA1xTfnelgf781yCKHei+08I0KlzVIpDGqZ 7hBiUa8NevZo1hiUGkCIeQ0XQ+igx5TQzo/qyz4f6ay4PvAEIM uywqdv3uWVJkG98Jn08Irmnp3hX2FksXuuwMh0f3pgiiYaNSyW 3neSR08VAlUH9d0W631n6LNI6UB+bPH3nCcl7n9bT23ahqFNd5 jLiY5b4H3i2gg== Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 07:49:21 -0000 Hi Margaret, > Since this is UDP, there is nothing that inherently binds the PANA = authentication to a particular (set of) PCP request(s). So, we will = need to make sure that the information passed in the authentication = option is sufficient for the sever to securely determine that the client = sending a the PCP request is the same client that initiated the PANA = exchange and vice versa, just as we would need to do if PANA and PCP = were run on separate ports. I don't think this will be difficult, we = just need to make sure that we achieve it. >=20 That's right. PANA session will generate a Session-Id, Key-Id, and a PCP key. We = should use the two identifiers along with the MIC generated using the = PCP key in Authentication Tag Option. That's how PANA session and PCP = messages get crypto-bound to each other. > Do you know what existing PANA implementations will do if the = "Reserved" field at the start of the packet is non-zero?=20 >=20 According to the RFC 5191, receiver MUST ignore the Reserved bits. Alper From alper.yegin@yegin.org Tue Aug 7 01:11:07 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADB121F85AD for ; Tue, 7 Aug 2012 01:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zesjq-MMej3F for ; Tue, 7 Aug 2012 01:11:05 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id B4C1321F8624 for ; Tue, 7 Aug 2012 01:11:05 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MFLYq-1SvPEP0B4G-00F02y; Tue, 07 Aug 2012 04:10:56 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <5020688F.4060004@toshiba.co.jp> Date: Tue, 7 Aug 2012 11:10:38 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <955DC538-A1D9-4B19-B1A5-A7741EA7FB35@yegin.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <075301cd7419$19557dd0$4c007970$@com> <5020688F.4060004@toshiba.co.jp> To: Yoshihiro Ohba X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:jrVWfuKJBQQqbvYsMOJX2g8QlKYuSmqQnfeOWG8tdwn tY+TVckizwKQJFDwQ6F/N+8VIZlsZNoNh5wLS/sJe4uv5y1d+V vcJScbIudzMParde+0DefNBNtspBk4gGJBqYLWHQ6NEW/yK8gN HzG8aZCdYk0WIMrKrHjFhxRsmpyipcEFAWgMYckbYS+rHOWqJ3 DqFD+YMf/wBKmWMqgjjVy1uXVxHWYiLdD7Yrkx5b8DkzZS+Xbc usOjA306p1nEhLMAvRQaEgz9VdFyUWtjRZJ5VBXAKVB9VO0+cE rlX8QIiEpkZ2ZbUN/IaZcOAQbnftGV1fkaEHEC3LIYhhtTf2Le 2BFf99eYJ5jxcnNk1oFrbfi9V2yk09oIcnJvEjfCRT1S2nnZCu fTPFNPScUmeYw== Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 08:11:07 -0000 >> Also, if an update to PANA allows 0b00000010 in that first octet, we = will >> have a problem. It would be safer if we assign the last two bits in = that >> first octet of PANA to must-be-zero. Perhaps via an Errata against = the PANA >> spec, if we decide this is the best solution. >=20 >=20 > If we specify a new use of PANA "Reserved" field, it cannot be an > Errata because it is not a specification error. It needs to be a new > RFC that updates RFC 5191. Those bits are reserved for "future."=20 And because of this demux design, "now" we want to make sure no one will = ever set bit#7. What we need is to allocate that bit and state it's always set to 0. I = don't think we need a separate RFC for this, this'd be the RFC that = defines how PANA and PCP are used together. Alper =20 From mrw@lilacglade.org Tue Aug 7 03:07:30 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787B221F866C for ; Tue, 7 Aug 2012 03:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.708 X-Spam-Level: X-Spam-Status: No, score=-95.708 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ireNRqmEbcLt for ; Tue, 7 Aug 2012 03:07:29 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id DA90321F860D for ; Tue, 7 Aug 2012 03:07:29 -0700 (PDT) Received: from lilac-too.home (permutation-city.suchdamage.org [69.25.196.28]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id DB1942023F; Tue, 7 Aug 2012 06:07:28 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <241D4228-E4FE-454A-9C3B-CA34C16D666E@yegin.org> Date: Tue, 7 Aug 2012 06:07:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6388F89E-C081-4C48-890C-8D99128A7B1C@lilacglade.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <241D4228-E4FE-454A-9C3B-CA34C16D666E@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 10:07:30 -0000 On Aug 7, 2012, at 3:48 AM, Alper Yegin wrote: > That's right. > PANA session will generate a Session-Id, Key-Id, and a PCP key. We = should use the two identifiers along with the MIC generated using the = PCP key in Authentication Tag Option. That's how PANA session and PCP = messages get crypto-bound to each other. We should also do something (a hash, or whatever) to bind those keys to = the contents of a specific request, so that we can be sure that the = contents of the request haven't been modified/replaced. If we include a = time and/or the transaction ID in the hash, I think we can guard against = replay attacks that way. I think that would do it. Much of this is the same, whether we use a demultiplexing approach or an = encapsulation approach, and much of it would apply to a PCP-specific = mechanism as well. Margaret From mrw@lilacglade.org Tue Aug 7 03:14:12 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E7021F866E for ; Tue, 7 Aug 2012 03:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.708 X-Spam-Level: X-Spam-Status: No, score=-95.708 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n60f+YQLrhsE for ; Tue, 7 Aug 2012 03:14:11 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 65E4421F867A for ; Tue, 7 Aug 2012 03:14:11 -0700 (PDT) Received: from lilac-too.home (permutation-city.suchdamage.org [69.25.196.28]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id B9348200E1; Tue, 7 Aug 2012 06:14:10 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <955DC538-A1D9-4B19-B1A5-A7741EA7FB35@yegin.org> Date: Tue, 7 Aug 2012 06:14:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <28610FE5-6528-4AF1-B081-6B21AB4F0010@lilacglade.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <075301cd7419$19557dd0$4c007970$@com> <5020688F.4060004@toshiba.co.jp> <955DC538-A1D9-4B19-B1A5-A7741EA7FB35@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 10:14:12 -0000 On Aug 7, 2012, at 4:10 AM, Alper Yegin wrote: > Those bits are reserved for "future."=20 > And because of this demux design, "now" we want to make sure no one = will ever set bit#7. > What we need is to allocate that bit and state it's always set to 0. I = don't think we need a separate RFC for this, this'd be the RFC that = defines how PANA and PCP are used together. Right. If we choose the demultiplexing option, the RFC that defines how = to run PANA and PCP together will Update the PANA RFC to allocate = certain bits in the first octet. We might or might not choose to update = PANA in other ways, depending on whether we decide to include a TLV = indicating that the request is for PCP authentication vs. network access = authentication. Margaret From alper.yegin@yegin.org Tue Aug 7 03:55:33 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D783921F84F4 for ; Tue, 7 Aug 2012 03:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibdfHUtSceE7 for ; Tue, 7 Aug 2012 03:55:33 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 12FC321F84E4 for ; Tue, 7 Aug 2012 03:55:33 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0M8kOC-1StAb60nUa-00CE8s; Tue, 07 Aug 2012 06:55:32 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <6388F89E-C081-4C48-890C-8D99128A7B1C@lilacglade.org> Date: Tue, 7 Aug 2012 13:55:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2DE4A4B1-FCF9-4E6F-8239-E3A546DB44B7@yegin.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <241D4228-E4FE-454A-9C3B-CA34C16D666E@yegin.org> <6388F89E-C081-4C48-890C-8D99128A7B1C@lilacglade.org> To: Margaret Wasserman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:9BN/+ofDXjoE7PAp16OUsEu90DGMEATQBSlAIVBzffc h2zehMpwwIYfsVj45cUov/9ThEcgwVjLQgCC1r6smYEcTjP+v3 gOAjlaRv+fFjpVIbj7rl3yERbDTkgqTGhuljwy67frRRPnZBgs HuiI3EyE+6eNtjUzAYNePKgq77s+DWEMu0Kf29ABKCREN0nVbx tSN1QRkrqqjwNns9aBTcsa3dw0bzuYGNVTm5RPrZXLQwiCC8oF 2TxjhJvQ0LW1SdS2aqGTjXubfPT7/QiewF6vzSWmKAZtAoCYOG ncHKskfPZMoQ29ZE2z/TAp61i5lclVnEaa47K5MHOhT9D7rIsn NhDjec1ZG4rfRhrZBu/xd0oOTiZdMkP3rz5GMUTMBIxrRYvBbX 5tkvrnE1vA38A== Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 10:55:34 -0000 On Aug 7, 2012, at 1:07 PM, Margaret Wasserman wrote: >=20 > On Aug 7, 2012, at 3:48 AM, Alper Yegin wrote: >> That's right. >> PANA session will generate a Session-Id, Key-Id, and a PCP key. We = should use the two identifiers along with the MIC generated using the = PCP key in Authentication Tag Option. That's how PANA session and PCP = messages get crypto-bound to each other. >=20 > We should also do something (a hash, or whatever) to bind those keys = to the contents of a specific request, Authentication Data field of the Authentication Tag Option in your I-D = does that. > so that we can be sure that the contents of the request haven't been = modified/replaced. If we include a time and/or the transaction ID in = the hash, I think we can guard against replay attacks that way. I think = that would do it. >=20 Yes. Alper > Much of this is the same, whether we use a demultiplexing approach or = an encapsulation approach, and much of it would apply to a PCP-specific = mechanism as well. >=20 > Margaret >=20 >=20 >=20 From mohamed.boucadair@orange.com Tue Aug 7 05:56:08 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5507421F8468 for ; Tue, 7 Aug 2012 05:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[AWL=-1.131, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9dySKPu4UPK for ; Tue, 7 Aug 2012 05:56:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id AAA5A21F8609 for ; Tue, 7 Aug 2012 05:56:06 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 1300C3241D1; Tue, 7 Aug 2012 14:56:05 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id EC87E35C045; Tue, 7 Aug 2012 14:56:04 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Tue, 7 Aug 2012 14:55:51 +0200 From: To: "Tirumaleswar Reddy (tireddy)" , "pcp@ietf.org" Date: Tue, 7 Aug 2012 14:55:50 +0200 Thread-Topic: [pcp] Comments on draft-ietf-pcp-dhcp-03 Thread-Index: AQHNcnNckAHLzaHHt0W3VNgj76hdP5dLnPPQgAJLlQD//64KoIAAvAJQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E4CD30245@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B7380B2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B73881F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <913383AAA69FF945B8F946018B75898A1477C15D@xmb-rcd-x10.cisco.com> <9B57C850BB53634CACEC56EF4853FF653B73D410@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <913383AAA69FF945B8F946018B75898A1477DD69@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A1477DD69@xmb-rcd-x10.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.7.101815 Subject: Re: [pcp] Comments on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 12:56:08 -0000 Dear Tiru, I added this text to the draft to reflect your comment: Multiple Names may be configured to a PCP Client in some deployment contexts such as multi-homing. It is out of scope of this document to enumerate all deployment scenarios which require multiple Names to be configured. Cheers, Med=20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Tirumaleswar Reddy (tireddy) >Envoy=E9 : mardi 7 ao=FBt 2012 04:10 >=C0 : Dave Thaler; Reinaldo Penno (repenno); pcp@ietf.org >Objet : Re: [pcp] Comments on draft-ietf-pcp-dhcp-03 > >> A small number of examples might be nice, but I don't think=20 >it can ever >> be complete, >> and so we shouldn't try to enumerate all possible cases. > >Yes, we need some examples. > >--Tiru. > >> -----Original Message----- >> From: Dave Thaler [mailto:dthaler@microsoft.com] >> Sent: Tuesday, August 07, 2012 7:05 AM >> To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); >> pcp@ietf.org >> Subject: RE: [pcp] Comments on draft-ietf-pcp-dhcp-03 >>=20 >> > -----Original Message----- >> > From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] >> > Sent: Sunday, August 5, 2012 2:46 PM >> > To: Dave Thaler; Reinaldo Penno (repenno); pcp@ietf.org >> > Subject: RE: [pcp] Comments on draft-ietf-pcp-dhcp-03 >> > >> > Hi - >> > >> > I think we need to clarify in the draft when multiple PCP server >> names/IP >> > addresses will be returned by the DHCP server, for example like >> multi-homing >> > case. >>=20 >> A small number of examples might be nice, but I don't think=20 >it can ever >> be complete, >> and so we shouldn't try to enumerate all possible cases. >>=20 >> > Considering various other cases other than multi-homing >> > >> > [1]In High Availability mode of NAT/Firewall devices=20 >(Active/Passive >> Mode), >> > PCP client still gets just one IP address. >> > >> > [2] For example in the draft http://tools.ietf.org/html/draft-rpcw- >> pcp-pmipv6- >> > serv-discovery-00 where selected traffic is offload at the local >> access network. >> > Mobile Node is provided only the PCP server address in the Local >> Access >> > Network and MAG decides if the PCP request will be handled by Home >> network >> > or Local Access Network. >> > >> > [3] In Enterprise use case there could be two to three different >> possibilities >> > >> > a)All the traffic from the branches tunneled back to the=20 >head office >> where >> > there is a NAT/Firewall device. >> > >> > b)Split Tunneling - In this case branch site itself would have >> NAT/Firewall to >> > handle traffic to Internet. >> > How will the DHCP server be populated with the right=20 >Firewall/NAT IP >> > addresses in this case ? >> > >> > [4] >> > Finally we will also need to solve the problem with just=20 >IPv6 (NPTv6, >> Firewall) >> > where there is no DHCPv6 server. >> > From RFC6106 >> > "RA-based DNS configuration is a useful alternative in=20 >networks where >> an IPv6 >> > host's address is auto-configured through IPv6 stateless address >> auto- >> > configuration and where there is either no DHCPv6 infrastructure at >> all or >> > some hosts do not have a DHCPv6 client" >>=20 >> I (with no hats) disagree that a no-DHCPv6 server case needs to be >> solved by this WG. >>=20 >> -Dave >>=20 >> > --Tiru. >> > >> > > -----Original Message----- >> > > From: Dave Thaler [mailto:dthaler@microsoft.com] >> > > Sent: Friday, August 03, 2012 2:30 PM >> > > To: Reinaldo Penno (repenno); pcp@ietf.org >> > > Subject: Re: [pcp] Comments on draft-ietf-pcp-dhcp-03 >> > > >> > > Responding on list for benefit of others, although we already >> talked >> > > in person... >> > > >> > > > -----Original Message----- >> > > > From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] >> > > > Sent: Friday, August 03, 2012 11:18 AM >> > > > To: Dave Thaler; pcp@ietf.org >> > > > Subject: Re: Comments on draft-ietf-pcp-dhcp-03 >> > > > >> > > > On 8/3/12 10:53 AM, "Dave Thaler"=20 > wrote: >> > > > >> > > > >> -----Original Message----- >> > > > >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On >> > > > >> Behalf >> > > Of >> > > > >> Reinaldo Penno (repenno) >> > > > >> Sent: Friday, August 03, 2012 10:45 AM >> > > > >> To: pcp@ietf.org >> > > > >> Subject: [pcp] Comments on draft-ietf-pcp-dhcp-03 >> > > > >> >> > > > >> After reviewing draft-ietf-pcp-dhcp-03 I believe there are >> some >> > > > >> things I believe we need to tie up. >> > > > > >> > > > >I agree. >> > > > > >> > > > >> When a PCP Client contacts PCP Servers in parallel,=20 >say, IPx1, >> > > IPy1 >> > > > >> and >> > > > >> IPz1 as mentioned in draft and all respond then: >> > > > >> >> > > > >> 1 - What happens to the state in y1 and z1 if PCP Client >> chooses >> > > x1 >> > > > >> to communicate? Probably let it age out or delete mappings. >> > > > > >> > > > >What do you mean by "chooses x1"? >> > > > >> > > > That's what we find in section 6.2 >> > > >> > > Yes but the text is lacking, as this exchange shows. >> > > >> > > > >if we're talking about MAP (for a >> > > > >listening application) do you mean when x, y, and y=20 >are all NATs >> > > rather >> > > > >than FWs, and the client app can only deal with one=20 >external IP >> > > > >address? >> > > > >> > > > The draft says as soon as one PCP Server responds=20 >successfully it >> > > sticks to it. >> > > > So, I'm assuming other PCP Server are not contacted further and >> > > mappings >> > > > will time out or need to be deleted. >> > > > >> > > > As a side effect why would an app get 3 external=20 >IP:ports for the >> > > same >> > > > purpose and consume three times the state. It seems to=20 >me a side >> > > effect of >> > > > the wording more than something the app really needs. >> > > >> > > Two reasons (cases): >> > > a) there's different networks it's providing the same service on, >> e.g. >> > > via the Internet and via some other network. >> > > b) for failover purposes. For example, if it uses SRV records, >> it'd >> > > have >> > > 3 SRV records. If one NAT goes down, the other end will >> > > automatically >> > > use a different IP:port pair (which might be via a different >> ISP). >> > > Otherwise >> > > the failover time is capped at the TTL of the SRV=20 >record, and we >> > > know >> > > DNS TTLs below around 30 seconds aren't respected by many DNS >> > > servers. >> > > So having multiple records provides sub-30-second failover. >> > > >> > > > >If they're firewalls (so the external IP address/port isn't >> > > different), >> > > > >or if the client app can deal with multiple external IP/ports, >> then >> > > I >> > > > >don't think it would choose one. >> > > > >> > > > What's the use case for three? >> > > >> > > Answered above. Note I'm not saying three is appropriate in all >> > > cases. >> > > Only that there is a use case, and the choice is up to=20 >the client, >> > > which is the only entity that knows the use case. >> > > >> > > > Anyway, this exchange is telling in light of >> > > > >> > > > "Once the PCP Client has successfully >> > > > received a response from a PCP Server on that interface, it >> sends >> > > > subsequent PCP requests to that same server until that PCP >> Server >> > > > becomes non-responsive," >> > > > >> > > > > >> > > > >> 2 - If there is a failure on x1 and PCP Client decides to >> > > communicate >> > > > >>with y1, there might be some 'leftover' mappings=20 >for internal >> > > IP:port >> > > > >>(see 1). >> > > > >> PCP Client will need to delete or reuse existing=20 >state in y1. >> > > > >>Important to notice that there is no way to=20 >guarantee that PCP >> > > Server >> > > > >>will allocate same external IP:ports. >> > > > >> >> > > > >> 3 - I guess it is assumed that if PCP Server is co-located >> with >> > > NAT, >> > > > >>if >> > > > >>x1 fails, >> > > > >> traffic (PCP and data) will be diverted to y1. >> > > > > >> > > > >Unclear which model you're referring to (different external >> IP:port >> > > or >> > > > >same external IP:port), can you clarify your question? >> > > > >> > > > The app needs one external IP:port to announce on the external >> world >> > > > through, say, DynDDNS client. Why it would need three >> _different_? >> > > > If >> > > it >> > > > needs them, fine, not sure about use case. But if it=20 >gets 3 as a >> > > collateral effect >> > > > of the bootstrap procedure there is no way to=20 >guarantee they will >> be >> > > the >> > > > same. >> > > >> > > Answered above. >> > > >> > > -Dave >> > > >> > > > >> 4 - Related (2). The draft says that when a PCP Server is >> > > unreachable >> > > > >>(say, y1) PCP Client will continue to try to=20 >communicate even >> > > though >> > > > >>other PCP Server are available. The only way to=20 >'communicate' >> is >> > > > >>sending a request, which might create state. So, when y1 is >> back >> > > up. >> > > > >>y1 might allocate a different external IP:port than other >> server. >> > > > >> >> > > > >> Thanks, >> > > > >> >> > > > >> Reinaldo >> > > >> > > >> > >>=20 > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp >= From mohamed.boucadair@orange.com Tue Aug 7 05:59:07 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DC921F8674 for ; Tue, 7 Aug 2012 05:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.553 X-Spam-Level: X-Spam-Status: No, score=-1.553 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsM1iuiQrWEe for ; Tue, 7 Aug 2012 05:59:06 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3086321F8652 for ; Tue, 7 Aug 2012 05:59:06 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 86EE622C4D9; Tue, 7 Aug 2012 14:59:05 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 6BB914C027; Tue, 7 Aug 2012 14:59:05 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Tue, 7 Aug 2012 14:58:53 +0200 From: To: Dave Thaler , "Reinaldo Penno (repenno)" , "pcp@ietf.org" Date: Tue, 7 Aug 2012 14:58:51 +0200 Thread-Topic: Comments on draft-ietf-pcp-dhcp-03 Thread-Index: AQHNcZ+sIMSFRn6eBkOpyqHfeftPVJdIXN9Q///nFoCAAERGIIAFzJYg Message-ID: <94C682931C08B048B7A8645303FDC9F36E4CD30247@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B7380B2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B73881F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B73881F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.7.101815 Subject: Re: [pcp] Comments on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 12:59:07 -0000 Dear all, I added this text to the draft: The discovery procedure may result in a PCP Client instantiating multiple mappings maintained by distinct PCP Servers. The decision to use all these mappings or delete some of them is deployment-specific. Only the client can decide whether all the mappings are needed or only a subset of them. I don't think we can say more in this draft. This is really a deployment-sp= ecific issue.=20 Cheers, Med=20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Dave Thaler >Envoy=E9 : vendredi 3 ao=FBt 2012 22:30 >=C0 : Reinaldo Penno (repenno); pcp@ietf.org >Objet : Re: [pcp] Comments on draft-ietf-pcp-dhcp-03 > >Responding on list for benefit of others, although we already >talked in person... > >> -----Original Message----- >> From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] >> Sent: Friday, August 03, 2012 11:18 AM >> To: Dave Thaler; pcp@ietf.org >> Subject: Re: Comments on draft-ietf-pcp-dhcp-03 >>=20 >> On 8/3/12 10:53 AM, "Dave Thaler" wrote: >>=20 >> >> -----Original Message----- >> >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org]=20 >On Behalf Of >> >> Reinaldo Penno (repenno) >> >> Sent: Friday, August 03, 2012 10:45 AM >> >> To: pcp@ietf.org >> >> Subject: [pcp] Comments on draft-ietf-pcp-dhcp-03 >> >> >> >> After reviewing draft-ietf-pcp-dhcp-03 I believe there are some >> >> things I believe we need to tie up. >> > >> >I agree. >> > >> >> When a PCP Client contacts PCP Servers in parallel, say,=20 >IPx1, IPy1 >> >> and >> >> IPz1 as mentioned in draft and all respond then: >> >> >> >> 1 - What happens to the state in y1 and z1 if PCP Client=20 >chooses x1 >> >> to communicate? Probably let it age out or delete mappings. >> > >> >What do you mean by "chooses x1"? >>=20 >> That's what we find in section 6.2 > >Yes but the text is lacking, as this exchange shows. > >> >if we're talking about MAP (for a >> >listening application) do you mean when x, y, and y are all=20 >NATs rather >> >than FWs, and the client app can only deal with one external IP >> >address? >>=20 >> The draft says as soon as one PCP Server responds=20 >successfully it sticks to it. >> So, I'm assuming other PCP Server are not contacted further=20 >and mappings >> will time out or need to be deleted. >>=20 >> As a side effect why would an app get 3 external IP:ports=20 >for the same >> purpose and consume three times the state. It seems to me a=20 >side effect of >> the wording more than something the app really needs. > >Two reasons (cases): >a) there's different networks it's providing the same service on, e.g. > via the Internet and via some other network. >b) for failover purposes. For example, if it uses SRV=20 >records, it'd have > 3 SRV records. If one NAT goes down, the other end will=20 >automatically > use a different IP:port pair (which might be via a=20 >different ISP). Otherwise > the failover time is capped at the TTL of the SRV record,=20 >and we know > DNS TTLs below around 30 seconds aren't respected by many=20 >DNS servers. > So having multiple records provides sub-30-second failover. > >> >If they're firewalls (so the external IP address/port isn't=20 >different), >> >or if the client app can deal with multiple external=20 >IP/ports, then I >> >don't think it would choose one. >>=20 >> What's the use case for three?=20 > >Answered above. Note I'm not saying three is appropriate in=20 >all cases. >Only that there is a use case, and the choice is up to the client, >which is the only entity that knows the use case. > >> Anyway, this exchange is telling in light of >>=20 >> "Once the PCP Client has successfully >> received a response from a PCP Server on that interface, it sends >> subsequent PCP requests to that same server until that PCP Server >> becomes non-responsive," >>=20 >> > >> >> 2 - If there is a failure on x1 and PCP Client decides to=20 >communicate >> >>with y1, there might be some 'leftover' mappings for=20 >internal IP:port >> >>(see 1). >> >> PCP Client will need to delete or reuse existing state in y1. >> >>Important to notice that there is no way to guarantee=20 >that PCP Server >> >>will allocate same external IP:ports. >> >> >> >> 3 - I guess it is assumed that if PCP Server is=20 >co-located with NAT, >> >>if >> >>x1 fails, >> >> traffic (PCP and data) will be diverted to y1. >> > >> >Unclear which model you're referring to (different external=20 >IP:port or >> >same external IP:port), can you clarify your question? >>=20 >> The app needs one external IP:port to announce on the external world >> through, say, DynDDNS client. Why it would need three=20 >_different_? If it >> needs them, fine, not sure about use case. But if it gets 3=20 >as a collateral effect >> of the bootstrap procedure there is no way to guarantee they=20 >will be the >> same. > >Answered above. > >-Dave >=20 >> >> 4 - Related (2). The draft says that when a PCP Server is=20 >unreachable >> >>(say, y1) PCP Client will continue to try to communicate=20 >even though >> >>other PCP Server are available. The only way to 'communicate' is >> >>sending a request, which might create state. So, when y1=20 >is back up. >> >>y1 might allocate a different external IP:port than other server. >> >> >> >> Thanks, >> >> >> >> Reinaldo=20 > > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp >= From internet-drafts@ietf.org Tue Aug 7 06:15:23 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2A721F8517; Tue, 7 Aug 2012 06:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FMVfr2dSKhc; Tue, 7 Aug 2012 06:15:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA1D21F841A; Tue, 7 Aug 2012 06:15:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120807131522.10467.31563.idtracker@ietfa.amsl.com> Date: Tue, 07 Aug 2012 06:15:22 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-dhcp-04.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 13:15:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Port Control Protocol Working Group of th= e IETF. Title : DHCP Options for the Port Control Protocol (PCP) Author(s) : Mohamed Boucadair Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-dhcp-04.txt Pages : 12 Date : 2012-08-07 Abstract: This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) Server names. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenario. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-dhcp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-dhcp-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-dhcp-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Tue Aug 7 06:41:45 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2C921F8692 for ; Tue, 7 Aug 2012 06:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6VQP2fk6A5N for ; Tue, 7 Aug 2012 06:41:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 957BD21F8690 for ; Tue, 7 Aug 2012 06:41:44 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 8012D2640A9 for ; Tue, 7 Aug 2012 15:41:43 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D0CA64C06F for ; Tue, 7 Aug 2012 15:41:42 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Tue, 7 Aug 2012 15:41:30 +0200 From: To: "pcp@ietf.org" Date: Tue, 7 Aug 2012 15:41:29 +0200 Thread-Topic: [pcp] I-D Action: draft-ietf-pcp-dhcp-04.txt Thread-Index: Ac10nrc/M/qUuVGpTxKNan5dJYkA3gAAD8BA Message-ID: <94C682931C08B048B7A8645303FDC9F36E4CD30282@PUEXCB1B.nanterre.francetelecom.fr> References: <20120807131522.10467.31563.idtracker@ietfa.amsl.com> In-Reply-To: <20120807131522.10467.31563.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.7.101815 Subject: Re: [pcp] I-D Action: draft-ietf-pcp-dhcp-04.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 13:41:45 -0000 Re-, This version integrates the comments received during the WGLC.=20 The main changes are: * rfc1035 encoding is not used * indicate rfc3396 mechanism is required for the dhcpv4 option * remove redundant text to a new sub-section * update the pcp server discovery section: indicate the procedure is not sp= ecific to dhcp A diff link is available here: http://www.ietf.org/rfcdiff?url2=3Ddraft-iet= f-pcp-dhcp-04 Cheers, Med >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de internet-drafts@ietf.org >Envoy=E9 : mardi 7 ao=FBt 2012 15:15 >=C0 : i-d-announce@ietf.org >Cc : pcp@ietf.org >Objet : [pcp] I-D Action: draft-ietf-pcp-dhcp-04.txt > > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. > This draft is a work item of the Port Control Protocol=20 >Working Group of the IETF. > > Title : DHCP Options for the Port Control=20 >Protocol (PCP) > Author(s) : Mohamed Boucadair > Reinaldo Penno > Dan Wing > Filename : draft-ietf-pcp-dhcp-04.txt > Pages : 12 > Date : 2012-08-07 > >Abstract: > This document specifies DHCP (IPv4 and IPv6) options to configure > hosts with Port Control Protocol (PCP) Server names. The use of > DHCPv4 or DHCPv6 depends on the PCP deployment scenario. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-pcp-dhcp > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-pcp-dhcp-04 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-dhcp-04 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp >= From yoshihiro.ohba@toshiba.co.jp Tue Aug 7 07:24:28 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A195B21F86C5 for ; Tue, 7 Aug 2012 07:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.322 X-Spam-Level: X-Spam-Status: No, score=-5.322 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcPNeQeL43TZ for ; Tue, 7 Aug 2012 07:24:27 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 040C821F86A0 for ; Tue, 7 Aug 2012 07:24:26 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q77EONKd005274; Tue, 7 Aug 2012 23:24:23 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q77EONTx008769; Tue, 7 Aug 2012 23:24:23 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id ZAA08768; Tue, 7 Aug 2012 23:24:23 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q77EONGr027522; Tue, 7 Aug 2012 23:24:23 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q77EONXm006760; Tue, 7 Aug 2012 23:24:23 +0900 (JST) Received: from [133.199.18.188] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0M8E00M232OMU110@mail.po.toshiba.co.jp>; Tue, 07 Aug 2012 23:24:23 +0900 (JST) Date: Tue, 07 Aug 2012 23:24:22 +0900 From: Yoshihiro Ohba In-reply-to: <955DC538-A1D9-4B19-B1A5-A7741EA7FB35@yegin.org> To: Alper Yegin Message-id: <50212516.5080902@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <075301cd7419$19557dd0$4c007970$@com> <5020688F.4060004@toshiba.co.jp> <955DC538-A1D9-4B19-B1A5-A7741EA7FB35@yegin.org> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 14:24:29 -0000 Alper, (2012/08/07 17:10), Alper Yegin wrote: >> >> If we specify a new use of PANA "Reserved" field, it cannot be an >> Errata because it is not a specification error. It needs to be a new >> RFC that updates RFC 5191. > > > Those bits are reserved for "future." > And because of this demux design, "now" we want to make sure no one will ever set bit#7. I think "no one will ever set bit#7" is too much restricted. Because of in-band key management, a bit in the PANA "Reserved" field to be used for demultiplexing "over PCP port" can be meaningful only when PANA message is carried "over the PCP port". The bit could also be used for demultiplexing other application carried over another port if the other application allows to use the bit for demultiplexing purpose as well. >From PANA perspective, we can now allocate the whole 16-bit "Reserved" PANA field for "in-band key management usage", and let each application including PCP define how to demultiplex using the 16-bit. I think this is a cleaner and extensible approach. Yoshihiro Ohba > What we need is to allocate that bit and state it's always set to 0. I don't think we need a separate RFC for this, this'd be the RFC that defines how PANA and PCP are used together. > > Alper > > > > > From alper.yegin@yegin.org Tue Aug 7 09:16:16 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AEF21F8792 for ; Tue, 7 Aug 2012 09:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcP77xhq65ed for ; Tue, 7 Aug 2012 09:16:15 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8164121F874C for ; Tue, 7 Aug 2012 09:16:13 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M6B3i-1TwuBe3ZMI-00xOvq; Tue, 07 Aug 2012 12:16:12 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-2022-jp From: Alper Yegin In-Reply-To: <50212516.5080902@toshiba.co.jp> Date: Tue, 7 Aug 2012 19:16:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2C42D4BA-608E-4A1F-8955-117E64E892FC@yegin.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <075301cd7419$19557dd0$4c007970$@com> <5020688F.4060004@toshiba.co.jp> <955DC538-A1D9-4B19-B1A5-A7741EA7FB35@yegin.org> <50212516.5080902@toshiba.co.jp> To: Yoshihiro Ohba X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:iVkDtVotKylyevqGVsFUMe1YiyWwoFlJ+3DMnnmKPdG 9cRQjNHwUF6L15MngPbmVbDXpDNBJKKmERisoy8ZHHPCQtM+tB sFTCkXTKDErfKL+VZ4Myy+d/oYGn8z5fivNmd5zdp35qh5Aw7I B9e8X06ABl54xTUeJUeXIeE92O3hbTf+c+v6EhuDiLMXkMBj82 xV5lYpESom0ZYW0pFKiUijJHkau5CWYr3HcDxEyCAQYMpu3SQn 3gV2x6LWn/dBT4xCqXVLH1gJkdYHrTNwXD450IFXKclRbOl7Bp +oUwrvVjuPJCMBovBWR8D6rQM2WDOsdcmC+3LK0cHYOyAX20AV r5GBdTqfSRpBXcJgmFASIWKbis4DpB0gEF8bGPknW9qj9wXzGF lYeVApASIev4g== Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 16:16:16 -0000 Hi Yoshi, >>>=20 >>> If we specify a new use of PANA "Reserved" field, it cannot be an >>> Errata because it is not a specification error. It needs to be a = new >>> RFC that updates RFC 5191. >>=20 >>=20 >> Those bits are reserved for "future." >> And because of this demux design, "now" we want to make sure no one = will ever set bit#7. >=20 > I think "no one will ever set bit#7" is too much restricted. >=20 > Because of in-band key management, a bit in the PANA "Reserved" field > to be used for demultiplexing "over PCP port" can be meaningful only > when PANA message is carried "over the PCP port". The bit could also > be used for demultiplexing other application carried over another port > if the other application allows to use the bit for demultiplexing > purpose as well. We can either say: Bit#7 is reserved for use with PCP. (And it's always set to 0). Or, When used over PCP port, Bit#7 is always set to 0. When used over other ports, its reserved for future use (as it currently = is). Latter one is more conservative about bit usage, but a bit more = cumbersome. Not sure which way to go. >=20 > =46rom PANA perspective, we can now allocate the whole 16-bit = "Reserved" > PANA field for "in-band key management usage", and let each > application including PCP define how to demultiplex using the 16-bit. > I think this is a cleaner and extensible approach. >=20 We may not want to give up on the 16-bit space for encoding one type of = usage (in-band). Let's think about this=1B$B!D=1B(B.. Alper > Yoshihiro Ohba >=20 >=20 >> What we need is to allocate that bit and state it's always set to 0. = I don't think we need a separate RFC for this, this'd be the RFC that = defines how PANA and PCP are used together. >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >=20 From mrw@lilacglade.org Tue Aug 7 10:30:31 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C988021F8604 for ; Tue, 7 Aug 2012 10:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.709 X-Spam-Level: X-Spam-Status: No, score=-95.709 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6g639ymjGRn for ; Tue, 7 Aug 2012 10:30:31 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 5185521F8602 for ; Tue, 7 Aug 2012 10:30:31 -0700 (PDT) Received: from [192.168.43.5] (permutation-city.suchdamage.org [69.25.196.28]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 500AC2021E; Tue, 7 Aug 2012 13:30:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <2C42D4BA-608E-4A1F-8955-117E64E892FC@yegin.org> Date: Tue, 7 Aug 2012 13:30:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4DB3175B-3234-42CC-8200-9FDDF1A04B5D@lilacglade.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <075301cd7419$19557dd0$4c007970$@com> <5020688F.4060004@toshiba.co.jp> <955DC538-A1D9-4B19-B1A5-A7741EA7FB35@yegin.org> <50212516.5080902@toshiba.co.jp> <2C42D4BA-608E-4A1F-8955-117E64E892FC@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 17:30:31 -0000 On Aug 7, 2012, at 12:16 PM, Alper Yegin wrote: > When used over PCP port, Bit#7 is always set to 0. > When used over other ports, its reserved for future use (as it = currently is). >=20 >=20 > Latter one is more conservative about bit usage, but a bit more = cumbersome. Not sure which way to go. The problem comes in when/if PCP wants to allocate another version = number. Could we use the top nibble (4 bits) for demultiplexing, and leave PCP = with a 4-bit version number, and PANA with 4 bits for future use? Margaret From hartmans@painless-security.com Tue Aug 7 11:01:21 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B88411E8097 for ; Tue, 7 Aug 2012 11:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.583 X-Spam-Level: * X-Spam-Status: No, score=1.583 tagged_above=-999 required=5 tests=[AWL=-2.705, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+VOscnKNtIv for ; Tue, 7 Aug 2012 11:01:20 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 47C6B21F86F7 for ; Tue, 7 Aug 2012 11:01:20 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 078DF2029E; Tue, 7 Aug 2012 14:01:19 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 344DD420E; Tue, 7 Aug 2012 14:01:14 -0400 (EDT) From: Sam Hartman To: "Zhangdacheng \(Dacheng\)" References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <075301cd7419$19557dd0$4c007970$@com> Date: Tue, 07 Aug 2012 14:01:14 -0400 In-Reply-To: (zhangdacheng@huawei.com's message of "Tue, 7 Aug 2012 03:50:24 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Margaret Wasserman , "pcp@ietf.org" Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 18:01:21 -0000 If you are concerned about server DOS issues, the general solution is to have the server send the client an encrypted cookie so the server maintains no state. See for example RFc 6113 section 5.2. That's a Kerberos mechanism but it has similar properties. EAP protocols have generally not done that, but it's certainly possibly to do with EAP-like things. We designed draft-ietf-abfab-gss-eap to permit extending to this use in the future if needed. The Moonshot implementation of draft-ietf-abfab-gss-eap supports the necessary mechanisms for no server state, demonstrating that it is possible. Everything I say here can be applied to PANA with a bit of creativity. From alper.yegin@yegin.org Tue Aug 7 13:58:20 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE2321F8589 for ; Tue, 7 Aug 2012 13:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibH2am5iRAe6 for ; Tue, 7 Aug 2012 13:58:19 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5DD21F8598 for ; Tue, 7 Aug 2012 13:58:19 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M3zbe-1Tq8E82NEI-00qvaf; Tue, 07 Aug 2012 16:58:12 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Tue, 7 Aug 2012 23:57:51 +0300 Content-Transfer-Encoding: 7bit Message-Id: <478EC6FB-18B8-46BC-8CEC-2EB9F0B339FE@yegin.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <075301cd7419$19557dd0$4c007970$@com> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:e8R46ZzyLcXD85cyI18dKZgjrei2OjVD9Qz5X2L5J/U YxcW693evlwi0Rty86e5a3/uQp3J4trDoOJ/Y7l9lBC4deVPHf 9VPjlB2s4HwNG6F/WSlVc+C7VYoTaonLzU3SqS6bK7nj7IfxTF VbClDvpm+0wXs9KxuK4DkJFayskyfc1F3E2SqCSCbih4VA1pBs 3YasvnrKfEpczBSwGxxcIXzUQNtYykq/VxQNxFI5uvtRNwTGpM 3OshVkn91bL+HVKwcxlia4tOBZjaAy463S1xE/F2zAO89tnzbA LxXbFrgREeEi19vybeGIE0m4f3ZmcyEeC8etY3cEyPtHvnJgaa 4P5sjpuJQhsT7Pn5Lca4n9nZDkLTFUjpN/oi79Uw1Sr/MzmwSi nSMY6F9pf6A1Q== Cc: Margaret Wasserman , "pcp@ietf.org" Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 20:58:20 -0000 On Aug 7, 2012, at 9:01 PM, Sam Hartman wrote: > If you are concerned about server DOS issues, the general solution is to > have the server send the client an encrypted cookie so the server > maintains no state. > See for example RFc 6113 section 5.2. > That's a Kerberos mechanism but it has similar properties. > > EAP protocols have generally not done that, but it's certainly possibly > to do with EAP-like things. We designed draft-ietf-abfab-gss-eap to > permit extending to this use in the future if needed. The Moonshot > implementation of draft-ietf-abfab-gss-eap supports the necessary > mechanisms for no server state, demonstrating that it is possible. > > Everything I say here can be applied to PANA with a bit of creativity. PANA itself already has that property. > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From mrw@lilacglade.org Tue Aug 7 14:10:20 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B6611E809B for ; Tue, 7 Aug 2012 14:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.708 X-Spam-Level: X-Spam-Status: No, score=-95.708 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJDuuRZuk8JD for ; Tue, 7 Aug 2012 14:10:19 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 753A721F85CC for ; Tue, 7 Aug 2012 14:10:19 -0700 (PDT) Received: from [192.168.43.5] (permutation-city.suchdamage.org [69.25.196.28]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 2BDDD2023F; Tue, 7 Aug 2012 17:10:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-12-994396974 From: Margaret Wasserman In-Reply-To: <478EC6FB-18B8-46BC-8CEC-2EB9F0B339FE@yegin.org> Date: Tue, 7 Aug 2012 17:10:16 -0400 Message-Id: <1F6F2A45-CCD3-4AEB-A127-EEC9E248532D@lilacglade.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <075301cd7419$19557dd0$4c007970$@com> <478EC6FB-18B8-46BC-8CEC-2EB9F0B339FE@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: "pcp@ietf.org" Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 21:10:20 -0000 --Apple-Mail-12-994396974 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Alper, On Aug 7, 2012, at 4:57 PM, Alper Yegin wrote: >>=20 >> Everything I say here can be applied to PANA with a bit of = creativity. >=20 > PANA itself already has that property. The specific discussion was about whether we can piggyback = authentication messages in the PCP request/response packets when PANA is = used in an encapsulated mode. So, while PANA itself may not require = server state, it can't (alone) prevent the PCP Server from needing to = maintain server state in this case. While we probably could achieve = this using encapsulated PANA, we would also need to do something to = retain the PCP Server state as part of the session. Margaret --Apple-Mail-12-994396974 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Everything I say here can be applied to PANA with a bit of = creativity.

PANA itself already has that = property.

The specific discussion = was about whether we can piggyback authentication messages in the PCP = request/response packets when PANA is used in an encapsulated mode. =  So, while PANA itself may not require server state, it can't = (alone) prevent the PCP Server from needing to maintain server state in = this case.  While we probably could achieve this using encapsulated = PANA, we would also need to do something to retain the PCP Server state = as part of the = session.

Margaret


= --Apple-Mail-12-994396974-- From yoshihiro.ohba@toshiba.co.jp Tue Aug 7 16:39:43 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2ED11E8105 for ; Tue, 7 Aug 2012 16:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.16 X-Spam-Level: X-Spam-Status: No, score=-3.16 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOtZaEJMQF5C for ; Tue, 7 Aug 2012 16:39:42 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 51CC911E8100 for ; Tue, 7 Aug 2012 16:39:41 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q77Ndfde022243; Wed, 8 Aug 2012 08:39:41 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q77Nderv004593; Wed, 8 Aug 2012 08:39:40 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id JAA04592; Wed, 8 Aug 2012 08:39:40 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q77Ndeg1015659; Wed, 8 Aug 2012 08:39:40 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q77NdesJ022912; Wed, 8 Aug 2012 08:39:40 +0900 (JST) Received: from [133.196.16.80] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0M8E00M3QSE3U1D0@mail.po.toshiba.co.jp>; Wed, 08 Aug 2012 08:39:40 +0900 (JST) Date: Wed, 08 Aug 2012 08:39:40 +0900 From: Yoshihiro Ohba In-reply-to: <2C42D4BA-608E-4A1F-8955-117E64E892FC@yegin.org> To: Alper Yegin Message-id: <5021A73C.1020407@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <075301cd7419$19557dd0$4c007970$@com> <5020688F.4060004@toshiba.co.jp> <955DC538-A1D9-4B19-B1A5-A7741EA7FB35@yegin.org> <50212516.5080902@toshiba.co.jp> <2C42D4BA-608E-4A1F-8955-117E64E892FC@yegin.org> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 23:39:43 -0000 Alper, (2012/08/08 1:16), Alper Yegin wrote: > Hi Yoshi, > >>>> >>>> If we specify a new use of PANA "Reserved" field, it cannot be an >>>> Errata because it is not a specification error. It needs to be a new >>>> RFC that updates RFC 5191. >>> >>> >>> Those bits are reserved for "future." >>> And because of this demux design, "now" we want to make sure no one will ever set bit#7. >> >> I think "no one will ever set bit#7" is too much restricted. >> >> Because of in-band key management, a bit in the PANA "Reserved" field >> to be used for demultiplexing "over PCP port" can be meaningful only >> when PANA message is carried "over the PCP port". The bit could also >> be used for demultiplexing other application carried over another port >> if the other application allows to use the bit for demultiplexing >> purpose as well. > > > We can either say: > > Bit#7 is reserved for use with PCP. (And it's always set to 0). This is over-specified as I explained above. > > Or, > > When used over PCP port, Bit#7 is always set to 0. > When used over other ports, its reserved for future use (as it currently is). > > > Latter one is more conservative about bit usage, but a bit more cumbersome. Not sure which way to go. > The latter one does not work. Once we define some PANA bits for in-band key management (for whatever application protocol), the same bits cannot be used for future new PANA extensions commonly applicable to both plain PANA and in-band PANA. Therefore, the bits won't be able to be marked as reserved any more once we give out. This is what I think: - Decide on how many bits (4 bits?) are needed from the 16-bit PANA "Reserved" field for in-band key management. - Write a new PANA I-D to allocate the in-band bits that are not bound to any specific application protocol in the I-D. Perhaps you and I can work on this. - Describe PCP-specific usage of the in-band bits in draft-ietf-pcp-authentication. > >> >> From PANA perspective, we can now allocate the whole 16-bit "Reserved" >> PANA field for "in-band key management usage", and let each >> application including PCP define how to demultiplex using the 16-bit. >> I think this is a cleaner and extensible approach. >> > > We may not want to give up on the 16-bit space for encoding one type of usage (in-band). Let's think about this$B!D(B.. > I agree with you that we don't need to give up on the whole 16-bit space. I think the top 4 bits should be sufficient as Margaret mentioned. Yoshihiro Ohba > Alper > > > > >> Yoshihiro Ohba >> >> >>> What we need is to allocate that bit and state it's always set to 0. I don't think we need a separate RFC for this, this'd be the RFC that defines how PANA and PCP are used together. >>> >>> Alper >>> >>> >>> >>> >>> >> > > From tireddy@cisco.com Tue Aug 7 23:03:22 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692DE11E8132 for ; Tue, 7 Aug 2012 23:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.129 X-Spam-Level: X-Spam-Status: No, score=-9.129 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1FVGvLvgX08 for ; Tue, 7 Aug 2012 23:03:20 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 759B011E812B for ; Tue, 7 Aug 2012 23:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=10510; q=dns/txt; s=iport; t=1344405800; x=1345615400; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=OY1cz76b8SCb2oKgZYBUnFkDUvOvLgMAnRkwJJPhrkI=; b=KP7G/JjF2WHma5Zo+mSRMK31i5aq5djlF3Yli1zs7Xxlv/gZD6Rh4Qnf n/8ilC2yqk+jbMDwSY+xU/S6BYepvEoGZ2ssnYEyewXeyVHyC3uMBO73U tkRYehhKquwyJIVw4C44sjP8Ah2jtCFeXvy3Qnan5ASBHxls6gQwVcbi5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABIAIlCtJXHB/2dsb2JhbABFuWyBB4IgAQEBAwEBAQEPAVsXBAIBCBEEAQEBCh0HJwsUCQgCBAESCBqHZQYLmlegQ4sPhgBgA4gYjkSNEoFmgl8 X-IronPort-AV: E=Sophos;i="4.77,730,1336348800"; d="scan'208";a="109248616" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 08 Aug 2012 06:03:19 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7863J2M027625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Aug 2012 06:03:19 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0298.004; Wed, 8 Aug 2012 01:03:19 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" , "pcp@ietf.org" Thread-Topic: [pcp] Comments on draft-ietf-pcp-dhcp-03 Thread-Index: AQHNcnNckAHLzaHHt0W3VNgj76hdP5dLnPPQgAJLlQD//64KoIAAvAJQgAEen5A= Date: Wed, 8 Aug 2012 06:03:18 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1477ED49@xmb-rcd-x10.cisco.com> References: <9B57C850BB53634CACEC56EF4853FF653B7380B2@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B73881F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <913383AAA69FF945B8F946018B75898A1477C15D@xmb-rcd-x10.cisco.com> <9B57C850BB53634CACEC56EF4853FF653B73D410@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <913383AAA69FF945B8F946018B75898A1477DD69@xmb-rcd-x10.cisco.com> <94C682931C08B048B7A8645303FDC9F36E4CD30245@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4CD30245@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.85.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19092.004 x-tm-as-result: No--63.545800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Comments on draft-ietf-pcp-dhcp-03 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 06:03:22 -0000 > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Tuesday, August 07, 2012 6:26 PM > To: Tirumaleswar Reddy (tireddy); pcp@ietf.org > Subject: RE: [pcp] Comments on draft-ietf-pcp-dhcp-03 >=20 > Dear Tiru, >=20 > I added this text to the draft to reflect your comment: >=20 > Multiple Names may be configured to a PCP Client in some deployment > contexts such as multi-homing. It is out of scope of this document > to enumerate all deployment scenarios which require multiple Names > to be configured. Hi Med - The text looks good. If you can highlight at least one use case of multi-ho= ming you have in mind that would be great (An example in the Appendix would= also work) --Tiru. >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la > >part de Tirumaleswar Reddy (tireddy) > >Envoy=E9 : mardi 7 ao=FBt 2012 04:10 > >=C0 : Dave Thaler; Reinaldo Penno (repenno); pcp@ietf.org > >Objet : Re: [pcp] Comments on draft-ietf-pcp-dhcp-03 > > > >> A small number of examples might be nice, but I don't think > >it can ever > >> be complete, > >> and so we shouldn't try to enumerate all possible cases. > > > >Yes, we need some examples. > > > >--Tiru. > > > >> -----Original Message----- > >> From: Dave Thaler [mailto:dthaler@microsoft.com] > >> Sent: Tuesday, August 07, 2012 7:05 AM > >> To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); > >> pcp@ietf.org > >> Subject: RE: [pcp] Comments on draft-ietf-pcp-dhcp-03 > >> > >> > -----Original Message----- > >> > From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > >> > Sent: Sunday, August 5, 2012 2:46 PM > >> > To: Dave Thaler; Reinaldo Penno (repenno); pcp@ietf.org > >> > Subject: RE: [pcp] Comments on draft-ietf-pcp-dhcp-03 > >> > > >> > Hi - > >> > > >> > I think we need to clarify in the draft when multiple PCP server > >> names/IP > >> > addresses will be returned by the DHCP server, for example like > >> multi-homing > >> > case. > >> > >> A small number of examples might be nice, but I don't think > >it can ever > >> be complete, > >> and so we shouldn't try to enumerate all possible cases. > >> > >> > Considering various other cases other than multi-homing > >> > > >> > [1]In High Availability mode of NAT/Firewall devices > >(Active/Passive > >> Mode), > >> > PCP client still gets just one IP address. > >> > > >> > [2] For example in the draft http://tools.ietf.org/html/draft- > rpcw- > >> pcp-pmipv6- > >> > serv-discovery-00 where selected traffic is offload at the local > >> access network. > >> > Mobile Node is provided only the PCP server address in the Local > >> Access > >> > Network and MAG decides if the PCP request will be handled by Home > >> network > >> > or Local Access Network. > >> > > >> > [3] In Enterprise use case there could be two to three different > >> possibilities > >> > > >> > a)All the traffic from the branches tunneled back to the > >head office > >> where > >> > there is a NAT/Firewall device. > >> > > >> > b)Split Tunneling - In this case branch site itself would have > >> NAT/Firewall to > >> > handle traffic to Internet. > >> > How will the DHCP server be populated with the right > >Firewall/NAT IP > >> > addresses in this case ? > >> > > >> > [4] > >> > Finally we will also need to solve the problem with just > >IPv6 (NPTv6, > >> Firewall) > >> > where there is no DHCPv6 server. > >> > From RFC6106 > >> > "RA-based DNS configuration is a useful alternative in > >networks where > >> an IPv6 > >> > host's address is auto-configured through IPv6 stateless address > >> auto- > >> > configuration and where there is either no DHCPv6 infrastructure > at > >> all or > >> > some hosts do not have a DHCPv6 client" > >> > >> I (with no hats) disagree that a no-DHCPv6 server case needs to be > >> solved by this WG. > >> > >> -Dave > >> > >> > --Tiru. > >> > > >> > > -----Original Message----- > >> > > From: Dave Thaler [mailto:dthaler@microsoft.com] > >> > > Sent: Friday, August 03, 2012 2:30 PM > >> > > To: Reinaldo Penno (repenno); pcp@ietf.org > >> > > Subject: Re: [pcp] Comments on draft-ietf-pcp-dhcp-03 > >> > > > >> > > Responding on list for benefit of others, although we already > >> talked > >> > > in person... > >> > > > >> > > > -----Original Message----- > >> > > > From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] > >> > > > Sent: Friday, August 03, 2012 11:18 AM > >> > > > To: Dave Thaler; pcp@ietf.org > >> > > > Subject: Re: Comments on draft-ietf-pcp-dhcp-03 > >> > > > > >> > > > On 8/3/12 10:53 AM, "Dave Thaler" > > wrote: > >> > > > > >> > > > >> -----Original Message----- > >> > > > >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On > >> > > > >> Behalf > >> > > Of > >> > > > >> Reinaldo Penno (repenno) > >> > > > >> Sent: Friday, August 03, 2012 10:45 AM > >> > > > >> To: pcp@ietf.org > >> > > > >> Subject: [pcp] Comments on draft-ietf-pcp-dhcp-03 > >> > > > >> > >> > > > >> After reviewing draft-ietf-pcp-dhcp-03 I believe there are > >> some > >> > > > >> things I believe we need to tie up. > >> > > > > > >> > > > >I agree. > >> > > > > > >> > > > >> When a PCP Client contacts PCP Servers in parallel, > >say, IPx1, > >> > > IPy1 > >> > > > >> and > >> > > > >> IPz1 as mentioned in draft and all respond then: > >> > > > >> > >> > > > >> 1 - What happens to the state in y1 and z1 if PCP Client > >> chooses > >> > > x1 > >> > > > >> to communicate? Probably let it age out or delete mappings. > >> > > > > > >> > > > >What do you mean by "chooses x1"? > >> > > > > >> > > > That's what we find in section 6.2 > >> > > > >> > > Yes but the text is lacking, as this exchange shows. > >> > > > >> > > > >if we're talking about MAP (for a > >> > > > >listening application) do you mean when x, y, and y > >are all NATs > >> > > rather > >> > > > >than FWs, and the client app can only deal with one > >external IP > >> > > > >address? > >> > > > > >> > > > The draft says as soon as one PCP Server responds > >successfully it > >> > > sticks to it. > >> > > > So, I'm assuming other PCP Server are not contacted further > and > >> > > mappings > >> > > > will time out or need to be deleted. > >> > > > > >> > > > As a side effect why would an app get 3 external > >IP:ports for the > >> > > same > >> > > > purpose and consume three times the state. It seems to > >me a side > >> > > effect of > >> > > > the wording more than something the app really needs. > >> > > > >> > > Two reasons (cases): > >> > > a) there's different networks it's providing the same service > on, > >> e.g. > >> > > via the Internet and via some other network. > >> > > b) for failover purposes. For example, if it uses SRV records, > >> it'd > >> > > have > >> > > 3 SRV records. If one NAT goes down, the other end will > >> > > automatically > >> > > use a different IP:port pair (which might be via a different > >> ISP). > >> > > Otherwise > >> > > the failover time is capped at the TTL of the SRV > >record, and we > >> > > know > >> > > DNS TTLs below around 30 seconds aren't respected by many DNS > >> > > servers. > >> > > So having multiple records provides sub-30-second failover. > >> > > > >> > > > >If they're firewalls (so the external IP address/port isn't > >> > > different), > >> > > > >or if the client app can deal with multiple external > IP/ports, > >> then > >> > > I > >> > > > >don't think it would choose one. > >> > > > > >> > > > What's the use case for three? > >> > > > >> > > Answered above. Note I'm not saying three is appropriate in > all > >> > > cases. > >> > > Only that there is a use case, and the choice is up to > >the client, > >> > > which is the only entity that knows the use case. > >> > > > >> > > > Anyway, this exchange is telling in light of > >> > > > > >> > > > "Once the PCP Client has successfully > >> > > > received a response from a PCP Server on that interface, it > >> sends > >> > > > subsequent PCP requests to that same server until that PCP > >> Server > >> > > > becomes non-responsive," > >> > > > > >> > > > > > >> > > > >> 2 - If there is a failure on x1 and PCP Client decides to > >> > > communicate > >> > > > >>with y1, there might be some 'leftover' mappings > >for internal > >> > > IP:port > >> > > > >>(see 1). > >> > > > >> PCP Client will need to delete or reuse existing > >state in y1. > >> > > > >>Important to notice that there is no way to > >guarantee that PCP > >> > > Server > >> > > > >>will allocate same external IP:ports. > >> > > > >> > >> > > > >> 3 - I guess it is assumed that if PCP Server is co-located > >> with > >> > > NAT, > >> > > > >>if > >> > > > >>x1 fails, > >> > > > >> traffic (PCP and data) will be diverted to y1. > >> > > > > > >> > > > >Unclear which model you're referring to (different external > >> IP:port > >> > > or > >> > > > >same external IP:port), can you clarify your question? > >> > > > > >> > > > The app needs one external IP:port to announce on the external > >> world > >> > > > through, say, DynDDNS client. Why it would need three > >> _different_? > >> > > > If > >> > > it > >> > > > needs them, fine, not sure about use case. But if it > >gets 3 as a > >> > > collateral effect > >> > > > of the bootstrap procedure there is no way to > >guarantee they will > >> be > >> > > the > >> > > > same. > >> > > > >> > > Answered above. > >> > > > >> > > -Dave > >> > > > >> > > > >> 4 - Related (2). The draft says that when a PCP Server is > >> > > unreachable > >> > > > >>(say, y1) PCP Client will continue to try to > >communicate even > >> > > though > >> > > > >>other PCP Server are available. The only way to > >'communicate' > >> is > >> > > > >>sending a request, which might create state. So, when y1 is > >> back > >> > > up. > >> > > > >>y1 might allocate a different external IP:port than other > >> server. > >> > > > >> > >> > > > >> Thanks, > >> > > > >> > >> > > > >> Reinaldo > >> > > > >> > > > >> > > >> > > > >_______________________________________________ > >pcp mailing list > >pcp@ietf.org > >https://www.ietf.org/mailman/listinfo/pcp > > From dwing@cisco.com Wed Aug 8 10:02:47 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1061F21F8717 for ; Wed, 8 Aug 2012 10:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.498 X-Spam-Level: X-Spam-Status: No, score=-110.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94ubJaM1f1s3 for ; Wed, 8 Aug 2012 10:02:45 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D005C21F8712 for ; Wed, 8 Aug 2012 10:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3804; q=dns/txt; s=iport; t=1344445366; x=1345654966; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=3h3WmSs+NAUL6DgrciGhOw7bJc8Ug8YV8kN3GdN3dr4=; b=Rxm0xha+zCJ0AyONBgC0zBlHdkeR026cL199P7vVKytjFzrTA4FQUlYX rTdOIkL7LsKAseAwYNpIniemQbCsEuHFyAw8ofW7qBM+BHZB084sD9e+h PuI18tI+h5OuKXC681gUgGG8TzmXKqaPvUn3kT+ABkM2HfEmcgSGBvLhs 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAMeaIlCrRDoH/2dsb2JhbABFqhePRYEHgiABAQEDAQEBAQUKARQBAhA0EAcBAwIJDwIEAQEBJwcZDhUKCQgBAQQBEgsXh2UFDJsAjWOSVgSLEoZgA4hOhQyWGIFmgn+BNgc X-IronPort-AV: E=Sophos;i="4.77,733,1336348800"; d="scan'208";a="54450819" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 08 Aug 2012 17:02:45 +0000 Received: from dwingWS (sjc-vpn4-1372.cisco.com [10.21.85.91]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q78H2ihu009620; Wed, 8 Aug 2012 17:02:44 GMT From: "Dan Wing" To: "'james woodyatt'" , References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> In-Reply-To: Date: Wed, 8 Aug 2012 10:02:44 -0700 Message-ID: <003b01cd7587$a111b760$e3352620$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac10J67eOOhE5zD1Qz6jxkYshqojrwBXmD7w Content-Language: en-us Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 17:02:47 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > james woodyatt > Sent: Monday, August 06, 2012 4:03 PM > To: pcp@ietf.org > Subject: Re: [pcp] Comparison of PCP authentication > > On Aug 6, 2012, at 13:02 , Margaret Wasserman > wrote: > > > > Do you know what existing PANA implementations will do if the > "Reserved" field at the start of the packet is non-zero? > > A related question might be what existing NAT-PMP implementations will > do if they receive a message containing a PANA packet. That is important to consider. However, the message flows I have seen show: PCP client PCP server | | 1. |------PCP MAP request-------------->| 2. |<---error, need authentication------| | | 3. |-(several authentication messages)->| 4. |<-(several authentication messages)-| If the PCP client is really communicating with a NAT-PMP server, it would look like this, PCP client NAT-PMP server | | 1. |------PCP MAP request-------------->| 2. |<---error, wrong version------------| | | 3. |------NAT-PMP request-------------->| 4. |<---ok------------------------------| | | So, I think we are okay -- assuming we keep the idea that the PCP client tries to first send a PCP request (and not to first send a PANA request). However, I do worry that implementations may optimize themselves to send a PANA request first, which would cause the problem you describe if they send the PANA request to a NAT-PMP server. That is, this would be a problem: PCP client NAT-PMP server | | 1. |-------(authentication message)---->| 2. |<--NAT-PMP error--------------------| | | But the PCP client doesn't speak NAT-PMP, so there isn't a way for it to handle that case, anyway (no matter if we had PCP authentication or not). In summary, I think we can skate around problems with talking to a NAT-PMP server. -d > Assuming they > comply with I-D.cheshire-nat-pmp-03, they will interpret the first two > octets of a PANA message as an announcement request, and they will > reply with the announcement response message shown below. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vers = 0 | OP = 128 + 0 | Result Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Seconds Since Start of Epoch | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | External IP Address (a.b.c.d) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > If a PCP server needs to implement NAT-PMP too, then it can easily > distinguish a NAT-PMP announcement request from a PANA message, but one > wonders if a PANA client expecting to authenticate to such a server can > deal with replies from a NAT-PMP server that knows nothing about either > PCP or NAT-PMP. > > > -- > james woodyatt > member of technical staff, core os networking > > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From mrw@lilacglade.org Wed Aug 8 10:07:14 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6424321F8499 for ; Wed, 8 Aug 2012 10:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.709 X-Spam-Level: X-Spam-Status: No, score=-95.709 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DELnFFfN2dz5 for ; Wed, 8 Aug 2012 10:07:13 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id B02CA21F846F for ; Wed, 8 Aug 2012 10:07:11 -0700 (PDT) Received: from lilac-too.home (permutation-city.suchdamage.org [69.25.196.28]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 5EF8D2014C; Wed, 8 Aug 2012 13:07:10 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <003b01cd7587$a111b760$e3352620$@com> Date: Wed, 8 Aug 2012 13:07:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 17:07:14 -0000 On Aug 8, 2012, at 1:02 PM, Dan Wing wrote: > So, I think we are okay -- assuming we keep the idea that the PCP=20 > client tries to first send a PCP request (and not to first send > a PANA request). =20 Actually, we don't keep this, even now. There is certainly a notion = that a client could be configured to use authentication for all (or = some) PCP exchanges, and that the authentication would come first. =20 > However, I do worry that implementations may optimize themselves > to send a PANA request first, which would cause the problem you > describe if they send the PANA request to a NAT-PMP server. That > is, this would be a problem: >=20 > PCP client NAT-PMP server > | | =20 > 1. |-------(authentication message)---->| > 2. |<--NAT-PMP error--------------------| > | |=20 >=20 > But the PCP client doesn't speak NAT-PMP, so there isn't a way > for it to handle that case, anyway (no matter if we had PCP > authentication or not). >=20 > In summary, I think we can skate around problems with talking > to a NAT-PMP server. Makes sense. Margaret From hartmans@painless-security.com Wed Aug 8 10:47:08 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8742C21F86B9 for ; Wed, 8 Aug 2012 10:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.791 X-Spam-Level: * X-Spam-Status: No, score=1.791 tagged_above=-999 required=5 tests=[AWL=-2.497, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeOagNQuMsIM for ; Wed, 8 Aug 2012 10:47:08 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1283D21F86B7 for ; Wed, 8 Aug 2012 10:47:07 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id BF54E2014C; Wed, 8 Aug 2012 13:47:06 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 97B5D420E; Wed, 8 Aug 2012 13:47:04 -0400 (EDT) From: Sam Hartman To: Margaret Wasserman References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> Date: Wed, 08 Aug 2012 13:47:04 -0400 In-Reply-To: <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> (Margaret Wasserman's message of "Wed, 8 Aug 2012 13:07:09 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 17:47:08 -0000 It's not just that implementations may optimize sending an authentication request. An implementation MAY require authentication. I.E. it is unwilling to send the request unless it has an authenticated channel. For firewall control this makes a lot of sense. From dwing@cisco.com Wed Aug 8 10:57:18 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C9211E80BA for ; Wed, 8 Aug 2012 10:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.5 X-Spam-Level: X-Spam-Status: No, score=-110.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZWOuABxzcWK for ; Wed, 8 Aug 2012 10:57:18 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 38AB521F86D3 for ; Wed, 8 Aug 2012 10:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2622; q=dns/txt; s=iport; t=1344448638; x=1345658238; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=O0LHvWUsU5dipF4uUBtu2THnuzfc3WIbHiYjd9XOkBo=; b=UCUukPSTZpcxpiiVcR3+meaUfiZ/HTOHqGbw8WAGGbtIVPZ320YXQWkz Nj/ISkynHDFE8b2Q4VkczFz2Uvvuox/MDLRP1eet8RY4Ru4H02qLzVHtg d3gLpuudGmUKHGPzibcWUlQpDDnDTxnXOV6279XgHzoZ8JfWNKaO9YIGK A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAMOnIlCrRDoJ/2dsb2JhbABFqhiPRYEHgiABAQECAQEICgEUAQIQPwUHAQMCCQ4BAgQBAQEnBxkjCgkIAQEEARILF4dlBQybC41jkmWLEoZgA4hOhQyJA40VgWaCf4E2Bw X-IronPort-AV: E=Sophos;i="4.77,734,1336348800"; d="scan'208";a="51883513" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 08 Aug 2012 17:57:18 +0000 Received: from dwingWS (sjc-vpn4-1372.cisco.com [10.21.85.91]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q78HvHVc013460; Wed, 8 Aug 2012 17:57:17 GMT From: "Dan Wing" To: "'Margaret Wasserman'" , References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> In-Reply-To: <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> Date: Wed, 8 Aug 2012 10:57:17 -0700 Message-ID: <008801cd758f$3fd306e0$bf7914a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac11iEIv+Oqb1SnqQpao1sut0wysUgABe/7Q Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 17:57:18 -0000 > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@lilacglade.org] > Sent: Wednesday, August 08, 2012 10:07 AM > To: Dan Wing > Cc: 'james woodyatt'; pcp@ietf.org > Subject: Re: [pcp] Comparison of PCP authentication > > > On Aug 8, 2012, at 1:02 PM, Dan Wing wrote: > > So, I think we are okay -- assuming we keep the idea that the PCP > > client tries to first send a PCP request (and not to first send > > a PANA request). > > Actually, we don't keep this, even now. There is certainly a notion > that a client could be configured to use authentication for all (or > some) PCP exchanges, and that the authentication would come first. But slide 5 of your deck, http://tools.ietf.org/agenda/84/slides/slides-84-pcp-10.pdf, shows the PCP client doing an initial PCP request and getting an AUTH_REQUIRED error. That is the basis of my (lovely) ASCII artistry. > > However, I do worry that implementations may optimize themselves > > to send a PANA request first, which would cause the problem you > > describe if they send the PANA request to a NAT-PMP server. That > > is, this would be a problem: > > > > PCP client NAT-PMP server > > | | > > 1. |-------(authentication message)---->| > > 2. |<--NAT-PMP error--------------------| > > | | > > > > But the PCP client doesn't speak NAT-PMP, so there isn't a way > > for it to handle that case, anyway (no matter if we had PCP > > authentication or not). > > > > In summary, I think we can skate around problems with talking > > to a NAT-PMP server. > > Makes sense. Sam Hartman wrote: > It's not just that implementations may optimize sending an > authentication request. > > An implementation MAY require authentication. > I.E. it is unwilling to send the request unless it has an authenticated > channel. > For firewall control this makes a lot of sense. I believe we are okay -- the PCP client trying to do authentication will have to expect it will occasionally see a NAT-PMP error message. That will occur if it is communicating with a NAT-PMP server (which shares the same port as PCP). If the PCP client receives a NAT-PMP error, it needs to abort trying to do PCP and abort trying to do PANA (because neither will work); in the (unlikely) event the PCP client also implements NAT-PMP, it can then downgrade to using NAT-PMP. A sentence or three in draft-ietf-pcp-authentication will be needed to explain that a NAT-PMP error might be received. -d From zhangdacheng@huawei.com Wed Aug 8 18:59:02 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA9121F8585 for ; Wed, 8 Aug 2012 18:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.274 X-Spam-Level: X-Spam-Status: No, score=-5.274 tagged_above=-999 required=5 tests=[AWL=1.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRKzrntMZXMi for ; Wed, 8 Aug 2012 18:59:01 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 381AA21F857D for ; Wed, 8 Aug 2012 18:59:01 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIR21716; Wed, 08 Aug 2012 17:59:01 -0800 (PST) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 8 Aug 2012 18:56:37 -0700 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 8 Aug 2012 18:56:42 -0700 Received: from SZXEML528-MBX.china.huawei.com ([169.254.4.120]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Thu, 9 Aug 2012 09:56:35 +0800 From: "Zhangdacheng (Dacheng)" To: Dan Wing , 'Margaret Wasserman' , "hartmans@painless-security.com" Thread-Topic: [pcp] Comparison of PCP authentication Thread-Index: AQHNcPYy1F5Ai0qa4kawmCOKzP6BvpdMkuOAgAAcnICAAAVlgIAAMmWAgAK/7wCAAAE8gIAADgKAgAEKIIA= Date: Thu, 9 Aug 2012 01:56:34 +0000 Message-ID: References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> In-Reply-To: <008801cd758f$3fd306e0$bf7914a0$@com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pcp@ietf.org" Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 01:59:02 -0000 Slide 5 only illustrates a scenario where the pcp server initiates the auth= entication procedure. But in our draft, it is also described that the clien= t can initiate authentication proactively. In my opinion, this approach see= ms even more preferable. ^_^ > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dan > Wing > Sent: Thursday, August 09, 2012 1:57 AM > To: 'Margaret Wasserman'; hartmans@painless-security.com > Cc: pcp@ietf.org > Subject: Re: [pcp] Comparison of PCP authentication >=20 > > -----Original Message----- > > From: Margaret Wasserman [mailto:mrw@lilacglade.org] > > Sent: Wednesday, August 08, 2012 10:07 AM > > To: Dan Wing > > Cc: 'james woodyatt'; pcp@ietf.org > > Subject: Re: [pcp] Comparison of PCP authentication > > > > > > On Aug 8, 2012, at 1:02 PM, Dan Wing wrote: > > > So, I think we are okay -- assuming we keep the idea that the PCP > > > client tries to first send a PCP request (and not to first send > > > a PANA request). > > > > Actually, we don't keep this, even now. There is certainly a notion > > that a client could be configured to use authentication for all (or > > some) PCP exchanges, and that the authentication would come first. >=20 > But slide 5 of your deck, > http://tools.ietf.org/agenda/84/slides/slides-84-pcp-10.pdf, > shows the PCP client doing an initial PCP request and getting an > AUTH_REQUIRED > error. That is the basis of my (lovely) ASCII artistry. >=20 > > > However, I do worry that implementations may optimize themselves > > > to send a PANA request first, which would cause the problem you > > > describe if they send the PANA request to a NAT-PMP server. That > > > is, this would be a problem: > > > > > > PCP client NAT-PMP server > > > | | > > > 1. |-------(authentication message)---->| > > > 2. |<--NAT-PMP error--------------------| > > > | | > > > > > > But the PCP client doesn't speak NAT-PMP, so there isn't a way > > > for it to handle that case, anyway (no matter if we had PCP > > > authentication or not). > > > > > > In summary, I think we can skate around problems with talking > > > to a NAT-PMP server. > > > > Makes sense. >=20 >=20 > Sam Hartman wrote: >=20 > > It's not just that implementations may optimize sending an > > authentication request. > > > > An implementation MAY require authentication. > > I.E. it is unwilling to send the request unless it has an authenticated > > channel. > > For firewall control this makes a lot of sense. >=20 > I believe we are okay -- the PCP client trying to do authentication will > have to expect it will occasionally see a NAT-PMP error message. That > will occur if it is communicating with a NAT-PMP server (which shares the > same port as PCP). If the PCP client receives a NAT-PMP error, it needs > to abort trying to do PCP and abort trying to do PANA (because neither > will work); in the (unlikely) event the PCP client also implements > NAT-PMP, it can then downgrade to using NAT-PMP. >=20 > A sentence or three in draft-ietf-pcp-authentication will be needed > to explain that a NAT-PMP error might be received. >=20 > -d >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From dwing@cisco.com Wed Aug 8 19:29:17 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B25911E8156 for ; Wed, 8 Aug 2012 19:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.506 X-Spam-Level: X-Spam-Status: No, score=-110.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyVu-xs3S+Tg for ; Wed, 8 Aug 2012 19:29:16 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4ED11E813A for ; Wed, 8 Aug 2012 19:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4632; q=dns/txt; s=iport; t=1344479356; x=1345688956; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=dL0kFywzzLS7/EPy9jUgrJXnwSNw13C0gOEMR7GvbCc=; b=KeaCOvc5FjO/FRasordVLz/x4TV2BFH+7F+5HtswFNTI4NJRwyX0u1e/ EEvH3+6iRqwVy1Cq0h+iRTzLA6ns4wCgoNhtOjzZkUKPKLxa59nRyQ8s/ RnC8ZLjM71NiECAu/uqr/jHEeKDjrGtuenkU/yjevu/HnU+ns3GMGUepk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGwfI1CrRDoH/2dsb2JhbABFqh2PRoEHgiABAQECAgEBAQUKARQDEDQLDAEDAgkPAgQBAQEnBxkOFQoJCAIEARILF4dqDJtDjWOSUIsShmADiE6FDIkDjRWBZoJ/gTYH X-IronPort-AV: E=Sophos;i="4.77,736,1336348800"; d="scan'208";a="51380632" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 09 Aug 2012 02:29:15 +0000 Received: from dwingWS (sjc-vpn4-1372.cisco.com [10.21.85.91]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q792TFHZ003614; Thu, 9 Aug 2012 02:29:15 GMT From: "Dan Wing" To: "'Zhangdacheng \(Dacheng\)'" , "'Margaret Wasserman'" , References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> In-Reply-To: Date: Wed, 8 Aug 2012 19:29:15 -0700 Message-ID: <028801cd75d6$c5765490$5062fdb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNcPYy1F5Ai0qa4kawmCOKzP6BvpdMkuOAgAAcnICAAAVlgIAAMmWAgAK/7wCAAAE8gIAADgKAgAEKIICAAAgpcA== Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 02:29:17 -0000 > -----Original Message----- > From: Zhangdacheng (Dacheng) [mailto:zhangdacheng@huawei.com] > Sent: Wednesday, August 08, 2012 6:57 PM > To: Dan Wing; 'Margaret Wasserman'; hartmans@painless-security.com > Cc: pcp@ietf.org > Subject: RE: [pcp] Comparison of PCP authentication > > Slide 5 only illustrates a scenario where the pcp server initiates the > authentication procedure. But in our draft, it is also described that > the client can initiate authentication proactively. In my opinion, this > approach seems even more preferable. ^_^ Depends on if we want to optimize for the case where PCP authentication is necessary or is unnecessary. Doing PANA first is a good optimization only if the PCP client knows that PCP authentication will be required by the PCP server on that particular network. If PCP authentication is not needed on a particular network, requesting PCP authentication incurs an extra round trip. If the PCP server doesn't want authentication, I believe we can always rely on a PCP error response if for PANA messages and for PCP-encapsulated (tunneled) PANA messages (which I believe are the two proposals being considered) -- thus, we won't have timeouts due to requesting authentication, which is good. -d > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Dan > > Wing > > Sent: Thursday, August 09, 2012 1:57 AM > > To: 'Margaret Wasserman'; hartmans@painless-security.com > > Cc: pcp@ietf.org > > Subject: Re: [pcp] Comparison of PCP authentication > > > > > -----Original Message----- > > > From: Margaret Wasserman [mailto:mrw@lilacglade.org] > > > Sent: Wednesday, August 08, 2012 10:07 AM > > > To: Dan Wing > > > Cc: 'james woodyatt'; pcp@ietf.org > > > Subject: Re: [pcp] Comparison of PCP authentication > > > > > > > > > On Aug 8, 2012, at 1:02 PM, Dan Wing wrote: > > > > So, I think we are okay -- assuming we keep the idea that the PCP > > > > client tries to first send a PCP request (and not to first send > > > > a PANA request). > > > > > > Actually, we don't keep this, even now. There is certainly a > notion > > > that a client could be configured to use authentication for all (or > > > some) PCP exchanges, and that the authentication would come first. > > > > But slide 5 of your deck, > > http://tools.ietf.org/agenda/84/slides/slides-84-pcp-10.pdf, > > shows the PCP client doing an initial PCP request and getting an > > AUTH_REQUIRED > > error. That is the basis of my (lovely) ASCII artistry. > > > > > > However, I do worry that implementations may optimize themselves > > > > to send a PANA request first, which would cause the problem you > > > > describe if they send the PANA request to a NAT-PMP server. That > > > > is, this would be a problem: > > > > > > > > PCP client NAT-PMP server > > > > | | > > > > 1. |-------(authentication message)---->| > > > > 2. |<--NAT-PMP error--------------------| > > > > | | > > > > > > > > But the PCP client doesn't speak NAT-PMP, so there isn't a way > > > > for it to handle that case, anyway (no matter if we had PCP > > > > authentication or not). > > > > > > > > In summary, I think we can skate around problems with talking > > > > to a NAT-PMP server. > > > > > > Makes sense. > > > > > > Sam Hartman wrote: > > > > > It's not just that implementations may optimize sending an > > > authentication request. > > > > > > An implementation MAY require authentication. > > > I.E. it is unwilling to send the request unless it has an > authenticated > > > channel. > > > For firewall control this makes a lot of sense. > > > > I believe we are okay -- the PCP client trying to do authentication > will > > have to expect it will occasionally see a NAT-PMP error message. > That > > will occur if it is communicating with a NAT-PMP server (which shares > the > > same port as PCP). If the PCP client receives a NAT-PMP error, it > needs > > to abort trying to do PCP and abort trying to do PANA (because > neither > > will work); in the (unlikely) event the PCP client also implements > > NAT-PMP, it can then downgrade to using NAT-PMP. > > > > A sentence or three in draft-ietf-pcp-authentication will be needed > > to explain that a NAT-PMP error might be received. > > > > -d > > > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp From zhangdacheng@huawei.com Wed Aug 8 23:09:37 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D1F21F856D for ; Wed, 8 Aug 2012 23:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.495 X-Spam-Level: X-Spam-Status: No, score=-5.495 tagged_above=-999 required=5 tests=[AWL=1.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQbs1yzy6o4m for ; Wed, 8 Aug 2012 23:09:36 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id ACFD121F8568 for ; Wed, 8 Aug 2012 23:09:36 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJB31643; Wed, 08 Aug 2012 22:09:36 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 8 Aug 2012 23:07:00 -0700 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 8 Aug 2012 23:07:04 -0700 Received: from SZXEML528-MBX.china.huawei.com ([169.254.4.120]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Thu, 9 Aug 2012 14:07:02 +0800 From: "Zhangdacheng (Dacheng)" To: Dan Wing , 'Margaret Wasserman' , "hartmans@painless-security.com" Thread-Topic: [pcp] Comparison of PCP authentication Thread-Index: AQHNcPYy1F5Ai0qa4kawmCOKzP6BvpdMkuOAgAAcnICAAAVlgIAAMmWAgAK/7wCAAAE8gIAADgKAgAEKIICAAAgpcIAAG6yg Date: Thu, 9 Aug 2012 06:07:01 +0000 Message-ID: References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> In-Reply-To: <028801cd75d6$c5765490$5062fdb0$@com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pcp@ietf.org" Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 06:09:37 -0000 If a client has been configured to support PANA, then it is more likely to = stay in an environment where authentication is required, is it? ^_^ However= , if this assumption is broken, then two approaches do not make big differe= nces.=20 > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Thursday, August 09, 2012 10:29 AM > To: Zhangdacheng (Dacheng); 'Margaret Wasserman'; > hartmans@painless-security.com > Cc: pcp@ietf.org > Subject: RE: [pcp] Comparison of PCP authentication >=20 > > -----Original Message----- > > From: Zhangdacheng (Dacheng) [mailto:zhangdacheng@huawei.com] > > Sent: Wednesday, August 08, 2012 6:57 PM > > To: Dan Wing; 'Margaret Wasserman'; hartmans@painless-security.com > > Cc: pcp@ietf.org > > Subject: RE: [pcp] Comparison of PCP authentication > > > > Slide 5 only illustrates a scenario where the pcp server initiates the > > authentication procedure. But in our draft, it is also described that > > the client can initiate authentication proactively. In my opinion, this > > approach seems even more preferable. ^_^ >=20 > Depends on if we want to optimize for the case where PCP authentication > is necessary or is unnecessary. >=20 > Doing PANA first is a good optimization only if the PCP client knows > that PCP authentication will be required by the PCP server on that > particular network. If PCP authentication is not needed on a particular > network, requesting PCP authentication incurs an extra round trip. >=20 > If the PCP server doesn't want authentication, I believe we can always > rely on a PCP error response if for PANA messages and for > PCP-encapsulated (tunneled) PANA messages (which I believe are the two > proposals being considered) -- thus, we won't have timeouts due to > requesting authentication, which is good. >=20 > -d >=20 >=20 >=20 > > > -----Original Message----- > > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > > Dan > > > Wing > > > Sent: Thursday, August 09, 2012 1:57 AM > > > To: 'Margaret Wasserman'; hartmans@painless-security.com > > > Cc: pcp@ietf.org > > > Subject: Re: [pcp] Comparison of PCP authentication > > > > > > > -----Original Message----- > > > > From: Margaret Wasserman [mailto:mrw@lilacglade.org] > > > > Sent: Wednesday, August 08, 2012 10:07 AM > > > > To: Dan Wing > > > > Cc: 'james woodyatt'; pcp@ietf.org > > > > Subject: Re: [pcp] Comparison of PCP authentication > > > > > > > > > > > > On Aug 8, 2012, at 1:02 PM, Dan Wing wrote: > > > > > So, I think we are okay -- assuming we keep the idea that the PCP > > > > > client tries to first send a PCP request (and not to first send > > > > > a PANA request). > > > > > > > > Actually, we don't keep this, even now. There is certainly a > > notion > > > > that a client could be configured to use authentication for all (or > > > > some) PCP exchanges, and that the authentication would come first. > > > > > > But slide 5 of your deck, > > > http://tools.ietf.org/agenda/84/slides/slides-84-pcp-10.pdf, > > > shows the PCP client doing an initial PCP request and getting an > > > AUTH_REQUIRED > > > error. That is the basis of my (lovely) ASCII artistry. > > > > > > > > However, I do worry that implementations may optimize themselves > > > > > to send a PANA request first, which would cause the problem you > > > > > describe if they send the PANA request to a NAT-PMP server. That > > > > > is, this would be a problem: > > > > > > > > > > PCP client NAT-PMP server > > > > > | | > > > > > 1. |-------(authentication message)---->| > > > > > 2. |<--NAT-PMP error--------------------| > > > > > | | > > > > > > > > > > But the PCP client doesn't speak NAT-PMP, so there isn't a way > > > > > for it to handle that case, anyway (no matter if we had PCP > > > > > authentication or not). > > > > > > > > > > In summary, I think we can skate around problems with talking > > > > > to a NAT-PMP server. > > > > > > > > Makes sense. > > > > > > > > > Sam Hartman wrote: > > > > > > > It's not just that implementations may optimize sending an > > > > authentication request. > > > > > > > > An implementation MAY require authentication. > > > > I.E. it is unwilling to send the request unless it has an > > authenticated > > > > channel. > > > > For firewall control this makes a lot of sense. > > > > > > I believe we are okay -- the PCP client trying to do authentication > > will > > > have to expect it will occasionally see a NAT-PMP error message. > > That > > > will occur if it is communicating with a NAT-PMP server (which shares > > the > > > same port as PCP). If the PCP client receives a NAT-PMP error, it > > needs > > > to abort trying to do PCP and abort trying to do PANA (because > > neither > > > will work); in the (unlikely) event the PCP client also implements > > > NAT-PMP, it can then downgrade to using NAT-PMP. > > > > > > A sentence or three in draft-ietf-pcp-authentication will be needed > > > to explain that a NAT-PMP error might be received. > > > > > > -d > > > > > > > > > _______________________________________________ > > > pcp mailing list > > > pcp@ietf.org > > > https://www.ietf.org/mailman/listinfo/pcp From alper.yegin@yegin.org Thu Aug 9 02:32:24 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0F721F86D1 for ; Thu, 9 Aug 2012 02:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.269 X-Spam-Level: X-Spam-Status: No, score=-102.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZx0D791Dqtx for ; Thu, 9 Aug 2012 02:32:23 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 5FACB21F86CA for ; Thu, 9 Aug 2012 02:32:23 -0700 (PDT) Received: from [192.168.2.4] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Mgbk7-1TLlT33SKd-00NWTY; Thu, 09 Aug 2012 05:32:21 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <028801cd75d6$c5765490$5062fdb0$@com> Date: Thu, 9 Aug 2012 12:31:56 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2F9BADF9-2D26-4651-91F2-DAAF3089B9E3@yegin.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> To: Dan Wing X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:H7U+zEK3fNBXiciTZ99y7lN0+OviywCQbkEjk+iXb0r 2XfbLhRn/V/gNawiwAPr54wfysDDoujaBd3pzSJybMb8F214U7 YBdVpWqGWGidjTOrNMTedo/3T+pgZUH6QHAG9HljzmUr+Bs8QU ItT+6gLOJc4iKsOmtSF4e5jdm4A7Y2xMPavIXPYOgHmqyyRazc VkckJfVc2bi0/NkD9oo4Jz54lT1lDSpBjC44n09cyR3Dx8zPfP DLKPohVKpVZH2tCUASJsOvbzmgFCm/Y0+Zw1eBBDNuK8lT6cxO 4jzXGjMPX5CShv9TodhBwGwUZGx1khd7DbtV7fvFUHQCTyeXQt oPSqUuGOPWW58ysAYj/BQaLw5deOq4+l5qGBYijlI65x321qe+ oadxULCHuRivg== Cc: 'Margaret Wasserman' , pcp@ietf.org Subject: [pcp] single port PANA+PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 09:32:24 -0000 > If the PCP server doesn't want authentication, I believe we can always=20= > rely on a PCP error response if for PANA messages and for=20 > PCP-encapsulated (tunneled) PANA messages (which I believe are the two > proposals being considered)=20 My understand is that there are two alternatives we are considering for = using PANA for PCP authentication over the same PCP port: 1. Encapsulate PANA over PCP (e.g., define a dedicated PCP option that = encapsulate PANA packet). 2. Define a way to demux PANA and PCP even when they operate over the = same port (no encapsulation). Right? I might have lost track, just seeking confirmation=85 Alper From mrw@lilacglade.org Thu Aug 9 05:44:48 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC0421F8665 for ; Thu, 9 Aug 2012 05:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.409 X-Spam-Level: X-Spam-Status: No, score=-95.409 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, J_CHICKENPOX_43=0.6, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TlOmgorNtxc for ; Thu, 9 Aug 2012 05:44:47 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 88D1D21F8661 for ; Thu, 9 Aug 2012 05:44:47 -0700 (PDT) Received: from lilac-too.home (permutation-city.suchdamage.org [69.25.196.28]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id ECDCE201B6; Thu, 9 Aug 2012 08:44:45 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <2F9BADF9-2D26-4651-91F2-DAAF3089B9E3@yegin.org> Date: Thu, 9 Aug 2012 08:44:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9C09773C-F3CC-4BBA-AFE9-AE427DA58F6E@lilacglade.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <2F9BADF9-2D26-4651-91F2-DAAF3089B9E3@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] single port PANA+PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 12:44:48 -0000 Hi Alper, On Aug 9, 2012, at 5:31 AM, Alper Yegin wrote: > My understand is that there are two alternatives we are considering = for using PANA for PCP authentication over the same PCP port: >=20 > 1. Encapsulate PANA over PCP (e.g., define a dedicated PCP option that = encapsulate PANA packet). > 2. Define a way to demux PANA and PCP even when they operate over the = same port (no encapsulation). Yes, these are the two PANA-based approaches we are considering. Someone asked, at the end of the meeting, that we also keep the = PCP-Specific approach in the document, so that we could compare all = three approaches at the interim conference call, so we will do that, = too, since it doesn't require any significant work. Margaret From hartmans@painless-security.com Thu Aug 9 06:25:38 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A7021F859B for ; Thu, 9 Aug 2012 06:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.124 X-Spam-Level: ** X-Spam-Status: No, score=2.124 tagged_above=-999 required=5 tests=[AWL=-2.164, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqBC6zCP-IZl for ; Thu, 9 Aug 2012 06:25:38 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id D386A21F8599 for ; Thu, 9 Aug 2012 06:25:36 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id ED30C201B6; Thu, 9 Aug 2012 09:25:25 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9B0A7420E; Thu, 9 Aug 2012 09:25:22 -0400 (EDT) From: Sam Hartman To: "Dan Wing" References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> Date: Thu, 09 Aug 2012 09:25:22 -0400 In-Reply-To: <028801cd75d6$c5765490$5062fdb0$@com> (Dan Wing's message of "Wed, 8 Aug 2012 19:29:15 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: 'Margaret Wasserman' , pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 13:25:38 -0000 >>>>> "Dan" == Dan Wing writes: Dan> Doing PANA first is a good optimization only if the PCP client Dan> knows that PCP authentication will be required by the PCP Dan> server on that particular network. If PCP authentication is Dan> not needed on a particular network, requesting PCP Dan> authentication incurs an extra round trip. Thinking about this as an optimization seems wrong to me. consider the case where the client wants authentication but the server does not require it. For example, the client wants integrity protection of the result of the request. In this case it's about security requirements *not* optimization. The client needs a way to force the server to require authentication. Another case where this becomes important is where a server will accept requests from unauthenticated clients but treat them differently. For example an authenticated client is allowed to ask for longer lifetimes, etc. Especially since interacting with firewalls is in-scope for PCP, supporting clients with higher security requirements seems and important design goal for a PCP authentication mechanism. So, I don't think we should be thinking of this purely in terms of optimization. From alper.yegin@yegin.org Thu Aug 9 08:41:48 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605F221F87A7 for ; Thu, 9 Aug 2012 08:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.244 X-Spam-Level: X-Spam-Status: No, score=-102.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CptXcPivdgD6 for ; Thu, 9 Aug 2012 08:41:48 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id D658321F87A3 for ; Thu, 9 Aug 2012 08:41:47 -0700 (PDT) Received: from [192.168.2.4] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0Megvg-1TNbKI2fyy-00OKeb; Thu, 09 Aug 2012 11:41:42 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <9C09773C-F3CC-4BBA-AFE9-AE427DA58F6E@lilacglade.org> Date: Thu, 9 Aug 2012 18:41:20 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <2F9BADF9-2D26-4651-91F2-DAAF3089B9E3@yegin.org> <9C09773C-F3CC-4BBA-AFE9-AE427DA58F6E@lilacglade.org> To: Margaret Wasserman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:NIQ+O/jhvE/W1UWgu8t/inMP3fUQtX7BhiAEZGVz9Gc Jcj/xrxTxhFzLEoK2YUmcY4pUg8zAa4yPYSwiDWkiKdHLEFMzq gzY6Ybs1jWrT/yGCLKMwHsO61vWLV61mZVD/JQO4HuP9vtwhGc T4kgAQMtWAo/33TGRKevYurvtIM2yLIjo7Mdild1hNIDUytMh5 QB4UbIvIbZvh0Zcwklyebca4w7uKccqz7AC8H7dSpefCNZ4IpJ oQVH5irBVi1zhcCoswPs4WYRjmd/YirFoHZ1+st9vDHELkpOau 3jiPrTsXQxNAJeF8J1xOb1JYFCiPGjvbs423CPeMY+283AcBvz 6drTB3UW7+6AVahmeYF5KVZix0u6aIWJQIfOD88jbFy0ZCfmt7 G3IS9wd8F2c+A== Cc: pcp@ietf.org Subject: Re: [pcp] single port PANA+PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 15:41:48 -0000 Hi Margaret, >=20 > Hi Alper, >=20 > On Aug 9, 2012, at 5:31 AM, Alper Yegin wrote: >> My understand is that there are two alternatives we are considering = for using PANA for PCP authentication over the same PCP port: >>=20 >> 1. Encapsulate PANA over PCP (e.g., define a dedicated PCP option = that encapsulate PANA packet). >> 2. Define a way to demux PANA and PCP even when they operate over the = same port (no encapsulation). >=20 > Yes, these are the two PANA-based approaches we are considering. >=20 > Someone asked, at the end of the meeting, that we also keep the = PCP-Specific approach in the document, so that we could compare all = three approaches at the interim conference call, so we will do that, = too, since it doesn't require any significant work. >=20 There was a clear decision at the meeting to go with a PANA-based = solution, not with EAP-over-PCP solution. Given that the decision is = already made, why do we need to keep other options still floating in the = WG document? > Margaret >=20 >=20 From dwing@cisco.com Thu Aug 9 10:07:42 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C9D21F8793 for ; Thu, 9 Aug 2012 10:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.207 X-Spam-Level: X-Spam-Status: No, score=-110.207 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp8mK6ncRyM9 for ; Thu, 9 Aug 2012 10:07:41 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 07E2E21F8792 for ; Thu, 9 Aug 2012 10:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1186; q=dns/txt; s=iport; t=1344532061; x=1345741661; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=L2cObryEl2P82IQLG3hqpHGULNjbAy/j2TbVQvCzXFw=; b=dy6sXWwZLFXTWzv9Oa01e9+ORtDEsJ+96nbAm2zBIWc0PHhKMkpTN06F APs8O0KNKwvZRHTs/+SeQIDZW65VcAASAluHxnqBc98rN3uul8tT8LdhU Z115Yzup+U2BJspxPmCqSztA+LZWgyB7gGAPQ1VpW3PUG2IDo9vS5gH03 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAIzgI1CrRDoI/2dsb2JhbABFqiCPQoEHgiABAQEECAoBFxAuEQwBAwIJDgECBAEBAScHGSMKCQgBAQQBEgsXh2qbB6Btiw+GZAOIToUMlhiBZoJ/ X-IronPort-AV: E=Sophos;i="4.77,741,1336348800"; d="scan'208";a="54479443" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 09 Aug 2012 17:07:39 +0000 Received: from dwingWS (sjc-vpn7-1991.cisco.com [10.21.151.199]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q79H7ba7023470; Thu, 9 Aug 2012 17:07:39 GMT From: "Dan Wing" To: "'Margaret Wasserman'" , "'Alper Yegin'" References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <2F9BADF9-2D26-4651-91F2-DAAF3089B9E3@yegin.org> <9C09773C-F3CC-4BBA-AFE9-AE427DA58F6E@lilacglade.org> In-Reply-To: <9C09773C-F3CC-4BBA-AFE9-AE427DA58F6E@lilacglade.org> Date: Thu, 9 Aug 2012 10:07:08 -0700 Message-ID: <03ac01cd7651$7a7244b0$6f56ce10$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac12LMKn5vckw12tRDaAiSppFUTrLQAINeiA Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] single port PANA+PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 17:07:42 -0000 > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@lilacglade.org] > Sent: Thursday, August 09, 2012 5:45 AM > To: Alper Yegin > Cc: Dan Wing; 'Zhangdacheng (Dacheng)'; hartmans@painless-security.com; > pcp@ietf.org > Subject: Re: single port PANA+PCP > > > Hi Alper, > > On Aug 9, 2012, at 5:31 AM, Alper Yegin wrote: > > My understand is that there are two alternatives we are considering > for using PANA for PCP authentication over the same PCP port: > > > > 1. Encapsulate PANA over PCP (e.g., define a dedicated PCP option > that encapsulate PANA packet). > > 2. Define a way to demux PANA and PCP even when they operate over the > same port (no encapsulation). > > Yes, these are the two PANA-based approaches we are considering. > > Someone asked, at the end of the meeting, that we also keep the PCP- > Specific approach in the document, so that we could compare all three > approaches at the interim conference call, so we will do that, too, > since it doesn't require any significant work. That was me that asked. We need all three with pro/con to understand what value we get and what problems we solve. Thanks, -d From dwing@cisco.com Thu Aug 9 10:07:42 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0DB421F8792 for ; Thu, 9 Aug 2012 10:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.504 X-Spam-Level: X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWQP8JyWn07y for ; Thu, 9 Aug 2012 10:07:41 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 07AEC21F8790 for ; Thu, 9 Aug 2012 10:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=6420; q=dns/txt; s=iport; t=1344532061; x=1345741661; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=EC80hhUyBlS1vVpu2xtbJW1qT6RME1ZqkSh6spau7Gk=; b=MhQP5Gy6CmogqyIzbOiYX9o4Ltio0KTYtQqoQoLaq/5vsFdDpn6Y8KGa +sK8J48WEljVnLSLdqvAa1c9QHCYavoefsi7fYTZzCE795GKzlFKxpnnZ h4aXJvoM/ji8M0FyK3RIlCo7OxdRmlDuMynE6punRKjs31D0qL4QQUWeT M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAIzgI1CrRDoI/2dsb2JhbABFqiCPQoEHgiABAQECAQEBAQEFCgEUAxA0CwUHAQMCCQ8CBAEBAScHGQ4VCgkIAgQBEgsXh2UFDJp7jWOTCosPhmQDiE6FDIkDjRWBZoJ/gTYH X-IronPort-AV: E=Sophos;i="4.77,741,1336348800"; d="scan'208";a="51987956" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 09 Aug 2012 17:07:39 +0000 Received: from dwingWS (sjc-vpn7-1991.cisco.com [10.21.151.199]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q79H7ba6023470; Thu, 9 Aug 2012 17:07:38 GMT From: "Dan Wing" To: "'Zhangdacheng \(Dacheng\)'" , "'Margaret Wasserman'" , References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> In-Reply-To: Date: Thu, 9 Aug 2012 10:07:08 -0700 Message-ID: <03ab01cd7651$7a2bece0$6e83c6a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNcPYy1F5Ai0qa4kawmCOKzP6BvpdMkuOAgAAcnICAAAVlgIAAMmWAgAK/7wCAAAE8gIAADgKAgAEKIICAAAgpcIAAG6yggADVHJA= Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 17:07:42 -0000 > -----Original Message----- > From: Zhangdacheng (Dacheng) [mailto:zhangdacheng@huawei.com] > Sent: Wednesday, August 08, 2012 11:07 PM > To: Dan Wing; 'Margaret Wasserman'; hartmans@painless-security.com > Cc: pcp@ietf.org > Subject: RE: [pcp] Comparison of PCP authentication > > If a client has been configured to support PANA, then it is more likely > to stay in an environment where authentication is required, is it? ^_^ On the other hand, it would be annoying if configuring PCP authentication for one network (e.g., office network) added a round trip when on networks that don't need PCP authentication (e.g., home network, airport, hotel, 3G/LTE network). Heuristics to decide "same network" or "different network" are probably helpful for PCP to distinguish those networks (e.g., DNAv4 [RFC4436]). > However, if this assumption is broken, then two approaches do not make > big differences. Two approaches force additional code and test cases. -d > > > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Thursday, August 09, 2012 10:29 AM > > To: Zhangdacheng (Dacheng); 'Margaret Wasserman'; > > hartmans@painless-security.com > > Cc: pcp@ietf.org > > Subject: RE: [pcp] Comparison of PCP authentication > > > > > -----Original Message----- > > > From: Zhangdacheng (Dacheng) [mailto:zhangdacheng@huawei.com] > > > Sent: Wednesday, August 08, 2012 6:57 PM > > > To: Dan Wing; 'Margaret Wasserman'; hartmans@painless-security.com > > > Cc: pcp@ietf.org > > > Subject: RE: [pcp] Comparison of PCP authentication > > > > > > Slide 5 only illustrates a scenario where the pcp server initiates > the > > > authentication procedure. But in our draft, it is also described > that > > > the client can initiate authentication proactively. In my opinion, > this > > > approach seems even more preferable. ^_^ > > > > Depends on if we want to optimize for the case where PCP > authentication > > is necessary or is unnecessary. > > > > Doing PANA first is a good optimization only if the PCP client knows > > that PCP authentication will be required by the PCP server on that > > particular network. If PCP authentication is not needed on a > particular > > network, requesting PCP authentication incurs an extra round trip. > > > > If the PCP server doesn't want authentication, I believe we can > always > > rely on a PCP error response if for PANA messages and for > > PCP-encapsulated (tunneled) PANA messages (which I believe are the > two > > proposals being considered) -- thus, we won't have timeouts due to > > requesting authentication, which is good. > > > > -d > > > > > > > > > > -----Original Message----- > > > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On > Behalf Of > > > Dan > > > > Wing > > > > Sent: Thursday, August 09, 2012 1:57 AM > > > > To: 'Margaret Wasserman'; hartmans@painless-security.com > > > > Cc: pcp@ietf.org > > > > Subject: Re: [pcp] Comparison of PCP authentication > > > > > > > > > -----Original Message----- > > > > > From: Margaret Wasserman [mailto:mrw@lilacglade.org] > > > > > Sent: Wednesday, August 08, 2012 10:07 AM > > > > > To: Dan Wing > > > > > Cc: 'james woodyatt'; pcp@ietf.org > > > > > Subject: Re: [pcp] Comparison of PCP authentication > > > > > > > > > > > > > > > On Aug 8, 2012, at 1:02 PM, Dan Wing wrote: > > > > > > So, I think we are okay -- assuming we keep the idea that the > PCP > > > > > > client tries to first send a PCP request (and not to first > send > > > > > > a PANA request). > > > > > > > > > > Actually, we don't keep this, even now. There is certainly a > > > notion > > > > > that a client could be configured to use authentication for all > (or > > > > > some) PCP exchanges, and that the authentication would come > first. > > > > > > > > But slide 5 of your deck, > > > > http://tools.ietf.org/agenda/84/slides/slides-84-pcp-10.pdf, > > > > shows the PCP client doing an initial PCP request and getting an > > > > AUTH_REQUIRED > > > > error. That is the basis of my (lovely) ASCII artistry. > > > > > > > > > > However, I do worry that implementations may optimize > themselves > > > > > > to send a PANA request first, which would cause the problem > you > > > > > > describe if they send the PANA request to a NAT-PMP server. > That > > > > > > is, this would be a problem: > > > > > > > > > > > > PCP client NAT-PMP server > > > > > > | | > > > > > > 1. |-------(authentication message)---->| > > > > > > 2. |<--NAT-PMP error--------------------| > > > > > > | | > > > > > > > > > > > > But the PCP client doesn't speak NAT-PMP, so there isn't a > way > > > > > > for it to handle that case, anyway (no matter if we had PCP > > > > > > authentication or not). > > > > > > > > > > > > In summary, I think we can skate around problems with talking > > > > > > to a NAT-PMP server. > > > > > > > > > > Makes sense. > > > > > > > > > > > > Sam Hartman wrote: > > > > > > > > > It's not just that implementations may optimize sending an > > > > > authentication request. > > > > > > > > > > An implementation MAY require authentication. > > > > > I.E. it is unwilling to send the request unless it has an > > > authenticated > > > > > channel. > > > > > For firewall control this makes a lot of sense. > > > > > > > > I believe we are okay -- the PCP client trying to do > authentication > > > will > > > > have to expect it will occasionally see a NAT-PMP error message. > > > That > > > > will occur if it is communicating with a NAT-PMP server (which > shares > > > the > > > > same port as PCP). If the PCP client receives a NAT-PMP error, > it > > > needs > > > > to abort trying to do PCP and abort trying to do PANA (because > > > neither > > > > will work); in the (unlikely) event the PCP client also > implements > > > > NAT-PMP, it can then downgrade to using NAT-PMP. > > > > > > > > A sentence or three in draft-ietf-pcp-authentication will be > needed > > > > to explain that a NAT-PMP error might be received. > > > > > > > > -d > > > > > > > > > > > > _______________________________________________ > > > > pcp mailing list > > > > pcp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/pcp From dwing@cisco.com Thu Aug 9 10:07:47 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204D421F879F for ; Thu, 9 Aug 2012 10:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.206 X-Spam-Level: X-Spam-Status: No, score=-110.206 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFM7BBXN5kR6 for ; Thu, 9 Aug 2012 10:07:45 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id CA14C21F87A1 for ; Thu, 9 Aug 2012 10:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1033; q=dns/txt; s=iport; t=1344532066; x=1345741666; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=dmNfaY/LFttKpT5vXXr8oDVCpY3dOt2cl/gOscLZdPY=; b=aauPQ2JpT+zB68QQfmM6CeOs8mSx80CWs/EyPQGzC2cLms3fp3/jTllg TV7s0yfbo5y1Xj29G969XtxqeCc7A37sslEe8ziWk12vZevYoV/TDA24b TS1ppGatxmV+0Y8BbB9HDh/xLF1iwj48MBeV3ACVVl8QNbj1FSknPfO9Q A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAIzgI1CrRDoI/2dsb2JhbABFqiCPQoEHgiABAQEECAoBFxA/DAEDAgkPAgQBASgHGSMKCQgBAQQTCxeHapsHoG2LD4ZkA4hOhQyWGIFmgn8 X-IronPort-AV: E=Sophos;i="4.77,741,1336348800"; d="scan'208";a="54559063" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 09 Aug 2012 17:07:44 +0000 Received: from dwingWS (sjc-vpn7-1991.cisco.com [10.21.151.199]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q79H7baC023470; Thu, 9 Aug 2012 17:07:44 GMT From: "Dan Wing" To: "'Alper Yegin'" References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <2F9BADF9-2D26-4651-91F2-DAAF3089B9E3@yegin.org> In-Reply-To: <2F9BADF9-2D26-4651-91F2-DAAF3089B9E3@yegin.org> Date: Thu, 9 Aug 2012 10:07:08 -0700 Message-ID: <03bd01cd7651$7db058b0$79110a10$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac12EeMVsBCuAh+gQKa5gwXkZmZlhwAO4eIQ Content-Language: en-us Cc: 'Margaret Wasserman' , pcp@ietf.org Subject: Re: [pcp] single port PANA+PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 17:07:47 -0000 > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Thursday, August 09, 2012 2:32 AM > To: Dan Wing > Cc: 'Zhangdacheng (Dacheng)'; 'Margaret Wasserman'; hartmans@painless- > security.com; pcp@ietf.org > Subject: single port PANA+PCP > > > If the PCP server doesn't want authentication, I believe we can > always > > rely on a PCP error response if for PANA messages and for > > PCP-encapsulated (tunneled) PANA messages (which I believe are the > two > > proposals being considered) > > My understand is that there are two alternatives we are considering for > using PANA for PCP authentication over the same PCP port: > > 1. Encapsulate PANA over PCP (e.g., define a dedicated PCP option that > encapsulate PANA packet). > 2. Define a way to demux PANA and PCP even when they operate over the > same port (no encapsulation). > > Right? > > I might have lost track, just seeking confirmation. Yes, I believe those are the two approaches being considered. -d From dwing@cisco.com Thu Aug 9 10:55:53 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9049721F85AC for ; Thu, 9 Aug 2012 10:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.505 X-Spam-Level: X-Spam-Status: No, score=-110.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eErs3iu19WDl for ; Thu, 9 Aug 2012 10:55:53 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id F1AF921F851E for ; Thu, 9 Aug 2012 10:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2023; q=dns/txt; s=iport; t=1344534953; x=1345744553; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=EONUfjXc1iIypoFFK6wQuoN+ZO94jD4X7bxg8ngB1Yk=; b=SpIFEu7YoEDiCh38VeG6b3Lu88JT+bY9K9DW7O0YpbYoGjERQhZU3EkH YpRUrZoJXaJQ0u1eXJDxN3EWNHKP0CqXI8FDDwI/sNacez4fBm+3rh66n 8r7MlLWSZ+3+SZ68ejUwlcLqna1h4Q51kIrc6ELAqAf4hX5DuMdsBrDjk 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAIzgI1CrRDoG/2dsb2JhbABFqiCPQoEHgiABAQEDAQgKARcQPwUHAQMCCQ8CBAEBKAcZIwoJCAEBBBMLF4dlBZsHjWOTCosPhmQDiE6FDJYYgWaCfw X-IronPort-AV: E=Sophos;i="4.77,741,1336348800"; d="scan'208";a="54483511" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 09 Aug 2012 17:55:53 +0000 Received: from dwingWS (sjc-vpn7-1991.cisco.com [10.21.151.199]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q79Htq9T024941; Thu, 9 Aug 2012 17:55:52 GMT From: "Dan Wing" To: "'Sam Hartman'" References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> In-Reply-To: Date: Thu, 9 Aug 2012 10:55:52 -0700 Message-ID: <04c901cd7658$37a740c0$a6f5c240$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac12MnxUJnz2P+UcRQukhq9ambTiDwAJJx9w Content-Language: en-us Cc: 'Margaret Wasserman' , pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 17:55:53 -0000 > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Thursday, August 09, 2012 6:25 AM > To: Dan Wing > Cc: 'Zhangdacheng (Dacheng)'; 'Margaret Wasserman'; pcp@ietf.org > Subject: Re: [pcp] Comparison of PCP authentication > > >>>>> "Dan" == Dan Wing writes: > > > Dan> Doing PANA first is a good optimization only if the PCP client > Dan> knows that PCP authentication will be required by the PCP > Dan> server on that particular network. If PCP authentication is > Dan> not needed on a particular network, requesting PCP > Dan> authentication incurs an extra round trip. > > Thinking about this as an optimization seems wrong to me. > > consider the case where the client wants authentication but the server > does not require it. For example, the client wants integrity > protection > of the result of the request. > In this case it's about security requirements *not* optimization. > The client needs a way to force the server to require authentication. I am struggling to imagine a PCP client that would refuse to do MAP or PEER because its PCP server doesn't support authentication. > Another case where this becomes important is where a server will accept > requests from unauthenticated clients but treat them differently. For > example an authenticated client is allowed to ask for longer lifetimes, > etc. That sounds reasonable. But we could solve that differently than trying authentication first all the time, such as for example including an "I WILL DO AUTHENTICATION IF I GET BETTER CHOCOLATE COOKIES" in the initial PCP request, which triggers a PCP authentication required error. > Especially since interacting with firewalls is in-scope for PCP, > supporting clients with higher security requirements seems and > important design goal for a PCP authentication mechanism. > > So, I don't think we should be thinking of this purely in terms of > optimization. -d From hartmans@painless-security.com Thu Aug 9 11:20:18 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68ED21F8750 for ; Thu, 9 Aug 2012 11:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.259 X-Spam-Level: ** X-Spam-Status: No, score=2.259 tagged_above=-999 required=5 tests=[AWL=-2.029, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlk9tjtJk-bN for ; Thu, 9 Aug 2012 11:20:18 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 4629C21F8755 for ; Thu, 9 Aug 2012 11:20:18 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id C3C82201B6; Thu, 9 Aug 2012 14:20:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D3E02420E; Thu, 9 Aug 2012 14:20:12 -0400 (EDT) From: Sam Hartman To: "Dan Wing" References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> Date: Thu, 09 Aug 2012 14:20:12 -0400 In-Reply-To: <04c901cd7658$37a740c0$a6f5c240$@com> (Dan Wing's message of "Thu, 9 Aug 2012 10:55:52 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: 'Margaret Wasserman' , pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 18:20:18 -0000 >>>>> "Dan" == Dan Wing writes: Dan> I am struggling to imagine a PCP client that would refuse to do Dan> MAP or PEER because its PCP server doesn't support Dan> authentication. If I'm updating security policy on a firewall I want to be able to audit whether that actually happened. That requires authentication. From dwing@cisco.com Thu Aug 9 11:32:31 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729A321F875A for ; Thu, 9 Aug 2012 11:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.507 X-Spam-Level: X-Spam-Status: No, score=-110.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-XWhZREfabf for ; Thu, 9 Aug 2012 11:32:31 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0085621F8741 for ; Thu, 9 Aug 2012 11:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=909; q=dns/txt; s=iport; t=1344537151; x=1345746751; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=6lMPl5dN+cqQ+r3WhAbcZ/Xg1BoGkfF6aEIwwRpAICs=; b=g7znnotapvoxBOlw0nnEGZtu6S3CtF4NkIeagUUySceXMbRyRNWFCXDP fJifyBEf5mxxyHv9dsLzzEtORpUYSxvzHbTzJH23QOZJC6RpiEHzw2l7q uwRudMcRRhbmHvZEIcle/st96Q8AXF/8ykoRVmJoXJUaAhFSVvGy6yrX5 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAIzgI1CrRDoG/2dsb2JhbABFhTqkZo9CgQeCIAEBAQQICgEXED8MAQMCCQ8CBAEBKAcZIwoJCAEBBBMLF4dqmweNY5MKiw+GZAOIToUMlhiBZoJ/ X-IronPort-AV: E=Sophos;i="4.77,741,1336348800"; d="scan'208";a="51995661" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 09 Aug 2012 18:32:29 +0000 Received: from dwingWS (sjc-vpn7-1991.cisco.com [10.21.151.199]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q79IWS5d012505; Thu, 9 Aug 2012 18:32:28 GMT From: "Dan Wing" To: "'Sam Hartman'" References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> In-Reply-To: Date: Thu, 9 Aug 2012 11:32:28 -0700 Message-ID: <054001cd765d$54c0f3e0$fe42dba0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac12W6ER2TBeTf2DS4qcgYOm1MjDVgAAVNUQ Content-Language: en-us Cc: 'Margaret Wasserman' , pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 18:32:31 -0000 > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Thursday, August 09, 2012 11:20 AM > To: Dan Wing > Cc: 'Zhangdacheng (Dacheng)'; 'Margaret Wasserman'; pcp@ietf.org > Subject: Re: [pcp] Comparison of PCP authentication > > >>>>> "Dan" == Dan Wing writes: > > > Dan> I am struggling to imagine a PCP client that would refuse to > do > Dan> MAP or PEER because its PCP server doesn't support > Dan> authentication. > > If I'm updating security policy on a firewall I want to be able to > audit whether that actually happened. That requires authentication. You are saying a PCP client would only want to update firewall policies if the PCP server supports authentication, otherwise it would tell the user that it cannot enable the webcam, Internet-connected NAS, Internet-connected printer, etc.? -d From mrw@LILACGLADE.ORG Thu Aug 9 12:17:31 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2C021F86FD for ; Thu, 9 Aug 2012 12:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.392 X-Spam-Level: X-Spam-Status: No, score=-95.392 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoHq5dHawzhB for ; Thu, 9 Aug 2012 12:17:30 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7CE21F86B3 for ; Thu, 9 Aug 2012 12:17:30 -0700 (PDT) Received: from lilac-too.home (permutation-city.suchdamage.org [69.25.196.28]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 4857D202A6; Thu, 9 Aug 2012 15:12:05 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-3--987378556 From: Margaret Wasserman In-Reply-To: Date: Thu, 9 Aug 2012 15:12:05 -0400 Message-Id: <81DFAB1F-55BD-427B-88D4-4558BDDC926E@LILACGLADE.ORG> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <2F9BADF9-2D26-4651-91F2-DAAF3089B9E3@yegin.org> <9C09773C-F3CC-4BBA-AFE9-AE427DA58F6E@lilacglade.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] single port PANA+PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 19:17:31 -0000 --Apple-Mail-3--987378556 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Alper, On Aug 9, 2012, at 11:41 AM, Alper Yegin wrote: >=20 > There was a clear decision at the meeting to go with a PANA-based = solution, not with EAP-over-PCP solution. Given that the decision is = already made, why do we need to keep other options still floating in the = WG document? I'm not a WG chair, so it is not my place to call consensus of the room. = However, I don't _think_ we actually had consensus at that point in the = discussion... IIRC (and you should feel free to refer to the minutes = when available to check my memory), about 1/3 of the people who = expressed an opinion preferred a PCP-specific approach and 2/3 preferred = a PANA-based approach (either a PANA encapsulation or a PCP/PANA = demultiplexing). There was, IIRC, consensus that we wanted a single-port solution. I'm hoping we will emerge from the interim conference call with = consensus on a single approach to pursue, and I currently expect it will = be one of the PANA-based approaches. However, I don't think that has = been completely nailed down yet. We also have the open question from Dave Thaler about whether to = consider at DTLS-based approach. I would be interested in hearing from = other members of the WG whether a DTLS-based approach is of enough = interest that we should document what that would look like, and include = it in the trade-off discussion at the interim, or not. I'm not really looking for _more_ choices here, but I would like us to = fairly considered all of the sensible options and make a solid, = technical choice. Margaret --Apple-Mail-3--987378556 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

There was a = clear decision at the meeting to go with a PANA-based solution, not with = EAP-over-PCP solution. Given that the decision is already made, why do = we need to keep other options still floating in the WG = document?

I'm not a WG chair, so = it is not my place to call consensus of the room.  However, I don't = _think_ we actually had consensus at that point in the discussion... =  IIRC (and you should feel free to refer to the minutes when = available to check my memory), about 1/3 of the people who expressed an = opinion preferred a PCP-specific approach and 2/3 preferred a PANA-based = approach (either a PANA encapsulation or a PCP/PANA = demultiplexing).

There was, IIRC, consensus = that we wanted a single-port solution.

I'm = hoping we will emerge from the interim conference call with consensus on = a single approach to pursue, and I currently expect it will be one of = the PANA-based approaches.  However, I don't think that has been = completely nailed down yet.

We also have the = open question from Dave Thaler about whether to consider at DTLS-based = approach.  I would be interested in hearing from other members of = the WG whether a DTLS-based approach is of enough interest that we = should document what that would look like, and include it in the = trade-off discussion at the interim, or = not.

I'm not really looking for _more_ choices = here, but I would like us to fairly considered all of the sensible = options and make a solid, technical = choice.

Margaret






= --Apple-Mail-3--987378556-- From mrw@lilacglade.org Thu Aug 9 12:21:26 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D18B21F8736 for ; Thu, 9 Aug 2012 12:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.677 X-Spam-Level: X-Spam-Status: No, score=-95.677 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upwU26tuuIJx for ; Thu, 9 Aug 2012 12:21:25 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id D242A21F86FC for ; Thu, 9 Aug 2012 12:21:25 -0700 (PDT) Received: from lilac-too.home (permutation-city.suchdamage.org [69.25.196.28]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 8E3CC202A6; Thu, 9 Aug 2012 15:21:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4--986818603 From: Margaret Wasserman In-Reply-To: <054001cd765d$54c0f3e0$fe42dba0$@com> Date: Thu, 9 Aug 2012 15:21:25 -0400 Message-Id: <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> To: Dan Wing X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 19:21:26 -0000 --Apple-Mail-4--986818603 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 9, 2012, at 2:32 PM, Dan Wing wrote: >>=20 >> If I'm updating security policy on a firewall I want to be able to >> audit whether that actually happened. That requires authentication. >=20 > You are saying a PCP client would only want to update firewall = policies=20 > if the PCP server supports authentication, otherwise it would tell the > user that it cannot enable the webcam, Internet-connected NAS,=20 > Internet-connected printer, etc.? I wont presume to guess what Sam is thinking... However, I am thinking that there will be some clients that are = configured to perform authentication for every request. For example, = there is no reason for a PCP proxy, running in an environment where = authentication is required to do a THIRD-PARTY request, to perform a = useless round-trip for every THIRD-PARTY request it issues. =20 Margaret --Apple-Mail-4--986818603 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

If = I'm updating security policy on a firewall I want to be able = to
audit whether that actually = happened.  That requires authentication.

You = are saying a PCP client would only want to update firewall policies =
if the PCP server supports authentication, otherwise it would tell = the
user that it cannot enable the webcam, Internet-connected NAS, =
Internet-connected printer, etc.?

I = wont presume to guess what Sam is = thinking...

However, I am thinking that there = will be some clients  that are configured to perform authentication = for every request.  For example, there is no reason for a PCP = proxy, running in an environment where authentication is required to do = a THIRD-PARTY request, to perform a useless round-trip for every = THIRD-PARTY request it issues. =  

Margaret


= --Apple-Mail-4--986818603-- From hartmans@painless-security.com Thu Aug 9 12:32:31 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E43721F874F for ; Thu, 9 Aug 2012 12:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.378 X-Spam-Level: ** X-Spam-Status: No, score=2.378 tagged_above=-999 required=5 tests=[AWL=-1.910, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klocFvEghB5B for ; Thu, 9 Aug 2012 12:32:31 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC3121F8682 for ; Thu, 9 Aug 2012 12:32:30 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 8B530202A6; Thu, 9 Aug 2012 15:22:57 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AA8A3420E; Thu, 9 Aug 2012 15:22:53 -0400 (EDT) From: Sam Hartman To: "Dan Wing" References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> Date: Thu, 09 Aug 2012 15:22:53 -0400 In-Reply-To: <054001cd765d$54c0f3e0$fe42dba0$@com> (Dan Wing's message of "Thu, 9 Aug 2012 11:32:28 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: 'Margaret Wasserman' , pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 19:32:31 -0000 >>>>> "Dan" == Dan Wing writes: Dan> You are saying a PCP client would only want to update firewall Dan> policies if the PCP server supports authentication, otherwise Dan> it would tell the user that it cannot enable the webcam, Dan> Internet-connected NAS, Internet-connected printer, etc.? I'm saying that a PCP client poking a hole in an enterprise firewall for an enterprise server almost certainly wants to log an auditable event if it cannot confirm it updated the firewall policy. On the same network a webcam might not care what server it talked to. Note there are a lot of ways of meeting the security requirement for auditability. For example we can have a PCP message that requests a server send us back an authentication error if it can do that. --Sam From jhw@apple.com Mon Aug 13 14:33:25 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B87221F8516 for ; Mon, 13 Aug 2012 14:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+yc9GFf5N+q for ; Mon, 13 Aug 2012 14:33:24 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id CD2BF21F84E4 for ; Mon, 13 Aug 2012 14:33:24 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0M8P00CJ6QER3DA9@mail-out.apple.com> for pcp@ietf.org; Mon, 13 Aug 2012 14:33:23 -0700 (PDT) X-AuditID: 11807134-b7f866d000002583-1d-502972a23402 Received: from fenugreek.apple.com (fenugreek.apple.com [17.128.115.97]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id B0.81.09603.2A279205; Mon, 13 Aug 2012 14:33:22 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by fenugreek.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0M8P008SYQJMP220@fenugreek.apple.com> for pcp@ietf.org; Mon, 13 Aug 2012 14:33:22 -0700 (PDT) From: james woodyatt Message-id: Date: Mon, 13 Aug 2012 14:33:22 -0700 To: "pcp@ietf.org" X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgluLIzCtJLcpLzFFi42IRbChO1F1UpBlgsGa2pcXkY79ZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsXz7NLaCDWwV8+b/ZG9g7GLtYuTgkBAwkdix2LiLkRPIFJO4 cG89WxcjF4eQwAwmibbbF6GcWUwSy698ZgapYhNQkfh2+S4TiM0soCWxfudxKFtb4sm7C2BD hQWcJf4uDAYJ8wrYSPQ+3ssOEmYRUJXomG8HEhYRUJQ4sO0GO0SJHtDed4wQN8hKfD98nm0C I+8sJAtmIVkwC0nLAkbmVYyCRak5iZWGJnqJBQU5qXrJ+bmbGMHhUmiyg/HgT/5DjAIcjEo8 vA7mmgFCrIllxZW5hxglOJiVRHh1MoFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeXt3KAUICaQn lqRmp6YWpBbBZJk4OKUaGHuznW9V/vzu5ts09+NtEynJ40FLT7y6mvVWVE9m1pG6bXmtSed+ ibtZnM9MWej+ivOCzu1Du7UW/dx7fdmc/pgJv0J/9OeqnJx4ZMrsvveLMl9mayZrcChnNp7t XfQ0ao/9+z9Gz+6l6l8sie5I4wjYk7I75ccEL7vy+V97rTYa1hqX75h0YIISS3FGoqEWc1Fx IgCvsGwMEwIAAA== Subject: [pcp] I-D.ietf-pcp-base needs UNSAF Consideration, c.f. RFC 3424 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 21:33:25 -0000 everyone-- In every usage scenario other than the RFC 6092 IPv6 Simple Security one, Port Control Protocol (PCP) is an UNSAF system, according to the terminology in RFC 3424. The predecessor specification to the PCP Base draft, the NAT Port Mapping Protocol [I-D.cheshire-nat-pmp], has three pages of UNSAF Considerations in Section 4, and I don't understand why the PCP Base draft doesn't contain a similar section. Was this an oversight, or is it a deliberate omission? Was there a discussion on the list leading up to a working group decision to omit the UNSAF Considerations section from the draft? If so, then I would like to review that discussion for my own personal edification. -- james woodyatt member of technical staff, core os networking From tireddy@cisco.com Tue Aug 14 02:05:19 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC98121F866D for ; Tue, 14 Aug 2012 02:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.28 X-Spam-Level: X-Spam-Status: No, score=-10.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UEvS7DzfjL0 for ; Tue, 14 Aug 2012 02:05:19 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id F33B921F866B for ; Tue, 14 Aug 2012 02:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=4173; q=dns/txt; s=iport; t=1344935119; x=1346144719; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6L784HKrrQEZcIHQpLxqzKGf9tpgBTQNhyQXfP50ees=; b=L4KLKQM8oPXqJbTAW9HBVs+0shgWL9Qc+L9XC30kyZD2BTvjw7PA0641 XzJsly8mYsrxod00dkMWxS0Yye13/uJ05huv919O8t7o8KRGJRaSCHp6K ZeZEUiIv+GivYUFIFCA16rAu/3qvFy/uhP4ZG/OzTezmwYbHSBR3sLrvz M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFcUKlCtJV2d/2dsb2JhbABEug6BB4IgAQEBBBIBJz0OBAIBCBEDAQEBCxQFBAchERQJCAIEARIIAQsOh1wDDAuYF5csDYlOiiFkBRaFNmADk3iCZ4l2gyCBZoJf X-IronPort-AV: E=Sophos;i="4.77,765,1336348800"; d="scan'208";a="111337627" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 14 Aug 2012 09:05:18 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7E95I2v009825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Aug 2012 09:05:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Tue, 14 Aug 2012 04:05:18 -0500 From: "Tirumaleswar Reddy (tireddy)" To: GangChen , "pcp@ietf.org" Thread-Topic: [pcp] Issue Analysis of PCP in Mobile Network was (Fwd: New Version Notification for draft-chen-pcp-mobile-deployment-01.txt) Thread-Index: AQHNY4V3euq9CB4dPEON9BKc/XznjpdYtExg Date: Tue, 14 Aug 2012 09:05:18 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14782FFE@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.75.236] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19112.003 x-tm-as-result: No--42.191100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Issue Analysis of PCP in Mobile Network was (Fwd: New Version Notification for draft-chen-pcp-mobile-deployment-01.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 09:05:20 -0000 Hi - 1. Section 2.1 Can you please clarify what kind of applications on Mobile devices would re= quire port range on Firewall ? MAP/PEER cannot be used to request Firewall to open a range of ports (other= than "all ports") I am not sure what you mean by resource saving on the "Firewall node" - cla= rify 2. Section 5 There is similar problem in PMIPv6 with multiple APN. But with IPv6, MN wi= ll be assigned prefixes from multiple APN (using SLAAC). Firewall may be lo= cated only in the Internet-APN. In case of IPv4, MAG can act as PCP Server = to the Mobile Node and MAG will have act as PCP Proxy and propagate the PCP= request to PCP Server in appropriate APN. More clarity is required on thi= s section. 2. Section 7 Thus a PCP server SHOULD take care to throttle unicast ANNOUNCE messages it sends towards a collection of MN. Comment> Yes, this is a problem. For example RA throttle is dealt using the techniqu= e in http://tools.ietf.org/html/draft-thubert-savi-ra-throttler-01 For example dedicated RA is unicast to each of the associated devices as op= posed to sent once as a layer 2 broadcast to all devices in a single shot. What is the plan to address such problem for ANNOUNCE ?=20 For e.g. permit ANNOUNCE only on selected trusted ports. 3. Section 9 Because the UE has been authenticated to the MGW during context setup, i= f the MGW delegates its trust to the NAT/FW device (PCP server), the NAT/FW device can trust the PCP requests from those users. Comment> I guess if the Mobile network combines UE authentication with MGW + ingress= filtering (to prevent IP address spoofing, there may not be a need for exp= licit PCP authentication). Refer to section 17.3.2 in base PCP spec. --Tiru. > -----Original Message----- > From: GangChen [mailto:phdgang@gmail.com] > Sent: Monday, July 16, 2012 9:25 PM > To: pcp@ietf.org > Subject: [pcp] Issue Analysis of PCP in Mobile Network was (Fwd: New > Version Notification for draft-chen-pcp-mobile-deployment-01.txt) >=20 > Hello all, >=20 > We had a discussion of PCP in mobile context at last IETF meeting. > This work was encouraged to continue the analysis of major issues when > PCP is adopted in a mobile environment. > Considering very specific features in mobile network, we made a > thorough study to current PCP protocol design. > Several typical issues have been pointed. > PCP applicability to these issues is further presented in the memo. > The authors would seek your reviews and comments. > Hope the work is of value to the community. >=20 > Best Regards >=20 > Authors of PCP-mobile >=20 > ---------- Forwarded message ---------- > From: internet-drafts@ietf.org > Date: Mon, 16 Jul 2012 08:17:46 -0700 > Subject: New Version Notification for draft-chen-pcp-mobile-deployment- > 01.txt > To: phdgang@gmail.com > Cc: caozhen@chinamobile.com, mohamed.boucadair@orange.com, > ales.vizdal@t-mobile.cz, laurent.thiebaut@alcatel-lucent.com >=20 >=20 > A new version of I-D, draft-chen-pcp-mobile-deployment-01.txt > has been successfully submitted by Gang Chen and posted to the > IETF repository. >=20 > Filename: draft-chen-pcp-mobile-deployment > Revision: 01 > Title: Analysis of Port Control Protocol in Mobile Network > Creation date: 2012-07-16 > WG ID: Individual Submission > Number of pages: 14 > URL: > http://www.ietf.org/internet-drafts/draft-chen-pcp-mobile-deployment- > 01.txt > Status: > http://datatracker.ietf.org/doc/draft-chen-pcp-mobile-deployment > Htmlized: http://tools.ietf.org/html/draft-chen-pcp-mobile- > deployment-01 > Diff: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-chen-pcp-mobile-deployment-01 >=20 > Abstract: > This memo provides a motivation description for the Port Control > Protocol (PCP) deployment in a 3GPP mobile network environment. The > document focuses on a mobile network specific issues (e.g. cell > phone > battery power consumption, keep-alive traffic reduction), PCP > applicability to these issues is further studied and analysed. >=20 >=20 >=20 >=20 > The IETF Secretariat From hartmans@painless-security.com Tue Aug 14 11:55:52 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE4E21F8564 for ; Tue, 14 Aug 2012 11:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.407 X-Spam-Level: **** X-Spam-Status: No, score=4.407 tagged_above=-999 required=5 tests=[AWL=-1.370, BAYES_05=-1.11, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FuMWNbpezty for ; Tue, 14 Aug 2012 11:55:52 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3860321F853F for ; Tue, 14 Aug 2012 11:55:52 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 81054206EE; Tue, 14 Aug 2012 14:46:36 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 80F7B4350; Tue, 14 Aug 2012 14:46:33 -0400 (EDT) From: Sam Hartman To: james woodyatt References: Date: Tue, 14 Aug 2012 14:46:33 -0400 In-Reply-To: (james woodyatt's message of "Mon, 13 Aug 2012 14:33:22 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "pcp@ietf.org" Subject: Re: [pcp] I-D.ietf-pcp-base needs UNSAF Consideration, c.f. RFC 3424 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 18:55:52 -0000 >>>>> "james" == james woodyatt writes: james> The predecessor specification to the PCP Base draft, the NAT james> Port Mapping Protocol [I-D.cheshire-nat-pmp], has three pages james> of UNSAF Considerations in Section 4, and I don't understand james> why the PCP Base draft doesn't contain a similar section. I don't know how this came about. However as a matter a process, I don't think it appropriate to add this to the PCP base spec nor hold up the PCP base spec for this issue post iesg-review. If you brought this up as an IETF last call comment, a WGLC comment or earlier, I'd probably agree we should address it. However as specs get more and more done I think the bar for changes needs to get higher and higher. I mean I guess someone could file an appeal based on that issue and the IESG would have to consider such an appeal. However I'd suggest a more constructive approach than either appealing the approval of the base spec when it happens or delaying the base spec would be to write up a draft about UNSAF considerations for PCP and see if people are interested in publishing it. --Sam From dxhbupt@gmail.com Tue Aug 14 12:48:24 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F49221E8086 for ; Tue, 14 Aug 2012 12:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rkNIWJN7ppe for ; Tue, 14 Aug 2012 12:48:23 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E52221E8063 for ; Tue, 14 Aug 2012 12:48:22 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so489644lbb.31 for ; Tue, 14 Aug 2012 12:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WG77c8AFJllc7vk+jxLyLXLSqV5wbE6K2t5qZew+qAY=; b=xaR6KhuHHr7wpTTIyk0LgLXkyxDKDeOMVSz0xFzBtMmD67M6riAMk2eTZnEpgsBMna rGxeddmKc8sbIPbCx3/x/kHjmpf0FKI0nO1Wk3hSUQFiRaYdTr05pJSc82rAjQB0vv7j gOncIdHMOe6CtA0VO4qdr5GiZI9sAB5nWIv57ZnH2VgYoxHn2V84mG2p+YtpJsDvsm4/ /91GyNMIpXZXRVMpLqX91PNP3P6NERNmS5WrrF9J1KcYABmwcGU5UZJpsKQD+S9cdA87 niXKMA59dgGRNh7Mad2hLBiGrq7cIIBQhDbe/4bNZlIgTCTii9cNPIl4u5ADM9fQZvmc KBmg== MIME-Version: 1.0 Received: by 10.112.46.9 with SMTP id r9mr8469151lbm.81.1344973701999; Tue, 14 Aug 2012 12:48:21 -0700 (PDT) Received: by 10.112.43.196 with HTTP; Tue, 14 Aug 2012 12:48:21 -0700 (PDT) Date: Tue, 14 Aug 2012 21:48:21 +0200 Message-ID: From: Xiaohong Deng To: draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org, pcp@ietf.org Content-Type: multipart/alternative; boundary=f46d0401236fbd6c7b04c73f17f5 Subject: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 19:48:24 -0000 --f46d0401236fbd6c7b04c73f17f5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello authors and WG, Here is my review of draft-ietf-pcp-upnp-igd-interworking-02. Overall I think the draft is in a good shape, neat, easy to follow, and has a good architecture for WGLC. Below are a couple of questions and thoughts on text. Two types of them: the ones begin with +, are ones that, in my point of view, are worth to be addressed, and the ones begin with *, are minor ones that may make no significant difference. In both cases if I miss something, please elaborate and clarify. Thanks. Interworking Function (IGD-PCP IWF) is required to be embedded in CP + CP -> Customer Premises (CP) Triggers for deactivating the UPnP IGD-PCP Interworking Function from the IGD and relying on a PCP-only mode are out of scope of this + I=92m not sure I understand exactly "Triggers for deactivating the UPnP IGD-PCP Interworking Function". what does that exactly mean? Deactivating the whole IWF or IGD? (1) Section 4.1 provides the mapping between WANIPConnection State Variables and PCP parameters; + would suggest using=91correspondence=92 than =91mapping=92, as no mapping= s required to store in IGD for that, and also for lowering confusion with NAT mappings on a per UPnP CP basis. + UPnP CP -> UPnP Control Point? There are two 'CP' exit in the document, which I suppose stand for different things respectively. PortMappingEnabled: PCP does not support deactivating the dynamic NAT mapping since the initial goal of PCP is to ease the traversal of Carrier Grade NAT. Supporting such per-subscriber function may overload the Carrier Grade NAT. + What if the customer wants to deactivate a static NAT mappings on CGN? it is not stated clearly that IWF should support it or not. My reading here is that for the same reason: not to overload the carrier Grade NAT, it should not support deactivate static mappings either. IMO,it=92s worth to state clearer that it applys to both static and dynamic mappings, if that is what text here means. On reading the value is 1, writing a value different from 1 is not supported. + what if on reading the value is 0, which means deactivating the mapping? Point, it must be resolved to an IP address by the Interworking Function when relying the message to the PCP Server. + Must? Does this mean IWF must have a DNS resolving function also? 6 MALFORMED_OPTION: 501 "ActionFailed" Should not happen. *It may happen when IWF is not correctly implemented, mistached version of implementation with PCP server, and extra. 7 NETWORK_FAILURE: Not applicable Should not happen after communication was successfully established with a PCP Server. *What if IWF/PCP Client fails to establish communication with a PCP server? In that case, I see that "ActionFailed" looks like the semantical correspondence. Note: According to some experiments, some UPnP 1.0 implementations, e.g., uTorrent, simply try the same external port X times (usually 4 times) and then fail. Also note that some applications uses GetSpecificPortMapping() to check whether a mapping exists. *Behavior of uTorrent is more like following: it tries GetSpecificPortMapping X times (usually 4 times),if it finds an external port not being used before X times, it will call AddPortMapping Upon receipt of GetSpecificPortMappingEntry() from a UPnP Control Point, the IGD-PCP IWF MUST check first if the external port number is used by the requesting UPnP Control Point. If the external port is already in use by the requesting UPnP Control Point, the IGD-PCP IWF MUST send back a positive answer. If not, the IGD-PCP IWF MUST *or more precisely: IWF MUST send back mapping entires specified by the unique tuple of ExternalPort and PortMappingProtocol. relay to the PCP Server a MAP request, with short lifetime (e.g., 60s), including a PREFER_FAILURE Option. If the requested external port is in use, a PCP error message will be sent by the PCP Server to the IGD-PCP IWF indicating CANNOT_PROVIDE_EXTERNAL as the error cause. Then, the IGD-PCP IWF relays a negative message to the UPnP Control Point. If the port is not in use, the mapping will be + if CANNOT-PROVIDE_EXTERNAL is returned from PCP server, it means the enquired external port is being used: for example, enquired external port is being used by another customer sharing the same external IP. Since one of major usage of GetSpecificPortMappingEntry() is for UPnP control point to find out if an external port is available, how about using 718 "ConflictInMappingEntry"? which, to my eyes, provides a better semantic in this context. created by the PCP Server and a positive response will be sent back to the IGD-PCP IWF. Once received by the IGD-PCP IWF, it MUST relay a negative message to the UPnP Control Point indicating NoSuchEntryInArray as error code. *Since this is a somehow complicated to be understood case, add something like below may make it slightly clearer: it MUST relay a negative message to the UPnP Control Point indicating NoSuchEntryInArray as error code so that the UPnP control point knows the enquired mapping doesn't exist. Cheers, -Xiaohong --f46d0401236fbd6c7b04c73f17f5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello authors and WG,

Here is my review of draft-ietf-pcp-upnp-igd-i= nterworking-02.

Overall I think the draft is in a good shape, neat,= easy to follow, and has a good architecture for WGLC. Below are a couple o= f questions and thoughts on text. Two types of them: the ones begin with +,= are ones that, in my point of view, are worth to be addressed, and the one= s begin with *, are minor ones that may make no significant difference. In = both cases if I miss something, please elaborate and clarify. Thanks.


=A0 Interworking Function (IGD-PCP IWF) is required to be embedded = in CP
+ CP -> Customer Premises (CP)


=A0=A0 Triggers for = deactivating the UPnP IGD-PCP Interworking Function from
=A0=A0 the IGD = and relying on a PCP-only mode are out of scope of this
+ I=92m not sure I understand exactly "Triggers for deactivating the U= PnP IGD-PCP Interworking Function". what does that exactly mean? Deact= ivating the whole IWF or IGD?



=A0=A0 (1)=A0 Section 4.1 prov= ides the mapping between WANIPConnection State
=A0=A0=A0=A0=A0=A0=A0 Variables and PCP parameters;
+ would suggest usin= g=91correspondence=92 than =91mapping=92, as no mappings required to store = in IGD for that, and also for lowering confusion with NAT mappings

<= br>=A0=A0=A0=A0=A0 on a per UPnP CP basis.
+ UPnP CP -> UPnP Control Point? There are two 'CP' exit in the = document, which I suppose stand for different things respectively.

<= br>=A0=A0 PortMappingEnabled:
=A0=A0=A0=A0=A0 PCP does not support deact= ivating the dynamic NAT mapping since
=A0=A0=A0=A0=A0 the initial goal of PCP is to ease the traversal of Carrier= Grade
=A0=A0=A0=A0=A0 NAT.=A0 Supporting such per-subscriber function m= ay overload the
=A0=A0=A0=A0=A0 Carrier Grade NAT.
+ What if the cust= omer wants to deactivate a static NAT mappings on CGN? it is not stated cle= arly that IWF should support it or not. My reading here is that for the sam= e reason: not to overload the carrier Grade NAT, it should not support deac= tivate static mappings either. IMO,it=92s worth to state clearer that it ap= plys to both static and dynamic mappings, if that is what text here means.<= br>

=A0=A0=A0=A0=A0 On reading the value is 1, writing a value differen= t from 1 is not
=A0=A0=A0=A0=A0 supported.
+ what if on reading the v= alue is 0, which means deactivating the mapping?


=A0=A0=A0=A0=A0= Point, it must be resolved to an IP address by the Interworking
=A0=A0=A0=A0=A0 Function when relying the message to the PCP Server.
+ M= ust? Does this mean IWF must have a DNS resolving function also?

=A0=A0 6 MALFORMED_OPTION:=A0 501 "ActionFailed"
=A0=A0=A0=A0= =A0 Should not happen.
*It may happen when IWF is not correctly implemented, mistached version of = implementation with PCP server, and extra.


=A0=A0 7 NETWORK_FAIL= URE:=A0 Not applicable
=A0=A0=A0=A0=A0 Should not happen after communica= tion was successfully established
=A0=A0=A0=A0 with a PCP Server.
*What if IWF/PCP Client fails to establi= sh communication with a PCP server? In that case, I see that "ActionFa= iled" looks like the semantical correspondence.



=A0=A0= =A0=A0=A0 Note: According to some experiments, some UPnP 1.0
=A0=A0=A0=A0=A0 implementations, e.g., uTorrent, simply try the same extern= al port
=A0=A0=A0=A0=A0 X times (usually 4 times) and then fail.=A0 Also= note that some
=A0=A0=A0=A0=A0 applications uses GetSpecificPortMapping= () to check whether a
=A0=A0=A0=A0=A0 mapping exists.
*Behavior of uTorrent is more like following: it tries GetSpecificPortMappi= ng X times (usually 4 times),if it finds an external port not being used be= fore X times, it will call AddPortMapping



=A0=A0 Upon receip= t of GetSpecificPortMappingEntry() from a UPnP Control
=A0=A0 Point, the IGD-PCP IWF MUST check first if the external port number<= br>=A0=A0 is used by the requesting UPnP Control Point.=A0 If the external = port
=A0=A0 is already in use by the requesting UPnP Control Point, the = IGD-PCP
=A0=A0 IWF MUST send back a positive answer.=A0 If not, the IGD-PCP IWF MUS= T

*or more precisely: IWF MUST send back mapping entires specified b= y the unique tuple of ExternalPort and PortMappingProtocol.


=A0= =A0 relay to the PCP Server a MAP request, with short lifetime (e.g.,
=A0=A0 60s), including a PREFER_FAILURE Option.=A0 If the requested externa= l
=A0=A0 port is in use, a PCP error message will be sent by the PCP Ser= ver to
=A0=A0 the IGD-PCP IWF indicating CANNOT_PROVIDE_EXTERNAL as the = error
=A0=A0 cause.=A0 Then, the IGD-PCP IWF relays a negative message t= o the UPnP
=A0=A0 Control Point.=A0 If the port is not in use, the mapping will be
=
+ if CANNOT-PROVIDE_EXTERNAL is returned from PCP server, it means the = enquired external port is being used: for example, enquired external port i= s being used by another customer sharing the same external IP. Since one of= major usage of GetSpecificPortMappingEntry() is for UPnP control point to = find out if an external port is=A0 available, how about using 718 "Con= flictInMappingEntry"? which, to my eyes, provides a better semantic in= this context.


=A0=A0 created by the PCP Server and a positive response will be se= nt back
=A0=A0 to the IGD-PCP IWF.=A0 Once received by the IGD-PCP IWF, = it MUST relay
=A0=A0 a negative message to the UPnP Control Point indica= ting
=A0=A0 NoSuchEntryInArray as error code.

*Since this is a somehow complicated to be understood case, add somethi= ng like below may make it slightly clearer:

it MUST relay a negative= message to the UPnP Control Point indicating NoSuchEntryInArray as error c= ode so that the UPnP control point knows the enquired mapping doesn't e= xist.

Cheers,
-Xiaohong

--f46d0401236fbd6c7b04c73f17f5-- From jhw@apple.com Tue Aug 14 13:21:44 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D6D21E8054 for ; Tue, 14 Aug 2012 13:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.553 X-Spam-Level: X-Spam-Status: No, score=-110.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMZ6izbaa4Zd for ; Tue, 14 Aug 2012 13:21:42 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id B57E421E804C for ; Tue, 14 Aug 2012 13:21:42 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0M8R0083NH8NK86B@mail-out.apple.com> for pcp@ietf.org; Tue, 14 Aug 2012 13:21:25 -0700 (PDT) X-AuditID: 11807130-b7fb86d000004da6-d4-502ab345ffe7 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 0D.1F.19878.543BA205; Tue, 14 Aug 2012 13:21:25 -0700 (PDT) Received: from kallisti.apple.com ([17.193.13.64]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0M8R008OCHVND6A0@spicerack.apple.com> for pcp@ietf.org; Tue, 14 Aug 2012 13:21:25 -0700 (PDT) From: james woodyatt In-reply-to: Date: Tue, 14 Aug 2012 13:21:23 -0700 Message-id: <0EE48C8D-317F-4F73-8ED1-B764584267F4@apple.com> References: To: "pcp@ietf.org" X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUi2FCsoeu6WSvA4P9iKYvJx36zOjB6LFny kymAMYrLJiU1J7MstUjfLoErY/bBy6wFS9gqFq7YwdTA+Ieli5GTQ0LARGLl1xPMELaYxIV7 69m6GLk4hARmMEmcntECViQkMItJ4sQ7dhCbWUBLYv3O40wgNq+AHlDDO0YQW1jAV+L355Vg NpuAisS3y3fBajgF1CTW/28Dm8MioCox7/ZJqDnaEk/eXWCFmGMj8X/9F2aIXRESp2bfAasR EVCUOLDtBjvEcbIS3w+fZ5vAyD8LyRmzkJwxC8nYBYzMqxgFi1JzEisNDfUSCwpyUvWS83M3 MYJDrNBgB+Pan/yHGAU4GJV4eB3MNQOEWBPLiitzDzFKcDArifC+Xq0VIMSbklhZlVqUH19U mpNafIhRmoNFSZy3Z4dSgJBAemJJanZqakFqEUyWiYNTqoGxJUVaJSs66qQw09egZDvvLMMv KhaaC/Yv7PX562e8fO9aqXfa6tLKypc9XevF6uadPcxr+NhKtmrJxhU3TR/VyPjOfmgyZ5+g 5rtXLnOqdk63aVv074h6yK4mhsyp2k//fCuZ/4b/k+7XWY++vFiR+/HQOR2pw76F+55eat80 c/sSvu/liqdLlFiKMxINtZiLihMBfMkBTy0CAAA= Subject: Re: [pcp] I-D.ietf-pcp-base needs UNSAF Consideration, c.f. RFC 3424 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 20:21:44 -0000 On Aug 14, 2012, at 11:46 , Sam Hartman wrote: > > I don't know how this came about. However as a matter a process, I don't think it appropriate to add this to the PCP base spec nor hold up the PCP base spec for this issue post iesg-review. Concur. I'm just interested in finding out how the UNSAF considerations section, which appeared in the predecessor specification, was omitted from the PCP base draft. Was there a discussion about it, or did it happen without discussion? Whatever the case, I'm thinking the story about how it happened should be brought to the attention of IAB with a request to consider moving RFC 3424 to Historic. -- james woodyatt member of technical staff, core os networking From zhangdacheng@huawei.com Wed Aug 15 19:50:46 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA2221F84C4 for ; Wed, 15 Aug 2012 19:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.77 X-Spam-Level: X-Spam-Status: No, score=-5.77 tagged_above=-999 required=5 tests=[AWL=0.828, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoL+YY1Afs35 for ; Wed, 15 Aug 2012 19:50:45 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BB92821F8491 for ; Wed, 15 Aug 2012 19:50:26 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJL38439; Wed, 15 Aug 2012 18:50:26 -0800 (PST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 19:47:21 -0700 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Aug 2012 19:47:25 -0700 Received: from SZXEML528-MBS.china.huawei.com ([169.254.5.24]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 16 Aug 2012 10:47:17 +0800 From: "Zhangdacheng (Dacheng)" To: Margaret Wasserman , Dan Wing Thread-Topic: [pcp] Comparison of PCP authentication Thread-Index: Ac12W6ER1F5Ai0qa4kawmCOKzP6BvgAAVNUQ//+IUID/9Zu6kA== Date: Thu, 16 Aug 2012 02:47:16 +0000 Message-ID: References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> In-Reply-To: <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.49] Content-Type: multipart/alternative; boundary="_000_C72CBD9FE3CA604887B1B3F1D145D05E2CE756EEszxeml528mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pcp@ietf.org" Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 02:50:46 -0000 --_000_C72CBD9FE3CA604887B1B3F1D145D05E2CE756EEszxeml528mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Have we got any conclusions on two approaches? Or we can just support the = two options in the draft for the moment and briefly compare their pros and = cons, can we? Cheers Dcheng From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Marga= ret Wasserman Sent: Friday, August 10, 2012 3:21 AM To: Dan Wing Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication On Aug 9, 2012, at 2:32 PM, Dan Wing wrote: If I'm updating security policy on a firewall I want to be able to audit whether that actually happened. That requires authentication. You are saying a PCP client would only want to update firewall policies if the PCP server supports authentication, otherwise it would tell the user that it cannot enable the webcam, Internet-connected NAS, Internet-connected printer, etc.? I wont presume to guess what Sam is thinking... However, I am thinking that there will be some clients that are configured= to perform authentication for every request. For example, there is no rea= son for a PCP proxy, running in an environment where authentication is requ= ired to do a THIRD-PARTY request, to perform a useless round-trip for every= THIRD-PARTY request it issues. Margaret --_000_C72CBD9FE3CA604887B1B3F1D145D05E2CE756EEszxeml528mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Have we go= t any conclusions on two approaches?  Or we can just support the two o= ptions in the draft for the moment and briefly compare their pros and cons, can we?

 = ;

Cheers

 = ;

Dcheng

 = ;

From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Margaret Wasserman
Sent: Friday, August 10, 2012 3:21 AM
To: Dan Wing
Cc: pcp@ietf.org
Subject: Re: [pcp] Comparison of PCP authentication

 

 

On Aug 9, 2012, at 2:32 PM, Dan= Wing wrote:

 

If I'm updating security policy= on a firewall I want to be able to

audit whether that actually hap= pened.  That requires authentication.


You are saying a PCP client would only want to update firewall policies if the PCP server supports authentication, otherwise it would tell the
user that it cannot enable the webcam, Internet-connected NAS,
Internet-connected printer, etc.?

 

I wont presume to guess what Sa= m is thinking...

 

However, I am thinking that the= re will be some clients  that are configured to perform authentication= for every request.  For example, there is no reason for a PCP proxy, = running in an environment where authentication is required to do a THIRD-PARTY request, to perform a useless round-trip f= or every THIRD-PARTY request it issues.  

 

Margaret

 

 

--_000_C72CBD9FE3CA604887B1B3F1D145D05E2CE756EEszxeml528mbschi_-- From yoshihiro.ohba@toshiba.co.jp Wed Aug 15 20:41:41 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B621A11E80EC for ; Wed, 15 Aug 2012 20:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.624 X-Spam-Level: X-Spam-Status: No, score=-3.624 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsmyQCBuXd3f for ; Wed, 15 Aug 2012 20:41:41 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id B876D11E80E7 for ; Wed, 15 Aug 2012 20:41:37 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q7G3faqL016465 for ; Thu, 16 Aug 2012 12:41:36 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q7G3fZdT021000 for pcp@ietf.org; Thu, 16 Aug 2012 12:41:35 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id NAA20996; Thu, 16 Aug 2012 12:41:35 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q7G3fZZ7004611 for ; Thu, 16 Aug 2012 12:41:35 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q7G3fZQ7022307; Thu, 16 Aug 2012 12:41:35 +0900 (JST) Received: from [133.196.20.119] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0M8T008MSWXBK140@mail.po.toshiba.co.jp> for pcp@ietf.org; Thu, 16 Aug 2012 12:41:35 +0900 (JST) Date: Thu, 16 Aug 2012 12:41:36 +0900 From: Yoshihiro Ohba In-reply-to: To: pcp@ietf.org Message-id: <502C6BF0.3030400@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 03:41:41 -0000 Here is a brief comparison on both PANA-based schemes: Encapsulation/tunneling approach: - Pros: No impact on PANA specification - Cons: Encapsulation overhead Demultiplexing/port-sharing approach: - Pros: No encapsulation overhead - Cons: Impact on PANA specification (an Update of RFC 5191 is needed on the use of "Reserved" field.) Hope this helps, Yoshihiro Ohba (2012/08/16 11:47), Zhangdacheng (Dacheng) wrote: > Have we got any conclusions on two approaches? Or we can just support > the two options in the draft for the moment and briefly compare their > pros and cons, can we? > > Cheers > > Dcheng > > *From:*pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] *On Behalf > Of *Margaret Wasserman > *Sent:* Friday, August 10, 2012 3:21 AM > *To:* Dan Wing > *Cc:* pcp@ietf.org > *Subject:* Re: [pcp] Comparison of PCP authentication > > On Aug 9, 2012, at 2:32 PM, Dan Wing wrote: > > If I'm updating security policy on a firewall I want to be able to > > audit whether that actually happened. That requires > authentication. > > > You are saying a PCP client would only want to update firewall > policies > if the PCP server supports authentication, otherwise it would tell the > user that it cannot enable the webcam, Internet-connected NAS, > Internet-connected printer, etc.? > > I wont presume to guess what Sam is thinking... > > However, I am thinking that there will be some clients that are > configured to perform authentication for every request. For example, > there is no reason for a PCP proxy, running in an environment where > authentication is required to do a THIRD-PARTY request, to perform a > useless round-trip for every THIRD-PARTY request it issues. > > Margaret > > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From mohamed.boucadair@orange.com Thu Aug 16 01:24:56 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C5121F84C2 for ; Thu, 16 Aug 2012 01:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.343 X-Spam-Level: X-Spam-Status: No, score=-1.343 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, SARE_SUB_RAND_LETTRS4=0.799, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oICXp3Li1CAf for ; Thu, 16 Aug 2012 01:24:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1B00721F844E for ; Thu, 16 Aug 2012 01:24:53 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 34D9F2641F8; Thu, 16 Aug 2012 10:24:53 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 1599A4C06B; Thu, 16 Aug 2012 10:24:53 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 16 Aug 2012 10:24:35 +0200 From: To: Xiaohong Deng , "draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org" , "pcp@ietf.org" Date: Thu, 16 Aug 2012 10:24:34 +0200 Thread-Topic: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking Thread-Index: Ac16Vbv3MzHDIHiITW26OIOqggfULgBHxPOQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E4FC2DA35@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E4FC2DA35PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.16.74528 Subject: Re: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 08:24:56 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E4FC2DA35PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Xioahong, Thank you for your review. Please see inline. Cheers Med ________________________________ De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Xiaoh= ong Deng Envoy=E9 : mardi 14 ao=FBt 2012 21:48 =C0 : draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org; pcp@ietf.org Objet : [pcp] Review of draft-ietf-pcp-upnp-igd-interworking Hello authors and WG, Here is my review of draft-ietf-pcp-upnp-igd-interworking-02. Overall I think the draft is in a good shape, neat, easy to follow, and has= a good architecture for WGLC. Below are a couple of questions and thoughts= on text. Two types of them: the ones begin with +, are ones that, in my po= int of view, are worth to be addressed, and the ones begin with *, are mino= r ones that may make no significant difference. In both cases if I miss som= ething, please elaborate and clarify. Thanks. Interworking Function (IGD-PCP IWF) is required to be embedded in CP + CP -> Customer Premises (CP) [Med] I expanded the acronym. Triggers for deactivating the UPnP IGD-PCP Interworking Function from the IGD and relying on a PCP-only mode are out of scope of this + I'm not sure I understand exactly "Triggers for deactivating the UPnP IGD= -PCP Interworking Function". what does that exactly mean? Deactivating the = whole IWF or IGD? [Med] The sentence is about de-activating the IWF. It is out of scope of th= is document to elaborate on conditions which may justify to de-activate the= IWF in the IGD. (1) Section 4.1 provides the mapping between WANIPConnection State Variables and PCP parameters; + would suggest using'correspondence' than 'mapping', as no mappings requir= ed to store in IGD for that, and also for lowering confusion with NAT mappi= ngs [Med] Done. on a per UPnP CP basis. + UPnP CP -> UPnP Control Point? [Med] Yes. I added an entry to Section 2. There are two 'CP' exit in the document, which I suppose stand for differe= nt things respectively. [Med] The core text does not use CP but IGD. It appears only in the abstrac= t. PortMappingEnabled: PCP does not support deactivating the dynamic NAT mapping since the initial goal of PCP is to ease the traversal of Carrier Grade NAT. Supporting such per-subscriber function may overload the Carrier Grade NAT. + What if the customer wants to deactivate a static NAT mappings on CGN? it= is not stated clearly that IWF should support it or not. My reading here i= s that for the same reason: not to overload the carrier Grade NAT, it shoul= d not support deactivate static mappings either. IMO,it's worth to state cl= earer that it applys to both static and dynamic mappings, if that is what t= ext here means. [Med] IGD spec says "PortMappingEnabled: This variable allows security cons= cious users to disable and enable dynamic NAT port mappings on the IGD.". P= CP does not provide such feature. On reading the value is 1, writing a value different from 1 is not supported. + what if on reading the value is 0, which means deactivating the mapping? [Med] see above. Only "1" is supported. Point, it must be resolved to an IP address by the Interworking Function when relying the message to the PCP Server. + Must? Does this mean IWF must have a DNS resolving function also? [Med] No. This can be passed to a name resolution library. 6 MALFORMED_OPTION: 501 "ActionFailed" Should not happen. *It may happen when IWF is not correctly implemented, mistached version of = implementation with PCP server, and extra. [Med] Yes; but there is no need to list when it can occur. 7 NETWORK_FAILURE: Not applicable Should not happen after communication was successfully established with a PCP Server. *What if IWF/PCP Client fails to establish communication with a PCP server?= In that case, I see that "ActionFailed" looks like the semantical correspo= ndence. [Med] If the IWF fails to establish a communication with the PCP Server, th= en no error is received. An error should be generated locally by the IWF an= d sent back to the UPnP CP. I updated section 5.7.1 and section 5.7.2 to in= dicate "501" error code is returned when the IWF fails to contact its PCP S= erver. Note: According to some experiments, some UPnP 1.0 implementations, e.g., uTorrent, simply try the same external port X times (usually 4 times) and then fail. Also note that some applications uses GetSpecificPortMapping() to check whether a mapping exists. *Behavior of uTorrent is more like following: it tries GetSpecificPortMappi= ng X times (usually 4 times),if it finds an external port not being used be= fore X times, it will call AddPortMapping [Med] I updated the text to indicate the behaviour when a port is not in us= e. Thanks. Upon receipt of GetSpecificPortMappingEntry() from a UPnP Control Point, the IGD-PCP IWF MUST check first if the external port number is used by the requesting UPnP Control Point. If the external port is already in use by the requesting UPnP Control Point, the IGD-PCP IWF MUST send back a positive answer. If not, the IGD-PCP IWF MUST *or more precisely: IWF MUST send back mapping entires specified by the uni= que tuple of ExternalPort and PortMappingProtocol. [Med] I prefer the initial wording without detailing the content of the res= ponse. The exact content of the response is part of the UPnP spec. relay to the PCP Server a MAP request, with short lifetime (e.g., 60s), including a PREFER_FAILURE Option. If the requested external port is in use, a PCP error message will be sent by the PCP Server to the IGD-PCP IWF indicating CANNOT_PROVIDE_EXTERNAL as the error cause. Then, the IGD-PCP IWF relays a negative message to the UPnP Control Point. If the port is not in use, the mapping will be + if CANNOT-PROVIDE_EXTERNAL is returned from PCP server, it means the enqu= ired external port is being used: for example, enquired external port is be= ing used by another customer sharing the same external IP. Since one of maj= or usage of GetSpecificPortMappingEntry() is for UPnP control point to find= out if an external port is available, how about using 718 "ConflictInMapp= ingEntry"? which, to my eyes, provides a better semantic in this context. [Med] Are you sure 718 error code is allowed for GetSpecificPortMappingEntr= y? created by the PCP Server and a positive response will be sent back to the IGD-PCP IWF. Once received by the IGD-PCP IWF, it MUST relay a negative message to the UPnP Control Point indicating NoSuchEntryInArray as error code. *Since this is a somehow complicated to be understood case, add something l= ike below may make it slightly clearer: it MUST relay a negative message to the UPnP Control Point indicating NoSuc= hEntryInArray as error code so that the UPnP control point knows the enquir= ed mapping doesn't exist. [Med] Updated. Thanks. Cheers, -Xiaohong --_000_94C682931C08B048B7A8645303FDC9F36E4FC2DA35PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Xioahong,
 
Thank you for your review.
 
Please see inline.
 
Cheers
Med

De : pcp-bounces@ietf.org=20 [mailto:pcp-bounces@ietf.org] De la part de Xiaohong=20 Deng
Envoy=E9 : mardi 14 ao=FBt 2012 21:48
=C0 = :=20 draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org;=20 pcp@ietf.org
Objet : [pcp] Review of=20 draft-ietf-pcp-upnp-igd-interworking

Hello authors and WG,

Here is my review of=20 draft-ietf-pcp-upnp-igd-interworking-02.

Overall I think the draf= t is=20 in a good shape, neat, easy to follow, and has a good architecture for WG= LC.=20 Below are a couple of questions and thoughts on text. Two types of them: = the=20 ones begin with +, are ones that, in my point of view, are worth to be=20 addressed, and the ones begin with *, are minor ones that may make no=20 significant difference. In both cases if I miss something, please elabora= te=20 and clarify. Thanks.


  Interworking Function (IGD-PCP IWF= ) is=20 required to be embedded in CP
+ CP -> Customer Premises (CP)
[Med] I expanded the=20 acronym. 


   Triggers for deactiv= ating=20 the UPnP IGD-PCP Interworking Function from
   the IGD and=20 relying on a PCP-only mode are out of scope of this
+ I=92m not sure I= =20 understand exactly "Triggers for deactivating the UPnP IGD-PCP Interworki= ng=20 Function". what does that exactly mean? Deactivating the whole IWF or=20 IGD?
[Med] The sentence is about de-activating the I= WF. It=20 is out of scope of this document to elaborate on conditions which ma= y=20 justify to de-activate the IWF in the IGD.=20



   (1)  Section 4.1 provides= the=20 mapping between WANIPConnection=20 State
        Variables and PCP=20 parameters;
+ would suggest using=91correspondence=92 than =91mapping= =92, as no=20 mappings required to store in IGD for that, and also for lowering confusi= on=20 with NAT mappings
[Med] Done. 


&nbs= p;    =20 on a per UPnP CP basis.
+ UPnP CP -> UPnP Control Point?
[Med] Yes. I added an entry to Section=20 2.
 There are two 'CP' exi= t in=20 the document, which I suppose stand for different things=20 respectively.
[Med] The core text does not use CP but IGD.&nb= sp;It=20 appears only in the abstract.
 


  =20 PortMappingEnabled:
      PCP does not suppor= t=20 deactivating the dynamic NAT mapping since
    &nb= sp;=20 the initial goal of PCP is to ease the traversal of Carrier=20 Grade
      NAT.  Supporting such=20 per-subscriber function may overload the
     = ;=20 Carrier Grade NAT.
+ What if the customer wants to deactivate a static= NAT=20 mappings on CGN? it is not stated clearly that IWF should support it or n= ot.=20 My reading here is that for the same reason: not to overload the carrier = Grade=20 NAT, it should not support deactivate static mappings either. IMO,it=92s = worth=20 to state clearer that it applys to both static and dynamic mappings, if t= hat=20 is what text here means.
[Med] IGD spec says "PortMappingEnable= d: This variable allows security conscious users to disable and ena= ble=20 dynamic NAT port mappings on the IGD.". PCP does not provide = such=20 feature. 


      On= =20 reading the value is 1, writing a value different from 1 is=20 not
      supported.
+ what if on reading = the=20 value is 0, which means deactivating the mapping?
[Med] see above. Only "1" is supported.=20  


      Point, it = must=20 be resolved to an IP address by the=20 Interworking
      Function when relying the= =20 message to the PCP Server.
+ Must? Does this mean IWF must have a DNS= =20 resolving function also?
[Med] No. This can be passed to a = ;name=20 resolution library. 


   6=20 MALFORMED_OPTION:  501 "ActionFailed"
    &nb= sp;=20 Should not happen.
*It may happen when IWF is not correctly implemente= d,=20 mistached version of implementation with PCP server, and extra.
[Med] Yes; but there is no need to list wh= en it=20 can occur.   


   7=20 NETWORK_FAILURE:  Not applicable
      S= hould=20 not happen after communication was successfully=20 established
     with a PCP Server.
*What if IW= F/PCP=20 Client fails to establish communication with a PCP server? In that case, = I see=20 that "ActionFailed" looks like the semantical correspondence.
[Med] If the IWF fails to establ= ish a=20 communication with the PCP Server, then no error is received. A= n=20 error should be generated locally by the IWF and sent back to=20 the UPnP CP. I updated section 5.7.1 and section 5.7.2 to indic= ate=20 "501" error code is returned when the IWF fails to contact = ;its=20 PCP=20 Server.  



    =  =20 Note: According to some experiments, some UPnP=20 1.0
      implementations, e.g., uTorrent, si= mply=20 try the same external port
      X times (usu= ally=20 4 times) and then fail.  Also note that=20 some
      applications uses=20 GetSpecificPortMapping() to check whether a
    &n= bsp;=20 mapping exists.
*Behavior of uTorrent is more like following: it tries= =20 GetSpecificPortMapping X times (usually 4 times),if it finds an external = port=20 not being used before X times, it will call AddPortMapping
[Med] I updated the text to indicate = the=20 behaviour when a port is not in use. Thanks.=20  



   Upon receipt of=20 GetSpecificPortMappingEntry() from a UPnP Control
   Point, = the=20 IGD-PCP IWF MUST check first if the external port number
   = is=20 used by the requesting UPnP Control Point.  If the external=20 port
   is already in use by the requesting UPnP Control Poi= nt,=20 the IGD-PCP
   IWF MUST send back a positive answer.  I= f=20 not, the IGD-PCP IWF MUST

*or more precisely: IWF MUST send back=20 mapping entires specified by the unique tuple of ExternalPort and=20 PortMappingProtocol.
[Med] I prefer the initial wording&nbs= p;without=20 detailing the content of the response. The exact content of the resp= onse=20 is part of the UPnP spec.  


 &nbs= p;=20 relay to the PCP Server a MAP request, with short lifetime=20 (e.g.,
   60s), including a PREFER_FAILURE Option.  If = the=20 requested external
   port is in use, a PCP error message wi= ll be=20 sent by the PCP Server to
   the IGD-PCP IWF indicating=20 CANNOT_PROVIDE_EXTERNAL as the error
   cause.  Then, t= he=20 IGD-PCP IWF relays a negative message to the UPnP
   Control= =20 Point.  If the port is not in use, the mapping will be

+ if=20 CANNOT-PROVIDE_EXTERNAL is returned from PCP server, it means the enquire= d=20 external port is being used: for example, enquired external port is being= used=20 by another customer sharing the same external IP. Since one of major usag= e of=20 GetSpecificPortMappingEntry() is for UPnP control point to find out if an= =20 external port is  available, how about using 718=20 "ConflictInMappingEntry"? which, to my eyes, provides a better semantic i= n=20 this context.
[Med] Are you sure 718 error code is allowed fo= r=20 GetSpecificPortMappingEntry? 


  = =20 created by the PCP Server and a positive response will be sent=20 back
   to the IGD-PCP IWF.  Once received by the IGD-P= CP=20 IWF, it MUST relay
   a negative message to the UPnP Control= =20 Point indicating
   NoSuchEntryInArray as error=20 code.

*Since this is a somehow complicated to be understood case, = add=20 something like below may make it slightly clearer:

it MUST relay a= =20 negative message to the UPnP Control Point indicating NoSuchEntryInArray = as=20 error code so that the UPnP control point knows the enquired mapping does= n't=20 exist.
[Med] Updated.=20 Thanks. 

Cheers,
-Xiaohong

--_000_94C682931C08B048B7A8645303FDC9F36E4FC2DA35PUEXCB1Bnante_-- From zhangdacheng@huawei.com Thu Aug 16 01:54:35 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2297721F8570 for ; Thu, 16 Aug 2012 01:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.863 X-Spam-Level: X-Spam-Status: No, score=-5.863 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eskK1F7xDb8N for ; Thu, 16 Aug 2012 01:54:34 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8550221F84E4 for ; Thu, 16 Aug 2012 01:54:34 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp03-ep.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJL56118; Thu, 16 Aug 2012 00:54:34 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Aug 2012 01:52:10 -0700 Received: from SZXEML436-HUB.china.huawei.com (10.72.61.64) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 16 Aug 2012 01:52:09 -0700 Received: from SZXEML528-MBX.china.huawei.com ([169.254.4.229]) by szxeml436-hub.china.huawei.com ([10.72.61.64]) with mapi id 14.01.0323.003; Thu, 16 Aug 2012 16:52:04 +0800 From: "Zhangdacheng (Dacheng)" To: Yoshihiro Ohba , "pcp@ietf.org" Thread-Topic: [pcp] Comparison of PCP authentication Thread-Index: Ac12W6ER1F5Ai0qa4kawmCOKzP6BvgAAVNUQ//+IUID/9Zu6kIAUXgMA//8k6gA= Date: Thu, 16 Aug 2012 08:52:03 +0000 Message-ID: References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <502C6BF0.3030400@toshiba.co.jp> In-Reply-To: <502C6BF0.3030400@toshiba.co.jp> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 08:54:35 -0000 >=20 > Here is a brief comparison on both PANA-based schemes: >=20 > Encapsulation/tunneling approach: > - Pros: No impact on PANA specification > - Cons: Encapsulation overhead About this Con. Maybe we can remove the redundant information in a pana pac= ket and only transport the necessary part in a pcp packet. Therefore, after= receiving the PCP packet, the receiver can re-construct the pana packet. Dacheng From yoshihiro.ohba@toshiba.co.jp Thu Aug 16 02:24:15 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473F321F863B for ; Thu, 16 Aug 2012 02:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.779 X-Spam-Level: X-Spam-Status: No, score=-3.779 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yD84mDy9lnW for ; Thu, 16 Aug 2012 02:24:07 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9106721F84D9 for ; Thu, 16 Aug 2012 02:24:05 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q7G9O3xX004695; Thu, 16 Aug 2012 18:24:03 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q7G9O3S4014763; Thu, 16 Aug 2012 18:24:03 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id UAA14760; Thu, 16 Aug 2012 18:24:03 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q7G9O2ii016379; Thu, 16 Aug 2012 18:24:03 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q7G9O25d021167; Thu, 16 Aug 2012 18:24:02 +0900 (JST) Received: from [133.196.20.119] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0M8U00941CS2KIC0@mail.po.toshiba.co.jp>; Thu, 16 Aug 2012 18:24:02 +0900 (JST) Date: Thu, 16 Aug 2012 18:24:04 +0900 From: Yoshihiro Ohba In-reply-to: To: "Zhangdacheng (Dacheng)" Message-id: <502CBC34.4000408@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <502C6BF0.3030400@toshiba.co.jp> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 09:24:15 -0000 Dacheng, (2012/08/16 17:52), Zhangdacheng (Dacheng) wrote: >> >> Here is a brief comparison on both PANA-based schemes: >> >> Encapsulation/tunneling approach: >> - Pros: No impact on PANA specification >> - Cons: Encapsulation overhead > About this Con. Maybe we can remove the redundant information in a pana packet and only transport the necessary part in a pcp packet. Therefore, after receiving the PCP packet, the receiver can re-construct the pana packet. > If "remove the redundant information" means a change of the basic PANA PDU format other than defining a new use of "Reserved" field, then it is going towards "re-inventing the wheel" direction which we should not go. Yoshihiro Ohba > Dacheng > > From margaretw42@gmail.com Thu Aug 16 04:38:37 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D9A21F85ED for ; Thu, 16 Aug 2012 04:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5M1m-MNJxUZY for ; Thu, 16 Aug 2012 04:38:37 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id CEF2221F85DF for ; Thu, 16 Aug 2012 04:38:36 -0700 (PDT) Received: by qcac10 with SMTP id c10so2224522qca.31 for ; Thu, 16 Aug 2012 04:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=GJqBcUv5AT5hjHTYXGkT2lrEA6tdQ+G7FUbPT36DqRg=; b=mjnI5a112Q37tht6m1BDKjX7OvfQiNxEThfFXiZZu/C9Dh5GDzv4RSHnoeIpp8UzCn jPLOpeW+Xl3BFxgs89zC+xopzK1VXH8Rk7Z6lP4kyZM7GA9SOkIpofKf/Vs/+UjPgH59 ZxeMuzPoFDP21tsZyRiYCcVim/cuHtZv79YggtPLaxD9LqqWil9Cqmq5Di1EdHHTyTZ9 uuhU8ObLmetctnfMVI8jF48tyP+qF56uRvP2tUnSxo9QHHiUtI+5c8Czk0dRVo1HfvLW l9lu1hqCdhgRv8gxYfEKEnKgxIJWOddZdDh6OZ8LypQq8vMBHgr1IpfbNKL84anKuSie 0erA== Received: by 10.224.213.194 with SMTP id gx2mr2473226qab.11.1345117116058; Thu, 16 Aug 2012 04:38:36 -0700 (PDT) Received: from lilac-too.home (pool-71-184-120-122.bstnma.fios.verizon.net. [71.184.120.122]) by mx.google.com with ESMTPS id s9sm6309530qaa.7.2012.08.16.04.38.31 (version=SSLv3 cipher=OTHER); Thu, 16 Aug 2012 04:38:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-10--409792648 From: Margaret Wasserman In-Reply-To: Date: Thu, 16 Aug 2012 07:38:30 -0400 Message-Id: <2340495D-0811-42DD-B0D3-636499A0D802@lilacglade.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> To: "Zhangdacheng (Dacheng)" X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 11:38:37 -0000 --Apple-Mail-10--409792648 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Dacheng, The conclusion from the meeting was that we will document all three = approaches in our document: - PCP Specific - PANA Encapsulated in PCP - PANA Demultiplexed with PCP on the same port Then, we will have an interim PCP conference call to discuss the = trade-offs and hopefully decide between them. Margaret On Aug 15, 2012, at 10:47 PM, Zhangdacheng (Dacheng) wrote: > Have we got any conclusions on two approaches? Or we can just support = the two options in the draft for the moment and briefly compare their = pros and cons, can we? > =20 > Cheers > =20 > Dcheng > =20 > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of = Margaret Wasserman > Sent: Friday, August 10, 2012 3:21 AM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] Comparison of PCP authentication > =20 > =20 > On Aug 9, 2012, at 2:32 PM, Dan Wing wrote: > =20 > If I'm updating security policy on a firewall I want to be able to > audit whether that actually happened. That requires authentication. >=20 > You are saying a PCP client would only want to update firewall = policies=20 > if the PCP server supports authentication, otherwise it would tell the > user that it cannot enable the webcam, Internet-connected NAS,=20 > Internet-connected printer, etc.? > =20 > I wont presume to guess what Sam is thinking... > =20 > However, I am thinking that there will be some clients that are = configured to perform authentication for every request. For example, = there is no reason for a PCP proxy, running in an environment where = authentication is required to do a THIRD-PARTY request, to perform a = useless round-trip for every THIRD-PARTY request it issues. =20 > =20 > Margaret > =20 > =20 --Apple-Mail-10--409792648 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


Hi = Dacheng,

The conclusion from the meeting was = that we will document all three approaches in our = document:

- PCP Specific
- PANA = Encapsulated in PCP
- PANA Demultiplexed with PCP on the same = port

Then, we will have an interim PCP = conference call to discuss the trade-offs and hopefully decide between = them.

Margaret



On Aug 15, 2012, at 10:47 PM, Zhangdacheng (Dacheng) = wrote:

Cheers
Dcheng
 pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org]=  On Behalf Of Margaret = Wasserman
Sent: Friday, August 10, 2012 = 3:21 AM
To: Dan Wing
Cc: pcp@ietf.org
Subject: Re: [pcp] Comparison of PCP = authentication
 
 
On Aug 9, 2012, at 2:32 PM, Dan = Wing wrote:
 
If I'm updating security policy on a firewall I want to = be able to
audit whether that actually happened.  That requires = authentication.

You are saying a PCP client = would only want to update firewall policies 
if the PCP server = supports authentication, otherwise it would tell the
user that it = cannot enable the webcam, Internet-connected NAS, 
Internet-connected = printer, etc.?
 
I wont presume to guess what Sam = is thinking...
 
However, I am thinking that there = will be some clients  that are configured to perform authentication = for every request.  For example, there is no reason for a PCP = proxy, running in an environment where authentication is required to do = a THIRD-PARTY request, to perform a useless round-trip for every = THIRD-PARTY request it issues. =  
 
Margaret
 
 

= --Apple-Mail-10--409792648-- From margaretw42@gmail.com Thu Aug 16 04:41:07 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2702E21F8605 for ; Thu, 16 Aug 2012 04:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSyU1pFYpWa9 for ; Thu, 16 Aug 2012 04:41:06 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 34F7F21F85FF for ; Thu, 16 Aug 2012 04:41:06 -0700 (PDT) Received: by qadz3 with SMTP id z3so416929qad.10 for ; Thu, 16 Aug 2012 04:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=vaUkxMrYSkmUvW4g7Fg7iw+HCvzTFOrHMH6UgBRiCTQ=; b=WQRtbisdVYx6OiEzo7tsiVm4Na+aHt5EhmQLd8RRaW9cArHQjx/g3Vxz7Tpt9ZY5Wb Qd8ZLj2JqAHYI3ohDgg8gGzlf0xD9wJkizAPGoPq8TiuT+lCcWiUciX5pMLPAglqw16L ANdtXRwYD9dnEcL+vMpCrhy6pEvHZM3aqntClRwz7dCFhzuZgCNPNhKAesqqjt1v0Mij EY/fVLBIM1/bSRXDts2Yme6g+kk5fOAYPISLlbQ5iBlu5ake9XXImE8+CYRVfiKeStzo Wn1WyR9NvEOBy/MT/o5va5FDkBH1H5A25XzuQ3ODPWJgk96JAj6eIIzmkS2RpfgssTwC xxsA== Received: by 10.224.193.132 with SMTP id du4mr2345886qab.75.1345117265450; Thu, 16 Aug 2012 04:41:05 -0700 (PDT) Received: from lilac-too.home (pool-71-184-120-122.bstnma.fios.verizon.net. [71.184.120.122]) by mx.google.com with ESMTPS id s9sm6316494qaa.7.2012.08.16.04.41.02 (version=SSLv3 cipher=OTHER); Thu, 16 Aug 2012 04:41:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <502C6BF0.3030400@toshiba.co.jp> Date: Thu, 16 Aug 2012 07:41:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6F0B4ED8-68F1-44BB-A94B-E5D86E6C7254@lilacglade.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <502C6BF0.3030400@toshiba.co.jp> To: Yoshihiro Ohba X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 11:41:07 -0000 Hi Yoshi, On Aug 15, 2012, at 11:41 PM, Yoshihiro Ohba wrote: > Here is a brief comparison on both PANA-based schemes: >=20 > Encapsulation/tunneling approach: > - Pros: No impact on PANA specification > - Cons: Encapsulation overhead >=20 > Demultiplexing/port-sharing approach: > - Pros: No encapsulation overhead > - Cons: Impact on PANA specification (an Update of RFC 5191 is needed > on the use of "Reserved" field.) In both cases, I think there is an open question (raised by my regarding = your draft) of whether we want to modify PANA so that the server will = know that it is performing PCP authentication vs. network access = authentication. I think this could be important, if we want a single = PANA server to be able to serve both purposes in a small network. It is = possible that the credentials/criteria used to authenticate a node for = PCP will be different than for network access, isn't it? Margaret From yoshihiro.ohba@toshiba.co.jp Thu Aug 16 05:45:37 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E9921F8576 for ; Thu, 16 Aug 2012 05:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.014 X-Spam-Level: X-Spam-Status: No, score=-5.014 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5+GWWuEdq1J for ; Thu, 16 Aug 2012 05:45:37 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id D935421F8570 for ; Thu, 16 Aug 2012 05:45:36 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q7GCjX5k018618; Thu, 16 Aug 2012 21:45:33 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q7GCjXlb022824; Thu, 16 Aug 2012 21:45:33 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id XAA22823; Thu, 16 Aug 2012 21:45:33 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q7GCjX9K011171; Thu, 16 Aug 2012 21:45:33 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q7GCjX7Y011548; Thu, 16 Aug 2012 21:45:33 +0900 (JST) Received: from [133.199.16.135] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0M8U009MNM3VKIG0@mail.po.toshiba.co.jp>; Thu, 16 Aug 2012 21:45:33 +0900 (JST) Date: Thu, 16 Aug 2012 21:45:33 +0900 From: Yoshihiro Ohba In-reply-to: <6F0B4ED8-68F1-44BB-A94B-E5D86E6C7254@lilacglade.org> To: Margaret Wasserman Message-id: <502CEB6D.6040304@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <502C6BF0.3030400@toshiba.co.jp> <6F0B4ED8-68F1-44BB-A94B-E5D86E6C7254@lilacglade.org> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 12:45:37 -0000 Hi Margaret, In my opinion, PANA should be dedicated to PCP authentication in both cases where PANA runs over PCP port. In other words, we can say that PANA is used for network access authentication only when PANA operates over PANA port, regardless of whether the same or different credentials are used for PCP authentication and network access authentication. Yoshihiro Ohba (2012/08/16 20:41), Margaret Wasserman wrote: > > Hi Yoshi, > > On Aug 15, 2012, at 11:41 PM, Yoshihiro Ohba wrote: > >> Here is a brief comparison on both PANA-based schemes: >> >> Encapsulation/tunneling approach: >> - Pros: No impact on PANA specification >> - Cons: Encapsulation overhead >> >> Demultiplexing/port-sharing approach: >> - Pros: No encapsulation overhead >> - Cons: Impact on PANA specification (an Update of RFC 5191 is needed >> on the use of "Reserved" field.) > > In both cases, I think there is an open question (raised by my regarding your draft) of whether we want to modify PANA so that the server will know that it is performing PCP authentication vs. network access authentication. I think this could be important, if we want a single PANA server to be able to serve both purposes in a small network. It is possible that the credentials/criteria used to authenticate a node for PCP will be different than for network access, isn't it? > > Margaret > > > From hartmans@painless-security.com Thu Aug 16 05:46:26 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6383021F85E1 for ; Thu, 16 Aug 2012 05:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.162 X-Spam-Level: **** X-Spam-Status: No, score=4.162 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIxjXNbTqSDb for ; Thu, 16 Aug 2012 05:46:26 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id F1EDB21F85D5 for ; Thu, 16 Aug 2012 05:46:25 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7948D2085F; Thu, 16 Aug 2012 08:46:23 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 154A14350; Thu, 16 Aug 2012 08:46:17 -0400 (EDT) From: Sam Hartman To: Margaret Wasserman References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <502C6BF0.3030400@toshiba.co.jp> <6F0B4ED8-68F1-44BB-A94B-E5D86E6C7254@lilacglade.org> Date: Thu, 16 Aug 2012 08:46:17 -0400 In-Reply-To: <6F0B4ED8-68F1-44BB-A94B-E5D86E6C7254@lilacglade.org> (Margaret Wasserman's message of "Thu, 16 Aug 2012 07:41:01 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 12:46:26 -0000 I have a question. As background reading I recommend taking a look at RFC 6677 section 5.1. If we want to use EAP channel binding to bind an authentication to a specific PCP server, how will we do that with PANA? For all three approaches we need to define i1 or what attributes the client sends in the EAP channel binding to give the identity of the PCP server. We could for example use the IP address of the PCP server in the nas-ip-address (or v6 address) AVP. For the PCP specific approach the rest is easy. The PCP server knows it is a PCP server, and includes those attributes in the AAA message so that the EAP server has i2. How does the PANA server find out i2? RFC 6677 strongly recommends that an eap-lower-layer attribute be included. There's a value defined for PANA. However, that wouldn't really be a good choice here because it would not allow an EAP server to distinguish PCP authentications from uses of PANA for network access. how does the PANA server know which eap-lower-layer to include? --Sam From margaretw42@gmail.com Thu Aug 16 05:53:43 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A32621F85D5 for ; Thu, 16 Aug 2012 05:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77MvFdkr6fIJ for ; Thu, 16 Aug 2012 05:53:42 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82E4C21F8594 for ; Thu, 16 Aug 2012 05:53:42 -0700 (PDT) Received: by qadb17 with SMTP id b17so467590qad.10 for ; Thu, 16 Aug 2012 05:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=aaAaoBT++O96PrA/u46Mv/sqwZA5nqickttxC5AXGnc=; b=KfiFHY/T7Vif5Om84KnHdx87BNg0SnlQ5VxghchwJeTSjCwK+zcNeJxIqEC5n6Y7E1 9Jz+975ZzW04rqwZaFg+d2Uj0EB9vcW9lUFIHgPbNjOd7LVovrKlgRTs9LpQQcaHTy5Q XvUQQWjpH/+SfkjjsHPj7YnI7fpNOhC7W6QNMNnSAGZPpSRXVdKDpc+6A3YIUAL5uHg/ 3XATAXI/yG3zuPjWPajK5wOCeZJjZF2QdDMPOEb8EXci33Lf0nEUnrRolCPMWEV6sboZ I4gUg+oeF1U+9KOmnRec186aHHrrfwDiollcr5g6iuVuJnMTqlwt3fQBFyp0QPd421Lt LNqg== Received: by 10.229.135.81 with SMTP id m17mr679846qct.34.1345121621885; Thu, 16 Aug 2012 05:53:41 -0700 (PDT) Received: from lilac-too.home (pool-71-184-120-122.bstnma.fios.verizon.net. [71.184.120.122]) by mx.google.com with ESMTPS id ga2sm6533311qab.17.2012.08.16.05.53.38 (version=SSLv3 cipher=OTHER); Thu, 16 Aug 2012 05:53:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <502CEB6D.6040304@toshiba.co.jp> Date: Thu, 16 Aug 2012 08:53:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <684F11AE-1361-4A75-A70B-8B0226510E09@gmail.com> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <502C6BF0.3030400@toshiba.co.jp> <6F0B4ED8-68F1-44BB-A94B-E5D86E6C7254@lilacglade.org> <502CEB6D.6040304@toshiba.co.jp> To: Yoshihiro Ohba X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 12:53:43 -0000 Hi Yoshi, I thought the point of running PANA over/beside PCP, instead of using a = PCP-specific mechanism, was that the PCP Server could hand the PANA = request to a separate PANA server for processing, just like a PANA Relay = would hand-off a PANA request to a PANA Server. =20 How will that PANA Server (the one that receives the PANA request from = the PCP Server, presumably on the PANA port) know that the request is = coming from a PCP Server and concerns PCP access, and that it isn't a = network access request from a regular PANA PaC or Relay? I think it is = pretty important that we not set-up a situation where a PANA server = could think that it is authorizing network access while it is actually = authorizing PCP requests, don't you? Margaret On Aug 16, 2012, at 8:45 AM, Yoshihiro Ohba wrote: > Hi Margaret, >=20 > In my opinion, PANA should be dedicated to PCP authentication in both > cases where PANA runs over PCP port. >=20 > In other words, we can say that PANA is used for network access > authentication only when PANA operates over PANA port, regardless of > whether the same or different credentials are used for PCP > authentication and network access authentication. >=20 > Yoshihiro Ohba >=20 > (2012/08/16 20:41), Margaret Wasserman wrote: >>=20 >> Hi Yoshi, >>=20 >> On Aug 15, 2012, at 11:41 PM, Yoshihiro Ohba wrote: >>=20 >>> Here is a brief comparison on both PANA-based schemes: >>>=20 >>> Encapsulation/tunneling approach: >>> - Pros: No impact on PANA specification >>> - Cons: Encapsulation overhead >>>=20 >>> Demultiplexing/port-sharing approach: >>> - Pros: No encapsulation overhead >>> - Cons: Impact on PANA specification (an Update of RFC 5191 is = needed >>> on the use of "Reserved" field.) >>=20 >> In both cases, I think there is an open question (raised by my = regarding your draft) of whether we want to modify PANA so that the = server will know that it is performing PCP authentication vs. network = access authentication. I think this could be important, if we want a = single PANA server to be able to serve both purposes in a small network. = It is possible that the credentials/criteria used to authenticate a = node for PCP will be different than for network access, isn't it? >>=20 >> Margaret >>=20 >>=20 >>=20 >=20 From yoshihiro.ohba@toshiba.co.jp Thu Aug 16 06:41:09 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5442121F85E3 for ; Thu, 16 Aug 2012 06:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.829 X-Spam-Level: X-Spam-Status: No, score=-6.829 tagged_above=-999 required=5 tests=[AWL=1.260, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n75vihzCxY8m for ; Thu, 16 Aug 2012 06:41:08 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 8504021F85E0 for ; Thu, 16 Aug 2012 06:41:08 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q7GDf4B3018688; Thu, 16 Aug 2012 22:41:05 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q7GDf4pe020915; Thu, 16 Aug 2012 22:41:04 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id YAA20914; Thu, 16 Aug 2012 22:41:04 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q7GDf4t1014208; Thu, 16 Aug 2012 22:41:04 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q7GDf40V016696; Thu, 16 Aug 2012 22:41:04 +0900 (JST) Received: from [133.199.16.135] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0M8U0098VOOFKIH0@mail.po.toshiba.co.jp>; Thu, 16 Aug 2012 22:41:04 +0900 (JST) Date: Thu, 16 Aug 2012 22:41:04 +0900 From: Yoshihiro Ohba In-reply-to: <684F11AE-1361-4A75-A70B-8B0226510E09@gmail.com> To: Margaret Wasserman Message-id: <502CF870.1020608@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <502C6BF0.3030400@toshiba.co.jp> <6F0B4ED8-68F1-44BB-A94B-E5D86E6C7254@lilacglade.org> <502CEB6D.6040304@toshiba.co.jp> <684F11AE-1361-4A75-A70B-8B0226510E09@gmail.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 13:41:09 -0000 Hi Margaret, I understand your point. I think the challenging case is that the same node is acting as PANA relay for both network access authentication and PCP authentication where the both types of authentication goes to the same PAA. In this case, probably PANA needs to be extended to carry additional information (a new flag or AVP) for distinguishing the two types of authentication. Once the additional information is defined, then the information may also be used for channel binding purpose. Yoshihiro Ohba (2012/08/16 21:53), Margaret Wasserman wrote: > > Hi Yoshi, > > I thought the point of running PANA over/beside PCP, instead of using a PCP-specific mechanism, was that the PCP Server could hand the PANA request to a separate PANA server for processing, just like a PANA Relay would hand-off a PANA request to a PANA Server. > > How will that PANA Server (the one that receives the PANA request from the PCP Server, presumably on the PANA port) know that the request is coming from a PCP Server and concerns PCP access, and that it isn't a network access request from a regular PANA PaC or Relay? I think it is pretty important that we not set-up a situation where a PANA server could think that it is authorizing network access while it is actually authorizing PCP requests, don't you? > > Margaret > > > On Aug 16, 2012, at 8:45 AM, Yoshihiro Ohba wrote: > >> Hi Margaret, >> >> In my opinion, PANA should be dedicated to PCP authentication in both >> cases where PANA runs over PCP port. >> >> In other words, we can say that PANA is used for network access >> authentication only when PANA operates over PANA port, regardless of >> whether the same or different credentials are used for PCP >> authentication and network access authentication. >> >> Yoshihiro Ohba >> >> (2012/08/16 20:41), Margaret Wasserman wrote: >>> >>> Hi Yoshi, >>> >>> On Aug 15, 2012, at 11:41 PM, Yoshihiro Ohba wrote: >>> >>>> Here is a brief comparison on both PANA-based schemes: >>>> >>>> Encapsulation/tunneling approach: >>>> - Pros: No impact on PANA specification >>>> - Cons: Encapsulation overhead >>>> >>>> Demultiplexing/port-sharing approach: >>>> - Pros: No encapsulation overhead >>>> - Cons: Impact on PANA specification (an Update of RFC 5191 is needed >>>> on the use of "Reserved" field.) >>> >>> In both cases, I think there is an open question (raised by my regarding your draft) of whether we want to modify PANA so that the server will know that it is performing PCP authentication vs. network access authentication. I think this could be important, if we want a single PANA server to be able to serve both purposes in a small network. It is possible that the credentials/criteria used to authenticate a node for PCP will be different than for network access, isn't it? >>> >>> Margaret >>> >>> >>> >> > > From phdgang@gmail.com Thu Aug 16 20:12:11 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4A821F84B5 for ; Thu, 16 Aug 2012 20:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.191 X-Spam-Level: X-Spam-Status: No, score=-3.191 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mz95taj2laKb for ; Thu, 16 Aug 2012 20:12:10 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED7121F84B2 for ; Thu, 16 Aug 2012 20:12:10 -0700 (PDT) Received: by ggnh4 with SMTP id h4so3983025ggn.31 for ; Thu, 16 Aug 2012 20:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=muXtLoHVGmNKA01kYmM1En/Qlc6T0KLJaCI3zYWwEG8=; b=q8GNAXCrtWq0+eMVB2rbjC3NLuEqQu+nLrY7SDQuuFv4yrqFoioBQ2SX/u1QAecCPn 4Dg66k3IHS3e1mxDG8z/LHP/xPi4PHBrvuIyIZdxQ+cM+NUPQAmIlX0QdIniEW/vFCev sFzmrCbxSQFZ+0vZcKCu4gpvb1RJwYl7xpFdrGF5yJQr1pfLWdDWOwJOIiC1csvtnyCN hps0oC4mumvuBNyODMo7/jv0impYQ9WhsyHwdD6ZziIK4xGRWO58TRKEfO4dsd1p6OrG EjNFTHXsw3BKmeTLVv5mn4pRV2lCZ/rrhvpkE6LN7yNeJaF8kyjwrrUuIs195p+DNbZS D+1A== MIME-Version: 1.0 Received: by 10.50.161.131 with SMTP id xs3mr337701igb.46.1345173129361; Thu, 16 Aug 2012 20:12:09 -0700 (PDT) Received: by 10.42.57.204 with HTTP; Thu, 16 Aug 2012 20:12:08 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A14782FFE@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A14782FFE@xmb-rcd-x10.cisco.com> Date: Fri, 17 Aug 2012 11:12:08 +0800 Message-ID: From: GangChen To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "pcp@ietf.org" Subject: Re: [pcp] Issue Analysis of PCP in Mobile Network was (Fwd: New Version Notification for draft-chen-pcp-mobile-deployment-01.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 03:12:11 -0000 Thanks for the review. Please see my reply inline. 2012/8/14, Tirumaleswar Reddy (tireddy) : > Hi - > > 1. Section 2.1 > Can you please clarify what kind of applications on Mobile devices would > require port range on Firewall ? E.g. RTP/RTCP based applications. A pair of port is required to be reserved. > MAP/PEER cannot be used to request Firewall to open a range of ports (other > than "all ports") Acknowledged > I am not sure what you mean by resource saving on the "Firewall node" - > clarify If PCP is absent, firewall would have to handle unprompted keepalive messages. The resource saving is achieved by reducing such messages > 2. Section 5 > There is similar problem in PMIPv6 with multiple APN. But with IPv6, MN > will be assigned prefixes from multiple APN (using SLAAC). Firewall may be > located only in the Internet-APN. In case of IPv4, MAG can act as PCP Server > to the Mobile Node and MAG will have act as PCP Proxy and propagate the PCP > request to PCP Server in appropriate APN. More clarity is required on this > section. So, we would like to say more detailed description in a mobile case? > 2. Section 7 > Thus a PCP server SHOULD take care to throttle unicast ANNOUNCE > messages it sends towards a collection of MN. > > Comment> > Yes, this is a problem. For example RA throttle is dealt using the technique > in http://tools.ietf.org/html/draft-thubert-savi-ra-throttler-01 > For example dedicated RA is unicast to each of the associated devices as > opposed to sent once as a layer 2 broadcast to all devices in a single > shot. > What is the plan to address such problem for ANNOUNCE ? > For e.g. permit ANNOUNCE only on selected trusted ports. Could you detail what you mean by "selected trusted ports"? > 3. Section 9 > > Because the UE has been authenticated to the MGW during context setup, if > the MGW > delegates its trust to the NAT/FW device (PCP server), the NAT/FW > device can trust the PCP requests from those users. > > Comment> > I guess if the Mobile network combines UE authentication with MGW + ingress > filtering (to prevent IP address spoofing, there may not be a need for > explicit PCP authentication). Refer to section 17.3.2 in base PCP spec. Indeed. It's not required if address validation is enforced in the network. We would updated with this point. BRs Gang > --Tiru. > >> -----Original Message----- >> From: GangChen [mailto:phdgang@gmail.com] >> Sent: Monday, July 16, 2012 9:25 PM >> To: pcp@ietf.org >> Subject: [pcp] Issue Analysis of PCP in Mobile Network was (Fwd: New >> Version Notification for draft-chen-pcp-mobile-deployment-01.txt) >> >> Hello all, >> >> We had a discussion of PCP in mobile context at last IETF meeting. >> This work was encouraged to continue the analysis of major issues when >> PCP is adopted in a mobile environment. >> Considering very specific features in mobile network, we made a >> thorough study to current PCP protocol design. >> Several typical issues have been pointed. >> PCP applicability to these issues is further presented in the memo. >> The authors would seek your reviews and comments. >> Hope the work is of value to the community. >> >> Best Regards >> >> Authors of PCP-mobile >> >> ---------- Forwarded message ---------- >> From: internet-drafts@ietf.org >> Date: Mon, 16 Jul 2012 08:17:46 -0700 >> Subject: New Version Notification for draft-chen-pcp-mobile-deployment- >> 01.txt >> To: phdgang@gmail.com >> Cc: caozhen@chinamobile.com, mohamed.boucadair@orange.com, >> ales.vizdal@t-mobile.cz, laurent.thiebaut@alcatel-lucent.com >> >> >> A new version of I-D, draft-chen-pcp-mobile-deployment-01.txt >> has been successfully submitted by Gang Chen and posted to the >> IETF repository. >> >> Filename: draft-chen-pcp-mobile-deployment >> Revision: 01 >> Title: Analysis of Port Control Protocol in Mobile Network >> Creation date: 2012-07-16 >> WG ID: Individual Submission >> Number of pages: 14 >> URL: >> http://www.ietf.org/internet-drafts/draft-chen-pcp-mobile-deployment- >> 01.txt >> Status: >> http://datatracker.ietf.org/doc/draft-chen-pcp-mobile-deployment >> Htmlized: http://tools.ietf.org/html/draft-chen-pcp-mobile- >> deployment-01 >> Diff: >> http://tools.ietf.org/rfcdiff?url2=draft-chen-pcp-mobile-deployment-01 >> >> Abstract: >> This memo provides a motivation description for the Port Control >> Protocol (PCP) deployment in a 3GPP mobile network environment. The >> document focuses on a mobile network specific issues (e.g. cell >> phone >> battery power consumption, keep-alive traffic reduction), PCP >> applicability to these issues is further studied and analysed. >> >> >> >> >> The IETF Secretariat > > From tireddy@cisco.com Thu Aug 16 23:39:48 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4115621F8577 for ; Thu, 16 Aug 2012 23:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.316 X-Spam-Level: X-Spam-Status: No, score=-10.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLJe54sYY7hv for ; Thu, 16 Aug 2012 23:39:47 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id CE65321F856C for ; Thu, 16 Aug 2012 23:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=6151; q=dns/txt; s=iport; t=1345185586; x=1346395186; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=46i1fHlGDg7avvJIYRR3+xZdlDvKUxV9uEyhqPsY2NQ=; b=WutNLNapKzxvO2ESxOUYI8SitayblVIt2XWdJfL/+MezKFB8/Bv2S4QR eFqI14YmApOcafjmL57vBvvYKW+GX/AQ3nxDlc8f7YChcquMgKM5HnorT vL37jAqW/5EbQgJzR0oN/XOixS0HOwOrE+DiG4vPwXWQq52fFEo5++I4K c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGDmLVCtJV2b/2dsb2JhbABFujKBB4IgAQEBAwESASc9AgwEAgEIEQMBAQELFAUEByERFAkIAgQOBQgBCw6HXAMGBguZf5ZaDYlOiiZkBRaGAGADk3yCZ4l4gyCBZoJfgVgj X-IronPort-AV: E=Sophos;i="4.77,783,1336348800"; d="scan'208";a="112525648" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 17 Aug 2012 06:39:39 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7H6ddmA028329 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Aug 2012 06:39:39 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Fri, 17 Aug 2012 01:39:39 -0500 From: "Tirumaleswar Reddy (tireddy)" To: GangChen Thread-Topic: [pcp] Issue Analysis of PCP in Mobile Network was (Fwd: New Version Notification for draft-chen-pcp-mobile-deployment-01.txt) Thread-Index: AQHNY4V3euq9CB4dPEON9BKc/XznjpdYtExggAUkpgD//9zhcA== Date: Fri, 17 Aug 2012 06:39:39 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14788D24@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A14782FFE@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.72.206] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19120.004 x-tm-as-result: No--56.986500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Issue Analysis of PCP in Mobile Network was (Fwd: New Version Notification for draft-chen-pcp-mobile-deployment-01.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 06:39:48 -0000 > -----Original Message----- > From: GangChen [mailto:phdgang@gmail.com] > Sent: Friday, August 17, 2012 8:42 AM > To: Tirumaleswar Reddy (tireddy) > Cc: pcp@ietf.org > Subject: Re: [pcp] Issue Analysis of PCP in Mobile Network was (Fwd: > New Version Notification for draft-chen-pcp-mobile-deployment-01.txt) >=20 > Thanks for the review. > Please see my reply inline. >=20 > 2012/8/14, Tirumaleswar Reddy (tireddy) : > > Hi - > > > > 1. Section 2.1 > > Can you please clarify what kind of applications on Mobile devices > would > > require port range on Firewall ? > E.g. RTP/RTCP based applications. A pair of port is required to be > reserved. >=20 > > MAP/PEER cannot be used to request Firewall to open a range of ports > (other > > than "all ports") >=20 > Acknowledged >=20 > > I am not sure what you mean by resource saving on the "Firewall node" > - > > clarify >=20 > If PCP is absent, firewall would have to handle unprompted keepalive > messages. > The resource saving is achieved by reducing such messages Got it. >=20 > > 2. Section 5 > > There is similar problem in PMIPv6 with multiple APN. But with IPv6, > MN > > will be assigned prefixes from multiple APN (using SLAAC). Firewall > may be > > located only in the Internet-APN. In case of IPv4, MAG can act as PCP > Server > > to the Mobile Node and MAG will have act as PCP Proxy and propagate > the PCP > > request to PCP Server in appropriate APN. More clarity is required > on this > > section. >=20 > So, we would like to say more detailed description in a mobile case? Yes, that would be good to provide detailed description. >=20 >=20 > > 2. Section 7 > > Thus a PCP server SHOULD take care to throttle unicast ANNOUNCE > > messages it sends towards a collection of MN. > > > > Comment> > > Yes, this is a problem. For example RA throttle is dealt using the > technique > > in http://tools.ietf.org/html/draft-thubert-savi-ra-throttler-01 > > For example dedicated RA is unicast to each of the associated devices > as > > opposed to sent once as a layer 2 broadcast to all devices in a > single > > shot. > > What is the plan to address such problem for ANNOUNCE ? > > For e.g. permit ANNOUNCE only on selected trusted ports. >=20 > Could you detail what you mean by "selected trusted ports"? I meant if it's possible to do something like http://tools.ietf.org/html/rf= c6105 in RA Guard and block Multicast PCP restart announcements coming from= certain interfaces. For e.g. treat PCP client facing interfaces or ports a= s untrusted and block Multicast PCP restart announcements coming from these= interfaces.=20 (The other part of the question was would these Mobile Networks typically h= ave HA deployed for NAT/Firewall and ANNOUNCE in that case would rarely hap= pen) --Tiru. >=20 > > 3. Section 9 > > > > Because the UE has been authenticated to the MGW during context > setup, if > > the MGW > > delegates its trust to the NAT/FW device (PCP server), the NAT/FW > > device can trust the PCP requests from those users. > > > > Comment> > > I guess if the Mobile network combines UE authentication with MGW + > ingress > > filtering (to prevent IP address spoofing, there may not be a need > for > > explicit PCP authentication). Refer to section 17.3.2 in base PCP > spec. >=20 > Indeed. It's not required if address validation is enforced in the > network. We would updated with this point. >=20 > BRs >=20 > Gang >=20 > > --Tiru. > > > >> -----Original Message----- > >> From: GangChen [mailto:phdgang@gmail.com] > >> Sent: Monday, July 16, 2012 9:25 PM > >> To: pcp@ietf.org > >> Subject: [pcp] Issue Analysis of PCP in Mobile Network was (Fwd: New > >> Version Notification for draft-chen-pcp-mobile-deployment-01.txt) > >> > >> Hello all, > >> > >> We had a discussion of PCP in mobile context at last IETF meeting. > >> This work was encouraged to continue the analysis of major issues > when > >> PCP is adopted in a mobile environment. > >> Considering very specific features in mobile network, we made a > >> thorough study to current PCP protocol design. > >> Several typical issues have been pointed. > >> PCP applicability to these issues is further presented in the memo. > >> The authors would seek your reviews and comments. > >> Hope the work is of value to the community. > >> > >> Best Regards > >> > >> Authors of PCP-mobile > >> > >> ---------- Forwarded message ---------- > >> From: internet-drafts@ietf.org > >> Date: Mon, 16 Jul 2012 08:17:46 -0700 > >> Subject: New Version Notification for draft-chen-pcp-mobile- > deployment- > >> 01.txt > >> To: phdgang@gmail.com > >> Cc: caozhen@chinamobile.com, mohamed.boucadair@orange.com, > >> ales.vizdal@t-mobile.cz, laurent.thiebaut@alcatel-lucent.com > >> > >> > >> A new version of I-D, draft-chen-pcp-mobile-deployment-01.txt > >> has been successfully submitted by Gang Chen and posted to the > >> IETF repository. > >> > >> Filename: draft-chen-pcp-mobile-deployment > >> Revision: 01 > >> Title: Analysis of Port Control Protocol in Mobile Network > >> Creation date: 2012-07-16 > >> WG ID: Individual Submission > >> Number of pages: 14 > >> URL: > >> http://www.ietf.org/internet-drafts/draft-chen-pcp-mobile- > deployment- > >> 01.txt > >> Status: > >> http://datatracker.ietf.org/doc/draft-chen-pcp-mobile-deployment > >> Htmlized: http://tools.ietf.org/html/draft-chen-pcp-mobile- > >> deployment-01 > >> Diff: > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-chen-pcp-mobile-deployment- > 01 > >> > >> Abstract: > >> This memo provides a motivation description for the Port Control > >> Protocol (PCP) deployment in a 3GPP mobile network environment. > The > >> document focuses on a mobile network specific issues (e.g. cell > >> phone > >> battery power consumption, keep-alive traffic reduction), PCP > >> applicability to these issues is further studied and analysed. > >> > >> > >> > >> > >> The IETF Secretariat > > > > From alper.yegin@yegin.org Fri Aug 17 01:09:26 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0231D21F853E for ; Fri, 17 Aug 2012 01:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-UIi2bKLeAY for ; Fri, 17 Aug 2012 01:09:25 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 3239C21F853A for ; Fri, 17 Aug 2012 01:09:25 -0700 (PDT) Received: from [192.168.2.4] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MWCQ5-1TCsbv1LoH-00Xzpz; Fri, 17 Aug 2012 04:09:23 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_A3E9F3D3-F6AD-4FD8-B446-269EE669320F" From: Alper Yegin In-Reply-To: <2340495D-0811-42DD-B0D3-636499A0D802@lilacglade.org> Date: Fri, 17 Aug 2012 11:09:03 +0300 Message-Id: <17F2DC3F-3DAF-452C-B0FE-3337FDEE4118@yegin.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <2340495D-0811-42DD-B0D3-636499A0D802@lilacglade.org> To: Margaret Wasserman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:mOUKcGyr2qVpvGdq3LlJf/7qtl/IH6jGDvKY8S8+UAN gQutZEfW+7S2yauwYbc/Cwt6PUnaH76mgwIWxIDE+2kTjBnT/q 2E8OS46dxR2q903eqq07ASzRizie0Nso3EjWJhsRfNdlty3qkT jVUzYoFNivscBOF806oJmytcKMHNeh7b0q06AzCdCC2X0Nmn3Z ASi/+scEhW/HiegKpraqLPSZqWpbLSq0PrUujCJZYjIoklQBD1 xtPMdu+HR9IHhbuUr3OHJsdSfrN6mTfp1b5IhqUE/ye71iM92B dvcmLxs4mPoRGHNsNbTCyiUmEL/Ley34F0KwINSfigMcHl7/9u uO4BkIsAvhTuDlrxjp7Hn6kBJ6+z8vpsjmoXkiHRwBAQYP5PU3 Bw3pq93DWhv3w== Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 08:09:26 -0000 --Apple-Mail=_A3E9F3D3-F6AD-4FD8-B446-269EE669320F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 16, 2012, at 2:38 PM, Margaret Wasserman wrote: >=20 >=20 > Hi Dacheng, >=20 > The conclusion from the meeting was that we will document all three = approaches in our document: >=20 Could the chairs please declare what the meeting conclusions and next = steps are. Thanks. Alper > - PCP Specific > - PANA Encapsulated in PCP > - PANA Demultiplexed with PCP on the same port >=20 > Then, we will have an interim PCP conference call to discuss the = trade-offs and hopefully decide between them. >=20 > Margaret >=20 >=20 >=20 > On Aug 15, 2012, at 10:47 PM, Zhangdacheng (Dacheng) wrote: >=20 >> Have we got any conclusions on two approaches? Or we can just = support the two options in the draft for the moment and briefly compare = their pros and cons, can we? >> =20 >> Cheers >> =20 >> Dcheng >> =20 >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of = Margaret Wasserman >> Sent: Friday, August 10, 2012 3:21 AM >> To: Dan Wing >> Cc: pcp@ietf.org >> Subject: Re: [pcp] Comparison of PCP authentication >> =20 >> =20 >> On Aug 9, 2012, at 2:32 PM, Dan Wing wrote: >> =20 >> If I'm updating security policy on a firewall I want to be able to >> audit whether that actually happened. That requires authentication. >>=20 >> You are saying a PCP client would only want to update firewall = policies=20 >> if the PCP server supports authentication, otherwise it would tell = the >> user that it cannot enable the webcam, Internet-connected NAS,=20 >> Internet-connected printer, etc.? >> =20 >> I wont presume to guess what Sam is thinking... >> =20 >> However, I am thinking that there will be some clients that are = configured to perform authentication for every request. For example, = there is no reason for a PCP proxy, running in an environment where = authentication is required to do a THIRD-PARTY request, to perform a = useless round-trip for every THIRD-PARTY request it issues. =20 >> =20 >> Margaret >> =20 >> =20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp --Apple-Mail=_A3E9F3D3-F6AD-4FD8-B446-269EE669320F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


Hi = Dacheng,

The conclusion from the meeting was = that we will document all three approaches in our = document:


Could= the chairs please declare what the meeting conclusions and next steps = are.

Thanks.

Alper
=




- PCP = Specific
- PANA Encapsulated in PCP
- PANA = Demultiplexed with PCP on the same port

Then, = we will have an interim PCP conference call to discuss the trade-offs = and hopefully decide between = them.

Margaret



On Aug 15, 2012, at 10:47 PM, Zhangdacheng (Dacheng) = wrote:

Cheers
Dcheng
 pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org]=  On Behalf Of Margaret = Wasserman
Sent: Friday, August 10, 2012 = 3:21 AM
To: Dan Wing
Cc: pcp@ietf.org
Subject: Re: [pcp] Comparison of PCP = authentication
 
 
On Aug 9, 2012, at 2:32 PM, Dan = Wing wrote:
 
If I'm updating security policy on a firewall I want to = be able to
audit whether that actually happened.  That requires = authentication.

You are saying a PCP client = would only want to update firewall policies 
if the PCP server = supports authentication, otherwise it would tell the
user that it = cannot enable the webcam, Internet-connected NAS, 
Internet-connected = printer, etc.?
 
I wont presume to guess what Sam = is thinking...
 
However, I am thinking that there = will be some clients  that are configured to perform authentication = for every request.  For example, there is no reason for a PCP = proxy, running in an environment where authentication is required to do = a THIRD-PARTY request, to perform a useless round-trip for every = THIRD-PARTY request it issues. =  
 
Margaret
 
 

_____________________________________= __________
pcp mailing list
pcp@ietf.org
https://www.ietf.org/mail= man/listinfo/pcp

= --Apple-Mail=_A3E9F3D3-F6AD-4FD8-B446-269EE669320F-- From alper.yegin@yegin.org Fri Aug 17 01:15:36 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807BF21F844C for ; Fri, 17 Aug 2012 01:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-z6fHPZDrzX for ; Fri, 17 Aug 2012 01:15:35 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 75F8921F84D2 for ; Fri, 17 Aug 2012 01:15:29 -0700 (PDT) Received: from [192.168.2.4] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MAhGN-1SrWDS2SBX-00BXUO; Fri, 17 Aug 2012 04:15:19 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <502CF870.1020608@toshiba.co.jp> Date: Fri, 17 Aug 2012 11:14:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <63E0C6E0-8E5B-4AAA-B0C8-D2E892ECEE18@yegin.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <502C6BF0.3030400@toshiba.co.jp> <6F0B4ED8-68F1-44BB-A94B-E5D86E6C7254@lilacglade.org> <502CEB6D.6040304@toshiba.co.jp> <684F11AE-1361-4A75-A70B-8B0226510E09@gmail.com> <502CF870.1020608@toshib a.co.jp> To: Yoshihiro Ohba X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:Q6d0/9RQ4NveRfdZpLhx8fODtwQYG4Vsc7FdIZHWT4T tyZ7oOj2hXwwaqxBMgMn5PbOqZgj7uWnqYT6g4RG+ktlM1YDJN q2lW6Tr1U1FNvvHwEj4nEXwWy+smLNLRIcJxqpaadkKjNngHJh 1gxkfot4qTCpstSa944PrVleeKvR6rB0WvmPhKnXaYg/Ca4J+v wCjhty8oR35EPQpFq0ugzsGvAowstCU0nUgS7Tk2EgWD0Sbjee 2X8y4BkQgpYNhlTCdqasPaya6NiCm1O0X6WTSgG9be1TZmh23k x9mQ071rl48qDgyWpUn+qzUuacqPTP86UqoR6moUH5yMjm5kl3 ufE4is3YR4E4yLIYXF1Ep1aV7/rQXSFlfp9mw5qwqnZqIqa6HI pjGC8J8Fw7xnQ== Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 08:15:36 -0000 EAP Authenticator is on the PCP server. Hence, PAA (PANA Authentication Agent) and PCP server are on the same = node. Therefore, the PAA can tell whether it's authenticating the PaC for PCP = or for network access by looking at the destination port. That's sufficient. (I don't know why you folks are digressing to another model where EAP = authenticator resides on a different node than the PCP server -- in = which case we need to engage PANA relay (OK, fine) ; and EAPoPCP folks = need to come up with yet another solution to relay the EAP from PCP = server to the EAP authenticator). On Aug 16, 2012, at 4:41 PM, Yoshihiro Ohba wrote: > Hi Margaret, >=20 > I understand your point. >=20 > I think the challenging case is that the same node is acting as PANA > relay for both network access authentication and PCP authentication > where the both types of authentication goes to the same PAA. In this > case, probably PANA needs to be extended to carry additional > information (a new flag or AVP) for distinguishing the two types of > authentication. Once the additional information is defined, then the > information may also be used for channel binding purpose. >=20 > Yoshihiro Ohba >=20 > (2012/08/16 21:53), Margaret Wasserman wrote: >>=20 >> Hi Yoshi, >>=20 >> I thought the point of running PANA over/beside PCP, instead of using = a PCP-specific mechanism, was that the PCP Server could hand the PANA = request to a separate PANA server for processing, just like a PANA Relay = would hand-off a PANA request to a PANA Server. >>=20 >> How will that PANA Server (the one that receives the PANA request = from the PCP Server, presumably on the PANA port) know that the request = is coming from a PCP Server and concerns PCP access, and that it isn't a = network access request from a regular PANA PaC or Relay? I think it is = pretty important that we not set-up a situation where a PANA server = could think that it is authorizing network access while it is actually = authorizing PCP requests, don't you? >>=20 >> Margaret >>=20 >>=20 >> On Aug 16, 2012, at 8:45 AM, Yoshihiro Ohba wrote: >>=20 >>> Hi Margaret, >>>=20 >>> In my opinion, PANA should be dedicated to PCP authentication in = both >>> cases where PANA runs over PCP port. >>>=20 >>> In other words, we can say that PANA is used for network access >>> authentication only when PANA operates over PANA port, regardless of >>> whether the same or different credentials are used for PCP >>> authentication and network access authentication. >>>=20 >>> Yoshihiro Ohba >>>=20 >>> (2012/08/16 20:41), Margaret Wasserman wrote: >>>>=20 >>>> Hi Yoshi, >>>>=20 >>>> On Aug 15, 2012, at 11:41 PM, Yoshihiro Ohba wrote: >>>>=20 >>>>> Here is a brief comparison on both PANA-based schemes: >>>>>=20 >>>>> Encapsulation/tunneling approach: >>>>> - Pros: No impact on PANA specification >>>>> - Cons: Encapsulation overhead >>>>>=20 >>>>> Demultiplexing/port-sharing approach: >>>>> - Pros: No encapsulation overhead >>>>> - Cons: Impact on PANA specification (an Update of RFC 5191 is = needed >>>>> on the use of "Reserved" field.) >>>>=20 >>>> In both cases, I think there is an open question (raised by my = regarding your draft) of whether we want to modify PANA so that the = server will know that it is performing PCP authentication vs. network = access authentication. I think this could be important, if we want a = single PANA server to be able to serve both purposes in a small network. = It is possible that the credentials/criteria used to authenticate a = node for PCP will be different than for network access, isn't it? >>>>=20 >>>> Margaret >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From alper.yegin@yegin.org Fri Aug 17 01:22:56 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3984D21F8535 for ; Fri, 17 Aug 2012 01:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64+PucZPUyBU for ; Fri, 17 Aug 2012 01:22:55 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 5682421F8526 for ; Fri, 17 Aug 2012 01:22:53 -0700 (PDT) Received: from [192.168.2.4] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lkwt3-1TZy183xi9-00bDVU; Fri, 17 Aug 2012 04:22:42 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Fri, 17 Aug 2012 11:22:21 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <502C6BF0.3030400@toshiba.co.jp> <6F0B4ED8-68F1-44BB-A94B-E5D86E6C7254@lilacglade.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:53e8QEYqWydCb0Szi6IJsIi6/RC6NEIBtISohJqGZ7o dKnlVKIzrZJEnKYAe1hjKPYSvfRRbq4EZPl6eypqdF524qwKCa B9nHlzNPaKLg6lGz57CA0JIpfvXPzas6SNkCal37hsRAY87NgF K1NJ9JjBlcENavzgNIZ1kMBMGTw+kYICNrZtKnPf1/y9Q2vUkd prEjIQAYA8C1mGzZFvr/gCL+FyC4ivWOb/Pys59FskVPuDQkpg fa2ZunEruDNevielV3UtTv5FN1SibwG9eiJQeRiSOcX3YPlpCw 9pj4agvHJHpBk5vUmbQ+3ECz9M50TBup3FmH4VOqINhTevjrmt VTM8cv9jJyP4ygDaoTWkCBHWWs4zD2OntopsQG+YvS6TbIMGZd FTfG1LA0RomQw== Cc: pcp@ietf.org Subject: [pcp] channel binding (was Re: Comparison of PCP authentication) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 08:22:56 -0000 (spinning off a new thread for easier tracking) What value are you thinking of using for i1 and i2? IP address of the = PCP server? If so, you can do that in any of those solutions.=20 Is there a problem? Alper On Aug 16, 2012, at 3:46 PM, Sam Hartman wrote: > I have a question. > As background reading I recommend taking a look at RFC 6677 section = 5.1. >=20 >=20 > If we want to use EAP channel binding to bind an authentication to a > specific PCP server, how will we do that with PANA? >=20 > For all three approaches we need to define i1 or what attributes the = client > sends in the EAP channel binding to give the identity of the PCP > server. We could for example use the IP address of the PCP server in = the > nas-ip-address (or v6 address) AVP. >=20 > For the PCP specific approach the rest is easy. The PCP server knows = it > is a PCP server, and includes those attributes in the AAA message > so that the EAP server has i2. >=20 > How does the PANA server find out i2? >=20 > RFC 6677 strongly recommends that an eap-lower-layer attribute be > included. There's a value defined for PANA. However, that wouldn't > really be a good choice here because it would not allow an EAP server = to > distinguish PCP authentications from uses of PANA for network access. > how does the PANA server know which eap-lower-layer to include? >=20 > --Sam > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From alper.yegin@yegin.org Fri Aug 17 01:36:48 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1702B21F8564 for ; Fri, 17 Aug 2012 01:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.089 X-Spam-Level: X-Spam-Status: No, score=-101.089 tagged_above=-999 required=5 tests=[AWL=-1.390, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, MANGLED_TOOL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChFAQ7+zd-T3 for ; Fri, 17 Aug 2012 01:36:47 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 5606621F855B for ; Fri, 17 Aug 2012 01:36:47 -0700 (PDT) Received: from [192.168.2.4] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0Lbdxb-1TQOOX472p-00lApF; Fri, 17 Aug 2012 04:36:45 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1278) From: Alper Yegin In-Reply-To: <502C6BF0.3030400@toshiba.co.jp> Date: Fri, 17 Aug 2012 11:36:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <502C6BF0.3030400@toshiba.co.jp> To: pcp@ietf.org X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:8Voueko1JL4aAv+y3QIGQE45LLZHJyZAwEH7hWiuwdv jjjqLuiY7Tpg1FpfQSoQHIPrR2MmXcqFiXAgU6ws/kEjM0U4Sn 5huOd2Zd+oplBhzLT7cF4igo0d2MJA2yaoVrOl46uidGveThV5 WzaOsY1YSeCJgd3F7wLxdmXw8dOF6YBbhlP3CxMX94W0OHhw/H iRyS6ZRjD0h82GV0xHIRvjrs5TnwhpQhnHp7Uh9bfDLMmwD/Qv Vl7FOS6xyinIeQdetX8m8SzstnqVqhKSJ7KaXaIXa5wJnlWNk/ 82CLOXtB8AO/xqKje6a157KOjd6XaUKWQUShtgnGXulUJ3hQIL U6RWI41EI7zAQGE2lfN561R3Am20HiUjOYPbPfteD9XNHjVnJC lUs0mIPuXqpgg== Subject: [pcp] PANA and PCP port sharing (was Re: Comparison of PCP authentication) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 08:36:48 -0000 >=20 > Encapsulation/tunneling approach: > - Pros: No impact on PANA specification > - Cons: Encapsulation overhead >=20 > Demultiplexing/port-sharing approach: > - Pros: No encapsulation overhead > - Cons: Impact on PANA specification (an Update of RFC 5191 is needed > on the use of "Reserved" field.) >=20 I prefer the latter approach as this seems to be most straightforward. Yoshi and I exchanged some emails to figure out what needs to be done, = and here's the finding: We have 16 Reserved bits in PANA header. Bits 5-6-7 will be used for demux'ing between PANA and PCP when the two = are run over the PCP port. PCP version 2 sets the values to 0-1-0 and future versions would be = 0-1-1, 1-0-0, =85 1-1-1 -- should be enough. PCP-spec would state the following: - When PANA is executed over the PCP port, sender shall set the Bits = 5-6-7 to 0-0-0 and the receiver shall ignore them. (Other reserved bits and Bits 5-6-7 when used over ports other than PCP = port are still governed by RC 5191). RFC 5191 will include an "Updated by RFC(PCP-spec)". =20 Alper =20 > Hope this helps, > Yoshihiro Ohba >=20 > (2012/08/16 11:47), Zhangdacheng (Dacheng) wrote: >> Have we got any conclusions on two approaches? Or we can just = support=20 >> the two options in the draft for the moment and briefly compare their=20= >> pros and cons, can we? >>=20 >> Cheers >>=20 >> Dcheng >>=20 >> *From:*pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] *On Behalf=20= >> Of *Margaret Wasserman >> *Sent:* Friday, August 10, 2012 3:21 AM >> *To:* Dan Wing >> *Cc:* pcp@ietf.org >> *Subject:* Re: [pcp] Comparison of PCP authentication >>=20 >> On Aug 9, 2012, at 2:32 PM, Dan Wing wrote: >>=20 >> If I'm updating security policy on a firewall I want to be = able to >>=20 >> audit whether that actually happened. That requires >> authentication. >>=20 >>=20 >> You are saying a PCP client would only want to update firewall >> policies >> if the PCP server supports authentication, otherwise it would tell = the >> user that it cannot enable the webcam, Internet-connected NAS, >> Internet-connected printer, etc.? >>=20 >> I wont presume to guess what Sam is thinking... >>=20 >> However, I am thinking that there will be some clients that are=20 >> configured to perform authentication for every request. For example,=20= >> there is no reason for a PCP proxy, running in an environment where=20= >> authentication is required to do a THIRD-PARTY request, to perform a=20= >> useless round-trip for every THIRD-PARTY request it issues. >>=20 >> Margaret >>=20 >>=20 >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >>=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From internet-drafts@ietf.org Fri Aug 17 02:23:47 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC1321F8539; Fri, 17 Aug 2012 02:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEdhqbSCEC1U; Fri, 17 Aug 2012 02:23:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CFC21F852C; Fri, 17 Aug 2012 02:23:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120817092347.27948.43556.idtracker@ietfa.amsl.com> Date: Fri, 17 Aug 2012 02:23:47 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-proxy-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 09:23:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Port Control Protocol Working Group of th= e IETF. Title : Port Control Protocol (PCP) Proxy Function Author(s) : Mohamed Boucadair Internet Systems Consortium Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-proxy-01.txt Pages : 11 Date : 2012-08-17 Abstract: This document specifies a new PCP functional element denoted as PCP Proxy. The PCP Proxy relays PCP requests received from PCP Clients to upstream PCP Server(s). This function is mandatory when PCP Clients can not be configured with the address of the PCP Server located more than one hop. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-proxy There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-proxy-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-proxy-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Fri Aug 17 02:32:59 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B752C21F8532 for ; Fri, 17 Aug 2012 02:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMA-CVaThOy2 for ; Fri, 17 Aug 2012 02:32:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B36D421F8459 for ; Fri, 17 Aug 2012 02:32:55 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 51A233B4621 for ; Fri, 17 Aug 2012 11:32:54 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 3911B35C045 for ; Fri, 17 Aug 2012 11:32:54 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 17 Aug 2012 11:32:35 +0200 From: To: "pcp@ietf.org" Date: Fri, 17 Aug 2012 11:32:34 +0200 Thread-Topic: draft-ietf-pcp-proxy-01 Thread-Index: Ac18Wf38+SHs+qaOSKKGin77Rqi26QAACRFg Message-ID: <94C682931C08B048B7A8645303FDC9F36E512B43CD@PUEXCB1B.nanterre.francetelecom.fr> References: <20120817092347.27948.43556.idtracker@ietfa.amsl.com> In-Reply-To: <20120817092347.27948.43556.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.15.135715 Subject: [pcp] draft-ietf-pcp-proxy-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 09:32:59 -0000 Dear all, A new version is now available online: http://tools.ietf.org/html/draft-iet= f-pcp-proxy-01 The main changes in -01 are as follows: * The reference architecture is updated: the PCP proxy is not restricted to= the CP router deployment case. * Add a new section to specify the behaviour when the PCP Proxy is not co-l= ocated with a NAT function * Add a new section for mappings repair * More discussion for the multiple PCP Servers scenario * Text is cleanup A detailed diff is available here: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-proxy-01 Please review this new version and provide input. =20 Cheers, Med= From hartmans@painless-security.com Fri Aug 17 06:04:46 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98DD821F8584 for ; Fri, 17 Aug 2012 06:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.204 X-Spam-Level: **** X-Spam-Status: No, score=4.204 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNmCzoBELhYa for ; Fri, 17 Aug 2012 06:04:46 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id F2D9D21F8575 for ; Fri, 17 Aug 2012 06:04:45 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E0355209C0; Fri, 17 Aug 2012 09:04:42 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CDE4A4350; Fri, 17 Aug 2012 09:04:33 -0400 (EDT) From: Sam Hartman To: References: <20120817092347.27948.43556.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36E512B43CD@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 17 Aug 2012 09:04:33 -0400 In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E512B43CD@PUEXCB1B.nanterre.francetelecom.fr> (mohamed boucadair's message of "Fri, 17 Aug 2012 11:32:34 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "pcp@ietf.org" Subject: Re: [pcp] draft-ietf-pcp-proxy-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 13:04:46 -0000 I was not aware of the proxy draft. We're going to have to carefully consider the interactions between the proxy and the authentication mechanism and the PCP base security models. --Sam From hartmans@painless-security.com Fri Aug 17 06:16:03 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CC921F859B for ; Fri, 17 Aug 2012 06:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.216 X-Spam-Level: **** X-Spam-Status: No, score=4.216 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TH788Bg8Ims7 for ; Fri, 17 Aug 2012 06:16:03 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id E377A21F8517 for ; Fri, 17 Aug 2012 06:16:02 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E3131209D1; Fri, 17 Aug 2012 09:07:56 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EA6BE4350; Fri, 17 Aug 2012 09:07:47 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <502C6BF0.3030400@toshiba.co.jp> <6F0B4ED8-68F1-44BB-A94B-E5D86E6C7254@lilacglade.org> <502CEB6D.6040304@toshiba.co.jp> <684F11AE-1361-4A75-A70B-8B0226510E09@gmail.com> <63E0C6E0-8E5B-4AAA-B0C8-D2E892ECEE18@yegin.org> Date: Fri, 17 Aug 2012 09:07:47 -0400 In-Reply-To: <63E0C6E0-8E5B-4AAA-B0C8-D2E892ECEE18@yegin.org> (Alper Yegin's message of "Fri, 17 Aug 2012 11:14:59 +0300") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 13:16:03 -0000 Alper> EAP Authenticator is on the PCP server. Hence, PAA (PANA Alper> Authentication Agent) and PCP server are on the same node. Alper> Therefore, the PAA can tell whether it's authenticating the Alper> PaC for PCP or for network access by looking at the Alper> destination port. That's sufficient. So you are happy to decide PCP authentication doesn't need a PANA relay? If so, I propose we explicitly decide that. It makes my channel binding question easier. From hartmans@painless-security.com Fri Aug 17 06:16:03 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0D721F8517 for ; Fri, 17 Aug 2012 06:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.225 X-Spam-Level: **** X-Spam-Status: No, score=4.225 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQ5FWNBet0uf for ; Fri, 17 Aug 2012 06:16:03 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 012E321F854F for ; Fri, 17 Aug 2012 06:16:03 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id ABB06209A4; Fri, 17 Aug 2012 09:06:37 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 989964350; Fri, 17 Aug 2012 09:06:28 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <502C6BF0.3030400@toshiba.co.jp> <6F0B4ED8-68F1-44BB-A94B-E5D86E6C7254@lilacglade.org> Date: Fri, 17 Aug 2012 09:06:28 -0400 In-Reply-To: (Alper Yegin's message of "Fri, 17 Aug 2012 11:22:21 +0300") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] channel binding X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 13:16:03 -0000 >>>>> "Alper" == Alper Yegin writes: Alper> (spinning off a new thread for easier tracking) Alper> What value are you thinking of using for i1 and i2? IP Alper> address of the PCP server? If so, you can do that in any of Alper> those solutions. Is there a problem? I'm not entirely sure what we need for i1 and i2. I think it definitely needs to include: * an indication that it is PCP * IP address. Possibly this is easy. Can you give a clear algorithm for determining what ip address to use in i2? --Sam From dxhbupt@gmail.com Fri Aug 17 06:50:11 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5788521F8467 for ; Fri, 17 Aug 2012 06:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.065 X-Spam-Level: X-Spam-Status: No, score=-3.065 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clBiG-aA8XEu for ; Fri, 17 Aug 2012 06:50:10 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 24A6121F844D for ; Fri, 17 Aug 2012 06:50:09 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so2218815lbb.31 for ; Fri, 17 Aug 2012 06:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=udIaR0TV8SO/WJVs3CHwys99W5nGsi1rIDqDTMkrk4o=; b=F67tpst8yQGcJsBcQ0PsXQZ8bopWd5QuAp/+fONIxHJ2/jhKt/S3+9GY9N5AK/i/Hn 0guOSId6kR+SWmak4nE2QNegwtd4uDrLJjykFWFxpTe7Jy2HQyEZoUvn03n03Jequ/5q JzGLaen5KxgkWUktNo5nDKLITg11a5CgFDROOBpe5/XcLIcT/8hy2JBxswdCOvlPUwcv 8gu4znZwPrpCJp0bBuBOc3AQyKo0SiYa/cj65eMSR6RdljhcocK7O3ObnOO3gh02Yxaf TjlnYH+l4QJEt5UzTCgaHBnJc4DzBb+46OojoGX1TLwFUfv0SjUiNiILuisbAl5zxbxq s2Tg== MIME-Version: 1.0 Received: by 10.112.11.38 with SMTP id n6mr2247183lbb.82.1345211408984; Fri, 17 Aug 2012 06:50:08 -0700 (PDT) Received: by 10.112.43.196 with HTTP; Fri, 17 Aug 2012 06:50:08 -0700 (PDT) In-Reply-To: References: <94C682931C08B048B7A8645303FDC9F36E4FC2DA35@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 17 Aug 2012 15:50:08 +0200 Message-ID: From: Xiaohong Deng To: draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org, pcp@ietf.org, "" Content-Type: multipart/alternative; boundary=e0cb4efe326c2e2ca904c7767056 Subject: Re: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 13:50:11 -0000 --e0cb4efe326c2e2ca904c7767056 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Med, Thanks for your efficient feedback. Please see inline. Now focus only on unsolved ones. On Thu, Aug 16, 2012 at 10:24 AM, wrote: > ** > > PortMappingEnabled: > PCP does not support deactivating the dynamic NAT mapping since > the initial goal of PCP is to ease the traversal of Carrier Grade > NAT. Supporting such per-subscriber function may overload the > Carrier Grade NAT. > + What if the customer wants to deactivate a static NAT mappings on CGN? > it is not stated clearly that IWF should support it or not. My reading he= re > is that for the same reason: not to overload the carrier Grade NAT, it > should not support deactivate static mappings either. IMO,it=92s worth to > state clearer that it applys to both static and dynamic mappings, if that > is what text here means. > [Med] IGD spec says "PortMappingEnabled: This variable allows security > conscious users to disable and enable dynamic NAT port mappings on the IG= D.". PCP > does not provide such feature. > > > Je sais. That's why I asked, and please see below . > > > > On reading the value is 1, writing a value different from 1 is not > supported. > + what if on reading the value is 0, which means deactivating the mapping= ? > [Med] see above. Only "1" is supported. > > Here, I elaborate the question again. Quotation from UPnP-gw-WANIPConnection-v2-Service spcification: "Arguments for AddPortMapping() and AddAnyPortMapping() : *Argument Direction relatedStateVariable* ... NewEnabled IN PortMappingEnabled ..." My concern was and is: with the current text, it doesn't look clear to me, how IGD should react when recieve a PortMappingEnabled valule of '0' from these two actions, which means that users want to disable the mapping. "Arguments for GetGenericPortMappingEntry() GetGenericPortMappingEntry() *Argument Direction relatedStateVariable* ... NewEnabled OUT PortMappingEnabled ..." Don't see any problems for IGD with actions (Get*) having this parameter for OUT direction. [Med] Are you sure 718 error code is allowed for > GetSpecificPortMappingEntry? > > Good point. According to specification, no. p.s. But I think anyway it would be interesting to do a test to see what will happen in that case. Come back to you soon later with the test results= . Cheers, Xiaohong --e0cb4efe326c2e2ca904c7767056 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Med,

Thanks for your efficient feedbac= k.

Please see inline. Now focus only on unsolved ones.

On Thu, Aug 16, 2012 at 10:24 AM, <m= ohamed.boucadair@orange.com> wrote:
=A0=A0=20 PortMappingEnabled:
=A0=A0=A0=A0=A0 PCP does not support=20 deactivating the dynamic NAT mapping since
=A0=A0=A0=A0=A0=20 the initial goal of PCP is to ease the traversal of Carrier=20 Grade
=A0=A0=A0=A0=A0 NAT.=A0 Supporting such=20 per-subscriber function may overload the
=A0=A0=A0=A0=A0=20 Carrier Grade NAT.
+ What if the customer wants to deactivate a static= NAT=20 mappings on CGN? it is not stated clearly that IWF should support it or n= ot.=20 My reading here is that for the same reason: not to overload the carrier = Grade=20 NAT, it should not support deactivate static mappings either. IMO,it=92s = worth=20 to state clearer that it applys to both static and dynamic mappings, if t= hat=20 is what text here means.
[Med]=A0IGD spec says "PortMappingEnabled: This= variable allows security conscious users to disable and enable=20 dynamic NAT port mappings on the IGD.".=A0PCP does not provid= e such=20 feature.=A0

=
Je sais. That's why I asked, and please see below .



=A0=A0=A0=A0=A0 On=20 reading the value is 1, writing a value different from 1 is=20 not
=A0=A0=A0=A0=A0 supported.
+ what if on reading the=20 value is 0, which means deactivating the mapping?
[Med]=A0see above. Only "1" = is supported.=20 =A0
Here, I= elaborate the question again.

Quotation from UPnP-gw-WANIPConnectio= n-v2-Service spcification:

"Arguments for AddPortMapping() and = AddAnyPortMapping() :

*Argument=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Direction=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 relatedStateVariable*
...=
NewEnabled=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IN=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PortMappingEna= bled
..."

My concern was and is: with the current text, it = doesn't look clear to me, how IGD should react when recieve a PortMappi= ngEnabled valule of '0' from these two actions, which means that us= ers want to disable the mapping.


"Arguments for GetGenericPortMappingEntry() GetGenericPortMappingE= ntry()
*Argument=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Direction=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 relatedStateVariable*<= br>...
=A0NewEnabled=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 OUT=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 PortMappingEnabl= ed
..."

Don't see any problems for IGD with actions=A0 (Get*) = having this parameter for OUT direction.



[Med] Are you sure 718=A0error code is allowed for=20 GetSpecificPortMappingEntry?=A0
Good point. According to specification, no.
p.s. Bu= t I think anyway it would be interesting to do a test to see what will happ= en in that case. Come back to you soon later with the test results.

Cheers,
Xiaohong


--e0cb4efe326c2e2ca904c7767056-- From mohamed.boucadair@orange.com Fri Aug 17 07:15:27 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E6521F8454 for ; Fri, 17 Aug 2012 07:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.338 X-Spam-Level: X-Spam-Status: No, score=-1.338 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, SARE_SUB_RAND_LETTRS4=0.799, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8sqe5uvryyl for ; Fri, 17 Aug 2012 07:15:26 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 289CC21F842E for ; Fri, 17 Aug 2012 07:15:26 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 48CA626435D; Fri, 17 Aug 2012 16:15:25 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 24FA8238056; Fri, 17 Aug 2012 16:15:25 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Fri, 17 Aug 2012 16:15:06 +0200 From: To: Xiaohong Deng , "draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org" , "pcp@ietf.org" Date: Fri, 17 Aug 2012 16:15:06 +0200 Thread-Topic: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking Thread-Index: Ac18fy0uAImkGSXCRF6fEcmSX5jfQgAAzGEg Message-ID: <94C682931C08B048B7A8645303FDC9F36E512B4463@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E4FC2DA35@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E512B4463PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.17.104219 Subject: Re: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 14:15:27 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E512B4463PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Xiaohong, The current text says only "1" is allowed: i.e., the iwf is supposed to sen= d back an error if not set to 0. If you have a better wording, this is welcome. Cheers, Med ________________________________ De : Xiaohong Deng [mailto:dxhbupt@gmail.com] Envoy=E9 : vendredi 17 ao=FBt 2012 15:50 =C0 : draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org; pcp@ietf.org; BO= UCADAIR Mohamed OLNC/NAD/TIP Objet : Re: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking Hi Med, Thanks for your efficient feedback. Please see inline. Now focus only on unsolved ones. On Thu, Aug 16, 2012 at 10:24 AM, > wrote: PortMappingEnabled: PCP does not support deactivating the dynamic NAT mapping since the initial goal of PCP is to ease the traversal of Carrier Grade NAT. Supporting such per-subscriber function may overload the Carrier Grade NAT. + What if the customer wants to deactivate a static NAT mappings on CGN? it= is not stated clearly that IWF should support it or not. My reading here i= s that for the same reason: not to overload the carrier Grade NAT, it shoul= d not support deactivate static mappings either. IMO,it's worth to state cl= earer that it applys to both static and dynamic mappings, if that is what t= ext here means. [Med] IGD spec says "PortMappingEnabled: This variable allows security cons= cious users to disable and enable dynamic NAT port mappings on the IGD.". P= CP does not provide such feature. Je sais. That's why I asked, and please see below . On reading the value is 1, writing a value different from 1 is not supported. + what if on reading the value is 0, which means deactivating the mapping? [Med] see above. Only "1" is supported. Here, I elaborate the question again. Quotation from UPnP-gw-WANIPConnection-v2-Service spcification: "Arguments for AddPortMapping() and AddAnyPortMapping() : *Argument Direction relatedStateVariable* ... NewEnabled IN PortMappingEnabled ..." My concern was and is: with the current text, it doesn't look clear to me, = how IGD should react when recieve a PortMappingEnabled valule of '0' from t= hese two actions, which means that users want to disable the mapping. "Arguments for GetGenericPortMappingEntry() GetGenericPortMappingEntry() *Argument Direction relatedStateVariable* ... NewEnabled OUT PortMappingEnabled ..." Don't see any problems for IGD with actions (Get*) having this parameter f= or OUT direction. [Med] Are you sure 718 error code is allowed for GetSpecificPortMappingEntr= y? Good point. According to specification, no. p.s. But I think anyway it would be interesting to do a test to see what wi= ll happen in that case. Come back to you soon later with the test results. Cheers, Xiaohong --_000_94C682931C08B048B7A8645303FDC9F36E512B4463PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Xiaohong,
 
The current text says only "1" is allowed: i.= e., the=20 iwf is supposed to send back an error if not set to 0.
 
If you have a better wording, this is=20 welcome.
 
Cheers,
Med

De : Xiaohong Deng=20 [mailto:dxhbupt@gmail.com]
Envoy=E9 : vendredi 17 ao=FBt = 2012=20 15:50
=C0 : draft-ietf-pcp-upnp-igd-interworking@tools.iet= f.org;=20 pcp@ietf.org; BOUCADAIR Mohamed OLNC/NAD/TIP
Objet : Re: [= pcp]=20 Review of draft-ietf-pcp-upnp-igd-interworking

Hi Med,

Thanks for your efficient=20 feedback.

Please see inline. Now focus only on unsolved ones.
<= BR>
On Thu, Aug 16, 2012 at 10:24 AM, <mohamed.boucadair@orange.com> wrote:
   PortMappingEnabled:
    &nbs= p;=20 PCP does not support deactivating the dynamic NAT mapping=20 since
      the initial goal of PCP is to= ease=20 the traversal of Carrier Grade
     =20 NAT.  Supporting such per-subscriber function may overload=20 the
      Carrier Grade NAT.
+ What if= the=20 customer wants to deactivate a static NAT mappings on CGN? it is not= =20 stated clearly that IWF should support it or not. My reading here is = that=20 for the same reason: not to overload the carrier Grade NAT, it should= not=20 support deactivate static mappings either. IMO,it=92s worth to state = clearer=20 that it applys to both static and dynamic mappings, if that is what t= ext=20 here means.
[Med] IGD = spec says=20 "PortMappingEnabled: This variable allows security co= nscious=20 users to disable and enable dynamic NAT port mappings on the=20 IGD.". PCP does not provide such=20 feature. 

Je sais. That's why I asked, and please see below .



      On reading the value = is 1,=20 writing a value different from 1 is not
    &n= bsp;=20 supported.
+ what if on reading the value is 0, which means=20 deactivating the mapping?
[Med] see above. Only "1" is supported.=20  
Here, I elaborate the question again.

Quotation from=20 UPnP-gw-WANIPConnection-v2-Service spcification:

"Arguments for=20 AddPortMapping() and AddAnyPortMapping()=20 :

*Argument         &= nbsp;           &nbs= p;=20 Direction          =20 relatedStateVariable*
...
NewEnabled     &= nbsp;           &nbs= p;=20 IN            = ;         =20 PortMappingEnabled
..."

My concern was and is: with the current= =20 text, it doesn't look clear to me, how IGD should react when recieve a=20 PortMappingEnabled valule of '0' from these two actions, which means that= =20 users want to disable the mapping.


"Arguments for=20 GetGenericPortMappingEntry()=20 GetGenericPortMappingEntry()
*Argument     &n= bsp;            = ;    =20 Direction          =20 relatedStateVariable*
...
 NewEnabled    &= nbsp;           &nbs= p; =20 OUT           &nbs= p;     =20 PortMappingEnabled
..."

Don't see any problems for IGD with=20 actions  (Get*) having this parameter for OUT=20 direction.



[Med] Are you s= ure=20 718 error code is allowed for=20 GetSpecificPortMappingEntry? 
Good point. According to specification, no.
p.s. But I think anyw= ay it=20 would be interesting to do a test to see what will happen in that case. C= ome=20 back to you soon later with the test=20 results.

Cheers,
Xiaohong


--_000_94C682931C08B048B7A8645303FDC9F36E512B4463PUEXCB1Bnante_-- From yoshihiro.ohba@toshiba.co.jp Fri Aug 17 07:53:42 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F6911E80D5 for ; Fri, 17 Aug 2012 07:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.039 X-Spam-Level: X-Spam-Status: No, score=-5.039 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miyUYoyQZqmp for ; Fri, 17 Aug 2012 07:53:40 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id DA4D911E80DE for ; Fri, 17 Aug 2012 07:53:39 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q7HErPbs010092; Fri, 17 Aug 2012 23:53:25 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q7HErPZr007597; Fri, 17 Aug 2012 23:53:25 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id ZAA07596; Fri, 17 Aug 2012 23:53:25 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q7HErP9E010305; Fri, 17 Aug 2012 23:53:25 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q7HErP7M000361; Fri, 17 Aug 2012 23:53:25 +0900 (JST) Received: from [133.199.16.183] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0M8W00EEQMOZ7TL0@mail.po.toshiba.co.jp>; Fri, 17 Aug 2012 23:53:25 +0900 (JST) Date: Fri, 17 Aug 2012 23:53:27 +0900 From: Yoshihiro Ohba In-reply-to: To: Sam Hartman Message-id: <502E5AE7.1000407@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <502C6BF0.3030400@toshiba.co.jp> <6F0B4ED8-68F1-44BB-A94B-E5D86E6C7254@lilacglade.org> <502CEB6D.6040304@toshiba.co.jp> <684F11AE-1361-4A75-A70B-8B0226510E09@gmail.com> <63E0C6E0-8E5B-4AAA-B0C8-D2E892ECEE18@yegin.org> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 Cc: pcp@ietf.org Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 14:53:49 -0000 I am ok without supporting PANA relay for PCP authentication. It also makes key management easier because remote transport of PCP key from PAA to PCP server is needed if PANA relay is supported for PCP authentication. Yoshihiro Ohba (2012/08/17 22:07), Sam Hartman wrote: > > Alper> EAP Authenticator is on the PCP server. Hence, PAA (PANA > Alper> Authentication Agent) and PCP server are on the same node. > Alper> Therefore, the PAA can tell whether it's authenticating the > Alper> PaC for PCP or for network access by looking at the > Alper> destination port. That's sufficient. > > So you are happy to decide PCP authentication doesn't need a PANA relay? > If so, I propose we explicitly decide that. > > It makes my channel binding question easier. > From alper.yegin@yegin.org Fri Aug 17 08:51:03 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78C421F860D for ; Fri, 17 Aug 2012 08:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSoT+ybEd-DC for ; Fri, 17 Aug 2012 08:51:03 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id CB97721F8605 for ; Fri, 17 Aug 2012 08:51:02 -0700 (PDT) Received: from [192.168.2.4] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MQgmT-1T84FI1mVp-00U1j7; Fri, 17 Aug 2012 11:50:53 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: Date: Fri, 17 Aug 2012 18:50:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5FEBF03D-2045-4F6C-B1A3-C35330677AED@yegin.org> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <502C6BF0.3030400@toshiba.co.jp> <6F0B4ED8-68F1-44BB-A94B-E5D86E6C7254@lilacglade.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:QKqL7CBk+o0H5iC04S00GsV6SA5urUn2LU4pITM1/E7 JceBkl2MqN3oLuV+8fcwKhfXUxxJkng9tKSDJXxVL3nl4rBOzZ GFCxV9NINY8/0U+OPwkL5nmqfUEkI9MQBOFbW52DKTvZoqQsBr pVKvjxWRESN6VNkmOCCNW0bhQOzDC3Lo/e6EKtnzt7jeKPbKQC tLT1y3eAxlwXZLROOPDvYxg8oQXNOypFkM3faYVMUHG4w9PUHY 5XDB84pF6/OvSXKFiNaqRUKdW5tNG0ZtHEK/w1BGtDtGlFVyrT F5BsFhVGI7MqsgBdh826wBUlrZdLK8qu4YPD0fuVMurkJHnXnH cCjYLvDSwUCWYluLOH/fs52dugvES5FkKM5w8NTpKvGNqO5R9j XhopEgmWy+d7g== Cc: pcp@ietf.org Subject: Re: [pcp] channel binding X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 15:51:04 -0000 >=20 > Alper> (spinning off a new thread for easier tracking) >=20 > Alper> What value are you thinking of using for i1 and i2? IP > Alper> address of the PCP server? If so, you can do that in any of > Alper> those solutions. Is there a problem? > I'm not entirely sure what we need for i1 and i2. > I think it definitely needs to include: >=20 > * an indication that it is PCP > * IP address. >=20 > Possibly this is easy. > Can you give a clear algorithm for determining what ip address to use = in > i2? >=20 For i2, we need new RADIUS attribute(s)/Diameter AVP(s) to carry an = indication that this is for PCP authentication, and the IP address = facing the PCP client/PANA Client. These would constitute i2. Note that the IP address used by the node implementing PAA and PCP = server may be different than the IP address used by the same node with = its AAA client. That's why I said "facing=85" Alper =20 > --Sam From alper.yegin@yegin.org Fri Aug 17 08:55:04 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E529D21F8615 for ; Fri, 17 Aug 2012 08:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9yGHklQy0FD for ; Fri, 17 Aug 2012 08:55:03 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 5715F21F8613 for ; Fri, 17 Aug 2012 08:55:03 -0700 (PDT) Received: from [192.168.2.4] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lkwt3-1Taukz1ApB-00bDen; Fri, 17 Aug 2012 11:55:02 -0400 Content-Type: text/plain; charset=iso-2022-jp Mime-Version: 1.0 (Apple Message framework v1278) From: Alper Yegin In-Reply-To: <502E5AE7.1000407@toshiba.co.jp> Date: Fri, 17 Aug 2012 18:54:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <502C6BF0.3030400@toshiba.co.jp> <6F0B4ED8-68F1-44BB-A94B-E5D86E6C7254@lilacglade.org> <502CEB6D.6040304@toshiba.co.jp> <684F11AE-1361-4A75-A70B-8B0226510E09@gmail.com> <63E0C6E0-8E5B-4AAA-B0C8-D2E892ECEE18@yegin.org> <502E5AE7.1000407@toshiba.co.jp> To: pcp@ietf.org X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:P8fI6+L4p/ZDSEZxv40TmXOHxXyu4BF3pz0tJiq3Xgh E/TCfZAfMOuvMFm/EZswhmT9J2N9YDXxREMMQy2wE1Kv1jBUHN jD8C25aOJK/CpuEOoMp27Q3kD4uzHoFvMFM98VcCKe/dAtGCdI NJxzdMGvSRNbxGER5BkjagYs6uD2w0qW0KPmydSH3IT5SwhvQB 90v+Um9NBcvpOwTxr9EKnSVxXx3fZAoUEKDpRFjPJAsHOLGcyH rklTfdcApvLmXYfgKF1KCaNSsTrwayO0qENdfqMPi202SYXgb1 M28Xkj0B5HskrQc8gMaisJwnVdmkdNhAKUNPDyHFMbmH70AEw5 30FKh6T7zFJZsrg7qACtU54XF7ebgHa+JOVEGF3Z3jPBfIaykn gHPTeB4iaEcOA== Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 15:55:04 -0000 Sam said: > So you are happy to decide PCP authentication doesn't need a PANA = relay? I really didn't understand when this "split EAP authenticator from PCP = server" case came into the picture. Unless someone has a real use case behind it, we can ignore that case. Yoshi said: > I am ok without supporting PANA relay for PCP authentication. >=20 > It also makes key management easier because remote transport of PCP > key from PAA to PCP server is needed if PANA relay is supported for > PCP authentication. >=20 Well, such a thing would have been needed irrespective of what carried = EAP (PCP itself or PANA) if we were to deal with the split case. Alper > Yoshihiro Ohba >=20 > (2012/08/17 22:07), Sam Hartman wrote: >>=20 >> Alper> EAP Authenticator is on the PCP server. Hence, PAA (PANA >> Alper> Authentication Agent) and PCP server are on the same node. >> Alper> Therefore, the PAA can tell whether it's authenticating = the >> Alper> PaC for PCP or for network access by looking at the >> Alper> destination port. That's sufficient. >>=20 >> So you are happy to decide PCP authentication doesn't need a PANA = relay? >> If so, I propose we explicitly decide that. >>=20 >> It makes my channel binding question easier. >>=20 >=20 From dwing@cisco.com Fri Aug 17 17:51:29 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B725621E809C for ; Fri, 17 Aug 2012 17:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.488 X-Spam-Level: X-Spam-Status: No, score=-110.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mr0801ZeAqim for ; Fri, 17 Aug 2012 17:51:27 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA5421E808D for ; Fri, 17 Aug 2012 17:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5164; q=dns/txt; s=iport; t=1345251082; x=1346460682; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=TcrzGwYVgpa8449NXBOtq7PqrsxPUEEGs/Pcz2o/M5o=; b=Fp3Whw6dbLoKJ/HIvhU2qq3gDfvRoTmg3ktk7+whfSg/L0M0PyFaBait oKJ1I9ZAsGOsGFULHUEBohucJqYiriyz6Nb6YDqt8Kn8GyPYamV/fQFyG LEAhT+24+nLL06J6ss8TQM5cJxd+VscHBpbJA21Tste5sDqgpBNs5vBuc k=; X-IronPort-AV: E=Sophos;i="4.77,789,1336348800"; d="scan'208";a="55412195" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 18 Aug 2012 00:51:22 +0000 Received: from dwingWS ([10.21.75.132]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7I0pMIE007431; Sat, 18 Aug 2012 00:51:22 GMT From: "Dan Wing" To: Date: Fri, 17 Aug 2012 17:51:22 -0700 Message-ID: <028301cd7cdb$966780a0$c33681e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1825YgdqnKbKRsQbGswo9PpQX9dg== Content-Language: en-us Cc: 'Stuart Cheshire' Subject: [pcp] strengthening PCP with Mapping Nonce X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 00:51:29 -0000 We incorporated changes to draft-ietf-behave-pcp-base from IESG review. After reading the PCP restrictions in REQ-9-A through E in draft-ietf-behave-lsn-requirements-09 (copied below for reference), we had a productive phone call this week between Stuart Cheshire, Simon Perreault, Sam Hartman, and myself. During that discussion, we found a way to strengthen security of PCP against a specific attack and hopefully soften some of the restrictions in both draft-ietf-behave-lsn-requirements (REQ-9-A through E) and draft-ietf-pcp-base for the PCP Basic Threat Model, when PCP is not using authentication. To achieve this, we need to improve how draft-ietf-pcp-base handles Mapping Nonce values. Currently, draft-ietf-pcp-base is pretty silent on how and when the PCP client chooses its Mapping Nonce value, and says this about server processing, which sort of implies the PCP client is free to change the Mapping Nonce value whenever it likes, http://tools.ietf.org/html/draft-ietf-pcp-base-26#section-11.3, The PCP server only needs to remember one Mapping Nonce value for each mapping (that is, the most recent Mapping Nonce value overwrites the previous Mapping Nonce value). We would replace the above text with something like: If the Internal port, Protocol, and Internal Address match an existing explicit dynamic mapping, but the Mapping Nonce does not match, the request MUST be rejected with a NOT_AUTHORIZED error with the Lifetime of the error indicating duration of that existing mapping. The PCP server only needs to remember one Mapping Nonce value for each explicit dynamic mapping. with this change (and corresponding text for the PCP client's generation of a Mapping Nonce, and corresponding text for PEER), we avoid the attack described in detail below. Attack: The attack is a traffic-stealing attack. The diagram below may help with the textual description. The attack scenario is where there is a CGN running PCP and a home NAT not running PCP, and two hosts on separate networks behind the same home NAT. The hosts are on separate networks. One host is running a server (the victim) on the wired network, the other host is the attacker on the guest Wi-Fi network. The host running the server has a mapping created in the NAT, which was created with UPnP IGD or created manually, and has a PCP-created mapping in the CGN. The attacker uses UPnP IGD, NAT-PMP, STUN (RFC5389), or STUNT (http://nutss.gforge.cis.cornell.edu/stunt.php) to create a mapping in the home NAT and learn the home NAT's "WAN" address. The attacker formulates a PCP MAP request with the NAT's WAN address in the PCP Client IP Address field, Lifetime=0, and sends that to the CGN, deleting the CGN's existing mapping that goes to the victim machine. That attack packet is sent without address spoofing. 120 seconds later (per REQ-8 of draft-ietf-behave-lsn-requirements-09), the attacker sends a new PCP MAP request to try to acquire the (old) mapping of the victim host. In this way, the attacker steals incoming traffic intended to go to the victim host. Diagram: +-------------+ +----------+ attacker -------+ | | | (guest network) | | | | | home NAT +----+ CGN +----{Internet} victim ---------+(without PCP)| |(with PCP)| (wired network) | | | | +-------------+ +----------+ Please provide us feedback. I expect to publish -27 soon with these changes, but we are doing some text coordination before publishing -27. -d ----- REQ-9: A CGN MUST implement a protocol giving subscribers explicit control over NAT mappings. That protocol SHOULD be the Port Control Protocol [I-D.ietf-pcp-base], in which case the PCP server MUST obey the following constraints on its behavior: A. It MUST NOT permit the lifetime of a mapping to be reduced beyond its current life or be set to zero (deleted). B. It MUST NOT permit a NAT mapping to be created with a lifetime less than the lifetime used for implicit mappings. C. It MUST NOT support the THIRD_PARTY option except for requests received from "trusted" sources where it is impractical for those sources to be spoofed. D. The MAP opcode MAY be permitted if the recommendation of endpoint independent filtering behavior described in REQ-7 is adopted; the map opcode MUST NOT be permitted in other circumstances. These constraints MAY be relaxed if a security mechanism consistent with PCP's Advanced Threat Model (see Section 17.2 of [I-D.ietf-pcp-base]) is used; this is expected to be rare for CGN deployments. E. Mappings created by PCP MUST follow the same deallocation behavior (REQ-8) as implicitly mapped traffic. From zhangdacheng@huawei.com Mon Aug 20 00:13:57 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3962D21F8650 for ; Mon, 20 Aug 2012 00:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.936 X-Spam-Level: X-Spam-Status: No, score=-5.936 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yvXrUJ4ORV1 for ; Mon, 20 Aug 2012 00:13:56 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 70C8B21F8647 for ; Mon, 20 Aug 2012 00:13:55 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJE77907; Sun, 19 Aug 2012 23:13:54 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 20 Aug 2012 00:07:55 -0700 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 20 Aug 2012 00:07:55 -0700 Received: from SZXEML528-MBS.china.huawei.com ([169.254.5.217]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Mon, 20 Aug 2012 15:07:52 +0800 From: "Zhangdacheng (Dacheng)" To: Yoshihiro Ohba , Sam Hartman Thread-Topic: [pcp] Comparison of PCP authentication Thread-Index: AQHNfHlL1F5Ai0qa4kawmCOKzP6BvpddkQ6AgAS6yUA= Date: Mon, 20 Aug 2012 07:07:51 +0000 Message-ID: References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <502C6BF0.3030400@toshiba.co.jp> <6F0B4ED8-68F1-44BB-A94B-E5D86E6C7254@lilacglade.org> <502CEB6D.6040304@toshiba.co.jp> <684F11AE-1361-4A75-A70B-8B0226510E09@gmail.com> <63E0C6E0-8E5B-4AAA-B0C8-D2E892ECEE18@yegin.org> <502E5AE7.1000407@toshiba.co.jp> In-Reply-To: <502E5AE7.1000407@toshiba.co.jp> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pcp@ietf.org" Subject: Re: [pcp] Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 07:13:57 -0000 +1 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Yoshihiro Ohba > Sent: Friday, August 17, 2012 10:53 PM > To: Sam Hartman > Cc: pcp@ietf.org > Subject: Re: [pcp] Comparison of PCP authentication >=20 > I am ok without supporting PANA relay for PCP authentication. >=20 > It also makes key management easier because remote transport of PCP > key from PAA to PCP server is needed if PANA relay is supported for > PCP authentication. >=20 > Yoshihiro Ohba >=20 > (2012/08/17 22:07), Sam Hartman wrote: > > > > Alper> EAP Authenticator is on the PCP server. Hence, PAA (PANA > > Alper> Authentication Agent) and PCP server are on the same node. > > Alper> Therefore, the PAA can tell whether it's authenticating the > > Alper> PaC for PCP or for network access by looking at the > > Alper> destination port. That's sufficient. > > > > So you are happy to decide PCP authentication doesn't need a PANA relay= ? > > If so, I propose we explicitly decide that. > > > > It makes my channel binding question easier. > > >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Mon Aug 20 05:27:26 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E4A21F85A8 for ; Mon, 20 Aug 2012 05:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQI+UwtHoe3Q for ; Mon, 20 Aug 2012 05:27:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6207F21F85A5 for ; Mon, 20 Aug 2012 05:27:25 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 715A13249A7 for ; Mon, 20 Aug 2012 14:27:24 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 564964C015 for ; Mon, 20 Aug 2012 14:27:24 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Mon, 20 Aug 2012 14:27:04 +0200 From: To: "pcp@ietf.org" Date: Mon, 20 Aug 2012 14:27:02 +0200 Thread-Topic: PCP Failure Scenarios (draft-boucadair-pcp-failure-04) Thread-Index: Ac1+zmyEA+eEkT8SSQeiG7W/NOMHlwAABIbQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E512B4680@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Subject: [pcp] PCP Failure Scenarios (draft-boucadair-pcp-failure-04) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 12:27:26 -0000 Dear all, A new version of the draft has been submitted. This new version takes into = account some new features added to PCP (e.g., mapping repair procedure). Please review and comment. A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-failure-04 Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : lundi 20 ao=FBt 2012 14:22 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-boucadair-pcp-failure-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Port Control Protocol (PCP) Failure Scenarios Author(s) : Mohamed Boucadair Francis Dupont Reinaldo Penno Filename : draft-boucadair-pcp-failure-04.txt Pages : 21 Date : 2012-08-20 Abstract: This document identifies and analyzes several PCP failure scenarios. A procedure to retrieve the explicit dynamic mapping(s) from the PCP Server is proposed. This procedure relies upon the use of a new PCP OpCode and Option: GET/NEXT. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-pcp-failure There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-pcp-failure-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-failure-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From repenno@cisco.com Mon Aug 20 19:24:50 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A14011E80A4; Mon, 20 Aug 2012 19:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.359 X-Spam-Level: X-Spam-Status: No, score=-10.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c6kaIoevcoA; Mon, 20 Aug 2012 19:24:50 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id CF8EC11E809A; Mon, 20 Aug 2012 19:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=1268; q=dns/txt; s=iport; t=1345515890; x=1346725490; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7SBdHV1CANR2yheI8fGQKBCf6P+VtyPARXz7HQgL5M8=; b=RlCpaSnUdCuZn5a+zpKomLTUxtbyJEpKhVI4dsB0x0PVGStN4DFRgak7 kbsCfEWAVtFFCm3TzL0V4lQK0QZ5IPih7Isw3uvPfl5MO9NeKrEZO3h4W gdf7670UcK/z/OWCCSAz2IYaKUFvYvmhqbPpsJT6jLhqVHBpfnCJ4y5Kt Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPzvMlCtJXG9/2dsb2JhbABFuluBB4InEgEnPxIBPkIlAgQOHgIHh2uZJKA6kicDlVCOLIFmgmE X-IronPort-AV: E=Sophos;i="4.77,799,1336348800"; d="scan'208";a="113624791" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 21 Aug 2012 02:24:49 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7L2Onuj000372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Aug 2012 02:24:49 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Mon, 20 Aug 2012 21:24:48 -0500 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: Comment on REQ-9A of LSN requirements (PCP) Thread-Index: AQHNf0Qj9EHhzDdBA0m9uGbHtDuTEQ== Date: Tue, 21 Aug 2012 02:24:48 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.155.70.70] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19128.001 x-tm-as-result: No--27.330000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <58B31ABC34AD18438D06D0F7FA90A4F5@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: [pcp] Comment on REQ-9A of LSN requirements (PCP) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 02:24:50 -0000 "A. It MUST NOT permit the lifetime of a mapping to be reduced beyond its current life or be set to zero (deleted)." In the case of renumbering how a CPE that gets a new address can delete stale mappings of the previous user of that IP address? Given some of the requirements, it can not. Before mapping 'nonce' CPE/host could just send a delete all and we would rely on ingress filtering to make sure things are okay. But now with the mapping nonce the new owner of an IP address has no way of deleting the stale mappings because it does not know the nonce. If renumbering happens frequently (as in some networks as short as 30 minutes) and there are many PCP MAP mappings from each CPE/host, then soon depending on the Lifetime there will be no more resources on CGN/AFTR/Firewall due to stale mappings A possible solution would be for DHCP Server or other provisioning server to send a PCP message with THIRD_PARTY to delete all MAP mappings. But again, it does not know the nonce. Not to mention that coupling provisioning and PCP becomes a barrier for adoption. Reducing the 'lifetime' defeats the purpose of having PCP. Not sure of any solution given all requirements in place. Thanks, Reinaldo From mohamed.boucadair@orange.com Mon Aug 20 22:57:27 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FA511E80BF; Mon, 20 Aug 2012 22:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtDlGJmijUyO; Mon, 20 Aug 2012 22:57:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5DA21F8596; Mon, 20 Aug 2012 22:57:26 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 7380F325058; Tue, 21 Aug 2012 07:57:25 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 555AE27C046; Tue, 21 Aug 2012 07:57:25 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 21 Aug 2012 07:57:04 +0200 From: To: "Reinaldo Penno (repenno)" , "pcp@ietf.org" Date: Tue, 21 Aug 2012 07:57:03 +0200 Thread-Topic: Comment on REQ-9A of LSN requirements (PCP) Thread-Index: AQHNf0Qj9EHhzDdBA0m9uGbHtDuTEZdjwh9w Message-ID: <94C682931C08B048B7A8645303FDC9F36E5229895A@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.21.10322 Cc: "behave@ietf.org" Subject: Re: [pcp] Comment on REQ-9A of LSN requirements (PCP) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 05:57:27 -0000 Hi Reinaldo, Stale mapping is a real issue which may consume per-user quota. The issue, = exacerbated with the use of nonce, is discussed in detail in http://tools.i= etf.org/html/draft-boucadair-pcp-failure-04 which proposes also a mechanism= to recover the mapping nonce. Below some excerpts from the draft: Section 2.2 of the failure draft reads: If the same port number is used but a distinct mapping nonce is generated, the request will be rejected with a NOT_AUTHORIZED error with the Lifetime of the error indicating duration of that existing mapping. This issue can be solved if the PCP Client uses GET OpCode (Section 4) to recover the mapping nonce used when instantiating the mapping. Section 2.3 of the failure draft reads: If the PCP Client does not store the explicit dynamic mappings and new mapping nonces are assigned, the PCP Server will reject to refresh these mappings. This issue can be solved if the PCP Client uses GET OpCode (Section 4) to recover the mapping nonces used when instantiating the mappings. Section 2.6 of the failure draft reads: On the reboot of the IWF, if no mapping table is maintained in a permanent storage, "stale" mappings will be maintained by the PCP Server and per-user quota will be consumed. This is even exacerbated if new mapping nonces are assigned by the IWF. This issue can be soften by synchronizing the mapping table owing to the invocation of the GET OpCode defined in Section 4. =20 Cheers, Med >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Reinaldo Penno (repenno) >Envoy=E9 : mardi 21 ao=FBt 2012 04:25 >=C0 : pcp@ietf.org >Cc : behave@ietf.org >Objet : [pcp] Comment on REQ-9A of LSN requirements (PCP) > >"A. It MUST NOT permit the lifetime of a mapping to be > reduced beyond its current life or be set to zero > (deleted)." > >In the case of renumbering how a CPE that gets a new address can delete >stale mappings of the previous user of that IP address? Given=20 >some of the >requirements, it can not. > >Before mapping 'nonce' CPE/host could just send a delete all=20 >and we would >rely on ingress filtering to make sure things are okay. But=20 >now with the >mapping nonce the new owner of an IP address has no way of deleting the >stale mappings because it does not know the nonce. > >If renumbering happens frequently (as in some networks as short as 30 >minutes) and there are many PCP MAP mappings from each=20 >CPE/host, then soon >depending on the Lifetime there will be no more resources on >CGN/AFTR/Firewall due to stale mappings > >A possible solution would be for DHCP Server or other=20 >provisioning server >to send a PCP message with THIRD_PARTY to delete all MAP mappings. But >again, it does not know the nonce. Not to mention that coupling >provisioning and PCP becomes a barrier for adoption. Reducing the >'lifetime' defeats the purpose of having PCP. > >Not sure of any solution given all requirements in place. > >Thanks, > >Reinaldo > > > > > > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp >= From repenno@cisco.com Tue Aug 21 03:16:16 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13BA21F869F; Tue, 21 Aug 2012 03:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id te13NuTc2qu3; Tue, 21 Aug 2012 03:16:16 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 08BDF21F86AA; Tue, 21 Aug 2012 03:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=4098; q=dns/txt; s=iport; t=1345544176; x=1346753776; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Is0UXtokxZhdjn1dl1Px5qvMWmQwvRaljdEzNakuJ/4=; b=h9wME8djdoFAyD/HhA45LA3X6IVggWG79SwcrxRMistVjHL61W3c0Sa2 4BEl2nBEWyOHJMnmZ46chOdEwtSWYOpiuWN5Ch/yShOuIIP7IhASzwdRc jgFppbrU/19Y40ftrINnhpApFuq5hds0akojNtUm8xPzY1hYKZOWZ2e+x k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAANfM1CtJV2Y/2dsb2JhbABFul+BB4IgAQEBBAEBAQ8BWwsMBgEIEQMBAiguCxQJCAIEAQ0FGQIHh2sLmROgPIsIHASGfAOIGo04gRSNGYFmgmGBWQ X-IronPort-AV: E=Sophos;i="4.77,801,1336348800"; d="scan'208";a="113695432" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 21 Aug 2012 10:16:15 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7LAGFBL002027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Aug 2012 10:16:15 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0298.004; Tue, 21 Aug 2012 05:16:15 -0500 From: "Reinaldo Penno (repenno)" To: "mohamed.boucadair@orange.com" , "pcp@ietf.org" Thread-Topic: Comment on REQ-9A of LSN requirements (PCP) Thread-Index: AQHNf0Qj9EHhzDdBA0m9uGbHtDuTEZdjwh9wgAApyoA= Date: Tue, 21 Aug 2012 10:16:14 +0000 Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5229895A@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.74.208] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19128.005 x-tm-as-result: No--52.736900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [pcp] Comment on REQ-9A of LSN requirements (PCP) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 10:16:16 -0000 -----Original Message----- From: Date: Tue, 21 Aug 2012 07:57:03 +0200 To: Reinaldo Penno , "pcp@ietf.org" Cc: "behave@ietf.org" Subject: RE: Comment on REQ-9A of LSN requirements (PCP) >Hi Reinaldo, > >Stale mapping is a real issue which may consume per-user quota. The >issue, exacerbated with the use of nonce, is discussed in detail in >http://tools.ietf.org/html/draft-boucadair-pcp-failure-04 which proposes >also a mechanism to recover the mapping nonce. Below some excerpts from >the draft: > >Section 2.2 of the failure draft reads: > > If the same port number is used but a distinct mapping nonce is > generated, the request will be rejected with a NOT_AUTHORIZED error > with the Lifetime of the error indicating duration of that existing > mapping. This issue can be solved if the PCP Client uses GET OpCode > (Section 4) to recover the mapping nonce used when instantiating the > mapping. That's a good idea but unless the PCP Client recovers all nonces by trying to map to all internal ports the problem would still exist, right? I mean, only those mappings that resulted in collisions would be recovered. Alos, wouldn't this opcode allow an attacker to recover opcodes belonging to others. But anyway, the problem we are facing is due to base spec which is at WGLC. If something, we need to solve there. =20 > >Section 2.3 of the failure draft reads: > > If the PCP Client does not store the explicit dynamic mappings and > new mapping nonces are assigned, the PCP Server will reject to > refresh these mappings. This issue can be solved if the PCP Client > uses GET OpCode (Section 4) to recover the mapping nonces used when > instantiating the mappings. > >Section 2.6 of the failure draft reads: > > On the reboot of the IWF, if no mapping table is maintained in a > permanent storage, "stale" mappings will be maintained by the PCP > Server and per-user quota will be consumed. This is even exacerbated > if new mapping nonces are assigned by the IWF. This issue can be > soften by synchronizing the mapping table owing to the invocation of > the GET OpCode defined in Section 4. >=20 > >Cheers, >Med > >>-----Message d'origine----- >>De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la >>part de Reinaldo Penno (repenno) >>Envoy=E9 : mardi 21 ao=FBt 2012 04:25 >>=C0 : pcp@ietf.org >>Cc : behave@ietf.org >>Objet : [pcp] Comment on REQ-9A of LSN requirements (PCP) >> >>"A. It MUST NOT permit the lifetime of a mapping to be >> reduced beyond its current life or be set to zero >> (deleted)." >> >>In the case of renumbering how a CPE that gets a new address can delete >>stale mappings of the previous user of that IP address? Given >>some of the >>requirements, it can not. >> >>Before mapping 'nonce' CPE/host could just send a delete all >>and we would >>rely on ingress filtering to make sure things are okay. But >>now with the >>mapping nonce the new owner of an IP address has no way of deleting the >>stale mappings because it does not know the nonce. >> >>If renumbering happens frequently (as in some networks as short as 30 >>minutes) and there are many PCP MAP mappings from each >>CPE/host, then soon >>depending on the Lifetime there will be no more resources on >>CGN/AFTR/Firewall due to stale mappings >> >>A possible solution would be for DHCP Server or other >>provisioning server >>to send a PCP message with THIRD_PARTY to delete all MAP mappings. But >>again, it does not know the nonce. Not to mention that coupling >>provisioning and PCP becomes a barrier for adoption. Reducing the >>'lifetime' defeats the purpose of having PCP. >> >>Not sure of any solution given all requirements in place. >> >>Thanks, >> >>Reinaldo >> >> >> >> >> >> >>_______________________________________________ >>pcp mailing list >>pcp@ietf.org >>https://www.ietf.org/mailman/listinfo/pcp From zhangzhongjian@huawei.com Wed Aug 22 01:04:39 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0E721F8602 for ; Wed, 22 Aug 2012 01:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQBaavOqUmed for ; Wed, 22 Aug 2012 01:04:35 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B368521F84F7 for ; Wed, 22 Aug 2012 01:04:34 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp01-ep.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJM03473; Wed, 22 Aug 2012 00:04:31 -0800 (PST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Aug 2012 00:59:19 -0700 Received: from SZXEML433-HUB.china.huawei.com (10.72.61.61) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Aug 2012 00:59:18 -0700 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.83]) by szxeml433-hub.china.huawei.com ([10.72.61.61]) with mapi id 14.01.0323.003; Wed, 22 Aug 2012 15:59:12 +0800 From: "Zhangzongjian (Thomas)" To: Dan Wing , "pcp@ietf.org" Thread-Topic: [pcp] strengthening PCP with Mapping Nonce Thread-Index: Ac1825YgdqnKbKRsQbGswo9PpQX9dgDXgBgw Date: Wed, 22 Aug 2012 07:59:12 +0000 Message-ID: <0B2F754289D27B449F7F1B95456B77544EDC4FFE@szxeml524-mbs.china.huawei.com> References: <028301cd7cdb$966780a0$c33681e0$@com> In-Reply-To: <028301cd7cdb$966780a0$c33681e0$@com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.96] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: 'Stuart Cheshire' Subject: Re: [pcp] strengthening PCP with Mapping Nonce X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 08:04:39 -0000 Dear wing > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dan > Wing > Sent: Saturday, August 18, 2012 8:51 AM > To: pcp@ietf.org > Cc: 'Stuart Cheshire' > Subject: [pcp] strengthening PCP with Mapping Nonce >=20 > We incorporated changes to draft-ietf-behave-pcp-base from IESG review. >=20 > After reading the PCP restrictions in REQ-9-A through E in > draft-ietf-behave-lsn-requirements-09 (copied below for reference), we ha= d a > productive phone call this week between Stuart Cheshire, Simon Perreault, > Sam Hartman, and myself. During that discussion, we found a way to > strengthen security of PCP against a specific attack and hopefully soften > some of the restrictions in both draft-ietf-behave-lsn-requirements (REQ-= 9-A > through E) and draft-ietf-pcp-base for the PCP Basic Threat Model, when P= CP > is not using authentication. >=20 > To achieve this, we need to improve how draft-ietf-pcp-base handles Mappi= ng > Nonce values. Currently, draft-ietf-pcp-base is pretty silent on how and > when the PCP client chooses its Mapping Nonce value, and says this about > server processing, which sort of implies the PCP client is free to change > the Mapping Nonce value whenever it likes, > http://tools.ietf.org/html/draft-ietf-pcp-base-26#section-11.3, >=20 > The PCP server only needs to remember one Mapping Nonce value for > each mapping (that is, the most recent Mapping Nonce value overwrites > the previous Mapping Nonce value). >=20 > We would replace the above text with something like: >=20 > If the Internal port, Protocol, and Internal Address match an > existing explicit dynamic mapping, but the Mapping Nonce does not > match, the request MUST be rejected with a NOT_AUTHORIZED error with > the Lifetime of the error indicating duration of that existing > mapping. The PCP server only needs to remember one Mapping Nonce > value for each explicit dynamic mapping. >=20 > with this change (and corresponding text for the PCP client's generation = of > a Mapping Nonce, and corresponding text for PEER), we avoid the attack > described in detail below. >=20 >=20 > Attack: The attack is a traffic-stealing attack. The diagram below may > help with the textual description. The attack scenario is where there is= a > CGN running PCP and a home NAT not running PCP, and two hosts on separate > networks behind the same home NAT. The hosts are on separate networks. > One > host is running a server (the victim) on the wired network, the other hos= t > is the attacker on the guest Wi-Fi network. The host running the server = has > a mapping created in the NAT, which was created with UPnP IGD or created > manually, and has a PCP-created mapping in the CGN. The attacker uses > UPnP > IGD, NAT-PMP, STUN (RFC5389), or STUNT > (http://nutss.gforge.cis.cornell.edu/stunt.php) to create a mapping in th= e > home NAT and learn the home NAT's "WAN" address. The attacker > formulates a > PCP MAP request with the NAT's WAN address in the PCP Client IP Address > field, Lifetime=3D0, and sends that to the CGN, deleting the CGN's existi= ng > mapping that goes to the victim machine. That attack packet is sent with= out Thomas=3D> Why does not the home NAT use the third party option?=20 When home NAT receives a PCP MAP request with lifetime=3D0 from attacker, i= t should add a third party option with the attacker's IP address in this op= tion. When CGN gets the PCP request, it will use the third party option add= ress as the source address to search the MAP entries. Then the attacker can= 't delete the MAP entry created by victim. > address spoofing. 120 seconds later (per REQ-8 of > draft-ietf-behave-lsn-requirements-09), the attacker sends a new PCP MAP > request to try to acquire the (old) mapping of the victim host. In this > way, the attacker steals incoming traffic intended to go to the victim ho= st. >=20 >=20 > Diagram: >=20 > +-------------+ +----------+ > attacker -------+ | | | > (guest network) | | | | > | home NAT +----+ CGN +----{Internet} > victim ---------+(without PCP)| |(with PCP)| > (wired network) | | | | > +-------------+ +----------+ >=20 >=20 > Please provide us feedback. I expect to publish -27 soon with these > changes, but we are doing some text coordination before publishing -27. >=20 > -d >=20 > ----- >=20 > REQ-9: A CGN MUST implement a protocol giving subscribers explicit > control over NAT mappings. That protocol SHOULD be the Port > Control Protocol [I-D.ietf-pcp-base], in which case the PCP > server MUST obey the following constraints on its behavior: >=20 > A. It MUST NOT permit the lifetime of a mapping to be > reduced beyond its current life or be set to zero > (deleted). >=20 > B. It MUST NOT permit a NAT mapping to be created with a > lifetime less than the lifetime used for implicit > mappings. >=20 > C. It MUST NOT support the THIRD_PARTY option except for > requests received from "trusted" sources where it is > impractical for those sources to be spoofed. >=20 > D. The MAP opcode MAY be permitted if the recommendation > of > endpoint independent filtering behavior described in > REQ-7 is adopted; the map opcode MUST NOT be permitted > in > other circumstances. These constraints MAY be relaxed if > a security mechanism consistent with PCP's Advanced > Threat Model (see Section 17.2 of [I-D.ietf-pcp-base]) is > used; this is expected to be rare for CGN deployments. >=20 > E. Mappings created by PCP MUST follow the same deallocation > behavior (REQ-8) as implicitly mapped traffic. >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp Best regards Thomas From ales.vizdal@t-mobile.cz Wed Aug 22 01:51:45 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D806F21F8570 for ; Wed, 22 Aug 2012 01:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.294 X-Spam-Level: * X-Spam-Status: No, score=1.294 tagged_above=-999 required=5 tests=[AWL=3.244, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKlz2wPTkGAp for ; Wed, 22 Aug 2012 01:51:44 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id DE45021F851E for ; Wed, 22 Aug 2012 01:51:42 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.254.92.81]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 39C6528581D; Wed, 22 Aug 2012 10:51:40 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Wed, 22 Aug 2012 10:50:44 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "Tirumaleswar Reddy (tireddy)" , GangChen , "pcp@ietf.org" Date: Wed, 22 Aug 2012 10:53:53 +0200 Thread-Topic: [pcp] Issue Analysis of PCP in Mobile Network was (Fwd: New Version Notification for draft-chen-pcp-mobile-deployment-01.txt) Thread-Index: AQHNY4V3euq9CB4dPEON9BKc/XznjpdYtExggA0GZ8A= Message-ID: <1808340F7EC362469DDFFB112B37E2FCC681D9234A@SRVHKE02.rdm.cz> References: <913383AAA69FF945B8F946018B75898A14782FFE@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A14782FFE@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forwarded Subject: Re: [pcp] Issue Analysis of PCP in Mobile Network was (Fwd: New Version Notification for draft-chen-pcp-mobile-deployment-01.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 08:51:45 -0000 Hi Tiru, > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Tir= umaleswar > Reddy (tireddy) > Sent: Tuesday, August 14, 2012 11:05 AM > To: GangChen; pcp@ietf.org > Subject: Re: [pcp] Issue Analysis of PCP in Mobile Network was (Fwd: New = Version > Notification for draft-chen-pcp-mobile-deployment-01.txt) >=20 > Hi - >=20 > 1. Section 2.1 > Can you please clarify what kind of applications on Mobile devices would = require port > range on Firewall ? > MAP/PEER cannot be used to request Firewall to open a range of ports (oth= er than "all > ports") Do you mean that PCP cannot be used to open up a port on the Firewall or ar= e you pointing out that a port range cannot be opened? The latter could be achiev= ed by=20 a request per port to open up a port range. =20 > --Tiru. Cheers, Ales From tireddy@cisco.com Wed Aug 22 05:10:10 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C36321F86A3 for ; Wed, 22 Aug 2012 05:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.878 X-Spam-Level: X-Spam-Status: No, score=-7.878 tagged_above=-999 required=5 tests=[AWL=2.421, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lrXX0AJUxhP for ; Wed, 22 Aug 2012 05:10:06 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD6421F8489 for ; Wed, 22 Aug 2012 05:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tireddy@cisco.com; l=1465; q=dns/txt; s=iport; t=1345637406; x=1346847006; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8lE6L3Xn6DCClgD94+RtOPsg+z72MdUiVA6mkfMzQSs=; b=WKse8eJMSte4FA8BCOElXA2I4Z9dWVY8tbDJQuSbP7tIGA442AhaW/vH ileulqnmzRa70XG9XgnTlzg9ok4aPlV65GaORThgmFrYx5ViWsUnS8yrq 518gD38HhXUqvtrdEGb/ot1zdZ93+xsDjwuoS2ZxjUQRvO4c7ycWogQ2r 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANDKNFCtJV2b/2dsb2JhbABFukCBB4IgAQEBAwESAWQHBwQCAQgRBAEBCxkEBzIUCQgCBAESCBqHZQaZKqBQiwiGPGADo3+BZoJh X-IronPort-AV: E=Sophos;i="4.77,808,1336348800"; d="scan'208";a="114166787" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 22 Aug 2012 12:10:06 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7MCA52k028947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Aug 2012 12:10:06 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Wed, 22 Aug 2012 07:10:05 -0500 From: "Tirumaleswar Reddy (tireddy)" To: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= , GangChen , "pcp@ietf.org" Thread-Topic: [pcp] Issue Analysis of PCP in Mobile Network was (Fwd: New Version Notification for draft-chen-pcp-mobile-deployment-01.txt) Thread-Index: AQHNY4V3euq9CB4dPEON9BKc/XznjpdYtExggA0GZ8CAAA7kIA== Date: Wed, 22 Aug 2012 12:10:04 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1478FB54@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A14782FFE@xmb-rcd-x10.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC681D9234A@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC681D9234A@SRVHKE02.rdm.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.28.67] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19130.005 x-tm-as-result: No--44.455800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Issue Analysis of PCP in Mobile Network was (Fwd: New Version Notification for draft-chen-pcp-mobile-deployment-01.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 12:10:10 -0000 > -----Original Message----- > From: V=EDzdal Ale=B9 [mailto:ales.vizdal@t-mobile.cz] > Sent: Wednesday, August 22, 2012 2:24 PM > To: Tirumaleswar Reddy (tireddy); GangChen; pcp@ietf.org > Subject: RE: [pcp] Issue Analysis of PCP in Mobile Network was (Fwd: > New Version Notification for draft-chen-pcp-mobile-deployment-01.txt) >=20 > Hi Tiru, >=20 > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Tirumaleswar > > Reddy (tireddy) > > Sent: Tuesday, August 14, 2012 11:05 AM > > To: GangChen; pcp@ietf.org > > Subject: Re: [pcp] Issue Analysis of PCP in Mobile Network was (Fwd: > New Version > > Notification for draft-chen-pcp-mobile-deployment-01.txt) > > > > Hi - > > > > 1. Section 2.1 > > Can you please clarify what kind of applications on Mobile devices > would require port > > range on Firewall ? > > MAP/PEER cannot be used to request Firewall to open a range of ports > (other than "all > > ports") >=20 > Do you mean that PCP cannot be used to open up a port on the Firewall PCP can be used to open port on firewall. > or are you > pointing out that a port range cannot be opened ? The latter could be > achieved by > a request per port to open up a port range. using single request/response port range cannot be opened, but agreed it ca= n be achieved using multiple request/responses. --Tiru. >=20 > > --Tiru. >=20 > Cheers, > Ales From simon.perreault@viagenie.ca Wed Aug 22 06:18:32 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77F221F84F1 for ; Wed, 22 Aug 2012 06:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLNYxTYaUsCy for ; Wed, 22 Aug 2012 06:18:27 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 71CAD21F8450 for ; Wed, 22 Aug 2012 06:18:27 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:6ca5:e542:5b44:7b06]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 99438415D8 for ; Wed, 22 Aug 2012 09:18:26 -0400 (EDT) Message-ID: <5034DC22.7020505@viagenie.ca> Date: Wed, 22 Aug 2012 09:18:26 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: pcp@ietf.org References: <028301cd7cdb$966780a0$c33681e0$@com> <0B2F754289D27B449F7F1B95456B77544EDC4FFE@szxeml524-mbs.china.huawei.com> In-Reply-To: <0B2F754289D27B449F7F1B95456B77544EDC4FFE@szxeml524-mbs.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] strengthening PCP with Mapping Nonce X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 13:18:32 -0000 Le 2012-08-22 03:59, Zhangzongjian (Thomas) a écrit : > Why does not the home NAT use the third party option? In Dan's scenario the home NAT does not support PCP. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dwing@cisco.com Wed Aug 22 08:51:04 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4F621F85F4 for ; Wed, 22 Aug 2012 08:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.49 X-Spam-Level: X-Spam-Status: No, score=-110.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFR6HbsxP5w3 for ; Wed, 22 Aug 2012 08:50:54 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 075B321F858A for ; Wed, 22 Aug 2012 08:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=7083; q=dns/txt; s=iport; t=1345650654; x=1346860254; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=qAZYSuIztNgpGSrh+qXzURdbny2DjhMf5XZ8VJfBKCs=; b=AoK6odZq61Y7DeFYMIiXaI7thFWB/J9hylRmntywior7RhAE+9azEk9O /0dmWYHOgCKReI+C6EysccyV0b7hL+3yo2upREtvlJGySMGW1acuWWa9a MVaavPy55kO0dmqvm7tDaqzAIAh3ru0jmtCFw/V24HhqaYRu2RAbOaz2I I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJ3+NFCrRDoG/2dsb2JhbAArGqpYj3GBB4IgAQEBAwEBAQEFCgEVAhA0CwUHAQMCCQ8CBAEBKAcZDhUKCQgBAQQBEgsOCYdlBQwqmDegU4sIhxwDiE+FDYQOhHyJdIMlgWaDAw X-IronPort-AV: E=Sophos;i="4.77,808,1336348800"; d="scan'208";a="55776521" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 22 Aug 2012 15:50:53 +0000 Received: from dwingWS (sjc-vpn2-607.cisco.com [10.21.114.95]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7MFor26010049; Wed, 22 Aug 2012 15:50:53 GMT From: "Dan Wing" To: "'Zhangzongjian \(Thomas\)'" , References: <028301cd7cdb$966780a0$c33681e0$@com> <0B2F754289D27B449F7F1B95456B77544EDC4FFE@szxeml524-mbs.china.huawei.com> In-Reply-To: <0B2F754289D27B449F7F1B95456B77544EDC4FFE@szxeml524-mbs.china.huawei.com> Date: Wed, 22 Aug 2012 08:50:52 -0700 Message-ID: <002301cd807d$e8d9fd40$ba8df7c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1825YgdqnKbKRsQbGswo9PpQX9dgDXgBgwABEHyxA= Content-Language: en-us Cc: 'Stuart Cheshire' Subject: Re: [pcp] strengthening PCP with Mapping Nonce X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 15:51:05 -0000 > -----Original Message----- > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] > Sent: Wednesday, August 22, 2012 12:59 AM > To: Dan Wing; pcp@ietf.org > Cc: 'Stuart Cheshire' > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > Dear wing > > > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Dan > > Wing > > Sent: Saturday, August 18, 2012 8:51 AM > > To: pcp@ietf.org > > Cc: 'Stuart Cheshire' > > Subject: [pcp] strengthening PCP with Mapping Nonce > > > > We incorporated changes to draft-ietf-behave-pcp-base from IESG > review. > > > > After reading the PCP restrictions in REQ-9-A through E in > > draft-ietf-behave-lsn-requirements-09 (copied below for reference), > we had a > > productive phone call this week between Stuart Cheshire, Simon > Perreault, > > Sam Hartman, and myself. During that discussion, we found a way to > > strengthen security of PCP against a specific attack and hopefully > soften > > some of the restrictions in both draft-ietf-behave-lsn-requirements > (REQ-9-A > > through E) and draft-ietf-pcp-base for the PCP Basic Threat Model, > when PCP > > is not using authentication. > > > > To achieve this, we need to improve how draft-ietf-pcp-base handles > Mapping > > Nonce values. Currently, draft-ietf-pcp-base is pretty silent on how > and > > when the PCP client chooses its Mapping Nonce value, and says this > about > > server processing, which sort of implies the PCP client is free to > change > > the Mapping Nonce value whenever it likes, > > http://tools.ietf.org/html/draft-ietf-pcp-base-26#section-11.3, > > > > The PCP server only needs to remember one Mapping Nonce value for > > each mapping (that is, the most recent Mapping Nonce value > overwrites > > the previous Mapping Nonce value). > > > > We would replace the above text with something like: > > > > If the Internal port, Protocol, and Internal Address match an > > existing explicit dynamic mapping, but the Mapping Nonce does not > > match, the request MUST be rejected with a NOT_AUTHORIZED error > with > > the Lifetime of the error indicating duration of that existing > > mapping. The PCP server only needs to remember one Mapping Nonce > > value for each explicit dynamic mapping. > > > > with this change (and corresponding text for the PCP client's > generation of > > a Mapping Nonce, and corresponding text for PEER), we avoid the > attack > > described in detail below. > > > > > > Attack: The attack is a traffic-stealing attack. The diagram below > may > > help with the textual description. The attack scenario is where > there is a > > CGN running PCP and a home NAT not running PCP, and two hosts on > separate > > networks behind the same home NAT. The hosts are on separate > networks. > > One > > host is running a server (the victim) on the wired network, the other > host > > is the attacker on the guest Wi-Fi network. The host running the > server has > > a mapping created in the NAT, which was created with UPnP IGD or > created > > manually, and has a PCP-created mapping in the CGN. The attacker > uses > > UPnP > > IGD, NAT-PMP, STUN (RFC5389), or STUNT > > (http://nutss.gforge.cis.cornell.edu/stunt.php) to create a mapping > in the > > home NAT and learn the home NAT's "WAN" address. The attacker > > formulates a > > PCP MAP request with the NAT's WAN address in the PCP Client IP > Address > > field, Lifetime=0, and sends that to the CGN, deleting the CGN's > existing > > mapping that goes to the victim machine. That attack packet is sent > without > Thomas=> > Why does not the home NAT use the third party option? In the above attack scenario, the home NAT does not support PCP at all. And, if it did, there is no need for THIRD_PARTY if all traffic is NAT'ed to one IP address, as typically occurs with a residential NAT. -d > When home NAT receives a PCP MAP request with lifetime=0 from attacker, > it should add a third party option with the attacker's IP address in > this option. When CGN gets the PCP request, it will use the third party > option address as the source address to search the MAP entries. Then > the attacker can't delete the MAP entry created by victim. > > > > address spoofing. 120 seconds later (per REQ-8 of > > draft-ietf-behave-lsn-requirements-09), the attacker sends a new PCP > MAP > > request to try to acquire the (old) mapping of the victim host. In > this > > way, the attacker steals incoming traffic intended to go to the > victim host. > > > > > > Diagram: > > > > +-------------+ +----------+ > > attacker -------+ | | | > > (guest network) | | | | > > | home NAT +----+ CGN +----{Internet} > > victim ---------+(without PCP)| |(with PCP)| > > (wired network) | | | | > > +-------------+ +----------+ > > > > > > Please provide us feedback. I expect to publish -27 soon with these > > changes, but we are doing some text coordination before publishing - > 27. > > > > -d > > > > ----- > > > > REQ-9: A CGN MUST implement a protocol giving subscribers > explicit > > control over NAT mappings. That protocol SHOULD be the > Port > > Control Protocol [I-D.ietf-pcp-base], in which case the > PCP > > server MUST obey the following constraints on its > behavior: > > > > A. It MUST NOT permit the lifetime of a mapping to be > > reduced beyond its current life or be set to zero > > (deleted). > > > > B. It MUST NOT permit a NAT mapping to be created with a > > lifetime less than the lifetime used for implicit > > mappings. > > > > C. It MUST NOT support the THIRD_PARTY option except for > > requests received from "trusted" sources where it is > > impractical for those sources to be spoofed. > > > > D. The MAP opcode MAY be permitted if the recommendation > > of > > endpoint independent filtering behavior described in > > REQ-7 is adopted; the map opcode MUST NOT be permitted > > in > > other circumstances. These constraints MAY be relaxed > if > > a security mechanism consistent with PCP's Advanced > > Threat Model (see Section 17.2 of [I-D.ietf-pcp-base]) > is > > used; this is expected to be rare for CGN deployments. > > > > E. Mappings created by PCP MUST follow the same > deallocation > > behavior (REQ-8) as implicitly mapped traffic. > > > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp > > Best regards > Thomas From zhangzhongjian@huawei.com Wed Aug 22 19:02:02 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7807B21F854A for ; Wed, 22 Aug 2012 19:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFlRNkI2+Zzj for ; Wed, 22 Aug 2012 19:02:01 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4221A21F853D for ; Wed, 22 Aug 2012 19:02:01 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp03-ep.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJM59299; Wed, 22 Aug 2012 18:02:00 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Aug 2012 18:59:12 -0700 Received: from SZXEML433-HUB.china.huawei.com (10.72.61.61) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Aug 2012 18:59:10 -0700 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.83]) by szxeml433-hub.china.huawei.com ([10.72.61.61]) with mapi id 14.01.0323.003; Thu, 23 Aug 2012 09:59:06 +0800 From: "Zhangzongjian (Thomas)" To: Dan Wing , "pcp@ietf.org" Thread-Topic: [pcp] strengthening PCP with Mapping Nonce Thread-Index: Ac1825YgdqnKbKRsQbGswo9PpQX9dgDXgBgwABEHyxAAFIZlwA== Date: Thu, 23 Aug 2012 01:59:06 +0000 Message-ID: <0B2F754289D27B449F7F1B95456B77544EDC5131@szxeml524-mbs.china.huawei.com> References: <028301cd7cdb$966780a0$c33681e0$@com> <0B2F754289D27B449F7F1B95456B77544EDC4FFE@szxeml524-mbs.china.huawei.com> <002301cd807d$e8d9fd40$ba8df7c0$@com> In-Reply-To: <002301cd807d$e8d9fd40$ba8df7c0$@com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.96] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: 'Stuart Cheshire' Subject: Re: [pcp] strengthening PCP with Mapping Nonce X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 02:02:02 -0000 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Wednesday, August 22, 2012 11:51 PM > To: Zhangzongjian (Thomas); pcp@ietf.org > Cc: 'Stuart Cheshire' > Subject: RE: [pcp] strengthening PCP with Mapping Nonce >=20 > > -----Original Message----- > > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] > > Sent: Wednesday, August 22, 2012 12:59 AM > > To: Dan Wing; pcp@ietf.org > > Cc: 'Stuart Cheshire' > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > > Dear wing > > > > > > > -----Original Message----- > > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > > Dan > > > Wing > > > Sent: Saturday, August 18, 2012 8:51 AM > > > To: pcp@ietf.org > > > Cc: 'Stuart Cheshire' > > > Subject: [pcp] strengthening PCP with Mapping Nonce > > > > > > We incorporated changes to draft-ietf-behave-pcp-base from IESG > > review. > > > > > > After reading the PCP restrictions in REQ-9-A through E in > > > draft-ietf-behave-lsn-requirements-09 (copied below for reference), > > we had a > > > productive phone call this week between Stuart Cheshire, Simon > > Perreault, > > > Sam Hartman, and myself. During that discussion, we found a way to > > > strengthen security of PCP against a specific attack and hopefully > > soften > > > some of the restrictions in both draft-ietf-behave-lsn-requirements > > (REQ-9-A > > > through E) and draft-ietf-pcp-base for the PCP Basic Threat Model, > > when PCP > > > is not using authentication. > > > > > > To achieve this, we need to improve how draft-ietf-pcp-base handles > > Mapping > > > Nonce values. Currently, draft-ietf-pcp-base is pretty silent on how > > and > > > when the PCP client chooses its Mapping Nonce value, and says this > > about > > > server processing, which sort of implies the PCP client is free to > > change > > > the Mapping Nonce value whenever it likes, > > > http://tools.ietf.org/html/draft-ietf-pcp-base-26#section-11.3, > > > > > > The PCP server only needs to remember one Mapping Nonce value for > > > each mapping (that is, the most recent Mapping Nonce value > > overwrites > > > the previous Mapping Nonce value). > > > > > > We would replace the above text with something like: > > > > > > If the Internal port, Protocol, and Internal Address match an > > > existing explicit dynamic mapping, but the Mapping Nonce does not > > > match, the request MUST be rejected with a NOT_AUTHORIZED error > > with > > > the Lifetime of the error indicating duration of that existing > > > mapping. The PCP server only needs to remember one Mapping > Nonce > > > value for each explicit dynamic mapping. > > > > > > with this change (and corresponding text for the PCP client's > > generation of > > > a Mapping Nonce, and corresponding text for PEER), we avoid the > > attack > > > described in detail below. > > > > > > > > > Attack: The attack is a traffic-stealing attack. The diagram below > > may > > > help with the textual description. The attack scenario is where > > there is a > > > CGN running PCP and a home NAT not running PCP, and two hosts on > > separate > > > networks behind the same home NAT. The hosts are on separate > > networks. > > > One > > > host is running a server (the victim) on the wired network, the other > > host > > > is the attacker on the guest Wi-Fi network. The host running the > > server has > > > a mapping created in the NAT, which was created with UPnP IGD or > > created > > > manually, and has a PCP-created mapping in the CGN. The attacker > > uses > > > UPnP > > > IGD, NAT-PMP, STUN (RFC5389), or STUNT > > > (http://nutss.gforge.cis.cornell.edu/stunt.php) to create a mapping > > in the > > > home NAT and learn the home NAT's "WAN" address. The attacker > > > formulates a > > > PCP MAP request with the NAT's WAN address in the PCP Client IP > > Address > > > field, Lifetime=3D0, and sends that to the CGN, deleting the CGN's > > existing > > > mapping that goes to the victim machine. That attack packet is sent > > without > > Thomas=3D> > > Why does not the home NAT use the third party option? >=20 > In the above attack scenario, the home NAT does not support PCP at > all. >=20 > And, if it did, there is no need for THIRD_PARTY if all traffic > is NAT'ed to one IP address, as typically occurs with a residential > NAT. > Thomas=3D> Do you mean that the home NAT does not support PCP client, PCP proxy and up= np-pcp interworking? But, how could the victim host create the MAP entries? As you know the home NAT will change the source IP address of PCP request f= rom hosts. This will result to mis-match with " PCP Client's IP Address" in= PCP request heard. Then PCP server will return an ADDRESS_MISMATCH error = without creating MAP entry. Draft-ietf-pcp-base-26 tells something about mis-match. Below are copied fr= om last paragraph of chart 8.2 for reference. The PCP server compares the source IP address (from the received IP header) with the field PCP Client IP Address. If they do not match, the error ADDRESS_MISMATCH MUST be returned. This is done to detect and prevent accidental use of PCP where a non-PCP-aware NAT exists between the PCP client and PCP server. If the PCP client wants such a mapping it needs to ensure the PCP field matches its apparent IP address from the perspective of the PCP server. =20 > -d >=20 > > When home NAT receives a PCP MAP request with lifetime=3D0 from attacke= r, > > it should add a third party option with the attacker's IP address in > > this option. When CGN gets the PCP request, it will use the third party > > option address as the source address to search the MAP entries. Then > > the attacker can't delete the MAP entry created by victim. > > > > > > > address spoofing. 120 seconds later (per REQ-8 of > > > draft-ietf-behave-lsn-requirements-09), the attacker sends a new PCP > > MAP > > > request to try to acquire the (old) mapping of the victim host. In > > this > > > way, the attacker steals incoming traffic intended to go to the > > victim host. > > > > > > > > > Diagram: > > > > > > +-------------+ +----------+ > > > attacker -------+ | | | > > > (guest network) | | | | > > > | home NAT +----+ CGN +----{Internet} > > > victim ---------+(without PCP)| |(with PCP)| > > > (wired network) | | | | > > > +-------------+ +----------+ > > > > > > > > > Please provide us feedback. I expect to publish -27 soon with these > > > changes, but we are doing some text coordination before publishing - > > 27. > > > > > > -d > > > > > > ----- > > > > > > REQ-9: A CGN MUST implement a protocol giving subscribers > > explicit > > > control over NAT mappings. That protocol SHOULD be the > > Port > > > Control Protocol [I-D.ietf-pcp-base], in which case the > > PCP > > > server MUST obey the following constraints on its > > behavior: > > > > > > A. It MUST NOT permit the lifetime of a mapping to be > > > reduced beyond its current life or be set to zero > > > (deleted). > > > > > > B. It MUST NOT permit a NAT mapping to be created with a > > > lifetime less than the lifetime used for implicit > > > mappings. > > > > > > C. It MUST NOT support the THIRD_PARTY option except > for > > > requests received from "trusted" sources where it is > > > impractical for those sources to be spoofed. > > > > > > D. The MAP opcode MAY be permitted if the > recommendation > > > of > > > endpoint independent filtering behavior described in > > > REQ-7 is adopted; the map opcode MUST NOT be > permitted > > > in > > > other circumstances. These constraints MAY be > relaxed > > if > > > a security mechanism consistent with PCP's Advanced > > > Threat Model (see Section 17.2 of [I-D.ietf-pcp-base]) > > is > > > used; this is expected to be rare for CGN deployments. > > > > > > E. Mappings created by PCP MUST follow the same > > deallocation > > > behavior (REQ-8) as implicitly mapped traffic. > > > > > > > > > _______________________________________________ > > > pcp mailing list > > > pcp@ietf.org > > > https://www.ietf.org/mailman/listinfo/pcp > > > > Best regards > > Thomas From dwing@cisco.com Thu Aug 23 09:49:31 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C6921F857A for ; Thu, 23 Aug 2012 09:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.492 X-Spam-Level: X-Spam-Status: No, score=-110.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnIOMTHi1FW0 for ; Thu, 23 Aug 2012 09:49:30 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 33DA421F8577 for ; Thu, 23 Aug 2012 09:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5968; q=dns/txt; s=iport; t=1345740570; x=1346950170; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=ZLQKvOuQ9bjML70DlmhSnngDRalV6MPwpKX3QrgB9iU=; b=GyHPPeMJZLfQ0qxAbFN8bqZjx0sYKTGUCw91W9QzuhpZWs25EokxisII DmYUzov1qqDrSHkSu8EmpjxfxXxHVahVq77SIn1vV6GQOb2oQmDNK4rsQ fxTQ/j9/nhbjnCVgnp9XPn4gJMyY6t+dLletZ7koboFku/FPN4swGsWhh A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFANVdNlCrRDoG/2dsb2JhbABFqmOPaoEHgiABAQEDAQEBAQUKARcQNAsFBwEDAgkPAgQBASgHGQ4VCgkIAQEEARILDgmHZQUMmU6gQASLCIcRA4hPhQ2WJYFngwM X-IronPort-AV: E=Sophos;i="4.80,301,1344211200"; d="scan'208";a="53298800" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 23 Aug 2012 16:49:28 +0000 Received: from dwingWS (sjc-vpn2-607.cisco.com [10.21.114.95]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7NGnRQZ031531; Thu, 23 Aug 2012 16:49:28 GMT From: "Dan Wing" To: "'Zhangzongjian \(Thomas\)'" , References: <028301cd7cdb$966780a0$c33681e0$@com> <0B2F754289D27B449F7F1B95456B77544EDC4FFE@szxeml524-mbs.china.huawei.com> <002301cd807d$e8d9fd40$ba8df7c0$@com> <0B2F754289D27B449F7F1B95456B77544EDC5131@szxeml524-mbs.china.huawei.com> In-Reply-To: <0B2F754289D27B449F7F1B95456B77544EDC5131@szxeml524-mbs.china.huawei.com> Date: Thu, 23 Aug 2012 09:49:27 -0700 Message-ID: <042601cd814f$421c41c0$c654c540$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1825YgdqnKbKRsQbGswo9PpQX9dgDXgBgwABEHyxAAFIZlwAAfravA Content-Language: en-us Cc: 'Stuart Cheshire' Subject: Re: [pcp] strengthening PCP with Mapping Nonce X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 16:49:31 -0000 > -----Original Message----- > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] > Sent: Wednesday, August 22, 2012 6:59 PM > To: Dan Wing; pcp@ietf.org > Cc: 'Stuart Cheshire' > Subject: RE: [pcp] strengthening PCP with Mapping Nonce ... > Thomas=> > Do you mean that the home NAT does not support PCP client, PCP proxy > and upnp-pcp interworking? Correct -- the home NAT, in this attack scenario, is the home NAT that is currently for sale at the local computer store, which do not support PCP and do not know anything about PCP. > But, how could the victim host create the MAP entries? The victim's host supports PCP in its application (or its operating system), which sends the PCP request to the CGN directly. > As you know the home NAT will change the source IP address of PCP > request from hosts. This will result to mis-match with " PCP Client's > IP Address" in PCP request heard. Then PCP server will return an > ADDRESS_MISMATCH error without creating MAP entry. The PCP client in the (victim) host can overcome that by placing the WAN address of the NAT into the PCP Client IP Address field of the PCP packet. In -27, we have tentatively added: When such an intervening non-PCP-aware inner NAT is detected, mappings must first be created by some other means in the inner NAT, before mappings can be usefully created in the outer PCP-controlled NAT. Having created mappings in the inner NAT by some other means, the PCP client should then use the inner NAT's External Address as the Client IP Address, to signal to the outer PCP-controlled NAT that the client is aware of the inner NAT, and has taken steps to create mappings in it by some other means, so that mappings created in the outer NAT will not be a pointless waste of state. -d > Draft-ietf-pcp-base-26 tells something about mis-match. Below are > copied from last paragraph of chart 8.2 for reference. > > The PCP server compares the source IP address (from the received IP > header) with the field PCP Client IP Address. If they do not match, > the error ADDRESS_MISMATCH MUST be returned. This is done to detect > and prevent accidental use of PCP where a non-PCP-aware NAT exists > between the PCP client and PCP server. If the PCP client wants such > a mapping it needs to ensure the PCP field matches its apparent IP > address from the perspective of the PCP server. > > > > > -d > > > > > When home NAT receives a PCP MAP request with lifetime=0 from > attacker, > > > it should add a third party option with the attacker's IP address > in > > > this option. When CGN gets the PCP request, it will use the third > party > > > option address as the source address to search the MAP entries. > Then > > > the attacker can't delete the MAP entry created by victim. > > > > > > > > > > address spoofing. 120 seconds later (per REQ-8 of > > > > draft-ietf-behave-lsn-requirements-09), the attacker sends a new > PCP > > > MAP > > > > request to try to acquire the (old) mapping of the victim host. > In > > > this > > > > way, the attacker steals incoming traffic intended to go to the > > > victim host. > > > > > > > > > > > > Diagram: > > > > > > > > +-------------+ +----------+ > > > > attacker -------+ | | | > > > > (guest network) | | | | > > > > | home NAT +----+ CGN +----{Internet} > > > > victim ---------+(without PCP)| |(with PCP)| > > > > (wired network) | | | | > > > > +-------------+ +----------+ > > > > > > > > > > > > Please provide us feedback. I expect to publish -27 soon with > these > > > > changes, but we are doing some text coordination before > publishing - > > > 27. > > > > > > > > -d > > > > > > > > ----- > > > > > > > > REQ-9: A CGN MUST implement a protocol giving subscribers > > > explicit > > > > control over NAT mappings. That protocol SHOULD be > the > > > Port > > > > Control Protocol [I-D.ietf-pcp-base], in which case > the > > > PCP > > > > server MUST obey the following constraints on its > > > behavior: > > > > > > > > A. It MUST NOT permit the lifetime of a mapping to be > > > > reduced beyond its current life or be set to zero > > > > (deleted). > > > > > > > > B. It MUST NOT permit a NAT mapping to be created > with a > > > > lifetime less than the lifetime used for implicit > > > > mappings. > > > > > > > > C. It MUST NOT support the THIRD_PARTY option except > > for > > > > requests received from "trusted" sources where it > is > > > > impractical for those sources to be spoofed. > > > > > > > > D. The MAP opcode MAY be permitted if the > > recommendation > > > > of > > > > endpoint independent filtering behavior described > in > > > > REQ-7 is adopted; the map opcode MUST NOT be > > permitted > > > > in > > > > other circumstances. These constraints MAY be > > relaxed > > > if > > > > a security mechanism consistent with PCP's > Advanced > > > > Threat Model (see Section 17.2 of [I-D.ietf-pcp- > base]) > > > is > > > > used; this is expected to be rare for CGN > deployments. > > > > > > > > E. Mappings created by PCP MUST follow the same > > > deallocation > > > > behavior (REQ-8) as implicitly mapped traffic. > > > > > > > > > > > > _______________________________________________ > > > > pcp mailing list > > > > pcp@ietf.org > > > > https://www.ietf.org/mailman/listinfo/pcp > > > > > > Best regards > > > Thomas From zhangzhongjian@huawei.com Fri Aug 24 01:10:27 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4068221F86CB for ; Fri, 24 Aug 2012 01:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDMzeOpzUHns for ; Fri, 24 Aug 2012 01:10:25 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 956FC21F86C8 for ; Fri, 24 Aug 2012 01:10:25 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp03-ep.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AKB00730; Fri, 24 Aug 2012 00:10:25 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Aug 2012 01:06:18 -0700 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Aug 2012 01:06:24 -0700 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.83]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Fri, 24 Aug 2012 16:06:17 +0800 From: "Zhangzongjian (Thomas)" To: Dan Wing , "pcp@ietf.org" Thread-Topic: [pcp] strengthening PCP with Mapping Nonce Thread-Index: Ac1825YgdqnKbKRsQbGswo9PpQX9dgDXgBgwABEHyxAAFIZlwAAfravAAB3rq7A= Date: Fri, 24 Aug 2012 08:06:18 +0000 Message-ID: <0B2F754289D27B449F7F1B95456B77544EDC53B3@szxeml524-mbs.china.huawei.com> References: <028301cd7cdb$966780a0$c33681e0$@com> <0B2F754289D27B449F7F1B95456B77544EDC4FFE@szxeml524-mbs.china.huawei.com> <002301cd807d$e8d9fd40$ba8df7c0$@com> <0B2F754289D27B449F7F1B95456B77544EDC5131@szxeml524-mbs.china.huawei.com> <042601cd814f$421c41c0$c654c540$@com> In-Reply-To: <042601cd814f$421c41c0$c654c540$@com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.96] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: 'Stuart Cheshire' Subject: Re: [pcp] strengthening PCP with Mapping Nonce X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 08:10:27 -0000 > In -27, we have tentatively added: >=20 > When such > an intervening non-PCP-aware inner NAT is detected, mappings must > first be created by some other means in the inner NAT, before > mappings can be usefully created in the outer PCP-controlled NAT. > Having created mappings in the inner NAT by some other means, the PCP > client should then use the inner NAT's External Address as the Client > IP Address, to signal to the outer PCP-controlled NAT that the client > is aware of the inner NAT, and has taken steps to create mappings in > it by some other means, so that mappings created in the outer NAT > will not be a pointless waste of state. > Dear Wing I think I understand your proposal, but there still are some questions. 1. How did PCP client (host) detect that there are two levels NAT (Inner NA= T and Out NAT)? PCP client need to know this first of all. How could the PCP client know the inner NAT is an unsupported PCP device.= If inner NAT supports PCP, it will find the PCP request is a malformed pa= cket. It may discard the packet as the error packet or packet from an attac= ker. PCP client also need to know the Out NAT support PCP. 2. You said that " mappings must first be created by some other means in th= e inner NAT". What is the means? Manually or dynamically? I am afraid there will be a coincident lifetime problem. For example the = lifetime of MAP in Out NAT is 12 hour, but the lifetime of MAP in inner NAT= is 1 hour. What will happen when inner NAT MAP's lifetime expired. 3. The Inner NAT function on CPE may be shut down for some reasons, how cou= ld the PCP client know the dynamic change on CPE? 4.How could the PCP client know the external IP address on inner NAT?=20 5.Is it possible that there are more than one external IP address (maybe a = private IP address) on inner NAT external Pool? For example, different exte= rnal IP for different service. Regards Thomas > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Friday, August 24, 2012 12:49 AM > To: Zhangzongjian (Thomas); pcp@ietf.org > Cc: 'Stuart Cheshire' > Subject: RE: [pcp] strengthening PCP with Mapping Nonce >=20 > > -----Original Message----- > > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] > > Sent: Wednesday, August 22, 2012 6:59 PM > > To: Dan Wing; pcp@ietf.org > > Cc: 'Stuart Cheshire' > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > ... > > Thomas=3D> > > Do you mean that the home NAT does not support PCP client, PCP proxy > > and upnp-pcp interworking? >=20 >=20 > Correct -- the home NAT, in this attack scenario, is the home NAT > that is currently for sale at the local computer store, which do > not support PCP and do not know anything about PCP. >=20 >=20 > > But, how could the victim host create the MAP entries? >=20 > The victim's host supports PCP in its application (or its > operating system), which sends the PCP request to the CGN > directly. >=20 >=20 > > As you know the home NAT will change the source IP address of PCP > > request from hosts. This will result to mis-match with " PCP Client's > > IP Address" in PCP request heard. Then PCP server will return an > > ADDRESS_MISMATCH error without creating MAP entry. >=20 > The PCP client in the (victim) host can overcome that by placing the > WAN address of the NAT into the PCP Client IP Address field of the > PCP packet. >=20 > In -27, we have tentatively added: >=20 > When such > an intervening non-PCP-aware inner NAT is detected, mappings must > first be created by some other means in the inner NAT, before > mappings can be usefully created in the outer PCP-controlled NAT. > Having created mappings in the inner NAT by some other means, the PCP > client should then use the inner NAT's External Address as the Client > IP Address, to signal to the outer PCP-controlled NAT that the client > is aware of the inner NAT, and has taken steps to create mappings in > it by some other means, so that mappings created in the outer NAT > will not be a pointless waste of state. >=20 > -d >=20 >=20 > > Draft-ietf-pcp-base-26 tells something about mis-match. Below are > > copied from last paragraph of chart 8.2 for reference. > > > > The PCP server compares the source IP address (from the received IP > > header) with the field PCP Client IP Address. If they do not match, > > the error ADDRESS_MISMATCH MUST be returned. This is done to > detect > > and prevent accidental use of PCP where a non-PCP-aware NAT exists > > between the PCP client and PCP server. If the PCP client wants such > > a mapping it needs to ensure the PCP field matches its apparent IP > > address from the perspective of the PCP server. > > > > > > > > > -d > > > > > > > When home NAT receives a PCP MAP request with lifetime=3D0 from > > attacker, > > > > it should add a third party option with the attacker's IP address > > in > > > > this option. When CGN gets the PCP request, it will use the third > > party > > > > option address as the source address to search the MAP entries. > > Then > > > > the attacker can't delete the MAP entry created by victim. > > > > > > > > > > > > > address spoofing. 120 seconds later (per REQ-8 of > > > > > draft-ietf-behave-lsn-requirements-09), the attacker sends a new > > PCP > > > > MAP > > > > > request to try to acquire the (old) mapping of the victim host. > > In > > > > this > > > > > way, the attacker steals incoming traffic intended to go to the > > > > victim host. > > > > > > > > > > > > > > > Diagram: > > > > > > > > > > +-------------+ +----------+ > > > > > attacker -------+ | | | > > > > > (guest network) | | | | > > > > > | home NAT +----+ CGN > +----{Internet} > > > > > victim ---------+(without PCP)| |(with PCP)| > > > > > (wired network) | | | | > > > > > +-------------+ +----------+ > > > > > > > > > > > > > > > Please provide us feedback. I expect to publish -27 soon with > > these > > > > > changes, but we are doing some text coordination before > > publishing - > > > > 27. > > > > > > > > > > -d > > > > > > > > > > ----- > > > > > > > > > > REQ-9: A CGN MUST implement a protocol giving subscribers > > > > explicit > > > > > control over NAT mappings. That protocol SHOULD be > > the > > > > Port > > > > > Control Protocol [I-D.ietf-pcp-base], in which case > > the > > > > PCP > > > > > server MUST obey the following constraints on its > > > > behavior: > > > > > > > > > > A. It MUST NOT permit the lifetime of a mapping to be > > > > > reduced beyond its current life or be set to zero > > > > > (deleted). > > > > > > > > > > B. It MUST NOT permit a NAT mapping to be created > > with a > > > > > lifetime less than the lifetime used for implicit > > > > > mappings. > > > > > > > > > > C. It MUST NOT support the THIRD_PARTY option > except > > > for > > > > > requests received from "trusted" sources where it > > is > > > > > impractical for those sources to be spoofed. > > > > > > > > > > D. The MAP opcode MAY be permitted if the > > > recommendation > > > > > of > > > > > endpoint independent filtering behavior described > > in > > > > > REQ-7 is adopted; the map opcode MUST NOT be > > > permitted > > > > > in > > > > > other circumstances. These constraints MAY be > > > relaxed > > > > if > > > > > a security mechanism consistent with PCP's > > Advanced > > > > > Threat Model (see Section 17.2 of [I-D.ietf-pcp- > > base]) > > > > is > > > > > used; this is expected to be rare for CGN > > deployments. > > > > > > > > > > E. Mappings created by PCP MUST follow the same > > > > deallocation > > > > > behavior (REQ-8) as implicitly mapped traffic. > > > > > > > > > > > > > > > _______________________________________________ > > > > > pcp mailing list > > > > > pcp@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/pcp > > > > > > > > Best regards > > > > Thomas From dxhbupt@gmail.com Fri Aug 24 05:47:25 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E343D21F86C7 for ; Fri, 24 Aug 2012 05:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xw3w2e7RhM5K for ; Fri, 24 Aug 2012 05:47:25 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A2BCE21F8501 for ; Fri, 24 Aug 2012 05:47:24 -0700 (PDT) Received: by lahm15 with SMTP id m15so1165413lah.31 for ; Fri, 24 Aug 2012 05:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=auR/hMX6kgbWm8JMQebBCyMSgw8OpFWQ8vOjlGjxwVc=; b=VXFoM+Wpfqlg50fT2QVs50OkJDrgWE01xZGmancpzmPKw0sROOPcS+BdETDI4p04UX mYe+/lfZLVTm5D0fniSL9gviao2wgUDqCdKxGLBJ33/jRnpq5bW73tz6DZp+VYMDPP0r 19ZuiLWPGiPqMLwK3dUzmRuQb3a2Ksb9zNWHpRP5VLDUTmU7Er5Tn+xs9e9Tknt8UHja KX6T+7RCJcNfs2X8j/3cXWfniNSlh86IJeZFqj2cKkBG3Ziu16qfMSCNvjlkvwTrQSf+ RkAKloRxJZZz6A9hHJs+fGp59zsKmWmcymjDq861e7Omgn7Xk7ry1lvIZJ9QX5/3o+9B fBiQ== MIME-Version: 1.0 Received: by 10.152.46.209 with SMTP id x17mr5502033lam.38.1345812443435; Fri, 24 Aug 2012 05:47:23 -0700 (PDT) Received: by 10.112.43.196 with HTTP; Fri, 24 Aug 2012 05:47:23 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E512B4463@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E4FC2DA35@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E512B4463@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 24 Aug 2012 14:47:23 +0200 Message-ID: From: Xiaohong Deng To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=bcaec550b3aea0110604c8026013 Cc: "pcp@ietf.org" , "draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org" Subject: Re: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 12:47:26 -0000 --bcaec550b3aea0110604c8026013 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Med, I prefer the wording in your explanation: only "1" is allowed: i.e., the iwf is supposed to send back an error if not set to 0. Cheers, Xiaohong On Fri, Aug 17, 2012 at 4:15 PM, wrote: > ** > Hi Xiaohong, > > The current text says only "1" is allowed: i.e., the iwf is supposed to > send back an error if not set to 0. > > If you have a better wording, this is welcome. > > Cheers, > Med > > ------------------------------ > *De :* Xiaohong Deng [mailto:dxhbupt@gmail.com] > *Envoy=E9 :* vendredi 17 ao=FBt 2012 15:50 > *=C0 :* draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org; pcp@ietf.org= ; > BOUCADAIR Mohamed OLNC/NAD/TIP > *Objet :* Re: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking > > Hi Med, > > Thanks for your efficient feedback. > > Please see inline. Now focus only on unsolved ones. > > On Thu, Aug 16, 2012 at 10:24 AM, wrote: > >> ** >> >> PortMappingEnabled: >> PCP does not support deactivating the dynamic NAT mapping since >> the initial goal of PCP is to ease the traversal of Carrier Grade >> NAT. Supporting such per-subscriber function may overload the >> Carrier Grade NAT. >> + What if the customer wants to deactivate a static NAT mappings on CGN? >> it is not stated clearly that IWF should support it or not. My reading h= ere >> is that for the same reason: not to overload the carrier Grade NAT, it >> should not support deactivate static mappings either. IMO,it=92s worth t= o >> state clearer that it applys to both static and dynamic mappings, if tha= t >> is what text here means. >> [Med] IGD spec says "PortMappingEnabled: This variable allows security >> conscious users to disable and enable dynamic NAT port mappings on the I= GD.". PCP >> does not provide such feature. >> >> >> Je sais. That's why I asked, and please see below . > >> >> >> >> On reading the value is 1, writing a value different from 1 is not >> supported. >> + what if on reading the value is 0, which means deactivating the mappin= g? >> [Med] see above. Only "1" is supported. >> >> Here, I elaborate the question again. > > Quotation from UPnP-gw-WANIPConnection-v2-Service spcification: > > "Arguments for AddPortMapping() and AddAnyPortMapping() : > > *Argument Direction relatedStateVariable* > ... > NewEnabled IN PortMappingEnabled > ..." > > My concern was and is: with the current text, it doesn't look clear to me= , > how IGD should react when recieve a PortMappingEnabled valule of '0' from > these two actions, which means that users want to disable the mapping. > > > "Arguments for GetGenericPortMappingEntry() GetGenericPortMappingEntry() > *Argument Direction relatedStateVariable* > ... > NewEnabled OUT PortMappingEnabled > ..." > > Don't see any problems for IGD with actions (Get*) having this parameter > for OUT direction. > > > > [Med] Are you sure 718 error code is allowed for >> GetSpecificPortMappingEntry? >> >> Good point. According to specification, no. > p.s. But I think anyway it would be interesting to do a test to see what > will happen in that case. Come back to you soon later with the test resul= ts. > > Cheers, > Xiaohong > > > --bcaec550b3aea0110604c8026013 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Med,

I prefer the wording in your explanation:=A0

<= font color=3D"#0000ff" face=3D"Courier New">only "1" is allowed: = i.e., the=20 iwf is supposed to send back an error if not set to 0.

Cheers,
Xi= aohong

On Fri, Aug 17, 2012= at 4:15 PM, <mohamed.boucadair@orange.com> wrot= e:
Hi Xiaohong,
=A0
The current text says only "1" is allowed: i.e., the=20 iwf is supposed to send back an error if not set to 0.
=A0
If you have a better wording, this is=20 welcome.
=A0
Cheers,
Med

De=A0: Xiaohong Deng=20 [mailto:dxhbupt@gm= ail.com]
Envoy=E9=A0: vendredi 17 ao=FBt 2012=20 15:50
=C0=A0: draft-ietf-pcp-upnp-igd-interworkin= g@tools.ietf.org;=20 pcp@ietf.org; BOUCA= DAIR Mohamed OLNC/NAD/TIP
Objet=A0: Re: [pcp]=20 Review of draft-ietf-pcp-upnp-igd-interworking

<= div class=3D"h5">
Hi Med,

Thanks for your efficient=20 feedback.

Please see inline. Now focus only on unsolved ones.
<= br>
On Thu, Aug 16, 2012 at 10:24 AM, <mohamed.boucadair@ora= nge.com> wrote:
=A0=A0 PortMappingEnabled:
=A0=A0=A0=A0=A0=20 PCP does not support deactivating the dynamic NAT mapping=20 since
=A0=A0=A0=A0=A0 the initial goal of PCP is to ease=20 the traversal of Carrier Grade
=A0=A0=A0=A0=A0=20 NAT.=A0 Supporting such per-subscriber function may overload=20 the
=A0=A0=A0=A0=A0 Carrier Grade NAT.
+ What if the=20 customer wants to deactivate a static NAT mappings on CGN? it is not= =20 stated clearly that IWF should support it or not. My reading here is = that=20 for the same reason: not to overload the carrier Grade NAT, it should= not=20 support deactivate static mappings either. IMO,it=92s worth to state = clearer=20 that it applys to both static and dynamic mappings, if that is what t= ext=20 here means.
[Med]=A0IGD s= pec says=20 "PortMappingEnabled: This variable allows secu= rity conscious=20 users to disable and enable dynamic NAT port mappings on the=20 IGD.".=A0PCP does not provide such=20 feature.=A0

Je sais. That's why I asked, and please see below .



=A0=A0=A0=A0=A0 On reading the value is 1,=20 writing a value different from 1 is not
=A0=A0=A0=A0=A0=20 supported.
+ what if on reading the value is 0, which means=20 deactivating the mapping?
[Med]=A0see above. Only "1" is supported.=20 =A0
Here, I elaborate the question again.

Quotation from=20 UPnP-gw-WANIPConnection-v2-Service spcification:

"Arguments f= or=20 AddPortMapping() and AddAnyPortMapping()=20 :

*Argument=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=20 Direction=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 relatedStateVariable*
...
NewEnabled=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=20 IN=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 PortMappingEnabled
..."

My concern was and is: with the cu= rrent=20 text, it doesn't look clear to me, how IGD should react when recieve = a=20 PortMappingEnabled valule of '0' from these two actions, which me= ans that=20 users want to disable the mapping.


"Arguments for=20 GetGenericPortMappingEntry()=20 GetGenericPortMappingEntry()
*Argument=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 Direction=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 relatedStateVariable*
...
=A0NewEnabled=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=20 OUT=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20 PortMappingEnabled
..."

Don't see any problems for IGD= with=20 actions=A0 (Get*) having this parameter for OUT=20 direction.



[Med] Are you= sure=20 718=A0error code is allowed for=20 GetSpecificPortMappingEntry?=A0
Good point. According to specification, no.
p.s. But I think anyw= ay it=20 would be interesting to do a test to see what will happen in that case. C= ome=20 back to you soon later with the test=20 results.

Cheers,
Xiaohong



--bcaec550b3aea0110604c8026013-- From mohamed.boucadair@orange.com Fri Aug 24 08:47:29 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC27E21F86C5 for ; Fri, 24 Aug 2012 08:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, SARE_SUB_RAND_LETTRS4=0.799, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mA1oe4HWyTqJ for ; Fri, 24 Aug 2012 08:47:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 73EAA21F8710 for ; Fri, 24 Aug 2012 08:47:28 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 9539F26475A; Fri, 24 Aug 2012 17:47:27 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 5BF0927C054; Fri, 24 Aug 2012 17:47:27 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 24 Aug 2012 17:47:05 +0200 From: To: Xiaohong Deng Date: Fri, 24 Aug 2012 17:47:03 +0200 Thread-Topic: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking Thread-Index: Ac2B9o9t5rxM1IRtQqaV2bqKwDuD9QAGRI+w Message-ID: <94C682931C08B048B7A8645303FDC9F36E5332AAF7@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E4FC2DA35@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E512B4463@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E5332AAF7PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.24.150316 Cc: "pcp@ietf.org" , "draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org" Subject: Re: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 15:47:29 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E5332AAF7PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Xiaohong, Ok, done. Thank you for the review. Cheers, Med ________________________________ De : Xiaohong Deng [mailto:dxhbupt@gmail.com] Envoy=E9 : vendredi 24 ao=FBt 2012 14:47 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org; pcp@ietf.org Objet : Re: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking Hi Med, I prefer the wording in your explanation: only "1" is allowed: i.e., the iwf is supposed to send back an error if not= set to 0. Cheers, Xiaohong On Fri, Aug 17, 2012 at 4:15 PM, > wrote: Hi Xiaohong, The current text says only "1" is allowed: i.e., the iwf is supposed to sen= d back an error if not set to 0. If you have a better wording, this is welcome. Cheers, Med ________________________________ De : Xiaohong Deng [mailto:dxhbupt@gmail.com] Envoy=E9 : vendredi 17 ao=FBt 2012 15:50 =C0 : draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org; pcp@ietf.org; BOUCADAIR Mohamed OLNC/NAD/TIP Objet : Re: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking Hi Med, Thanks for your efficient feedback. Please see inline. Now focus only on unsolved ones. On Thu, Aug 16, 2012 at 10:24 AM, > wrote: PortMappingEnabled: PCP does not support deactivating the dynamic NAT mapping since the initial goal of PCP is to ease the traversal of Carrier Grade NAT. Supporting such per-subscriber function may overload the Carrier Grade NAT. + What if the customer wants to deactivate a static NAT mappings on CGN? it= is not stated clearly that IWF should support it or not. My reading here i= s that for the same reason: not to overload the carrier Grade NAT, it shoul= d not support deactivate static mappings either. IMO,it's worth to state cl= earer that it applys to both static and dynamic mappings, if that is what t= ext here means. [Med] IGD spec says "PortMappingEnabled: This variable allows security cons= cious users to disable and enable dynamic NAT port mappings on the IGD.". P= CP does not provide such feature. Je sais. That's why I asked, and please see below . On reading the value is 1, writing a value different from 1 is not supported. + what if on reading the value is 0, which means deactivating the mapping? [Med] see above. Only "1" is supported. Here, I elaborate the question again. Quotation from UPnP-gw-WANIPConnection-v2-Service spcification: "Arguments for AddPortMapping() and AddAnyPortMapping() : *Argument Direction relatedStateVariable* ... NewEnabled IN PortMappingEnabled ..." My concern was and is: with the current text, it doesn't look clear to me, = how IGD should react when recieve a PortMappingEnabled valule of '0' from t= hese two actions, which means that users want to disable the mapping. "Arguments for GetGenericPortMappingEntry() GetGenericPortMappingEntry() *Argument Direction relatedStateVariable* ... NewEnabled OUT PortMappingEnabled ..." Don't see any problems for IGD with actions (Get*) having this parameter f= or OUT direction. [Med] Are you sure 718 error code is allowed for GetSpecificPortMappingEntr= y? Good point. According to specification, no. p.s. But I think anyway it would be interesting to do a test to see what wi= ll happen in that case. Come back to you soon later with the test results. Cheers, Xiaohong --_000_94C682931C08B048B7A8645303FDC9F36E5332AAF7PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Xiaohong,
 
Ok, done.
 
Thank you for the review.
 
Cheers,
Med

De : Xiaohong Deng=20 [mailto:dxhbupt@gmail.com]
Envoy=E9 : vendredi 24 ao=FBt = 2012=20 14:47
=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc := =20 draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org;=20 pcp@ietf.org
Objet : Re: [pcp] Review of=20 draft-ietf-pcp-upnp-igd-interworking

Hi Med,

I prefer the wording in your explanation: = =20

only "1" is allo= wed:=20 i.e., the iwf is supposed to send back an error if not set to=20 0.

Cheers,
Xiaohong

On Fri, Aug 17, 2012 at 4:15 PM, <mohamed.boucadair@orange.com> wrote:
Hi=20 Xiaohong,
 
The=20 current text says only "1" is allowed: i.e., the iwf is supposed to sen= d=20 back an error if not set to 0.
 
If you=20 have a better wording, this is welcome.
 
Cheers,
Med

De : Xiaohong Deng [mailto:dxhbupt@gmail.com]=20
Envoy=E9 : vendredi 17 ao=FBt 2012 15:50
=C0&nb= sp;: draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org; pcp@ietf.org; BOUCAD= AIR=20 Mohamed OLNC/NAD/TIP
Objet : Re: [pcp] Review of=20 draft-ietf-pcp-upnp-igd-interworking

Hi Med,

Thanks for your efficient=20 feedback.

Please see inline. Now focus only on unsolved=20 ones.

On Thu, Aug 16, 2012 at 10:24 AM, <mohamed.boucadair@orange.com> wrote:
  =20 PortMappingEnabled:
      PCP does no= t=20 support deactivating the dynamic NAT mapping=20 since
      the initial goal of PCP i= s to=20 ease the traversal of Carrier Grade
    &n= bsp;=20 NAT.  Supporting such per-subscriber function may overload=20 the
      Carrier Grade NAT.
+ Wha= t if=20 the customer wants to deactivate a static NAT mappings on CGN? it= is=20 not stated clearly that IWF should support it or not. My reading = here=20 is that for the same reason: not to overload the carrier Grade NA= T, it=20 should not support deactivate static mappings either. IMO,it=92s = worth=20 to state clearer that it applys to both static and dynamic mappin= gs,=20 if that is what text here means.
[Med] = IGD spec=20 says "PortMappingEnabled: This variable allows se= curity=20 conscious users to disable and enable dynamic NAT port mappings o= n the=20 IGD.". PCP does not provide such=20 feature. 

Je sais. That's why I asked, and please see below .



      On reading the va= lue=20 is 1, writing a value different from 1 is=20 not
      supported.
+ what if on= =20 reading the value is 0, which means deactivating the=20 mapping?
[Med] see above. Only "1" is supported.= =20  
Here, I elaborate the question again.

Quotation from=20 UPnP-gw-WANIPConnection-v2-Service spcification:

"Arguments fo= r=20 AddPortMapping() and AddAnyPortMapping()=20 :

*Argument        &nb= sp;            =  =20 Direction          = =20 relatedStateVariable*
...
NewEnabled    &nb= sp;            =  =20 IN           &= nbsp;         =20 PortMappingEnabled
..."

My concern was and is: with the cur= rent=20 text, it doesn't look clear to me, how IGD should react when recieve = a=20 PortMappingEnabled valule of '0' from these two actions, which means = that=20 users want to disable the mapping.


"Arguments for=20 GetGenericPortMappingEntry()=20 GetGenericPortMappingEntry()
*Argument    &nbs= p;            &= nbsp;    =20 Direction          = =20 relatedStateVariable*
...
 NewEnabled   &nb= sp;            =   =20 OUT           =       =20 PortMappingEnabled
..."

Don't see any problems for IGD with= =20 actions  (Get*) having this parameter for OUT=20 direction.



[Med] Are y= ou sure=20 718 error code is allowed for=20 GetSpecificPortMappingEntry? 
Good point. According to specification, no.
p.s. But I think= =20 anyway it would be interesting to do a test to see what will happen i= n=20 that case. Come back to you soon later with the test=20 results.

Cheers,
Xiaohong



--_000_94C682931C08B048B7A8645303FDC9F36E5332AAF7PUEXCB1Bnante_-- From dwing@cisco.com Fri Aug 24 09:19:26 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1073C21F858F for ; Fri, 24 Aug 2012 09:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.494 X-Spam-Level: X-Spam-Status: No, score=-110.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-qB6fo5iuha for ; Fri, 24 Aug 2012 09:19:24 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id D6F4721F8585 for ; Fri, 24 Aug 2012 09:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=10997; q=dns/txt; s=iport; t=1345825164; x=1347034764; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=jZepUy7FbPX20lig/oiEK7mTXyDueYfnvOHVOZYQxps=; b=AyPGuRHmgsmIEpDi8SP+e2PKFbhGRoWZBzP44zKrGFuacv6piHRKNRs5 rqBV7bf1CAskO+3uNmB7enO7GgBt79pSISS45BWOlXPVibunEP/v1cLv4 nt+A1jLIMjpPqAIxUVFwrq6qOa4DjFuLVw+d7zwqB0xd1vr7N9FOq5koO k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAIqoN1CrRDoJ/2dsb2JhbABFqmqPeoEHgiABAQEDAQEBAQUKARcQLQcLBQcBAwIJDwICAgEBKAcZDhUKCQgCBAESCw4Jh2UFDJkloB+LCIcRA4hPhQ2WJoFngwM X-IronPort-AV: E=Sophos;i="4.80,304,1344211200"; d="scan'208";a="53417092" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 24 Aug 2012 16:19:24 +0000 Received: from dwingWS (sjc-vpn2-607.cisco.com [10.21.114.95]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7OGJNsb020303; Fri, 24 Aug 2012 16:19:24 GMT From: "Dan Wing" To: "'Zhangzongjian \(Thomas\)'" , References: <028301cd7cdb$966780a0$c33681e0$@com> <0B2F754289D27B449F7F1B95456B77544EDC4FFE@szxeml524-mbs.china.huawei.com> <002301cd807d$e8d9fd40$ba8df7c0$@com> <0B2F754289D27B449F7F1B95456B77544EDC5131@szxeml524-mbs.china.huawei.com> <042601cd814f$421c41c0$c654c540$@com> <0B2F754289D27B449F7F1B95456B77544EDC53B3@szxeml524-mbs.china.huawei.com> In-Reply-To: <0B2F754289D27B449F7F1B95456B77544EDC53B3@szxeml524-mbs.china.huawei.com> Date: Fri, 24 Aug 2012 09:19:23 -0700 Message-ID: <07c901cd8214$39a4c970$acee5c50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1825YgdqnKbKRsQbGswo9PpQX9dgDXgBgwABEHyxAAFIZlwAAfravAAB3rq7AAEybCEA== Content-Language: en-us Cc: 'Stuart Cheshire' Subject: Re: [pcp] strengthening PCP with Mapping Nonce X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 16:19:26 -0000 > -----Original Message----- > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] > Sent: Friday, August 24, 2012 1:06 AM > To: Dan Wing; pcp@ietf.org > Cc: 'Stuart Cheshire' > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > In -27, we have tentatively added: > > > > When such > > an intervening non-PCP-aware inner NAT is detected, mappings must > > first be created by some other means in the inner NAT, before > > mappings can be usefully created in the outer PCP-controlled NAT. > > Having created mappings in the inner NAT by some other means, the > PCP > > client should then use the inner NAT's External Address as the > Client > > IP Address, to signal to the outer PCP-controlled NAT that the > client > > is aware of the inner NAT, and has taken steps to create mappings > in > > it by some other means, so that mappings created in the outer NAT > > will not be a pointless waste of state. > > > > Dear Wing > > I think I understand your proposal, but there still are some questions. > > 1. How did PCP client (host) detect that there are two levels NAT > (Inner NAT and Out NAT)? PCP client need to know this first of all. It can use UPnP IGD, NAT-PMP, or HTTP screen-scraping to communicate with the in-home residential NAT and get a mapping. Then, it can use traceroute or some other technique to learn the internal IP address of the CGN, and send it a PCP request. > How could the PCP client know the inner NAT is an unsupported PCP > device. It doesn't know, and it doesn't care if the in-home residential NAT supports PCP or not. The attack works as long as the in-home residential NAT allows the PCP request from the attacker's IP address to the CGN's PCP server address. > If inner NAT supports PCP, it will find the PCP request is a > malformed packet. It may discard the packet as the error packet or > packet from an attacker. In the attack scenario, the in-home residential NAT ('inner NAT') does not support PCP. And, even if it did, the attacker's PCP packet is not being sent to the in-home residential NAT -- the attacker's PCP packet has a destination address that is the PCP server in the ISP's network (the CGN). > PCP client also need to know the Out NAT support PCP. Yes, the attack is a PCP attack, and relies on the CGN supporting PCP. > 2. You said that " mappings must first be created by some other means > in the inner NAT". What is the means? Manually or dynamically? Any of these would work: (a) UPnP IGD, (b) NAT-PMP, (c) screen- scraping HTTP to the NAT's HTTP server, or (d) a human reading the CLI or HTTP of the NAT and manually configuring the host to send the proper PCP message. > I am afraid there will be a coincident lifetime problem. For example > the lifetime of MAP in Out NAT is 12 hour, but the lifetime of MAP in > inner NAT is 1 hour. What will happen when inner NAT MAP's lifetime > expired. The lifetime of the mapping in the in-home residential NAT doesn't matter for this attack. > 3. The Inner NAT function on CPE may be shut down for some reasons, how > could the PCP client know the dynamic change on CPE? If the in-home residential NAT is bridging (and is not a NAT), this PCP attack is not possible. > 4.How could the PCP client know the external IP address on inner NAT? UPnP IGD, NAT-PMP, or screen-scraping the HTTP, or a human reading the CLI or HTTP. > 5.Is it possible that there are more than one external IP address > (maybe a private IP address) on inner NAT external Pool? For example, > different external IP for different service. If the victim and the attacker have different IP addresses, from the perspective of the carrier's PCP server, this specific PCP attack is not possible. That occurs if the in-home residential CPE is not NATing (as described in (3)) or if separate IP addresses are assigned to each possible attack & victim host pair. -d > Regards > Thomas > > > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Friday, August 24, 2012 12:49 AM > > To: Zhangzongjian (Thomas); pcp@ietf.org > > Cc: 'Stuart Cheshire' > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > > > -----Original Message----- > > > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] > > > Sent: Wednesday, August 22, 2012 6:59 PM > > > To: Dan Wing; pcp@ietf.org > > > Cc: 'Stuart Cheshire' > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > ... > > > Thomas=> > > > Do you mean that the home NAT does not support PCP client, PCP > proxy > > > and upnp-pcp interworking? > > > > > > Correct -- the home NAT, in this attack scenario, is the home NAT > > that is currently for sale at the local computer store, which do > > not support PCP and do not know anything about PCP. > > > > > > > But, how could the victim host create the MAP entries? > > > > The victim's host supports PCP in its application (or its > > operating system), which sends the PCP request to the CGN > > directly. > > > > > > > As you know the home NAT will change the source IP address of PCP > > > request from hosts. This will result to mis-match with " PCP > Client's > > > IP Address" in PCP request heard. Then PCP server will return an > > > ADDRESS_MISMATCH error without creating MAP entry. > > > > The PCP client in the (victim) host can overcome that by placing the > > WAN address of the NAT into the PCP Client IP Address field of the > > PCP packet. > > > > In -27, we have tentatively added: > > > > When such > > an intervening non-PCP-aware inner NAT is detected, mappings must > > first be created by some other means in the inner NAT, before > > mappings can be usefully created in the outer PCP-controlled NAT. > > Having created mappings in the inner NAT by some other means, the > PCP > > client should then use the inner NAT's External Address as the > Client > > IP Address, to signal to the outer PCP-controlled NAT that the > client > > is aware of the inner NAT, and has taken steps to create mappings > in > > it by some other means, so that mappings created in the outer NAT > > will not be a pointless waste of state. > > > > -d > > > > > > > Draft-ietf-pcp-base-26 tells something about mis-match. Below are > > > copied from last paragraph of chart 8.2 for reference. > > > > > > The PCP server compares the source IP address (from the received IP > > > header) with the field PCP Client IP Address. If they do not > match, > > > the error ADDRESS_MISMATCH MUST be returned. This is done to > > detect > > > and prevent accidental use of PCP where a non-PCP-aware NAT > exists > > > between the PCP client and PCP server. If the PCP client wants > such > > > a mapping it needs to ensure the PCP field matches its apparent > IP > > > address from the perspective of the PCP server. > > > > > > > > > > > > > -d > > > > > > > > > When home NAT receives a PCP MAP request with lifetime=0 from > > > attacker, > > > > > it should add a third party option with the attacker's IP > address > > > in > > > > > this option. When CGN gets the PCP request, it will use the > third > > > party > > > > > option address as the source address to search the MAP entries. > > > Then > > > > > the attacker can't delete the MAP entry created by victim. > > > > > > > > > > > > > > > > address spoofing. 120 seconds later (per REQ-8 of > > > > > > draft-ietf-behave-lsn-requirements-09), the attacker sends a > new > > > PCP > > > > > MAP > > > > > > request to try to acquire the (old) mapping of the victim > host. > > > In > > > > > this > > > > > > way, the attacker steals incoming traffic intended to go to > the > > > > > victim host. > > > > > > > > > > > > > > > > > > Diagram: > > > > > > > > > > > > +-------------+ +----------+ > > > > > > attacker -------+ | | | > > > > > > (guest network) | | | | > > > > > > | home NAT +----+ CGN > > +----{Internet} > > > > > > victim ---------+(without PCP)| |(with PCP)| > > > > > > (wired network) | | | | > > > > > > +-------------+ +----------+ > > > > > > > > > > > > > > > > > > Please provide us feedback. I expect to publish -27 soon > with > > > these > > > > > > changes, but we are doing some text coordination before > > > publishing - > > > > > 27. > > > > > > > > > > > > -d > > > > > > > > > > > > ----- > > > > > > > > > > > > REQ-9: A CGN MUST implement a protocol giving subscribers > > > > > explicit > > > > > > control over NAT mappings. That protocol SHOULD > be > > > the > > > > > Port > > > > > > Control Protocol [I-D.ietf-pcp-base], in which > case > > > the > > > > > PCP > > > > > > server MUST obey the following constraints on its > > > > > behavior: > > > > > > > > > > > > A. It MUST NOT permit the lifetime of a mapping > to be > > > > > > reduced beyond its current life or be set to > zero > > > > > > (deleted). > > > > > > > > > > > > B. It MUST NOT permit a NAT mapping to be created > > > with a > > > > > > lifetime less than the lifetime used for > implicit > > > > > > mappings. > > > > > > > > > > > > C. It MUST NOT support the THIRD_PARTY option > > except > > > > for > > > > > > requests received from "trusted" sources where > it > > > is > > > > > > impractical for those sources to be spoofed. > > > > > > > > > > > > D. The MAP opcode MAY be permitted if the > > > > recommendation > > > > > > of > > > > > > endpoint independent filtering behavior > described > > > in > > > > > > REQ-7 is adopted; the map opcode MUST NOT be > > > > permitted > > > > > > in > > > > > > other circumstances. These constraints MAY be > > > > relaxed > > > > > if > > > > > > a security mechanism consistent with PCP's > > > Advanced > > > > > > Threat Model (see Section 17.2 of [I-D.ietf- > pcp- > > > base]) > > > > > is > > > > > > used; this is expected to be rare for CGN > > > deployments. > > > > > > > > > > > > E. Mappings created by PCP MUST follow the same > > > > > deallocation > > > > > > behavior (REQ-8) as implicitly mapped traffic. > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > pcp mailing list > > > > > > pcp@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/pcp > > > > > > > > > > Best regards > > > > > Thomas From zhangzhongjian@huawei.com Fri Aug 24 19:26:47 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C658321F85A1 for ; Fri, 24 Aug 2012 19:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGSwV3sgU78u for ; Fri, 24 Aug 2012 19:26:46 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6182621F8539 for ; Fri, 24 Aug 2012 19:26:46 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp01-ep.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id ALE00699; Fri, 24 Aug 2012 18:26:46 -0800 (PST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Aug 2012 19:22:10 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 24 Aug 2012 19:22:07 -0700 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.83]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Sat, 25 Aug 2012 10:22:05 +0800 From: "Zhangzongjian (Thomas)" To: Dan Wing , "pcp@ietf.org" Thread-Topic: [pcp] strengthening PCP with Mapping Nonce Thread-Index: Ac1825YgdqnKbKRsQbGswo9PpQX9dgDXgBgwABEHyxAAFIZlwAAfravAAB3rq7AAEybCEAARu6pw Date: Sat, 25 Aug 2012 02:22:04 +0000 Message-ID: <0B2F754289D27B449F7F1B95456B77544EDC558E@szxeml524-mbs.china.huawei.com> References: <028301cd7cdb$966780a0$c33681e0$@com> <0B2F754289D27B449F7F1B95456B77544EDC4FFE@szxeml524-mbs.china.huawei.com> <002301cd807d$e8d9fd40$ba8df7c0$@com> <0B2F754289D27B449F7F1B95456B77544EDC5131@szxeml524-mbs.china.huawei.com> <042601cd814f$421c41c0$c654c540$@com> <0B2F754289D27B449F7F1B95456B77544EDC53B3@szxeml524-mbs.china.huawei.com> <07c901cd8214$39a4c970$acee5c50$@com> In-Reply-To: <07c901cd8214$39a4c970$acee5c50$@com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.96] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: 'Stuart Cheshire' Subject: Re: [pcp] strengthening PCP with Mapping Nonce X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 02:26:47 -0000 Dear Wing Replay on line > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Saturday, August 25, 2012 12:19 AM > To: Zhangzongjian (Thomas); pcp@ietf.org > Cc: 'Stuart Cheshire' > Subject: RE: [pcp] strengthening PCP with Mapping Nonce >=20 > > -----Original Message----- > > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] > > Sent: Friday, August 24, 2012 1:06 AM > > To: Dan Wing; pcp@ietf.org > > Cc: 'Stuart Cheshire' > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > > > In -27, we have tentatively added: > > > > > > When such > > > an intervening non-PCP-aware inner NAT is detected, mappings must > > > first be created by some other means in the inner NAT, before > > > mappings can be usefully created in the outer PCP-controlled NAT. > > > Having created mappings in the inner NAT by some other means, the > > PCP > > > client should then use the inner NAT's External Address as the > > Client > > > IP Address, to signal to the outer PCP-controlled NAT that the > > client > > > is aware of the inner NAT, and has taken steps to create mappings > > in > > > it by some other means, so that mappings created in the outer NAT > > > will not be a pointless waste of state. > > > > > > > Dear Wing > > > > I think I understand your proposal, but there still are some questions. > > > > 1. How did PCP client (host) detect that there are two levels NAT > > (Inner NAT and Out NAT)? PCP client need to know this first of all. >=20 > It can use UPnP IGD, NAT-PMP, or HTTP screen-scraping to communicate > with the in-home residential NAT and get a mapping. Then, it can > use traceroute or some other technique to learn the internal IP > address of the CGN, and send it a PCP request. >=20 Thomas=3D> Getting a mapping does not mean there is a inner NAT in CPE. For example, = the CPE supports UPnP-PCP interworking function. Learning the IP address of CGN means there is a CGN, but it does not mean i= t is the second NAT. it may be the first NAT or the third NAT.=20 > > How could the PCP client know the inner NAT is an unsupported PCP > > device. >=20 > It doesn't know, and it doesn't care if the in-home residential > NAT supports PCP or not. The attack works as long as the in-home > residential NAT allows the PCP request from the attacker's IP > address to the CGN's PCP server address. >=20 > > If inner NAT supports PCP, it will find the PCP request is a > > malformed packet. It may discard the packet as the error packet or > > packet from an attacker. >=20 > In the attack scenario, the in-home residential NAT ('inner NAT') does > not support PCP. >=20 > And, even if it did, the attacker's PCP packet is not being sent to > the in-home residential NAT -- the attacker's PCP packet has a > destination address that is the PCP server in the ISP's network > (the CGN). Thomas=3D> Yes you are right. I mean when inner NAT has PCP proxy function, it may add= a third party option. It won't know use source IP address or PCP Client's = IP address in request header as the third party option value. PCP proxy may= discard the PCP request packet as the illegal packet. Then the PCP client = has to know whether CPE (inner NAT device) support PCP. If CPE does, it can= 't send the request packet with different source IP address and PCP Client'= s IP address. Or else it can do.=20 >=20 > > PCP client also need to know the Out NAT support PCP. >=20 > Yes, the attack is a PCP attack, and relies on the CGN supporting PCP. >=20 >=20 > > 2. You said that " mappings must first be created by some other means > > in the inner NAT". What is the means? Manually or dynamically? >=20 > Any of these would work: (a) UPnP IGD, (b) NAT-PMP, (c) screen- > scraping HTTP to the NAT's HTTP server, or (d) a human reading > the CLI or HTTP of the NAT and manually configuring the host > to send the proper PCP message. >=20 > > I am afraid there will be a coincident lifetime problem. For example > > the lifetime of MAP in Out NAT is 12 hour, but the lifetime of MAP in > > inner NAT is 1 hour. What will happen when inner NAT MAP's lifetime > > expired. >=20 > The lifetime of the mapping in the in-home residential NAT doesn't > matter for this attack. >=20 Thomas=3D> You are right, it has nothing to do with attack. I mean when we take consideration of two level NATs on draft-PCP-base, ther= e will be a lifetime disaccord problem. When the lifetime of mapping entry = in inner NAT expired, the mapping entry in outer NAT still active. The remo= te user can't access the server on PCP client host, but it seems that CGN w= orks better. >=20 > > 3. The Inner NAT function on CPE may be shut down for some reasons, how > > could the PCP client know the dynamic change on CPE? >=20 > If the in-home residential NAT is bridging (and is not a NAT), this > PCP attack is not possible. > Thomas=3D> Right, but PCP client needs to know whether inner NAT shuts down to decide = whether it constructs PCP request's PCP Client's IP address with source add= ress or external IP address from inner NAT. I think there are varies reason= that user will shut down NAT or turn on NAT function on CPE. =20 >=20 > > 4.How could the PCP client know the external IP address on inner NAT? >=20 > UPnP IGD, NAT-PMP, or screen-scraping the HTTP, or a human reading > the CLI or HTTP. >=20 Thomas=3D> I remember that UPnP can get the IP address on WAN interface. But external = IP address is a address pool of NAT. IP address on WAN and external IP addr= ess of pool may be the different IP address. I am not sure in this field. If there are an external IP in UPnP packets, i= t will be ok. > > 5.Is it possible that there are more than one external IP address > > (maybe a private IP address) on inner NAT external Pool? For example, > > different external IP for different service. >=20 > If the victim and the attacker have different IP addresses, from the > perspective of the carrier's PCP server, this specific PCP attack is > not possible. That occurs if the in-home residential CPE is not > NATing (as described in (3)) or if separate IP addresses are assigned > to each possible attack & victim host pair. Thomas=3D> It is ok >=20 > -d >=20 >=20 > > Regards > > Thomas > > > > > > > > > -----Original Message----- > > > From: Dan Wing [mailto:dwing@cisco.com] > > > Sent: Friday, August 24, 2012 12:49 AM > > > To: Zhangzongjian (Thomas); pcp@ietf.org > > > Cc: 'Stuart Cheshire' > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > > > > > -----Original Message----- > > > > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] > > > > Sent: Wednesday, August 22, 2012 6:59 PM > > > > To: Dan Wing; pcp@ietf.org > > > > Cc: 'Stuart Cheshire' > > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > ... > > > > Thomas=3D> > > > > Do you mean that the home NAT does not support PCP client, PCP > > proxy > > > > and upnp-pcp interworking? > > > > > > > > > Correct -- the home NAT, in this attack scenario, is the home NAT > > > that is currently for sale at the local computer store, which do > > > not support PCP and do not know anything about PCP. > > > > > > > > > > But, how could the victim host create the MAP entries? > > > > > > The victim's host supports PCP in its application (or its > > > operating system), which sends the PCP request to the CGN > > > directly. > > > > > > > > > > As you know the home NAT will change the source IP address of PCP > > > > request from hosts. This will result to mis-match with " PCP > > Client's > > > > IP Address" in PCP request heard. Then PCP server will return an > > > > ADDRESS_MISMATCH error without creating MAP entry. > > > > > > The PCP client in the (victim) host can overcome that by placing the > > > WAN address of the NAT into the PCP Client IP Address field of the > > > PCP packet. > > > > > > In -27, we have tentatively added: > > > > > > When such > > > an intervening non-PCP-aware inner NAT is detected, mappings must > > > first be created by some other means in the inner NAT, before > > > mappings can be usefully created in the outer PCP-controlled NAT. > > > Having created mappings in the inner NAT by some other means, the > > PCP > > > client should then use the inner NAT's External Address as the > > Client > > > IP Address, to signal to the outer PCP-controlled NAT that the > > client > > > is aware of the inner NAT, and has taken steps to create mappings > > in > > > it by some other means, so that mappings created in the outer NAT > > > will not be a pointless waste of state. > > > > > > -d > > > > > > > > > > Draft-ietf-pcp-base-26 tells something about mis-match. Below are > > > > copied from last paragraph of chart 8.2 for reference. > > > > > > > > The PCP server compares the source IP address (from the received IP > > > > header) with the field PCP Client IP Address. If they do not > > match, > > > > the error ADDRESS_MISMATCH MUST be returned. This is done to > > > detect > > > > and prevent accidental use of PCP where a non-PCP-aware NAT > > exists > > > > between the PCP client and PCP server. If the PCP client wants > > such > > > > a mapping it needs to ensure the PCP field matches its apparent > > IP > > > > address from the perspective of the PCP server. > > > > > > > > > > > > > > > > > -d > > > > > > > > > > > When home NAT receives a PCP MAP request with lifetime=3D0 from > > > > attacker, > > > > > > it should add a third party option with the attacker's IP > > address > > > > in > > > > > > this option. When CGN gets the PCP request, it will use the > > third > > > > party > > > > > > option address as the source address to search the MAP entries. > > > > Then > > > > > > the attacker can't delete the MAP entry created by victim. > > > > > > > > > > > > > > > > > > > address spoofing. 120 seconds later (per REQ-8 of > > > > > > > draft-ietf-behave-lsn-requirements-09), the attacker sends a > > new > > > > PCP > > > > > > MAP > > > > > > > request to try to acquire the (old) mapping of the victim > > host. > > > > In > > > > > > this > > > > > > > way, the attacker steals incoming traffic intended to go to > > the > > > > > > victim host. > > > > > > > > > > > > > > > > > > > > > Diagram: > > > > > > > > > > > > > > +-------------+ +----------+ > > > > > > > attacker -------+ | | | > > > > > > > (guest network) | | | | > > > > > > > | home NAT +----+ CGN > > > +----{Internet} > > > > > > > victim ---------+(without PCP)| |(with PCP)| > > > > > > > (wired network) | | | | > > > > > > > +-------------+ +----------+ > > > > > > > > > > > > > > > > > > > > > Please provide us feedback. I expect to publish -27 soon > > with > > > > these > > > > > > > changes, but we are doing some text coordination before > > > > publishing - > > > > > > 27. > > > > > > > > > > > > > > -d > > > > > > > > > > > > > > ----- > > > > > > > > > > > > > > REQ-9: A CGN MUST implement a protocol giving subscribers > > > > > > explicit > > > > > > > control over NAT mappings. That protocol SHOULD > > be > > > > the > > > > > > Port > > > > > > > Control Protocol [I-D.ietf-pcp-base], in which > > case > > > > the > > > > > > PCP > > > > > > > server MUST obey the following constraints on its > > > > > > behavior: > > > > > > > > > > > > > > A. It MUST NOT permit the lifetime of a mapping > > to be > > > > > > > reduced beyond its current life or be set to > > zero > > > > > > > (deleted). > > > > > > > > > > > > > > B. It MUST NOT permit a NAT mapping to be created > > > > with a > > > > > > > lifetime less than the lifetime used for > > implicit > > > > > > > mappings. > > > > > > > > > > > > > > C. It MUST NOT support the THIRD_PARTY option > > > except > > > > > for > > > > > > > requests received from "trusted" sources where > > it > > > > is > > > > > > > impractical for those sources to be spoofed. > > > > > > > > > > > > > > D. The MAP opcode MAY be permitted if the > > > > > recommendation > > > > > > > of > > > > > > > endpoint independent filtering behavior > > described > > > > in > > > > > > > REQ-7 is adopted; the map opcode MUST NOT be > > > > > permitted > > > > > > > in > > > > > > > other circumstances. These constraints MAY > be > > > > > relaxed > > > > > > if > > > > > > > a security mechanism consistent with PCP's > > > > Advanced > > > > > > > Threat Model (see Section 17.2 of [I-D.ietf- > > pcp- > > > > base]) > > > > > > is > > > > > > > used; this is expected to be rare for CGN > > > > deployments. > > > > > > > > > > > > > > E. Mappings created by PCP MUST follow the same > > > > > > deallocation > > > > > > > behavior (REQ-8) as implicitly mapped traffic. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > pcp mailing list > > > > > > > pcp@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/pcp > > > > > > > > > > > > Best regards > > > > > > Thomas From hartmans@painless-security.com Sun Aug 26 19:15:02 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E30F21F8533 for ; Sun, 26 Aug 2012 19:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.288 X-Spam-Level: **** X-Spam-Status: No, score=4.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doa2pw6wJHxA for ; Sun, 26 Aug 2012 19:15:01 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6C721F84E2 for ; Sun, 26 Aug 2012 19:15:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (gain1-180.nortex.net [63.160.158.180]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5F36B21255; Sun, 26 Aug 2012 22:14:55 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9AE264350; Sun, 26 Aug 2012 22:14:55 -0400 (EDT) From: Sam Hartman To: "Zhangzongjian \(Thomas\)" References: <028301cd7cdb$966780a0$c33681e0$@com> <0B2F754289D27B449F7F1B95456B77544EDC4FFE@szxeml524-mbs.china.huawei.com> <002301cd807d$e8d9fd40$ba8df7c0$@com> <0B2F754289D27B449F7F1B95456B77544EDC5131@szxeml524-mbs.china.huawei.com> <042601cd814f$421c41c0$c654c540$@com> <0B2F754289D27B449F7F1B95456B77544EDC53B3@szxeml524-mbs.china.huawei.com> <07c901cd8214$39a4c970$acee5c50$@com> <0B2F754289D27B449F7F1B95456B77544EDC558E@szxeml524-mbs.china.huawei.com> Date: Sun, 26 Aug 2012 22:14:55 -0400 In-Reply-To: <0B2F754289D27B449F7F1B95456B77544EDC558E@szxeml524-mbs.china.huawei.com> (Zhangzongjian's message of "Sat, 25 Aug 2012 02:22:04 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: 'Stuart Cheshire' , "pcp@ietf.org" Subject: Re: [pcp] strengthening PCP with Mapping Nonce X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 02:15:02 -0000 Hi. Margaret Wasserman and I got together for about 1.5 hours to look at the security implications of this proposal. I've been pondering it since that meeting. I believe that this proposal does improve the PCP protocol. In particular once we have a widely implemented security mechanism, a proposal like this could help give deployers a better set of options under the advanced threat model. That is, people who do need a security mechanism could turn it on. More people would find PCP met their security needs with the nonce mapping change than without it even if those people did not turn on a security mechanism. However, Margaret and I found that this change did not remove several of the attacks that most concern us when a security mechanism is not used. So, I'm strongly against the idea of relaxing the restrictions in section 17.1 of the base specification even if this proposal is adopted. >From a process standpoint, I think several people in the security community (myself included) supported the draft because of the compromise we reached in the simple threat model. I think we'd need to open up the document to fairly wide review if we changed those restrictions to seek a new security balance. I think that would add significant delay. I'd rather see us publish the base spec with as few changes as possible and move on with the authentication work. In that document or a future document we can update security restrictions if we gain consensus to do so. Beyond the process issues, I continue to support the technical direction of the simple thread model. The most serious attacks are present when there are multiple layers of NAT involved and the outer-most NAT has a PCP server. PCP or some other NAT control protocol really assists the attacker in that situation. At least with PCP we've thought through the security implications and we've given recommendations. Other NAT control protocols are worse than PCP in their security impact on the Internet. (I don't consider this justification for weakening the simple threat model: when we standardize things in the IETF, we often find we're considering security implications that pre-standardization efforts didn't consider. That's part of our value add) Even creating a very long-lived mapping in the PCP NAT can assist an attacker. If there is a longer-lived outer mapping, it can assist an attacker behind the inner NAT in capturing traffic when the inner mapping (but not outer mapping) expires. These attacks are somewhat complex to analyze because you have to assume things about application behavior. That's one of the reasons we want a very conservative stance prior to having a mandatory to implement security mechanism. Being able to create a mapping can also be valuable in capturing traffic. A and B are behind the same two nats, N1 and N2. N1, the inner NAT does not support PCP; N2, the outer NAT does. A is about to contact C. Note that from the prospective of N2, B and A have the same source address. So, B can create mappings on A's behalf if it can guess the port A will use. There are a number of cases where this is probable, especially if you consider that B can create multiple mappings. So, B creates a mapping that A will happen to use. B is an attacker; it can easily deal with PCP through an inner NAT. A, even if it does support PCP probably will not choose to use it through N1. Later as A's session is in progress, B deletes its mapping and attempts to create a new mapping that will reuse the same external port on N2. Obviously several factors affect this: N2's port allocation strategy, the application characteristics, etc etc. It's easy to decide that the attack is too difficult in practice. Unfortunately, people tend to find ways to exploit resource allocation strategies, mount timing attacks, etc in order to mount such attacks. Once the attack has been scripted in a convenient tool and argument that the attack is difficult to mount holds little weight. Yes, there are doubtless environments where being concerned with these attacks is not necessary. I strongly support moving as fast as we can to a point where we have a security mechanism and we can give customers the choice to either use the security mechanism or turn off restrictions required by the simple threat model. I do not support relaxing the simple threat model to get there. I do not support delaying the PCP base spec significantly at this point in the process. From dwing@cisco.com Mon Aug 27 10:31:11 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C08121F84F2 for ; Mon, 27 Aug 2012 10:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.495 X-Spam-Level: X-Spam-Status: No, score=-110.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jZhz-1RyJ9R for ; Mon, 27 Aug 2012 10:31:09 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 31CB921F84DA for ; Mon, 27 Aug 2012 10:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=15497; q=dns/txt; s=iport; t=1346088664; x=1347298264; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=bdy9LrngWXrTzw5bXWzBdofvpr7bikXX+yl5w7dHsUI=; b=iPHr4iCOR5JfIFZQuoEclQMeHf9ZObfjMUl5T/Fa8q112AWp3ltiUuyG bXDPdkMCndOJZwAlfLdN2TUZS9IdWqajWzQOzS+qshjwKSR2vbAgIlk3o Ri7eanb6gwCrxS5q67SezQDaocOHPtu7I+ITf9uUgIkiKgn0CtoGuKh3b 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsJAHyuO1CrRDoJ/2dsb2JhbABFqnSPAASBAYEHgiABAQEDAQEBAQUKARcQLQYBCwUHAQMCCQ8CAgIBASgHGQ4VCgkIAgQBEgsOCYdlBQyaS6AZiwhMhkUDiE+FDZYngWeDAw X-IronPort-AV: E=Sophos;i="4.80,321,1344211200"; d="scan'208";a="56257405" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 27 Aug 2012 17:27:42 +0000 Received: from dwingWS ([10.154.160.182]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7RHRg0k018725; Mon, 27 Aug 2012 17:27:42 GMT From: "Dan Wing" To: "'Zhangzongjian \(Thomas\)'" , References: <028301cd7cdb$966780a0$c33681e0$@com> <0B2F754289D27B449F7F1B95456B77544EDC4FFE@szxeml524-mbs.china.huawei.com> <002301cd807d$e8d9fd40$ba8df7c0$@com> <0B2F754289D27B449F7F1B95456B77544EDC5131@szxeml524-mbs.china.huawei.com> <042601cd814f$421c41c0$c654c540$@com> <0B2F754289D27B449F7F1B95456B77544EDC53B3@szxeml524-mbs.china.huawei.com> <07c901cd8214$39a4c970$acee5c50$@com> <0B2F754289D27B449F7F1B95456B77544EDC558E@szxeml524-mbs.china.huawei.com> In-Reply-To: <0B2F754289D27B449F7F1B95456B77544EDC558E@szxeml524-mbs.china.huawei.com> Date: Mon, 27 Aug 2012 10:27:42 -0700 Message-ID: <037101cd8479$43b2e840$cb18b8c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1825YgdqnKbKRsQbGswo9PpQX9dgDXgBgwABEHyxAAFIZlwAAfravAAB3rq7AAEybCEAARu6pwAIesO8A= Content-Language: en-us Cc: 'Stuart Cheshire' Subject: Re: [pcp] strengthening PCP with Mapping Nonce X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 17:31:11 -0000 > -----Original Message----- > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] > Sent: Friday, August 24, 2012 7:22 PM > To: Dan Wing; pcp@ietf.org > Cc: 'Stuart Cheshire' > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > Dear Wing > Replay on line > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Saturday, August 25, 2012 12:19 AM > > To: Zhangzongjian (Thomas); pcp@ietf.org > > Cc: 'Stuart Cheshire' > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > > > -----Original Message----- > > > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] > > > Sent: Friday, August 24, 2012 1:06 AM > > > To: Dan Wing; pcp@ietf.org > > > Cc: 'Stuart Cheshire' > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > > > > > In -27, we have tentatively added: > > > > > > > > When such > > > > an intervening non-PCP-aware inner NAT is detected, mappings > must > > > > first be created by some other means in the inner NAT, before > > > > mappings can be usefully created in the outer PCP-controlled > NAT. > > > > Having created mappings in the inner NAT by some other means, > the > > > PCP > > > > client should then use the inner NAT's External Address as the > > > Client > > > > IP Address, to signal to the outer PCP-controlled NAT that the > > > client > > > > is aware of the inner NAT, and has taken steps to create > mappings > > > in > > > > it by some other means, so that mappings created in the outer > NAT > > > > will not be a pointless waste of state. > > > > > > > > > > Dear Wing > > > > > > I think I understand your proposal, but there still are some > questions. > > > > > > 1. How did PCP client (host) detect that there are two levels NAT > > > (Inner NAT and Out NAT)? PCP client need to know this first of > all. > > > > It can use UPnP IGD, NAT-PMP, or HTTP screen-scraping to communicate > > with the in-home residential NAT and get a mapping. Then, it can > > use traceroute or some other technique to learn the internal IP > > address of the CGN, and send it a PCP request. > > > Thomas=> > Getting a mapping does not mean there is a inner NAT in CPE. For > example, the CPE supports UPnP-PCP interworking function. If there is a UPnP-PCP interworking function in the CPE router, I would expect the CPE router would prohibit PCP clients within the home from communicating directly with the PCP server in the CGN. However, the PCP working group has not yet finished the UPnP-PCP document, so I dunno if/how the working group will conclude on this problem. > Learning the IP address of CGN means there is a CGN, but it does not > mean it is the second NAT. it may be the first NAT or the third NAT. > > > > > How could the PCP client know the inner NAT is an unsupported PCP > > > device. > > > > It doesn't know, and it doesn't care if the in-home residential > > NAT supports PCP or not. The attack works as long as the in-home > > residential NAT allows the PCP request from the attacker's IP > > address to the CGN's PCP server address. > > > > > If inner NAT supports PCP, it will find the PCP request is a > > > malformed packet. It may discard the packet as the error packet or > > > packet from an attacker. > > > > In the attack scenario, the in-home residential NAT ('inner NAT') > does > > not support PCP. > > > > And, even if it did, the attacker's PCP packet is not being sent to > > the in-home residential NAT -- the attacker's PCP packet has a > > destination address that is the PCP server in the ISP's network > > (the CGN). > > Thomas=> > Yes you are right. I mean when inner NAT has PCP proxy function, it may > add a third party option. It won't know use source IP address or PCP > Client's IP address in request header as the third party option value. > PCP proxy may discard the PCP request packet as the illegal packet. > Then the PCP client has to know whether CPE (inner NAT device) support > PCP. If CPE does, it can't send the request packet with different > source IP address and PCP Client's IP address. Or else it can do. The inner NAT has no reason to add THIRD_PARTY, because the PCP request would come from the same IP address as the "PCP Client Source IP Address" in the PCP request. And the current text in pcp-base prohibits it from doing so, anyway. > > > PCP client also need to know the Out NAT support PCP. > > > > Yes, the attack is a PCP attack, and relies on the CGN supporting > PCP. > > > > > > > 2. You said that " mappings must first be created by some other > means > > > in the inner NAT". What is the means? Manually or dynamically? > > > > Any of these would work: (a) UPnP IGD, (b) NAT-PMP, (c) screen- > > scraping HTTP to the NAT's HTTP server, or (d) a human reading > > the CLI or HTTP of the NAT and manually configuring the host > > to send the proper PCP message. > > > > > I am afraid there will be a coincident lifetime problem. For > example > > > the lifetime of MAP in Out NAT is 12 hour, but the lifetime of MAP > in > > > inner NAT is 1 hour. What will happen when inner NAT MAP's > lifetime > > > expired. > > > > The lifetime of the mapping in the in-home residential NAT doesn't > > matter for this attack. > > > Thomas=> > You are right, it has nothing to do with attack. > I mean when we take consideration of two level NATs on draft-PCP-base, > there will be a lifetime disaccord problem. When the lifetime of > mapping entry in inner NAT expired, the mapping entry in outer NAT > still active. Sure. Not much we can do about that. (I see Sam answered this point in more detail over the weekend.) -d > The remote user can't access the server on PCP client > host, but it seems that CGN works better. > > > > > > > > > 3. The Inner NAT function on CPE may be shut down for some reasons, > how > > > could the PCP client know the dynamic change on CPE? > > > > If the in-home residential NAT is bridging (and is not a NAT), this > > PCP attack is not possible. > > > Thomas=> > Right, but PCP client needs to know whether inner NAT shuts down to > decide whether it constructs PCP request's PCP Client's IP address with > source address or external IP address from inner NAT. I think there are > varies reason that user will shut down NAT or turn on NAT function on > CPE. > > > > > > > 4.How could the PCP client know the external IP address on inner > NAT? > > > > UPnP IGD, NAT-PMP, or screen-scraping the HTTP, or a human reading > > the CLI or HTTP. > > > Thomas=> > I remember that UPnP can get the IP address on WAN interface. But > external IP address is a address pool of NAT. IP address on WAN and > external IP address of pool may be the different IP address. > I am not sure in this field. If there are an external IP in UPnP > packets, it will be ok. > > > > > > 5.Is it possible that there are more than one external IP address > > > (maybe a private IP address) on inner NAT external Pool? For > example, > > > different external IP for different service. > > > > If the victim and the attacker have different IP addresses, from the > > perspective of the carrier's PCP server, this specific PCP attack is > > not possible. That occurs if the in-home residential CPE is not > > NATing (as described in (3)) or if separate IP addresses are assigned > > to each possible attack & victim host pair. > Thomas=> It is ok > > > > > -d > > > > > > > Regards > > > Thomas > > > > > > > > > > > > > -----Original Message----- > > > > From: Dan Wing [mailto:dwing@cisco.com] > > > > Sent: Friday, August 24, 2012 12:49 AM > > > > To: Zhangzongjian (Thomas); pcp@ietf.org > > > > Cc: 'Stuart Cheshire' > > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > > > > > > > -----Original Message----- > > > > > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] > > > > > Sent: Wednesday, August 22, 2012 6:59 PM > > > > > To: Dan Wing; pcp@ietf.org > > > > > Cc: 'Stuart Cheshire' > > > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > > ... > > > > > Thomas=> > > > > > Do you mean that the home NAT does not support PCP client, PCP > > > proxy > > > > > and upnp-pcp interworking? > > > > > > > > > > > > Correct -- the home NAT, in this attack scenario, is the home NAT > > > > that is currently for sale at the local computer store, which do > > > > not support PCP and do not know anything about PCP. > > > > > > > > > > > > > But, how could the victim host create the MAP entries? > > > > > > > > The victim's host supports PCP in its application (or its > > > > operating system), which sends the PCP request to the CGN > > > > directly. > > > > > > > > > > > > > As you know the home NAT will change the source IP address of > PCP > > > > > request from hosts. This will result to mis-match with " PCP > > > Client's > > > > > IP Address" in PCP request heard. Then PCP server will return > an > > > > > ADDRESS_MISMATCH error without creating MAP entry. > > > > > > > > The PCP client in the (victim) host can overcome that by placing > the > > > > WAN address of the NAT into the PCP Client IP Address field of > the > > > > PCP packet. > > > > > > > > In -27, we have tentatively added: > > > > > > > > When such > > > > an intervening non-PCP-aware inner NAT is detected, mappings > must > > > > first be created by some other means in the inner NAT, before > > > > mappings can be usefully created in the outer PCP-controlled > NAT. > > > > Having created mappings in the inner NAT by some other means, > the > > > PCP > > > > client should then use the inner NAT's External Address as the > > > Client > > > > IP Address, to signal to the outer PCP-controlled NAT that the > > > client > > > > is aware of the inner NAT, and has taken steps to create > mappings > > > in > > > > it by some other means, so that mappings created in the outer > NAT > > > > will not be a pointless waste of state. > > > > > > > > -d > > > > > > > > > > > > > Draft-ietf-pcp-base-26 tells something about mis-match. Below > are > > > > > copied from last paragraph of chart 8.2 for reference. > > > > > > > > > > The PCP server compares the source IP address (from the > received IP > > > > > header) with the field PCP Client IP Address. If they do > not > > > match, > > > > > the error ADDRESS_MISMATCH MUST be returned. This is done > to > > > > detect > > > > > and prevent accidental use of PCP where a non-PCP-aware NAT > > > exists > > > > > between the PCP client and PCP server. If the PCP client > wants > > > such > > > > > a mapping it needs to ensure the PCP field matches its > apparent > > > IP > > > > > address from the perspective of the PCP server. > > > > > > > > > > > > > > > > > > > > > -d > > > > > > > > > > > > > When home NAT receives a PCP MAP request with lifetime=0 > from > > > > > attacker, > > > > > > > it should add a third party option with the attacker's IP > > > address > > > > > in > > > > > > > this option. When CGN gets the PCP request, it will use the > > > third > > > > > party > > > > > > > option address as the source address to search the MAP > entries. > > > > > Then > > > > > > > the attacker can't delete the MAP entry created by victim. > > > > > > > > > > > > > > > > > > > > > > address spoofing. 120 seconds later (per REQ-8 of > > > > > > > > draft-ietf-behave-lsn-requirements-09), the attacker > sends a > > > new > > > > > PCP > > > > > > > MAP > > > > > > > > request to try to acquire the (old) mapping of the victim > > > host. > > > > > In > > > > > > > this > > > > > > > > way, the attacker steals incoming traffic intended to go > to > > > the > > > > > > > victim host. > > > > > > > > > > > > > > > > > > > > > > > > Diagram: > > > > > > > > > > > > > > > > +-------------+ +----------+ > > > > > > > > attacker -------+ | | | > > > > > > > > (guest network) | | | | > > > > > > > > | home NAT +----+ CGN > > > > +----{Internet} > > > > > > > > victim ---------+(without PCP)| |(with PCP)| > > > > > > > > (wired network) | | | | > > > > > > > > +-------------+ +----------+ > > > > > > > > > > > > > > > > > > > > > > > > Please provide us feedback. I expect to publish -27 soon > > > with > > > > > these > > > > > > > > changes, but we are doing some text coordination before > > > > > publishing - > > > > > > > 27. > > > > > > > > > > > > > > > > -d > > > > > > > > > > > > > > > > ----- > > > > > > > > > > > > > > > > REQ-9: A CGN MUST implement a protocol giving > subscribers > > > > > > > explicit > > > > > > > > control over NAT mappings. That protocol > SHOULD > > > be > > > > > the > > > > > > > Port > > > > > > > > Control Protocol [I-D.ietf-pcp-base], in which > > > case > > > > > the > > > > > > > PCP > > > > > > > > server MUST obey the following constraints on > its > > > > > > > behavior: > > > > > > > > > > > > > > > > A. It MUST NOT permit the lifetime of a > mapping > > > to be > > > > > > > > reduced beyond its current life or be set > to > > > zero > > > > > > > > (deleted). > > > > > > > > > > > > > > > > B. It MUST NOT permit a NAT mapping to be > created > > > > > with a > > > > > > > > lifetime less than the lifetime used for > > > implicit > > > > > > > > mappings. > > > > > > > > > > > > > > > > C. It MUST NOT support the THIRD_PARTY option > > > > except > > > > > > for > > > > > > > > requests received from "trusted" sources > where > > > it > > > > > is > > > > > > > > impractical for those sources to be > spoofed. > > > > > > > > > > > > > > > > D. The MAP opcode MAY be permitted if the > > > > > > recommendation > > > > > > > > of > > > > > > > > endpoint independent filtering behavior > > > described > > > > > in > > > > > > > > REQ-7 is adopted; the map opcode MUST NOT > be > > > > > > permitted > > > > > > > > in > > > > > > > > other circumstances. These constraints > MAY > > be > > > > > > relaxed > > > > > > > if > > > > > > > > a security mechanism consistent with PCP's > > > > > Advanced > > > > > > > > Threat Model (see Section 17.2 of [I- > D.ietf- > > > pcp- > > > > > base]) > > > > > > > is > > > > > > > > used; this is expected to be rare for CGN > > > > > deployments. > > > > > > > > > > > > > > > > E. Mappings created by PCP MUST follow the > same > > > > > > > deallocation > > > > > > > > behavior (REQ-8) as implicitly mapped > traffic. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > pcp mailing list > > > > > > > > pcp@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/pcp > > > > > > > > > > > > > > Best regards > > > > > > > Thomas From zhangzhongjian@huawei.com Tue Aug 28 00:00:15 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CA421F8474 for ; Tue, 28 Aug 2012 00:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6augqryo9KBU for ; Tue, 28 Aug 2012 00:00:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AA7BC21F8476 for ; Tue, 28 Aug 2012 00:00:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJB89464; Tue, 28 Aug 2012 07:00:11 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 28 Aug 2012 07:58:29 +0100 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 28 Aug 2012 14:58:55 +0800 Received: from SZXEML524-MBS.china.huawei.com ([169.254.5.83]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Tue, 28 Aug 2012 14:58:47 +0800 From: "Zhangzongjian (Thomas)" To: Dan Wing , "pcp@ietf.org" Thread-Topic: [pcp] strengthening PCP with Mapping Nonce Thread-Index: Ac1825YgdqnKbKRsQbGswo9PpQX9dgDXgBgwABEHyxAAFIZlwAAfravAAB3rq7AAEybCEAARu6pwAIesO8AAHDBB0A== Date: Tue, 28 Aug 2012 06:58:47 +0000 Message-ID: <0B2F754289D27B449F7F1B95456B77544EDC59D9@szxeml524-mbs.china.huawei.com> References: <028301cd7cdb$966780a0$c33681e0$@com> <0B2F754289D27B449F7F1B95456B77544EDC4FFE@szxeml524-mbs.china.huawei.com> <002301cd807d$e8d9fd40$ba8df7c0$@com> <0B2F754289D27B449F7F1B95456B77544EDC5131@szxeml524-mbs.china.huawei.com> <042601cd814f$421c41c0$c654c540$@com> <0B2F754289D27B449F7F1B95456B77544EDC53B3@szxeml524-mbs.china.huawei.com> <07c901cd8214$39a4c970$acee5c50$@com> <0B2F754289D27B449F7F1B95456B77544EDC558E@szxeml524-mbs.china.huawei.com> <037101cd8479$43b2e840$cb18b8c0$@com> In-Reply-To: <037101cd8479$43b2e840$cb18b8c0$@com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.96] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: 'Stuart Cheshire' Subject: Re: [pcp] strengthening PCP with Mapping Nonce X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 07:00:15 -0000 > If there is a UPnP-PCP interworking function in the CPE router, > I would expect the CPE router would prohibit PCP clients within > the home from communicating directly with the PCP server in the > CGN. However, the PCP working group has not yet finished the > UPnP-PCP document, so I dunno if/how the working group will conclude > on this problem. > It seems strange to prohibit PCP clients from communicating directly with P= CP server. Sorry, I make a mistake on adding THIRD_PARTY question. Regards Thomas > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Tuesday, August 28, 2012 1:28 AM > To: Zhangzongjian (Thomas); pcp@ietf.org > Cc: 'Stuart Cheshire' > Subject: RE: [pcp] strengthening PCP with Mapping Nonce >=20 > > -----Original Message----- > > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] > > Sent: Friday, August 24, 2012 7:22 PM > > To: Dan Wing; pcp@ietf.org > > Cc: 'Stuart Cheshire' > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > > Dear Wing > > Replay on line > > > > > -----Original Message----- > > > From: Dan Wing [mailto:dwing@cisco.com] > > > Sent: Saturday, August 25, 2012 12:19 AM > > > To: Zhangzongjian (Thomas); pcp@ietf.org > > > Cc: 'Stuart Cheshire' > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > > > > > -----Original Message----- > > > > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] > > > > Sent: Friday, August 24, 2012 1:06 AM > > > > To: Dan Wing; pcp@ietf.org > > > > Cc: 'Stuart Cheshire' > > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > > > > > > > In -27, we have tentatively added: > > > > > > > > > > When such > > > > > an intervening non-PCP-aware inner NAT is detected, mappings > > must > > > > > first be created by some other means in the inner NAT, before > > > > > mappings can be usefully created in the outer PCP-controlled > > NAT. > > > > > Having created mappings in the inner NAT by some other means, > > the > > > > PCP > > > > > client should then use the inner NAT's External Address as the > > > > Client > > > > > IP Address, to signal to the outer PCP-controlled NAT that the > > > > client > > > > > is aware of the inner NAT, and has taken steps to create > > mappings > > > > in > > > > > it by some other means, so that mappings created in the outer > > NAT > > > > > will not be a pointless waste of state. > > > > > > > > > > > > > Dear Wing > > > > > > > > I think I understand your proposal, but there still are some > > questions. > > > > > > > > 1. How did PCP client (host) detect that there are two levels NAT > > > > (Inner NAT and Out NAT)? PCP client need to know this first of > > all. > > > > > > It can use UPnP IGD, NAT-PMP, or HTTP screen-scraping to communicate > > > with the in-home residential NAT and get a mapping. Then, it can > > > use traceroute or some other technique to learn the internal IP > > > address of the CGN, and send it a PCP request. > > > > > Thomas=3D> > > Getting a mapping does not mean there is a inner NAT in CPE. For > > example, the CPE supports UPnP-PCP interworking function. >=20 > If there is a UPnP-PCP interworking function in the CPE router, > I would expect the CPE router would prohibit PCP clients within > the home from communicating directly with the PCP server in the > CGN. However, the PCP working group has not yet finished the > UPnP-PCP document, so I dunno if/how the working group will conclude > on this problem. >=20 >=20 > > Learning the IP address of CGN means there is a CGN, but it does not > > mean it is the second NAT. it may be the first NAT or the third NAT. > > > > > > > > How could the PCP client know the inner NAT is an unsupported PCP > > > > device. > > > > > > It doesn't know, and it doesn't care if the in-home residential > > > NAT supports PCP or not. The attack works as long as the in-home > > > residential NAT allows the PCP request from the attacker's IP > > > address to the CGN's PCP server address. > > > > > > > If inner NAT supports PCP, it will find the PCP request is a > > > > malformed packet. It may discard the packet as the error packet or > > > > packet from an attacker. > > > > > > In the attack scenario, the in-home residential NAT ('inner NAT') > > does > > > not support PCP. > > > > > > And, even if it did, the attacker's PCP packet is not being sent to > > > the in-home residential NAT -- the attacker's PCP packet has a > > > destination address that is the PCP server in the ISP's network > > > (the CGN). > > > > Thomas=3D> > > Yes you are right. I mean when inner NAT has PCP proxy function, it may > > add a third party option. It won't know use source IP address or PCP > > Client's IP address in request header as the third party option value. > > PCP proxy may discard the PCP request packet as the illegal packet. > > Then the PCP client has to know whether CPE (inner NAT device) support > > PCP. If CPE does, it can't send the request packet with different > > source IP address and PCP Client's IP address. Or else it can do. >=20 > The inner NAT has no reason to add THIRD_PARTY, because the PCP > request would come from the same IP address as the "PCP Client > Source IP Address" in the PCP request. And the current text in > pcp-base prohibits it from doing so, anyway. >=20 >=20 > > > > PCP client also need to know the Out NAT support PCP. > > > > > > Yes, the attack is a PCP attack, and relies on the CGN supporting > > PCP. > > > > > > > > > > 2. You said that " mappings must first be created by some other > > means > > > > in the inner NAT". What is the means? Manually or dynamically? > > > > > > Any of these would work: (a) UPnP IGD, (b) NAT-PMP, (c) screen- > > > scraping HTTP to the NAT's HTTP server, or (d) a human reading > > > the CLI or HTTP of the NAT and manually configuring the host > > > to send the proper PCP message. > > > > > > > I am afraid there will be a coincident lifetime problem. For > > example > > > > the lifetime of MAP in Out NAT is 12 hour, but the lifetime of MAP > > in > > > > inner NAT is 1 hour. What will happen when inner NAT MAP's > > lifetime > > > > expired. > > > > > > The lifetime of the mapping in the in-home residential NAT doesn't > > > matter for this attack. > > > > > Thomas=3D> > > You are right, it has nothing to do with attack. > > I mean when we take consideration of two level NATs on draft-PCP-base, > > there will be a lifetime disaccord problem. When the lifetime of > > mapping entry in inner NAT expired, the mapping entry in outer NAT > > still active. >=20 > Sure. Not much we can do about that. (I see Sam answered this > point in more detail over the weekend.) >=20 > -d >=20 >=20 > > The remote user can't access the server on PCP client > > host, but it seems that CGN works better. > > > > > > > > > > > > > > > 3. The Inner NAT function on CPE may be shut down for some reasons, > > how > > > > could the PCP client know the dynamic change on CPE? > > > > > > If the in-home residential NAT is bridging (and is not a NAT), this > > > PCP attack is not possible. > > > > > Thomas=3D> > > Right, but PCP client needs to know whether inner NAT shuts down to > > decide whether it constructs PCP request's PCP Client's IP address with > > source address or external IP address from inner NAT. I think there are > > varies reason that user will shut down NAT or turn on NAT function on > > CPE. > > > > > > > > > > > 4.How could the PCP client know the external IP address on inner > > NAT? > > > > > > UPnP IGD, NAT-PMP, or screen-scraping the HTTP, or a human reading > > > the CLI or HTTP. > > > > > Thomas=3D> > > I remember that UPnP can get the IP address on WAN interface. But > > external IP address is a address pool of NAT. IP address on WAN and > > external IP address of pool may be the different IP address. > > I am not sure in this field. If there are an external IP in UPnP > > packets, it will be ok. > > > > > > > > > > 5.Is it possible that there are more than one external IP address > > > > (maybe a private IP address) on inner NAT external Pool? For > > example, > > > > different external IP for different service. > > > > > > If the victim and the attacker have different IP addresses, from the > > > perspective of the carrier's PCP server, this specific PCP attack is > > > not possible. That occurs if the in-home residential CPE is not > > > NATing (as described in (3)) or if separate IP addresses are assigned > > > to each possible attack & victim host pair. > > Thomas=3D> It is ok > > > > > > > > -d > > > > > > > > > > Regards > > > > Thomas > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Dan Wing [mailto:dwing@cisco.com] > > > > > Sent: Friday, August 24, 2012 12:49 AM > > > > > To: Zhangzongjian (Thomas); pcp@ietf.org > > > > > Cc: 'Stuart Cheshire' > > > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > > > > > > > > > -----Original Message----- > > > > > > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] > > > > > > Sent: Wednesday, August 22, 2012 6:59 PM > > > > > > To: Dan Wing; pcp@ietf.org > > > > > > Cc: 'Stuart Cheshire' > > > > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > > > ... > > > > > > Thomas=3D> > > > > > > Do you mean that the home NAT does not support PCP client, PCP > > > > proxy > > > > > > and upnp-pcp interworking? > > > > > > > > > > > > > > > Correct -- the home NAT, in this attack scenario, is the home NAT > > > > > that is currently for sale at the local computer store, which do > > > > > not support PCP and do not know anything about PCP. > > > > > > > > > > > > > > > > But, how could the victim host create the MAP entries? > > > > > > > > > > The victim's host supports PCP in its application (or its > > > > > operating system), which sends the PCP request to the CGN > > > > > directly. > > > > > > > > > > > > > > > > As you know the home NAT will change the source IP address of > > PCP > > > > > > request from hosts. This will result to mis-match with " PCP > > > > Client's > > > > > > IP Address" in PCP request heard. Then PCP server will return > > an > > > > > > ADDRESS_MISMATCH error without creating MAP entry. > > > > > > > > > > The PCP client in the (victim) host can overcome that by placing > > the > > > > > WAN address of the NAT into the PCP Client IP Address field of > > the > > > > > PCP packet. > > > > > > > > > > In -27, we have tentatively added: > > > > > > > > > > When such > > > > > an intervening non-PCP-aware inner NAT is detected, mappings > > must > > > > > first be created by some other means in the inner NAT, before > > > > > mappings can be usefully created in the outer PCP-controlled > > NAT. > > > > > Having created mappings in the inner NAT by some other means, > > the > > > > PCP > > > > > client should then use the inner NAT's External Address as the > > > > Client > > > > > IP Address, to signal to the outer PCP-controlled NAT that the > > > > client > > > > > is aware of the inner NAT, and has taken steps to create > > mappings > > > > in > > > > > it by some other means, so that mappings created in the outer > > NAT > > > > > will not be a pointless waste of state. > > > > > > > > > > -d > > > > > > > > > > > > > > > > Draft-ietf-pcp-base-26 tells something about mis-match. Below > > are > > > > > > copied from last paragraph of chart 8.2 for reference. > > > > > > > > > > > > The PCP server compares the source IP address (from the > > received IP > > > > > > header) with the field PCP Client IP Address. If they do > > not > > > > match, > > > > > > the error ADDRESS_MISMATCH MUST be returned. This is done > > to > > > > > detect > > > > > > and prevent accidental use of PCP where a non-PCP-aware NAT > > > > exists > > > > > > between the PCP client and PCP server. If the PCP client > > wants > > > > such > > > > > > a mapping it needs to ensure the PCP field matches its > > apparent > > > > IP > > > > > > address from the perspective of the PCP server. > > > > > > > > > > > > > > > > > > > > > > > > > -d > > > > > > > > > > > > > > > When home NAT receives a PCP MAP request with lifetime=3D0 > > from > > > > > > attacker, > > > > > > > > it should add a third party option with the attacker's IP > > > > address > > > > > > in > > > > > > > > this option. When CGN gets the PCP request, it will use the > > > > third > > > > > > party > > > > > > > > option address as the source address to search the MAP > > entries. > > > > > > Then > > > > > > > > the attacker can't delete the MAP entry created by victim. > > > > > > > > > > > > > > > > > > > > > > > > > address spoofing. 120 seconds later (per REQ-8 of > > > > > > > > > draft-ietf-behave-lsn-requirements-09), the attacker > > sends a > > > > new > > > > > > PCP > > > > > > > > MAP > > > > > > > > > request to try to acquire the (old) mapping of the victim > > > > host. > > > > > > In > > > > > > > > this > > > > > > > > > way, the attacker steals incoming traffic intended to go > > to > > > > the > > > > > > > > victim host. > > > > > > > > > > > > > > > > > > > > > > > > > > > Diagram: > > > > > > > > > > > > > > > > > > +-------------+ +----------+ > > > > > > > > > attacker -------+ | | | > > > > > > > > > (guest network) | | | | > > > > > > > > > | home NAT +----+ CGN > > > > > +----{Internet} > > > > > > > > > victim ---------+(without PCP)| |(with PCP)| > > > > > > > > > (wired network) | | | | > > > > > > > > > +-------------+ +----------+ > > > > > > > > > > > > > > > > > > > > > > > > > > > Please provide us feedback. I expect to publish -27 soon > > > > with > > > > > > these > > > > > > > > > changes, but we are doing some text coordination before > > > > > > publishing - > > > > > > > > 27. > > > > > > > > > > > > > > > > > > -d > > > > > > > > > > > > > > > > > > ----- > > > > > > > > > > > > > > > > > > REQ-9: A CGN MUST implement a protocol giving > > subscribers > > > > > > > > explicit > > > > > > > > > control over NAT mappings. That protocol > > SHOULD > > > > be > > > > > > the > > > > > > > > Port > > > > > > > > > Control Protocol [I-D.ietf-pcp-base], in which > > > > case > > > > > > the > > > > > > > > PCP > > > > > > > > > server MUST obey the following constraints on > > its > > > > > > > > behavior: > > > > > > > > > > > > > > > > > > A. It MUST NOT permit the lifetime of a > > mapping > > > > to be > > > > > > > > > reduced beyond its current life or be set > > to > > > > zero > > > > > > > > > (deleted). > > > > > > > > > > > > > > > > > > B. It MUST NOT permit a NAT mapping to be > > created > > > > > > with a > > > > > > > > > lifetime less than the lifetime used for > > > > implicit > > > > > > > > > mappings. > > > > > > > > > > > > > > > > > > C. It MUST NOT support the THIRD_PARTY > option > > > > > except > > > > > > > for > > > > > > > > > requests received from "trusted" sources > > where > > > > it > > > > > > is > > > > > > > > > impractical for those sources to be > > spoofed. > > > > > > > > > > > > > > > > > > D. The MAP opcode MAY be permitted if the > > > > > > > recommendation > > > > > > > > > of > > > > > > > > > endpoint independent filtering behavior > > > > described > > > > > > in > > > > > > > > > REQ-7 is adopted; the map opcode MUST NOT > > be > > > > > > > permitted > > > > > > > > > in > > > > > > > > > other circumstances. These constraints > > MAY > > > be > > > > > > > relaxed > > > > > > > > if > > > > > > > > > a security mechanism consistent with PCP's > > > > > > Advanced > > > > > > > > > Threat Model (see Section 17.2 of [I- > > D.ietf- > > > > pcp- > > > > > > base]) > > > > > > > > is > > > > > > > > > used; this is expected to be rare for CGN > > > > > > deployments. > > > > > > > > > > > > > > > > > > E. Mappings created by PCP MUST follow the > > same > > > > > > > > deallocation > > > > > > > > > behavior (REQ-8) as implicitly mapped > > traffic. > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > pcp mailing list > > > > > > > > > pcp@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/pcp > > > > > > > > > > > > > > > > Best regards > > > > > > > > Thomas From dwing@cisco.com Tue Aug 28 08:03:03 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6008B21F8462 for ; Tue, 28 Aug 2012 08:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.496 X-Spam-Level: X-Spam-Status: No, score=-110.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwcAkASBtfU3 for ; Tue, 28 Aug 2012 08:03:01 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 831DC21F8460 for ; Tue, 28 Aug 2012 08:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=19026; q=dns/txt; s=iport; t=1346166181; x=1347375781; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=hhDUyQz3XnJJWc600hGK21wllEsfW5p49E+1gdxb/0k=; b=WZ5mvYfpgAGb+qpomN2c9Wwa4ZKGC6ncAxM1zuaKO3DpCdmduaZ3lM/x GaOuvZ9LfMowxYu282JrCASCkcntDe+b5QJmgh1TIBUG4Lh93NAxDbJQr JUJsg6DGC1WXASrKP4jBkHxdjwJGae4fGekXus5PH8CwjMlXJiYO/+GQI s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FACLdPFCrRDoI/2dsb2JhbABFqnyPboEHgiABAQEDAQEBAQUKARcQLQYBCwUHAQMCCQ8CAgIBASgHGQ4VCgkIAgQBEgsOCYdlBQybRaBKiwiGWQOIT4UNliiBZ4MD X-IronPort-AV: E=Sophos;i="4.80,327,1344211200"; d="scan'208";a="53857029" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 28 Aug 2012 15:03:00 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7SF2xbR022490; Tue, 28 Aug 2012 15:02:59 GMT From: "Dan Wing" To: "'Zhangzongjian \(Thomas\)'" , References: <028301cd7cdb$966780a0$c33681e0$@com> <0B2F754289D27B449F7F1B95456B77544EDC4FFE@szxeml524-mbs.china.huawei.com> <002301cd807d$e8d9fd40$ba8df7c0$@com> <0B2F754289D27B449F7F1B95456B77544EDC5131@szxeml524-mbs.china.huawei.com> <042601cd814f$421c41c0$c654c540$@com> <0B2F754289D27B449F7F1B95456B77544EDC53B3@szxeml524-mbs.china.huawei.com> <07c901cd8214$39a4c970$acee5c50$@com> <0B2F754289D27B449F7F1B95456B77544EDC558E@szxeml524-mbs.china.huawei.com> <037101cd8479$43b2e840$cb18b8c0$@com> <0B2F754289D27B449F7F1B95456B77544EDC59D9@szxeml524-mbs.china.huawei.com> In-Reply-To: <0B2F754289D27B449F7F1B95456B77544EDC59D9@szxeml524-mbs.china.huawei.com> Date: Tue, 28 Aug 2012 08:02:59 -0700 Message-ID: <073701cd852e$36ac8c40$a405a4c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1825YgdqnKbKRsQbGswo9PpQX9dgDXgBgwABEHyxAAFIZlwAAfravAAB3rq7AAEybCEAARu6pwAIesO8AAHDBB0AARF5uA Content-Language: en-us Cc: 'Stuart Cheshire' Subject: Re: [pcp] strengthening PCP with Mapping Nonce X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:03:03 -0000 > -----Original Message----- > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] > Sent: Monday, August 27, 2012 11:59 PM > To: Dan Wing; pcp@ietf.org > Cc: 'Stuart Cheshire' > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > If there is a UPnP-PCP interworking function in the CPE router, > > I would expect the CPE router would prohibit PCP clients within > > the home from communicating directly with the PCP server in the > > CGN. However, the PCP working group has not yet finished the > > UPnP-PCP document, so I dunno if/how the working group will conclude > > on this problem. > > > It seems strange to prohibit PCP clients from communicating directly > with PCP server. Yes, I agree that would be strange. But the current plan for PCP proxying has the PCP client only communicate with its local (closest) PCP server, and not communicate with every upstream PCP server. So blocking that communication would be in line with the current plan for PCP proxying. However, that current plan for PCP proxying might change if it doesn't work properly with PCP authentication or with asymmetric routing or some other new problem. -d > Sorry, I make a mistake on adding THIRD_PARTY question. > > Regards > Thomas > > > > > > -----Original Message----- > > From: Dan Wing [mailto:dwing@cisco.com] > > Sent: Tuesday, August 28, 2012 1:28 AM > > To: Zhangzongjian (Thomas); pcp@ietf.org > > Cc: 'Stuart Cheshire' > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > > > -----Original Message----- > > > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] > > > Sent: Friday, August 24, 2012 7:22 PM > > > To: Dan Wing; pcp@ietf.org > > > Cc: 'Stuart Cheshire' > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > > > > Dear Wing > > > Replay on line > > > > > > > -----Original Message----- > > > > From: Dan Wing [mailto:dwing@cisco.com] > > > > Sent: Saturday, August 25, 2012 12:19 AM > > > > To: Zhangzongjian (Thomas); pcp@ietf.org > > > > Cc: 'Stuart Cheshire' > > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > > > > > > > -----Original Message----- > > > > > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] > > > > > Sent: Friday, August 24, 2012 1:06 AM > > > > > To: Dan Wing; pcp@ietf.org > > > > > Cc: 'Stuart Cheshire' > > > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > > > > > > > > > In -27, we have tentatively added: > > > > > > > > > > > > When such > > > > > > an intervening non-PCP-aware inner NAT is detected, > mappings > > > must > > > > > > first be created by some other means in the inner NAT, > before > > > > > > mappings can be usefully created in the outer PCP- > controlled > > > NAT. > > > > > > Having created mappings in the inner NAT by some other > means, > > > the > > > > > PCP > > > > > > client should then use the inner NAT's External Address as > the > > > > > Client > > > > > > IP Address, to signal to the outer PCP-controlled NAT that > the > > > > > client > > > > > > is aware of the inner NAT, and has taken steps to create > > > mappings > > > > > in > > > > > > it by some other means, so that mappings created in the > outer > > > NAT > > > > > > will not be a pointless waste of state. > > > > > > > > > > > > > > > > Dear Wing > > > > > > > > > > I think I understand your proposal, but there still are some > > > questions. > > > > > > > > > > 1. How did PCP client (host) detect that there are two levels > NAT > > > > > (Inner NAT and Out NAT)? PCP client need to know this first > of > > > all. > > > > > > > > It can use UPnP IGD, NAT-PMP, or HTTP screen-scraping to > communicate > > > > with the in-home residential NAT and get a mapping. Then, it can > > > > use traceroute or some other technique to learn the internal IP > > > > address of the CGN, and send it a PCP request. > > > > > > > Thomas=> > > > Getting a mapping does not mean there is a inner NAT in CPE. For > > > example, the CPE supports UPnP-PCP interworking function. > > > > If there is a UPnP-PCP interworking function in the CPE router, > > I would expect the CPE router would prohibit PCP clients within > > the home from communicating directly with the PCP server in the > > CGN. However, the PCP working group has not yet finished the > > UPnP-PCP document, so I dunno if/how the working group will conclude > > on this problem. > > > > > > > Learning the IP address of CGN means there is a CGN, but it does > not > > > mean it is the second NAT. it may be the first NAT or the third > NAT. > > > > > > > > > > > How could the PCP client know the inner NAT is an unsupported > PCP > > > > > device. > > > > > > > > It doesn't know, and it doesn't care if the in-home residential > > > > NAT supports PCP or not. The attack works as long as the in-home > > > > residential NAT allows the PCP request from the attacker's IP > > > > address to the CGN's PCP server address. > > > > > > > > > If inner NAT supports PCP, it will find the PCP request is a > > > > > malformed packet. It may discard the packet as the error packet > or > > > > > packet from an attacker. > > > > > > > > In the attack scenario, the in-home residential NAT ('inner NAT') > > > does > > > > not support PCP. > > > > > > > > And, even if it did, the attacker's PCP packet is not being sent > to > > > > the in-home residential NAT -- the attacker's PCP packet has a > > > > destination address that is the PCP server in the ISP's network > > > > (the CGN). > > > > > > Thomas=> > > > Yes you are right. I mean when inner NAT has PCP proxy function, it > may > > > add a third party option. It won't know use source IP address or > PCP > > > Client's IP address in request header as the third party option > value. > > > PCP proxy may discard the PCP request packet as the illegal packet. > > > Then the PCP client has to know whether CPE (inner NAT device) > support > > > PCP. If CPE does, it can't send the request packet with different > > > source IP address and PCP Client's IP address. Or else it can do. > > > > The inner NAT has no reason to add THIRD_PARTY, because the PCP > > request would come from the same IP address as the "PCP Client > > Source IP Address" in the PCP request. And the current text in > > pcp-base prohibits it from doing so, anyway. > > > > > > > > > PCP client also need to know the Out NAT support PCP. > > > > > > > > Yes, the attack is a PCP attack, and relies on the CGN supporting > > > PCP. > > > > > > > > > > > > > 2. You said that " mappings must first be created by some other > > > means > > > > > in the inner NAT". What is the means? Manually or dynamically? > > > > > > > > Any of these would work: (a) UPnP IGD, (b) NAT-PMP, (c) screen- > > > > scraping HTTP to the NAT's HTTP server, or (d) a human reading > > > > the CLI or HTTP of the NAT and manually configuring the host > > > > to send the proper PCP message. > > > > > > > > > I am afraid there will be a coincident lifetime problem. For > > > example > > > > > the lifetime of MAP in Out NAT is 12 hour, but the lifetime of > MAP > > > in > > > > > inner NAT is 1 hour. What will happen when inner NAT MAP's > > > lifetime > > > > > expired. > > > > > > > > The lifetime of the mapping in the in-home residential NAT > doesn't > > > > matter for this attack. > > > > > > > Thomas=> > > > You are right, it has nothing to do with attack. > > > I mean when we take consideration of two level NATs on draft-PCP- > base, > > > there will be a lifetime disaccord problem. When the lifetime of > > > mapping entry in inner NAT expired, the mapping entry in outer NAT > > > still active. > > > > Sure. Not much we can do about that. (I see Sam answered this > > point in more detail over the weekend.) > > > > -d > > > > > > > The remote user can't access the server on PCP client > > > host, but it seems that CGN works better. > > > > > > > > > > > > > > > > > > > > > 3. The Inner NAT function on CPE may be shut down for some > reasons, > > > how > > > > > could the PCP client know the dynamic change on CPE? > > > > > > > > If the in-home residential NAT is bridging (and is not a NAT), > this > > > > PCP attack is not possible. > > > > > > > Thomas=> > > > Right, but PCP client needs to know whether inner NAT shuts down to > > > decide whether it constructs PCP request's PCP Client's IP address > with > > > source address or external IP address from inner NAT. I think there > are > > > varies reason that user will shut down NAT or turn on NAT function > on > > > CPE. > > > > > > > > > > > > > > > 4.How could the PCP client know the external IP address on > inner > > > NAT? > > > > > > > > UPnP IGD, NAT-PMP, or screen-scraping the HTTP, or a human > reading > > > > the CLI or HTTP. > > > > > > > Thomas=> > > > I remember that UPnP can get the IP address on WAN interface. But > > > external IP address is a address pool of NAT. IP address on WAN and > > > external IP address of pool may be the different IP address. > > > I am not sure in this field. If there are an external IP in UPnP > > > packets, it will be ok. > > > > > > > > > > > > > > 5.Is it possible that there are more than one external IP > address > > > > > (maybe a private IP address) on inner NAT external Pool? For > > > example, > > > > > different external IP for different service. > > > > > > > > If the victim and the attacker have different IP addresses, from > the > > > > perspective of the carrier's PCP server, this specific PCP attack > is > > > > not possible. That occurs if the in-home residential CPE is not > > > > NATing (as described in (3)) or if separate IP addresses are > assigned > > > > to each possible attack & victim host pair. > > > Thomas=> It is ok > > > > > > > > > > > -d > > > > > > > > > > > > > Regards > > > > > Thomas > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dan Wing [mailto:dwing@cisco.com] > > > > > > Sent: Friday, August 24, 2012 12:49 AM > > > > > > To: Zhangzongjian (Thomas); pcp@ietf.org > > > > > > Cc: 'Stuart Cheshire' > > > > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Zhangzongjian (Thomas) > [mailto:zhangzhongjian@huawei.com] > > > > > > > Sent: Wednesday, August 22, 2012 6:59 PM > > > > > > > To: Dan Wing; pcp@ietf.org > > > > > > > Cc: 'Stuart Cheshire' > > > > > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce > > > > > > ... > > > > > > > Thomas=> > > > > > > > Do you mean that the home NAT does not support PCP client, > PCP > > > > > proxy > > > > > > > and upnp-pcp interworking? > > > > > > > > > > > > > > > > > > Correct -- the home NAT, in this attack scenario, is the home > NAT > > > > > > that is currently for sale at the local computer store, which > do > > > > > > not support PCP and do not know anything about PCP. > > > > > > > > > > > > > > > > > > > But, how could the victim host create the MAP entries? > > > > > > > > > > > > The victim's host supports PCP in its application (or its > > > > > > operating system), which sends the PCP request to the CGN > > > > > > directly. > > > > > > > > > > > > > > > > > > > As you know the home NAT will change the source IP address > of > > > PCP > > > > > > > request from hosts. This will result to mis-match with " > PCP > > > > > Client's > > > > > > > IP Address" in PCP request heard. Then PCP server will > return > > > an > > > > > > > ADDRESS_MISMATCH error without creating MAP entry. > > > > > > > > > > > > The PCP client in the (victim) host can overcome that by > placing > > > the > > > > > > WAN address of the NAT into the PCP Client IP Address field > of > > > the > > > > > > PCP packet. > > > > > > > > > > > > In -27, we have tentatively added: > > > > > > > > > > > > When such > > > > > > an intervening non-PCP-aware inner NAT is detected, > mappings > > > must > > > > > > first be created by some other means in the inner NAT, > before > > > > > > mappings can be usefully created in the outer PCP- > controlled > > > NAT. > > > > > > Having created mappings in the inner NAT by some other > means, > > > the > > > > > PCP > > > > > > client should then use the inner NAT's External Address as > the > > > > > Client > > > > > > IP Address, to signal to the outer PCP-controlled NAT that > the > > > > > client > > > > > > is aware of the inner NAT, and has taken steps to create > > > mappings > > > > > in > > > > > > it by some other means, so that mappings created in the > outer > > > NAT > > > > > > will not be a pointless waste of state. > > > > > > > > > > > > -d > > > > > > > > > > > > > > > > > > > Draft-ietf-pcp-base-26 tells something about mis-match. > Below > > > are > > > > > > > copied from last paragraph of chart 8.2 for reference. > > > > > > > > > > > > > > The PCP server compares the source IP address (from the > > > received IP > > > > > > > header) with the field PCP Client IP Address. If they > do > > > not > > > > > match, > > > > > > > the error ADDRESS_MISMATCH MUST be returned. This is > done > > > to > > > > > > detect > > > > > > > and prevent accidental use of PCP where a non-PCP-aware > NAT > > > > > exists > > > > > > > between the PCP client and PCP server. If the PCP > client > > > wants > > > > > such > > > > > > > a mapping it needs to ensure the PCP field matches its > > > apparent > > > > > IP > > > > > > > address from the perspective of the PCP server. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -d > > > > > > > > > > > > > > > > > When home NAT receives a PCP MAP request with > lifetime=0 > > > from > > > > > > > attacker, > > > > > > > > > it should add a third party option with the attacker's > IP > > > > > address > > > > > > > in > > > > > > > > > this option. When CGN gets the PCP request, it will use > the > > > > > third > > > > > > > party > > > > > > > > > option address as the source address to search the MAP > > > entries. > > > > > > > Then > > > > > > > > > the attacker can't delete the MAP entry created by > victim. > > > > > > > > > > > > > > > > > > > > > > > > > > > > address spoofing. 120 seconds later (per REQ-8 of > > > > > > > > > > draft-ietf-behave-lsn-requirements-09), the attacker > > > sends a > > > > > new > > > > > > > PCP > > > > > > > > > MAP > > > > > > > > > > request to try to acquire the (old) mapping of the > victim > > > > > host. > > > > > > > In > > > > > > > > > this > > > > > > > > > > way, the attacker steals incoming traffic intended to > go > > > to > > > > > the > > > > > > > > > victim host. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Diagram: > > > > > > > > > > > > > > > > > > > > +-------------+ +----------+ > > > > > > > > > > attacker -------+ | | | > > > > > > > > > > (guest network) | | | | > > > > > > > > > > | home NAT +----+ CGN > > > > > > +----{Internet} > > > > > > > > > > victim ---------+(without PCP)| |(with PCP)| > > > > > > > > > > (wired network) | | | | > > > > > > > > > > +-------------+ +----------+ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please provide us feedback. I expect to publish -27 > soon > > > > > with > > > > > > > these > > > > > > > > > > changes, but we are doing some text coordination > before > > > > > > > publishing - > > > > > > > > > 27. > > > > > > > > > > > > > > > > > > > > -d > > > > > > > > > > > > > > > > > > > > ----- > > > > > > > > > > > > > > > > > > > > REQ-9: A CGN MUST implement a protocol giving > > > subscribers > > > > > > > > > explicit > > > > > > > > > > control over NAT mappings. That protocol > > > SHOULD > > > > > be > > > > > > > the > > > > > > > > > Port > > > > > > > > > > Control Protocol [I-D.ietf-pcp-base], in > which > > > > > case > > > > > > > the > > > > > > > > > PCP > > > > > > > > > > server MUST obey the following constraints > on > > > its > > > > > > > > > behavior: > > > > > > > > > > > > > > > > > > > > A. It MUST NOT permit the lifetime of a > > > mapping > > > > > to be > > > > > > > > > > reduced beyond its current life or be > set > > > to > > > > > zero > > > > > > > > > > (deleted). > > > > > > > > > > > > > > > > > > > > B. It MUST NOT permit a NAT mapping to be > > > created > > > > > > > with a > > > > > > > > > > lifetime less than the lifetime used > for > > > > > implicit > > > > > > > > > > mappings. > > > > > > > > > > > > > > > > > > > > C. It MUST NOT support the THIRD_PARTY > > option > > > > > > except > > > > > > > > for > > > > > > > > > > requests received from "trusted" > sources > > > where > > > > > it > > > > > > > is > > > > > > > > > > impractical for those sources to be > > > spoofed. > > > > > > > > > > > > > > > > > > > > D. The MAP opcode MAY be permitted if the > > > > > > > > recommendation > > > > > > > > > > of > > > > > > > > > > endpoint independent filtering > behavior > > > > > described > > > > > > > in > > > > > > > > > > REQ-7 is adopted; the map opcode MUST > NOT > > > be > > > > > > > > permitted > > > > > > > > > > in > > > > > > > > > > other circumstances. These > constraints > > > MAY > > > > be > > > > > > > > relaxed > > > > > > > > > if > > > > > > > > > > a security mechanism consistent with > PCP's > > > > > > > Advanced > > > > > > > > > > Threat Model (see Section 17.2 of [I- > > > D.ietf- > > > > > pcp- > > > > > > > base]) > > > > > > > > > is > > > > > > > > > > used; this is expected to be rare for > CGN > > > > > > > deployments. > > > > > > > > > > > > > > > > > > > > E. Mappings created by PCP MUST follow > the > > > same > > > > > > > > > deallocation > > > > > > > > > > behavior (REQ-8) as implicitly mapped > > > traffic. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > pcp mailing list > > > > > > > > > > pcp@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/pcp > > > > > > > > > > > > > > > > > > Best regards > > > > > > > > > Thomas From repenno@cisco.com Tue Aug 28 08:12:14 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839D421F8513 for ; Tue, 28 Aug 2012 08:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xs0oddJYV-CY for ; Tue, 28 Aug 2012 08:12:13 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B171821F84F2 for ; Tue, 28 Aug 2012 08:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=20291; q=dns/txt; s=iport; t=1346166732; x=1347376332; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=iuCkfNX90mRGG4e6Ph65C4/Qu1k1m5x/O60Vpjphmq8=; b=hxWipzKN2zWeZmGCy8zivQ03s59yWwkykIL1CN3nN9AdHfXZJzbENgqF 7MczMurFisIyin0bj0Qp5EyfToxB/2j7y7RXEi37/ri6qywqHqO6gjKWc rA/+Y/O5H+2p5N2PJ8klLtgucqs21NNonJcrnGJKY4MHN8jZdlR/B25t6 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHPfPFCtJV2Z/2dsb2JhbABFumqBB4IgAQEBAwEBAQEPASctBgELDAYBCBECAQEBAR8JLgsUCQgCBAENBRkJh2UGC5tQoEqLCIZZA5VWji6BZ4Jj X-IronPort-AV: E=Sophos;i="4.80,327,1344211200"; d="scan'208";a="116039237" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 28 Aug 2012 15:12:11 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7SFCB01012575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Aug 2012 15:12:11 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Tue, 28 Aug 2012 10:12:10 -0500 From: "Reinaldo Penno (repenno)" To: "Dan Wing (dwing)" , "'Zhangzongjian (Thomas)'" , "pcp@ietf.org" Thread-Topic: [pcp] strengthening PCP with Mapping Nonce Thread-Index: Ac1825YgdqnKbKRsQbGswo9PpQX9dgDXgBgwABEHyxAAFIZlwAAfravAAB3rq7AAEybCEAARu6pwAIesO8AAHDBB0AARF5uA///iVgA= Date: Tue, 28 Aug 2012 15:12:10 +0000 Message-ID: In-Reply-To: <073701cd852e$36ac8c40$a405a4c0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.89.2.202] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.007 x-tm-as-result: No--65.299500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Stuart Cheshire' Subject: Re: [pcp] strengthening PCP with Mapping Nonce X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:12:14 -0000 -----Original Message----- From: Dan Wing Date: Tue, 28 Aug 2012 08:02:59 -0700 To: "'Zhangzongjian (Thomas)'" , Cc: 'Stuart Cheshire' Subject: Re: [pcp] strengthening PCP with Mapping Nonce >> -----Original Message----- >> From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] >> Sent: Monday, August 27, 2012 11:59 PM >> To: Dan Wing; pcp@ietf.org >> Cc: 'Stuart Cheshire' >> Subject: RE: [pcp] strengthening PCP with Mapping Nonce >>=20 >> > If there is a UPnP-PCP interworking function in the CPE router, >> > I would expect the CPE router would prohibit PCP clients within >> > the home from communicating directly with the PCP server in the >> > CGN. However, the PCP working group has not yet finished the >> > UPnP-PCP document, so I dunno if/how the working group will conclude >> > on this problem. >> > >> It seems strange to prohibit PCP clients from communicating directly >> with PCP server. > >Yes, I agree that would be strange. But the current plan for PCP >proxying has the PCP client only communicate with its local (closest) >PCP server, and not communicate with every upstream PCP server. So >blocking that communication would be in line with the current plan >for PCP proxying. However, that current plan for PCP proxying might >change if it doesn't work properly with PCP authentication or >with asymmetric routing or some other new problem. The I believe we should change otherwise wouldn't this be a problem for the protocol evolution? Suppose I want to control the Firewall policies of my machine in some datacenter from my home - and the CPE implements this kind of 'blocking' PCP Proxy? =20 > >-d > > >> Sorry, I make a mistake on adding THIRD_PARTY question. >>=20 >> Regards >> Thomas >>=20 >>=20 >>=20 >>=20 >> > -----Original Message----- >> > From: Dan Wing [mailto:dwing@cisco.com] >> > Sent: Tuesday, August 28, 2012 1:28 AM >> > To: Zhangzongjian (Thomas); pcp@ietf.org >> > Cc: 'Stuart Cheshire' >> > Subject: RE: [pcp] strengthening PCP with Mapping Nonce >> > >> > > -----Original Message----- >> > > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] >> > > Sent: Friday, August 24, 2012 7:22 PM >> > > To: Dan Wing; pcp@ietf.org >> > > Cc: 'Stuart Cheshire' >> > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce >> > > >> > > Dear Wing >> > > Replay on line >> > > >> > > > -----Original Message----- >> > > > From: Dan Wing [mailto:dwing@cisco.com] >> > > > Sent: Saturday, August 25, 2012 12:19 AM >> > > > To: Zhangzongjian (Thomas); pcp@ietf.org >> > > > Cc: 'Stuart Cheshire' >> > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce >> > > > >> > > > > -----Original Message----- >> > > > > From: Zhangzongjian (Thomas) [mailto:zhangzhongjian@huawei.com] >> > > > > Sent: Friday, August 24, 2012 1:06 AM >> > > > > To: Dan Wing; pcp@ietf.org >> > > > > Cc: 'Stuart Cheshire' >> > > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce >> > > > > >> > > > > > In -27, we have tentatively added: >> > > > > > >> > > > > > When such >> > > > > > an intervening non-PCP-aware inner NAT is detected, >> mappings >> > > must >> > > > > > first be created by some other means in the inner NAT, >> before >> > > > > > mappings can be usefully created in the outer PCP- >> controlled >> > > NAT. >> > > > > > Having created mappings in the inner NAT by some other >> means, >> > > the >> > > > > PCP >> > > > > > client should then use the inner NAT's External Address as >> the >> > > > > Client >> > > > > > IP Address, to signal to the outer PCP-controlled NAT that >> the >> > > > > client >> > > > > > is aware of the inner NAT, and has taken steps to create >> > > mappings >> > > > > in >> > > > > > it by some other means, so that mappings created in the >> outer >> > > NAT >> > > > > > will not be a pointless waste of state. >> > > > > > >> > > > > >> > > > > Dear Wing >> > > > > >> > > > > I think I understand your proposal, but there still are some >> > > questions. >> > > > > >> > > > > 1. How did PCP client (host) detect that there are two levels >> NAT >> > > > > (Inner NAT and Out NAT)? PCP client need to know this first >> of >> > > all. >> > > > >> > > > It can use UPnP IGD, NAT-PMP, or HTTP screen-scraping to >> communicate >> > > > with the in-home residential NAT and get a mapping. Then, it can >> > > > use traceroute or some other technique to learn the internal IP >> > > > address of the CGN, and send it a PCP request. >> > > > >> > > Thomas=3D> >> > > Getting a mapping does not mean there is a inner NAT in CPE. For >> > > example, the CPE supports UPnP-PCP interworking function. >> > >> > If there is a UPnP-PCP interworking function in the CPE router, >> > I would expect the CPE router would prohibit PCP clients within >> > the home from communicating directly with the PCP server in the >> > CGN. However, the PCP working group has not yet finished the >> > UPnP-PCP document, so I dunno if/how the working group will conclude >> > on this problem. >> > >> > >> > > Learning the IP address of CGN means there is a CGN, but it does >> not >> > > mean it is the second NAT. it may be the first NAT or the third >> NAT. >> > > >> > > >> > > > > How could the PCP client know the inner NAT is an unsupported >> PCP >> > > > > device. >> > > > >> > > > It doesn't know, and it doesn't care if the in-home residential >> > > > NAT supports PCP or not. The attack works as long as the in-home >> > > > residential NAT allows the PCP request from the attacker's IP >> > > > address to the CGN's PCP server address. >> > > > >> > > > > If inner NAT supports PCP, it will find the PCP request is a >> > > > > malformed packet. It may discard the packet as the error packet >> or >> > > > > packet from an attacker. >> > > > >> > > > In the attack scenario, the in-home residential NAT ('inner NAT') >> > > does >> > > > not support PCP. >> > > > >> > > > And, even if it did, the attacker's PCP packet is not being sent >> to >> > > > the in-home residential NAT -- the attacker's PCP packet has a >> > > > destination address that is the PCP server in the ISP's network >> > > > (the CGN). >> > > >> > > Thomas=3D> >> > > Yes you are right. I mean when inner NAT has PCP proxy function, it >> may >> > > add a third party option. It won't know use source IP address or >> PCP >> > > Client's IP address in request header as the third party option >> value. >> > > PCP proxy may discard the PCP request packet as the illegal packet. >> > > Then the PCP client has to know whether CPE (inner NAT device) >> support >> > > PCP. If CPE does, it can't send the request packet with different >> > > source IP address and PCP Client's IP address. Or else it can do. >> > >> > The inner NAT has no reason to add THIRD_PARTY, because the PCP >> > request would come from the same IP address as the "PCP Client >> > Source IP Address" in the PCP request. And the current text in >> > pcp-base prohibits it from doing so, anyway. >> > >> > >> > > > > PCP client also need to know the Out NAT support PCP. >> > > > >> > > > Yes, the attack is a PCP attack, and relies on the CGN supporting >> > > PCP. >> > > > >> > > > >> > > > > 2. You said that " mappings must first be created by some other >> > > means >> > > > > in the inner NAT". What is the means? Manually or dynamically? >> > > > >> > > > Any of these would work: (a) UPnP IGD, (b) NAT-PMP, (c) screen- >> > > > scraping HTTP to the NAT's HTTP server, or (d) a human reading >> > > > the CLI or HTTP of the NAT and manually configuring the host >> > > > to send the proper PCP message. >> > > > >> > > > > I am afraid there will be a coincident lifetime problem. For >> > > example >> > > > > the lifetime of MAP in Out NAT is 12 hour, but the lifetime of >> MAP >> > > in >> > > > > inner NAT is 1 hour. What will happen when inner NAT MAP's >> > > lifetime >> > > > > expired. >> > > > >> > > > The lifetime of the mapping in the in-home residential NAT >> doesn't >> > > > matter for this attack. >> > > > >> > > Thomas=3D> >> > > You are right, it has nothing to do with attack. >> > > I mean when we take consideration of two level NATs on draft-PCP- >> base, >> > > there will be a lifetime disaccord problem. When the lifetime of >> > > mapping entry in inner NAT expired, the mapping entry in outer NAT >> > > still active. >> > >> > Sure. Not much we can do about that. (I see Sam answered this >> > point in more detail over the weekend.) >> > >> > -d >> > >> > >> > > The remote user can't access the server on PCP client >> > > host, but it seems that CGN works better. >> > > >> > > >> > > >> > > >> > > > >> > > > > 3. The Inner NAT function on CPE may be shut down for some >> reasons, >> > > how >> > > > > could the PCP client know the dynamic change on CPE? >> > > > >> > > > If the in-home residential NAT is bridging (and is not a NAT), >> this >> > > > PCP attack is not possible. >> > > > >> > > Thomas=3D> >> > > Right, but PCP client needs to know whether inner NAT shuts down to >> > > decide whether it constructs PCP request's PCP Client's IP address >> with >> > > source address or external IP address from inner NAT. I think there >> are >> > > varies reason that user will shut down NAT or turn on NAT function >> on >> > > CPE. >> > > >> > > >> > > > >> > > > > 4.How could the PCP client know the external IP address on >> inner >> > > NAT? >> > > > >> > > > UPnP IGD, NAT-PMP, or screen-scraping the HTTP, or a human >> reading >> > > > the CLI or HTTP. >> > > > >> > > Thomas=3D> >> > > I remember that UPnP can get the IP address on WAN interface. But >> > > external IP address is a address pool of NAT. IP address on WAN and >> > > external IP address of pool may be the different IP address. >> > > I am not sure in this field. If there are an external IP in UPnP >> > > packets, it will be ok. >> > > >> > > >> > > >> > > > > 5.Is it possible that there are more than one external IP >> address >> > > > > (maybe a private IP address) on inner NAT external Pool? For >> > > example, >> > > > > different external IP for different service. >> > > > >> > > > If the victim and the attacker have different IP addresses, from >> the >> > > > perspective of the carrier's PCP server, this specific PCP attack >> is >> > > > not possible. That occurs if the in-home residential CPE is not >> > > > NATing (as described in (3)) or if separate IP addresses are >> assigned >> > > > to each possible attack & victim host pair. >> > > Thomas=3D> It is ok >> > > >> > > > >> > > > -d >> > > > >> > > > >> > > > > Regards >> > > > > Thomas >> > > > > >> > > > > >> > > > > >> > > > > > -----Original Message----- >> > > > > > From: Dan Wing [mailto:dwing@cisco.com] >> > > > > > Sent: Friday, August 24, 2012 12:49 AM >> > > > > > To: Zhangzongjian (Thomas); pcp@ietf.org >> > > > > > Cc: 'Stuart Cheshire' >> > > > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce >> > > > > > >> > > > > > > -----Original Message----- >> > > > > > > From: Zhangzongjian (Thomas) >> [mailto:zhangzhongjian@huawei.com] >> > > > > > > Sent: Wednesday, August 22, 2012 6:59 PM >> > > > > > > To: Dan Wing; pcp@ietf.org >> > > > > > > Cc: 'Stuart Cheshire' >> > > > > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce >> > > > > > ... >> > > > > > > Thomas=3D> >> > > > > > > Do you mean that the home NAT does not support PCP client, >> PCP >> > > > > proxy >> > > > > > > and upnp-pcp interworking? >> > > > > > >> > > > > > >> > > > > > Correct -- the home NAT, in this attack scenario, is the home >> NAT >> > > > > > that is currently for sale at the local computer store, which >> do >> > > > > > not support PCP and do not know anything about PCP. >> > > > > > >> > > > > > >> > > > > > > But, how could the victim host create the MAP entries? >> > > > > > >> > > > > > The victim's host supports PCP in its application (or its >> > > > > > operating system), which sends the PCP request to the CGN >> > > > > > directly. >> > > > > > >> > > > > > >> > > > > > > As you know the home NAT will change the source IP address >> of >> > > PCP >> > > > > > > request from hosts. This will result to mis-match with " >> PCP >> > > > > Client's >> > > > > > > IP Address" in PCP request heard. Then PCP server will >> return >> > > an >> > > > > > > ADDRESS_MISMATCH error without creating MAP entry. >> > > > > > >> > > > > > The PCP client in the (victim) host can overcome that by >> placing >> > > the >> > > > > > WAN address of the NAT into the PCP Client IP Address field >> of >> > > the >> > > > > > PCP packet. >> > > > > > >> > > > > > In -27, we have tentatively added: >> > > > > > >> > > > > > When such >> > > > > > an intervening non-PCP-aware inner NAT is detected, >> mappings >> > > must >> > > > > > first be created by some other means in the inner NAT, >> before >> > > > > > mappings can be usefully created in the outer PCP- >> controlled >> > > NAT. >> > > > > > Having created mappings in the inner NAT by some other >> means, >> > > the >> > > > > PCP >> > > > > > client should then use the inner NAT's External Address as >> the >> > > > > Client >> > > > > > IP Address, to signal to the outer PCP-controlled NAT that >> the >> > > > > client >> > > > > > is aware of the inner NAT, and has taken steps to create >> > > mappings >> > > > > in >> > > > > > it by some other means, so that mappings created in the >> outer >> > > NAT >> > > > > > will not be a pointless waste of state. >> > > > > > >> > > > > > -d >> > > > > > >> > > > > > >> > > > > > > Draft-ietf-pcp-base-26 tells something about mis-match. >> Below >> > > are >> > > > > > > copied from last paragraph of chart 8.2 for reference. >> > > > > > > >> > > > > > > The PCP server compares the source IP address (from the >> > > received IP >> > > > > > > header) with the field PCP Client IP Address. If they >> do >> > > not >> > > > > match, >> > > > > > > the error ADDRESS_MISMATCH MUST be returned. This is >> done >> > > to >> > > > > > detect >> > > > > > > and prevent accidental use of PCP where a non-PCP-aware >> NAT >> > > > > exists >> > > > > > > between the PCP client and PCP server. If the PCP >> client >> > > wants >> > > > > such >> > > > > > > a mapping it needs to ensure the PCP field matches its >> > > apparent >> > > > > IP >> > > > > > > address from the perspective of the PCP server. >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > -d >> > > > > > > > >> > > > > > > > > When home NAT receives a PCP MAP request with >> lifetime=3D0 >> > > from >> > > > > > > attacker, >> > > > > > > > > it should add a third party option with the attacker's >> IP >> > > > > address >> > > > > > > in >> > > > > > > > > this option. When CGN gets the PCP request, it will use >> the >> > > > > third >> > > > > > > party >> > > > > > > > > option address as the source address to search the MAP >> > > entries. >> > > > > > > Then >> > > > > > > > > the attacker can't delete the MAP entry created by >> victim. >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > > address spoofing. 120 seconds later (per REQ-8 of >> > > > > > > > > > draft-ietf-behave-lsn-requirements-09), the attacker >> > > sends a >> > > > > new >> > > > > > > PCP >> > > > > > > > > MAP >> > > > > > > > > > request to try to acquire the (old) mapping of the >> victim >> > > > > host. >> > > > > > > In >> > > > > > > > > this >> > > > > > > > > > way, the attacker steals incoming traffic intended to >> go >> > > to >> > > > > the >> > > > > > > > > victim host. >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > Diagram: >> > > > > > > > > > >> > > > > > > > > > +-------------+ +----------+ >> > > > > > > > > > attacker -------+ | | | >> > > > > > > > > > (guest network) | | | | >> > > > > > > > > > | home NAT +----+ CGN >> > > > > > +----{Internet} >> > > > > > > > > > victim ---------+(without PCP)| |(with PCP)| >> > > > > > > > > > (wired network) | | | | >> > > > > > > > > > +-------------+ +----------+ >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > Please provide us feedback. I expect to publish -27 >> soon >> > > > > with >> > > > > > > these >> > > > > > > > > > changes, but we are doing some text coordination >> before >> > > > > > > publishing - >> > > > > > > > > 27. >> > > > > > > > > > >> > > > > > > > > > -d >> > > > > > > > > > >> > > > > > > > > > ----- >> > > > > > > > > > >> > > > > > > > > > REQ-9: A CGN MUST implement a protocol giving >> > > subscribers >> > > > > > > > > explicit >> > > > > > > > > > control over NAT mappings. That protocol >> > > SHOULD >> > > > > be >> > > > > > > the >> > > > > > > > > Port >> > > > > > > > > > Control Protocol [I-D.ietf-pcp-base], in >> which >> > > > > case >> > > > > > > the >> > > > > > > > > PCP >> > > > > > > > > > server MUST obey the following constraints >> on >> > > its >> > > > > > > > > behavior: >> > > > > > > > > > >> > > > > > > > > > A. It MUST NOT permit the lifetime of a >> > > mapping >> > > > > to be >> > > > > > > > > > reduced beyond its current life or be >> set >> > > to >> > > > > zero >> > > > > > > > > > (deleted). >> > > > > > > > > > >> > > > > > > > > > B. It MUST NOT permit a NAT mapping to be >> > > created >> > > > > > > with a >> > > > > > > > > > lifetime less than the lifetime used >> for >> > > > > implicit >> > > > > > > > > > mappings. >> > > > > > > > > > >> > > > > > > > > > C. It MUST NOT support the THIRD_PARTY >> > option >> > > > > > except >> > > > > > > > for >> > > > > > > > > > requests received from "trusted" >> sources >> > > where >> > > > > it >> > > > > > > is >> > > > > > > > > > impractical for those sources to be >> > > spoofed. >> > > > > > > > > > >> > > > > > > > > > D. The MAP opcode MAY be permitted if the >> > > > > > > > recommendation >> > > > > > > > > > of >> > > > > > > > > > endpoint independent filtering >> behavior >> > > > > described >> > > > > > > in >> > > > > > > > > > REQ-7 is adopted; the map opcode MUST >> NOT >> > > be >> > > > > > > > permitted >> > > > > > > > > > in >> > > > > > > > > > other circumstances. These >> constraints >> > > MAY >> > > > be >> > > > > > > > relaxed >> > > > > > > > > if >> > > > > > > > > > a security mechanism consistent with >> PCP's >> > > > > > > Advanced >> > > > > > > > > > Threat Model (see Section 17.2 of [I- >> > > D.ietf- >> > > > > pcp- >> > > > > > > base]) >> > > > > > > > > is >> > > > > > > > > > used; this is expected to be rare for >> CGN >> > > > > > > deployments. >> > > > > > > > > > >> > > > > > > > > > E. Mappings created by PCP MUST follow >> the >> > > same >> > > > > > > > > deallocation >> > > > > > > > > > behavior (REQ-8) as implicitly mapped >> > > traffic. >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > _______________________________________________ >> > > > > > > > > > pcp mailing list >> > > > > > > > > > pcp@ietf.org >> > > > > > > > > > https://www.ietf.org/mailman/listinfo/pcp >> > > > > > > > > >> > > > > > > > > Best regards >> > > > > > > > > Thomas > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From subirdas21@gmail.com Wed Aug 29 06:26:56 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C79021F865B for ; Wed, 29 Aug 2012 06:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnBxG6coXxPx for ; Wed, 29 Aug 2012 06:26:55 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 534CA21F866B for ; Wed, 29 Aug 2012 06:26:55 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so740400vcb.31 for ; Wed, 29 Aug 2012 06:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7ZbIY/lez4vunwDQ82Siy3tKUa4ehJ09MNFKSkoPzCg=; b=benDINbO3ApInM46qM+TKU4iC1aH+4jCPPC23KPBeWjAbWCkybnrhRtPl8KVoScG75 h1TzmMZBf/uMgr3mCG8sfkVxvWdnuMtc+J2VWp5m2acfx31TklZkVOXGXcb/e3JjgwXm YqNvM6+vEA1UfX0RtpmDlPSOffsOLG6XipXWyhkUtLM/1ql+0mmExvXtgS75GG1z6oRm 0X6JyobfMpXZkLDP118v01PLLoLOdXFXFFsZSp0xvLND0db1+XZ/0t/ChVnkdw8rej5E zn4FVrKabRfQXufcj2vcWCOsym5XOkhoS9h90v9HjdJ5CYZ9pJf65eMRiMviMx5SuNY4 WoSg== MIME-Version: 1.0 Received: by 10.220.150.211 with SMTP id z19mr1109497vcv.48.1346246814493; Wed, 29 Aug 2012 06:26:54 -0700 (PDT) Received: by 10.58.155.170 with HTTP; Wed, 29 Aug 2012 06:26:54 -0700 (PDT) In-Reply-To: References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <2340495D-0811-42DD-B0D3-636499A0D802@lilacglade.org> Date: Wed, 29 Aug 2012 09:26:54 -0400 Message-ID: From: Subir Das To: Margaret Wasserman Content-Type: multipart/alternative; boundary=f46d043c8224286b4204c8678370 Cc: "pcp@ietf.org" Subject: [pcp] Fwd: Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 13:26:56 -0000 --f46d043c8224286b4204c8678370 Content-Type: text/plain; charset=ISO-8859-1 Margaret, I realized that I didn't copy my mail to the mailing list. Thanks, -Subir ---------- Forwarded message ---------- From: Subir Das Date: Fri, Aug 17, 2012 at 8:29 AM Subject: Re: [pcp] Comparison of PCP authentication To: Margaret Wasserman Hi Margaret, My recollection regarding conclusion was little different: We will discuss the following two PANA-based approaches and then decide: - PANA Encapsulated in PCP - PANA Demultiplexed with PCP on the same port The consensus in the room was that PANA-based approach is preferrable over PCP specific approach. I need to look at the meeting minutes and recording though. regards, _Subir On Thu, Aug 16, 2012 at 7:38 AM, Margaret Wasserman wrote: > > > Hi Dacheng, > > The conclusion from the meeting was that we will document all three > approaches in our document: > > - PCP Specific > - PANA Encapsulated in PCP > - PANA Demultiplexed with PCP on the same port > > Then, we will have an interim PCP conference call to discuss the > trade-offs and hopefully decide between them. > > Margaret > > > > On Aug 15, 2012, at 10:47 PM, Zhangdacheng (Dacheng) wrote: > > Have we got any conclusions on two approaches? Or we can just support the > two options in the draft for the moment and briefly compare their pros and > cons, can we?**** > ** ** > Cheers**** > ** ** > Dcheng**** > ** ** > *From:* pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] *On Behalf Of *Margaret > Wasserman > *Sent:* Friday, August 10, 2012 3:21 AM > *To:* Dan Wing > *Cc:* pcp@ietf.org > *Subject:* Re: [pcp] Comparison of PCP authentication**** > ** ** > ** ** > On Aug 9, 2012, at 2:32 PM, Dan Wing wrote:**** > > ** ** > > If I'm updating security policy on a firewall I want to be able to**** > > audit whether that actually happened. That requires authentication.**** > > > You are saying a PCP client would only want to update firewall policies > if the PCP server supports authentication, otherwise it would tell the > user that it cannot enable the webcam, Internet-connected NAS, > Internet-connected printer, etc.?**** > > ** ** > I wont presume to guess what Sam is thinking...**** > ** ** > However, I am thinking that there will be some clients that are > configured to perform authentication for every request. For example, there > is no reason for a PCP proxy, running in an environment where > authentication is required to do a THIRD-PARTY request, to perform a > useless round-trip for every THIRD-PARTY request it issues. **** > ** ** > Margaret**** > ** ** > ** ** > > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > > --f46d043c8224286b4204c8678370 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Margaret,
I realized that I didn't copy=A0my =A0mail to = the mailing list.
=A0
Thanks,
-Subir
---------- Forwarded message ----------From: Subir Das <<= a href=3D"mailto:subirdas21@gmail.com">subirdas21@gmail.com><= br> Date: Fri, Aug 17, 2012 at 8:29 AM
Subject: Re: [pcp] Comparison of PCP = authentication
To: Margaret Wasserman <margaretw42@gmail.com>


Hi Margaret,
My recollection regarding conclusion was little different:
= =A0
We will discuss=A0=A0the following two PANA-based approaches = and then decide:
=A0
- PANA Encapsula= ted in PCP
- PANA Demultiplexed with PCP on the same= port
=A0
The consensus in the room =A0was that P= ANA-based approach is preferrable over PCP specific approach. I need to loo= k at the meeting minutes and recording though.
=A0
regards,
_Subir

On Thu, Aug 16, 2012 at 7:38 AM, Margar= et Wasserman <margaretw42@gmail.com> wrote:


Hi Dacheng,

The conclusion from the mee= ting was that we will document all three approaches in our document:
<= div>
- PCP Specific
- PANA Encapsulated in PCP
- PANA Demultiplexed with PCP on the same port

Then, we will have an interim PCP conference call to discuss the trade-of= fs and hopefully decide between them.

Margaret


On Aug 15, 2012, at 10:47 PM, Zhangdacheng (Dach= eng) wrote:

Have we got any conclusio= ns on two approaches?=A0 Or we can just support the two options in the draf= t for the moment and briefly compare their pros and cons, can we?=
=A0
=
Cheers
=A0
= Dcheng
=A0
=
Fr= om:=A0pcp-bounces@ie= tf.org=A0[mailto:pcp-bounces@ietf.org]=A0On Behalf Of=A0Margaret Wasserman
Sent:=A0Friday, August 10, 2012 3:21 AM
To:=A0Dan Wing
Cc:=A0p= cp@ietf.org
Subject:=A0Re: [pcp] Comparison of PCP authentication
=A0
=A0
On Aug 9, 2012, at 2:32 PM, Dan Wing wrote:<= /u>
=A0
If I'm updating security policy on a firewall I want to be a= ble to
audit whether that actually happened. =A0= That requires authentication.

You are saying a = PCP client would only want to update firewall policies=A0
i= f the PCP server supports authentication, otherwise it would tell the
user that it cannot enable the webcam, Internet-connected NAS,=A0
Internet-connected printer, etc.?
=A0
I wont presume to guess what Sam is thinking...=
=A0
However, I am thinking that there will be some clients= =A0that are configured to perform authentication for every request. =A0For= example, there is no reason for a PCP proxy, running in an environment whe= re authentication is required to do a THIRD-PARTY request, to perform a use= less round-trip for every THIRD-PARTY request it issues. =A0<= /span>
=A0
Margaret
=A0
<= div style=3D"margin:0cm 0cm 0pt;font-family:"Times New Roman",ser= if;font-size:12pt"> =A0
=


_______________________________________________
pcp mailing list
pcp@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pcp



--f46d043c8224286b4204c8678370-- From dwing@cisco.com Wed Aug 29 08:59:14 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A2B21F85AF for ; Wed, 29 Aug 2012 08:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.497 X-Spam-Level: X-Spam-Status: No, score=-110.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCkcgu+GDT+T for ; Wed, 29 Aug 2012 08:59:13 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id A01FA21F85AA for ; Wed, 29 Aug 2012 08:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4203; q=dns/txt; s=iport; t=1346255953; x=1347465553; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=LnG1l6QFJys/N4GgDbCKFJKe+e8QIYwlaZKcOD9rmUQ=; b=jUiE8yk/VCYQ6mb2edId3Gbhit9GxgGRBPFI4nhUjTRbsDVCC4iKUqr8 +/ac/qb6aHU0A2H+DiXeY8+PjiHJfLQUBLFxZX2KEXS+Jf0VaSzyjt70Z wlvuVWRn/ch18/VkPOY0Fm0Ty+neKZqLy22Z2LJ+5MUNGdAfO9/1xrYtX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAH47PlCrRDoH/2dsb2JhbABFqwaPa4EHgiABAQEEAQEBBQoBFxAuBgsMAQMCCQ8CAwEBAQEnBxkIBhUKCQgBAQQBEgkCEAMEh1wDCwybQ41iiHQNiU6KJWMahj8DiE+FDYYnjGGDIIFngwOBQQ X-IronPort-AV: E=Sophos;i="4.80,335,1344211200"; d="scan'208";a="56480635" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 29 Aug 2012 15:59:12 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7TFxBuJ010760; Wed, 29 Aug 2012 15:59:12 GMT From: "Dan Wing" To: "'Subir Das'" , "'Margaret Wasserman'" References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <2340495D-0811-42DD-B0D3-636499A0D802@lilacglade.org> In-Reply-To: Date: Wed, 29 Aug 2012 08:59:11 -0700 Message-ID: <012301cd85ff$3b451430$b1cf3c90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2F6fp9kdlxwkgZRrGfKW2gvcKRGwAFBCPQ Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] Fwd: Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 15:59:14 -0000 I went to the audio, to try to understand this resistance to analyzing everything. The discussion of the three options started at about 77 minutes into the audio, which is at http://www.ietf.org/audio/ietf84/ietf84-regencya-20120802-1510-pm2.mp3. The audio quality is pretty poor. I heard: 1. separate PCP-dedicated function: 4 hands 2. PANA 'tunnel': ? hands (I could not hear) 3. PCP/PANA demux: 5 hands 4. don't care: ? hands (I could not hear) then, after a little more hand-raising, PANA had twice the votes of a separate PCP-dedicated function. Alain said the direction is PANA on a single port. I then heard myself asking at the microphone that I answered "don't care" because I lack enough information to decide. I couldn't hear Margaret's reply in the audio. In any event, I am struggling to understand the resistance to analyzing all three in detail. Worried a non-PANA solution will win, or the analysis will take an additional 15 minutes, or what? -d > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Subir Das > Sent: Wednesday, August 29, 2012 6:27 AM > To: Margaret Wasserman > Cc: pcp@ietf.org > Subject: [pcp] Fwd: Comparison of PCP authentication > > Margaret, > I realized that I didn't copy my mail to the mailing list. > > Thanks, > -Subir > > > ---------- Forwarded message ---------- > From: Subir Das > Date: Fri, Aug 17, 2012 at 8:29 AM > Subject: Re: [pcp] Comparison of PCP authentication > To: Margaret Wasserman > > > > Hi Margaret, > My recollection regarding conclusion was little different: > > We will discuss the following two PANA-based approaches and then > decide: > > - PANA Encapsulated in PCP > - PANA Demultiplexed with PCP on the same port > > The consensus in the room was that PANA-based approach is preferrable > over PCP specific approach. I need to look at the meeting minutes and > recording though. > > regards, > _Subir > > On Thu, Aug 16, 2012 at 7:38 AM, Margaret Wasserman > wrote: > > > > > Hi Dacheng, > > The conclusion from the meeting was that we will document all > three approaches in our document: > > - PCP Specific > - PANA Encapsulated in PCP > - PANA Demultiplexed with PCP on the same port > > Then, we will have an interim PCP conference call to discuss the > trade-offs and hopefully decide between them. > > > Margaret > > > > On Aug 15, 2012, at 10:47 PM, Zhangdacheng (Dacheng) wrote: > > > > Have we got any conclusions on two approaches? Or we can > just support the two options in the draft for the moment and briefly > compare their pros and cons, can we? > > Cheers > > Dcheng > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On > Behalf Of Margaret Wasserman > Sent: Friday, August 10, 2012 3:21 AM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] Comparison of PCP authentication > > > On Aug 9, 2012, at 2:32 PM, Dan Wing wrote: > > > > If I'm updating security policy on a firewall I > want to be able to > > audit whether that actually happened. That > requires authentication. > > > You are saying a PCP client would only want to update > firewall policies > if the PCP server supports authentication, otherwise > it would tell the > user that it cannot enable the webcam, Internet- > connected NAS, > Internet-connected printer, etc.? > > > I wont presume to guess what Sam is thinking... > > However, I am thinking that there will be some clients > that are configured to perform authentication for every request. For > example, there is no reason for a PCP proxy, running in an environment > where authentication is required to do a THIRD-PARTY request, to > perform a useless round-trip for every THIRD-PARTY request it issues. > > Margaret > > > > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > > > > From subirdas21@gmail.com Wed Aug 29 10:19:35 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D29C21F861C for ; Wed, 29 Aug 2012 10:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oySIBP1KBCDm for ; Wed, 29 Aug 2012 10:19:31 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C5E2821F8615 for ; Wed, 29 Aug 2012 10:19:30 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1046240vbb.31 for ; Wed, 29 Aug 2012 10:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lxgRZ5G2EAtOAxl7zLGOIoS+kYS3xVFSldmgOTU73ZU=; b=kxq3e6Fyhbh4xqzi4quoN6UjJL1gcpxVNgMNTC+0f/2mFcWUJRuIZBwbL1ZI+dRdrM Y88m3p8N+F+9TLXxWSZrIqeMXEGiENiqe8LVO+bw/7ZyqmlXl6JfMMIYRj/IQ6fqmOyt tFOFt7IRefNmI4ExdlmMsS5ulFaPPHDgAHfMMy97AmsfvRXjTBw1yMYDLqFlW1utf7rq byGNOvqjuZUQYk4LycnfdQUXYEtEZxkMPmdtyvK6TANI9/tTD7mOXu6OPKtBfzTPMpTm sfV6yhPfwXVyzCJpLAEPqmZ9aUM5cPo8XalmM+KCEi+Qrff0A6hazMjBTkumhLVDD+1k Z/5w== MIME-Version: 1.0 Received: by 10.52.33.15 with SMTP id n15mr1221918vdi.67.1346260769879; Wed, 29 Aug 2012 10:19:29 -0700 (PDT) Received: by 10.58.155.170 with HTTP; Wed, 29 Aug 2012 10:19:29 -0700 (PDT) In-Reply-To: <012301cd85ff$3b451430$b1cf3c90$@com> References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <2340495D-0811-42DD-B0D3-636499A0D802@lilacglade.org> <012301cd85ff$3b451430$b1cf3c90$@com> Date: Wed, 29 Aug 2012 13:19:29 -0400 Message-ID: From: Subir Das To: Dan Wing Content-Type: multipart/alternative; boundary=20cf307c9bdcf6b66904c86ac24b Cc: pcp@ietf.org Subject: Re: [pcp] Fwd: Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 17:19:35 -0000 --20cf307c9bdcf6b66904c86ac24b Content-Type: text/plain; charset=ISO-8859-1 I also tried the audio and it was very poor. You have summarized it nicely though. I am not resisting anything, I was merely stating my takeway on Chair's statement. -Subir On Wed, Aug 29, 2012 at 11:59 AM, Dan Wing wrote: > I went to the audio, to try to understand this resistance to analyzing > everything. > > The discussion of the three options started at about 77 minutes into the > audio, which is at > http://www.ietf.org/audio/ietf84/ietf84-regencya-20120802-1510-pm2.mp3. > The > audio quality is pretty poor. > > I heard: > 1. separate PCP-dedicated function: 4 hands > 2. PANA 'tunnel': ? hands (I could not hear) > 3. PCP/PANA demux: 5 hands > 4. don't care: ? hands (I could not hear) > > then, after a little more hand-raising, PANA had twice the votes of a > separate PCP-dedicated function. Alain said the direction is PANA on a > single port. I then heard myself asking at the microphone that I answered > "don't care" because I lack enough information to decide. I couldn't hear > Margaret's reply in the audio. > > > In any event, I am struggling to understand the resistance to analyzing all > three in detail. Worried a non-PANA solution will win, or the analysis > will > take an additional 15 minutes, or what? > > -d > > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > > Subir Das > > Sent: Wednesday, August 29, 2012 6:27 AM > > To: Margaret Wasserman > > Cc: pcp@ietf.org > > Subject: [pcp] Fwd: Comparison of PCP authentication > > > > Margaret, > > I realized that I didn't copy my mail to the mailing list. > > > > Thanks, > > -Subir > > > > > > ---------- Forwarded message ---------- > > From: Subir Das > > Date: Fri, Aug 17, 2012 at 8:29 AM > > Subject: Re: [pcp] Comparison of PCP authentication > > To: Margaret Wasserman > > > > > > > > Hi Margaret, > > My recollection regarding conclusion was little different: > > > > We will discuss the following two PANA-based approaches and then > > decide: > > > > - PANA Encapsulated in PCP > > - PANA Demultiplexed with PCP on the same port > > > > The consensus in the room was that PANA-based approach is preferrable > > over PCP specific approach. I need to look at the meeting minutes and > > recording though. > > > > regards, > > _Subir > > > > On Thu, Aug 16, 2012 at 7:38 AM, Margaret Wasserman > > wrote: > > > > > > > > > > Hi Dacheng, > > > > The conclusion from the meeting was that we will document all > > three approaches in our document: > > > > - PCP Specific > > - PANA Encapsulated in PCP > > - PANA Demultiplexed with PCP on the same port > > > > Then, we will have an interim PCP conference call to discuss the > > trade-offs and hopefully decide between them. > > > > > > Margaret > > > > > > > > On Aug 15, 2012, at 10:47 PM, Zhangdacheng (Dacheng) wrote: > > > > > > > > Have we got any conclusions on two approaches? Or we can > > just support the two options in the draft for the moment and briefly > > compare their pros and cons, can we? > > > > Cheers > > > > Dcheng > > > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] > On > > Behalf Of Margaret Wasserman > > Sent: Friday, August 10, 2012 3:21 AM > > To: Dan Wing > > Cc: pcp@ietf.org > > Subject: Re: [pcp] Comparison of PCP authentication > > > > > > On Aug 9, 2012, at 2:32 PM, Dan Wing wrote: > > > > > > > > If I'm updating security policy on a > firewall I > > want to be able to > > > > audit whether that actually happened. That > > requires authentication. > > > > > > You are saying a PCP client would only want to > update > > firewall policies > > if the PCP server supports authentication, > otherwise > > it would tell the > > user that it cannot enable the webcam, Internet- > > connected NAS, > > Internet-connected printer, etc.? > > > > > > I wont presume to guess what Sam is thinking... > > > > However, I am thinking that there will be some clients > > that are configured to perform authentication for every request. For > > example, there is no reason for a PCP proxy, running in an environment > > where authentication is required to do a THIRD-PARTY request, to > > perform a useless round-trip for every THIRD-PARTY request it issues. > > > > Margaret > > > > > > > > > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp > > > > > > > > > > > --20cf307c9bdcf6b66904c86ac24b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I also tried the audio and it=A0was very poor. You have summarized it = nicely though. I=A0am not resisting anything, I was merely stating my takew= ay on Chair's=A0statement. =A0
=A0
-Subir

<= /div>
On Wed, Aug 29, 2012 at 11:59 AM, Dan Wing <dwing@cisco.com> w= rote:
I went to the audio, to try to understand this resistance = to analyzing
everything.

The discussion of the three options started at about 77 minutes into the audio, which is at
http://www.ietf.org/audio/ietf84/ietf84-regencya-= 20120802-1510-pm2.mp3. =A0The
audio quality is pretty poor.

I heard:
=A01. =A0separate PCP-dedicated function: =A04 hands
=A02. =A0PANA 'tunnel': ? hands (I could not hear)
=A03. =A0PCP/PANA demux: 5 hands
=A04. =A0don't care: =A0? hands (I could not hear)

then, after a little more hand-raising, PANA had twice the votes of a
separate PCP-dedicated function. =A0Alain said the direction is PANA on a single port. =A0I then heard myself asking at the microphone that I answere= d
"don't care" because I lack enough information to decide. =A0= I couldn't hear
Margaret's reply in the audio.


In any event, I am struggling to understand the resistance to analyzing all=
three in detail. =A0Worried a non-PANA solution will win, or the analysis w= ill
take an additional 15 minutes, or what?

-d

> -----Original Message-----
> From: pcp-bo= unces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of
> Subir Das
> Sent: Wednesday, August 29, 2012 6:27 AM
> To: Margaret Wasserman
> Cc: pcp@ietf.org=
> Subject: [pcp] Fwd: Comparison of PCP authentication
>
> Margaret,
> I realized that I didn't copy my =A0mail to the mailing list.
>
> Thanks,
> -Subir
>
>
> ---------- Forwarded message ----------
> From: Subir Das <subirdas21@gmail.com>
> Date: Fri, Aug 17, 2012 at 8:29 AM
> Subject: Re: [pcp] Comparison of PCP authentication
> To: Margaret Wasserman <margaretw42@gmail.com>
>
>
>
> Hi Margaret,
> My recollection regarding conclusion was little different:
>
> We will discuss =A0the following two PANA-based approaches and then > decide:
>
> - PANA Encapsulated in PCP
> - PANA Demultiplexed with PCP on the same port
>
> The consensus in the room =A0was that PANA-based approach is preferrab= le
> over PCP specific approach. I need to look at the meeting minutes and<= br> > recording though.
>
> regards,
> _Subir
>
> On Thu, Aug 16, 2012 at 7:38 AM, Margaret Wasserman
> <margare= tw42@gmail.com> wrote:
>
>
>
>
> =A0 =A0 =A0 Hi Dacheng,
>
> =A0 =A0 =A0 The conclusion from the meeting was that we will document = all
> three approaches in our document:
>
> =A0 =A0 =A0 - PCP Specific
> =A0 =A0 =A0 - PANA Encapsulated in PCP
> =A0 =A0 =A0 - PANA Demultiplexed with PCP on the same port
>
> =A0 =A0 =A0 Then, we will have an interim PCP conference call to discu= ss the
> trade-offs and hopefully decide between them.
>
>
> =A0 =A0 =A0 Margaret
>
>
>
> =A0 =A0 =A0 On Aug 15, 2012, at 10:47 PM, Zhangdacheng (Dacheng) wrote= :
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Have we got any conclusions on two approac= hes? =A0Or we can
> just support the two options in the draft for the moment and briefly > compare their pros and cons, can we?
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cheers
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Dcheng
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On
> Behalf Of Margaret Wasserman
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sent: Friday, August 10, 2012 3:21 AM
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 To: Dan Wing
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cc: pcp@ietf.org
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Subject: Re: [pcp] Comparison of PCP authe= ntication
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 On Aug 9, 2012, at 2:32 PM, Dan Wing wrote= :
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If I'm= updating security policy on a
firewall I
> want to be able to
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 audit whet= her that actually happened. =A0That
> requires authentication.
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 You are saying a PCP clien= t would only want to
update
> firewall policies
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if the PCP server supports= authentication, otherwise
> it would tell the
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 user that it cannot enable= the webcam, Internet-
> connected NAS,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Internet-connected printer= , etc.?
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 I wont presume to guess what Sam is thinki= ng...
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 However, I am thinking that there will be = some clients
> that are configured to perform authentication for every request. =A0Fo= r
> example, there is no reason for a PCP proxy, running in an environment=
> where authentication is required to do a THIRD-PARTY request, to
> perform a useless round-trip for every THIRD-PARTY request it issues.<= br> >
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Margaret
>
>
>
>
>
> =A0 =A0 =A0 _______________________________________________
> =A0 =A0 =A0 pcp mailing list
> =A0 =A0 =A0 pcp@ietf= .org
> =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/pcp
>
>
>
>



--20cf307c9bdcf6b66904c86ac24b-- From hartmans@painless-security.com Wed Aug 29 11:20:53 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205E311E80E2 for ; Wed, 29 Aug 2012 11:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.398 X-Spam-Level: **** X-Spam-Status: No, score=4.398 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUF5IlVGc+it for ; Wed, 29 Aug 2012 11:20:52 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFD311E80E0 for ; Wed, 29 Aug 2012 11:20:52 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5E2635C047; Wed, 29 Aug 2012 14:20:46 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2AD0A4350; Wed, 29 Aug 2012 14:20:47 -0400 (EDT) From: Sam Hartman To: "Dan Wing" References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <003b01cd7587$a111b760$e3352620$@com> <15990E87-2D59-49B1-845C-2A4CB5A1FBD6@lilacglade.org> <008801cd758f$3fd306e0$bf7914a0$@com> <028801cd75d6$c5765490$5062fdb0$@com> <04c901cd7658$37a740c0$a6f5c240$@com> <054001cd765d$54c0f3e0$fe42dba0$@com> <0F259BA1-CEFF-4346-AFE5-3D33BB0CF0CC@lilacglade.org> <2340495D-0811-42DD-B0D3-636499A0D802@lilacglade.org> <012301cd85ff$3b451430$b1cf3c90$@com> Date: Wed, 29 Aug 2012 14:20:47 -0400 In-Reply-To: <012301cd85ff$3b451430$b1cf3c90$@com> (Dan Wing's message of "Wed, 29 Aug 2012 08:59:11 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] Fwd: Comparison of PCP authentication X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 18:20:53 -0000 I was not at the meeting. I'll note a couple of IETF process points though; RFC 2418 is a good read on issues like this: 1) This decision would need to be confirmed on the list anyway; a consensus of the room does not make a decision. 2) Let's say that there were 8 hands in favor of PANA onsame port and 4 hands in favor of PCP-specific. That's kind of questionable as a rough consensus. It's certainly sufficient to say that the room was moving towards PANA on same port, but 2/3 is kind of iffy for calling rough consensus depending on the issue and on level of discussion. Certainly, if additional discussion doesn't make things more clear, and if we confirm that the WG is more interested in progress on this issue than blocking (which I suspect strongly it is), then you might eventually make a decision at 2/3. You might make a decision at 2/3 much earlier if no one in the 1/3 cared much. I was not counted in the room, so I'll need to be counted when confirming on the list. I prefer a PCP-specific solution. However, I need more information before I'll be able to say whether I strongly prefer the PCP-specific solution, or whether it's a weak preference among similar technical approaches. I know there are others who have expressed opinions who were not in the room. For example I think Alper has indicated he prefers a PANA-based solution and I believe I recall he could not make the meeting. I definitely would prefer understanding all the options. --Sam