From internet-drafts@ietf.org Mon Jan 6 08:49:22 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F190A1AE04D; Mon, 6 Jan 2014 08:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hx3vnhO0z3SU; Mon, 6 Jan 2014 08:49:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F821AE048; Mon, 6 Jan 2014 08:49:19 -0800 (PST) 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.90.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140106164919.26373.48038.idtracker@ietfa.amsl.com> Date: Mon, 06 Jan 2014 08:49:19 -0800 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-server-selection-02.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 16:49:22 -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 : PCP Server Selection Authors : Mohamed Boucadair Reinaldo Penno Dan Wing Prashanth Patil Tirumaleswar Reddy Filename : draft-ietf-pcp-server-selection-02.txt Pages : 11 Date : 2014-01-06 Abstract: Multiple IP addresses may be configured on a PCP client in some deployment contexts such as multi-homing. This document specifies the behavior to be followed by the PCP client to contact its PCP server(s) when one or several PCP server IP addresses are configured. This document updates RFC6887. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-server-selection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-server-selection-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-server-selection-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From praspati@cisco.com Mon Jan 6 08:52:34 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE211AE0F1 for ; Mon, 6 Jan 2014 08:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDOjLfmi3BTb for ; Mon, 6 Jan 2014 08:52:32 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 752581AE0D0 for ; Mon, 6 Jan 2014 08:52:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1909; q=dns/txt; s=iport; t=1389027144; x=1390236744; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=V5jwOyYNDuKa6fC7QXKUcXIcpHksSN39qgildlkOVbg=; b=GS9jAufiOxkL6RXjXecv6UU5p826/NKAVJxdhDPMqbSKVqOye6Oh16a+ zM8aBB43tVWnCsipXTF+HwoXSolAqbVHJtxoZBEfjDJE5Ap16juCKSI3E K+6xBQUY/RTsmSEPuZh32OyqsyNHBB6ZJZdLiyObkLMs04tQTovCUceAW M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkGAAveylKtJV2c/2dsb2JhbABYgws4Twa5SIELFnSCJgEBBAEBATc0GwIBCDYQJwslAgQTCYd7CAXDHhePFoQ3BJgXgTCQZYMtgio X-IronPort-AV: E=Sophos;i="4.95,613,1384300800"; d="scan'208";a="295547241" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 06 Jan 2014 16:52:24 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s06GqN09024514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 6 Jan 2014 16:52:24 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.150]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Mon, 6 Jan 2014 10:52:23 -0600 From: "Prashanth Patil (praspati)" To: "pcp@ietf.org" Thread-Topic: [pcp] I-D Action: draft-ietf-pcp-server-selection-02.txt Thread-Index: AQHPCv+rg9QMmdjcakSbxk1PUaz1IQ== Date: Mon, 6 Jan 2014 16:52:22 +0000 Message-ID: References: <20140106164919.26373.48038.idtracker@ietfa.amsl.com> In-Reply-To: <20140106164919.26373.48038.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.78.112] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] I-D Action: draft-ietf-pcp-server-selection-02.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 16:52:34 -0000 Folks, Revised PCP server selection draft has been published. The update addresses comments received from Dave Thaler and the ones at IETF 88. -Prashanth On 1/6/14 10:19 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Port Control Protocol Working Group of >the IETF. > > Title : PCP Server Selection > Authors : Mohamed Boucadair > Reinaldo Penno > Dan Wing > Prashanth Patil > Tirumaleswar Reddy > Filename : draft-ietf-pcp-server-selection-02.txt > Pages : 11 > Date : 2014-01-06 > >Abstract: > Multiple IP addresses may be configured on a PCP client in some > deployment contexts such as multi-homing. This document specifies > the behavior to be followed by the PCP client to contact its PCP > server(s) when one or several PCP server IP addresses are configured. > > This document updates RFC6887. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-pcp-server-selection/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-pcp-server-selection-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-server-selection-02 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >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 sureshk@juniper.net Mon Jan 6 20:48:53 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286321AE42F for ; Mon, 6 Jan 2014 20:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVZf4zMPVhvp for ; Mon, 6 Jan 2014 20:48:50 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAC41AE42D for ; Mon, 6 Jan 2014 20:48:50 -0800 (PST) Received: from mail176-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 7 Jan 2014 04:48:41 +0000 Received: from mail176-va3 (localhost [127.0.0.1]) by mail176-va3-R.bigfish.com (Postfix) with ESMTP id 4536E1E018F; Tue, 7 Jan 2014 04:48:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -17 X-BigFish: VPS-17(z579eh5621h3fb8kzc85fhzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h209eh20f0h2216h22d0h2336h1155h) Received-SPF: pass (mail176-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=sureshk@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(199002)(189002)(66066001)(74366001)(15975445006)(36756003)(76482001)(80022001)(65816001)(83506001)(80976001)(59766001)(54356001)(76786001)(79102001)(46102001)(81816001)(220493001)(54316002)(56776001)(19580395003)(53806001)(83322001)(76796001)(51856001)(90146001)(76176001)(47976001)(77982001)(74502001)(2656002)(16236675002)(74876001)(50986001)(47446002)(87266001)(47736001)(81686001)(49866001)(63696002)(81342001)(69226001)(15202345003)(4396001)(85306002)(74662001)(83072002)(81542001)(85852003)(56816005)(87936001)(74706001)(31966008)(163123001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR05MB287; H:DM2PR05MB288.namprd05.prod.outlook.com; CLIP:66.129.239.10; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail176-va3 (localhost.localdomain [127.0.0.1]) by mail176-va3 (MessageSwitch) id 1389070118447622_32521; Tue, 7 Jan 2014 04:48:38 +0000 (UTC) Received: from VA3EHSMHS004.bigfish.com (unknown [10.7.14.231]) by mail176-va3.bigfish.com (Postfix) with ESMTP id 67D861A0047; Tue, 7 Jan 2014 04:48:38 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS004.bigfish.com (10.7.99.14) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 7 Jan 2014 04:48:38 +0000 Received: from DM2PR05MB287.namprd05.prod.outlook.com (10.141.101.27) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.395.1; Tue, 7 Jan 2014 04:48:37 +0000 Received: from DM2PR05MB288.namprd05.prod.outlook.com (10.141.101.11) by DM2PR05MB287.namprd05.prod.outlook.com (10.141.101.27) with Microsoft SMTP Server (TLS) id 15.0.842.7; Tue, 7 Jan 2014 04:48:35 +0000 Received: from DM2PR05MB288.namprd05.prod.outlook.com ([10.141.101.11]) by DM2PR05MB288.namprd05.prod.outlook.com ([10.141.101.11]) with mapi id 15.00.0842.003; Tue, 7 Jan 2014 04:48:35 +0000 From: Suresh Kumar Vinapamula Venkata To: "Tirumaleswar Reddy (tireddy)" , "Reinaldo Penno (repenno)" , "Dan Wing (dwing)" , "praspati@cisco.com" Thread-Topic: Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) Thread-Index: AQHPCKSZkUiuNHzC/E6jbju6rMAZpA== Date: Tue, 7 Jan 2014 04:48:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [66.129.239.10] x-forefront-prvs: 008421A8FF Content-Type: multipart/alternative; boundary="_000_CEEC2B2E2BA0Dsureshkjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "pcp@ietf.org" Subject: [pcp] Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 04:48:53 -0000 --_000_CEEC2B2E2BA0Dsureshkjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tiru, Interesting draft, here are my initial comments. 1. Why can't we achieve this with http://tools.ietf.org/html/draft-wasse= rman-pcp-authentication-02 and RFC6887. 2. What is the significance of third party authorization here? There wil= l anyway be admin configuration rules, whether to honor a PCP request from = a client or not. 3. How would applications detect that they are behind NAT and they shoul= d contact PCP server for opening ports for the data connections? 4. This draft proposes a mechanism where holes are punched in firewall/N= AT using PCP as per application thus eliminating the need of ALGs. Is my un= derstanding correct? Applications behind NAT have to use public IP address = and port, in the payload so that no pay load translation happens in the NAT= box. Wouldn't that not result in rewite of applications and introduce late= ncy? Or, is there another approach? May be a section with migration strateg= y would be helpful. -Suresh --_000_CEEC2B2E2BA0Dsureshkjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <2BFF8D9A4D35644F9E87C823EA4F4648@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Tiru, 

Interesting draft,  here are my initial comments.
  1. Why can't we achieve this with http://tools.ietf.org/html/draft-= wasserman-pcp-authentication-02 and RFC6887.
  2. What is the s= ignificance of third party authorization here? There will anyway be admin c= onfiguration rules, whether to honor a PCP request from a client or not.
  3. How would applications detect that they are behind NAT and they shoul= d contact PCP server for opening ports for the data connections?
  4. Th= is draft proposes a mechanism where holes are punched in firewall/NAT using= PCP as per application thus eliminating the need of ALGs. Is my understand= ing correct? Applications behind NAT have to use public IP address and port= , in the payload so that no pay load translation happens in the NAT box. Wouldn't that not result in r= ewite of applications and introduce latency? Or, is there another approach?= May be a section with migration strategy would be helpful. 
-Suresh
--_000_CEEC2B2E2BA0Dsureshkjunipernet_-- From zhangdacheng@huawei.com Wed Jan 8 22:54:52 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52AA61AE021 for ; Wed, 8 Jan 2014 22:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.738 X-Spam-Level: X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwyWyrCqIoKM for ; Wed, 8 Jan 2014 22:54:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 54E3C1ADFA8 for ; Wed, 8 Jan 2014 22:54:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZT63926; Thu, 09 Jan 2014 06:54:36 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Jan 2014 06:53:59 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Jan 2014 06:54:32 +0000 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.75]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Thu, 9 Jan 2014 14:54:28 +0800 From: "Zhangdacheng (Dacheng)" To: Suresh Kumar Vinapamula Venkata , "Tirumaleswar Reddy (tireddy)" , "Reinaldo Penno (repenno)" , "Dan Wing (dwing)" , "praspati@cisco.com" Thread-Topic: Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) Thread-Index: AQHPCKSZkUiuNHzC/E6jbju6rMAZpJp7/Vhg Date: Thu, 9 Jan 2014 06:54:27 +0000 Message-ID: References: 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.98.139] Content-Type: multipart/alternative; boundary="_000_C72CBD9FE3CA604887B1B3F1D145D05E3B4272C9nkgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pcp@ietf.org" Subject: Re: [pcp] Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 06:54:52 -0000 --_000_C72CBD9FE3CA604887B1B3F1D145D05E3B4272C9nkgeml507mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Interesting discussion, I would like to contribute some comments too: 1) In the security consideration section, maybe it is worthwhile to d= iscuss how to secure the communication between the PCP server and the autho= rization server. It could be reasonable to assume the communication between= the PCP server and the authorization server could be attacked. 2) In the PCP authentication draft, a PCP Auth session has a life per= iod. What will happen if the session expires before the authorization token= the client got from the server expires? 3) Since the authorization work and authorization work are compatible= , we may also need to consider the scenario where the authorization and EAP= authentication are performed concurrently. For instance, is it possible fo= r a PCP client to send the authorization token in the first PCP-Auth messag= e to the PCP server? Or maybe the token should be sent after the EAP authe= ntication has succeeded. 4) In addition, in the PCP authentication draft, there is a result co= de "Authorization Failed", which means the same thing as "AUTHORIZATION_INV= ALID". Can it be re-used in the authorization work? Cheers Dacheng From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Suresh Kumar Vinapamul= a Venkata Sent: Tuesday, January 07, 2014 12:49 PM To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); Dan Wing (dwing= ); praspati@cisco.com Cc: pcp@ietf.org Subject: [pcp] Comments on PCP Extension for Third Party Authorization (htt= p://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) Hi Tiru, Interesting draft, here are my initial comments. 1. Why can't we achieve this with http://tools.ietf.org/html/draft-wasse= rman-pcp-authentication-02 and RFC6887. 2. What is the significance of third party authorization here? There wil= l anyway be admin configuration rules, whether to honor a PCP request from = a client or not. 3. How would applications detect that they are behind NAT and they shoul= d contact PCP server for opening ports for the data connections? 4. This draft proposes a mechanism where holes are punched in firewall/N= AT using PCP as per application thus eliminating the need of ALGs. Is my un= derstanding correct? Applications behind NAT have to use public IP address = and port, in the payload so that no pay load translation happens in the NAT= box. Wouldn't that not result in rewite of applications and introduce late= ncy? Or, is there another approach? May be a section with migration strateg= y would be helpful. -Suresh --_000_C72CBD9FE3CA604887B1B3F1D145D05E3B4272C9nkgeml507mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

Interestin= g discussion, I would like to contribute some  comments too:

1)       In= the security consideration section, maybe it is worthwhile to discuss how = to secure the communication between the PCP server and the authorization server. It could be reasonable to assume the communication b= etween the PCP server and the authorization server could be attacked.

2)       In= the PCP authentication draft, a PCP Auth session has a life period. What w= ill happen if the session expires before the authorization token the client got from the server expires?

3)       Si= nce the authorization work and authorization work are compatible, we may al= so need to consider the scenario where the authorization and EAP authentication are performed concurrently. For instance, is it pos= sible for a PCP client to send the authorization token in the first PCP-Aut= h message to the PCP server?  Or maybe the token should be sent after = the EAP authentication has succeeded.

4)       In= addition, in the PCP authentication draft, there is a result code “A= uthorization Failed”, which means the same thing as “AUTHORIZAT= ION_INVALID”. Can it be re-used in the authorization work?

 = ;

Cheers

 = ;

Dacheng

 = ;

From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Suresh Kumar Vinapamula Venkata
Sent: Tuesday, January 07, 2014 12:49 PM
To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); Dan Wing= (dwing); praspati@cisco.com
Cc: pcp@ietf.org
Subject: [pcp] Comments on PCP Extension for Third Party Authorizati= on (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01= .txt)

 

Hi Tiru,&nbs= p;

 <= /o:p>

Interesting = draft,  here are my initial comments.

  1. Why can't we achieve this with http://to= ols.ietf.org/html/draft-wasserman-pcp-authentication-02 and RFC6887.
  2. What is the significance of third party authori= zation here? There will anyway be admin configuration rules, whether to hon= or a PCP request from a client or not.
  3. How would applications detect that they are beh= ind NAT and they should contact PCP server for opening ports for the data c= onnections?
  4. This draft proposes a mechanism where holes are= punched in firewall/NAT using PCP as per application thus eliminating the = need of ALGs. Is my understanding correct? Applications behind NAT have to use public IP address and port, in the payload so that = no pay load translation happens in the NAT box. Wouldn't that not result in= rewite of applications and introduce latency? Or, is there another approac= h? May be a section with migration strategy would be helpful. 

-Suresh=

--_000_C72CBD9FE3CA604887B1B3F1D145D05E3B4272C9nkgeml507mbschi_-- From tireddy@cisco.com Thu Jan 9 01:38:20 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11C71AE136 for ; Thu, 9 Jan 2014 01:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4HTFK5uEw84 for ; Thu, 9 Jan 2014 01:38:19 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id DAB8D1AE105 for ; Thu, 9 Jan 2014 01:38:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3285; q=dns/txt; s=iport; t=1389260289; x=1390469889; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=YoxRvwPpUkZJKm/AD5DsanZ8KUWm9ZEokOQkC0m7vXY=; b=BbWs6TkSvsIuS2qj2Wxl3MkOM7ngszYA8VHKOZXtuvphyUF6vI821mAf /9tL6ytUJiOllNYv5DLlqUmVGFZ1rZWB0ZXLSoGZNpsj2hKu3dMc6PXAf GyW41SzxOTDfF0vXEEJr10vzB8NpYuB4yFkohR53FK5PVXuVy3/BYZODT o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAIttzlKtJXG+/2dsb2JhbABZgws4VrlEgQ0WdIIlAQEBBHkSAQgRBAEBCxkEORQJCQEEAQ0FCAGHew3EeheOVDGDK4ETBIkLkDyQZYFvgT6BaCQe X-IronPort-AV: E=Sophos;i="4.95,630,1384300800"; d="scan'208";a="11617837" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-7.cisco.com with ESMTP; 09 Jan 2014 09:38:09 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s099c9FN005979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jan 2014 09:38:09 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Thu, 9 Jan 2014 03:38:09 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Suresh Kumar Vinapamula Venkata , "Reinaldo Penno (repenno)" , "Dan Wing (dwing)" , "Prashanth Patil (praspati)" Thread-Topic: Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) Thread-Index: Ac8NHn2TtmgGTL6ISAuvVEHc0hmoSQ== Date: Thu, 9 Jan 2014 09:38:08 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A24285F8B@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.67.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 09:38:21 -0000 Hi Suresh, Thanks for the review. Please see inline From: Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net]=20 Sent: Tuesday, January 07, 2014 10:19 AM To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); Dan Wing (dwing= ); Prashanth Patil (praspati) Cc: pcp@ietf.org Subject: Comments on PCP Extension for Third Party Authorization (http://ww= w.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) Hi Tiru,=A0 Interesting draft, =A0here are my initial comments. 1. Why can't we achieve this with=A0http://tools.ietf.org/html/draft-wasser= man-pcp-authentication-02=A0and RFC6887. [TR] RFC 6887 does not have any mutual authentication mechanism between the= PCP client and PCP server, hence draft-ietf-pcp-authentication-02 is intro= duced. draft-ietf-pcp-authentication-02 solves first party auth problem.=20 Third party authorization would be required in scenarios where PCP client d= oes have not have authorization to use specific PCP opcodes, but will get t= emporary authorization from an application server (e.g. WebRTC Server) trus= ted by the Network. This requirement (REQ-13) is discussed in http://tools.= ietf.org/html/draft-reddy-pcp-auth-req-04. 2. What is the significance of third party authorization here? There will a= nyway be admin configuration rules, whether to honor a PCP request from a c= lient or not. [TR] Admin configuration rules are static. With PCP third party authorizati= on clients will get time-bound, dynamic permission to send PCP requests to = PCP Server. 3. How would applications detect that they are behind NAT and they should c= ontact PCP server for opening ports for the data connections ? [TR] PCP client can use techniques like draft-ietf-pcp-dhcp to find the PCP= Servers in the network. PCP Servers would be available if PCP-aware NAT = or firewall exists. By using PCP MAP/PEER opcodes or by using any other mec= hanism like STUN, client can find out if it is behind NAT or not. 4. This draft proposes a mechanism where holes are punched in firewall/NAT = using PCP as per application thus eliminating the need of ALGs. Is my under= standing correct?=20 [TR] No, that's the goal of PCP itself, not this draft. Applications behind NAT have to use public IP address and port, in the payl= oad so that no pay load translation happens in the NAT box. Wouldn't that n= ot result in rewite of applications and introduce latency? Or, is there ano= ther approach? May be a section with migration strategy would be helpful.= =A0 [TR] With or without third party authorization with PCP, applications will = have to rewritten to use public IP address and port learnt from PCP MAP res= ponse.=20 Third party authorization is assisting applications to be deployed in netwo= rks with restrictive firewall policies. For example a PCP-aware firewall wi= th a restrictive policy to permit media streams only when call is made usin= g WebRTC/SIP Server trusted by the Enterprise network can use the technique= proposed in this draft to open/close firewall mapping thus eliminating the= need of ALGs.=20 This way media streams will not permitted if the clients use unknown WebRTC= /SIP Servers to make a call. -Tiru. -Suresh From tireddy@cisco.com Thu Jan 9 05:55:20 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC3E1AE2EE for ; Thu, 9 Jan 2014 05:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3mtBv2L3TYO for ; Thu, 9 Jan 2014 05:55:18 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 71F9F1AE24D for ; Thu, 9 Jan 2014 05:55:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4300; q=dns/txt; s=iport; t=1389275709; x=1390485309; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=EEuYy9/AZD+bgtsGIkYpw/yD4v6k8chnwH8RFU81xuM=; b=k2po7WHApElImxRfXl0V92p1ozSJOZ44L4g1bCRILnJaVSTQI7ljDyzl p5tXwxOGE/i8/kH0v8g2HR1trQV45kSuOz0GKL+FqdsH2fcMzyWJpUlNE nh8L2laq7WLxcbkYGM3PAHQXW7LvjmCW/PhEx68XSnn0c5fjtjFFzUr2R w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFAAOqzlKtJV2a/2dsb2JhbABZgws4VrlBgREWdIIlAQEBBHkSAQgRBAEBCxkEORQJCQEEAQ0FCAEQh2sNxFIXjlQxDYMegRMEiQuQPJBlgW+BPoIq X-IronPort-AV: E=Sophos;i="4.95,631,1384300800"; d="scan'208";a="296079451" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 09 Jan 2014 13:54:45 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s09DshvP012810 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jan 2014 13:54:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 9 Jan 2014 07:54:43 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "Zhangdacheng (Dacheng)" , "Suresh Kumar Vinapamula Venkata" , "Reinaldo Penno (repenno)" , "Dan Wing (dwing)" , "Prashanth Patil (praspati)" Thread-Topic: Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) Thread-Index: Ac8NQlUeIxcc356cRNaGGTyF43TCGQ== Date: Thu, 9 Jan 2014 13:54:42 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A24286153@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.67.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 13:55:20 -0000 Hi Dacheng, Thanks for review. Please see inline [TR] From: Zhangdacheng (Dacheng) [mailto:zhangdacheng@huawei.com]=20 Sent: Thursday, January 09, 2014 12:24 PM To: Suresh Kumar Vinapamula Venkata; Tirumaleswar Reddy (tireddy); Reinaldo= Penno (repenno); Dan Wing (dwing); Prashanth Patil (praspati) Cc: pcp@ietf.org Subject: RE: Comments on PCP Extension for Third Party Authorization (http:= //www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) Hi, Interesting discussion, I would like to contribute some =A0comments too: 1) In the security consideration section, maybe it is worthwhile to discuss= how to secure the communication between the PCP server and the authorizati= on server. It could be reasonable to assume the communication between the P= CP server and the authorization server could be attacked.=20 [TR] Yes, the communication between the PCP server and authorization server= could be attacked. Therefore the authorization server should issue special= credentials to the PCP server so that it can access and query the authoriz= ation server. The communication must also be protected by TLS or equivalen= t. The actual exchange is outside the scope of this doc. But it's discussed= in detail in OAuth WG in draft http://tools.ietf.org/html/draft-richer-oau= th-introspection-04. We will describe this attack in the Security Considera= tions section in the next revision.=20 2) In the PCP authentication draft, a PCP Auth session has a life period. W= hat will happen if the session expires before the authorization token the c= lient got from the server expires?=20 [TR] If PCP Auth session lifetime expires before the authorization token ex= pires and the PCP client, PCP server fail to trigger re-authentication then= dynamic mappings created because of third party authorization should also = be deleted. Since the authorization work and authorization work are compatible, we may = also need to consider the scenario where the authorization and EAP authenti= cation are performed concurrently. For instance, is it possible for a PCP c= lient to send the authorization token in the first PCP-Auth message to the = PCP server?=A0 Or maybe the token should be sent after the EAP authenticati= on has succeeded.=20 [TR] Sending the access token after the EAP authentication has succeeded wi= ll give the benefit of integrity protecting the ACCESS_TOKEN option. we wi= ll add a new section in the next revision explaining the usage of PCP third= party authz with PCP authentication draft. 3) In addition, in the PCP authentication draft, there is a result code "Au= thorization Failed", which means the same thing as "AUTHORIZATION_INVALID".= Can it be re-used in the authorization work ? [TR] Yes it can be reused, will update the draft. Best Regards, -Tiru. Cheers Dacheng From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Suresh Kumar Vinapamul= a Venkata Sent: Tuesday, January 07, 2014 12:49 PM To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); Dan Wing (dwing= ); praspati@cisco.com Cc: pcp@ietf.org Subject: [pcp] Comments on PCP Extension for Third Party Authorization (htt= p://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) Hi Tiru,=A0 Interesting draft, =A0here are my initial comments. 1. Why can't we achieve this with=A0http://tools.ietf.org/html/draft-wasser= man-pcp-authentication-02=A0and RFC6887. 2. What is the significance of third party authorization here? There will a= nyway be admin configuration rules, whether to honor a PCP request from a c= lient or not. 3. How would applications detect that they are behind NAT and they should c= ontact PCP server for opening ports for the data connections? 4. This draft proposes a mechanism where holes are punched in firewall/NAT = using PCP as per application thus eliminating the need of ALGs. Is my under= standing correct? Applications behind NAT have to use public IP address and= port, in the payload so that no pay load translation happens in the NAT bo= x. Wouldn't that not result in rewite of applications and introduce latency= ? Or, is there another approach? May be a section with migration strategy w= ould be helpful.=A0 -Suresh From sureshk@juniper.net Fri Jan 10 17:38:48 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55D21AD957 for ; Fri, 10 Jan 2014 17:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dpTz5mW-ZqC for ; Fri, 10 Jan 2014 17:38:45 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD0C1A1F76 for ; Fri, 10 Jan 2014 17:38:44 -0800 (PST) Received: from mail154-va3-R.bigfish.com (10.7.14.230) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Sat, 11 Jan 2014 01:38:34 +0000 Received: from mail154-va3 (localhost [127.0.0.1]) by mail154-va3-R.bigfish.com (Postfix) with ESMTP id 6D07B4C01BF; Sat, 11 Jan 2014 01:38:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(z579eh5621h3fb8kzbb2dI98dI9371I1432I1447Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h1155h) Received-SPF: pass (mail154-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=sureshk@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(189002)(199002)(24454002)(51704005)(51914003)(377454003)(479174003)(15975445006)(19580405001)(83506001)(53806001)(83322001)(74876001)(46102001)(51856001)(19580395003)(80976001)(81686001)(15202345003)(81342001)(47736001)(47976001)(50986001)(49866001)(85306002)(81542001)(77982001)(59766001)(79102001)(81816001)(69226001)(56776001)(4396001)(76786001)(76176001)(92566001)(92726001)(87936001)(76796001)(93136001)(87266001)(2656002)(36756003)(83072002)(85852003)(56816005)(74706001)(90146001)(54356001)(63696002)(76482001)(74366001)(31966008)(54316002)(66066001)(80022001)(74502001)(47446002)(220493001)(74662001)(65816001)(163123001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR05MB285; H:DM2PR05MB288.namprd05.prod.outlook.com; CLIP:66.129.239.12; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail154-va3 (localhost.localdomain [127.0.0.1]) by mail154-va3 (MessageSwitch) id 1389404312810605_7536; Sat, 11 Jan 2014 01:38:32 +0000 (UTC) Received: from VA3EHSMHS001.bigfish.com (unknown [10.7.14.252]) by mail154-va3.bigfish.com (Postfix) with ESMTP id BEAF23A004C; Sat, 11 Jan 2014 01:38:32 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS001.bigfish.com (10.7.99.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 11 Jan 2014 01:38:32 +0000 Received: from DM2PR05MB285.namprd05.prod.outlook.com (10.141.101.21) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.395.1; Sat, 11 Jan 2014 01:38:32 +0000 Received: from DM2PR05MB288.namprd05.prod.outlook.com (10.141.101.11) by DM2PR05MB285.namprd05.prod.outlook.com (10.141.101.21) with Microsoft SMTP Server (TLS) id 15.0.851.15; Sat, 11 Jan 2014 01:38:30 +0000 Received: from DM2PR05MB288.namprd05.prod.outlook.com ([10.141.101.11]) by DM2PR05MB288.namprd05.prod.outlook.com ([10.141.101.11]) with mapi id 15.00.0842.003; Sat, 11 Jan 2014 01:38:30 +0000 From: Suresh Kumar Vinapamula Venkata To: "Tirumaleswar Reddy (tireddy)" , "Reinaldo Penno (repenno)" , "Dan Wing (dwing)" , "Prashanth Patil (praspati)" Thread-Topic: Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) Thread-Index: Ac8NHn2TkUiuNHzC/E6jbju6rMAZpABDEc2A Date: Sat, 11 Jan 2014 01:38:30 +0000 Message-ID: In-Reply-To: <913383AAA69FF945B8F946018B75898A24285F8B@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [66.129.239.12] x-forefront-prvs: 0088C92887 Content-Type: text/plain; charset="us-ascii" Content-ID: <1A59FEF8D6D48E459ECE0E9DDF837572@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "pcp@ietf.org" Subject: Re: [pcp] Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 01:38:48 -0000 Few followup questions. Please see inline. On 1/9/14 1:38 AM, "Tirumaleswar Reddy (tireddy)" wrote: >Hi Suresh, > >Thanks for the review. Please see inline > >From: Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net] >Sent: Tuesday, January 07, 2014 10:19 AM >To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); Dan Wing >(dwing); Prashanth Patil (praspati) >Cc: pcp@ietf.org >Subject: Comments on PCP Extension for Third Party Authorization >(http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.t >xt) > >Hi Tiru,=20 > >Interesting draft, here are my initial comments. > >1. Why can't we achieve this with >http://tools.ietf.org/html/draft-wasserman-pcp-authentication-02 and >RFC6887. > >[TR] RFC 6887 does not have any mutual authentication mechanism between >the PCP client and PCP server, hence draft-ietf-pcp-authentication-02 is >introduced. draft-ietf-pcp-authentication-02 solves first party auth >problem.=20 > >Third party authorization would be required in scenarios where PCP client >does have not have authorization to use specific PCP opcodes, but will >get temporary authorization from an application server (e.g. WebRTC >Server) trusted by the Network. This requirement (REQ-13) is discussed in >http://tools.ietf.org/html/draft-reddy-pcp-auth-req-04. SV> I don't see REQ-13 in the draft http://tools.ietf.org/html/draft-reddy-pcp-auth-req-04. > >2. What is the significance of third party authorization here? There will >anyway be admin configuration rules, whether to honor a PCP request from >a client or not. > >[TR] Admin configuration rules are static. With PCP third party >authorization clients will get time-bound, dynamic permission to send PCP >requests to PCP Server. SV> Who and on what basis will give this authorization? You mean Application server? > >3. How would applications detect that they are behind NAT and they should >contact PCP server for opening ports for the data connections ? > >[TR] PCP client can use techniques like draft-ietf-pcp-dhcp to find the >PCP Servers in the network. PCP Servers would be available if PCP-aware >NAT or firewall exists. By using PCP MAP/PEER opcodes or by using any >other mechanism like STUN, client can find out if it is behind NAT or not. > >4. This draft proposes a mechanism where holes are punched in >firewall/NAT using PCP as per application thus eliminating the need of >ALGs. Is my understanding correct? > >[TR] No, that's the goal of PCP itself, not this draft. SV> Correct. But, abstract of this draft talks necessity of opening ports and weakness with algs. So, I initially assumed it is meant for any existing application. So was asking for the migration path. Looks like in addition to applications, there has to be a signaling and an oauth server, which issues tokens on need basis to its clients for them to raise PCP requests. Is that correct? What is the communication channel between signaling server and oauth server? Before that, are they the same are different? In other words, is application issued token only when the signaling server detect the need? > >Applications behind NAT have to use public IP address and port, in the >payload so that no pay load translation happens in the NAT box. Wouldn't >that not result in rewite of applications and introduce latency? Or, is >there another approach? May be a section with migration strategy would be >helpful.=20 > >[TR] With or without third party authorization with PCP, applications >will have to rewritten to use public IP address and port learnt from PCP >MAP response.=20 >Third party authorization is assisting applications to be deployed in >networks with restrictive firewall policies. For example a PCP-aware >firewall with a restrictive policy to permit media streams only when call >is made using WebRTC/SIP Server trusted by the Enterprise network can use >the technique proposed in this draft to open/close firewall mapping thus >eliminating the need of ALGs. >This way media streams will not permitted if the clients use unknown >WebRTC/SIP Servers to make a call. SV> What if an application granted a token to raise a PEER request, but raises a MAP request? SV>If bob is in same network as alice, then you expect hair pin communication or direct communication between alice or bob, it is left to application signaling server's discretion? > >-Tiru. > >-Suresh > From partha@parthasarathi.co.in Sun Jan 12 17:01:42 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BAC1ACCEA for ; Sun, 12 Jan 2014 17:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.232 X-Spam-Level: X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfPOZSFe--JU for ; Sun, 12 Jan 2014 17:01:40 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.229]) by ietfa.amsl.com (Postfix) with ESMTP id BA0381ACC91 for ; Sun, 12 Jan 2014 17:01:40 -0800 (PST) Received: from userPC (unknown [122.178.241.14]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 736781908196; Mon, 13 Jan 2014 01:01:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1389574889; bh=7kf6SGdIq16iGrxO1GOfXYZNyfHITp9qT3GYw+OUDMo=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=LIn1nmuYI/1LC3DuxCabfMlNHxWjR1a1J9fNxCbM/kDrTs5iu0jIdRDUcdS+3opLZ AlBnjvZ8H6GnF/DQUTNDsXYCD36m2RL31hPCTI33HiZJJKpBWfzFrdXLsF4oqPDApj guJ1+89TYABAwYSCQ4+sJlaR25iHdavwgjyGPfik= From: "Parthasarathi R" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Zhangdacheng \(Dacheng\)'" , "'Suresh Kumar Vinapamula Venkata'" , "'Reinaldo Penno \(repenno\)'" , "'Dan Wing \(dwing\)'" , "'Prashanth Patil \(praspati\)'" References: <913383AAA69FF945B8F946018B75898A24286153@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A24286153@xmb-rcd-x10.cisco.com> Date: Mon, 13 Jan 2014 06:31:16 +0530 Message-ID: <005e01cf0ffa$fcdd83d0$f6988b70$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8NQlUeIxcc356cRNaGGTyF43TCGQCuHjAQ Content-Language: en-us X-CTCH-RefID: str=0001.0A020209.52D33AE9.0055, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Cc: pcp@ietf.org Subject: Re: [pcp] Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 01:01:43 -0000 Hi Thiru, I like this proposal as this mechanism works well for WebRTC scenario wherein the signaling is not standardized and also, TURN server is not required. My initial review comments are as follows: 1) Sec 4 Point 2, 3: it has to be OAuth 2.0 Authorization server instead = of OAuth 2.0 server 2) Sec 5 Fig 2, Fig 3: WebRTC server as an authorization server does not look appropriate to me. As it is possible to have separate authorization server in the WebRTC scenario. Thanks Partha > -----Original Message----- > From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Tirumaleswar = Reddy > (tireddy) > Sent: Thursday, January 09, 2014 7:25 PM > To: Zhangdacheng (Dacheng); Suresh Kumar Vinapamula Venkata; Reinaldo > Penno (repenno); Dan Wing (dwing); Prashanth Patil (praspati) > Cc: pcp@ietf.org > Subject: Re: [pcp] Comments on PCP Extension for Third Party > Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp- > third-party-authz-01.txt) >=20 > Hi Dacheng, >=20 > Thanks for review. Please see inline [TR] >=20 > From: Zhangdacheng (Dacheng) [mailto:zhangdacheng@huawei.com] > Sent: Thursday, January 09, 2014 12:24 PM > To: Suresh Kumar Vinapamula Venkata; Tirumaleswar Reddy (tireddy); > Reinaldo Penno (repenno); Dan Wing (dwing); Prashanth Patil (praspati) > Cc: pcp@ietf.org > Subject: RE: Comments on PCP Extension for Third Party Authorization > (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz- > 01.txt) >=20 > Hi, >=20 > Interesting discussion, I would like to contribute some =A0comments = too: >=20 > 1) In the security consideration section, maybe it is worthwhile to > discuss how to secure the communication between the PCP server and the > authorization server. It could be reasonable to assume the > communication between the PCP server and the authorization server = could > be attacked. >=20 > [TR] Yes, the communication between the PCP server and authorization > server could be attacked. Therefore the authorization server should > issue special credentials to the PCP server so that it can access and > query the authorization server. The communication must also be > protected by TLS or equivalent. The actual exchange is outside the > scope of this doc. But it's discussed in detail in OAuth WG in draft > http://tools.ietf.org/html/draft-richer-oauth-introspection-04. We = will > describe this attack in the Security Considerations section in the = next > revision. >=20 > 2) In the PCP authentication draft, a PCP Auth session has a life > period. What will happen if the session expires before the > authorization token the client got from the server expires? >=20 > [TR] If PCP Auth session lifetime expires before the authorization > token expires and the PCP client, PCP server fail to trigger re- > authentication then dynamic mappings created because of third party > authorization should also be deleted. >=20 > Since the authorization work and authorization work are compatible, we > may also need to consider the scenario where the authorization and EAP > authentication are performed concurrently. For instance, is it = possible > for a PCP client to send the authorization token in the first PCP-Auth > message to the PCP server?=A0 Or maybe the token should be sent after = the > EAP authentication has succeeded. >=20 > [TR] Sending the access token after the EAP authentication has > succeeded will give the benefit of integrity protecting the > ACCESS_TOKEN option. we will add a new section in the next revision > explaining the usage of PCP third party authz with PCP authentication > draft. >=20 > 3) In addition, in the PCP authentication draft, there is a result = code > "Authorization Failed", which means the same thing as > "AUTHORIZATION_INVALID". Can it be re-used in the authorization work ? >=20 > [TR] Yes it can be reused, will update the draft. >=20 > Best Regards, > -Tiru. >=20 > Cheers >=20 > Dacheng >=20 > From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Suresh Kumar > Vinapamula Venkata > Sent: Tuesday, January 07, 2014 12:49 PM > To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); Dan Wing > (dwing); praspati@cisco.com > Cc: pcp@ietf.org > Subject: [pcp] Comments on PCP Extension for Third Party Authorization > (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz- > 01.txt) >=20 > Hi Tiru, >=20 > Interesting draft, =A0here are my initial comments. > 1. Why can't we achieve this with=A0http://tools.ietf.org/html/draft- > wasserman-pcp-authentication-02=A0and RFC6887. > 2. What is the significance of third party authorization here? There > will anyway be admin configuration rules, whether to honor a PCP > request from a client or not. > 3. How would applications detect that they are behind NAT and they > should contact PCP server for opening ports for the data connections? > 4. This draft proposes a mechanism where holes are punched in > firewall/NAT using PCP as per application thus eliminating the need of > ALGs. Is my understanding correct? Applications behind NAT have to use > public IP address and port, in the payload so that no pay load > translation happens in the NAT box. Wouldn't that not result in rewite > of applications and introduce latency? Or, is there another approach? > May be a section with migration strategy would be helpful. > -Suresh > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From tireddy@cisco.com Mon Jan 13 01:24:06 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1C11ADF81 for ; Mon, 13 Jan 2014 01:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.439 X-Spam-Level: X-Spam-Status: No, score=-9.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbXdvao8FBqQ for ; Mon, 13 Jan 2014 01:24:03 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 745D41AE04D for ; Mon, 13 Jan 2014 01:24:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6786; q=dns/txt; s=iport; t=1389605032; x=1390814632; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=Go0WDi0x1ycHEMUr9TgeEcWfni6gSZPQvRjz5Rbtews=; b=Cl75r3PyXFGhEWivux+v2S3na2/AD1h7RM47uquEC11oa2LUdRE05dQe z8RUyv0AIblO2C+2C4mljzTIbI0ehrV51SXTp8HnZLtwCIVLNjd/xEVK9 IXFAcRmjHxSr0mU/2lHgyG95hpa6w9MrdB1HTgvewF3ZQmoKasX1NqUwo Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAESw01KtJXG//2dsb2JhbABQCoMLOFa5aIEOFnSCJQEBAQMBOj8FBwYBCBEEAQEBChQFBDkUCQkBBAENBQgBh3MIDcRJF44rCwEBHjECC4MegRMEmUeQZYFvgT6BaAIHFwQCHA X-IronPort-AV: E=Sophos;i="4.95,651,1384300800"; d="scan'208";a="12399416" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-1.cisco.com with ESMTP; 13 Jan 2014 09:23:52 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0D9Np1o001272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jan 2014 09:23:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Mon, 13 Jan 2014 03:23:51 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Suresh Kumar Vinapamula Venkata , "Reinaldo Penno (repenno)" , "Dan Wing (dwing)" , "Prashanth Patil (praspati)" Thread-Topic: Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) Thread-Index: Ac8QQSeDqLy4oFHmTEuJ/wTWKaO7GA== Date: Mon, 13 Jan 2014 09:23:50 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A24289CED@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.67.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 09:24:06 -0000 Hi Suresh, Please see line > -----Original Message----- > From: Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net] > Sent: Saturday, January 11, 2014 7:09 AM > To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); Dan Wing > (dwing); Prashanth Patil (praspati) > Cc: pcp@ietf.org > Subject: Re: Comments on PCP Extension for Third Party Authorization > (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz- > 01.txt) >=20 > Few followup questions. Please see inline. >=20 > On 1/9/14 1:38 AM, "Tirumaleswar Reddy (tireddy)" > wrote: >=20 > >Hi Suresh, > > > >Thanks for the review. Please see inline > > > >From: Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net] > >Sent: Tuesday, January 07, 2014 10:19 AM > >To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); Dan Wing > >(dwing); Prashanth Patil (praspati) > >Cc: pcp@ietf.org > >Subject: Comments on PCP Extension for Third Party Authorization > >(http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-0 > >1.t > >xt) > > > >Hi Tiru, > > > >Interesting draft, here are my initial comments. > > > >1. Why can't we achieve this with > >http://tools.ietf.org/html/draft-wasserman-pcp-authentication-02 and > >RFC6887. > > > >[TR] RFC 6887 does not have any mutual authentication mechanism > between > >the PCP client and PCP server, hence draft-ietf-pcp-authentication-02 > >is introduced. draft-ietf-pcp-authentication-02 solves first party > >auth problem. > > > >Third party authorization would be required in scenarios where PCP > >client does have not have authorization to use specific PCP opcodes, > >but will get temporary authorization from an application server (e.g. > >WebRTC > >Server) trusted by the Network. This requirement (REQ-13) is discussed > >in http://tools.ietf.org/html/draft-reddy-pcp-auth-req-04. > SV> I don't see REQ-13 in the draft > http://tools.ietf.org/html/draft-reddy-pcp-auth-req-04. It's specified in section 4 of the draft http://tools.ietf.org/html/draft-r= eddy-pcp-auth-req-04#section-4.=20 >=20 > > > >2. What is the significance of third party authorization here? There > >will anyway be admin configuration rules, whether to honor a PCP > >request from a client or not. > > > >[TR] Admin configuration rules are static. With PCP third party > >authorization clients will get time-bound, dynamic permission to send > >PCP requests to PCP Server. > SV> Who and on what basis will give this authorization? You mean > Application server? > > > >3. How would applications detect that they are behind NAT and they > >should contact PCP server for opening ports for the data connections ? > > > >[TR] PCP client can use techniques like draft-ietf-pcp-dhcp to find the > >PCP Servers in the network. PCP Servers would be available if > >PCP-aware NAT or firewall exists. By using PCP MAP/PEER opcodes or by > >using any other mechanism like STUN, client can find out if it is behind= NAT > or not. > > > >4. This draft proposes a mechanism where holes are punched in > >firewall/NAT using PCP as per application thus eliminating the need of > >ALGs. Is my understanding correct? > > > >[TR] No, that's the goal of PCP itself, not this draft. > SV> Correct. But, abstract of this draft talks necessity of opening > SV> ports > and weakness with algs. So, I initially assumed it is meant for any exist= ing > application. So was asking for the migration path. Looks like in addition= to > applications, there has to be a signaling and an oauth server, which issu= es > tokens on need basis to its clients for them to raise PCP requests. Is th= at > correct ? Yes. WebRTC does not mandate any specific signaling protocol, so the propri= etary signaling protocol used by the web provider can be enhanced to provid= e the tokens to the client (Java Script). The Java Script can use the PCP c= lient provided by the browser to send PCP request with ACCESS_TOKEN option= to the PCP Server. For example PCP implementation by Mozilla is discussed = in https://bugzilla.mozilla.org/show_bug.cgi?id=3D845007. The WebRTC Serve= r itself is acting as Authorization server. > What is the communication channel between signaling server and oauth > server ?=20 > Before that, are they the same are different?=20 Yes, the signaling server and authorization server are the same.=20 > In other words, is > application issued token only when the signaling server detect the need ? Yes >=20 > > > >Applications behind NAT have to use public IP address and port, in the > >payload so that no pay load translation happens in the NAT box. > >Wouldn't that not result in rewite of applications and introduce > >latency? Or, is there another approach? May be a section with migration > >strategy would be helpful. > > > >[TR] With or without third party authorization with PCP, applications > >will have to rewritten to use public IP address and port learnt from > >PCP MAP response. > >Third party authorization is assisting applications to be deployed in > >networks with restrictive firewall policies. For example a PCP-aware > >firewall with a restrictive policy to permit media streams only when > >call is made using WebRTC/SIP Server trusted by the Enterprise network > >can use the technique proposed in this draft to open/close firewall > >mapping thus eliminating the need of ALGs. > >This way media streams will not permitted if the clients use unknown > >WebRTC/SIP Servers to make a call. > SV> What if an application granted a token to raise a PEER request, but > raises a MAP request ? To validate the handle token, PCP server will communicate with the authoriz= ation server and can identify the grant (i.e. PCP requests the client is pe= rmitted to use). Handle Token validation for other use cases is already imp= lemented by vendors like PingIdentity (http://documentation.pingidentity.co= m/display/PF66/Token+Models) and the protocol they had used for token valid= ation is discussed in Oauth WG thread http://www.ietf.org/mail-archive/web/= oauth/current/msg08607.html. The work to standardize the communication is d= iscussed in http://tools.ietf.org/html/draft-richer-oauth-introspection-04 >=20 > SV>If bob is in same network as alice, then you expect hair pin > communication or direct communication between alice or bob, it is left to > application signaling server's discretion ? The application signaling server could be located in the cloud or provided = by third party that Enterprise has tie-up with. It may not be aware where a= lice, bob are located. =20 -Tiru. >=20 >=20 >=20 > > > >-Tiru. > > > >-Suresh > > >=20 From tireddy@cisco.com Mon Jan 13 04:46:04 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3DD1AE134 for ; Mon, 13 Jan 2014 04:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rdhFduvB-Fh for ; Mon, 13 Jan 2014 04:46:01 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id ED7681AE06C for ; Mon, 13 Jan 2014 04:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6546; q=dns/txt; s=iport; t=1389617133; x=1390826733; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=mGOEWwSxgOHz5WZKNmLmBdBipbOO55ybZ1dShHA+49M=; b=DEVox4oP+3nl6zBos0XBf6z0Z49liqzbyhDD0Lo8MQ/QkhTds5MUqAw4 8PwZ/X5ljo09qKRr34WeM/7/EwxVEpOFFHmaDU/e9V4WXmCpT2A5XmoyP B/lzWR3KyP8e/HZi8nXQTqgROOK4DBIQmu8QJoG3n3L507yuUz/EzMG2f 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAE7f01KtJV2b/2dsb2JhbABagws4VrlsgQ8WdIIlAQEBAwEBAQFrCwUHBgEIEQQBAQsZBC4LFAkJAQQBDQUIARCHYwgNxGUXjlYxDYMegRMEiQuQPJBlgW+BPoFoIiA X-IronPort-AV: E=Sophos;i="4.95,652,1384300800"; d="scan'208";a="297037660" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 13 Jan 2014 12:45:32 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0DCjWK8031998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Jan 2014 12:45:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Mon, 13 Jan 2014 06:45:31 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Parthasarathi R , "'Zhangdacheng (Dacheng)'" , "'Suresh Kumar Vinapamula Venkata'" , "Reinaldo Penno (repenno)" , "Dan Wing (dwing)" , "Prashanth Patil (praspati)" Thread-Topic: [pcp] Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) Thread-Index: Ac8QXVVztmib/cCzQKqSUIUhUEcYjg== Date: Mon, 13 Jan 2014 12:45:30 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A24289E5D@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.67.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 12:46:04 -0000 Hi Partha, Thanks for the review. Please see inline > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > Sent: Monday, January 13, 2014 6:31 AM > To: Tirumaleswar Reddy (tireddy); 'Zhangdacheng (Dacheng)'; 'Suresh Kumar > Vinapamula Venkata'; Reinaldo Penno (repenno); Dan Wing (dwing); > Prashanth Patil (praspati) > Cc: pcp@ietf.org > Subject: RE: [pcp] Comments on PCP Extension for Third Party Authorizatio= n > (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz- > 01.txt) >=20 > Hi Thiru, >=20 > I like this proposal as this mechanism works well for WebRTC scenario > wherein the signaling is not standardized and also, TURN server is not > required. My initial review comments are as follows: >=20 > 1) Sec 4 Point 2, 3: it has to be OAuth 2.0 Authorization server instead = of > OAuth 2.0 server Yes, updated the draft. > 2) Sec 5 Fig 2, Fig 3: WebRTC server as an authorization server does not = look > appropriate to me. As it is possible to have separate authorization serve= r in > the WebRTC scenario. The Authorization server has to be WebRTC signaling server because only it = will be aware of call termination details to revoke the access token. Cheers, -Tiru. >=20 > Thanks > Partha >=20 > > -----Original Message----- > > From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Tirumaleswar > > Reddy > > (tireddy) > > Sent: Thursday, January 09, 2014 7:25 PM > > To: Zhangdacheng (Dacheng); Suresh Kumar Vinapamula Venkata; Reinaldo > > Penno (repenno); Dan Wing (dwing); Prashanth Patil (praspati) > > Cc: pcp@ietf.org > > Subject: Re: [pcp] Comments on PCP Extension for Third Party > > Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp- > > third-party-authz-01.txt) > > > > Hi Dacheng, > > > > Thanks for review. Please see inline [TR] > > > > From: Zhangdacheng (Dacheng) [mailto:zhangdacheng@huawei.com] > > Sent: Thursday, January 09, 2014 12:24 PM > > To: Suresh Kumar Vinapamula Venkata; Tirumaleswar Reddy (tireddy); > > Reinaldo Penno (repenno); Dan Wing (dwing); Prashanth Patil (praspati) > > Cc: pcp@ietf.org > > Subject: RE: Comments on PCP Extension for Third Party Authorization > > (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz- > > 01.txt) > > > > Hi, > > > > Interesting discussion, I would like to contribute some =A0comments too= : > > > > 1) In the security consideration section, maybe it is worthwhile to > > discuss how to secure the communication between the PCP server and the > > authorization server. It could be reasonable to assume the > > communication between the PCP server and the authorization server > > could be attacked. > > > > [TR] Yes, the communication between the PCP server and authorization > > server could be attacked. Therefore the authorization server should > > issue special credentials to the PCP server so that it can access and > > query the authorization server. The communication must also be > > protected by TLS or equivalent. The actual exchange is outside the > > scope of this doc. But it's discussed in detail in OAuth WG in draft > > http://tools.ietf.org/html/draft-richer-oauth-introspection-04. We > > will describe this attack in the Security Considerations section in > > the next revision. > > > > 2) In the PCP authentication draft, a PCP Auth session has a life > > period. What will happen if the session expires before the > > authorization token the client got from the server expires? > > > > [TR] If PCP Auth session lifetime expires before the authorization > > token expires and the PCP client, PCP server fail to trigger re- > > authentication then dynamic mappings created because of third party > > authorization should also be deleted. > > > > Since the authorization work and authorization work are compatible, we > > may also need to consider the scenario where the authorization and EAP > > authentication are performed concurrently. For instance, is it > > possible for a PCP client to send the authorization token in the first > > PCP-Auth message to the PCP server?=A0 Or maybe the token should be sen= t > > after the EAP authentication has succeeded. > > > > [TR] Sending the access token after the EAP authentication has > > succeeded will give the benefit of integrity protecting the > > ACCESS_TOKEN option. we will add a new section in the next revision > > explaining the usage of PCP third party authz with PCP authentication > > draft. > > > > 3) In addition, in the PCP authentication draft, there is a result > > code "Authorization Failed", which means the same thing as > > "AUTHORIZATION_INVALID". Can it be re-used in the authorization work ? > > > > [TR] Yes it can be reused, will update the draft. > > > > Best Regards, > > -Tiru. > > > > Cheers > > > > Dacheng > > > > From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Suresh Kumar > > Vinapamula Venkata > > Sent: Tuesday, January 07, 2014 12:49 PM > > To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); Dan Wing > > (dwing); praspati@cisco.com > > Cc: pcp@ietf.org > > Subject: [pcp] Comments on PCP Extension for Third Party Authorization > > (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz- > > 01.txt) > > > > Hi Tiru, > > > > Interesting draft, =A0here are my initial comments. > > 1. Why can't we achieve this with=A0http://tools.ietf.org/html/draft- > > wasserman-pcp-authentication-02=A0and RFC6887. > > 2. What is the significance of third party authorization here? There > > will anyway be admin configuration rules, whether to honor a PCP > > request from a client or not. > > 3. How would applications detect that they are behind NAT and they > > should contact PCP server for opening ports for the data connections? > > 4. This draft proposes a mechanism where holes are punched in > > firewall/NAT using PCP as per application thus eliminating the need of > > ALGs. Is my understanding correct? Applications behind NAT have to use > > public IP address and port, in the payload so that no pay load > > translation happens in the NAT box. Wouldn't that not result in rewite > > of applications and introduce latency? Or, is there another approach? > > May be a section with migration strategy would be helpful. > > -Suresh > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp From tireddy@cisco.com Mon Jan 20 04:28:06 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5E31A0128 for ; Mon, 20 Jan 2014 04:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L281Rk1vCdg5 for ; Mon, 20 Jan 2014 04:28:01 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6F11A0113 for ; Mon, 20 Jan 2014 04:28:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4198; q=dns/txt; s=iport; t=1390220882; x=1391430482; h=from:to:cc:subject:date:message-id:mime-version; bh=5gnXXymrPXdrRILFxlZi4e8D1OeEjB1xrup8NyzD4h4=; b=El4Qg3OAl/CNr+oZHbF2uzdfB28Uf23F/OjOcjfSUzfY/hOaPqRf9FMM PEHQ0iBr/DhpRHQ5uCKoBS4QtJT6+Am47do8nixvSbTq2j9+FH84/3+m0 2ORykHEr6MBBpD/Ppl/6JWNYFLvqH5//8mpO9n5QZY0jCV7clSHU0yWaw k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUHACMW3VKtJV2b/2dsb2JhbABZgkdEOFaybIhRgQ0WdIInAQQtTBIBDB5WJgEEDg2HfQ3DSheOTjGDK4EUBJlUkGaDLYIq X-IronPort-AV: E=Sophos;i="4.95,690,1384300800"; d="scan'208,217";a="14112240" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP; 20 Jan 2014 12:27:50 +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 s0KCRoge030185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jan 2014 12:27:50 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Mon, 20 Jan 2014 06:27:50 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" Thread-Topic: Review of draft-ietf-pcp-proxy-04 Thread-Index: Ac8V2wUklboI3EvRSZq6EyvvUWA9VQ== Date: Mon, 20 Jan 2014 12:27:49 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2428D9BE@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.67.100] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2428D9BExmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: [pcp] Review of draft-ietf-pcp-proxy-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 12:28:06 -0000 --_000_913383AAA69FF945B8F946018B75898A2428D9BExmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Med, Comments: a) If PCP authentication is used, Is there a need to still use THIRD_PARTY opt= ion for the use case "No NAT is Co-located with the PCP Proxy" in section = 6 of the draft ? b) Are you planning to update the draft with details about the usage of PCP p= roxy with PCP auth. In addition to the existing use cases this integration = will be useful for http://tools.ietf.org/html/draft-wing-pcp-flowdata-00 wh= ere the PCP proxy in the Home network receives the flow characteristics sig= naled by the PCP client and propagates the flow characteristics to the PCP = Server in the Access Network. Cheers, -Tiru. --_000_913383AAA69FF945B8F946018B75898A2428D9BExmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

Comments:

 

a)

If PCP authentication is used, Is there a need to st= ill use THIRD_PARTY option for the use case “No NAT is Co-located wit= h the PCP Proxy”  in section 6 of the draft ?

 

b)

Are you planning to update the draft  with deta= ils about the usage of PCP proxy with PCP auth. In addition to the existing= use cases this integration will be useful for http://to= ols.ietf.org/html/draft-wing-pcp-flowdata-00 where the PCP proxy in the= Home network receives the flow characteristics signaled by the PCP client = and propagates the flow characteristics to the PCP Server in the Access Network.

 

Cheers,

-Tiru.

--_000_913383AAA69FF945B8F946018B75898A2428D9BExmbrcdx10ciscoc_-- From mohamed.boucadair@orange.com Mon Jan 20 04:59:42 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4981A0144 for ; Mon, 20 Jan 2014 04:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.148 X-Spam-Level: X-Spam-Status: No, score=-0.148 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2oVfHaYsdHU for ; Mon, 20 Jan 2014 04:59:40 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B1C391A0142 for ; Mon, 20 Jan 2014 04:59:39 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 05D8118C09B; Mon, 20 Jan 2014 13:59:39 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id DAAC34C077; Mon, 20 Jan 2014 13:59:38 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Mon, 20 Jan 2014 13:59:38 +0100 From: To: "Tirumaleswar Reddy (tireddy)" Date: Mon, 20 Jan 2014 13:59:35 +0100 Thread-Topic: Review of draft-ietf-pcp-proxy-04 Thread-Index: Ac8V2wUklboI3EvRSZq6EyvvUWA9VQAAx9Gg Message-ID: <94C682931C08B048B7A8645303FDC9F36F46255383@PUEXCB1B.nanterre.francetelecom.fr> References: <913383AAA69FF945B8F946018B75898A2428D9BE@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2428D9BE@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: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36F46255383PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015 Cc: "pcp@ietf.org" Subject: Re: [pcp] Review of draft-ietf-pcp-proxy-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 12:59:42 -0000 --_000_94C682931C08B048B7A8645303FDC9F36F46255383PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, Thanks for the comments. Please see inline. Cheers, Med De : Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Envoy=E9 : lundi 20 janvier 2014 13:28 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Dan Wing (dwing); Reinaldo Penno (repenno); pcp@ietf.org Objet : Review of draft-ietf-pcp-proxy-04 Hi Med, Comments: a) If PCP authentication is used, Is there a need to still use THIRD_PARTY opt= ion for the use case "No NAT is Co-located with the PCP Proxy" in section = 6 of the draft ? [Med] THIRD_PARTY option is needed even if no NAT is co-located with the PC= P Proxy (e.g., DS-Lite context). For other contexts than DS-Lite, if the so= urce IP address is not altered by the PCP proxy, the proxy has to inspect a= ll incoming packets to find out pcp ones and therefore enforces the appropr= iate policies. Altering the source IP address by the pcp proxy is a solutio= n to redirect all the incoming pcp traffic explicitly to the PCP proxy. In= addition, as indicated below, proxy implications on authentication are out= of scope of this document. The proxy document adopts the same rationale as= the base pcp specification. b) Are you planning to update the draft with details about the usage of PCP p= roxy with PCP auth. [Med] NO. The plan is to follow what have been presented during the Berlin = meeting (http://www.ietf.org/proceedings/87/slides/slides-87-pcp-2.pdf): "P= roxy implication on authentication are out of scope and should be specified= in pcp-authentication document" In addition to the existing use cases this integration will be useful for h= ttp://tools.ietf.org/html/draft-wing-pcp-flowdata-00 where the PCP proxy in= the Home network receives the flow characteristics signaled by the PCP cli= ent and propagates the flow characteristics to the PCP Server in the Access= Network. Cheers, -Tiru. --_000_94C682931C08B048B7A8645303FDC9F36F46255383PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Thanks for the comments.

&n= bsp;

Please see inline.

Cheers,

<= span style=3D'font-size:10.0pt;font-family:"Courier New";color:#1F497D'>Med=

 

De : Tirumaleswa= r Reddy (tireddy) [mailto:tireddy@cisco.com]
Envoy=E9 : lun= di 20 janvier 2014 13:28
=C0 : BOUCADAIR Mohamed IMT/OLN
= Cc : Dan Wing (dwing); Reinaldo Penno (repenno); pcp@ietf.orgObjet : Review of draft-ietf-pcp-proxy-04

 

Hi Med,

 

Comments:

 =

a)

If PCP authe= ntication is used, Is there a need to still use THIRD_PARTY option for the = use case “No NAT is Co-located with the PCP Proxy”  in sec= tion 6 of the draft ?

[Med] THIRD_P= ARTY option is needed even if no NAT is co-located with the PCP Proxy (e.g.= , DS-Lite context). For other contexts than DS-Lite, if the source IP addre= ss is not altered by the PCP proxy, the proxy has to inspect all incoming p= ackets to find out pcp ones and therefore enforces the appropriate policies= . Altering the source IP address by the pcp proxy is a solution to redirect= all the incoming=A0 pcp traffic explicitly to the PCP proxy. In addition, = as indicated below, proxy implications on authentication are out of scope o= f this document. The proxy document adopts the same rationale as the base p= cp specification.

 

b)

Are you planning to update the draft  with details about the usage = of PCP proxy with PCP auth.=

[Med] NO. The plan is to follow what have been= presented during the Berlin meeting (http://www.ietf.org/proceedings/87/sli= des/slides-87-pcp-2.pdf): “Proxy implication on authentication ar= e out of scope and should be specified in pcp-authentication document”= ;

 

In addition to the existing use case= s this integration will be useful for http://tools.ietf.org/html/draft-wing-pcp-flow= data-00 where the PCP proxy in the Home network receives the flow chara= cteristics signaled by the PCP client and propagates the flow characteristi= cs to the PCP Server in the Access Network.

 

Cheers,

-Tiru.

= --_000_94C682931C08B048B7A8645303FDC9F36F46255383PUEXCB1Bnante_-- From tireddy@cisco.com Mon Jan 20 08:05:51 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B2D1A01B9 for ; Mon, 20 Jan 2014 08:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfCLpywxLbDI for ; Mon, 20 Jan 2014 08:05:48 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 40D111A01B5 for ; Mon, 20 Jan 2014 08:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13401; q=dns/txt; s=iport; t=1390233948; x=1391443548; h=from:to:cc:subject:date:message-id:mime-version; bh=GljGoAFsM7EShDHqWyujyWNo/rWlUT19dViciFyrvk4=; b=JqnFRsGHdy0KYLFbQwMDrEr5fKlXGz/7dVG2GXUWv+Hjj0lL5nlqxnLz ZR2LF8rtXFIGM5/+73v6N9aTrH3rTFG7BI9rPZERV5Gk459WSyurYQGdX ANCsbjPjiy9S2IOxZMXht+9g5YZZfdP9eg/Gu0dAa4TJUTfcSebaLJVHC 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucHAMVI3VKtJV2b/2dsb2JhbABZgkdEOFaybIhRgQ8WdIIlAQEBAgItTBIBCBEEAQELHTkUCQkBBA4FCAESh2oNw14Xjk4xBoMlgRQEiQ+QRZBmgUCBbYIq X-IronPort-AV: E=Sophos;i="4.95,691,1384300800"; d="scan'208,217";a="298292923" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 20 Jan 2014 16:05:48 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0KG5lfP016709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jan 2014 16:05:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Mon, 20 Jan 2014 10:05:47 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" Thread-Topic: Review of draft-ietf-pcp-proxy-04 Thread-Index: Ac8V+XYFwCZwUiErRFWZJpB8oQYf6A== Date: Mon, 20 Jan 2014 16:05:46 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2428DACF@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.66.147] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2428DACFxmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Review of draft-ietf-pcp-proxy-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 16:05:51 -0000 --_000_913383AAA69FF945B8F946018B75898A2428DACFxmbrcdx10ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ok, If that's the case - Is there consensus that PCP auth draft will addres= s the below comments to explain the usage of PCP proxy when auth is used ? Best Regards, -Tiru. From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, January 20, 2014 6:30 PM To: Tirumaleswar Reddy (tireddy) Cc: Dan Wing (dwing); Reinaldo Penno (repenno); pcp@ietf.org Subject: RE: Review of draft-ietf-pcp-proxy-04 Hi Tiru, Thanks for the comments. Please see inline. Cheers, Med De : Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Envoy=E9 : lundi 20 janvier 2014 13:28 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Dan Wing (dwing); Reinaldo Penno (repenno); pcp@ietf.org Objet : Review of draft-ietf-pcp-proxy-04 Hi Med, Comments: a) If PCP authentication is used, Is there a need to still use THIRD_PARTY opt= ion for the use case "No NAT is Co-located with the PCP Proxy" in section = 6 of the draft ? [Med] THIRD_PARTY option is needed even if no NAT is co-located with the PC= P Proxy (e.g., DS-Lite context). For other contexts than DS-Lite, if the so= urce IP address is not altered by the PCP proxy, the proxy has to inspect a= ll incoming packets to find out pcp ones and therefore enforces the appropr= iate policies. Altering the source IP address by the pcp proxy is a solutio= n to redirect all the incoming pcp traffic explicitly to the PCP proxy. In= addition, as indicated below, proxy implications on authentication are out= of scope of this document. The proxy document adopts the same rationale as= the base pcp specification. b) Are you planning to update the draft with details about the usage of PCP p= roxy with PCP auth. [Med] NO. The plan is to follow what have been presented during the Berlin = meeting (http://www.ietf.org/proceedings/87/slides/slides-87-pcp-2.pdf): "P= roxy implication on authentication are out of scope and should be specified= in pcp-authentication document" In addition to the existing use cases this integration will be useful for h= ttp://tools.ietf.org/html/draft-wing-pcp-flowdata-00 where the PCP proxy in= the Home network receives the flow characteristics signaled by the PCP cli= ent and propagates the flow characteristics to the PCP Server in the Access= Network. Cheers, -Tiru. --_000_913383AAA69FF945B8F946018B75898A2428DACFxmbrcdx10ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ok, If that’s th= e case - Is there consensus that PCP auth draft will address the below comm= ents to explain the usage of PCP proxy when auth is used ?

 

Best Regards,

-Tiru.

From: mohamed.= boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Monday, January 20, 2014 6:30 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Dan Wing (dwing); Reinaldo Penno (repenno); pcp@ietf.org
Subject: RE: Review of draft-ietf-pcp-proxy-04

 

Hi Tiru,

 

Thanks for the comments.

 

Please see inline.

Cheers,

Med

 

 

Hi Med,

 

Comments:

 

a)

If PCP authentication is used, Is there a need to st= ill use THIRD_PARTY option for the use case “No NAT is Co-located wit= h the PCP Proxy”  in section 6 of the draft ?

[Med] THIRD_PARTY option is needed eve= n if no NAT is co-located with the PCP Proxy (e.g., DS-Lite context). For o= ther contexts than DS-Lite, if the source IP address is not altered by the PCP proxy, the proxy has to inspect all incoming pac= kets to find out pcp ones and therefore enforces the appropriate policies. = Altering the source IP address by the pcp proxy is a solution to redirect a= ll the incoming  pcp traffic explicitly to the PCP proxy. In addition, as indicated below, proxy implications on a= uthentication are out of scope of this document. The proxy document adopts = the same rationale as the base pcp specification.

 

b)

Are you planning to update the draft  with deta= ils about the usage of PCP proxy with PCP auth.

[Med] NO. The plan is to follow what h= ave been presented during the Berlin meeting (http://www.ietf= .org/proceedings/87/slides/slides-87-pcp-2.pdf): “Proxy implication on authentication are out of scope and should be = specified in pcp-authentication document”

 

In addition to the existing use cases this integrati= on will be useful for http://to= ols.ietf.org/html/draft-wing-pcp-flowdata-00 where the PCP proxy in the= Home network receives the flow characteristics signaled by the PCP client = and propagates the flow characteristics to the PCP Server in the Access Network.

 

Cheers,

-Tiru.

--_000_913383AAA69FF945B8F946018B75898A2428DACFxmbrcdx10ciscoc_-- From dthaler@microsoft.com Mon Jan 20 17:32:02 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA351A0272 for ; Mon, 20 Jan 2014 17:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rkc-GVUD6WK for ; Mon, 20 Jan 2014 17:31:59 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 679B41A0255 for ; Mon, 20 Jan 2014 17:31:59 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB410.namprd03.prod.outlook.com (10.141.141.16) with Microsoft SMTP Server (TLS) id 15.0.847.13; Tue, 21 Jan 2014 01:31:57 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.00.0847.008; Tue, 21 Jan 2014 01:31:57 +0000 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: WG Call for Adoption: Updates to the PCP Specification Thread-Index: Ac8WSAKps2kh8549QXC1rQ7lWh/u/w== Date: Tue, 21 Jan 2014 01:31:56 +0000 Message-ID: <910ca6b9345845e599c06cc77ffbf9c1@BY2PR03MB412.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::3] x-forefront-prvs: 0098BA6C6C x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(164054003)(189002)(199002)(87266001)(63696002)(79102001)(81816001)(76176001)(76576001)(31966008)(74502001)(47446002)(74662001)(85306002)(81542001)(81342001)(76786001)(76796001)(69226001)(15975445006)(77982001)(59766001)(54316002)(56776001)(83072002)(65816001)(49866001)(47976001)(47736001)(4396001)(85852003)(80022001)(19580395003)(15202345003)(53806001)(54356001)(46102001)(74706001)(19300405004)(51856001)(33646001)(50986001)(83322001)(86362001)(80976001)(93516002)(87936001)(76482001)(2656002)(56816005)(74316001)(81686001)(93136001)(74876001)(92566001)(90146001)(74366001)(16236675002)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB410; H:BY2PR03MB412.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::3; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_910ca6b9345845e599c06cc77ffbf9c1BY2PR03MB412namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [pcp] WG Call for Adoption: Updates to the PCP Specification X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 01:32:02 -0000 --_000_910ca6b9345845e599c06cc77ffbf9c1BY2PR03MB412namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, This email starts a 2-week consensus call on adopting "Updates to the PCP Specification" as a WG item. Title : Updates to the PCP Specification Authors : S. Cheshire and S. Perreault Filename: draft-cheshire-pcp-unsupp-family-06 URL : http://tools.ietf.org/html/draft-cheshire-pcp-unsupp-family-06 Please read the current revision and state on the mailing list your opinion either for or against adoption. The call for adoption ends 3rd February 2014. Thanks, Chairs --_000_910ca6b9345845e599c06cc77ffbf9c1BY2PR03MB412namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

This email starts a 2-week consensus call on adopting "Updates to t= he PCP

Specification" as a WG item.

 

Title   : Updates to the PCP Specification

Authors : S. Cheshire and S. Perreault

Filename: draft-cheshire-pcp-unsupp-family-06

URL     : http://tools.ietf.org/html/draft-cheshire-pcp-unsupp-family-06

 

Please read the current revision and state on the mailing list your=

opinion either for or against adoption.

 

The call for adoption ends 3rd February 2014.

 

Thanks,

Chairs

--_000_910ca6b9345845e599c06cc77ffbf9c1BY2PR03MB412namprd03pro_-- From mohamed.boucadair@orange.com Tue Jan 21 00:06:57 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5611A02A4 for ; Tue, 21 Jan 2014 00:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aWFtnP92aTZ for ; Tue, 21 Jan 2014 00:06:55 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id A1EE71A0048 for ; Tue, 21 Jan 2014 00:06:54 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 21B122DC151; Tue, 21 Jan 2014 09:06:53 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id F346135C06A; Tue, 21 Jan 2014 09:06:52 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 21 Jan 2014 09:06:52 +0100 From: To: "Tirumaleswar Reddy (tireddy)" Date: Tue, 21 Jan 2014 09:06:51 +0100 Thread-Topic: Review of draft-ietf-pcp-proxy-04 Thread-Index: Ac8V+XYFwCZwUiErRFWZJpB8oQYf6AAhhSfg Message-ID: <94C682931C08B048B7A8645303FDC9F36F46255636@PUEXCB1B.nanterre.francetelecom.fr> References: <913383AAA69FF945B8F946018B75898A2428DACF@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2428DACF@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: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36F46255636PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.21.62115 Cc: "pcp@ietf.org" Subject: Re: [pcp] Review of draft-ietf-pcp-proxy-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 08:06:57 -0000 --_000_94C682931C08B048B7A8645303FDC9F36F46255636PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, I wasn't in the meeting, but the minutes do not mention any objection to th= e proposal made in the prez: see http://tools.ietf.org/wg/pcp/minutes?item= =3Dminutes-88-pcp.html. Cheers, Med De : Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Envoy=E9 : lundi 20 janvier 2014 17:06 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Dan Wing (dwing); Reinaldo Penno (repenno); pcp@ietf.org Objet : RE: Review of draft-ietf-pcp-proxy-04 Ok, If that's the case - Is there consensus that PCP auth draft will addres= s the below comments to explain the usage of PCP proxy when auth is used ? Best Regards, -Tiru. From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, January 20, 2014 6:30 PM To: Tirumaleswar Reddy (tireddy) Cc: Dan Wing (dwing); Reinaldo Penno (repenno); pcp@ietf.org Subject: RE: Review of draft-ietf-pcp-proxy-04 Hi Tiru, Thanks for the comments. Please see inline. Cheers, Med De : Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Envoy=E9 : lundi 20 janvier 2014 13:28 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Dan Wing (dwing); Reinaldo Penno (repenno); pcp@ietf.org Objet : Review of draft-ietf-pcp-proxy-04 Hi Med, Comments: a) If PCP authentication is used, Is there a need to still use THIRD_PARTY opt= ion for the use case "No NAT is Co-located with the PCP Proxy" in section = 6 of the draft ? [Med] THIRD_PARTY option is needed even if no NAT is co-located with the PC= P Proxy (e.g., DS-Lite context). For other contexts than DS-Lite, if the so= urce IP address is not altered by the PCP proxy, the proxy has to inspect a= ll incoming packets to find out pcp ones and therefore enforces the appropr= iate policies. Altering the source IP address by the pcp proxy is a solutio= n to redirect all the incoming pcp traffic explicitly to the PCP proxy. In= addition, as indicated below, proxy implications on authentication are out= of scope of this document. The proxy document adopts the same rationale as= the base pcp specification. b) Are you planning to update the draft with details about the usage of PCP p= roxy with PCP auth. [Med] NO. The plan is to follow what have been presented during the Berlin = meeting (http://www.ietf.org/proceedings/87/slides/slides-87-pcp-2.pdf): "P= roxy implication on authentication are out of scope and should be specified= in pcp-authentication document" In addition to the existing use cases this integration will be useful for h= ttp://tools.ietf.org/html/draft-wing-pcp-flowdata-00 where the PCP proxy in= the Home network receives the flow characteristics signaled by the PCP cli= ent and propagates the flow characteristics to the PCP Server in the Access= Network. Cheers, -Tiru. --_000_94C682931C08B048B7A8645303FDC9F36F46255636PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

I wasn’t in the meeting, but the minutes do not mention any object= ion to the proposal made in the prez: see http://tools.ietf.org/wg/pcp/min= utes?item=3Dminutes-88-pcp.html.

Cheers,<= /p>

Med

&nbs= p;

De = : Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
= Envoy=E9 : lundi 20 janvier 2014 17:06
=C0 : BOU= CADAIR Mohamed IMT/OLN
Cc : Dan Wing (dwing); Reinaldo Penno= (repenno); pcp@ietf.org
Objet : RE: Review of draft-ietf-pc= p-proxy-04

 = ;

Ok, If that&#= 8217;s the case - Is there consensus that PCP auth draft will address the b= elow comments to explain the usage of PCP proxy when auth is used ?

 = ;

Best R= egards,

-Tiru.

= From:= mohamed.boucadair@orange= .com [mailto:mohamed.bouc= adair@orange.com]
Sent: Monday, January 20, 2014 6:30 PM
<= b>To: Tirumaleswar Reddy (tireddy)
Cc: Dan Wing (dwing); Rein= aldo Penno (repenno); pcp@ietf.org
= Subject: RE: Review of draft-ietf-pcp-proxy-04

 

Hi Ti= ru,

 

Thanks for the comments.

 

Please see inline.

Cheers,

Med

 

De : Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Envoy=E9 : lund= i 20 janvier 2014 13:28
=C0 : BOUCADAIR Mohamed IMT/OLN
<= b>Cc : Dan Wing (dwing); Reinaldo Penno (repenno); pcp@ietf.org
Objet := Review of draft-ietf-pcp-proxy-04

 

Hi Med,<= /p>

 

Comments:=

 

a)

If PCP authentication is used, Is = there a need to still use THIRD_PARTY option for the use case “No NAT= is Co-located with the PCP Proxy”  in section 6 of the draft ?<= o:p>

[Med] THIRD_PARTY option is needed e= ven if no NAT is co-located with the PCP Proxy (e.g., DS-Lite context). For= other contexts than DS-Lite, if the source IP address is not altered by th= e PCP proxy, the proxy has to inspect all incoming packets to find out pcp = ones and therefore enforces the appropriate policies. Altering the source I= P address by the pcp proxy is a solution to redirect all the incoming = pcp traffic explicitly to the PCP proxy. In addition, as indicated below, = proxy implications on authentication are out of scope of this document. The= proxy document adopts the same rationale as the base pcp specification.

 

<= p class=3DMsoNormal>b)

Are you planning = to update the draft  with details about the usage of PCP proxy with PC= P auth.

[Med] NO. The plan is to follow what have been presented during th= e Berlin meeting (http://www.ietf.org/proceedings/87/slides/slides-87-p= cp-2.pdf): “Proxy implication on authenticatio= n are out of scope and should be specified in pcp-authentication document&#= 8221;

 

In addition to the existing use= cases this integration will be useful for http://tools.ietf.org/html/draft-wing-pcp= -flowdata-00 where the PCP proxy in the Home network receives the flow = characteristics signaled by the PCP client and propagates the flow characte= ristics to the PCP Server in the Access Network.

 

Cheers,

-Tiru.

= --_000_94C682931C08B048B7A8645303FDC9F36F46255636PUEXCB1Bnante_-- From tireddy@cisco.com Tue Jan 21 01:17:53 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2844D1A00AA for ; Tue, 21 Jan 2014 01:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5S2Pp3P_ZEHJ for ; Tue, 21 Jan 2014 01:17:49 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 82E6F1A00A9 for ; Tue, 21 Jan 2014 01:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20141; q=dns/txt; s=iport; t=1390295870; x=1391505470; h=from:to:cc:subject:date:message-id:mime-version; bh=0oMERNRUhID0pM8fS2FBcoNvBN0lL1D3d+sQn1LtKqE=; b=asjsmrvB+NReYIRWLuYeyxzhsfL/ibkoPB05e3SL3XB9FdRG3es/V1+N LcU9PvoJPPvR0UCGTHPtlEkYFBUSz907j+y8tvUG4HB3zKOGxrONxr6eK t2Q8EJDZHH4/Gd3Lj/DnAKr3othA7SBoCHad7J+3p1025tf+1Ww444jkR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoHAIk63lKtJV2c/2dsb2JhbABZgkdEOFazCIhUgQ8WdIIlAQEBAgItTBIBCBEEAQELFgc5FAkJAQQOBQgBEodqDcN3F45OMQaDJYEUBIkPkEWQZoFAgW2CKg X-IronPort-AV: E=Sophos;i="4.95,695,1384300800"; d="scan'208,217";a="298586874" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 21 Jan 2014 09:17:49 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0L9Hm8s011613 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 09:17:48 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 03:17:48 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" Thread-Topic: Review of draft-ietf-pcp-proxy-04 Thread-Index: Ac8WiaNKNMVDkcsfTkSd6nIEWusG1g== Date: Tue, 21 Jan 2014 09:17:47 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2428E325@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.58.147] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2428E325xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Review of draft-ietf-pcp-proxy-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 09:17:53 -0000 --_000_913383AAA69FF945B8F946018B75898A2428E325xmbrcdx10ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, Even I wasn't present in the meeting and could not give feedback :) But would like this topic to be discussed in one of these drafts. -Tiru. From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Tuesday, January 21, 2014 1:37 PM To: Tirumaleswar Reddy (tireddy) Cc: Dan Wing (dwing); Reinaldo Penno (repenno); pcp@ietf.org Subject: RE: Review of draft-ietf-pcp-proxy-04 Hi Tiru, I wasn't in the meeting, but the minutes do not mention any objection to th= e proposal made in the prez: see http://tools.ietf.org/wg/pcp/minutes?item= =3Dminutes-88-pcp.html. Cheers, Med De : Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Envoy=E9 : lundi 20 janvier 2014 17:06 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Dan Wing (dwing); Reinaldo Penno (repenno); pcp@ietf.org Objet : RE: Review of draft-ietf-pcp-proxy-04 Ok, If that's the case - Is there consensus that PCP auth draft will addres= s the below comments to explain the usage of PCP proxy when auth is used ? Best Regards, -Tiru. From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, January 20, 2014 6:30 PM To: Tirumaleswar Reddy (tireddy) Cc: Dan Wing (dwing); Reinaldo Penno (repenno); pcp@ietf.org Subject: RE: Review of draft-ietf-pcp-proxy-04 Hi Tiru, Thanks for the comments. Please see inline. Cheers, Med De : Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Envoy=E9 : lundi 20 janvier 2014 13:28 =C0 : BOUCADAIR Mohamed IMT/OLN Cc : Dan Wing (dwing); Reinaldo Penno (repenno); pcp@ietf.org Objet : Review of draft-ietf-pcp-proxy-04 Hi Med, Comments: a) If PCP authentication is used, Is there a need to still use THIRD_PARTY opt= ion for the use case "No NAT is Co-located with the PCP Proxy" in section = 6 of the draft ? [Med] THIRD_PARTY option is needed even if no NAT is co-located with the PC= P Proxy (e.g., DS-Lite context). For other contexts than DS-Lite, if the so= urce IP address is not altered by the PCP proxy, the proxy has to inspect a= ll incoming packets to find out pcp ones and therefore enforces the appropr= iate policies. Altering the source IP address by the pcp proxy is a solutio= n to redirect all the incoming pcp traffic explicitly to the PCP proxy. In= addition, as indicated below, proxy implications on authentication are out= of scope of this document. The proxy document adopts the same rationale as= the base pcp specification. b) Are you planning to update the draft with details about the usage of PCP p= roxy with PCP auth. [Med] NO. The plan is to follow what have been presented during the Berlin = meeting (http://www.ietf.org/proceedings/87/slides/slides-87-pcp-2.pdf): "P= roxy implication on authentication are out of scope and should be specified= in pcp-authentication document" In addition to the existing use cases this integration will be useful for h= ttp://tools.ietf.org/html/draft-wing-pcp-flowdata-00 where the PCP proxy in= the Home network receives the flow characteristics signaled by the PCP cli= ent and propagates the flow characteristics to the PCP Server in the Access= Network. Cheers, -Tiru. --_000_913383AAA69FF945B8F946018B75898A2428E325xmbrcdx10ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

Even I wasn’t pr= esent in the meeting and could not give feedback J

But would like this to= pic to be discussed in one of these drafts.

 

-Tiru.

From: mohamed.= boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Tuesday, January 21, 2014 1:37 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Dan Wing (dwing); Reinaldo Penno (repenno); pcp@ietf.org
Subject: RE: Review of draft-ietf-pcp-proxy-04

 

Hi Tiru,

 

I wasn’t in the meeting, but the minut= es do not mention any objection to the proposal made in the prez: see .

 

Cheers,

Med

 

 

Ok, If that’s th= e case - Is there consensus that PCP auth draft will address the below comm= ents to explain the usage of PCP proxy when auth is used ?

 

Best Regards,

-Tiru.

From: mohamed.= boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Monday, January 20, 2014 6:30 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Dan Wing (dwing); Reinaldo Penno (repenno); pcp@ietf.org
Subject: RE: Review of draft-ietf-pcp-proxy-04

 

Hi Tiru,

 

Thanks for the comments.

 

Please see inline.

Cheers,

Med

 

 

Hi Med,

 

Comments:

 

a)

If PCP authentication is used, Is there a need to st= ill use THIRD_PARTY option for the use case “No NAT is Co-located wit= h the PCP Proxy”  in section 6 of the draft ?

[Med] THIRD_PARTY option is needed eve= n if no NAT is co-located with the PCP Proxy (e.g., DS-Lite context). For o= ther contexts than DS-Lite, if the source IP address is not altered by the PCP proxy, the proxy has to inspect all incoming pac= kets to find out pcp ones and therefore enforces the appropriate policies. = Altering the source IP address by the pcp proxy is a solution to redirect a= ll the incoming  pcp traffic explicitly to the PCP proxy. In addition, as indicated below, proxy implications on a= uthentication are out of scope of this document. The proxy document adopts = the same rationale as the base pcp specification.

 

b)

Are you planning to update the draft  with deta= ils about the usage of PCP proxy with PCP auth.

[Med] NO. The plan is to follow what h= ave been presented during the Berlin meeting (http://www.ietf= .org/proceedings/87/slides/slides-87-pcp-2.pdf): “Proxy implication on authentication are out of scope and should be = specified in pcp-authentication document”

 

In addition to the existing use cases this integrati= on will be useful for http://to= ols.ietf.org/html/draft-wing-pcp-flowdata-00 where the PCP proxy in the= Home network receives the flow characteristics signaled by the PCP client = and propagates the flow characteristics to the PCP Server in the Access Network.

 

Cheers,

-Tiru.

--_000_913383AAA69FF945B8F946018B75898A2428E325xmbrcdx10ciscoc_-- From tireddy@cisco.com Tue Jan 21 01:24:39 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFDC1A0102 for ; Tue, 21 Jan 2014 01:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id murOTMINwrxP for ; Tue, 21 Jan 2014 01:24:36 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A67EA1A0090 for ; Tue, 21 Jan 2014 01:24:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10605; q=dns/txt; s=iport; t=1390296277; x=1391505877; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=1AkDsEH2vUa2zyPnmw0MLpR44fvYxcCBROSAwj6Gct0=; b=k312xjnEgtywNLuSsNJS2LQtDYpOJV9918iGvTQnzyGoDAkgf9twj4eG Enia7B3pKao5vsKJbm8z4wDwdAT5JPjbWN69V9Ghl+NlxY3zbcMXnCosx g/b4827rSPDP94ipoUJBvniJz/iVxcz0rfSzlQCW7D2cCINAZgH8W3anp o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoHALI73lKtJV2b/2dsb2JhbABZgkdEOFazCIhUgQ8WdIIlAQEBBB0QQAEbAgEIDgMEAQELHQcyFAkIAgQBEgiHfQ3DdxeOHREBHzcBgySBFASZVJBmgy2BcTk X-IronPort-AV: E=Sophos;i="4.95,695,1384300800"; d="scan'208,217";a="298588199" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 21 Jan 2014 09:24:36 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0L9OaJL005509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 09:24:36 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 03:24:36 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Dave Thaler , "pcp@ietf.org" Thread-Topic: [pcp] WG Call for Adoption: Updates to the PCP Specification Thread-Index: AQHPFom3smyJFk/fNUeFRZM2kOZAmZqO5p2Q Date: Tue, 21 Jan 2014 09:24:35 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2428E371@xmb-rcd-x10.cisco.com> References: <910ca6b9345845e599c06cc77ffbf9c1@BY2PR03MB412.namprd03.prod.outlook.com> In-Reply-To: <910ca6b9345845e599c06cc77ffbf9c1@BY2PR03MB412.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.58.147] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2428E371xmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: Re: [pcp] WG Call for Adoption: Updates to the PCP Specification X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 09:24:39 -0000 --_000_913383AAA69FF945B8F946018B75898A2428E371xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support adopting the draft. Comments on the current version of the draft: For section "Nonce Check Behavior" you may want to consider the following a= spects: a) When PCP authentication is used discuss the behavior of PCP server. comment 1> I don't see any security threat that client re-boots, loses nonc= e, authenticates again, Authenticated PCP client can find the existing map= pings without remembering the nonce and can even renew or delete the existi= ng mapping. b) Section 3 discusses the problem about new host receiving the same IP add= ress of old host leaving the network comment2> This problem could also be resolved by PCP auth. PCP Server would= find out that a different user has authenticated from the same IP address = and hence can try to do re-authentication with the old user, if no response= is received then PCP server can delete the existing mappings. c) Section 5 comment 3> PCP authentication solves the problem of preventing a user from = learning the existing mappings of a different user. comment 4> The problem of bogus mappings could be resolved either by PCP au= thentication or IP Source guard. -Tiru. From: Dave Thaler [mailto:dthaler@microsoft.com] Sent: Tuesday, January 21, 2014 7:02 AM To: pcp@ietf.org Subject: [pcp] WG Call for Adoption: Updates to the PCP Specification Hello, This email starts a 2-week consensus call on adopting "Updates to the PCP Specification" as a WG item. Title : Updates to the PCP Specification Authors : S. Cheshire and S. Perreault Filename: draft-cheshire-pcp-unsupp-family-06 URL : http://tools.ietf.org/html/draft-cheshire-pcp-unsupp-family-06 Please read the current revision and state on the mailing list your opinion either for or against adoption. The call for adoption ends 3rd February 2014. Thanks, Chairs --_000_913383AAA69FF945B8F946018B75898A2428E371xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support adopting the= draft.

 

Comments on the curren= t version of the draft:

For section "Nonc= e Check Behavior" you may want to consider the following aspects:=

 

a) When PCP authentica= tion is used discuss the behavior of PCP server. 

 

comment 1> I don't = see any security threat that client re-boots, loses nonce,  authentica= tes again, Authenticated PCP client can find the existing mappings without = remembering the nonce and can even renew or delete the existing mapping.

 

b) Section 3 discusses= the problem about new host receiving the same IP address of old host leavi= ng the network

 

comment2> This prob= lem could also be resolved by PCP auth. PCP Server would find out that a di= fferent user has authenticated from the same IP address and hence can try t= o do re-authentication with the old user, if no response is received then PCP server can delete the existing mapping= s.

 

c) Section 5

 

comment 3> PCP auth= entication solves the problem of preventing a user from learning the existi= ng mappings of a different user.

comment 4> The prob= lem of bogus mappings could be resolved either by PCP authentication or IP = Source guard.

 

-Tiru.

From: Dave Tha= ler [mailto:dthaler@microsoft.com]
Sent: Tuesday, January 21, 2014 7:02 AM
To: pcp@ietf.org
Subject: [pcp] WG Call for Adoption: Updates to the PCP Specificatio= n

 

Hello,

 

This email starts a 2-week consensus call on adopting "Updates to t= he PCP

Specification" as a WG item.

 

Title   : Updates to the PCP Specification

Authors : S. Cheshire and S. Perreault

Filename: draft-cheshire-pcp-unsupp-family-06

URL     : http://tools.ietf.org/html/draft-cheshire-pcp-unsupp-family-06

 

Please read the current revision and state on the mailing list your=

opinion either for or against adoption.

 

The call for adoption ends 3rd February 2014.

 

Thanks,

Chairs

--_000_913383AAA69FF945B8F946018B75898A2428E371xmbrcdx10ciscoc_-- From simon.perreault@viagenie.ca Tue Jan 21 06:58:43 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009E91A0167 for ; Tue, 21 Jan 2014 06:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06xqo64k0uhc for ; Tue, 21 Jan 2014 06:58:41 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D16A21A014A for ; Tue, 21 Jan 2014 06:58:41 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 98ACD40367 for ; Tue, 21 Jan 2014 09:58:41 -0500 (EST) Message-ID: <52DE8B21.7060402@viagenie.ca> Date: Tue, 21 Jan 2014 09:58:41 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pcp@ietf.org References: <910ca6b9345845e599c06cc77ffbf9c1@BY2PR03MB412.namprd03.prod.outlook.com> <913383AAA69FF945B8F946018B75898A2428E371@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2428E371@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] WG Call for Adoption: Updates to the PCP Specification X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 14:58:43 -0000 Le 2014-01-21 04:24, Tirumaleswar Reddy (tireddy) a écrit : > For section "Nonce Check Behavior" you may want to consider the > following aspects: > > a) When PCP authentication is used discuss the behavior of PCP server. > > comment 1> I don't see any security threat that client re-boots, loses > nonce, authenticates again, Authenticated PCP client can find the > existing mappings without remembering the nonce and can even renew or > delete the existing mapping. I'm sorry, I don't understand what your point is. What are the changes that you are suggesting? > b) Section 3 discusses the problem about new host receiving the same IP > address of old host leaving the network > > comment2> This problem could also be resolved by PCP auth. PCP Server > would find out that a different user has authenticated from the same IP > address and hence can try to do re-authentication with the old user, if > no response is received then PCP server can delete the existing mappings. Correct, but IMHO auth is out of scope for this doc. > c) Section 5 > > comment 3> PCP authentication solves the problem of preventing a user > from learning the existing mappings of a different user. > > comment 4> The problem of bogus mappings could be resolved either by PCP > authentication or IP Source guard. Both are correct, but IMHO both are also out of scope. 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 iesg-secretary@ietf.org Tue Jan 21 12:03:40 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F2D1A0349; Tue, 21 Jan 2014 12:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OU8qi7pDX5Bl; Tue, 21 Jan 2014 12:03:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DAC1A0257; Tue, 21 Jan 2014 12:03:39 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140121200339.19952.55011.idtracker@ietfa.amsl.com> Date: Tue, 21 Jan 2014 12:03:39 -0800 Cc: pcp@ietf.org Subject: [pcp] Last Call: (PCP Description Option) to Proposed Standard X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 20:03:40 -0000 The IESG has received a request from the Port Control Protocol WG (pcp) to consider the following document: - 'PCP Description Option' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-02-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document extends Port Control Protocol (PCP) with the ability to associate a description with a PCP-instantiated mapping. It does so by defining a new DESCRIPTION option. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pcp-description-option/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pcp-description-option/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Tue Jan 21 12:58:27 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774861A0253; Tue, 21 Jan 2014 12:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YLM8oPnDfLJ; Tue, 21 Jan 2014 12:58:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 262851A022C; Tue, 21 Jan 2014 12:58:26 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140121205825.3741.96281.idtracker@ietfa.amsl.com> Date: Tue, 21 Jan 2014 12:58:25 -0800 Cc: pcp@ietf.org Subject: [pcp] Last Call: (Learning NAT64 PREFIX64s using PCP) to Proposed Standard X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 20:58:27 -0000 The IESG has received a request from the Port Control Protocol WG (pcp) to consider the following document: - 'Learning NAT64 PREFIX64s using PCP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-02-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a new PCP extension to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses. This extension is needed for successful communications when IPv4 addresses are used in referrals. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pcp-nat64-prefix64/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pcp-nat64-prefix64/ballot/ No IPR declarations have been submitted directly on this I-D. From hassnaa.moustafa@intel.com Tue Jan 21 13:15:05 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACE51A0169 for ; Tue, 21 Jan 2014 13:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.435 X-Spam-Level: X-Spam-Status: No, score=-7.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i_C_9rFmPlQL for ; Tue, 21 Jan 2014 13:15:01 -0800 (PST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id B988E1A0166 for ; Tue, 21 Jan 2014 13:15:01 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 21 Jan 2014 13:15:01 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.95,697,1384329600"; d="scan'208,217";a="470332123" Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by orsmga002.jf.intel.com with ESMTP; 21 Jan 2014 13:15:00 -0800 Received: from orsmsx102.amr.corp.intel.com ([169.254.1.197]) by ORSMSX106.amr.corp.intel.com ([169.254.5.234]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 13:15:00 -0800 From: "Moustafa, Hassnaa" To: "pcp@ietf.org" Thread-Topic: Comments on draft-wing-pcp-flowdata-00 Thread-Index: Ac8W4q0/PYU9Q5VUTCqetHyRnU67zg== Date: Tue, 21 Jan 2014 21:15:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] Content-Type: multipart/alternative; boundary="_000_F893BEC192403B489DBA38999068CF190597E416ORSMSX102amrcor_" MIME-Version: 1.0 Subject: [pcp] Comments on draft-wing-pcp-flowdata-00 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 21:15:05 -0000 --_000_F893BEC192403B489DBA38999068CF190597E416ORSMSX102amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan, Reinaldo and Tiru, To follow up the discussion on draft-wing-pcp-flowdata-00, I have some que= stions as follows: In Section 3.2 (Figure 1 and Figure 2): what does the PCP server represent,= is it an edge router in the network? Does it have specific role for QoS ma= nagement (is there any association with diffserv operation at that node)? In Section 3.2: the second paragraphs mentions the use of "FlowData option"= for flows terminated by the PCP client (when operating s server): this exa= mple (when operating as a server) is not clear for me. Is there a concrete = service example for that? In Section 3.4: - it is mentioned that the PCP client can use the information in the= Flowdata fields in PCP response to influence the traffic it sends and rece= ives: how can the PCP client influence the traffic it receives? - An example is also given for Flowdata response indicating how the = network can accommodate a flow for a certain downstream bandwidth: is this = also valid for upstream case? In Section 3.6: It is not clear why the mapping is sent 3 times in Figure = 5 In section 7: It is mentioned that the short lived flows will receive no be= nefit from the flowdata signaling: The reason is not that clear for me espe= cially if the short flows needs certain level of QoE. Thanks for your feedback on these questions. Hassnaa --_000_F893BEC192403B489DBA38999068CF190597E416ORSMSX102amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dan, Reinaldo and Tiru,

 

To follow up the discussion on  draft-wing-pcp-= flowdata-00, I have some questions as follows:

 

In Section 3.2 (Figure 1 and Figure 2): what does th= e PCP server represent, is it an edge router in the network? Does it have s= pecific role for QoS management (is there any association with diffserv ope= ration at that node)?

 

In Section 3.2: the second paragraphs mentions the u= se of “FlowData option” for flows terminated by the PCP client = (when operating s server): this example (when operating as a server) is not= clear for me. Is there a concrete service example for that?

 

In Section 3.4:

-     &= nbsp;  it is mentioned that the PCP client can use the inf= ormation in the Flowdata fields in PCP response to influence the traffic it= sends and receives: how can the PCP client influence the traffic it receiv= es?

-     &= nbsp;  An example is also given for Flowdata response indi= cating how the network can accommodate a flow for a certain downstream band= width: is this also valid for upstream case?

 

In Section 3.6: It  is not clear why the mappin= g is sent 3 times in Figure 5

 

In section 7: It is mentioned that the short lived f= lows will receive no benefit from the flowdata signaling: The reason is not= that clear for me especially if the short flows needs certain level of QoE= .

 

Thanks for your feedback on these questions.

 

Hassnaa

--_000_F893BEC192403B489DBA38999068CF190597E416ORSMSX102amrcor_-- From tireddy@cisco.com Tue Jan 21 19:49:57 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DDE1A01BF for ; Tue, 21 Jan 2014 19:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YnyqUgcC2fQ for ; Tue, 21 Jan 2014 19:49:56 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id EEAAA1A0017 for ; Tue, 21 Jan 2014 19:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2214; q=dns/txt; s=iport; t=1390362596; x=1391572196; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=SSbeO46IZKMBf9cdL84zXsrlWQ/cchN0PwAN9NuotSU=; b=l9AdJmig532xMv4mgYZuxuZLH817F2pNFfNL8MrXsNyraBnmYHHzUUAU WFCHx0zIrp7WQAxpeoiZlK7pIPUlBtYaHuAlZCwgA6HLJ/M+4qh+DkG/b EUkEH/M6leM09jhyL4ox1jgq8WXrH0xmKRxYLPpPjNQr+VEcGuEv8Phxl o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFALI+31KtJXG+/2dsb2JhbABagws4VrtvgRIWdIIlAQEBAwEdCkYYBgEIEQQBAQsdORQJCQEEARIIh3UIwmEXjk4+gx6BFASJD5BFkGaDLYIq X-IronPort-AV: E=Sophos;i="4.95,697,1384300800"; d="scan'208";a="14533231" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-3.cisco.com with ESMTP; 22 Jan 2014 03:49:55 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0M3ntNf015350 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jan 2014 03:49:55 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 21:49:55 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , "pcp@ietf.org" Thread-Topic: [pcp] WG Call for Adoption: Updates to the PCP Specification Thread-Index: Ac8XJQEJb7SUzGa4T/+pceJp6RZsfw== Date: Wed, 22 Jan 2014 03:49:54 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2428EBAF@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.75.153] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] WG Call for Adoption: Updates to the PCP Specification X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 03:49:57 -0000 Hi Simon, Please see inline > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Tuesday, January 21, 2014 8:29 PM > To: pcp@ietf.org > Subject: Re: [pcp] WG Call for Adoption: Updates to the PCP Specification >=20 > Le 2014-01-21 04:24, Tirumaleswar Reddy (tireddy) a =E9crit : > > For section "Nonce Check Behavior" you may want to consider the > > following aspects: > > > > a) When PCP authentication is used discuss the behavior of PCP server. > > > > comment 1> I don't see any security threat that client re-boots, loses > > nonce, authenticates again, Authenticated PCP client can find the > > existing mappings without remembering the nonce and can even renew or > > delete the existing mapping. >=20 > I'm sorry, I don't understand what your point is. What are the changes th= at > you are suggesting ? I am suggesting that if PCP authentication is used then a authenticated PCP= client can delete or renew the mapping even if it has lost the mapping bec= ause of reboot. >=20 > > b) Section 3 discusses the problem about new host receiving the same > > IP address of old host leaving the network > > > > comment2> This problem could also be resolved by PCP auth. PCP Server > > would find out that a different user has authenticated from the same > > IP address and hence can try to do re-authentication with the old > > user, if no response is received then PCP server can delete the existin= g > mappings. >=20 > Correct, but IMHO auth is out of scope for this doc. >=20 > > c) Section 5 > > > > comment 3> PCP authentication solves the problem of preventing a user > > from learning the existing mappings of a different user. > > > > comment 4> The problem of bogus mappings could be resolved either by > > PCP authentication or IP Source guard. >=20 > Both are correct, but IMHO both are also out of scope. Any specific reason why PCP auth is out of scope ?=20 -Tiru.=20 >=20 > 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 aeh@db.org Wed Jan 22 03:33:42 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D9C1A0436 for ; Wed, 22 Jan 2014 03:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ym68O5O1uMjJ for ; Wed, 22 Jan 2014 03:33:41 -0800 (PST) Received: from mailstore06.sysedata.no (b.mail.tornado.no [195.159.29.130]) by ietfa.amsl.com (Postfix) with ESMTP id C5E2C1A0435 for ; Wed, 22 Jan 2014 03:33:40 -0800 (PST) Received: from [84.208.99.60] (helo=[192.168.1.2]) by mailstore06.sysedata.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1W5w3u-00061D-FB; Wed, 22 Jan 2014 12:33:38 +0100 Message-ID: <52DFAC92.3050209@db.org> Date: Wed, 22 Jan 2014 12:33:38 +0100 From: "Alfred E. Heggestad" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: Dave Thaler References: <910ca6b9345845e599c06cc77ffbf9c1@BY2PR03MB412.namprd03.prod.outlook.com> In-Reply-To: <910ca6b9345845e599c06cc77ffbf9c1@BY2PR03MB412.namprd03.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pcp@ietf.org" Subject: Re: [pcp] WG Call for Adoption: Updates to the PCP Specification X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 11:33:42 -0000 On 01/21/2014 02:31 AM, Dave Thaler wrote: > Hello, > > This email starts a 2-week consensus call on adopting "Updates to the PCP > > Specification" as a WG item. > > Title : Updates to the PCP Specification > > Authors : S. Cheshire and S. Perreault > > Filename: draft-cheshire-pcp-unsupp-family-06 > > URL : http://tools.ietf.org/html/draft-cheshire-pcp-unsupp-family-06 > > Please read the current revision and state on the mailing list your > > opinion either for or against adoption. > > The call for adoption ends 3rd February 2014. > I support adopting this draft. /alfred From tireddy@cisco.com Wed Jan 22 04:10:50 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796BB1A043E for ; Wed, 22 Jan 2014 04:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GU-wONGORYe for ; Wed, 22 Jan 2014 04:10:48 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 122CF1A043B for ; Wed, 22 Jan 2014 04:10:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3070; q=dns/txt; s=iport; t=1390392648; x=1391602248; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pC2pmqU3nJ2sUeJ4YPeU0EfrAdObws8DM4no12USZWw=; b=FXCLKGxLtcxP+ZD87xxUHYgg3m/LEVrNXV2YE2v7Ywkb3oA6fPY79jzy +BVkkRgTxBbRdLmt0OfRcjphw4I94djcC/P2RFCVB2/R9Kxazn+KRGrOi Va5xn306HYgcmRLw20zqzMOi37UdjpTbkjy91KAqPc2vnSXJRwjfumeb1 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFACG031KtJV2c/2dsb2JhbABagws4VrtdgRAWdIImAQEEHR0/EAIBCCIUEDIlAgQODYd9DcFsF44lJjEHgySBFASZVJBmgy2BaUE X-IronPort-AV: E=Sophos;i="4.95,699,1384300800"; d="scan'208";a="14640629" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP; 22 Jan 2014 12:10:47 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0MCAlX0010036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jan 2014 12:10:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Wed, 22 Jan 2014 06:10:47 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "hassnaa.moustafa@intel.com" Thread-Topic: [pcp] Comments on draft-wing-pcp-flowdata-00 Thread-Index: AQHPF2nk7PVpHS2FbE2wSyBxA+TTupqQpf1w Date: Wed, 22 Jan 2014 12:10:46 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2428EF9D@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.67.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-wing-pcp-flowdata-00 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 12:10:50 -0000 Hi Hassnaa,=20 Thanks for the review. Please see inline [TR] Hi Dan, Reinaldo and Tiru, =20 To follow up the discussion on draft-wing-pcp-flowdata-00, I have some que= stions as follows: =20 In Section 3.2 (Figure 1 and Figure 2): what does the PCP server represent,= is it an edge router in the network? Does it have specific role for QoS ma= nagement (is there any association with diffserv operation at that node) ? [TR] PCP Server could be the edge router in the network. For example in a h= ome network the flow description can propagate from in-home CPE router to t= he ISP's access router, and in an enterprise network the flow description c= an propagate within the enterprise network and up to the ISP's access route= r. =20 =20 In Section 3.2: the second paragraphs mentions the use of "FlowData option"= for flows terminated by the PCP client (when operating s server): this exa= mple (when operating as a server) is not clear for me. Is there a concrete = service example for that ? [TR] Yes. For example Bittorrent acting as a Server in Home Network can sig= nal the flow characteristics to the PCP Server.=20 =20 In Section 3.4:=20 - it is mentioned that the PCP client can use the information in the= Flowdata fields in PCP response to influence the traffic it sends and rece= ives: how can the PCP client influence the traffic it receives? [TR] If we consider video adaption use case in draft http://tools.ietf.org/= html/draft-eckel-aeon-use-cases-00#section-2.5.1 then HLS client can select= the chunk (bitrate) based on PCP FLOWDATA response. For example HAS client= will not retrieve a too high-bit rate chunk based on PCP FLOWDATA response= . This way adaptive bit rate applications can improve user experience by av= oiding attempts to exceed the network's upper bandwidth limit - An example is also given for Flowdata response indicating how the = network can accommodate a flow for a certain downstream bandwidth: is this = also valid for upstream case? [TR] Yes. For example PCP FLOWDATA option could be used in SIP/WebRTC call = for media session (audio, video) which includes both upstream and downstrea= m bandwidth for media streams. =20 In Section 3.6: It is not clear why the mapping is sent 3 times in Figure = 5 =20 [TR] It's sent multiple times because it is a unsolicited PCP response sent= to the client, unsolicited PCP response (over UDP) is sent multiple times= because it could be lost.=20 In section 7: It is mentioned that the short lived flows will receive no be= nefit from the flowdata signaling: The reason is not that clear for me espe= cially if the short flows needs certain level of QoE.=20 [TR] It's up to the application to decide if there is benefit in signaling = flow characteristics to the network or not. Some short lived sessions (HTT= P session which get terminated just after a single response) may not see be= nefit from this approach. -Tiru.=20 Thanks for your feedback on these questions. =20 Hassnaa From simon.perreault@viagenie.ca Wed Jan 22 06:22:06 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28711A00B6 for ; Wed, 22 Jan 2014 06:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lR47MU3P7vAE for ; Wed, 22 Jan 2014 06:22:04 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6EC1A00AC for ; Wed, 22 Jan 2014 06:22:04 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E0BBD40367; Wed, 22 Jan 2014 09:22:03 -0500 (EST) Message-ID: <52DFD40B.2010505@viagenie.ca> Date: Wed, 22 Jan 2014 09:22:03 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , "pcp@ietf.org" References: <913383AAA69FF945B8F946018B75898A2428EBAF@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2428EBAF@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] WG Call for Adoption: Updates to the PCP Specification X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 14:22:07 -0000 Le 2014-01-21 22:49, Tirumaleswar Reddy (tireddy) a écrit : >> Both are correct, but IMHO both are also out of scope. > > Any specific reason why PCP auth is out of scope ? Well, I suppose we could prefix section 3 with something like "if you use PCP auth then all the problems we're fixing in this section disappear". That's what I mean by out of scope: if you use PCP auth, then you don't experience the problem we're trying to fix. 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 hassnaa.moustafa@intel.com Wed Jan 22 06:35:28 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6809E1A00F0 for ; Wed, 22 Jan 2014 06:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.436 X-Spam-Level: X-Spam-Status: No, score=-7.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQHHMNY0z8yE for ; Wed, 22 Jan 2014 06:35:26 -0800 (PST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4E03B1A00EC for ; Wed, 22 Jan 2014 06:35:26 -0800 (PST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 22 Jan 2014 06:31:19 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.95,700,1384329600"; d="scan'208";a="442893583" Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by orsmga001.jf.intel.com with ESMTP; 22 Jan 2014 06:35:24 -0800 Received: from orsmsx102.amr.corp.intel.com ([169.254.1.197]) by ORSMSX106.amr.corp.intel.com ([169.254.5.234]) with mapi id 14.03.0123.003; Wed, 22 Jan 2014 06:35:24 -0800 From: "Moustafa, Hassnaa" To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [pcp] Comments on draft-wing-pcp-flowdata-00 Thread-Index: AQHPF2nk7PVpHS2FbE2wSyBxA+TTupqQpf1wgAApLCA= Date: Wed, 22 Jan 2014 14:35:24 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A2428EF9D@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2428EF9D@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-wing-pcp-flowdata-00 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 14:35:28 -0000 Thanks for these details and clarification. Hassnaa -----Original Message----- From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 Sent: Wednesday, January 22, 2014 4:11 AM To: Moustafa, Hassnaa Cc: pcp@ietf.org Subject: RE: [pcp] Comments on draft-wing-pcp-flowdata-00 Hi Hassnaa,=20 Thanks for the review. Please see inline [TR] Hi Dan, Reinaldo and Tiru, =20 To follow up the discussion on draft-wing-pcp-flowdata-00, I have some que= stions as follows: =20 In Section 3.2 (Figure 1 and Figure 2): what does the PCP server represent,= is it an edge router in the network? Does it have specific role for QoS ma= nagement (is there any association with diffserv operation at that node) ? [TR] PCP Server could be the edge router in the network. For example in a h= ome network the flow description can propagate from in-home CPE router to t= he ISP's access router, and in an enterprise network the flow description c= an propagate within the enterprise network and up to the ISP's access route= r. =20 =20 In Section 3.2: the second paragraphs mentions the use of "FlowData option"= for flows terminated by the PCP client (when operating s server): this exa= mple (when operating as a server) is not clear for me. Is there a concrete = service example for that ? [TR] Yes. For example Bittorrent acting as a Server in Home Network can sig= nal the flow characteristics to the PCP Server.=20 =20 In Section 3.4:=20 - it is mentioned that the PCP client can use the information in the= Flowdata fields in PCP response to influence the traffic it sends and rece= ives: how can the PCP client influence the traffic it receives? [TR] If we consider video adaption use case in draft http://tools.ietf.org/= html/draft-eckel-aeon-use-cases-00#section-2.5.1 then HLS client can select= the chunk (bitrate) based on PCP FLOWDATA response. For example HAS client= will not retrieve a too high-bit rate chunk based on PCP FLOWDATA response= . This way adaptive bit rate applications can improve user experience by av= oiding attempts to exceed the network's upper bandwidth limit - An example is also given for Flowdata response indicating how the = network can accommodate a flow for a certain downstream bandwidth: is this = also valid for upstream case? [TR] Yes. For example PCP FLOWDATA option could be used in SIP/WebRTC call = for media session (audio, video) which includes both upstream and downstrea= m bandwidth for media streams. =20 In Section 3.6: It is not clear why the mapping is sent 3 times in Figure = 5 =20 [TR] It's sent multiple times because it is a unsolicited PCP response sent= to the client, unsolicited PCP response (over UDP) is sent multiple times= because it could be lost.=20 In section 7: It is mentioned that the short lived flows will receive no be= nefit from the flowdata signaling: The reason is not that clear for me espe= cially if the short flows needs certain level of QoE.=20 [TR] It's up to the application to decide if there is benefit in signaling = flow characteristics to the network or not. Some short lived sessions (HTT= P session which get terminated just after a single response) may not see be= nefit from this approach. -Tiru.=20 Thanks for your feedback on these questions. =20 Hassnaa From tireddy@cisco.com Wed Jan 22 08:20:34 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46381A035B for ; Wed, 22 Jan 2014 08:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J--HGJXoqrrg for ; Wed, 22 Jan 2014 08:20:32 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BD7091A0198 for ; Wed, 22 Jan 2014 08:20:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1037; q=dns/txt; s=iport; t=1390407632; x=1391617232; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ytpqdzPHp61Wu0PWgFLHbJ3xnvA8gvvzZ5OivRv5GBs=; b=G0glRBb8xsdw+yx22bVJOBclofcY6L0GmoHJ/f5gADf2R7m2xOPlnSOb jStA+4V//E4OiRTnwatrnYbIFhl8Y2a1ypHiYoDG3TUuqFOZS3blpHimw LVe16sPD4nsniGehSOU4UZIwG80tDc6Q9ahnhmveeVgC4UhlSJLRLRuvz g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAPTu31KtJXG9/2dsb2JhbABbgws4VrtdgRQWdIIlAQEBAwEdCl4EAgEIEQQBAQsdBzIUCQgBAQQBEgiHdQjCbBeOSzgGgx6BFAEDiQ+QRZBmgy2CKg X-IronPort-AV: E=Sophos;i="4.95,700,1384300800"; d="scan'208";a="298957060" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 22 Jan 2014 16:20:32 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0MGKWWN022272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jan 2014 16:20:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 22 Jan 2014 10:20:32 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , "pcp@ietf.org" Thread-Topic: [pcp] WG Call for Adoption: Updates to the PCP Specification Thread-Index: Ac8XJQEJb7SUzGa4T/+pceJp6RZsfwAipuCAAAh6vgA= Date: Wed, 22 Jan 2014 16:20:31 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2428F2AF@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A2428EBAF@xmb-rcd-x10.cisco.com> <52DFD40B.2010505@viagenie.ca> In-Reply-To: <52DFD40B.2010505@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.69.42] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] WG Call for Adoption: Updates to the PCP Specification X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 16:20:34 -0000 > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Wednesday, January 22, 2014 7:52 PM > To: Tirumaleswar Reddy (tireddy); pcp@ietf.org > Subject: Re: [pcp] WG Call for Adoption: Updates to the PCP Specification >=20 > Le 2014-01-21 22:49, Tirumaleswar Reddy (tireddy) a =E9crit : > >> Both are correct, but IMHO both are also out of scope. > > > > Any specific reason why PCP auth is out of scope ? >=20 > Well, I suppose we could prefix section 3 with something like "if you use= PCP > auth then all the problems we're fixing in this section disappear". Yup, the above line in section 3 will look good. Thanks, -Tiru. >=20 > That's what I mean by out of scope: if you use PCP auth, then you don't > experience the problem we're trying to fix. >=20 > 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 internet-drafts@ietf.org Thu Jan 23 01:08:37 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21961A0341; Thu, 23 Jan 2014 01:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2diUNdVXQE1; Thu, 23 Jan 2014 01:08:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9DE1A0282; Thu, 23 Jan 2014 01:08:36 -0800 (PST) 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.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140123090836.22277.17014.idtracker@ietfa.amsl.com> Date: Thu, 23 Jan 2014 01:08:36 -0800 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-description-option-03.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 09:08:38 -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 : PCP Description Option Authors : Mohamed Boucadair Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-description-option-03.txt Pages : 6 Date : 2014-01-23 Abstract: This document extends Port Control Protocol (PCP) with the ability to associate a description with a PCP-instantiated mapping. It does so by defining a new DESCRIPTION option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-description-option/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-description-option-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-description-option-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From B.McCann@f5.com Tue Jan 28 12:55:09 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521E61A033C for ; Tue, 28 Jan 2014 12:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.435 X-Spam-Level: X-Spam-Status: No, score=-7.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4JjqLhYhR_i for ; Tue, 28 Jan 2014 12:55:06 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF6F1A026C for ; Tue, 28 Jan 2014 12:55:06 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,738,1384300800"; d="scan'208,217";a="99530909" X-IPAS-Result: AtEEAMkY6FLAqArr/2dsb2JhbABQCoJIfFa1R4hTdIIsLV4BFStAJgEEGxME0XMXjiODEg+BegSfGI5cgio Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 28 Jan 2014 20:54:47 +0000 Received: from LWLEXCHMBX01.olympus.F5Net.com (192.168.96.165) by seaecas02.olympus.F5Net.com (192.168.16.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 12:54:47 -0800 Received: from LWLEXCHMBX01.olympus.F5Net.com (192.168.96.165) by LWLEXCHMBX01.olympus.F5Net.com (192.168.96.165) with Microsoft SMTP Server (TLS) id 15.0.775.38; Tue, 28 Jan 2014 15:54:39 -0500 Received: from LWLEXCHMBX01.olympus.F5Net.com ([fe80::4568:8ee5:b320:f164]) by LWLEXCHMBX01.olympus.F5Net.com ([fe80::4568:8ee5:b320:f164%20]) with mapi id 15.00.0775.031; Tue, 28 Jan 2014 15:54:39 -0500 From: Ben McCann To: "pcp@ietf.org" Thread-Topic: Draft-wing-pcp-flowdata-000 Comments Thread-Index: Ac8cQFOrOh/pJlxNTzy/FEwmlT1QOA== Date: Tue, 28 Jan 2014 20:54:39 +0000 Message-ID: <76c0291b15c042de82b06fa139e2773f@LWLEXCHMBX01.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.96.220] Content-Type: multipart/alternative; boundary="_000_76c0291b15c042de82b06fa139e2773fLWLEXCHMBX01olympusF5Ne_" MIME-Version: 1.0 Subject: [pcp] Draft-wing-pcp-flowdata-000 Comments X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 20:55:09 -0000 --_000_76c0291b15c042de82b06fa139e2773fLWLEXCHMBX01olympusF5Ne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan, Reinaldo, and Tiru, I have a few comments and questions on your PCP flowdata draft. Overall, it= looks good. To summarize, this PCP enhancement enables an application attached to an ac= cess network to signal its resource (bandwidth, etc) requirements to the ne= twork via a PCP server. The PCP server reserves none, some, or all of the r= equested resources and returns a response describing that reservation. * Section 1: Recursively forwarding PCP FlowData requests hop-by-ho= p through the access network is an elegant solution for reserving resources= from the application to the boundary between the access network and the In= ternet. That said, does this introduce scaling problems? o Are there administrative scaling challenges for large access networks w= ith many switches and routers? Do most of them have to be configured with P= CP servers for the reservation system to be effective? o Can upstream PCP servers handle all of the individual reservation reque= sts arriving from multiple downstream PCP servers? Is some kind of reservat= ion aggregation mechanism required to scale to 1000's or 10000s of reservat= ions? * Section 3.2 & Figure 3: Does the FlowData option in a MAP request= define the aggregate resource requirements for all matching inbound flows = going to the application sending that MAP request or is the reservation per= flow? Both options have issues: o If the reservation is for all flows, then the resource manager can easi= ly reserve resources (bandwidth, etc) in aggregate for that application. Th= at simplifies resource allocation but it is extremely inefficient because r= esources are pre-allocated for flows that may never arrive. o If the reservation is per flow, then how does the resource manager know= how many resources to reserve? If the MAP request FlowData option only des= cribes the resource requirements for one flow, then how does the resource r= eservation system know how many flows to expect? IMHO, both of these options are broken. Instead, the FlowData option should= : o Describe the resource requirements per flow. The CGNAT/Firewall/Etc mus= t reserve resources incrementally as clients connect to the mapped server. = This provides some level of fairness across multiple servers using the MAP = request. o Define the maximum number of flows that are expected. The PCP server ma= y return a smaller number in the MAP reply if this is excessive. The CGNAT = may reject inbound connections that exceed this upper bound to ensure it ha= s resources for other mapped servers. o Define the behavior of the connection when resources (as defined in the= MAP request) are unavailable. Should the CGNAT fall back to "best effort",= drop the SYN packet and let the client retry, send back something in ICMP,= or should it reject the connection request with a RST? (Examples are admit= tedly TCP-centric). In summary, FlowData should describe resources per flow, how many flows are= expected, and how to handle new inbound flows when resources are unavailab= le. Note that the CGNAT/Firewall handles resource reservation errors autonomous= ly because, IMHO, sending PCP packets back to the client when resources are= low introduces unacceptable DoS attack vectors. * Section 6: Why do we need a separate authorization mechanism for = FlowData? The client's identify is verified during PCP Authentication so wh= y doesn't the PCP server consult a policy server at that time to determine = the client's resource reservation privileges? We don't need a separate cryp= to-token for FlowData because the whole PCP request is signed by the PCP Au= thentication Tag. We should also avoid authorizing individual FlowData requ= ests to an external server because it won't scale. * (Other) Should the FlowData option define enforcement policies fo= r non-conformant flows that exceed their bandwidth reservation? For example= , best effort, some flavor of random early discard, rate shaping, etc, etc.= ..? The alternative is that the reservation enforcement policy is staticall= y defined per hop and that it is unaware of the best protocol-dependent met= hod to enforce bandwidth reservations. Ben McCann, F5 Networks --_000_76c0291b15c042de82b06fa139e2773fLWLEXCHMBX01olympusF5Ne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dan, Reinaldo, and Tiru,

 

I have a few comments and questions on your PCP flow= data draft. Overall, it looks good.

 

To summarize, this PCP enhancement enables an applic= ation attached to an access network to signal its resource (bandwidth, etc)= requirements to the network via a PCP server. The PCP server reserves none= , some, or all of the requested resources and returns a response describing that reservation.

 

·         Section 1: Recursively forwarding PCP= FlowData requests hop-by-hop through the access network is an elegant solu= tion for reserving resources from the application to the boundary between t= he access network and the Internet. That said,  does this introduce scaling problems?

o   Are there administrative scaling challenges = for large access networks with many switches and routers? Do most of them h= ave to be configured with PCP servers for the reservation system to be effe= ctive?

o   Can upstream PCP servers handle all of the i= ndividual reservation requests arriving from multiple downstream PCP server= s? Is some kind of reservation aggregation mechanism required to scale to 1= 000’s or 10000s of reservations?

 

·         Section 3.2 & Figure 3: Does the = FlowData option in a MAP request define the aggregate resource requirements for all matching inbound flows going to the application sending that MAP request or is the reservation per flow? Both options have issues:

o   If the reservation is for all flows, = then the resource manager can easily reserve resources (bandwidth, etc) in = aggregate for that application. That simplifies resource allocation but it = is extremely inefficient because resources are pre-allocated for flows that may never arrive.

o   If the reservation is per flow, then = how does the resource manager know how many resources to reserve? If the MA= P request FlowData option only describes the resource requirements for one flow, then how does the resource reservation system know how man= y flows to expect?

 

IMHO, both of these optio= ns are broken. Instead, the FlowData option should:

o   Describe the resource requirements per fl= ow. The CGNAT/Firewall/Etc must reserve resources incrementally as clients connect to the mapped server. This provides= some level of fairness across multiple servers using the MAP request.=

o   Define the maximum number of flows that are = expected. The PCP server may return a smaller number in the MAP reply if th= is is excessive. The CGNAT may reject inbound connections that exceed this = upper bound to ensure it has resources for other mapped servers.

o   Define the behavior of the connection when r= esources (as defined in the MAP request) are unavailable. Should the CGNAT = fall back to “best effort”, drop the SYN packet and let the cli= ent retry, send back something in ICMP, or should it reject the connection request with a RST? (Examples are admittedly TCP-= centric).

 

In summary, FlowData shou= ld describe resources per flow, how many flows are expected, and how to han= dle new inbound flows when resources are unavailable.

 

Note that the CGNAT/Firew= all handles resource reservation errors autonomously because, IMHO, sending= PCP packets back to the client when resources are low introduces unaccepta= ble DoS attack vectors.

 

·         Section 6: Why do we need a separate = authorization mechanism for FlowData? The client’s identify is verifi= ed during PCP Authentication so why doesn’t the PCP server consult a = policy server at that time to determine the client’s resource reservation privileges? We don’t need a sepa= rate crypto-token for FlowData because the whole PCP request is signed by t= he PCP Authentication Tag. We should also avoid authorizing individual Flow= Data requests to an external server because it won’t scale.

 

·         (Other) Should the FlowData option de= fine enforcement policies for non-conformant flows that exceed their bandwi= dth reservation? For example, best effort, some flavor of random early disc= ard, rate shaping, etc, etc…? The alternative is that the reservation enforcement policy is statically defin= ed per hop and that it is unaware of the best protocol-dependent method to = enforce bandwidth reservations.

 

 

Ben McCann,

F5 Networks

--_000_76c0291b15c042de82b06fa139e2773fLWLEXCHMBX01olympusF5Ne_-- From ancaz@cisco.com Wed Jan 29 03:25:59 2014 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093A01A01ED for ; Wed, 29 Jan 2014 03:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXosri0bSPOB for ; Wed, 29 Jan 2014 03:25:56 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B614A1A014C for ; Wed, 29 Jan 2014 03:25:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5738; q=dns/txt; s=iport; t=1390994754; x=1392204354; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=PzEOylOzruYairqkOSpyDIsSkU0255mX7nbU0XofPjY=; b=Nus5ASwpbRT0mOzMFKvi6YNsSail0WDGx+0ETkMBy2RTIIOC6V/xBTmQ r/vT6S0UCv4btIgi5OX95covFZkeRI91WezFTgQV1AfJDAv4ndJ9CH4n9 CN3n3nPUA6OisGkpBRgJBkNIgcQjqTdbUz0I0ovhxXAcv89uLYLorIipi 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAP/k6FKtJV2c/2dsb2JhbABPCoJIRDhKDLx+gQYWdIIseRIBDDc9JQIEAQ0Oh3wNyUgXjiNcB4Q4BJgokh+Bb4E+gio X-IronPort-AV: E=Sophos;i="4.95,741,1384300800"; d="scan'208,217";a="300456585" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 29 Jan 2014 11:25:42 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0TBPgLF031829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 29 Jan 2014 11:25:42 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.104]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Wed, 29 Jan 2014 05:25:40 -0600 From: "Anca Zamfir (ancaz)" To: "Tirumaleswar Reddy (tireddy)" , "Reinaldo Penno (repenno)" , "Dan Wing (dwing)" , "Prashanth Patil (praspati)" Thread-Topic: [pcp] Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) Thread-Index: AQHPCKSZkUiuNHzC/E6jbju6rMAZpJqcLcIA Date: Wed, 29 Jan 2014 11:25:40 +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.2.3.120616 x-originating-ip: [10.61.103.14] Content-Type: multipart/alternative; boundary="_000_CF0E90478E577ancazciscocom_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: [pcp] Comments on PCP Extension for Third Party Authorization (http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-01.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 11:25:59 -0000 --_000_CF0E90478E577ancazciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Tiru et al, A few comments and questions on this draft. Section 4: * Figure 1: could you identify the entities you mention in the text bel= ow it? Like PCP Client (Alice box), Oauth 2.0 server (does it have to be th= e WebRTC or could it be separate?) * I don't understand the paragraph after bullet 4 and how is relevant t= o this section/ draft? What do you mean by "This technique"? Section 5: * Figure 3: Show a bidirectional Request/ Response on (1). Show a (5) a= rrow with PCP Response so the loop is closed. * Same question as above. Does the Auth Server has to be the WebRTC Ser= ver (or app server in general)? Or is this figure just a possible scenario? * Create section 5.1 for the option detail and say something like "This= specification defines the new PCP ACCESS_TOKEN Option=85" * Option Length: Is this like any PCP option (i.e. length of Option Dat= a, must be multiple of 4, etc). Maybe just refer to RFC6887 Section 7.3 * "Reserved1": set to 0 by sender and ignored by the receiver? * Lifetime: Why does the PCP Client need to tell the PCP Server about t= he lifetime? Is this the expires_in value that the PCP Client got from the = Auth Server? Can this be "extended" later in a PCP Request by the PCP Clien= t/ Alice or Mallory? And what would happen? I thought the PCP Server must = ensure that the token has not expired by interacting with the authorization= server (e.g. on arrow (4) in your Figure 3, the Auth server would also inc= lude the lifetime). I don't understand why it's needed in the PCP Option. * Timestamp : This assumes some sort of synchronization, right? Then I = don't understand how the Timestamp on its own can prevent replay attacks. M= aybe you can elaborate on this a bit? * May appear in: response...I don't see any explanation on when PCP Ser= ver would include it in response and what is the PCP Client supposed to do/= check. Maybe you can say a few words about this in Sections 5.2 and 5.3 * Probably out of scope but what happens on mapping refresh, PCP server= restart, etc? Will PCP Client get new token, reuse the old one, etc? Maybe= give some hints on good practices? Section 6: * PCP Proxy question: What are the possible actions here wrt to the TOK= EN option? Just forward or drop (e.g. if unknown and configured to drop unk= nowns)? thanks, -anca --_000_CF0E90478E577ancazciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <38DE5F1B7702CE44AA89AA5C0BA2FDB2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Tiru et al,
A few comments and questions on this draft. 

Section 4:
  • Figure 1: could you identify the entities you mention in the text below= it? Like PCP Client (Alice box), Oauth 2.0 server (does it have to be the = WebRTC or could it be separate?)
  • I don't understand the paragraph a= fter bullet 4 and how is relevant to this section/ draft? What do you mean = by "This technique"?
Section 5:
  • Figure 3: Show a bidirectional Request/ Response on (1). Show a (5) arr= ow with PCP Response so the loop is closed.
  • Same question as above.= Does the Auth Server has to be the WebRTC Server (or app server in general= )? Or is this figure just a possible scenario?
  • Create section 5.1 f= or the option detail and say something like "This specification define= s the new PCP ACCESS_TOKEN Option=85"
  • Option Length: Is this l= ike any PCP option (i.e. length of Option Data, must be multiple of 4, etc)= . Maybe just refer to RFC6887 Section 7.3
  • "Reserved1": se= t to 0 by sender and ignored by the receiver?
  • Lifetime: Why does th= e PCP Client need to tell the PCP Server about the lifetime? Is this the ex= pires_in value that the PCP Client got from the Auth Server? Can this be &q= uot;extended" later in a PCP Request by the PCP Client/ Alice or Mallo= ry? And what would happen? I thought the PCP Server  must ensure that the token has not = expired by interacting with the authorization server (e.g. on arrow (4) in = your Figure 3, the Auth server would also include the lifetime). I don't un= derstand why it's needed in the PCP Option.
  • Timestamp : This assume= s some sort of synchronization, right? Then I don't understand how the Time= stamp on its own can prevent replay attacks. Maybe you can elaborate on thi= s a bit?
  • May appear in: response...I don't see any explanation on w= hen PCP Server would include it in response and what is the PCP Client supp= osed to do/ check. Maybe you can say a few words about this in Sections 5.2= and 5.3 
  • Probably out of scope but what happens on mapping re= fresh, PCP server restart, etc? Will PCP Client get new token, reuse the ol= d one, etc? Maybe give some hints on good practices?
Section 6:
  • PCP Proxy question: What are the possible actions here wrt to the TOKEN= option? Just forward or drop (e.g. if unknown and configured to drop unkno= wns)? 
thanks,
-anca
--_000_CF0E90478E577ancazciscocom_--