From eckert@cisco.com Thu Aug 1 04:46:29 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C24A21F992B for ; Thu, 1 Aug 2013 04:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yggba3WMHanZ for ; Thu, 1 Aug 2013 04:46:24 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D4B3721E809A for ; Thu, 1 Aug 2013 04:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=70; q=dns/txt; s=iport; t=1375357566; x=1376567166; h=date:from:to:subject:message-id:mime-version; bh=0aVUes2yicddPl7pjN9AuYOgNVxlckiuI4sCbaqMojA=; b=mGxvHGsoAOtK+C1/hQSe3nkpoZkJuNLwjecQ/gvGB1d/zaAjTlsyrOKf 6SqVmAWqKAXSs7slIZZ53SxTvREkbUNKRCaOxEi6lKsCuDnUJbJlos1Rr 1/cjdVJt2bZ6Gaa2lFLnHeSqVTD1ajDpzGfXen0oZ9cn1v1S63r/26Lo1 Q=; X-IronPort-AV: E=Sophos;i="4.89,793,1367971200"; d="scan'208";a="88170067" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 01 Aug 2013 11:46:04 +0000 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r71Bk3JC011148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Aug 2013 11:46:03 GMT Received: from irp-view13.cisco.com (localhost [127.0.0.1]) by irp-view13.cisco.com (8.14.4+Sun/8.13.8) with ESMTP id r71Bk3FV007117; Thu, 1 Aug 2013 04:46:03 -0700 (PDT) Received: (from eckert@localhost) by irp-view13.cisco.com (8.14.4+Sun/8.14.4/Submit) id r71Bk341007116; Thu, 1 Aug 2013 04:46:03 -0700 (PDT) Date: Thu, 1 Aug 2013 04:46:03 -0700 From: Toerless Eckert To: pcp@ietf.org, repenno@cisco.com Message-ID: <20130801044603.A4366@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [pcp] Reinaldos implementations status preso et.al ? X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 11:46:29 -0000 Where can i find subject presentation PDF ? Thanks Toerless From eckelcu@cisco.com Thu Aug 1 07:39:58 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A510821F9E31 for ; Thu, 1 Aug 2013 07:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4R-4vQ3JP5Sn for ; Thu, 1 Aug 2013 07:39:53 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC2021E824A for ; Thu, 1 Aug 2013 07:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=587; q=dns/txt; s=iport; t=1375367991; x=1376577591; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=EsOcDYztmZbO3L453vWe6cLpDR4RxM336FG67coMbP4=; b=U8wU5MYA47OoUz2LIgiCDFOrRDIDWseyGles2zrNCe1WC8wUrGQM8MZc MReLBzjthstHMljZSptGbbEgukrl1ajGzEHceapLIIunF4vouykcGfh2i CkRmlyfCu2BfvfoV3tsZu0HWteMCJOaJXHpViIBMaMPXO0d7f1PmZYDrs 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4FACFy+lGtJXG8/2dsb2JhbABbgwY1UIJJu32BHBZ0giQBAQEEAQEBNzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCIgIDLlkj1Y4BoMTcwOZCZAkgxSCKg X-IronPort-AV: E=Sophos;i="4.89,795,1367971200"; d="scan'208";a="242311545" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 01 Aug 2013 14:39:47 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r71EdkoG000761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 1 Aug 2013 14:39:46 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.214]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Thu, 1 Aug 2013 09:39:46 -0500 From: "Charles Eckel (eckelcu)" To: "Toerless Eckert (eckert)" , "pcp@ietf.org" , "Reinaldo Penno (repenno)" Thread-Topic: [pcp] Reinaldos implementations status preso et.al ? Thread-Index: AQHOjqzHWwt1exAoW0u3TfBhNBGpXpmAbFgw Date: Thu, 1 Aug 2013 14:39:45 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280490B51C@xmb-aln-x08.cisco.com> References: <20130801044603.A4366@cisco.com> In-Reply-To: <20130801044603.A4366@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.115.113] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Reinaldos implementations status preso et.al ? X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 14:39:58 -0000 http://tools.ietf.org/wg/pcp/agenda?item=3Dagenda-87-pcp.html Cheers, Charles > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Toerless Eckert (eckert) > Sent: Thursday, August 01, 2013 1:46 PM > To: pcp@ietf.org; Reinaldo Penno (repenno) > Subject: [pcp] Reinaldos implementations status preso et.al ? >=20 > Where can i find subject presentation PDF ? >=20 > Thanks > Toerless > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From dthaler@microsoft.com Thu Aug 1 07:46:17 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEA711E813F for ; Thu, 1 Aug 2013 07:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.634 X-Spam-Level: X-Spam-Status: No, score=-101.634 tagged_above=-999 required=5 tests=[AWL=1.233, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kb0a2hqlJuc1 for ; Thu, 1 Aug 2013 07:46:12 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id CD4D911E8183 for ; Thu, 1 Aug 2013 07:46:09 -0700 (PDT) Received: from mail135-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.22; Thu, 1 Aug 2013 14:46:08 +0000 Received: from mail135-tx2 (localhost [127.0.0.1]) by mail135-tx2-R.bigfish.com (Postfix) with ESMTP id B4E182600E2 for ; Thu, 1 Aug 2013 14:46:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -19 X-BigFish: VS-19(zz9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275bh8275dh1de097hz2fh2a8h683h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh17ej9a9j1155h) Received-SPF: pass (mail135-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail135-tx2 (localhost.localdomain [127.0.0.1]) by mail135-tx2 (MessageSwitch) id 1375368367144576_9050; Thu, 1 Aug 2013 14:46:07 +0000 (UTC) Received: from TX2EHSMHS043.bigfish.com (unknown [10.9.14.231]) by mail135-tx2.bigfish.com (Postfix) with ESMTP id 1DFF44E0046 for ; Thu, 1 Aug 2013 14:46:07 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS043.bigfish.com (10.9.99.143) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 1 Aug 2013 14:46:06 +0000 Received: from co1outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.3.136.1; Thu, 1 Aug 2013 14:45:48 +0000 Received: from mail47-co1-R.bigfish.com (10.243.78.230) by CO1EHSOBE006.bigfish.com (10.243.66.69) with Microsoft SMTP Server id 14.1.225.22; Thu, 1 Aug 2013 14:45:00 +0000 Received: from mail47-co1 (localhost [127.0.0.1]) by mail47-co1-R.bigfish.com (Postfix) with ESMTP id 860154801D2 for ; Thu, 1 Aug 2013 14:45:00 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(13464003)(377454003)(51704005)(81342001)(33646001)(46102001)(4396001)(83072001)(77982001)(76576001)(56816003)(76786001)(77096001)(74316001)(83322001)(74876001)(19580395003)(19580385001)(51856001)(16406001)(76796001)(74366001)(59766001)(19580405001)(74502001)(47446002)(49866001)(80022001)(56776001)(53806001)(47976001)(74706001)(74662001)(76482001)(63696002)(81542001)(79102001)(31966008)(47736001)(54316002)(54356001)(80976001)(65816001)(69226001)(50986001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB271; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:df8:0:64:3d9e:af0e:20ed:e6c2; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail47-co1 (localhost.localdomain [127.0.0.1]) by mail47-co1 (MessageSwitch) id 1375368298914144_10439; Thu, 1 Aug 2013 14:44:58 +0000 (UTC) Received: from CO1EHSMHS030.bigfish.com (unknown [10.243.78.232]) by mail47-co1.bigfish.com (Postfix) with ESMTP id D264040049; Thu, 1 Aug 2013 14:44:58 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by CO1EHSMHS030.bigfish.com (10.243.66.40) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 1 Aug 2013 14:44:58 +0000 Received: from BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) by BL2PRD0310HT004.namprd03.prod.outlook.com (10.255.97.39) with Microsoft SMTP Server (TLS) id 14.16.341.1; Thu, 1 Aug 2013 14:44:56 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) with Microsoft SMTP Server (TLS) id 15.0.731.11; Thu, 1 Aug 2013 14:44:54 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.171]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.234]) with mapi id 15.00.0731.000; Thu, 1 Aug 2013 14:44:53 +0000 From: Dave Thaler To: Toerless Eckert , "pcp@ietf.org" , "repenno@cisco.com" Thread-Topic: [pcp] Reinaldos implementations status preso et.al ? Thread-Index: AQHOjqz8NypUuh4lBk2t6qUADnYQypmAbbVQ Date: Thu, 1 Aug 2013 14:44:52 +0000 Message-ID: <93ad23cc7ffb4cc5beedc9c289ef9fab@BY2PR03MB269.namprd03.prod.outlook.com> References: <20130801044603.A4366@cisco.com> In-Reply-To: <20130801044603.A4366@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:df8:0:64:3d9e:af0e:20ed:e6c2] x-forefront-prvs: 0925081676 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB271.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CISCO.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [pcp] Reinaldos implementations status preso et.al ? X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 14:46:18 -0000 They're in the meeting materials... https://datatracker.ietf.org/meeting/87/materials.html See PCP Implementation Report - Transmission Bittorrent Client PCP Implementation Report - MiniUPnP Server > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Toerless Eckert > Sent: Thursday, August 1, 2013 1:46 PM > To: pcp@ietf.org; repenno@cisco.com > Subject: [pcp] Reinaldos implementations status preso et.al ? >=20 > Where can i find subject presentation PDF ? >=20 > Thanks > Toerless > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp >=20 >=20 From phdgang@gmail.com Fri Aug 2 13:35:15 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5518221E80CB for ; Fri, 2 Aug 2013 13:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FgWzxBANPU9 for ; Fri, 2 Aug 2013 13:35:13 -0700 (PDT) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 080A021E80C8 for ; Fri, 2 Aug 2013 13:35:12 -0700 (PDT) Received: by mail-ea0-f171.google.com with SMTP id n15so539478ead.30 for ; Fri, 02 Aug 2013 13:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=QWDzBrkOW7DFbtv3ZDtUyf+225WkK84pBH3vD1ycyP0=; b=mBYjCq7SWU4BkqWkIcDboxmMfyPtEtvPMMnBwYdVt2rBqjtdRTr0tDPQ2I2ySvd86k Om7KULXzKYN+KH/ytqfUh/Kk2w5FSiMkB44FBREt4MZ8mTe+AkVcncuL4yCrCtxE4ZIT K02zJz7wwg/0O/BhmTBbA+fKNGZLM/zGOvjIzfyfxGLvj5gZ6M4wHMEts19Vj4GMgJIt OnddlVXdmf+ptnqp2gYkWgJwqUKQwngIV3/iLrh+8jYO56tpVQ7qlsWBhW0xaXV50ml9 MJvBRcwRQpTOalsB8/f01gJmmSpzQXirSMNcu7rP7K866NL1BZwtp0yWPZqEODm/N9ha 37mg== X-Received: by 10.14.106.195 with SMTP id m43mr7154854eeg.60.1375475711992; Fri, 02 Aug 2013 13:35:11 -0700 (PDT) Received: from [10.0.3.62] ([89.246.150.136]) by mx.google.com with ESMTPSA id x3sm14188099eeu.1.2013.08.02.13.35.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 Aug 2013 13:35:10 -0700 (PDT) References: <45A697A8FFD7CF48BCF2BE7E106F0604090E81CE@xmb-rcd-x04.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090E81CE@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <70891127-BCBB-4401-8CC2-1B58A0529A88@gmail.com> X-Mailer: iPhone Mail (10B329) From: Gang Chen Date: Fri, 2 Aug 2013 22:35:07 +0200 To: "Reinaldo Penno (repenno)" Cc: "pcp@ietf.org" Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 20:35:15 -0000 I believe that is the right direction we should work. I support the adoption. Best regards Gang On 2013-7-29, at 12:22, "Reinaldo Penno (repenno)" wrote: > Hello, > > This email starts a 2-week consensus call on adopting "Optimizing NAT and > Firewall Keepalives Using Port Control Protocol (PCP)" as a WG item. > > Title : Optimizing NAT and Firewall Keepalives Using Port Control > Protocol (PCP) > Author(s) : T. Reddy et al > Filename : draft-reddy-pcp-optimize-keepalives-01 > URL : > http://tools.ietf.org/html/draft-reddy-pcp-optimize-keepalives-01 > > Please read the current revision and state you opinion either for or > against adoption in the mailing list. > > The call for adoption ends 12th August 2013. > > Thanks, > > Chairs > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Sun Aug 4 23:41:32 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344BA21F9E88 for ; Sun, 4 Aug 2013 23:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWhffmj8onuD for ; Sun, 4 Aug 2013 23:41:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id A152811E8136 for ; Sun, 4 Aug 2013 23:41:27 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 91860325254; Mon, 5 Aug 2013 08:41:26 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 7604335C083; Mon, 5 Aug 2013 08:41:26 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Mon, 5 Aug 2013 08:41:26 +0200 From: To: "Reinaldo Penno (repenno)" , "pcp@ietf.org" Date: Mon, 5 Aug 2013 08:41:22 +0200 Thread-Topic: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) Thread-Index: AQHOjEWHMNpikDyP/E6vAANE1noeMpmGMwnQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EE99C8E34@PUEXCB1B.nanterre.francetelecom.fr> References: <45A697A8FFD7CF48BCF2BE7E106F06040905138F@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F0604090E81CE@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090E81CE@xmb-rcd-x04.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.5.50640 Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 06:41:32 -0000 Hi all, I support this work.=20 I have one comment for the authors: consider adding some text to highlight = PCP benefits to reduce keepalive messages when deployed in managed networks= (i.e., both the underlying network and the service are managed by the same= administrative entity). A typical example is SIP-based deployments: optimi= ze the load on access service nodes (SBC, SBE, P-CSCF, etc.) because the li= fetime of the mapping is known to the SIP UA and as such there is no need t= o issue frequent register messages to maintain the mapping alive, etc.=20 Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >Reinaldo Penno (repenno) >Envoy=E9=A0: lundi 29 juillet 2013 12:22 >=C0=A0: pcp@ietf.org >Objet=A0: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepaliv= es >Using Port Control Protocol (PCP) > >Hello, > >This email starts a 2-week consensus call on adopting "Optimizing NAT and >Firewall Keepalives Using Port Control Protocol (PCP)" as a WG item. > > Title : Optimizing NAT and Firewall Keepalives Using Port Control >Protocol (PCP) > Author(s) : T. Reddy et al > Filename : draft-reddy-pcp-optimize-keepalives-01 > URL : >http://tools.ietf.org/html/draft-reddy-pcp-optimize-keepalives-01 > >Please read the current revision and state you opinion either for or >against adoption in the mailing list. > >The call for adoption ends 12th August 2013. > >Thanks, > >Chairs > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From dthaler@microsoft.com Mon Aug 5 16:59:24 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DAF21F9D7E for ; Mon, 5 Aug 2013 16:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.467 X-Spam-Level: X-Spam-Status: No, score=-98.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QenprET2MasI for ; Mon, 5 Aug 2013 16:59:18 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 18B9021F9D7A for ; Mon, 5 Aug 2013 16:59:17 -0700 (PDT) Received: from mail17-am1-R.bigfish.com (10.3.201.225) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.22; Mon, 5 Aug 2013 23:59:16 +0000 Received: from mail17-am1 (localhost [127.0.0.1]) by mail17-am1-R.bigfish.com (Postfix) with ESMTP id C976B4A0204 for ; Mon, 5 Aug 2013 23:59:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -30 X-BigFish: VS-30(zz9371I936eI542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah186M1de096h5eeeK8275bh8275dh1de097hz2fh2a8h683h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail17-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail17-am1 (localhost.localdomain [127.0.0.1]) by mail17-am1 (MessageSwitch) id 1375747154917692_8068; Mon, 5 Aug 2013 23:59:14 +0000 (UTC) Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.245]) by mail17-am1.bigfish.com (Postfix) with ESMTP id DB3DF4E0048 for ; Mon, 5 Aug 2013 23:59:14 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 5 Aug 2013 23:59:14 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.3.136.1; Mon, 5 Aug 2013 23:59:05 +0000 Received: from mail218-ch1-R.bigfish.com (10.43.68.243) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.22; Mon, 5 Aug 2013 23:57:30 +0000 Received: from mail218-ch1 (localhost [127.0.0.1]) by mail218-ch1-R.bigfish.com (Postfix) with ESMTP id 15029601DA for ; Mon, 5 Aug 2013 23:57:30 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377424004)(13464003)(377454003)(199002)(189002)(51704005)(243025003)(19580405001)(19580385001)(19580395003)(77982001)(83072001)(83322001)(53806001)(74502001)(46102001)(47976001)(33646001)(76796001)(79102001)(49866001)(66066001)(63696002)(80976001)(65816001)(74316001)(81542001)(81342001)(59766001)(74366001)(80022001)(76176001)(76786001)(74876001)(50986001)(74706001)(74662001)(51856001)(69226001)(76576001)(56776001)(47736001)(16406001)(56816003)(47446002)(31966008)(54356001)(4396001)(76482001)(15202345003)(77096001)(54316002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR03MB268; H:BN1PR03MB267.namprd03.prod.outlook.com; CLIP:50.135.4.20; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail218-ch1 (localhost.localdomain [127.0.0.1]) by mail218-ch1 (MessageSwitch) id 1375747047666181_27166; Mon, 5 Aug 2013 23:57:27 +0000 (UTC) Received: from CH1EHSMHS004.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.240]) by mail218-ch1.bigfish.com (Postfix) with ESMTP id 9534F3E020B; Mon, 5 Aug 2013 23:57:27 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS004.bigfish.com (10.43.70.4) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 5 Aug 2013 23:57:27 +0000 Received: from BN1PR03MB268.namprd03.prod.outlook.com (10.255.200.20) by BL2PRD0310HT004.namprd03.prod.outlook.com (10.255.97.39) with Microsoft SMTP Server (TLS) id 14.16.341.1; Mon, 5 Aug 2013 23:57:27 +0000 Received: from BN1PR03MB267.namprd03.prod.outlook.com (10.255.200.17) by BN1PR03MB268.namprd03.prod.outlook.com (10.255.200.20) with Microsoft SMTP Server (TLS) id 15.0.731.11; Mon, 5 Aug 2013 23:57:25 +0000 Received: from BN1PR03MB267.namprd03.prod.outlook.com ([169.254.15.165]) by BN1PR03MB267.namprd03.prod.outlook.com ([169.254.15.151]) with mapi id 15.00.0731.000; Mon, 5 Aug 2013 23:57:25 +0000 From: Dave Thaler To: "pcp@ietf.org" , "draft-ietf-pcp-server-selection@tools.ietf.org" Thread-Topic: Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6SN4UBylvrgKNiQjOEzEfANBzc7A== Date: Mon, 5 Aug 2013 23:57:24 +0000 Message-ID: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.135.4.20] x-forefront-prvs: 0929F1BAED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BN1PR03MB268.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 23:59:24 -0000 Comments on draft-ietf-pcp-server-selection-01 below. Main technical comments: 1) Needs to remove mention of names and just use addresses. The DHCP option is being changed per WG discussion. But even before the DHCP option, we had the default router list (see RFC 6887 section 8.1) which is a list of IP's with no name known. 2) Document assumes that "PCP requests to different servers are independent, the result of a PCP request to one server does not influence another" We currently have no WG consensus on this. Some (e.g., Stuart) have argued that it's the responsibility of the server to interact with other=20 redundant servers managed by the same entity. Since no one has given any counter argument, that should be the starting point. 3) There needs to be a step where the selection algorithm takes a source=20 address into account, if the app specified one. Consider the case of sendi= ng a PEER after establishing a TCP connection. The source address of the TCP= =20 connection should constrain the PCP server selection mechanism so you=20 don't try sending PEER messages on some other network than the one the TCP connection is on. 4) The server selection is still missing a lot of details on how an address= is selected. E.g.: * Is it assumed that the addresses of the same server are already ordered by the configuration mechanism? (I think there's no need for such assu= mption) * Should RFC 6724 sorting be done on them by the client? (I think so) * If you're trying to use PCP on an IPv4 mapping should you prefer IPv4 or= not=20 for PCP server addresses? * Should a client do RFC 6724 to choose among servers, if point 2 is addre= ssed by just using one?=20 And for each of the above: Why or why not? Full comments (including editorial ones) in context can be found at http://research.microsoft.com/~dthaler/draft-ietf-pcp-server-selection-01.p= df (a .docx is also available at the same location, just change .pdf to .docx) -Dave > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Wednesday, May 22, 2013 4:47 AM > To: i-d-announce@ietf.org > Cc: pcp@ietf.org > Subject: [pcp] I-D Action: draft-ietf-pcp-server-selection-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Port Control Protocol Working Group of = the > IETF. >=20 > Title : PCP Server Selection > Author(s) : Mohamed Boucadair > Reinaldo Penno > Dan Wing > Prashanth Patil > Tirumaleswar Reddy > Filename : draft-ietf-pcp-server-selection-01.txt > Pages : 10 > Date : 2013-05-22 >=20 > Abstract: > This document specifies the behavior to be followed by the PCP client > to contact its PCP server(s) when one or several PCP server names are > configured. Multiple names may be configured to a PCP client in some > deployment contexts such as multi-homing. >=20 > This document updates RFC6887. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pcp-server-selection >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-pcp-server-selection-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-server-selection-01 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Mon Aug 5 23:16:50 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E391921E8082 for ; Mon, 5 Aug 2013 23:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCWB9yfA0Xg8 for ; Mon, 5 Aug 2013 23:16:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9576521E8063 for ; Mon, 5 Aug 2013 23:16:46 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 5214F22C7F5; Tue, 6 Aug 2013 08:16:45 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 948F027C0FF; Tue, 6 Aug 2013 08:16:41 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Tue, 6 Aug 2013 08:16:41 +0200 From: To: Dave Thaler , "pcp@ietf.org" , "draft-ietf-pcp-server-selection@tools.ietf.org" Date: Tue, 6 Aug 2013 08:16:38 +0200 Thread-Topic: Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6SN4UBylvrgKNiQjOEzEfANBzc7AAMCTHw Message-ID: <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> In-Reply-To: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.6.50022 Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 06:16:51 -0000 Hi Dave,=20 Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Da= ve >Thaler >Envoy=E9=A0: mardi 6 ao=FBt 2013 01:57 >=C0=A0: pcp@ietf.org; draft-ietf-pcp-server-selection@tools.ietf.org >Objet=A0: [pcp] Comments on draft-ietf-pcp-server-selection-01 > >Comments on draft-ietf-pcp-server-selection-01 below. > >Main technical comments: > >1) Needs to remove mention of names and just use addresses. The DHCP > option is being changed per WG discussion. But even before the DHCP > option, we had the default router list (see RFC 6887 section 8.1) whic= h > is a list of IP's with no name known. [Med] IMHO, the dhcp discussion should not impact the consensus the wg had = on the definition of the name. A name can be configured using a variety of = means (manually, device management protocol, etc.). The PCP server selectio= n draft does not make any assumption on how the names are configured. Follo= wing dhc recommendations, the name is first resolved and then its results a= re conveyed in the dhcp option as IP addresses.=20 > >2) Document assumes that > "PCP requests to different servers are independent, the result of a > PCP request to one server does not influence another" >We currently have no WG consensus on this. Some (e.g., Stuart) have >argued that it's the responsibility of the server to interact with other >redundant servers managed by the same entity. Since no one has given >any counter argument, that should be the starting point. [Med] I don't get the point here. The document makes one design assumption = which is: if multiple names are configured to the pcp clients, this is a hi= nt multiple servers are to be contacted simultaneously. If only one name is= configured (which may result in one or multiple IP addresses), only one IP= address will be used to contact that pcp server. The case of "redundant" s= erver as you say, will means that multiple IP addresses are configured to t= he pcp client as being bound to the same PCP server. As currently defined i= n the document, the pcp client will never sent multiple request to multiple= addresses pointing to the same pcp server. What is wrong with that rationa= le? > > 3) There needs to be a step where the selection algorithm takes a source >address into account, if the app specified one. Consider the case of >sending >a PEER after establishing a TCP connection. The source address of the TCP >connection should constrain the PCP server selection mechanism so you >don't try sending PEER messages on some other network than the one the >TCP connection is on. [Med] Yes, I agree. If we had a provisioning data per interface, then we ca= n re-use what we had in the dhcp draft:=20 "A host may have multiple network interfaces (e.g., 3G, WiFi, etc.); each c= onfigured differently. Each PCP server learned MUST be associated with the = interface via which it was learned."=20 The problem is if the pcp server address is configured manually for example= , the interface to which it is bound may not be available.=20 > >4) The server selection is still missing a lot of details on how an addres= s >is selected. E.g.: > * Is it assumed that the addresses of the same server are already ordered > by the configuration mechanism? (I think there's no need for such >assumption) [Med] There is no need for such preference. This can be explicitly indicate= d in the text.=20 > * Should RFC 6724 sorting be done on them by the client? (I think so) [Med] Why do you think we need more than what we have in http://tools.ietf.= org/html/rfc6887#section-8.4?=20 > * If you're trying to use PCP on an IPv4 mapping should you prefer IPv4 o= r >not > for PCP server addresses? [Med] Why? Remember NAT64 is reachable using IPv6 but it assigns external I= Pv4 addresses. The rationale adopted in the document does not need to enter= into such details: multiple names means multiple servers, one name means o= ne pcp server (that can be reached with multiple IP addresses). > * Should a client do RFC 6724 to choose among servers, if point 2 is >addressed > by just using one? [Med] Isn't this covered in http://tools.ietf.org/html/rfc6887#section-8.4? >And for each of the above: Why or why not? > >Full comments (including editorial ones) in context can be found at >http://research.microsoft.com/~dthaler/draft-ietf-pcp-server-selection- >01.pdf >(a .docx is also available at the same location, just change .pdf to .docx= ) > >-Dave > >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Wednesday, May 22, 2013 4:47 AM >> To: i-d-announce@ietf.org >> Cc: pcp@ietf.org >> Subject: [pcp] I-D Action: draft-ietf-pcp-server-selection-01.txt >> >> >> 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 >> Author(s) : Mohamed Boucadair >> Reinaldo Penno >> Dan Wing >> Prashanth Patil >> Tirumaleswar Reddy >> Filename : draft-ietf-pcp-server-selection-01.txt >> Pages : 10 >> Date : 2013-05-22 >> >> Abstract: >> This document specifies the behavior to be followed by the PCP client >> to contact its PCP server(s) when one or several PCP server names are >> configured. Multiple names may be configured to a PCP client in some >> deployment contexts such as multi-homing. >> >> 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-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-server-selection-01 >> >> >> 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 > > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From tireddy@cisco.com Tue Aug 6 00:35:24 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F18F21F9FC9 for ; Tue, 6 Aug 2013 00:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmlNMsn1H5iv for ; Tue, 6 Aug 2013 00:35:19 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0044D21F9FC8 for ; Tue, 6 Aug 2013 00:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1003; q=dns/txt; s=iport; t=1375774519; x=1376984119; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0+4m4ymSpfcZIIOM6CBZpbdiooIKten5bfBBoM+H1k0=; b=C+iJ6/sR1Mtk62lAKbIspoySNc2tuZQfF0AEK8/HcqxyVtAolnK37SBT M1iokNUsJdrTo7NuAPnzIC/8y/UyCD271C8ussaz4FMkfpv+fa24D4JX2 +1AZraeVMfvJg3FLWAggASJ9gpPfZLa57CCF9QsLS6cA/wOwH65tfhnH7 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAASmAFKtJXG//2dsb2JhbABbgwY1UL51gR8WdIIkAQEBBB0dNBcEAgEIEQQBAQsUBQsyHQgCBAESCIgIDLYOjlGBFTgGgxN0A5kKkCWBXoE5gXE5 X-IronPort-AV: E=Sophos;i="4.89,824,1367971200"; d="scan'208";a="243970209" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 06 Aug 2013 07:35:18 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r767ZIsO026580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 6 Aug 2013 07:35:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Tue, 6 Aug 2013 02:35:17 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Reinaldo Penno (repenno)" , "pcp@ietf.org" Thread-Topic: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) Thread-Index: AQHOjFORrIMjf8sOSUiRMwszh5KQt5mGK8aw Date: Tue, 6 Aug 2013 07:35:16 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1900D8CE@xmb-rcd-x10.cisco.com> References: <45A697A8FFD7CF48BCF2BE7E106F06040905138F@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F0604090E81CE@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090E81CE@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.69.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 07:35:24 -0000 I support adoption of this I-D as a WG document (as a co-author). Regards, --Tiru. > -----Original Message----- > From: Reinaldo Penno (repenno) > Sent: Monday, July 29, 2013 3:52 PM > To: pcp@ietf.org > Subject: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepaliv= es > Using Port Control Protocol (PCP) >=20 > Hello, >=20 > This email starts a 2-week consensus call on adopting "Optimizing NAT and > Firewall Keepalives Using Port Control Protocol (PCP)" as a WG item. >=20 > Title : Optimizing NAT and Firewall Keepalives Using Port Contro= l > Protocol (PCP) > Author(s) : T. Reddy et al > Filename : draft-reddy-pcp-optimize-keepalives-01 > URL : > http://tools.ietf.org/html/draft-reddy-pcp-optimize-keepalives-01 >=20 > Please read the current revision and state you opinion either for or > against adoption in the mailing list. >=20 > The call for adoption ends 12th August 2013. >=20 > Thanks, >=20 > Chairs >=20 From Markus.Isomaki@nokia.com Tue Aug 6 05:39:53 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEC621F93D4 for ; Tue, 6 Aug 2013 05:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7u+BJrGYcLrs for ; Tue, 6 Aug 2013 05:39:48 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8A47521F8BFD for ; Tue, 6 Aug 2013 05:39:48 -0700 (PDT) Received: from smtp.mgd.nokia.com ([65.54.30.26]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r76CdZ07005274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 6 Aug 2013 15:39:35 +0300 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.18]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.03.0136.001; Tue, 6 Aug 2013 12:39:35 +0000 From: To: , , Thread-Topic: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) Thread-Index: AQHOjFORrIMjf8sOSUiRMwszh5KQt5mGK8awgAH/cLA= Date: Tue, 6 Aug 2013 12:39:34 +0000 Message-ID: References: <45A697A8FFD7CF48BCF2BE7E106F06040905138F@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F0604090E81CE@xmb-rcd-x04.cisco.com> <913383AAA69FF945B8F946018B75898A1900D8CE@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A1900D8CE@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Imb/kNG8e5MBaAZCGWp2zCcmriI8lnVAfaV3+HkLL5QL0vdF69Z7XYn5GAjjV6RI9UB67e/BoNoOXYTiGPj5VJmDApl0RaDBWu7287tfJVrILsR5Dwm0Mm+M40rzp2zHrKTWcMFeptNvmWIRKM0u7hMBFFjF9kWgOHkJNz2+zN3DLJXhG2tCXj/Rap+FNYfqJmnY+xnLdm9OLCBmcjtcPzo7mPGVzXhEWPROcplGqWOGXdDXUOjsXY/My0yfrsOYeB2hFTSVMeSrE/iAGQ06PYCrvEQGZGgN655Fd6I3dhevKi35XSOvwA3YSzwwUkM+lQ== x-originating-ip: [172.21.81.194] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Nokia-AV: Clean Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 12:39:53 -0000 Same here. ;-) Markus > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > ext Tirumaleswar Reddy (tireddy) > Sent: 06 August, 2013 10:35 > To: Reinaldo Penno (repenno); pcp@ietf.org > Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall > Keepalives Using Port Control Protocol (PCP) >=20 > I support adoption of this I-D as a WG document (as a co-author). >=20 > Regards, > --Tiru. >=20 > > -----Original Message----- > > From: Reinaldo Penno (repenno) > > Sent: Monday, July 29, 2013 3:52 PM > > To: pcp@ietf.org > > Subject: [pcp] WG Call for Adoption: Optimizing NAT and Firewall > > Keepalives Using Port Control Protocol (PCP) > > > > Hello, > > > > This email starts a 2-week consensus call on adopting "Optimizing NAT > > and Firewall Keepalives Using Port Control Protocol (PCP)" as a WG item= . > > > > Title : Optimizing NAT and Firewall Keepalives Using Port Cont= rol > > Protocol (PCP) > > Author(s) : T. Reddy et al > > Filename : draft-reddy-pcp-optimize-keepalives-01 > > URL : > > http://tools.ietf.org/html/draft-reddy-pcp-optimize-keepalives-01 > > > > Please read the current revision and state you opinion either for or > > against adoption in the mailing list. > > > > The call for adoption ends 12th August 2013. > > > > Thanks, > > > > Chairs > > >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From Markus.Isomaki@nokia.com Tue Aug 6 06:15:23 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A4421F9E36 for ; Tue, 6 Aug 2013 06:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RGo4cIjrC9a for ; Tue, 6 Aug 2013 06:15:17 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2A82521F9E11 for ; Tue, 6 Aug 2013 06:15:16 -0700 (PDT) Received: from smtp.mgd.nokia.com ([65.54.30.21]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r76DF5g5020715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 6 Aug 2013 16:15:07 +0300 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.18]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.03.0136.001; Tue, 6 Aug 2013 13:15:05 +0000 From: To: , , Thread-Topic: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) Thread-Index: AQHOjEWHrIMjf8sOSUiRMwszh5KQt5mGMwnQgAH4seA= Date: Tue, 6 Aug 2013 13:15:05 +0000 Message-ID: References: <45A697A8FFD7CF48BCF2BE7E106F06040905138F@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F0604090E81CE@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36EE99C8E34@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EE99C8E34@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Imb/kNG8e5MBaAZCGWp2zCcmriI8lnVAfaV3+HkLL5QL0vdF69Z7XYn5GAjjV6RI9UB67e/BoNoOXYTiGPj5VJmDApl0RaDBWu7287tfJVrILsR5Dwm0Mm+M40rzp2zHrKTWcMFeptNvmWIRKM0u7hMBFFjF9kWgOHkJNz2+zN3DLJXhG2tCXj/Rap+FNYfqJmnY+xnLdm9OLCBmcjtcPzo7mPGVzXhEWPROcplGqWOGXdDXUOjsXY/My0yfrsOYeB2hFTSVMeSrE/iAGQ06PYCrvEQGZGgN655Fd6I3dhevKi35XSOvwA3YSzwwUkM+lQ== x-originating-ip: [172.21.81.194] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Nokia-AV: Clean Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 13:15:23 -0000 Hi, mohamed.boucadair@orange.com wrote: >=20 > I have one comment for the authors: consider adding some text to highligh= t > PCP benefits to reduce keepalive messages when deployed in managed > networks (i.e., both the underlying network and the service are managed b= y > the same administrative entity). A typical example is SIP-based deploymen= ts: > optimize the load on access service nodes (SBC, SBE, P-CSCF, etc.) becaus= e > the lifetime of the mapping is known to the SIP UA and as such there is n= o > need to issue frequent register messages to maintain the mapping alive, e= tc. >=20 Thanks for the comment.=20 I have a question, though: If the same entity operates the network and the = service such as SIP, do they need an explicit protocol like PCP to control = or learn about the mapping lifetimes, or can they just configure them? I me= an, since the service provider is able to configure the NAT/FW mapping life= times in the way they like, can't they just set the keep-alives in their SI= P clients accordingly? As an example, the Firewall in a mobile network can = be configured to set the lifetime for TCP connections destined to the SIP p= roxy (SBC, P-CSCF) to 1 hour, and via Device Management the operator could = also turn off or set the IMS client keep-alives to match that. PCP would no= t be needed for that particular case. It would seem to me that PCP would have more utility in "unmanaged" or "unr= elated" cases where the client app basically has no a priori knowledge abou= t the network, and neither does the application service provider. Or simila= rly, the NATs or Firewalls would have no idea what the TCP connections woul= d be used for.=20 Markus=20 From mohamed.boucadair@orange.com Tue Aug 6 06:27:45 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE6721F9E63 for ; Tue, 6 Aug 2013 06:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rWyog0-ClDX for ; Tue, 6 Aug 2013 06:27:40 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C03C421F9346 for ; Tue, 6 Aug 2013 06:27:39 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id D331A2645B5; Tue, 6 Aug 2013 15:27:38 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id B34AB2380EA; Tue, 6 Aug 2013 15:27:38 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Tue, 6 Aug 2013 15:27:38 +0200 From: To: "Markus.Isomaki@nokia.com" , "repenno@cisco.com" , "pcp@ietf.org" Date: Tue, 6 Aug 2013 15:27:32 +0200 Thread-Topic: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) Thread-Index: AQHOjEWHrIMjf8sOSUiRMwszh5KQt5mGMwnQgAH4seCAAAp+kA== Message-ID: <94C682931C08B048B7A8645303FDC9F36EE99C918C@PUEXCB1B.nanterre.francetelecom.fr> References: <45A697A8FFD7CF48BCF2BE7E106F06040905138F@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F0604090E81CE@xmb-rcd-x04.cisco.com> <94C682931C08B048B7A8645303FDC9F36EE99C8E34@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.6.121255 Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 13:27:45 -0000 Hi Markus, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] >Envoy=E9=A0: mardi 6 ao=FBt 2013 15:15 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN; repenno@cisco.com; pcp@ietf.org >Objet=A0: RE: [pcp] WG Call for Adoption: Optimizing NAT and Firewall >Keepalives Using Port Control Protocol (PCP) > >Hi, > >mohamed.boucadair@orange.com wrote: >> >> I have one comment for the authors: consider adding some text to >highlight >> PCP benefits to reduce keepalive messages when deployed in managed >> networks (i.e., both the underlying network and the service are managed >by >> the same administrative entity). A typical example is SIP-based >deployments: >> optimize the load on access service nodes (SBC, SBE, P-CSCF, etc.) >because >> the lifetime of the mapping is known to the SIP UA and as such there is >no >> need to issue frequent register messages to maintain the mapping alive, >etc. >> > >Thanks for the comment. > >I have a question, though: If the same entity operates the network and the [Med] This is indeed the same entity but distinct operational teams.=20 >service such as SIP, do they need an explicit protocol like PCP to control >or learn about the mapping lifetimes, or can they just configure them? [Med] Configure (dedicated) longer timer is indeed an approach but the use = of PCP is superior since the user agent can discover the configured lifetim= e and therefore react accordingly.=20 I >mean, since the service provider is able to configure the NAT/FW mapping >lifetimes in the way they like, can't they just set the keep-alives in >their SIP clients accordingly? [Med] As I said above, this is doable but it is static and needs off-line c= oordination to tweak the midbox and the user agent.=20 As an example, the Firewall in a mobile >network can be configured to set the lifetime for TCP connections destined >to the SIP proxy (SBC, P-CSCF) to 1 hour, and via Device Management the >operator could also turn off or set the IMS client keep-alives to match >that. [Med] Agree; that's doable.=20 PCP would not be needed for that particular case. [Med] PCP can be avoided but still there is a need for coordination between= distinct operational teams (those operating the network and those operatin= g the service). If for any reason the timers is to be updater because of so= me observed failures (synchronization issues), having PCP is superior sine = the timers is hinted by the user agent and the user agent is aware of the t= imer without requiring an additional management interface. Note, pcp is not= supposed to be activated only for SIP but for other purposes: one single s= olution for a variety of usages.=20 > >It would seem to me that PCP would have more utility in "unmanaged" or >"unrelated" cases where the client app basically has no a priori knowledge >about the network, and neither does the application service provider. Or >similarly, the NATs or Firewalls would have no idea what the TCP >connections would be used for. > >Markus From B.McCann@F5.com Tue Aug 6 08:24:12 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013F321F9E2B for ; Tue, 6 Aug 2013 08:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.739 X-Spam-Level: X-Spam-Status: No, score=-8.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qdik8w-BjRT0 for ; Tue, 6 Aug 2013 08:24:00 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id BE3B821F9E11 for ; Tue, 6 Aug 2013 08:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=B.McCann@f5.com; q=dns/txt; s=seattle; t=1375802640; x=1407338640; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=POMp3InW2Fnq4hUkRlQidCm7t6nroUaIMNlvNWj9hUk=; b=mm2CVBwQ389ekTASTOpRfy01RLbD5mp0KIZH8jQO7pu3ekZUU/S5JET4 IgbKxxD/d6ArJZifLgFpbAyMu9SYNfqIcnybqiJMv14Yldi33eAnYyhE/ cPBKGRxdERF7zS2qPB+3saDBpuWBR+lzvhtHrgHHn2rkHgOM+pYCVy26Y w=; X-IronPort-AV: E=Sophos;i="4.89,827,1367971200"; d="scan'208,217";a="77941183" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 06 Aug 2013 15:23:56 +0000 Received: from LWLECAS01.olympus.F5Net.com (192.168.96.3) by seaecas02.olympus.F5Net.com (192.168.16.221) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 6 Aug 2013 08:23:55 -0700 Received: from LWLMBX01.olympus.F5Net.com ([fe80::c509:8f7f:7f5f:cab9]) by LWLECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0123.003; Tue, 6 Aug 2013 11:23:54 -0400 From: Ben McCann To: Rafa Marin Lopez Thread-Topic: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP security) Thread-Index: AQHOg/4QNvmxMKgZ9E+rY1WqIUKDo5lq/65ggAUTqQCAFxFjgA== Date: Tue, 6 Aug 2013 15:23:54 +0000 Message-ID: <9374F3A019050A4C805B8DEF27285BE40115E1A00E@LWLMBX01.olympus.F5Net.com> References: <9374F3A019050A4C805B8DEF27285BE40115E075A9@LWLMBX01.olympus.F5Net.com> <839332CA-66AD-48A5-AF0E-7AAD1964FE5F@yegin.org> <9374F3A019050A4C805B8DEF27285BE40115E08503@LWLMBX01.olympus.F5Net.com> <76B8454D-73F0-4E3D-81A6-55F121535901@um.es> <9374F3A019050A4C805B8DEF27285BE40115E08BCF@LWLMBX01.olympus.F5Net.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.101.23] Content-Type: multipart/alternative; boundary="_000_9374F3A019050A4C805B8DEF27285BE40115E1A00ELWLMBX01olymp_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP security) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 15:24:12 -0000 --_000_9374F3A019050A4C805B8DEF27285BE40115E1A00ELWLMBX01olymp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rafa, Thanks for clarifying the purpose of the PANA SA during the transmission of= the final EAP response packet. If I understand RFC 5191 correctly, the EAP= response packets are the last packets exchanged prior to the Access phase = of the PANA protocol so it makes sense they must be cryptographically bound= to the EAP master key to prevent MITM attacks. I'd not considered this in my earlier email because I was thinking about th= e PCP packets that are sent after an SA is established. These PCP packets (= such as MAP requests) must include a signature derived from the EAP MSK to = prove they come from an authenticated peer. I think these PCP packets provi= de the same MITM defense as signing the EAP response packet does in PANA. (= They prove the sender knows the EAP MSK). I did not see why PANA authentica= tion had to cryptographically bind the PANA final response packet to the EA= P MSK because subsequently transmitted PCP packets are also bound to the EA= P MSK. So, I misunderstood the motivation for signing the final EAP response packe= t. I thought PANA was ensuring the integrity of the response payload instea= d of providing proof of knowledge of the MSK. That misunderstanding led me = to ask, should the authentication protocol (PANA or EAP-in-PCP) also ensure= the integrity of earlier authentication packets that negotiate cipher suit= es and other authentication protocol parameters? (I thought, if integrity c= hecking is required for the EAP response, then shouldn't it be required for= earlier packets)? This is why I mentioned EAP-TTLS. I think that protocol = protects the entire EAP packet exchange using TLS. I wondered whether EAP-T= TLS provides sufficient integrity for the authentication exchange so we cou= ld avoid signing packets within the PCP authentication protocol. You asked whether I thought the consensus call was premature. Possibly so, = especially if we select PANA as the authentication protocol. I think PANA b= rings with it a set of security decisions, such as not signing the cipher s= uite parameters, that may be inappropriate for PCP. We can design EAP-in-PC= P while we finalize the PCP authentication security requirements and hence = arrive at a EAP-in-PCP design that meets those requirements. I don't think = we have that flexibility if we select PANA because it has a pre-existing se= t of security requirements that may, or may not, be appropriate for PCP. In= the absence of fully baked PCP security requirements, I prefer EAP-in-PCP = because it is less defined than PANA. Last, I had previously read, and I just re-read, your post http://www.ietf.= org/mail-archive/web/pcp/current/msg02349.html. You state that implementing= an EAP lower layer is hard but your post doesn't clearly explain that poin= t. You mention interactions with EAP state machines and retransmissions but= you don't explain why this is so hard that we absolutely need PANA. There = are least two protocols (PANA and IKEv2) that manage to transport EAP over = IP so we have examples how to do this for EAP-in-PCP. -Ben McCann P.S. Vacation was great. Apologies for the late reply to your email. From: Rafa Marin Lopez [mailto:rafa@um.es] Sent: Sunday, July 21, 2013 7:44 PM To: Ben McCann Cc: pcp@ietf.org Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP secur= ity) Hi Ben: On Jul 19, 2013, at 2:55 AM, Ben McCann wrote: Hi Rafa, I incorrectly used a discussion about the suitability of the OpenPANA impl= ementation as an argument to defend my statement "EAP-in-PCP provides a cle= an slate that's unencumbered by the design decisions and assumptions of an = existing protocol (PANA).". That argument was a waste of time because the s= uitability or availability of a reference implementation is irrelevant to w= hether PANA was designed with a set of security considerations that are app= ropriate for PCP. This understanding of the security considerations is the = "clean slate" that is important to me. [Rafa] I must say I am a little bit confused about your general line of tho= ughts here. You started your arguments first saying about PANA is not mobil= e-friendly, then PANA consumes resources and then implementation problems o= r the liveliness test. Those are clearly misconceptions about PANA that we = have clarified. Now, "clean slate" is regarding security considerations. Ok= , let us discuss about security, but you may agree with me that this line o= f arguments might be a little bit confusing. For example, PANA negotiates its own security association so it can provide= data integrity for the final EAP response packet. That's fine, but where have we decided that PCP needs to secure the integri= ty of that response packet? (It probably should). [Rafa] The main purpose of the PANA SA does not have anything to do with pr= otecting the final EAP response packet. As many security protocols, it prov= ides key confirmation to bind authentication with the exported key material= by EAP. This is a cryptographic binding between the two layers. This ensu= res that same two entities participate not only performing EAP but also the= EAP lower-layer protocol. This is useful to avoid man-in-the-middle attack= s. Moreover it serves to avoid the attack you mention about ciphersuite and= authentication parameters below (see how PANA generates the PANA_AUTH_KEY)= . PANA does not secure the earlier EAP packets that carry parameters like the= cipher suite selection or authentication parameters for the selected EAP m= ethod. So, those could be compromised by an attacker. Where have we decided= that this is an acceptable risk for PCP? [Rafa] If you don't have any keys.... how are you supposed to protect anyth= ing? If we assume we are performing EAP for authentication and key managem= ent, we will not have any key material exported to any EAP lower-layer (e.g= . PCP or PANA) until EAP is successfully finished at the end. Moreover EAP= is designed to operate with no security assumption in the lower-layer. We haven't discussed that, but we implicitly agree to live with it if we mo= ve forward with PANA. (Or, at least, we accept that risk with some EAP meth= ods). [Rafa] See my comment above, there is no such a risk. Btw, what EAP methods= are you referring to? As I said EAP is designed to operate with no securit= y. I prefer EAP-in-PCP because it will make us think through those issues for = PCP. (We've made a good start in the auth requirements draft). [Rafa] About simplicity, how about this? Let assume that the only thing you= have to worry about at PCP level is to manage a pre-shared key between PCP= client and PCP server. That is simple, don't you think? Until we get those requirements down, I think it's premature to decide PANA= is the right choice. [Rafa] Then, do you think the consensus call is too premature? It might be, if we agree that PANA's security considerations are OK for PCP= . Or, we could decide that a simple EAP-in-PCP transport w/o *any* security= association is sufficient because we can leverage the security properties = of EAP methods such as EAP-TTLS to achieve the data integrity required for = the EAP protocol. [Rafa] Either or I don't understand your point or I think there is some con= fusion about EAP and its layers (see Fig. 1 and 2 in RFC 3748) EAP-TTLS is = a method and it will export keys to the EAP lower-layer . Why do you relate= EAP-TTLS with the protection of the EAP protocol ? In this regard, I also think there is a general misconception about EAP. Fo= r example, people may think that this is just tunneling EAP in PCP (I think= you even mentioned this in a previous e-mail). But it is not. RFC 3748 def= ines requirements for a correct EAP lower-layer. If we transport EAP in PCP= , PCP will become an EAP lower-layer according to the EAP standard. Conseq= uence is PCP has to follow requirements imposed by RFC 3748 and RFC 5247 to= be a correct EAP lower-layer. In other words, this means we will have to d= efine a new EAP lower-layer and to follow the same path we already followed= with PANA which is a RFC now. In other words, we are essentially re-invent= ing the wheel (I say this based also on experience since, at research level= , I have tried to design different EAP lower-layers... EAP-in-X, EAP-in-Y, = etc...). I would appreciate if you could read this link I sent to the list = about this aspect: http://www.ietf.org/mail-archive/web/pcp/current/msg023= 49.html The usage of PANA avoids to include all these aspects in PCP itself (PANA a= lready does it), and as a consequence the PCP security would be simplified = a lot. I'm vacation for two weeks and won't be in Berlin to continue this discussi= on face-to-face. Enjoy your vacations! -Ben McCann -----Original Message----- From: Rafa Marin Lopez [mailto:rafa@um.es] Sent: Thursday, July 18, 2013 5:31 PM To: Ben McCann Cc: pcp@ietf.org Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP secur= ity) Hi Ben: On Jul 18, 2013, at 7:00 PM, Ben McCann wrote: Thank you for clarifying that "PANA does not force clients to always have a= session, or always stay awake or connected". That, I believe, wasn't Margaret's point. PANA *supports* server side re-au= thentication even if the client doesn't think it's necessary. So, if the se= rver chooses, it can wake up the client by sending packets. That said, this= really isn't a legitimate criticism of the PANA protocol. It's an issue th= at can be addressed by proper programming or configuration of the PCP/PANA = server to make sure it doesn't unnecessarily re-authenticate the clients. So, I agree with you that PANA, on a properly configured server, can be as = "mobile friendly" and lightweight as EAP-in-PCP. My concerns about starting from a clean slate are based, in part, on Steve = Hartman's "Implementation Analysis: strong preference for PCP-specific appr= oach" (http://www.ietf.org/mail-archive/web/pcp/current/msg02324.html). His= arguments were persuasive (to me) and the counter-arguments were not. [Rafa] Why my answers in http://www.ietf.org/mail-archive/web/pcp/current/m= sg02349.html are not ok? I understand that implementation should not dictate protocol design but I t= hink we should let implementation *inform* protocol design. If I have to se= lect between two ways to define a protocol, and one of them is simpler to i= mplement, then I will tend to vote for the simpler option if all other crit= eria are equal. I see EAP-in-PCP as the simpler option even if there is sou= rce code for PANA. I've also reviewed the OpenPANA source code and I have some concerns that i= llustrate this point: * The PANA state machine includes 13 states with 22 separate input events. = That state machine has to be integrated with the simpler PCP state machine.= My intuition, based on too many years of experience, is that integrating t= he PANA and PCP state machines is tricky to implement, debug, and verify. T= hat complexity is, in part, because PANA already has a fairly complex state= machine. I don't believe EAP-in-PCP requires this much complexity. [Rafa] Ben, I have always assumed we all have experience in the area. In pa= rticular, I have been working on PANA since 2003 and I have done source cod= ing myself, I have been leading an open source PANA implementation and depl= oyed PANA in several EU projects, without any inconvenience so far. About the state machine, I can tell you that part of it is completely optio= nal. And about the integration between PANA and PCP, I disagree based on the exp= erience we got from http://www.ietf.org/proceedings/86/slides/slides-86-pcp= -17 * The OpenPANA implementation is about 6900 SLOCs long as measured by an sl= occount version 2.26. This seems like a lot of code (aka complexity) to tun= nel EAP packets over PCP. And, that doesn't include the code that must be a= dded to PCP required to integrate PCP with PANA. I believe an EAP-in-PCP im= plementation will be much simpler but, I admit, I don't have an implementat= ion to show you that proves that point. [Rafa] This number is completely wrong as I already explained in http://www= .ietf.org/mail-archive/web/pcp/current/msg02631.html (as you may observe th= is is a repeating conversation). You may agree with me that doing the slocc= ount over the entire package does not help too much. We need to be more sp= ecific. In the message I already sent, the discussion was about openpana-0.2.3. Rig= ht now, we have openpana-0.2.4 and we have new values. The following values= only show the LoC dedicated to PANA, not to EAP ST, EAP-Method or RADIUS c= lient since those values will be common to any other solution using EAP and= RADIUS. OpenPANA: The PAA: 3130 LoC (PAA ST + PAA main program + PANA messages + PAA session + PRF) The PaC 2720 (PaC ST + PaC main + PANA messages + PaC session + PRF) It is worth noting that those values includes 1846 LoCs which are common fu= nctionality to PaC and PAA. Moreover, as I also explained in the e-mail we have a version for very cons= trained devices (sensor nodes). In particular we have a PaC implementation = for Contiki OS named PANATIKI (http://sourceforge.net/projects/panatiki) an= d the values are: PANATIKI : 517 (PaC state machine) + 141 (PaC main program) But again, please take into account this is just an open source implementat= ion and not a product. And, of course, running code is absolutely better th= an no code. Regarding your comment "And, that doesn't include the code that must be add= ed to PCP required to integrate PCP with PANA", please see slide 12 in http= ://www.ietf.org/proceedings/86/slides/slides-86-pcp-17 . Just a 100 lines= that includes "PCP Key derivation and export. Unix Sockets." in the case = of OpenPANA. * The presence of an open source version of PANA is a vote in its favor but= that depends on whether that code is easily portable to many environments.= I think the OpenPANA implementation makes assumptions about its runtime en= vironment that aren't very portable. It assumes a multi-threaded environmen= t with posix sockets and my runtime environment doesn't meet those requirem= ents. [Rafa] For example, PANATIKI does not assume multi-threaded environment wit= h posix sockets (it is an implementation for a sensor node after all). Btw,= there are two open source implementations OpenPANA/PANATIKI and CPANA. To be fair, I don't think I've said anything here that wasn't already cover= ed by Steve Hartman. But, I did review the code and I agree with his conclu= sions. [Rafa] As you can see, I already counter-argumented that analysis. In any c= ase, I will be in Berlin so any doubt you have about OpenPana/PANATIKI or j= ust implementating PANA, let me know and I will be more than happy to meet = and discuss. Best regards. -Ben McCann -----Original Message----- From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Thursday, July 18, 2013 4:34 AM To: Ben McCann Cc: Dave Thaler; pcp@ietf.org Subject: PANA misconceptions (was Re: [pcp] CONSENSUS CALL on PCP security) Hello, I'm afraid your below issues are based on misconceptions introduced by the = http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf slides. We did address those misconceptions in several rounds, but it seems like so= me still linger. PANA does not force clients to always have a session, or always stay awake = or connected. If a client wants to get authenticated and generate a 5 minute key, and aft= erwards sleep, detach, etc., it can very well do that using PANA. We can support that by simply setting the lifetime of the PANA SA to that s= hort fix value, or letting the PANA SA timeout and expire. So, you can run PANA and have a 5 min SA, then have no PANA activity for 23= :55hrs, and then come back and do another PANA authentication and have anot= her 5min SA. No problems. Therefore, there are no issues with mobile, and no issues with server side = resources. After all, PANA is adopted by Zigbee Alliance. I don't think the deployment= cases considered here are any more constrained than theirs... EAP-in-PCP provides a clean slate that's unencumbered by the design decisio= ns and assumptions of an existing protocol (PANA). Was there any other concern leading to your above statement? Alper On Jul 17, 2013, at 10:20 PM, Ben McCann wrote: 1) Could you *live with* EAP-in-PCP? If not, state reason you would object. YES 2) Could you *live with* PANA? If not, state reason you would object. Yes, but we really rather not use PANA. See below... 3) If you said yes to both 1 and 2, but have a strong preference between th= e two, which approach do you prefer and why? We strongly prefer EAP-in-PCP for several reasons: * PANA, as we understand it, is not mobile-friendly. It requires the PCP cl= ient to *always* have an authenticated session active and that is wasteful = on mobile clients when the authentication rekey interval is much shorter th= an the mapping lifetime. Margaret Wasserman captured this in slides 13 and = 14 of her presentation http://www.ietf.org/proceedings/85/slides/slides-85-= pcp-17.pdf. We believe the *client* should decide when to authenticate (bec= ause it needs to create or refresh a mapping) because that lets the client = optimize its use of the network and reduce its power consumption. We understand that a PCP server may need to send a message to the client wh= en no authenticated session is active. If no authenticated session is activ= e then we prefer the server send an UN-authenticated "call home" message di= recting the client to authenticate and then the server can send its message= s over the authenticated channel. We recognize an attacker can induce the c= lient to connect to the server by forging an unauthenticated "call home" me= ssage. But, having done that, the client can ignore subsequent forged call = home messages because it will already have an authenticated session. Worse = case, an attacker can't make EAP-in-PCP consume any more client resources t= han PANA does because PANA requires the client to always have an authentica= ted session available. * PANA requires more server side resources. The authentication protocol sho= uld efficiently support 100,000's of clients on a large PCP server. Why sho= uld the server continuously maintain authenticated sessions with *every* cl= ient? Clients using 24 hour mapping lifetimes can be served by short authen= tication key lifetime like, for example, 5 minutes. Let the client connect,= authenticate, program the mappings, and then let the authenticated session= expire. Rinse and repeat in 24 hours,. Client-driven authentication via EA= P-in-PCP requires less resources on the server because the server can disca= rd the authenticated session state once the key lifetime expires. There was some discussion that PANA is preferable to EAP-in-PCP because it = supports "liveness testing". We don't believe liveness testing is useful wh= en the server resources consumed, per client, are PCP mappings. Checking th= e liveness of 100,000 clients is much more resource intensive on the server= than just keeping the client's mappings around until they expire naturally= at the end of their lifetime. In short, we believe EAP-in-PCP will scale b= etter on the server than PANA. * We believe the decision to use EAP-in-PCP vs. PANA is a choice between de= signing and implementing an EAP-in-PCP transport that is tailored for PCP v= ersus adapting an existing protocol (PANA) to fit the needs of PCP. We don= 't think implementing an EAP-in-PCP transport is difficult so we prefer it = over PANA. EAP-in-PCP provides a clean slate that's unencumbered by the des= ign decisions and assumptions of an existing protocol (PANA). -Ben McCann _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer= Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --_000_9374F3A019050A4C805B8DEF27285BE40115E1A00ELWLMBX01olymp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rafa,

 <= /p>

Thanks for clarifying the= purpose of the PANA SA during the transmission of the final EAP response p= acket. If I understand RFC 5191 correctly, the EAP response packets are the last packets exchanged prior to the Access phase of the PA= NA protocol so it makes sense they must be cryptographically bound to the E= AP master key to prevent MITM attacks.

 <= /p>

I’d not considered = this in my earlier email because I was thinking about the PCP packets that are sent after an SA is established. These PCP pack= ets (such as MAP requests) must include a signature derived from the EAP MS= K to prove they come from an authenticated peer. I think these PCP packets = provide the same MITM defense as signing the EAP response packet does in PANA. (They prove the sender knows= the EAP MSK). I did not see why PANA authentication had to cryptographical= ly bind the PANA final response packet to the EAP MSK because subsequently = transmitted PCP packets are also bound to the EAP MSK.

 <= /p>

So, I misunderstood the m= otivation for signing the final EAP response packet. I thought PANA was ens= uring the integrity of the response payload instead of providing proof of k= nowledge of the MSK. That misunderstanding led me to ask, should the au= thentication protocol (PANA or EAP-in-PCP) also ensure the integrity of earlier authentication packets that neg= otiate cipher suites and other authentication protocol parameters? (I thoug= ht, if integrity checking is required for the EAP response, then shouldn= 217;t it be required for earlier packets)? This is why I mentioned EAP-TTLS. I think that protocol protects the entir= e EAP packet exchange using TLS. I wondered whether EAP-TTLS provides suffi= cient integrity for the authentication exchange so we could avoid signing p= ackets within the PCP authentication protocol.

 <= /p>

You asked whether I thoug= ht the consensus call was premature. Possibly so, especially if we select P= ANA as the authentication protocol. I think PANA brings with it a set of security decisions, such as not signing the cipher suite = parameters, that may be inappropriate for PCP. We can design EAP-in-PCP while we fina= lize the PCP authentication security requirements and hence arrive at a EAP= -in-PCP design that meets those requirements. I don’t think we have t= hat flexibility if we select PANA because it has a pre-existing set of security requirements that may, or may not, b= e appropriate for PCP. In the absence of fully baked PCP security requireme= nts, I prefer EAP-in-PCP because it is less defined than PANA.

 <= /p>

Last, I had previously re= ad, and I just re-read, your post http://www.ietf.org/mail-archive/web/pcp/current/msg02349.html. You state that implementing an EAP lower layer i= s hard but your post doesn’t clearly explain that point. You mention = interactions with EAP state machines and retransmissions but you don’t explain why this is so hard that we absolutely need PANA. = There are least two protocols (PANA and IKEv2) that manage to transport EAP= over IP so we have examples how to do this for EAP-in-PCP.

 <= /p>

-Ben McCann

P.S. Vacation was great. Apologies for the late reply to your email.

 <= /p>

 <= /p>

From: Rafa Mar= in Lopez [mailto:rafa@um.es]
Sent: Sunday, July 21, 2013 7:44 PM
To: Ben McCann
Cc: pcp@ietf.org
Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PC= P security)

 

Hi Ben:

 

On Jul 19, 2013, at 2:55 AM, Ben McCann wrote:<= /o:p>



Hi Rafa,

I incorrectly used a discussion about the suitability of the OpenPANA  = ;implementation as an argument to defend my statement "EAP-in-PCP prov= ides a clean slate that's unencumbered by the design decisions and assumpti= ons of an existing protocol (PANA).". That argument was a waste of time because the suitability or availability of a = reference implementation is irrelevant to whether PANA was designed with a = set of security considerations that are appropriate for PCP. This understan= ding of the security considerations is the "clean slate" that is important to me.

 

[Rafa] I must say I am a little bit confused about y= our general line of thoughts here. You started your arguments first saying = about PANA is not mobile-friendly, then PANA consumes resources and then im= plementation problems or the liveliness test. Those are clearly misconceptions about PANA that we have clarified.&= nbsp;Now, "clean slate" is regarding security considerations. Ok,= let us discuss about security, but you may agree with me that this line of= arguments might be a little bit confusing. 




For example, PANA negotiates its own security association so it can provide= data integrity for the final EAP response packet.

That's fine, but where have we decided that PCP need= s to secure the integrity of that response packet? (It probably should).

 

[Rafa] The main purpose of the PANA SA does not= have anything to do with protecting the final EAP response packet. As many= security protocols, it provides key confirmation to bind authentication wi= th the exported key material by EAP. This  is a cryptographic binding between the two layers. This ensures that= same two entities participate not only performing EAP but also the EAP low= er-layer protocol. This is useful to avoid man-in-the-middle attacks. = Moreover it serves to avoid the attack you mention about ciphersuite and authentication parameters below (see how PAN= A generates the PANA_AUTH_KEY). 



PANA does not secure the earlier EAP packets that ca= rry parameters like the cipher suite selection or authentication parameters= for the selected EAP method. So, those could be compromised by an attacker= . Where have we decided that this is an acceptable risk for PCP?

 

[Rafa] If you don't have any keys.... how are you su= pposed to protect anything?  If we assume we are performing EAP for au= thentication and key management, we will not have any key material exported= to any EAP lower-layer (e.g. PCP or PANA) until EAP is successfully finished at the end.  Moreover EAP is desig= ned to operate with no security assumption in the lower-layer. 

 

We haven't discussed that, but we implicitly agree t= o live with it if we move forward with PANA. (Or, at least, we accept that = risk with some EAP methods).

 

[Rafa] See my comment above, there is no such a risk= . Btw, what EAP methods are you referring to? As I said EAP is designe= d to operate with no security.




I prefer EAP-in-PCP because it will make us think through those issues for = PCP. (We've made a good start in the auth requirements draft).

 

[Rafa] About simplicity, how about this? Let assume = that the only thing you have to worry about at PCP level is to manage a pre= -shared key between PCP client and PCP server. That is simple, don't you th= ink?

 

Until we get those requirements down, I think it's p= remature to decide PANA is the right choice.

 

[Rafa] Then, do you think the consensus call is too = premature? 



It might be, if we agree that PANA's security consid= erations are OK for PCP. Or, we could decide that a simple EAP-in-PCP trans= port w/o *any* security association is sufficient because we can leverage t= he security properties of EAP methods such as EAP-TTLS to achieve the data integrity required for the EAP protoc= ol.

 

[Rafa] Either or I don't understand your point or I = think there is some confusion about EAP and its layers (see Fig. 1 and 2 in= RFC 3748) EAP-TTLS is a method and it will export keys to the EAP low= er-layer . Why do you relate EAP-TTLS with the protection of the EAP protocol ?

 

In this regard, I also think there is a general misc= onception about EAP. For example, people may think that this is just tunnel= ing EAP in PCP (I think you even mentioned this in a previous e-mail). But = it is not. RFC 3748 defines requirements for a correct EAP lower-layer. If we transport EAP in PCP , PCP will becom= e an EAP lower-layer according to the EAP standard. Consequence is PCP has = to follow requirements imposed by RFC 3748 and RFC 5247 to be a correct EAP= lower-layer. In other words, this means we will have to define a new EAP lower-layer and to follow the same = path we already followed with PANA which is a RFC now. In other words, we a= re essentially re-inventing the wheel (I say this based also on experience = since, at research level, I have tried to design different EAP lower-layers... EAP-in-X, EAP-in-Y, etc...).= I would appreciate if you could read this link I sent to the list about th= is aspect:  http://www.ietf.org/mail-archive/web/pcp/current/msg02349.= html

 

The usage of PANA avoids to include all these aspect= s in PCP itself (PANA already does it), and as a consequence the PCP securi= ty would be simplified a lot.




I'm vacation for two weeks and won't be in Berlin to continue this discussi= on face-to-face.

 

Enjoy your vacations!




-Ben McCann

-----Original Message-----
From: Rafa Marin Lopez [mailto:rafa@um.es= ]
Sent: Thursday, July 18, 2013 5:31 PM
To: Ben McCann
Cc: pcp@ietf.org
Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP secur= ity)

Hi Ben:

On Jul 18, 2013, at 7:00 PM, Ben McCann wrote:


Thank you for clarifying that "PANA does not fo= rce clients to always have a session, or always stay awake or connected&quo= t;.

 

That, I believe, wasn't Margaret's point. PANA *supp= orts* server side re-authentication even if the client doesn't think it's n= ecessary. So, if the server chooses, it can wake up the client by sending p= ackets. That said, this really isn't a legitimate criticism of the PANA protocol. It's an issue that can be add= ressed by proper programming or configuration of the PCP/PANA server to mak= e sure it doesn't unnecessarily re-authenticate the clients.

 

So, I agree with you that PANA, on a properly config= ured server, can be as "mobile friendly" and lightweight as EAP-i= n-PCP.

 

 

My concerns about starting from a clean slate are ba= sed, in part, on Steve Hartman's "Implementation Analysis: strong pref= erence for PCP-specific approach" (http://www.ietf.org/mail-archive/we= b/pcp/current/msg02324.html). His arguments were persuasive (to me) and the counter-arguments were not. =


[Rafa] Why my answers in http://www.ietf.org/mail-archive/web/pcp/current/msg02349.html are not = ok?


 

I understand that implementation should not dictate = protocol design but I think we should let implementation *inform* protocol = design. If I have to select between two ways to define a protocol, and one = of them is simpler to implement, then I will tend to vote for the simpler option if all other criteria are equal= . I see EAP-in-PCP as the simpler option even if there is source code for P= ANA.

 

I've also reviewed the OpenPANA source code and I ha= ve some concerns that illustrate this point:

 

* The PANA state machine includes 13 states with 22 = separate input events. That state machine has to be integrated with the sim= pler PCP state machine. My intuition, based on too many years of experience= , is that integrating the PANA and PCP state machines is tricky to implement, debug, and verify. That complex= ity is, in part, because PANA already has a fairly complex state machine. I= don't believe EAP-in-PCP requires this much complexity.


[Rafa] Ben, I have always assumed we all have experience in the area. In pa= rticular, I have been working on PANA since 2003 and I have done source cod= ing myself, I have been leading an open source PANA implementation and depl= oyed PANA in several EU projects,  without any inconvenience so far.

About the state machine, I can tell you that part of it is completely optio= nal.

And about the integration between PANA and PCP, I disagree based on the exp= erience we got from http= ://www.ietf.org/proceedings/86/slides/slides-86-pcp-17


 

* The OpenPANA implementation is about 6900 SLOCs lo= ng as measured by an sloccount version 2.26. This seems like a lot of code = (aka complexity) to tunnel EAP packets over PCP. And, that doesn't include = the code that must be added to PCP required to integrate PCP with PANA. I believe an EAP-in-PCP implementatio= n will be much simpler but, I admit, I don't have an implementation to show= you that proves that point.


[Rafa] This number is completely wrong as I already explained in http://www.ietf.org/mail-archive/web/pcp/current/msg02631.html (as you = may observe this is a repeating conversation). You may agree with me that d= oing the sloccount  over the entire package does not help too much. We= need to be more specific.

In the message I already sent, the discussion was about openpana-0.2.3. Rig= ht now, we have openpana-0.2.4 and we have new values. The following values= only show the LoC dedicated to PANA, not to EAP ST, EAP-Method or RADIUS c= lient since those values will be common to any other solution using EAP and RADIUS.

OpenPANA:

The PAA:

3130 LoC (PAA ST + PAA main program + PANA messages + PAA sessi= on + PRF)

The PaC

2720 (PaC ST + PaC main + PANA messages + PaC session + PRF= )

It is worth noting that those values includes 1846 LoCs which are common fu= nctionality to PaC and PAA.

Moreover, as I also explained in the e-mail we have a version for very cons= trained devices (sensor nodes). In particular we have a PaC implementation = for Contiki OS named PANATIKI (http://sourceforge.net/projects/panatiki) and the values are:

PANATIKI : 517 (PaC state machine) + 141 (PaC main program)

But again, please take into account this is just an open source implementat= ion and not a product. And, of course, running code is absolutely better th= an no code.

Regarding your comment "And, that doesn't include the code that must b= e added to PCP required to integrate PCP with PANA", please see slide = 12 in http= ://www.ietf.org/proceedings/86/slides/slides-86-pcp-17  .  Ju= st a 100 lines that includes "PCP Key derivation and export. Unix Sock= ets."  in the case of OpenPANA.



 

* The presence of an open source version of PANA is = a vote in its favor but that depends on whether that code is easily portabl= e to many environments. I think the OpenPANA implementation makes assumptio= ns about its runtime environment that aren't very portable. It assumes a multi-threaded environment with posix s= ockets and my runtime environment doesn't meet those requirements.


[Rafa] For example, PANATIKI does not assume multi-threaded environment wit= h posix sockets (it is an implementation for a sensor node after all). Btw,= there are two open source implementations OpenPANA/PANATIKI and CPANA.


 

To be fair, I don't think I've said anything here th= at wasn't already covered by Steve Hartman. But, I did review the code and = I agree with his conclusions.


[Rafa] As you can see, I already counter-argumented that analysis. In any c= ase, I will be in Berlin so any doubt you have about OpenPana/PANATIKI or j= ust implementating PANA, let me know and I will be more than happy to meet = and discuss.

Best regards.


 

-Ben McCann

 

-----Original Message-----

From: Alper Yegin [mailto:alper.yegin@yegin.org]

Sent: Thursday, July 18, 2013 4:34 AM

To: Ben McCann

Cc: Dave Thaler; pcp= @ietf.org

Subject: PANA misconceptions (was Re: [pcp] CONSENSU= S CALL on PCP

security)

 

Hello,

 

I'm afraid your below issues are based on misconcept= ions introduced by the = http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf slides.<= o:p>

We did address those misconceptions in several round= s, but it seems like some still linger.

 

PANA does not force clients to always have a session= , or always stay awake or connected.

 

If a client wants to get authenticated and generate = a 5 minute key, and afterwards sleep, detach, etc., it can very well do tha= t using PANA.

We can support that by simply setting the lifetime o= f the PANA SA to that short fix value, or letting the PANA SA timeout and e= xpire.

So, you can run PANA and have a 5 min SA, then have = no PANA activity for 23:55hrs, and then come back and do another PANA authe= ntication and have another 5min SA. No problems.

 

Therefore, there are no issues with mobile, and no i= ssues with server side resources.

 

After all, PANA is adopted by Zigbee Alliance. I don= 't think the deployment cases considered here are any more constrained than= theirs...

 

EAP-in-PCP provides a clean slate that's unencumbere= d by the design decisions and assumptions of an existing protocol (PANA).

 

 

Was there any other concern leading to your above st= atement?

 

Alper

 

 

 

 

 

 

 

 

 

On Jul 17, 2013, at 10:20 PM, Ben McCann wrote:=

 

1) Could you *live with* EAP-in-PCP? If not, state r= eason you would object.

 

 YES

 

2) Could you *live with* PANA? If not, state reason = you would object.

 

 Yes, but we really rather not use PANA. See be= low...

 

3) If you said yes to both 1 and 2, but have a stron= g preference between the two, which approach do you prefer and why?

 

We strongly prefer EAP-in-PCP for several reasons:

 

* PANA, as we understand it, is not mobile-friendly.= It requires the PCP client to *always* have an authenticated session activ= e and that is wasteful on mobile clients when the authentication rekey inte= rval is much shorter than the mapping lifetime. Margaret Wasserman captured this in slides 13 and 14 of her pres= entation = http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf. We beli= eve the *client* should decide when to authenticate (because it needs to cr= eate or refresh a mapping) because that lets the client optimize its use of the network and reduce its power = consumption.

 

We understand that a PCP server may need to send a m= essage to the client when no authenticated session is active. If no authent= icated session is active then we prefer the server send an UN-authenticated= "call home" message directing the client to authenticate and then the server can send its messages over the = authenticated channel. We recognize an attacker can induce the client to co= nnect to the server by forging an unauthenticated "call home" mes= sage. But, having done that, the client can ignore subsequent forged call home messages because it will already have a= n authenticated session. Worse case, an attacker can't make EAP-in-PCP cons= ume any more client resources than PANA does because PANA requires the clie= nt to always have an authenticated session available.

 

* PANA requires more server side resources. The auth= entication protocol should efficiently support 100,000's of clients on a la= rge PCP server. Why should the server continuously maintain authenticated s= essions with *every* client? Clients using 24 hour mapping lifetimes can be served by short authentication key = lifetime like, for example, 5 minutes. Let the client connect, authenticate= , program the mappings, and then let the authenticated session expire. Rins= e and repeat in 24 hours,. Client-driven authentication via EAP-in-PCP requires less resources on the server becaus= e the server can discard the authenticated session state once the key lifet= ime expires.

 

There was some discussion that PANA is preferable to= EAP-in-PCP because it supports "liveness testing". We don't beli= eve liveness testing is useful when the server resources consumed, per clie= nt, are PCP mappings. Checking the liveness of 100,000 clients is much more resource intensive on the server than just= keeping the client's mappings around until they expire naturally at the en= d of their lifetime. In short, we believe EAP-in-PCP will scale better on t= he server than PANA.

 

* We believe the decision to use EAP-in-PCP vs. PANA= is a choice between designing and implementing an EAP-in-PCP transport tha= t is tailored for PCP versus adapting an existing protocol (PANA) to fit th= e needs of PCP.  We don't think implementing an EAP-in-PCP transport is difficult so we prefer it over PANA. EAP-in-PCP= provides a clean slate that's unencumbered by the design decisions and ass= umptions of an existing protocol (PANA).

 

-Ben McCann

 

 

 

_______________________________________________=

pcp mailing list

pcp@ietf.org

https://www.ietf.org/mailman/listinfo/pcp

 

_______________________________________________=

pcp mailing list

pcp@ietf.org

https://www.ietf.org/mailman/listinfo/pcp


-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC) Faculty of Computer= Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------

 

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications = Engineering (DIIC)
Faculty of Computer Science-University of = Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +3486= 8884151 e-mail: rafa@um.es ------------------------------------------= -------------


 

--_000_9374F3A019050A4C805B8DEF27285BE40115E1A00ELWLMBX01olymp_-- From ancaz@cisco.com Tue Aug 6 10:53:25 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EB721E80B7 for ; Tue, 6 Aug 2013 10:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTfY3-HT2bJ6 for ; Tue, 6 Aug 2013 10:53:15 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 11E1D21E8098 for ; Tue, 6 Aug 2013 10:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=905; q=dns/txt; s=iport; t=1375811574; x=1377021174; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=dJRm8SNd4q+us2zp27BKf/RHgkl+YSeeAt6VB5h+7TQ=; b=d9+NrgESIkEm3kGYMtKdqOKM0GSaTFVfzdBoebAHM7j69S5h5mN9PazN XzbjHKl9VPwHNwnl88dHKUtWSrdpbOE4VzP6jmWnhBC1S4H32q2Ybj92X 7rP0o9qSwj1b8MVJx1x5eo0y063u6KnPdng0tZWGNAvPviDcvzWqnom2H I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQGAOo2AVKtJXG8/2dsb2JhbABagwY1UIJJvDSBHxZ0giQBAQEEHR00FwYBCBEEAQELFAU9HQgCBAESCIgIDLcKjlSBFTgGgxR0A5kLkCSBXoE5gXE5 X-IronPort-AV: E=Sophos;i="4.89,827,1367971200"; d="scan'208";a="244288219" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 06 Aug 2013 17:52:53 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r76HqrLm024344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 6 Aug 2013 17:52:53 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.38]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Tue, 6 Aug 2013 12:52:53 -0500 From: "Anca Zamfir (ancaz)" To: "Reinaldo Penno (repenno)" , "pcp@ietf.org" Thread-Topic: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) Thread-Index: AQHOks3GURn6Jbzx+U2OespBiGNxkA== Date: Tue, 6 Aug 2013 17:52:53 +0000 Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EE99C8E34@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.61.100.28] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 17:53:25 -0000 I support adoption as a WG document. thanks, -anca >-----Original Message----- >From: Reinaldo Penno (repenno) >Sent: Monday, July 29, 2013 3:52 PM >To: pcp@ietf.org >Subject: [pcp] WG Call for Adoption: Optimizing NAT and Firewall >Keepalives >Using Port Control Protocol (PCP) >Hello, >This email starts a 2-week consensus call on adopting "Optimizing NAT and >Firewall Keepalives Using Port Control Protocol (PCP)" as a WG item. > Title : Optimizing NAT and Firewall Keepalives Using Port >Control >Protocol (PCP) > Author(s) : T. Reddy et al > Filename : draft-reddy-pcp-optimize-keepalives-01 > URL : >http://tools.ietf.org/html/draft-reddy-pcp-optimize-keepalives-01 >Please read the current revision and state you opinion either for or >against adoption in the mailing list. >The call for adoption ends 12th August 2013. >Thanks, >Chairs From yoshihiro.ohba@toshiba.co.jp Tue Aug 6 16:08:21 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038F621E80BE for ; Tue, 6 Aug 2013 16:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.088 X-Spam-Level: X-Spam-Status: No, score=-8.088 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-FcKMpF2sOl for ; Tue, 6 Aug 2013 16:08:15 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 56C0921F9CA1 for ; Tue, 6 Aug 2013 16:08:14 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id r76N87t7006688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Aug 2013 08:08:07 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r76N87iB018143; Wed, 7 Aug 2013 08:08:07 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 579; Wed, 7 Aug 2013 08:08:07 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r76N87Mo018140; Wed, 7 Aug 2013 08:08:07 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id r76N870J020013; Wed, 7 Aug 2013 08:08:07 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id JAA20012; Wed, 7 Aug 2013 08:08:07 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id r76N8628022009; Wed, 7 Aug 2013 08:08:06 +0900 (JST) Received: from tgxml345.toshiba.local by toshiba.co.jp id r76N85Ni001838; Wed, 7 Aug 2013 08:08:05 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.59]) by tgxml345.toshiba.local ([133.199.60.32]) with mapi id 14.03.0146.000; Wed, 7 Aug 2013 08:08:05 +0900 From: To: , Thread-Topic: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP security) Thread-Index: AQHOkrkGvqpIwrQWL0Su43BUp5IKb5mIw+XQ Date: Tue, 6 Aug 2013 23:08:05 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B188405A9@tgxml338.toshiba.local> References: <9374F3A019050A4C805B8DEF27285BE40115E075A9@LWLMBX01.olympus.F5Net.com> <839332CA-66AD-48A5-AF0E-7AAD1964FE5F@yegin.org> <9374F3A019050A4C805B8DEF27285BE40115E08503@LWLMBX01.olympus.F5Net.com> <76B8454D-73F0-4E3D-81A6-55F121535901@um.es> <9374F3A019050A4C805B8DEF27285BE40115E08BCF@LWLMBX01.olympus.F5Net.com> <9374F3A019050A4C805B8DEF27285BE40115E1A00E@LWLMBX01.olympus.F5Net.com> In-Reply-To: <9374F3A019050A4C805B8DEF27285BE40115E1A00E@LWLMBX01.olympus.F5Net.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.196.20.231] msscp.transfermailtomossagent: 103 Content-Type: multipart/alternative; boundary="_000_674F70E5F2BE564CB06B6901FD3DD78B188405A9tgxml338toshiba_" MIME-Version: 1.0 Cc: pcp@ietf.org Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP security) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 23:08:21 -0000 --_000_674F70E5F2BE564CB06B6901FD3DD78B188405A9tgxml338toshiba_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Ben, PANA provides a protection mechanism for its cipher-suite parameters. The = protection mechanism is based on including the initial PAR and PAN messages= with =1B$B!F=1B(BS=1B$B!G=1B(B-bit set (these messages contains cipher-sui= te parameters) in the PANA_AUTH_KEY derivation algorithm. So, if a MiTM a= ttacker alters the cipher-suite parameters, the key won=1B$B!G=1B(Bt match = between legitimate PaC and PAA. On the other hand, EAP-in-PCP also defines= its cipher-suite parameters but without a protection mechanism for cipher-= suite parameters. I think this is a design flaw of EAP-in-PCP. Note that EAP methods that have their own cipher-suite negotiation mechanis= m also should provide their own protection mechanism for the cipher-suite p= arameters (like TLS-based EAP methods do as you pointed out), but this is a= separate issue that should not be mixed with EAP-lower layer issues. Yoshihiro Ohba From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Ben M= cCann Sent: Wednesday, August 07, 2013 12:24 AM To: Rafa Marin Lopez Cc: pcp@ietf.org Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP secur= ity) Hi Rafa, Thanks for clarifying the purpose of the PANA SA during the transmission of= the final EAP response packet. If I understand RFC 5191 correctly, the EAP= response packets are the last packets exchanged prior to the Access phase = of the PANA protocol so it makes sense they must be cryptographically bound= to the EAP master key to prevent MITM attacks. I=1B$B!G=1B(Bd not considered this in my earlier email because I was thinki= ng about the PCP packets that are sent after an SA is established. These PC= P packets (such as MAP requests) must include a signature derived from the = EAP MSK to prove they come from an authenticated peer. I think these PCP pa= ckets provide the same MITM defense as signing the EAP response packet does= in PANA. (They prove the sender knows the EAP MSK). I did not see why PANA= authentication had to cryptographically bind the PANA final response packe= t to the EAP MSK because subsequently transmitted PCP packets are also boun= d to the EAP MSK. So, I misunderstood the motivation for signing the final EAP response packe= t. I thought PANA was ensuring the integrity of the response payload instea= d of providing proof of knowledge of the MSK. That misunderstanding led me = to ask, should the authentication protocol (PANA or EAP-in-PCP) also ensure= the integrity of earlier authentication packets that negotiate cipher suit= es and other authentication protocol parameters? (I thought, if integrity c= hecking is required for the EAP response, then shouldn=1B$B!G=1B(Bt it be r= equired for earlier packets)? This is why I mentioned EAP-TTLS. I think tha= t protocol protects the entire EAP packet exchange using TLS. I wondered wh= ether EAP-TTLS provides sufficient integrity for the authentication exchang= e so we could avoid signing packets within the PCP authentication protocol. You asked whether I thought the consensus call was premature. Possibly so, = especially if we select PANA as the authentication protocol. I think PANA b= rings with it a set of security decisions, such as not signing the cipher s= uite parameters, that may be inappropriate for PCP. We can design EAP-in-PC= P while we finalize the PCP authentication security requirements and hence = arrive at a EAP-in-PCP design that meets those requirements. I don=1B$B!G= =1B(Bt think we have that flexibility if we select PANA because it has a pr= e-existing set of security requirements that may, or may not, be appropriat= e for PCP. In the absence of fully baked PCP security requirements, I prefe= r EAP-in-PCP because it is less defined than PANA. Last, I had previously read, and I just re-read, your post http://www.ietf.= org/mail-archive/web/pcp/current/msg02349.html. You state that implementing= an EAP lower layer is hard but your post doesn=1B$B!G=1B(Bt clearly explai= n that point. You mention interactions with EAP state machines and retransm= issions but you don=1B$B!G=1B(Bt explain why this is so hard that we absolu= tely need PANA. There are least two protocols (PANA and IKEv2) that manage = to transport EAP over IP so we have examples how to do this for EAP-in-PCP. -Ben McCann P.S. Vacation was great. Apologies for the late reply to your email. From: Rafa Marin Lopez [mailto:rafa@um.es] Sent: Sunday, July 21, 2013 7:44 PM To: Ben McCann Cc: pcp@ietf.org Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP secur= ity) Hi Ben: On Jul 19, 2013, at 2:55 AM, Ben McCann wrote: Hi Rafa, I incorrectly used a discussion about the suitability of the OpenPANA impl= ementation as an argument to defend my statement "EAP-in-PCP provides a cle= an slate that's unencumbered by the design decisions and assumptions of an = existing protocol (PANA).". That argument was a waste of time because the s= uitability or availability of a reference implementation is irrelevant to w= hether PANA was designed with a set of security considerations that are app= ropriate for PCP. This understanding of the security considerations is the = "clean slate" that is important to me. [Rafa] I must say I am a little bit confused about your general line of tho= ughts here. You started your arguments first saying about PANA is not mobil= e-friendly, then PANA consumes resources and then implementation problems o= r the liveliness test. Those are clearly misconceptions about PANA that we = have clarified. Now, "clean slate" is regarding security considerations. Ok= , let us discuss about security, but you may agree with me that this line o= f arguments might be a little bit confusing. For example, PANA negotiates its own security association so it can provide= data integrity for the final EAP response packet. That's fine, but where have we decided that PCP needs to secure the integri= ty of that response packet? (It probably should). [Rafa] The main purpose of the PANA SA does not have anything to do with pr= otecting the final EAP response packet. As many security protocols, it prov= ides key confirmation to bind authentication with the exported key material= by EAP. This is a cryptographic binding between the two layers. This ensu= res that same two entities participate not only performing EAP but also the= EAP lower-layer protocol. This is useful to avoid man-in-the-middle attack= s. Moreover it serves to avoid the attack you mention about ciphersuite and= authentication parameters below (see how PANA generates the PANA_AUTH_KEY)= . PANA does not secure the earlier EAP packets that carry parameters like the= cipher suite selection or authentication parameters for the selected EAP m= ethod. So, those could be compromised by an attacker. Where have we decided= that this is an acceptable risk for PCP? [Rafa] If you don't have any keys.... how are you supposed to protect anyth= ing? If we assume we are performing EAP for authentication and key managem= ent, we will not have any key material exported to any EAP lower-layer (e.g= . PCP or PANA) until EAP is successfully finished at the end. Moreover EAP= is designed to operate with no security assumption in the lower-layer. We haven't discussed that, but we implicitly agree to live with it if we mo= ve forward with PANA. (Or, at least, we accept that risk with some EAP meth= ods). [Rafa] See my comment above, there is no such a risk. Btw, what EAP methods= are you referring to? As I said EAP is designed to operate with no securit= y. I prefer EAP-in-PCP because it will make us think through those issues for = PCP. (We've made a good start in the auth requirements draft). [Rafa] About simplicity, how about this? Let assume that the only thing you= have to worry about at PCP level is to manage a pre-shared key between PCP= client and PCP server. That is simple, don't you think? Until we get those requirements down, I think it's premature to decide PANA= is the right choice. [Rafa] Then, do you think the consensus call is too premature? It might be, if we agree that PANA's security considerations are OK for PCP= . Or, we could decide that a simple EAP-in-PCP transport w/o *any* security= association is sufficient because we can leverage the security properties = of EAP methods such as EAP-TTLS to achieve the data integrity required for = the EAP protocol. [Rafa] Either or I don't understand your point or I think there is some con= fusion about EAP and its layers (see Fig. 1 and 2 in RFC 3748) EAP-TTLS is = a method and it will export keys to the EAP lower-layer . Why do you relate= EAP-TTLS with the protection of the EAP protocol ? In this regard, I also think there is a general misconception about EAP. Fo= r example, people may think that this is just tunneling EAP in PCP (I think= you even mentioned this in a previous e-mail). But it is not. RFC 3748 def= ines requirements for a correct EAP lower-layer. If we transport EAP in PCP= , PCP will become an EAP lower-layer according to the EAP standard. Conseq= uence is PCP has to follow requirements imposed by RFC 3748 and RFC 5247 to= be a correct EAP lower-layer. In other words, this means we will have to d= efine a new EAP lower-layer and to follow the same path we already followed= with PANA which is a RFC now. In other words, we are essentially re-invent= ing the wheel (I say this based also on experience since, at research level= , I have tried to design different EAP lower-layers... EAP-in-X, EAP-in-Y, = etc...). I would appreciate if you could read this link I sent to the list = about this aspect: http://www.ietf.org/mail-archive/web/pcp/current/msg023= 49.html The usage of PANA avoids to include all these aspects in PCP itself (PANA a= lready does it), and as a consequence the PCP security would be simplified = a lot. I'm vacation for two weeks and won't be in Berlin to continue this discussi= on face-to-face. Enjoy your vacations! -Ben McCann -----Original Message----- From: Rafa Marin Lopez [mailto:rafa@um.es] Sent: Thursday, July 18, 2013 5:31 PM To: Ben McCann Cc: pcp@ietf.org Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP secur= ity) Hi Ben: On Jul 18, 2013, at 7:00 PM, Ben McCann wrote: Thank you for clarifying that "PANA does not force clients to always have a= session, or always stay awake or connected". That, I believe, wasn't Margaret's point. PANA *supports* server side re-au= thentication even if the client doesn't think it's necessary. So, if the se= rver chooses, it can wake up the client by sending packets. That said, this= really isn't a legitimate criticism of the PANA protocol. It's an issue th= at can be addressed by proper programming or configuration of the PCP/PANA = server to make sure it doesn't unnecessarily re-authenticate the clients. So, I agree with you that PANA, on a properly configured server, can be as = "mobile friendly" and lightweight as EAP-in-PCP. My concerns about starting from a clean slate are based, in part, on Steve = Hartman's "Implementation Analysis: strong preference for PCP-specific appr= oach" (http://www.ietf.org/mail-archive/web/pcp/current/msg02324.html). His= arguments were persuasive (to me) and the counter-arguments were not. [Rafa] Why my answers in http://www.ietf.org/mail-archive/web/pcp/current/m= sg02349.html are not ok? I understand that implementation should not dictate protocol design but I t= hink we should let implementation *inform* protocol design. If I have to se= lect between two ways to define a protocol, and one of them is simpler to i= mplement, then I will tend to vote for the simpler option if all other crit= eria are equal. I see EAP-in-PCP as the simpler option even if there is sou= rce code for PANA. I've also reviewed the OpenPANA source code and I have some concerns that i= llustrate this point: * The PANA state machine includes 13 states with 22 separate input events. = That state machine has to be integrated with the simpler PCP state machine.= My intuition, based on too many years of experience, is that integrating t= he PANA and PCP state machines is tricky to implement, debug, and verify. T= hat complexity is, in part, because PANA already has a fairly complex state= machine. I don't believe EAP-in-PCP requires this much complexity. [Rafa] Ben, I have always assumed we all have experience in the area. In pa= rticular, I have been working on PANA since 2003 and I have done source cod= ing myself, I have been leading an open source PANA implementation and depl= oyed PANA in several EU projects, without any inconvenience so far. About the state machine, I can tell you that part of it is completely optio= nal. And about the integration between PANA and PCP, I disagree based on the exp= erience we got from http://www.ietf.org/proceedings/86/slides/slides-86-pcp= -17 * The OpenPANA implementation is about 6900 SLOCs long as measured by an sl= occount version 2.26. This seems like a lot of code (aka complexity) to tun= nel EAP packets over PCP. And, that doesn't include the code that must be a= dded to PCP required to integrate PCP with PANA. I believe an EAP-in-PCP im= plementation will be much simpler but, I admit, I don't have an implementat= ion to show you that proves that point. [Rafa] This number is completely wrong as I already explained in http://www= .ietf.org/mail-archive/web/pcp/current/msg02631.html (as you may observe th= is is a repeating conversation). You may agree with me that doing the slocc= ount over the entire package does not help too much. We need to be more sp= ecific. In the message I already sent, the discussion was about openpana-0.2.3. Rig= ht now, we have openpana-0.2.4 and we have new values. The following values= only show the LoC dedicated to PANA, not to EAP ST, EAP-Method or RADIUS c= lient since those values will be common to any other solution using EAP and= RADIUS. OpenPANA: The PAA: 3130 LoC (PAA ST + PAA main program + PANA messages + PAA session + PRF) The PaC 2720 (PaC ST + PaC main + PANA messages + PaC session + PRF) It is worth noting that those values includes 1846 LoCs which are common fu= nctionality to PaC and PAA. Moreover, as I also explained in the e-mail we have a version for very cons= trained devices (sensor nodes). In particular we have a PaC implementation = for Contiki OS named PANATIKI (http://sourceforge.net/projects/panatiki) an= d the values are: PANATIKI : 517 (PaC state machine) + 141 (PaC main program) But again, please take into account this is just an open source implementat= ion and not a product. And, of course, running code is absolutely better th= an no code. Regarding your comment "And, that doesn't include the code that must be add= ed to PCP required to integrate PCP with PANA", please see slide 12 in http= ://www.ietf.org/proceedings/86/slides/slides-86-pcp-17 . Just a 100 lines= that includes "PCP Key derivation and export. Unix Sockets." in the case = of OpenPANA. * The presence of an open source version of PANA is a vote in its favor but= that depends on whether that code is easily portable to many environments.= I think the OpenPANA implementation makes assumptions about its runtime en= vironment that aren't very portable. It assumes a multi-threaded environmen= t with posix sockets and my runtime environment doesn't meet those requirem= ents. [Rafa] For example, PANATIKI does not assume multi-threaded environment wit= h posix sockets (it is an implementation for a sensor node after all). Btw,= there are two open source implementations OpenPANA/PANATIKI and CPANA. To be fair, I don't think I've said anything here that wasn't already cover= ed by Steve Hartman. But, I did review the code and I agree with his conclu= sions. [Rafa] As you can see, I already counter-argumented that analysis. In any c= ase, I will be in Berlin so any doubt you have about OpenPana/PANATIKI or j= ust implementating PANA, let me know and I will be more than happy to meet = and discuss. Best regards. -Ben McCann -----Original Message----- From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Thursday, July 18, 2013 4:34 AM To: Ben McCann Cc: Dave Thaler; pcp@ietf.org Subject: PANA misconceptions (was Re: [pcp] CONSENSUS CALL on PCP security) Hello, I'm afraid your below issues are based on misconceptions introduced by the = http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf slides. We did address those misconceptions in several rounds, but it seems like so= me still linger. PANA does not force clients to always have a session, or always stay awake = or connected. If a client wants to get authenticated and generate a 5 minute key, and aft= erwards sleep, detach, etc., it can very well do that using PANA. We can support that by simply setting the lifetime of the PANA SA to that s= hort fix value, or letting the PANA SA timeout and expire. So, you can run PANA and have a 5 min SA, then have no PANA activity for 23= :55hrs, and then come back and do another PANA authentication and have anot= her 5min SA. No problems. Therefore, there are no issues with mobile, and no issues with server side = resources. After all, PANA is adopted by Zigbee Alliance. I don't think the deployment= cases considered here are any more constrained than theirs... EAP-in-PCP provides a clean slate that's unencumbered by the design decisio= ns and assumptions of an existing protocol (PANA). Was there any other concern leading to your above statement? Alper On Jul 17, 2013, at 10:20 PM, Ben McCann wrote: 1) Could you *live with* EAP-in-PCP? If not, state reason you would object. YES 2) Could you *live with* PANA? If not, state reason you would object. Yes, but we really rather not use PANA. See below... 3) If you said yes to both 1 and 2, but have a strong preference between th= e two, which approach do you prefer and why? We strongly prefer EAP-in-PCP for several reasons: * PANA, as we understand it, is not mobile-friendly. It requires the PCP cl= ient to *always* have an authenticated session active and that is wasteful = on mobile clients when the authentication rekey interval is much shorter th= an the mapping lifetime. Margaret Wasserman captured this in slides 13 and = 14 of her presentation http://www.ietf.org/proceedings/85/slides/slides-85-= pcp-17.pdf. We believe the *client* should decide when to authenticate (bec= ause it needs to create or refresh a mapping) because that lets the client = optimize its use of the network and reduce its power consumption. We understand that a PCP server may need to send a message to the client wh= en no authenticated session is active. If no authenticated session is activ= e then we prefer the server send an UN-authenticated "call home" message di= recting the client to authenticate and then the server can send its message= s over the authenticated channel. We recognize an attacker can induce the c= lient to connect to the server by forging an unauthenticated "call home" me= ssage. But, having done that, the client can ignore subsequent forged call = home messages because it will already have an authenticated session. Worse = case, an attacker can't make EAP-in-PCP consume any more client resources t= han PANA does because PANA requires the client to always have an authentica= ted session available. * PANA requires more server side resources. The authentication protocol sho= uld efficiently support 100,000's of clients on a large PCP server. Why sho= uld the server continuously maintain authenticated sessions with *every* cl= ient? Clients using 24 hour mapping lifetimes can be served by short authen= tication key lifetime like, for example, 5 minutes. Let the client connect,= authenticate, program the mappings, and then let the authenticated session= expire. Rinse and repeat in 24 hours,. Client-driven authentication via EA= P-in-PCP requires less resources on the server because the server can disca= rd the authenticated session state once the key lifetime expires. There was some discussion that PANA is preferable to EAP-in-PCP because it = supports "liveness testing". We don't believe liveness testing is useful wh= en the server resources consumed, per client, are PCP mappings. Checking th= e liveness of 100,000 clients is much more resource intensive on the server= than just keeping the client's mappings around until they expire naturally= at the end of their lifetime. In short, we believe EAP-in-PCP will scale b= etter on the server than PANA. * We believe the decision to use EAP-in-PCP vs. PANA is a choice between de= signing and implementing an EAP-in-PCP transport that is tailored for PCP v= ersus adapting an existing protocol (PANA) to fit the needs of PCP. We don= 't think implementing an EAP-in-PCP transport is difficult so we prefer it = over PANA. EAP-in-PCP provides a clean slate that's unencumbered by the des= ign decisions and assumptions of an existing protocol (PANA). -Ben McCann _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer= Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --_000_674F70E5F2BE564CB06B6901FD3DD78B188405A9tgxml338toshiba_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Ben,

 <= /o:p>

PANA p= rovides a protection mechanism for its cipher-suite parameters.  The p= rotection mechanism is based on including the initial PAR and PAN messages with =1B$B!F=1B(BS=1B$B!G=1B(B-bit set (these messages contains c= ipher-suite parameters) in the PANA_AUTH_KEY  derivation algorithm. &n= bsp;So, if a MiTM attacker alters the cipher-suite parameters, the key won= =1B$B!G=1B(Bt match between legitimate PaC and PAA.  On the other hand= , EAP-in-PCP also defines its cipher-suite parameters but without a protection mechanis= m for cipher-suite parameters.  I think this is a design flaw of EAP-i= n-PCP.

&= nbsp;

Note t= hat EAP methods that have their own cipher-suite negotiation mechanism also= should provide their own protection mechanism for the cipher-suite parameters (like TLS-based EAP methods do as you pointed out), but this is= a separate issue that should not be mixed with  EAP-lower layer issue= s.

&= nbsp;

Yoshih= iro Ohba

&= nbsp;

 <= /o:p>

 <= /o:p>

From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Ben McCann
Sent: Wednesday, August 07, 2013 12:24 AM
To: Rafa Marin Lopez
Cc: pcp@ietf.org
Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PC= P security)

 

Hi Rafa,

 

Thanks for clarifying the pur= pose of the PANA SA during the transmission of the final EAP response packet. If I understand RFC 5191 correctly, the EAP response pack= ets are the last packets exchanged prior to the Access phase of the PANA pr= otocol so it makes sense they must be cryptographically bound to the EAP ma= ster key to prevent MITM attacks.

 

I=1B$B!G=1B(Bd not considered= this in my earlier email because I was thinking about the PCP packets that are sent after an SA is established. These PCP pack= ets (such as MAP requests) must include a signature derived from the EAP MS= K to prove they come from an authenticated peer. I think these PCP packets = provide the same MITM defense as signing the EAP response packet does in PANA. (They prove the sender knows= the EAP MSK). I did not see why PANA authentication had to cryptographical= ly bind the PANA final response packet to the EAP MSK because subsequently = transmitted PCP packets are also bound to the EAP MSK.

 

So, I misunderstood the motiv= ation for signing the final EAP response packet. I thought PANA was ensuring the integrity of the response payload instead of provi= ding proof of knowledge of the MSK. That misunderstanding led me to ask, sho= uld the authentication protocol (PANA or EAP-in-PCP) also ensure the integrity of earlier authentication packets that neg= otiate cipher suites and other authentication protocol parameters? (I thoug= ht, if integrity checking is required for the EAP response, then shouldn=1B= $B!G=1B(Bt it be required for earlier packets)? This is why I mentioned EAP-TTLS. I think that protocol protects the entir= e EAP packet exchange using TLS. I wondered whether EAP-TTLS provides suffi= cient integrity for the authentication exchange so we could avoid signing p= ackets within the PCP authentication protocol.

 

You asked whether I thought t= he consensus call was premature. Possibly so, especially if we select PANA as the authentication protocol. I think PANA brings with it= a set of security decisions, such as not signing the cipher suite paramete= rs, that may be inappropriate for PCP. We can design EAP-in-PCP while we fina= lize the PCP authentication security requirements and hence arrive at a EAP= -in-PCP design that meets those requirements. I don=1B$B!G=1B(Bt think we h= ave that flexibility if we select PANA because it has a pre-existing set of security requirements that may, or may not, b= e appropriate for PCP. In the absence of fully baked PCP security requireme= nts, I prefer EAP-in-PCP because it is less defined than PANA.

 

Last, I had previously read, = and I just re-read, your post http://www.ietf.org/mail-archive/web/pcp/curren= t/msg02349.html. You state that implementin= g an EAP lower layer is hard but your post doesn=1B$B!G=1B(Bt clearly expla= in that point. You mention interactions with EAP state machines and retransmissions but you don=1B$B!G=1B(Bt explain why this is so hard that = we absolutely need PANA. There are least two protocols (PANA and IKEv2) tha= t manage to transport EAP over IP so we have examples how to do this for EA= P-in-PCP.

 

-Ben McCann

P.S. Vacation was great. Apologies for the late reply to your email.

 

 

From: Rafa Marin Lopez [mailto:rafa@um.es]
Sent: Sunday, July 21, 2013 7:44 PM
To: Ben McCann
Cc: pcp@ietf.org
Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PC= P security)

 

Hi Ben:

 

On Jul 19, 2013, at 2:55 AM, Ben McCann wrote:

 

Hi Rafa,

I incorrectly used a discussion about the suitability of the OpenPANA  = ;implementation as an argument to defend my statement "EAP-in-PCP prov= ides a clean slate that's unencumbered by the design decisions and assumpti= ons of an existing protocol (PANA).". That argument was a waste of time because the suitability or availability of a = reference implementation is irrelevant to whether PANA was designed with a = set of security considerations that are appropriate for PCP. This understan= ding of the security considerations is the "clean slate" that is important to me.<= /p>

 

[Rafa] I must say I am a little bit confused about= your general line of thoughts here. You started your arguments first sayin= g about PANA is not mobile-friendly, then PANA consumes resources and then implementation problems or the liveliness= test. Those are clearly misconceptions about PANA that we have clarified.&= nbsp;Now, "clean slate" is regarding security considerations. Ok,= let us discuss about security, but you may agree with me that this line of arguments might be a little bit confusing. =

 


For example, PANA negotiates its own security association so it can provide= data integrity for the final EAP response packet.

That's fine, but where have we decided that PCP ne= eds to secure the integrity of that response packet? (It probably should).<= o:p>

 

[Rafa] The main purpose of the PANA SA does n= ot have anything to do with protecting the final EAP response packet. As ma= ny security protocols, it provides key confirmation to bind authentication with the exported key material by EAP. This  i= s a cryptographic binding between the two layers. This ensures that same tw= o entities participate not only performing EAP but also the EAP lower-layer= protocol. This is useful to avoid man-in-the-middle attacks. Moreover it serves to avoid the attack you mention about cip= hersuite and authentication parameters below (see how PANA generates the PA= NA_AUTH_KEY). 

 

PANA does not secure the earlier EAP packets that = carry parameters like the cipher suite selection or authentication paramete= rs for the selected EAP method. So, those could be compromised by an attacker. Where have we decided that this is an= acceptable risk for PCP?

 

[Rafa] If you don't have any keys.... how are you = supposed to protect anything?  If we assume we are performing EAP for = authentication and key management, we will not have any key material exported to any EAP lower-layer (e.g. PCP or PAN= A) until EAP is successfully finished at the end.  Moreover EAP is des= igned to operate with no security assumption in the lower-layer. =

 

We haven't discussed that, but we implicitly agree= to live with it if we move forward with PANA. (Or, at least, we accept tha= t risk with some EAP methods).

 

[Rafa] See my comment above, there is no such a ri= sk. Btw, what EAP methods are you referring to? As I said EAP is desig= ned to operate with no security.

 


I prefer EAP-in-PCP because it will make us think through those issues for = PCP. (We've made a good start in the auth requirements draft).

 

[Rafa] About simplicity, how about this? Let assum= e that the only thing you have to worry about at PCP level is to manage a p= re-shared key between PCP client and PCP server. That is simple, don't you think?

 

Until we get those requirements down, I think it's= premature to decide PANA is the right choice.

 

[Rafa] Then, do you think the consensus call is to= o premature? 

 

It might be, if we agree that PANA's security cons= iderations are OK for PCP. Or, we could decide that a simple EAP-in-PCP tra= nsport w/o *any* security association is sufficient because we can leverage the security properties of EAP metho= ds such as EAP-TTLS to achieve the data integrity required for the EAP prot= ocol.

 

[Rafa] Either or I don't understand your point or = I think there is some confusion about EAP and its layers (see Fig. 1 and 2 = in RFC 3748) EAP-TTLS is a method and it will export keys to the EAP lower-layer . Why do you relate EAP-TTLS wi= th the protection of the EAP protocol ?

 

In this regard, I also think there is a general mi= sconception about EAP. For example, people may think that this is just tunn= eling EAP in PCP (I think you even mentioned this in a previous e-mail). But it is not. RFC 3748 defines requirements f= or a correct EAP lower-layer. If we transport EAP in PCP , PCP will become = an EAP lower-layer according to the EAP standard. Consequence is PCP has to= follow requirements imposed by RFC 3748 and RFC 5247 to be a correct EAP lower-layer. In other words, thi= s means we will have to define a new EAP lower-layer and to follow the same= path we already followed with PANA which is a RFC now. In other words, we = are essentially re-inventing the wheel (I say this based also on experience since, at research level, I hav= e tried to design different EAP lower-layers... EAP-in-X, EAP-in-Y, etc...)= . I would appreciate if you could read this link I sent to the list about t= his aspect:  http://www.ietf.org/mail-archive/web/pcp/current/msg02349= .html

 

The usage of PANA avoids to include all these aspe= cts in PCP itself (PANA already does it), and as a consequence the PCP secu= rity would be simplified a lot.

 


I'm vacation for two weeks and won't be in Berlin to continue this discussi= on face-to-face.

 

Enjoy your vacations!

 


-Ben McCann

-----Original Message-----
From: Rafa Marin Lopez [mailto:rafa@um.es= ]
Sent: Thursday, July 18, 2013 5:31 PM
To: Ben McCann
Cc: pcp@ietf.org
Subject: Re: [pcp] PANA misconceptions (was Re: CONSENSUS CALL on PCP secur= ity)

Hi Ben:

On Jul 18, 2013, at 7:00 PM, Ben McCann wrote:

Thank you for clarifying that "PANA does not = force clients to always have a session, or always stay awake or connected&q= uot;.

 

That, I believe, wasn't Margaret's point. PANA *su= pports* server side re-authentication even if the client doesn't think it's= necessary. So, if the server chooses, it can wake up the client by sending packets. That said, this really isn't= a legitimate criticism of the PANA protocol. It's an issue that can be add= ressed by proper programming or configuration of the PCP/PANA server to mak= e sure it doesn't unnecessarily re-authenticate the clients.

 

So, I agree with you that PANA, on a properly conf= igured server, can be as "mobile friendly" and lightweight as EAP= -in-PCP.

 

 

My concerns about starting from a clean slate are = based, in part, on Steve Hartman's "Implementation Analysis: strong pr= eference for PCP-specific approach" (http://www.ietf.org/mail-archive/= web/pcp/current/msg02324.html). His arguments were persuasive (to me) and the counter-arguments were not. =


[Rafa] Why my answers in http://www.ietf.org/mail-archive/web/pcp/current/msg02349.html are not = ok?

 

I understand that implementation should not dictat= e protocol design but I think we should let implementation *inform* protoco= l design. If I have to select between two ways to define a protocol, and one of them is simpler to implement, th= en I will tend to vote for the simpler option if all other criteria are equ= al. I see EAP-in-PCP as the simpler option even if there is source code for= PANA.

 

I've also reviewed the OpenPANA source code and I = have some concerns that illustrate this point:

 

* The PANA state machine includes 13 states with 2= 2 separate input events. That state machine has to be integrated with the s= impler PCP state machine. My intuition, based on too many years of experience, is that integrating the PANA and PC= P state machines is tricky to implement, debug, and verify. That complexity= is, in part, because PANA already has a fairly complex state machine. I do= n't believe EAP-in-PCP requires this much complexity.


[Rafa] Ben, I have always assumed we all have experience in the area. In pa= rticular, I have been working on PANA since 2003 and I have done source cod= ing myself, I have been leading an open source PANA implementation and depl= oyed PANA in several EU projects,  without any inconvenience so far.

About the state machine, I can tell you that part of it is completely optio= nal.

And about the integration between PANA and PCP, I disagree based on the exp= erience we got from http= ://www.ietf.org/proceedings/86/slides/slides-86-pcp-17

 

* The OpenPANA implementation is about 6900 SLOCs = long as measured by an sloccount version 2.26. This seems like a lot of cod= e (aka complexity) to tunnel EAP packets over PCP. And, that doesn't include the code that must be added to PCP req= uired to integrate PCP with PANA. I believe an EAP-in-PCP implementation wi= ll be much simpler but, I admit, I don't have an implementation to show you= that proves that point.


[Rafa] This number is completely wrong as I already explained in http://www.ietf.org/mail-archive/web/pcp/current/msg02631.html (as you = may observe this is a repeating conversation). You may agree with me that d= oing the sloccount  over the entire package does not help too much. We= need to be more specific.

In the message I already sent, the discussion was about openpana-0.2.3. Rig= ht now, we have openpana-0.2.4 and we have new values. The following values= only show the LoC dedicated to PANA, not to EAP ST, EAP-Method or RADIUS c= lient since those values will be common to any other solution using EAP and RADIUS.

OpenPANA:

The PAA:

3130 LoC (PAA ST + PAA main program + PANA messages + PAA sessi= on + PRF)

The PaC

2720 (PaC ST + PaC main + PANA messages + PaC session + PRF= )

It is worth noting that those values includes 1846 LoCs which are common fu= nctionality to PaC and PAA.

Moreover, as I also explained in the e-mail we have a version for very cons= trained devices (sensor nodes). In particular we have a PaC implementation = for Contiki OS named PANATIKI (http://sourceforge.net/projects/panatiki) and the values are:

PANATIKI : 517 (PaC state machine) + 141 (PaC main program)

But again, please take into account this is just an open source implementat= ion and not a product. And, of course, running code is absolutely better th= an no code.

Regarding your comment "And, that doesn't include the code that must b= e added to PCP required to integrate PCP with PANA", please see slide = 12 in http= ://www.ietf.org/proceedings/86/slides/slides-86-pcp-17  .  Ju= st a 100 lines that includes "PCP Key derivation and export. Unix Sock= ets."  in the case of OpenPANA.


 

* The presence of an open source version of PANA i= s a vote in its favor but that depends on whether that code is easily porta= ble to many environments. I think the OpenPANA implementation makes assumptions about its runtime environment th= at aren't very portable. It assumes a multi-threaded environment with posix= sockets and my runtime environment doesn't meet those requirements.


[Rafa] For example, PANATIKI does not assume multi-threaded environment wit= h posix sockets (it is an implementation for a sensor node after all). Btw,= there are two open source implementations OpenPANA/PANATIKI and CPANA.

 

To be fair, I don't think I've said anything here = that wasn't already covered by Steve Hartman. But, I did review the code an= d I agree with his conclusions.


[Rafa] As you can see, I already counter-argumented that analysis. In any c= ase, I will be in Berlin so any doubt you have about OpenPana/PANATIKI or j= ust implementating PANA, let me know and I will be more than happy to meet = and discuss.

Best regards.

 

-Ben McCann

 

-----Original Message-----

From: Alper Yegin [mailto:alper.yegin@yegin.org]

Sent: Thursday, July 18, 2013 4:34 AM

To: Ben McCann

Cc: Dave Thaler; pcp@ietf.org

Subject: PANA misconceptions (was Re: [pcp] CONSEN= SUS CALL on PCP

security)

 

Hello,

 

I'm afraid your below issues are based on misconce= ptions introduced by the = http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf slides.<= o:p>

We did address those misconceptions in several rou= nds, but it seems like some still linger.

 

PANA does not force clients to always have a sessi= on, or always stay awake or connected.

 

If a client wants to get authenticated and generat= e a 5 minute key, and afterwards sleep, detach, etc., it can very well do t= hat using PANA.

We can support that by simply setting the lifetime= of the PANA SA to that short fix value, or letting the PANA SA timeout and= expire.

So, you can run PANA and have a 5 min SA, then hav= e no PANA activity for 23:55hrs, and then come back and do another PANA aut= hentication and have another 5min SA. No problems.

 

Therefore, there are no issues with mobile, and no= issues with server side resources.

 

After all, PANA is adopted by Zigbee Alliance. I d= on't think the deployment cases considered here are any more constrained th= an theirs...

 

EAP-in-PCP provides a clean slate that's unencumbe= red by the design decisions and assumptions of an existing protocol (PANA).

 

 

Was there any other concern leading to your above = statement?

 

Alper

 

 

 

 

 

 

 

 

 

On Jul 17, 2013, at 10:20 PM, Ben McCann wrote:

 

1) Could you *live with* EAP-in-PCP? If not, state= reason you would object.

 

 YES

 

2) Could you *live with* PANA? If not, state reaso= n you would object.

 

 Yes, but we really rather not use PANA. See = below...

 

3) If you said yes to both 1 and 2, but have a str= ong preference between the two, which approach do you prefer and why?<= /o:p>

 

We strongly prefer EAP-in-PCP for several reasons:=

 

* PANA, as we understand it, is not mobile-friendl= y. It requires the PCP client to *always* have an authenticated session act= ive and that is wasteful on mobile clients when the authentication rekey interval is much shorter than the mapping li= fetime. Margaret Wasserman captured this in slides 13 and 14 of her present= ation = http://www.ietf.org/proceedings/85/slides/slides-85-pcp-17.pdf. We beli= eve the *client* should decide when to authenticate (because it needs to cr= eate or refresh a mapping) because that lets the client optimize its use of the network and reduce its power = consumption.

 

We understand that a PCP server may need to send a= message to the client when no authenticated session is active. If no authe= nticated session is active then we prefer the server send an UN-authenticated "call home" message directin= g the client to authenticate and then the server can send its messages over= the authenticated channel. We recognize an attacker can induce the client = to connect to the server by forging an unauthenticated "call home" message. But, having done that, the client can ignor= e subsequent forged call home messages because it will already have an auth= enticated session. Worse case, an attacker can't make EAP-in-PCP consume an= y more client resources than PANA does because PANA requires the client to always have an authenticated session available= .

 

* PANA requires more server side resources. The au= thentication protocol should efficiently support 100,000's of clients on a = large PCP server. Why should the server continuously maintain authenticated sessions with *every* client? Clients = using 24 hour mapping lifetimes can be served by short authentication key l= ifetime like, for example, 5 minutes. Let the client connect, authenticate,= program the mappings, and then let the authenticated session expire. Rinse and repeat in 24 hours,. Clien= t-driven authentication via EAP-in-PCP requires less resources on the serve= r because the server can discard the authenticated session state once the k= ey lifetime expires.

 

There was some discussion that PANA is preferable = to EAP-in-PCP because it supports "liveness testing". We don't be= lieve liveness testing is useful when the server resources consumed, per client, are PCP mappings. Checking the liveness of= 100,000 clients is much more resource intensive on the server than just ke= eping the client's mappings around until they expire naturally at the end o= f their lifetime. In short, we believe EAP-in-PCP will scale better on the server than PANA.

 

* We believe the decision to use EAP-in-PCP vs. PA= NA is a choice between designing and implementing an EAP-in-PCP transport t= hat is tailored for PCP versus adapting an existing protocol (PANA) to fit the needs of PCP.  We don't think = implementing an EAP-in-PCP transport is difficult so we prefer it over PANA= . EAP-in-PCP provides a clean slate that's unencumbered by the design decis= ions and assumptions of an existing protocol (PANA).

 

-Ben McCann

 

 

 

_______________________________________________

pcp mailing list

pcp@ietf.org

https://www.ietf.org/mailman/listinfo/pcp

 

_______________________________________________

pcp mailing list

pcp@ietf.org

https://www.ietf.org/mailman/listinfo/pcp


-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC) Faculty of Computer= Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------

 

= -------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications = Engineering (DIIC)
Faculty of Computer Science-University of = Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +3486= 8884151 e-mail: rafa@um.es ------------------------------------------= -------------

 

--_000_674F70E5F2BE564CB06B6901FD3DD78B188405A9tgxml338toshiba_-- From sureshk@juniper.net Tue Aug 6 17:20:55 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680FD11E80F3 for ; Tue, 6 Aug 2013 17:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbI-Jpo-VD0M for ; Tue, 6 Aug 2013 17:20:48 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id 28D8921F9B1B for ; Tue, 6 Aug 2013 17:20:48 -0700 (PDT) Received: from mail208-db8-R.bigfish.com (10.174.8.231) by DB8EHSOBE026.bigfish.com (10.174.4.89) with Microsoft SMTP Server id 14.1.225.22; Wed, 7 Aug 2013 00:20:47 +0000 Received: from mail208-db8 (localhost [127.0.0.1]) by mail208-db8-R.bigfish.com (Postfix) with ESMTP id 1B8A210018D for ; Wed, 7 Aug 2013 00:20:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: PS-28(zzbb2dI98dI9371I936eI1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de096h5eeeK8275dh1de097hz2fh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail208-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=sureshk@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(377424004)(189002)(199002)(243025003)(479174003)(377454003)(16406001)(81542001)(63696002)(4396001)(81342001)(31966008)(49866001)(66066001)(83072001)(36756003)(80022001)(47736001)(77982001)(59766001)(15202345003)(50986001)(56776001)(65816001)(47976001)(76176001)(53806001)(77096001)(51856001)(74366001)(79102001)(54356001)(56816003)(80976001)(74876001)(76796001)(76786001)(69226001)(74662001)(19580405001)(19580385001)(83322001)(46102001)(19580395003)(76482001)(47446002)(74706001)(54316002)(74502001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB020; H:BL2PR05MB018.namprd05.prod.outlook.com; CLIP:66.129.224.50; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail208-db8 (localhost.localdomain [127.0.0.1]) by mail208-db8 (MessageSwitch) id 1375834845976194_10343; Wed, 7 Aug 2013 00:20:45 +0000 (UTC) Received: from DB8EHSMHS014.bigfish.com (unknown [10.174.8.233]) by mail208-db8.bigfish.com (Postfix) with ESMTP id E131620049 for ; Wed, 7 Aug 2013 00:20:45 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS014.bigfish.com (10.174.4.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 7 Aug 2013 00:20:45 +0000 Received: from BL2PR05MB020.namprd05.prod.outlook.com (10.255.228.152) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.341.1; Wed, 7 Aug 2013 00:20:45 +0000 Received: from BL2PR05MB018.namprd05.prod.outlook.com (10.255.228.145) by BL2PR05MB020.namprd05.prod.outlook.com (10.255.228.152) with Microsoft SMTP Server (TLS) id 15.0.731.16; Wed, 7 Aug 2013 00:20:43 +0000 Received: from BL2PR05MB018.namprd05.prod.outlook.com ([169.254.5.245]) by BL2PR05MB018.namprd05.prod.outlook.com ([169.254.5.178]) with mapi id 15.00.0731.000; Wed, 7 Aug 2013 00:20:43 +0000 From: Suresh Kumar Vinapamula Venkata To: "pcp@ietf.org" Thread-Topic: New Version Notification for draft-vinapamula-softwire-dslite-prefix-binding-00.txt Thread-Index: AQHOkwP0+MMNR4kjF0K6YI7/RrwIgg== Date: Wed, 7 Aug 2013 00:20:42 +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.3.2.130206 x-originating-ip: [66.129.224.50] x-forefront-prvs: 0931CB1479 Content-Type: text/plain; charset="us-ascii" Content-ID: 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% Subject: Re: [pcp] New Version Notification for draft-vinapamula-softwire-dslite-prefix-binding-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 00:20:55 -0000 Dear All,=20 Please refer to the issue#4 discussed in the document http://tools.ietf.org/agenda/87/slides/slides-87-pcp-14.pdf (slide 6). This is further discussed in the below draft. Please review and comment. -Suresh > >On 7/29/13 10:27 AM, "internet-drafts@ietf.org" >wrote: > >> >>A new version of I-D, >>draft-vinapamula-softwire-dslite-prefix-binding-00.txt >>has been successfully submitted by Suresh Vinapamula and posted to the >>IETF repository. >> >>Filename: draft-vinapamula-softwire-dslite-prefix-binding >>Revision: 00 >>Title: Recommendation for Prefix Binding in the Softwire DS-Lite >>Context >>Creation date: 2013-07-29 >>Group: Individual Submission >>Number of pages: 5 >>URL: =20 >>http://www.ietf.org/internet-drafts/draft-vinapamula-softwire-dslite-pref >>i >>x-binding-00.txt >>Status: =20 >>http://datatracker.ietf.org/doc/draft-vinapamula-softwire-dslite-prefix-b >>i >>nding >>Htmlized: =20 >>http://tools.ietf.org/html/draft-vinapamula-softwire-dslite-prefix-bindin >>g >>-00 >> >> >>Abstract: >> This document describes possible issues induced by the change of the >> B4 IPv6 address and sketches a set of recommendations. >> >> =20 >> =20 >> >> >>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. >> >>The IETF Secretariat >> >> >> > From internet-drafts@ietf.org Tue Aug 6 23:51:59 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C59C21E80DA; Tue, 6 Aug 2013 23:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKiV3-fTGUPB; Tue, 6 Aug 2013 23:51:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B472B21E80EF; Tue, 6 Aug 2013 23:51:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70p1 Message-ID: <20130807065141.7574.64502.idtracker@ietfa.amsl.com> Date: Tue, 06 Aug 2013 23:51:41 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-dhcp-08.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 06:51:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Port Control Protocol Working Group of th= e IETF. Title : DHCP Options for the Port Control Protocol (PCP) Author(s) : Mohamed Boucadair Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-dhcp-08.txt Pages : 9 Date : 2013-08-06 Abstract: This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) Server IP addresses. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenario. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-dhcp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-dhcp-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-dhcp-08 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 dthaler@microsoft.com Wed Aug 7 13:54:49 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E9721E8131 for ; Wed, 7 Aug 2013 13:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnVidKRyLWEG for ; Wed, 7 Aug 2013 13:54:45 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8C87721E8119 for ; Wed, 7 Aug 2013 13:54:29 -0700 (PDT) Received: from BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) by BY2PR03MB607.namprd03.prod.outlook.com (10.255.93.38) with Microsoft SMTP Server (TLS) id 15.0.745.25; Wed, 7 Aug 2013 20:39:24 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) with Microsoft SMTP Server (TLS) id 15.0.745.25; Wed, 7 Aug 2013 20:38:01 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.126]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.126]) with mapi id 15.00.0745.000; Wed, 7 Aug 2013 20:38:01 +0000 From: Dave Thaler To: "mohamed.boucadair@orange.com" , "pcp@ietf.org" , "draft-ietf-pcp-server-selection@tools.ietf.org" Thread-Topic: Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6SN4UBylvrgKNiQjOEzEfANBzc7AAMCTHwAFEmB5A= Date: Wed, 7 Aug 2013 20:38:00 +0000 Message-ID: <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::be] x-forefront-prvs: 0931CB1479 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(51704005)(189002)(199002)(69226001)(53806001)(16406001)(74876001)(79102001)(74316001)(49866001)(47736001)(4396001)(15202345003)(81542001)(74662001)(76482001)(47446002)(31966008)(81342001)(80976001)(56776001)(74706001)(77096001)(54316002)(54356001)(74502001)(47976001)(56816003)(80022001)(65816001)(77982001)(74366001)(51856001)(59766001)(63696002)(50986001)(46102001)(19580395003)(83072001)(19580385001)(76576001)(33646001)(76796001)(76786001)(83322001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB270; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::be; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 03 X-MS-Exchange-CrossPremises-AuthSource: BY2PR03MB269.namprd03.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 2001:4898:80e8:ed31::be X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: BY2PR03MB270.namprd03.prod.outlook.com X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 20:54:49 -0000 Med wrote: > >1) Needs to remove mention of names and just use addresses. The DHCP > > option is being changed per WG discussion. But even before the DHCP > > option, we had the default router list (see RFC 6887 section 8.1) wh= ich > > is a list of IP's with no name known. >=20 > [Med] IMHO, the dhcp discussion should not impact the consensus the wg > had on the definition of the name. A name can be configured using a varie= ty > of means (manually, device management protocol, etc.). The PCP server > selection draft does not make any assumption on how the names are > configured. Following dhc recommendations, the name is first resolved and > then its results are conveyed in the dhcp option as IP addresses. The server selection document needs to not assume there are any names. For example, it needs to be relevant in the case of the default router list as explained in RFC 6887. There is no need to complicate this draft with a discussion of names. > >2) Document assumes that > > "PCP requests to different servers are independent, the result of a > > PCP request to one server does not influence another" > >We currently have no WG consensus on this. Some (e.g., Stuart) have > >argued that it's the responsibility of the server to interact with > >other redundant servers managed by the same entity. Since no one has > >given any counter argument, that should be the starting point. >=20 > [Med] I don't get the point here. The document makes one design > assumption which is: if multiple names are configured to the pcp clients,= this > is a hint multiple servers are to be contacted simultaneously. If only on= e > name is configured (which may result in one or multiple IP addresses), on= ly > one IP address will be used to contact that pcp server. The case of > "redundant" server as you say, will means that multiple IP addresses are > configured to the pcp client as being bound to the same PCP server. No, "redundant" servers here means multiple servers managed by the same entity. > As > currently defined in the document, the pcp client will never sent multipl= e > request to multiple addresses pointing to the same pcp server. What is > wrong with that rationale? The point is that we have no WG consensus to send to multiple PCP servers managed by the same entity. And if you only send to any one of them, then I think you don't need to distinguish which IPs belong to which server= s. (You still have to distinguish between PCP server IPs managed by different entities, e.g. on different networks.) > > 3) There needs to be a step where the selection algorithm takes a > >source address into account, if the app specified one. Consider the > >case of sending a PEER after establishing a TCP connection. The source > >address of the TCP connection should constrain the PCP server selection > >mechanism so you don't try sending PEER messages on some other > network > >than the one the TCP connection is on. >=20 > [Med] Yes, I agree. If we had a provisioning data per interface, then we = can > re-use what we had in the dhcp draft: >=20 > "A host may have multiple network interfaces (e.g., 3G, WiFi, etc.); each > configured differently. Each PCP server learned MUST be associated with t= he > interface via which it was learned." >=20 > The problem is if the pcp server address is configured manually for examp= le, > the interface to which it is bound may not be available. We can set whatever requirements we want here. I think we should apply the same requirement as you quote, to all cases including manually configured servers. That is, you have to configure a server in the context of some ne= twork. > >4) The server selection is still missing a lot of details on how an > >address is selected. E.g.: > > * Is it assumed that the addresses of the same server are already order= ed > > by the configuration mechanism? (I think there's no need for such > >assumption) >=20 > [Med] There is no need for such preference. This can be explicitly indica= ted > in the text. >=20 > > * Should RFC 6724 sorting be done on them by the client? (I think so) >=20 > [Med] Why do you think we need more than what we have in > http://tools.ietf.org/html/rfc6887#section-8.4? Because that section is about multiple interfaces (and multiple source addr= esses). My question here is about sorting destination addresses of PCP servers, eve= n if you have only one interface and source address. > > * If you're trying to use PCP on an IPv4 mapping should you prefer > >IPv4 or not > > for PCP server addresses? >=20 > [Med] Why? Remember NAT64 is reachable using IPv6 but it assigns external > IPv4 addresses. The rationale adopted in the document does not need to > enter into such details: multiple names means multiple servers, one name > means one pcp server (that can be reached with multiple IP addresses). For an IPv4 mapping, RFC 6887 says the internal address is the source IP of= the PCP message, unless THIRD_PARTY is used. So if you're trying to use PCP on an IPv4 mapping, and you use an IPv4 address of a PCP server then you can use the correct source IP and don't need THIRD_PARTY. If you instead try IPv6 first, then the internal address of the mapping wil= l be different from the source IP of the PCP message and you'd have to use THIRD_PARTY which may or may not be permitted. Hence I think we need to explicitly say to prefer IPv4 PCP server addresses when affecting IPv4 mappings. =20 > > * Should a client do RFC 6724 to choose among servers, if point 2 is > >addressed > > by just using one? >=20 > [Med] Isn't this covered in http://tools.ietf.org/html/rfc6887#section-8.= 4? No, it isn't as explained above. -Dave From Ted.Lemon@nominum.com Wed Aug 7 13:58:08 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3510921E80A9 for ; Wed, 7 Aug 2013 13:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eqn3AlUIXyHw for ; Wed, 7 Aug 2013 13:58:01 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 236A721F9BD8 for ; Wed, 7 Aug 2013 13:58:01 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUgK02EWnyBthsQ224Q6i/hFTjs6T25Wg@postini.com; Wed, 07 Aug 2013 13:58:01 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9DFC11B8288 for ; Wed, 7 Aug 2013 13:58:00 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 97825190060; Wed, 7 Aug 2013 13:58:00 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Wed, 7 Aug 2013 13:57:54 -0700 From: Ted Lemon To: Dave Thaler Thread-Topic: [pcp] Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6SN4UBylvrgKNiQjOEzEfANBzc7AAMCTHwAFEmB5AAD8zuAA== Date: Wed, 7 Aug 2013 20:57:53 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> In-Reply-To: <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-pcp-server-selection@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 20:58:08 -0000 With respect to multiple interfaces, I think it's safe to rely on whatever = mechanism MIF comes up with. Doing a one-off mechanism just for PCP is mo= re likely to make things worse than better. From dthaler@microsoft.com Wed Aug 7 15:02:13 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A5121E8139 for ; Wed, 7 Aug 2013 15:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+GdGPI+5fhe for ; Wed, 7 Aug 2013 15:02:08 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0AB21E80A9 for ; Wed, 7 Aug 2013 15:02:07 -0700 (PDT) Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) with Microsoft SMTP Server (TLS) id 15.0.745.25; Wed, 7 Aug 2013 21:16:47 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.126]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.126]) with mapi id 15.00.0745.000; Wed, 7 Aug 2013 21:16:47 +0000 From: Dave Thaler To: Ted Lemon Thread-Topic: [pcp] Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6SN4UBylvrgKNiQjOEzEfANBzc7AAMCTHwAFEmB5AAD8zuAAAOFskA Date: Wed, 7 Aug 2013 21:16:46 +0000 Message-ID: References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::be] x-forefront-prvs: 0931CB1479 x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(377454003)(51704005)(189002)(199002)(16406001)(53806001)(69226001)(74876001)(4396001)(79102001)(47736001)(49866001)(74316001)(81542001)(54356001)(31966008)(81342001)(47446002)(74662001)(74502001)(76482001)(80976001)(54316002)(56816003)(77096001)(56776001)(74706001)(63696002)(50986001)(80022001)(65816001)(77982001)(59766001)(74366001)(51856001)(19580405001)(46102001)(47976001)(76576001)(83072001)(19580395003)(33646001)(83322001)(76786001)(76796001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB272; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::be; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 03 X-MS-Exchange-CrossPremises-AuthSource: BY2PR03MB269.namprd03.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 2001:4898:80e8:ed31::be X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: BY2PR03MB272.namprd03.prod.outlook.com Cc: "draft-ietf-pcp-server-selection@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 22:02:13 -0000 > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Wednesday, August 7, 2013 1:58 PM > To: Dave Thaler > Cc: mohamed.boucadair@orange.com; pcp@ietf.org; draft-ietf-pcp-server- > selection@tools.ietf.org > Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 >=20 > With respect to multiple interfaces, I think it's safe to rely on whateve= r > mechanism MIF comes up with. Doing a one-off mechanism just for PCP is > more likely to make things worse than better. Yes, but MIF won't say how things apply to other protocols. To steal a MIF= term, each "PVD element" (which PCP people can think of as any piece of info conf= igured in the context of a particular network) has to say how to handle multiple i= nterfaces, i.e. which category it's in as the MIF WG meeting discussed. E.g., pick on= e,=20 use all, or whatever else. PCP has to specify at least what category it's= in. -Dave From Ted.Lemon@nominum.com Wed Aug 7 19:05:17 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B69F21F995B for ; Wed, 7 Aug 2013 19:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQdJ0ol61Y1R for ; Wed, 7 Aug 2013 19:05:10 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id 52F7F21F9A3D for ; Wed, 7 Aug 2013 19:05:08 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKUgL80y1BCC/jl8geICoJqFzAW7uq7tjj@postini.com; Wed, 07 Aug 2013 19:05:08 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 468201B827D for ; Wed, 7 Aug 2013 19:05:07 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3FEAF190060; Wed, 7 Aug 2013 19:05:07 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 7 Aug 2013 19:05:07 -0700 From: Ted Lemon To: Dave Thaler Thread-Topic: [pcp] Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6SN4UBylvrgKNiQjOEzEfANBzc7AAMCTHwAFEmB5AAD8zuAAAOFskA///lHYA= Date: Thu, 8 Aug 2013 02:05:06 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-pcp-server-selection@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 02:05:17 -0000 On Aug 7, 2013, at 5:16 PM, Dave Thaler wrote: > Yes, but MIF won't say how things apply to other protocols. To steal a M= IF term, > each "PVD element" (which PCP people can think of as any piece of info co= nfigured > in the context of a particular network) has to say how to handle multiple= interfaces, > i.e. which category it's in as the MIF WG meeting discussed. E.g., pick = one,=20 > use all, or whatever else. PCP has to specify at least what category it= 's in. It seems pretty straightforward to me that if you are attempting to connect= to a host in the context of PVD x, you use the PCP server associated with = PVD x. If there is no PCP server associated with PVD x, then you do not u= se PCP within that PVD. From dthaler@microsoft.com Wed Aug 7 19:10:36 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC1C21F99ED for ; Wed, 7 Aug 2013 19:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-Zw3fnt5Wyx for ; Wed, 7 Aug 2013 19:10:30 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id 2673211E8196 for ; Wed, 7 Aug 2013 19:10:27 -0700 (PDT) Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 8 Aug 2013 02:10:16 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.126]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.126]) with mapi id 15.00.0745.000; Thu, 8 Aug 2013 02:10:16 +0000 From: Dave Thaler To: Ted Lemon Thread-Topic: [pcp] Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6SN4UBylvrgKNiQjOEzEfANBzc7AAMCTHwAFEmB5AAD8zuAAAOFskA///lHYCAAHUBcA== Date: Thu, 8 Aug 2013 02:10:15 +0000 Message-ID: <3e7fd3c6a757446f8269079cecfffea0@BY2PR03MB269.namprd03.prod.outlook.com> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::be] x-forefront-prvs: 093290AD39 x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(24454002)(377454003)(51704005)(199002)(189002)(69226001)(16406001)(54356001)(74876001)(4396001)(79102001)(47736001)(49866001)(74316001)(81542001)(81342001)(31966008)(74662001)(47446002)(74502001)(76482001)(54316002)(56776001)(53806001)(80976001)(56816003)(77096001)(74706001)(50986001)(47976001)(80022001)(65816001)(77982001)(59766001)(74366001)(51856001)(63696002)(46102001)(19580395003)(19580405001)(33646001)(83072001)(76796001)(76576001)(76786001)(83322001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB271; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::be; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 03 X-MS-Exchange-CrossPremises-AuthSource: BY2PR03MB269.namprd03.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 2001:4898:80e8:ed31::be X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: BY2PR03MB271.namprd03.prod.outlook.com Cc: "draft-ietf-pcp-server-selection@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 02:10:36 -0000 > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Wednesday, August 7, 2013 7:05 PM > To: Dave Thaler > Cc: mohamed.boucadair@orange.com; pcp@ietf.org; draft-ietf-pcp-server- > selection@tools.ietf.org > Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 >=20 > On Aug 7, 2013, at 5:16 PM, Dave Thaler wrote: > > Yes, but MIF won't say how things apply to other protocols. To steal > > a MIF term, each "PVD element" (which PCP people can think of as any > > piece of info configured in the context of a particular network) has > > to say how to handle multiple interfaces, i.e. which category it's in a= s the > MIF WG meeting discussed. E.g., pick one, > > use all, or whatever else. PCP has to specify at least what category = it's in. >=20 > It seems pretty straightforward to me that if you are attempting to conne= ct > to a host in the context of PVD x, you use the PCP server associated with= PVD > x. If there is no PCP server associated with PVD x, then you do not use= PCP > within that PVD. Not quite. PVD x can have zero or more PCP servers, each of which has 1 or more IP add= resses. So If you are attempting to connect to a host in the context of PVD x, you = use the PCP server IP address list associated with PVD x, and you select among them= using . However, that only handles the PEER case. In the MAP case, an application = isn't trying to connect, it's trying to listen. And it might be listening within= PVD x, or it might be trying to listen within "all" PVDs (using a socket with a wildc= ard bind)... and whether that works or not is still TBD. But if it is supported, then= =20 draft-ietf-pcp-server-selection needs to make sure this is covered too. -Dave From Ted.Lemon@nominum.com Wed Aug 7 19:14:29 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDD511E8146 for ; Wed, 7 Aug 2013 19:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+qJrC28Lc0d for ; Wed, 7 Aug 2013 19:14:22 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 923FE11E80F6 for ; Wed, 7 Aug 2013 19:14:22 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUgL+/mBOGX5E20ZGb2lYBxSApKgloPJ0@postini.com; Wed, 07 Aug 2013 19:14:22 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0B4801B8288 for ; Wed, 7 Aug 2013 19:14:22 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id DEB6D190060; Wed, 7 Aug 2013 19:14:21 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Wed, 7 Aug 2013 19:14:21 -0700 From: Ted Lemon To: Dave Thaler Thread-Topic: [pcp] Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6SN4UBylvrgKNiQjOEzEfANBzc7AAMCTHwAFEmB5AAD8zuAAAOFskA///lHYCAAHUBcP//jZOA Date: Thu, 8 Aug 2013 02:14:20 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775249F48@mbx-01.win.nominum.com> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> <3e7fd3c6a757446f8269079cecfffea0@BY2PR03MB269.namprd03.prod.outlook.com> In-Reply-To: <3e7fd3c6a757446f8269079cecfffea0@BY2PR03MB269.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-pcp-server-selection@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 02:14:29 -0000 On Aug 7, 2013, at 10:10 PM, Dave Thaler wrote: > PVD x can have zero or more PCP servers, each of which has 1 or more IP a= ddresses. Okay, so how does the client know which PCP server to use? From dthaler@microsoft.com Wed Aug 7 19:21:42 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E0A21F9B1B for ; Wed, 7 Aug 2013 19:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGUBaQNJAdr7 for ; Wed, 7 Aug 2013 19:21:35 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id 0299021F9A19 for ; Wed, 7 Aug 2013 19:21:34 -0700 (PDT) Received: from BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) by BY2PR03MB092.namprd03.prod.outlook.com (10.255.241.160) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 8 Aug 2013 02:21:32 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 8 Aug 2013 02:21:31 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.126]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.126]) with mapi id 15.00.0745.000; Thu, 8 Aug 2013 02:21:30 +0000 From: Dave Thaler To: Ted Lemon Thread-Topic: [pcp] Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6SN4UBylvrgKNiQjOEzEfANBzc7AAMCTHwAFEmB5AAD8zuAAAOFskA///lHYCAAHUBcP//jZOAgAB1A1A= Date: Thu, 8 Aug 2013 02:21:30 +0000 Message-ID: References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> <3e7fd3c6a757446f8269079cecfffea0@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249F48@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775249F48@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::be] x-forefront-prvs: 093290AD39 x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(24454002)(377454003)(51704005)(189002)(199002)(69226001)(53806001)(77096001)(16406001)(74876001)(79102001)(74316001)(47736001)(49866001)(4396001)(81542001)(74662001)(76482001)(47446002)(31966008)(81342001)(80976001)(56776001)(54316002)(74706001)(54356001)(74502001)(47976001)(56816003)(80022001)(65816001)(77982001)(74366001)(51856001)(59766001)(63696002)(83072001)(46102001)(50986001)(19580395003)(76576001)(33646001)(19580405001)(76796001)(76786001)(83322001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB270; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::be; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 03 X-MS-Exchange-CrossPremises-AuthSource: BY2PR03MB269.namprd03.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 2001:4898:80e8:ed31::be X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: BY2PR03MB270.namprd03.prod.outlook.com X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: "draft-ietf-pcp-server-selection@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 02:21:42 -0000 p> -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Wednesday, August 7, 2013 7:14 PM > To: Dave Thaler > Cc: mohamed.boucadair@orange.com; pcp@ietf.org; draft-ietf-pcp-server- > selection@tools.ietf.org > Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 >=20 > On Aug 7, 2013, at 10:10 PM, Dave Thaler wrote: > > PVD x can have zero or more PCP servers, each of which has 1 or more IP > addresses. >=20 > Okay, so how does the client know which PCP server to use? That's what draft-ietf-pcp-server-selection is supposed to specify. If you buy Stuart's argument that communicating with just one IP address pe= r PVD is sufficient (and that server is then responsible for syncing with any= others as needed), then I would expect the algorithm might be something like: If app wants to affect an IPv4 mapping, sort IPv4 server IP's from that PVD per RFC 6724, and try them one by one until one responds. If app wants to affect an IPv6 mapping, sort IPv6 server IP's from that PVD per RFC 6724, and try them one by one until one responds. -Dave From Ted.Lemon@nominum.com Wed Aug 7 19:40:49 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF7021F9301 for ; Wed, 7 Aug 2013 19:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDNGyClG+Anb for ; Wed, 7 Aug 2013 19:40:42 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 99D7921F9B92 for ; Wed, 7 Aug 2013 19:40:39 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUgMFJ2TzgbT0hGVgt3cpKQHMqNmw1USB@postini.com; Wed, 07 Aug 2013 19:40:39 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D9DE11B827D for ; Wed, 7 Aug 2013 19:40:38 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D2401190060; Wed, 7 Aug 2013 19:40:38 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Wed, 7 Aug 2013 19:40:26 -0700 From: Ted Lemon To: Dave Thaler Thread-Topic: [pcp] Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6SN4UBylvrgKNiQjOEzEfANBzc7AAMCTHwAFEmB5AAD8zuAAAOFskA///lHYCAAHUBcP//jZOAgAB1A1D//5JHAA== Date: Thu, 8 Aug 2013 02:40:25 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775249FC6@mbx-01.win.nominum.com> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> <3e7fd3c6a757446f8269079cecfffea0@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249F48@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <0895CF5C565B7148AF207B75B79D6FF6@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-pcp-server-selection@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 02:40:49 -0000 On Aug 7, 2013, at 10:21 PM, Dave Thaler wrote: > That's what draft-ietf-pcp-server-selection is supposed to specify. Okay, but this draft is talking about multi-homing, and that would only req= uire one PCP server per PVD. From praspati@cisco.com Thu Aug 8 03:29:52 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CEA21E8095 for ; Thu, 8 Aug 2013 03:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARvx5D1cfWkP for ; Thu, 8 Aug 2013 03:29:47 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A7B1D11E8103 for ; Thu, 8 Aug 2013 03:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=901; q=dns/txt; s=iport; t=1375957788; x=1377167388; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=VO2VYviChET4OMyWJ/hNgfkaW5yZ3Ba4TSLtT0r2QGE=; b=G0FPg1vHvIg/x49pSyahS1hGlfizCavY9Xkn8sK1af98F7YIgl8V2uBf 0Upacdq/usoynqmYSo4E5CzBScrB5MgTYl/75O8Kyyhye4j1TN4eyResr Z3bwEBN7GSJlp2YMe3tqBsQLMBTNeftyQSbiy0zQsQffcYaXI0n3wbkru A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUFAAhyA1KtJXG//2dsb2JhbABbgwY1UIJNu3yBGhZ0giYBBAEBARodNB0BCCIUBTILJQIEARIIiAgMuHCOVYEVOIMadAOZC5AlgV+BOYFxOQ X-IronPort-AV: E=Sophos;i="4.89,838,1367971200"; d="scan'208";a="241956630" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 08 Aug 2013 10:29:47 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r78ATlvL021126 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 8 Aug 2013 10:29:47 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.106]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Thu, 8 Aug 2013 05:29:46 -0500 From: "Prashanth Patil (praspati)" To: "Reinaldo Penno (repenno)" , "pcp@ietf.org" Thread-Topic: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) Thread-Index: AQHOlCIzI4RISEINAEO1x/QJQVAugg== Date: Thu, 8 Aug 2013 10:29:45 +0000 Message-ID: In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090E81CE@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.68.16.2] Content-Type: text/plain; charset="us-ascii" Content-ID: <66DC127E6B5B0645BFC70DE2A6A2B56A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 10:29:52 -0000 I support adoption of this draft (as a co-author). -Prashanth On 29/07/13 3:52 PM, "Reinaldo Penno (repenno)" wrote: >Hello, > >This email starts a 2-week consensus call on adopting "Optimizing NAT and >Firewall Keepalives Using Port Control Protocol (PCP)" as a WG item. > > Title : Optimizing NAT and Firewall Keepalives Using Port Control >Protocol (PCP) > Author(s) : T. Reddy et al > Filename : draft-reddy-pcp-optimize-keepalives-01 > URL : >http://tools.ietf.org/html/draft-reddy-pcp-optimize-keepalives-01 > >Please read the current revision and state you opinion either for or >against adoption in the mailing list. > >The call for adoption ends 12th August 2013. > >Thanks, > >Chairs > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From tireddy@cisco.com Thu Aug 8 06:23:05 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063E721E8083 for ; Thu, 8 Aug 2013 06:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta9QN7m4-eKh for ; Thu, 8 Aug 2013 06:22:59 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 26E0121F99FB for ; Thu, 8 Aug 2013 06:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1916; q=dns/txt; s=iport; t=1375968179; x=1377177779; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=z4J2glrGFzKa2fHzfTp/Hjw4lBWLUKvUlxlRLWkONK4=; b=jdGfT5J8uu++XB9iJfByuTpIOVOwEVH+2FS55pQdMAancxLVhoRXRZSK NJ2XTuknM64ZD7XWyk8bI8aBiB4nlkHMUelZtfMI9JWbJwtBLuXEF1MqM Mz1D6q7Wst66oJjXTkYweQQxSOnn+CVvleopYsNch1cyj0PEiI6h5ay6j g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFANGaA1KtJXG//2dsb2JhbABbgwaBBb5IgRoWdIIkAQEBBDo/DAQCAQgOAwQBAQsUCQcyFAkIAQEEAQ0FCIgIuGePajEHBoMUdAOpMIMYgio X-IronPort-AV: E=Sophos;i="4.89,839,1367971200"; d="scan'208";a="245004615" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 08 Aug 2013 13:22:58 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r78DMw8n004235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Aug 2013 13:22:58 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Thu, 8 Aug 2013 08:22:58 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Dave Thaler , Ted Lemon Thread-Topic: [pcp] Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6SN4UBylvrgKNiQjOEzEfANBzc7AAMCTHwAFEmB5AAD8zuAAAOFskAAAMVB9A= Date: Thu, 8 Aug 2013 13:22:57 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1900EF70@xmb-rcd-x10.cisco.com> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.65.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-pcp-server-selection@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 13:23:05 -0000 > -----Original Message----- > From: Dave Thaler [mailto:dthaler@microsoft.com] > Sent: Thursday, August 08, 2013 2:47 AM > To: Ted Lemon > Cc: mohamed.boucadair@orange.com; pcp@ietf.org; draft-ietf-pcp-server- > selection@tools.ietf.org > Subject: RE: [pcp] Comments on draft-ietf-pcp-server-selection-01 >=20 > > -----Original Message----- > > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > > Sent: Wednesday, August 7, 2013 1:58 PM > > To: Dave Thaler > > Cc: mohamed.boucadair@orange.com; pcp@ietf.org; draft-ietf-pcp-server- > > selection@tools.ietf.org > > Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 > > > > With respect to multiple interfaces, I think it's safe to rely on whate= ver > > mechanism MIF comes up with. Doing a one-off mechanism just for PCP i= s > > more likely to make things worse than better. >=20 > Yes, but MIF won't say how things apply to other protocols. To steal a M= IF > term, > each "PVD element" (which PCP people can think of as any piece of info > configured > in the context of a particular network) has to say how to handle multiple > interfaces, > i.e. which category it's in as the MIF WG meeting discussed. E.g., pick = one, > use all, or whatever else. PCP has to specify at least what category it= 's > in. I think it's "use all" for certain use-cases; For example if we consider ho= st with MIF (Wifi, 3G from different administrative domains) there will be = two PVD elements, let's say each PVD is associated with one PCP server; App= lications like WebRTC would communicate with both PCP servers in each PVD t= o find the server-reflexive candidates, advertize them in offer/answer. Bas= ed on ICE connectivity check results, one of the interfaces would be select= ed for media session. If it is MPRTP both the interfaces could be selected = for the media session. --Tiru. >=20 > -Dave From tireddy@cisco.com Thu Aug 8 06:45:48 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCBB21E80AE for ; Thu, 8 Aug 2013 06:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkXmTjXZuSEz for ; Thu, 8 Aug 2013 06:45:43 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B58DE21E80A9 for ; Thu, 8 Aug 2013 06:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1892; q=dns/txt; s=iport; t=1375969542; x=1377179142; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=J+5xuXFomRDYeTJMpMnQJZDUD+q6DMikXPwosIFpbMw=; b=C1mxnHIIvOJbih5lNMcitDhAGB8DutoQAVFfgDLFnarz4HNZvWE4vzrg cuweaEDfkKZeatPnqeGowAfzuNKUX96fWk1NQMIq1Ca3i3UUdreoZDRy4 C7T3kuGen2qf8RFyRMn0Ub9QPtn4MBz7O7RLxdTJW0+J2msGEsvuBivQA s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAC6gA1KtJV2Z/2dsb2JhbABbgwY1UL5IgRkWdIIkAQEBAwE6PwUHBAIBCA4DBAEBAQoUCQcyFAkIAgQBDQUIiAIGDLhnj2oxBwaDFHQDmQuQJYMYgio X-IronPort-AV: E=Sophos;i="4.89,839,1367971200"; d="scan'208";a="245110339" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 08 Aug 2013 13:45:41 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r78Djfdp018231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Aug 2013 13:45:41 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 8 Aug 2013 08:45:41 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Dave Thaler , Ted Lemon Thread-Topic: [pcp] Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6SN4UBylvrgKNiQjOEzEfANBzc7AAMCTHwAFEmB5AAD8zuAAAOFskA///lHYCAAHUBcP//jZOAgAB1A1CAAC9dQA== Date: Thu, 8 Aug 2013 13:45:40 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1900EFA0@xmb-rcd-x10.cisco.com> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> <3e7fd3c6a757446f8269079cecfffea0@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249F48@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.65.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-pcp-server-selection@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 13:45:48 -0000 > -----Original Message----- > From: Dave Thaler [mailto:dthaler@microsoft.com] > Sent: Thursday, August 08, 2013 7:52 AM > To: Ted Lemon > Cc: mohamed.boucadair@orange.com; pcp@ietf.org; draft-ietf-pcp-server- > selection@tools.ietf.org > Subject: RE: [pcp] Comments on draft-ietf-pcp-server-selection-01 >=20 > p> -----Original Message----- > > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > > Sent: Wednesday, August 7, 2013 7:14 PM > > To: Dave Thaler > > Cc: mohamed.boucadair@orange.com; pcp@ietf.org; draft-ietf-pcp-server- > > selection@tools.ietf.org > > Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 > > > > On Aug 7, 2013, at 10:10 PM, Dave Thaler wrote: > > > PVD x can have zero or more PCP servers, each of which has 1 or more = IP > > addresses. > > > > Okay, so how does the client know which PCP server to use? >=20 > That's what draft-ietf-pcp-server-selection is supposed to specify. >=20 > If you buy Stuart's argument that communicating with just one IP address = per If we consider the use-case http://tools.ietf.org/html/draft-ietf-pcp-serve= r-selection-01#appendix-A.1 there will be one PVD and two PCP server IP add= resses. If the ICE agent has ICE lite implementation, then it will have to = communicate with both the PCP controlled firewalls to permit incoming ICE c= onnectivity checks.=20 --Tiru. > PVD is sufficient (and that server is then responsible for syncing with a= ny > others > as needed), then I would expect the algorithm might be something like: >=20 > If app wants to affect an IPv4 mapping, sort IPv4 server IP's from that P= VD > per RFC 6724, and try them one by one until one responds. >=20 > If app wants to affect an IPv6 mapping, sort IPv6 server IP's from that P= VD > per RFC 6724, and try them one by one until one responds. >=20 > -Dave From dthaler@microsoft.com Thu Aug 8 07:28:33 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E6E11E81A7 for ; Thu, 8 Aug 2013 07:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.033 X-Spam-Level: X-Spam-Status: No, score=-101.033 tagged_above=-999 required=5 tests=[AWL=2.566, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRNjd4ui-4JM for ; Thu, 8 Aug 2013 07:28:29 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id F390611E812A for ; Thu, 8 Aug 2013 07:28:28 -0700 (PDT) Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 8 Aug 2013 14:28:26 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.126]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.126]) with mapi id 15.00.0745.000; Thu, 8 Aug 2013 14:28:26 +0000 From: Dave Thaler To: "Tirumaleswar Reddy (tireddy)" , Ted Lemon Thread-Topic: [pcp] Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6SN4UBylvrgKNiQjOEzEfANBzc7AAMCTHwAFEmB5AAD8zuAAAOFskA///lHYCAAHUBcP//jZOAgAB1A1CAAC9dQIAATVqw Date: Thu, 8 Aug 2013 14:28:25 +0000 Message-ID: <694128ccd41842df95f28fc29b7e0413@BY2PR03MB269.namprd03.prod.outlook.com> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> <3e7fd3c6a757446f8269079cecfffea0@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249F48@mbx-01.win.nominum.com> <913383AAA69FF945B8F946018B75898A1900EFA0@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A1900EFA0@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.135.4.20] x-forefront-prvs: 093290AD39 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(51704005)(24454002)(51856001)(74366001)(46102001)(80022001)(66066001)(65816001)(59766001)(77982001)(19580385001)(83322001)(33646001)(83072001)(19580395003)(76786001)(81686001)(76796001)(76576001)(47976001)(47736001)(49866001)(4396001)(15202345003)(79102001)(74316001)(81542001)(69226001)(74876001)(16406001)(53806001)(54356001)(56776001)(54316002)(56816003)(77096001)(63696002)(74706001)(50986001)(47446002)(80976001)(74662001)(76482001)(31966008)(81342001)(74502001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB272; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:50.135.4.20; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 03 X-MS-Exchange-CrossPremises-AuthSource: BY2PR03MB269.namprd03.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 50.135.4.20 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1 X-OrganizationHeadersPreserved: BY2PR03MB272.namprd03.prod.outlook.com Cc: "draft-ietf-pcp-server-selection@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 14:28:33 -0000 Tiru wrote: [...] > > If you buy Stuart's argument that communicating with just one IP > > address per >=20 > If we consider the use-case http://tools.ietf.org/html/draft-ietf-pcp-ser= ver- > selection-01#appendix-A.1 there will be one PVD and two PCP server IP > addresses. If the ICE agent has ICE lite implementation, then it will hav= e to > communicate with both the PCP controlled firewalls to permit incoming ICE > connectivity checks. That's an interesting assertion but you didn't give any justification. Stuart asserted that communicating with one is sufficient, and simpler for = the=20 client, because it's the PCP server's job to communicate with the other one= s to permit incoming ICE connectivity checks. If you disagree with that, please respond with a technical argument as to why having the client communicate with both is better than having one server communicate=20 with the other. -Dave From Ted.Lemon@nominum.com Thu Aug 8 07:41:26 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980AE21F9B66 for ; Thu, 8 Aug 2013 07:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igV7SLTgb4jO for ; Thu, 8 Aug 2013 07:41:12 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id D27CE11E81DE for ; Thu, 8 Aug 2013 07:41:06 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUgOt/zRn9Qr0bD5D62l/3DyJCKF81FLd@postini.com; Thu, 08 Aug 2013 07:41:06 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4AD071B8290 for ; Thu, 8 Aug 2013 07:41:03 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 977A4190060; Thu, 8 Aug 2013 07:41:02 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 8 Aug 2013 07:41:02 -0700 From: Ted Lemon To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [pcp] Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6SN4UBylvrgKNiQjOEzEfANBzc7AAMCTHwAFEmB5AAD8zuAAAOFskA///lHYCAAHUBcP//jZOAgAB1A1CAAC9dQIAALECA Date: Thu, 8 Aug 2013 14:41:01 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077524B544@mbx-01.win.nominum.com> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> <3e7fd3c6a757446f8269079cecfffea0@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249F48@mbx-01.win.nominum.com> <913383AAA69FF945B8F946018B75898A1900EFA0@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A1900EFA0@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <59BFF49D52A1D648BA3EF5CA8EE3386F@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-pcp-server-selection@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 14:41:27 -0000 On Aug 8, 2013, at 9:45 AM, "Tirumaleswar Reddy (tireddy)" wrote: > If we consider the use-case http://tools.ietf.org/html/draft-ietf-pcp-ser= ver-selection-01#appendix-A.1 there will be one PVD and two PCP server IP a= ddresses. If the ICE agent has ICE lite implementation, then it will have t= o communicate with both the PCP controlled firewalls to permit incoming ICE= connectivity checks.=20 I would expect this to be two provisioning domains, not one. That's certa= inly the way we're currently talking about it in the MIF architecture doc. From tireddy@cisco.com Sun Aug 11 20:20:11 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A75821F9E7E for ; Sun, 11 Aug 2013 20:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svUHxgIncQlw for ; Sun, 11 Aug 2013 20:20:06 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C0CFA21F9D2E for ; Sun, 11 Aug 2013 20:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2441; q=dns/txt; s=iport; t=1376277185; x=1377486785; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/DH+Fb+llBTedN6sRfH9OY8RvcTwjxMmSYEeUVYEjMM=; b=co671ADD81jr0WxBMOFap6bZrM+8N5lB4iNfZ1IVk2Ru1IoiKfhG8YdF 3PCMzgInW1dwSqSlWmNwiAdCwQ653b++LDkLGneV5PSJIA8ppFLZl/yug eGEw7thlPlwGg2tVRD9Is2/LrBt8sCKLpkF+SqiDYQ04E7UlmkOcSUuy7 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAFVSCFKtJV2Z/2dsb2JhbABagwY1UL5VgRsWdIIkAQEBBDo/DAQCAQgOAwQBAQEKFAkHMhQJCAIEAQ0FCIgIDLVQkAoxBwaDFXYDmRCQJYMbgio X-IronPort-AV: E=Sophos;i="4.89,859,1367971200"; d="scan'208";a="245881585" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 12 Aug 2013 03:12:56 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7C3Cu7g005082 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Aug 2013 03:12:56 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Sun, 11 Aug 2013 22:12:56 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Dave Thaler , Ted Lemon Thread-Topic: [pcp] Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6SN4UBylvrgKNiQjOEzEfANBzc7AAMCTHwAFEmB5AAD8zuAAAOFskA///lHYCAAHUBcP//jZOAgAB1A1CAAC9dQIAATVqw//+h86A= Date: Mon, 12 Aug 2013 03:12:55 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A190100D9@xmb-rcd-x10.cisco.com> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> <3e7fd3c6a757446f8269079cecfffea0@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249F48@mbx-01.win.nominum.com> <913383AAA69FF945B8F946018B75898A1900EFA0@xmb-rcd-x10.cisco.com> <694128ccd41842df95f28fc29b7e0413@BY2PR03MB269.namprd03.prod.outlook.com> In-Reply-To: <694128ccd41842df95f28fc29b7e0413@BY2PR03MB269.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.43.209] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-pcp-server-selection@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 03:20:11 -0000 Hi Dave, Please see inline > -----Original Message----- > From: Dave Thaler [mailto:dthaler@microsoft.com] > Sent: Thursday, August 08, 2013 7:58 PM > To: Tirumaleswar Reddy (tireddy); Ted Lemon > Cc: mohamed.boucadair@orange.com; pcp@ietf.org; draft-ietf-pcp-server- > selection@tools.ietf.org > Subject: RE: [pcp] Comments on draft-ietf-pcp-server-selection-01 >=20 >=20 > Tiru wrote: > [...] > > > If you buy Stuart's argument that communicating with just one IP > > > address per > > > > If we consider the use-case http://tools.ietf.org/html/draft-ietf-pcp- > server- > > selection-01#appendix-A.1 there will be one PVD and two PCP server IP > > addresses. If the ICE agent has ICE lite implementation, then it will h= ave > to > > communicate with both the PCP controlled firewalls to permit incoming I= CE > > connectivity checks. >=20 > That's an interesting assertion but you didn't give any justification. >=20 > Stuart asserted that communicating with one is sufficient, and simpler fo= r the > client, because it's the PCP server's job to communicate with the other o= nes > to permit incoming ICE connectivity checks. If you disagree with that, > please respond with a technical argument as to why having the client > communicate with both is better than having one server communicate > with the other. Comparing the two approaches: [1] PCP client will have to handle both the scenarios http://tools.ietf.org= /html/draft-ietf-pcp-server-selection-01#appendix-A.1 (where both the Firew= alls are managed by the same administrative domain) and http://tools.ietf.o= rg/html/draft-patil-pcp-multihoming-00#section-5.1 (Network managed Firewal= l provided by each ISP). For the latter scenario PCP client would have to c= ommunicate with both the firewalls and there is no way for FW1 or FW2 to ta= lk to each other.=20 So if PCP client would already have the logic to handle multiple PCP-contro= lled Firewalls why make a special treatment just for http://tools.ietf.org/= html/draft-ietf-pcp-server-selection-01#appendix-A.1 ? [2] If it's compared with your suggestion then the PCP client will send all= the PCP requests to only one of the routers (let's say rtr1 in appendix-A.= 1); rtr1 based on the source IP address of the PCP request will have to for= ward the request again to rtr2 causing additional delay, processing overhea= d. -Tiru. >=20 > -Dave From tireddy@cisco.com Sun Aug 11 22:43:00 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8278C11E80FC for ; Sun, 11 Aug 2013 22:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fw2ik1BsNnbn for ; Sun, 11 Aug 2013 22:42:55 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 674C321E80A1 for ; Sun, 11 Aug 2013 22:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3407; q=dns/txt; s=iport; t=1376285714; x=1377495314; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RqHhCoMPYL4xzrM6ZVxoUoBEGy9PZoOw7u3XyURupuk=; b=BotMe4PLfnZn1W3mNTwnodplVCJSglTuG0II7PLkMob4qEi43mHSBxth T2YJ2c5q1fMP6ov4To5j2t9h8n0HBcw7pzjWxa8ClBQVHnKRj23vla+AL QtbIHZqkuo7bwSCPoX6AtnHynYBMvdAb6KHKxJLJMA2cV3M6F+z+281/2 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAOdyCFKtJXG9/2dsb2JhbABZgwY1UL5VgRoWdIIkAQEBAgI6PQ4EAgEIEQEDAQELFAkHMhQDBggCBAESCAGIBwy1VY8LfzgGgxV2A5kQkCWBYYE6gWlB X-IronPort-AV: E=Sophos;i="4.89,859,1367971200"; d="scan'208";a="246125578" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 12 Aug 2013 05:35:13 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7C5ZD72025219 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Aug 2013 05:35:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 00:35:13 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Suresh Kumar Vinapamula Venkata , "pcp@ietf.org" Thread-Topic: [pcp] New Version Notification for draft-vinapamula-softwire-dslite-prefix-binding-00.txt Thread-Index: AQHOk6BWft4hVQbid0e2qbPIabDZjpmM+XMg Date: Mon, 12 Aug 2013 05:35:12 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1901012D@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.43.209] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] New Version Notification for draft-vinapamula-softwire-dslite-prefix-binding-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 05:43:00 -0000 Hi Suresh, Interesting problem.=20 Comments: [1] Any specific reason for mentioning EIM, EIF in section 3 ? I mean PCP server always show the behavior of EIM, EIF. [2] Step 2 in section 4; I think SP already track the number of flows, bandwidth utilization, conges= tion caused by the subscriber etc using architecture like Policy Charging a= nd control (PCC).=20 clarify why any new policy changes are required to track subscribers becaus= e of DS-lite ? [3] The other way to solve the problem could be store B4 address in stable = storage to handle router reload/crashes etc [4]=20 a) For CPE WAN IPv6 prefix change - would there be a "make before break" sc= enario for prefix re-numbering ? b) Step 4 - How different is this problem when compared with pure-IPv6 only= devices ? [5] Provide more details on why mappings cannot be re-used with the IPv6 addres= s change (but with no prefix change) and the need to clear mappings. What is the problem in associating existing IPv4 mappings with a new IPv6 a= ddress derived from the same prefix ? [6] Step 6 in Section 4 - clarify what do mean by "clear all resources in u= se" ? (Are you referring to resetting the TCP connections ?) [7] Include reference to security considerations given in http://tools.ietf= .org/html/draft-ietf-pcp-dslite-00 clarify what you mean by "active softwires per subscriber" in step 1 of= section 4 and default value of 1 ? clarify what you mean by "stable prefix" ? Cheers, -Tiru. > -----Original Message----- > From: Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net] > Sent: Wednesday, August 07, 2013 5:51 AM > To: pcp@ietf.org > Subject: Re: [pcp] New Version Notification for draft-vinapamula-softwire= - > dslite-prefix-binding-00.txt >=20 > Dear All, >=20 > Please refer to the issue#4 discussed in the document > http://tools.ietf.org/agenda/87/slides/slides-87-pcp-14.pdf (slide 6). > This is further discussed in the below draft. >=20 > Please review and comment. >=20 > -Suresh >=20 > > > >On 7/29/13 10:27 AM, "internet-drafts@ietf.org" > >wrote: > > > >> > >>A new version of I-D, > >>draft-vinapamula-softwire-dslite-prefix-binding-00.txt > >>has been successfully submitted by Suresh Vinapamula and posted to the > >>IETF repository. > >> > >>Filename: draft-vinapamula-softwire-dslite-prefix-binding > >>Revision: 00 > >>Title: Recommendation for Prefix Binding in the Softwire DS-Lite > >>Context > >>Creation date: 2013-07-29 > >>Group: Individual Submission > >>Number of pages: 5 > >>URL: > >>http://www.ietf.org/internet-drafts/draft-vinapamula-softwire-dslite-pr= ef > >>i > >>x-binding-00.txt > >>Status: > >>http://datatracker.ietf.org/doc/draft-vinapamula-softwire-dslite-prefix= -b > >>i > >>nding > >>Htmlized: > >>http://tools.ietf.org/html/draft-vinapamula-softwire-dslite-prefix-bind= in > >>g > >>-00 > >> > >> > >>Abstract: > >> This document describes possible issues induced by the change of the > >> B4 IPv6 address and sketches a set of recommendations. > >> > >> > >> > >> > >> > >>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. > >> > >>The IETF Secretariat > >> > >> > >> > > >=20 >=20 From mohamed.boucadair@orange.com Sun Aug 11 23:18:39 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E79721F9C8E for ; Sun, 11 Aug 2013 23:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbZLgA21BEe9 for ; Sun, 11 Aug 2013 23:18:34 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 27E3321E809E for ; Sun, 11 Aug 2013 23:08:56 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id AD3672DC1FE; Mon, 12 Aug 2013 08:08:54 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 9174B27C054; Mon, 12 Aug 2013 08:08:54 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 12 Aug 2013 08:08:54 +0200 From: To: Dave Thaler , "pcp@ietf.org" , "draft-ietf-pcp-server-selection@tools.ietf.org" Date: Mon, 12 Aug 2013 08:08:53 +0200 Thread-Topic: Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6SN4UBylvrgKNiQjOEzEfANBzc7AAMCTHwAFEmB5AA3RyvEA== Message-ID: <94C682931C08B048B7A8645303FDC9F36EEC7E96C2@PUEXCB1B.nanterre.francetelecom.fr> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> In-Reply-To: <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.12.24535 Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 06:18:39 -0000 Hi Dave, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Dave Thaler [mailto:dthaler@microsoft.com] >Envoy=E9=A0: mercredi 7 ao=FBt 2013 22:38 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN; pcp@ietf.org; draft-ietf-pcp-server- >selection@tools.ietf.org >Objet=A0: RE: Comments on draft-ietf-pcp-server-selection-01 > >Med wrote: >> >1) Needs to remove mention of names and just use addresses. The DHCP >> > option is being changed per WG discussion. But even before the DHC= P >> > option, we had the default router list (see RFC 6887 section 8.1) >which >> > is a list of IP's with no name known. >> >> [Med] IMHO, the dhcp discussion should not impact the consensus the wg >> had on the definition of the name. A name can be configured using a >variety >> of means (manually, device management protocol, etc.). The PCP server >> selection draft does not make any assumption on how the names are >> configured. Following dhc recommendations, the name is first resolved an= d >> then its results are conveyed in the dhcp option as IP addresses. > >The server selection document needs to not assume there are any names. >For example, it needs to be relevant in the case of the default router lis= t >as explained in RFC 6887. There is no need to complicate this draft with >a discussion of names. > >> >2) Document assumes that >> > "PCP requests to different servers are independent, the result of = a >> > PCP request to one server does not influence another" >> >We currently have no WG consensus on this. Some (e.g., Stuart) have >> >argued that it's the responsibility of the server to interact with >> >other redundant servers managed by the same entity. Since no one has >> >given any counter argument, that should be the starting point. >> >> [Med] I don't get the point here. The document makes one design >> assumption which is: if multiple names are configured to the pcp clients= , >this >> is a hint multiple servers are to be contacted simultaneously. If only >one >> name is configured (which may result in one or multiple IP addresses), >only >> one IP address will be used to contact that pcp server. The case of >> "redundant" server as you say, will means that multiple IP addresses are >> configured to the pcp client as being bound to the same PCP server. > >No, "redundant" servers here means multiple servers managed by the same >entity. [Med] This is deployment-specific. The assumption you made in your initial = comment is not so that easy to honor. I don't think it is safe to make depl= oyment assumption on behalf of an administrative entity. Synchronization st= ate among servers managing the same or distinct function may not so that si= mple. Think about configurations such as domain hosting:=20 * one or multiple nat64 provisioned to IPv6-only hosts * one or multiple nptv6 provisioned to IPv6-only and dual stack hosts * one or multiple nat44 provisioned to IPv4-only and dual stack hosts * one or multiple IPv4 fw=20 * one or multiple IPv6 fw * multiple flow-based access routers * one or many port range routers * etc. > >> As >> currently defined in the document, the pcp client will never sent >multiple >> request to multiple addresses pointing to the same pcp server. What is >> wrong with that rationale? > >The point is that we have no WG consensus to send to multiple PCP servers >managed by the same entity. [Med] BTW, I don't remember when and where this is issue was raised. This d= esign was in the dhcp draft since January 2012 and it was inherited by the = pcp-server selection draft.=20 And if you only send to any one of them, >then I think you don't need to distinguish which IPs belong to which >servers. [Med] Assuming that an administrative entity will need to return only one I= P address is deployment-specific. I disagree with putting this constraint t= he administrative entities. The protocol should avoid making deployment-spe= cific assumptions. From mohamed.boucadair@orange.com Sun Aug 11 23:24:25 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB89F21E80A5 for ; Sun, 11 Aug 2013 23:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSB22vpiG7TV for ; Sun, 11 Aug 2013 23:24:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7209621F9DF0 for ; Sun, 11 Aug 2013 23:14:43 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id BF42E2DCB4B; Mon, 12 Aug 2013 08:14:42 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id A374F35C045; Mon, 12 Aug 2013 08:14:42 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Mon, 12 Aug 2013 08:14:42 +0200 From: To: Ted Lemon , Dave Thaler Date: Mon, 12 Aug 2013 08:14:41 +0200 Thread-Topic: [pcp] Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6SN4UBylvrgKNiQjOEzEfANBzc7AAMCTHwAFEmB5AAD8zuAAAOFskA///lHYCAAHUBcP//jZOAgAB1A1D//5JHAP/58TgQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EEC7E96C5@PUEXCB1B.nanterre.francetelecom.fr> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> <3e7fd3c6a757446f8269079cecfffea0@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249F48@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775249FC6@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775249FC6@mbx-01.win.nominum.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.12.32418 Cc: "draft-ietf-pcp-server-selection@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 06:24:25 -0000 Hi Ted, Multi-homing is cited in the draft as an example to illustrate a typical ca= se where multiple servers will be provisioned. The example is not normative= and does not impact the specification since we don't assume that one and o= nly one pcp server is enabled per PVD. This is a deployment-specific assump= tion which, if adopted, will put a lot of complexity on the administrative = entity managing the PVD. I disagree with going that path.=20 Cheers, Med >-----Message d'origine----- >De=A0: Ted Lemon [mailto:Ted.Lemon@nominum.com] >Envoy=E9=A0: jeudi 8 ao=FBt 2013 04:40 >=C0=A0: Dave Thaler >Cc=A0: BOUCADAIR Mohamed OLNC/OLN; pcp@ietf.org; draft-ietf-pcp-server- >selection@tools.ietf.org >Objet=A0: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 > >On Aug 7, 2013, at 10:21 PM, Dave Thaler wrote: >> That's what draft-ietf-pcp-server-selection is supposed to specify. > >Okay, but this draft is talking about multi-homing, and that would only >require one PCP server per PVD. From mohamed.boucadair@orange.com Sun Aug 11 23:44:13 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A5D21F9E39 for ; Sun, 11 Aug 2013 23:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gg0HkU9-psSO for ; Sun, 11 Aug 2013 23:44:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 641FA21F9984 for ; Sun, 11 Aug 2013 23:31:42 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id E2D493240F3; Mon, 12 Aug 2013 08:31:40 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C34C623804B; Mon, 12 Aug 2013 08:31:40 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 12 Aug 2013 08:31:40 +0200 From: To: Dave Thaler , "Tirumaleswar Reddy (tireddy)" , Ted Lemon Date: Mon, 12 Aug 2013 08:31:39 +0200 Thread-Topic: [pcp] Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6SN4UBylvrgKNiQjOEzEfANBzc7AAMCTHwAFEmB5AAD8zuAAAOFskA///lHYCAAHUBcP//jZOAgAB1A1CAAC9dQIAATVqw//raSFA= Message-ID: <94C682931C08B048B7A8645303FDC9F36EEC7E96D6@PUEXCB1B.nanterre.francetelecom.fr> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> <3e7fd3c6a757446f8269079cecfffea0@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249F48@mbx-01.win.nominum.com> <913383AAA69FF945B8F946018B75898A1900EFA0@xmb-rcd-x10.cisco.com> <694128ccd41842df95f28fc29b7e0413@BY2PR03MB269.namprd03.prod.outlook.com> In-Reply-To: <694128ccd41842df95f28fc29b7e0413@BY2PR03MB269.namprd03.prod.outlook.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: "draft-ietf-pcp-server-selection@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 06:44:14 -0000 Re-, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Dave Thaler [mailto:dthaler@microsoft.com] >Envoy=E9=A0: jeudi 8 ao=FBt 2013 16:28 >=C0=A0: Tirumaleswar Reddy (tireddy); Ted Lemon >Cc=A0: BOUCADAIR Mohamed OLNC/OLN; pcp@ietf.org; draft-ietf-pcp-server- >selection@tools.ietf.org >Objet=A0: RE: [pcp] Comments on draft-ietf-pcp-server-selection-01 > > >Tiru wrote: >[...] >> > If you buy Stuart's argument that communicating with just one IP >> > address per >> >> If we consider the use-case http://tools.ietf.org/html/draft-ietf-pcp- >server- >> selection-01#appendix-A.1 there will be one PVD and two PCP server IP >> addresses. If the ICE agent has ICE lite implementation, then it will >have to >> communicate with both the PCP controlled firewalls to permit incoming IC= E >> connectivity checks. > >That's an interesting assertion but you didn't give any justification. > >Stuart asserted that communicating with one is sufficient, and simpler for >the >client, [Med] Communicating with one pcp server is indeed simple but it has implica= tions on the deployment options to be followed in the PVD side. BTW, this i= s not a technical argument since, from the pcp client perspective, the goal= to be reachable from outside and to control how outgoing packets are handl= ed by intermediary pcp-controlled device(s). This is achieved by installing= state so that to be able to receive incoming packets, to retrieve the life= time(s) of the state maintained by PCP-controlled device so that state are = refreshed as appropriate, etc. To achieve that goal, connectivity can be en= hanced if the client is provided with sufficient information to make approp= riate decision(s): e.g., an dual stack host can: * retrieve an external IPv6 address * retrieve an external IPv4 address and/or port number How would a PCP client can retrieve both an external IPv4 address and exter= nal IPv6 address with the same request? This is not doable with RFC6887. because it's the PCP server's job to communicate with the other >ones >to permit incoming ICE connectivity checks. [Med] does this assume one pcp server will controlled every deployed PCP-co= ntrolled device in that network? How PCP servers will coordinate among them= selves? How PCP servers will discover each other? How to select the set of = pcp servers which need to be coordinated? Take the example of a complex con= figuration in which both IPv6-only, IPv4-only and dual-stack hosts are conn= ected (e.g., only nat64, nptv6 and IPv6 fw need to be coordinated for servi= cing IPv6-only hosts, nat44 and nptv6 for dual-stack hosts, etc.)? =20 If you disagree with that, >please respond with a technical argument as to why having the client >communicate with both is better than having one server communicate >with the other. > >-Dave From mohamed.boucadair@orange.com Mon Aug 12 00:06:48 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6BD21F9A6A for ; Mon, 12 Aug 2013 00:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuU5IjJNXX8f for ; Mon, 12 Aug 2013 00:06:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 56C9F21E8086 for ; Sun, 11 Aug 2013 23:56:25 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 366DA22D374; Mon, 12 Aug 2013 08:56:22 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 0FA53238062; Mon, 12 Aug 2013 08:56:22 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Mon, 12 Aug 2013 08:56:22 +0200 From: To: "Tirumaleswar Reddy (tireddy)" , Suresh Kumar Vinapamula Venkata , "pcp@ietf.org" Date: Mon, 12 Aug 2013 08:56:21 +0200 Thread-Topic: [pcp] New Version Notification for draft-vinapamula-softwire-dslite-prefix-binding-00.txt Thread-Index: AQHOk6BWft4hVQbid0e2qbPIabDZjpmM+XMggAQqnlA= Message-ID: <94C682931C08B048B7A8645303FDC9F36EEC7E96E2@PUEXCB1B.nanterre.francetelecom.fr> References: <913383AAA69FF945B8F946018B75898A1901012D@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A1901012D@xmb-rcd-x10.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Subject: Re: [pcp] New Version Notification for draft-vinapamula-softwire-dslite-prefix-binding-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 07:06:48 -0000 Hi Tiru, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >Tirumaleswar Reddy (tireddy) >Envoy=E9=A0: lundi 12 ao=FBt 2013 07:35 >=C0=A0: Suresh Kumar Vinapamula Venkata; pcp@ietf.org >Objet=A0: Re: [pcp] New Version Notification for draft-vinapamula-softwire= - >dslite-prefix-binding-00.txt > >Hi Suresh, > >Interesting problem. > >Comments: > >[1] Any specific reason for mentioning EIM, EIF in section 3 ? > >I mean PCP server always show the behavior of EIM, EIF. [Med] That text applies for all mapping types maintained by the AFTR. The s= tatement is not specific to PCP. > >[2] Step 2 in section 4; > >I think SP already track the number of flows, bandwidth utilization, >congestion caused by the subscriber etc using architecture like Policy >Charging and control (PCC). > >clarify why any new policy changes are required to track subscribers >because of DS-lite ? [Med] The point of that step is to explicitly require policies to be enforc= ed per subscriber and not per softwire. In order to avoid explicitly config= uring IPv6 prefixes, the text suggest to configure the length of the prefix= assigned to subscribers in that domain(e.g., 56 or 64). Doing so, would al= low to include stale mappings in the quota in the event a new IPv6 address = (from the same prefix) is assigned to the B4 element. =20 > >[3] The other way to solve the problem could be store B4 address in stable >storage to handle router reload/crashes etc [Med] This is a constraint on the B4 side. There some contexts which requir= es that address to change for some reasons (e.g., avoid receiving unsolicit= ed traffic). The document explains how the service is not interrupted: migr= ate state to the new B4 IPv6 address. =20 > >[4] >a) For CPE WAN IPv6 prefix change - would there be a "make before break" >scenario for prefix re-numbering ? [Med] The CPE is not supposed to maintain the old IPv6 prefix. The text foc= uses on what happens if a new IPv6 prefix is assigned.=20 >b) Step 4 - How different is this problem when compared with pure-IPv6 onl= y >devices ? [Med] IPv6-only hosts can learn new IPv6 prefix from the new assigned prefi= x. In the DS-Lite context, hosts located behind the CPE may be IPv4-only an= d as such they have no means to be aware new IPv6 prefix is assigned to the= CPE. =20 > >[5] > >Provide more details on why mappings cannot be re-used with the IPv6 >address change (but with no prefix change) and the need to clear mappings. >What is the problem in associating existing IPv4 mappings with a new IPv6 >address derived from the same prefix ? > >[6] Step 6 in Section 4 - clarify what do mean by "clear all resources in >use" ? (Are you referring to resetting the TCP connections ?) [Med] clearing all NAT entries in the AFTR (including TCP sessions). > >[7] Include reference to security considerations given in >http://tools.ietf.org/html/draft-ietf-pcp-dslite-00 > clarify what you mean by "active softwires per subscriber" in step 1 o= f >section 4 and default value of 1 ? [Med] i.e., active IPv4-in-IPv6 tunnel per subscriber. =20 > clarify what you mean by "stable prefix" ? [Med] i.e., the same prefix is assigned to the CPE. In other words, avoid r= enumbering ;-) > >Cheers, >-Tiru. > >> -----Original Message----- >> From: Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net] >> Sent: Wednesday, August 07, 2013 5:51 AM >> To: pcp@ietf.org >> Subject: Re: [pcp] New Version Notification for draft-vinapamula- >softwire- >> dslite-prefix-binding-00.txt >> >> Dear All, >> >> Please refer to the issue#4 discussed in the document >> http://tools.ietf.org/agenda/87/slides/slides-87-pcp-14.pdf (slide 6). >> This is further discussed in the below draft. >> >> Please review and comment. >> >> -Suresh >> >> > >> >On 7/29/13 10:27 AM, "internet-drafts@ietf.org" drafts@ietf.org> >> >wrote: >> > >> >> >> >>A new version of I-D, >> >>draft-vinapamula-softwire-dslite-prefix-binding-00.txt >> >>has been successfully submitted by Suresh Vinapamula and posted to the >> >>IETF repository. >> >> >> >>Filename: draft-vinapamula-softwire-dslite-prefix-binding >> >>Revision: 00 >> >>Title: Recommendation for Prefix Binding in the Softwire DS- >Lite >> >>Context >> >>Creation date: 2013-07-29 >> >>Group: Individual Submission >> >>Number of pages: 5 >> >>URL: >> >>http://www.ietf.org/internet-drafts/draft-vinapamula-softwire-dslite- >pref >> >>i >> >>x-binding-00.txt >> >>Status: >> >>http://datatracker.ietf.org/doc/draft-vinapamula-softwire-dslite- >prefix-b >> >>i >> >>nding >> >>Htmlized: >> >>http://tools.ietf.org/html/draft-vinapamula-softwire-dslite-prefix- >bindin >> >>g >> >>-00 >> >> >> >> >> >>Abstract: >> >> This document describes possible issues induced by the change of th= e >> >> B4 IPv6 address and sketches a set of recommendations. >> >> >> >> >> >> >> >> >> >> >> >>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. >> >> >> >>The IETF Secretariat >> >> >> >> >> >> >> > >> >> > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From tireddy@cisco.com Mon Aug 12 00:15:31 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF4021F9BB6 for ; Mon, 12 Aug 2013 00:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.578 X-Spam-Level: X-Spam-Status: No, score=-10.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0k1lbAV6pGV for ; Mon, 12 Aug 2013 00:15:27 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 55E2521F9EFE for ; Mon, 12 Aug 2013 00:01:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1211; q=dns/txt; s=iport; t=1376290917; x=1377500517; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=B8TEVYx+/HLtZ/1lkdq6kTN0mkTBshhKCxF3ePC+Ci0=; b=fKO6tcylS25J4Lo9+Sn4l7V/QZQX+UA0h+raQljWAkZMK6Em+1WAy0WH gHgoMspfDfsqB3ri7BFw//0IJmf12TOraVGD+2drZdHe6ZhspVUDaMkM/ KeLZu2gMthQidVMfz1WFMoawiLPV2nnqU7CkE9bTEVmBHMpOPISOi3tye 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAIuHCFKtJV2d/2dsb2JhbABagwY1UL5WgRoWdIIkAQEBBDo/DAQCAQgRAQMBAQEKFAkHMhQDBggCBA4FCIgIDLVbkAoxBwaDFXYDmRCQJYMbgio X-IronPort-AV: E=Sophos;i="4.89,860,1367971200"; d="scan'208";a="246099658" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 12 Aug 2013 07:01:55 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7C71tc7032619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Aug 2013 07:01:55 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 02:01:54 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Ted Lemon Thread-Topic: [pcp] Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6SN4UBylvrgKNiQjOEzEfANBzc7AAMCTHwAFEmB5AAD8zuAAAOFskA///lHYCAAHUBcP//jZOAgAB1A1CAAC9dQIAALECA//9qV1A= Date: Mon, 12 Aug 2013 07:01:54 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A190101CB@xmb-rcd-x10.cisco.com> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> <3e7fd3c6a757446f8269079cecfffea0@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249F48@mbx-01.win.nominum.com> <913383AAA69FF945B8F946018B75898A1900EFA0@xmb-rcd-x10.cisco.com> <8D23D4052ABE7A4490E77B1A012B63077524B544@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077524B544@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.43.209] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-pcp-server-selection@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 07:15:32 -0000 > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Thursday, August 08, 2013 8:11 PM > To: Tirumaleswar Reddy (tireddy) > Cc: Dave Thaler; mohamed.boucadair@orange.com; pcp@ietf.org; draft-ietf-p= cp- > server-selection@tools.ietf.org > Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 >=20 > On Aug 8, 2013, at 9:45 AM, "Tirumaleswar Reddy (tireddy)" > wrote: > > If we consider the use-case http://tools.ietf.org/html/draft-ietf-pcp- > server-selection-01#appendix-A.1 there will be one PVD and two PCP server= IP > addresses. If the ICE agent has ICE lite implementation, then it will hav= e to > communicate with both the PCP controlled firewalls to permit incoming ICE > connectivity checks. >=20 > I would expect this to be two provisioning domains, not one. That's > certainly the way we're currently talking about it in the MIF architectur= e > doc. In the above scenario both Firewalls are managed by the same administrative= domain, I have read the draft http://tools.ietf.org/html/draft-anipko-mif-= mpvd-arch-02 but could not figure why two PVD are required for this use cas= e ? --Tiru. From tireddy@cisco.com Mon Aug 12 03:30:46 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBBB11E80D3 for ; Mon, 12 Aug 2013 03:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtBC6UnIlSos for ; Mon, 12 Aug 2013 03:30:37 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 71EFF21F9BB1 for ; Mon, 12 Aug 2013 01:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6905; q=dns/txt; s=iport; t=1376297669; x=1377507269; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=azcJeOi1fMf0ycP6JOyDVWaoE+QY5wlolCxFvp4gzMc=; b=JXnYYB6IESMEUeOkPqmRLSwMQCAh+WDcFl/gj+XcPMltK95glHNrrkgY 8o7x5NXheWN49qXHzTO24P5iKb0oGSTNg+XhRHpde2vALYR8DZ2JhZ2L2 WzbNVC1b+jWoMsBO3Up+c9flsns4Y4Lx9vCbLOm8KOpssUHMNNipsASVd I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAMWhCFKtJXG8/2dsb2JhbABagwY1UL5WgRoWdIIkAQEBAgEBAQEBawkOBAIBCBEBAwEBCx0HJwsUAwYIAgQBEggBiAEGDLYBjwcEfzgGgxV2A4h1ixiFA5AlgWGBOoFpQQ X-IronPort-AV: E=Sophos;i="4.89,860,1367971200"; d="scan'208";a="246178823" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 12 Aug 2013 08:52:52 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7C8qqYK030321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Aug 2013 08:52:52 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 03:52:51 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" , "Suresh Kumar Vinapamula Venkata" , "pcp@ietf.org" Thread-Topic: [pcp] New Version Notification for draft-vinapamula-softwire-dslite-prefix-binding-00.txt Thread-Index: AQHOk6BWft4hVQbid0e2qbPIabDZjpmM+XMggAQqnlCAABgfoA== Date: Mon, 12 Aug 2013 08:52:51 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1901023B@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A1901012D@xmb-rcd-x10.cisco.com> <94C682931C08B048B7A8645303FDC9F36EEC7E96E2@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEC7E96E2@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] New Version Notification for draft-vinapamula-softwire-dslite-prefix-binding-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 10:30:46 -0000 Hi Med, Please see inline > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Monday, August 12, 2013 12:26 PM > To: Tirumaleswar Reddy (tireddy); Suresh Kumar Vinapamula Venkata; > pcp@ietf.org > Subject: RE: [pcp] New Version Notification for draft-vinapamula-softwire= - > dslite-prefix-binding-00.txt >=20 > Hi Tiru, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de > >Tirumaleswar Reddy (tireddy) > >Envoy=E9=A0: lundi 12 ao=FBt 2013 07:35 > >=C0=A0: Suresh Kumar Vinapamula Venkata; pcp@ietf.org > >Objet=A0: Re: [pcp] New Version Notification for draft-vinapamula-softwi= re- > >dslite-prefix-binding-00.txt > > > >Hi Suresh, > > > >Interesting problem. > > > >Comments: > > > >[1] Any specific reason for mentioning EIM, EIF in section 3 ? > > > >I mean PCP server always show the behavior of EIM, EIF. >=20 > [Med] That text applies for all mapping types maintained by the AFTR. The > statement is not specific to PCP. >=20 > > > >[2] Step 2 in section 4; > > > >I think SP already track the number of flows, bandwidth utilization, > >congestion caused by the subscriber etc using architecture like Policy > >Charging and control (PCC). > > > >clarify why any new policy changes are required to track subscribers > >because of DS-lite ? >=20 > [Med] The point of that step is to explicitly require policies to be enfo= rced > per subscriber and not per softwire. In order to avoid explicitly configu= ring > IPv6 prefixes, the text suggest to configure the length of the prefix ass= igned > to subscribers in that domain(e.g., 56 or 64). Doing so, would allow to > include stale mappings in the quota in the event a new IPv6 address (from= the > same prefix) is assigned to the B4 element. If policies are enforced per subscriber then I guess there is no need to cl= ear the=20 mapping (clear the NAT entries) even if IPv6 address changes (but prefix is= not changed). > > > >[3] The other way to solve the problem could be store B4 address in stab= le > >storage to handle router reload/crashes etc >=20 > [Med] This is a constraint on the B4 side. There some contexts which requ= ires > that address to change for some reasons (e.g., avoid receiving unsolicite= d > traffic). The document explains how the service is not interrupted: migra= te > state to the new B4 IPv6 address. If more details are provided in the draft on scenarios which mandate the ad= dress to change it will help. >=20 > > > >[4] > >a) For CPE WAN IPv6 prefix change - would there be a "make before break" > >scenario for prefix re-numbering ? >=20 > [Med] The CPE is not supposed to maintain the old IPv6 prefix. The text > focuses on what happens if a new IPv6 prefix is assigned. By "make before break" I was implying maintain both old and new IPv6 prefix= es thus giving sometime for migration like being discussed in RFC 4191. >=20 > >b) Step 4 - How different is this problem when compared with pure-IPv6 o= nly > >devices ? >=20 > [Med] IPv6-only hosts can learn new IPv6 prefix from the new assigned pre= fix. > In the DS-Lite context, hosts located behind the CPE may be IPv4-only and= as > such they have no means to be aware new IPv6 prefix is assigned to the CP= E. >=20 > > > >[5] > > > >Provide more details on why mappings cannot be re-used with the IPv6 > >address change (but with no prefix change) and the need to clear mapping= s. > >What is the problem in associating existing IPv4 mappings with a new IPv= 6 > >address derived from the same prefix ? > > > >[6] Step 6 in Section 4 - clarify what do mean by "clear all resources i= n > >use" ? (Are you referring to resetting the TCP connections ?) >=20 > [Med] clearing all NAT entries in the AFTR (including TCP sessions). OK. >=20 > > > >[7] Include reference to security considerations given in > >http://tools.ietf.org/html/draft-ietf-pcp-dslite-00 > > clarify what you mean by "active softwires per subscriber" in step 1= of > >section 4 and default value of 1 ? >=20 > [Med] i.e., active IPv4-in-IPv6 tunnel per subscriber. Ok.=20 Any specific reason why it could be more than 1 ? >=20 > > clarify what you mean by "stable prefix" ? >=20 > [Med] i.e., the same prefix is assigned to the CPE. In other words, avoid > renumbering ;-) Got it. Is it possible in future that for privacy reasons renumbering could= happen more frequently ? --Tiru. >=20 > > > >Cheers, > >-Tiru. > > > >> -----Original Message----- > >> From: Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net] > >> Sent: Wednesday, August 07, 2013 5:51 AM > >> To: pcp@ietf.org > >> Subject: Re: [pcp] New Version Notification for draft-vinapamula- > >softwire- > >> dslite-prefix-binding-00.txt > >> > >> Dear All, > >> > >> Please refer to the issue#4 discussed in the document > >> http://tools.ietf.org/agenda/87/slides/slides-87-pcp-14.pdf (slide 6). > >> This is further discussed in the below draft. > >> > >> Please review and comment. > >> > >> -Suresh > >> > >> > > >> >On 7/29/13 10:27 AM, "internet-drafts@ietf.org" >drafts@ietf.org> > >> >wrote: > >> > > >> >> > >> >>A new version of I-D, > >> >>draft-vinapamula-softwire-dslite-prefix-binding-00.txt > >> >>has been successfully submitted by Suresh Vinapamula and posted to t= he > >> >>IETF repository. > >> >> > >> >>Filename: draft-vinapamula-softwire-dslite-prefix-binding > >> >>Revision: 00 > >> >>Title: Recommendation for Prefix Binding in the Softwire DS- > >Lite > >> >>Context > >> >>Creation date: 2013-07-29 > >> >>Group: Individual Submission > >> >>Number of pages: 5 > >> >>URL: > >> >>http://www.ietf.org/internet-drafts/draft-vinapamula-softwire-dslite= - > >pref > >> >>i > >> >>x-binding-00.txt > >> >>Status: > >> >>http://datatracker.ietf.org/doc/draft-vinapamula-softwire-dslite- > >prefix-b > >> >>i > >> >>nding > >> >>Htmlized: > >> >>http://tools.ietf.org/html/draft-vinapamula-softwire-dslite-prefix- > >bindin > >> >>g > >> >>-00 > >> >> > >> >> > >> >>Abstract: > >> >> This document describes possible issues induced by the change of = the > >> >> B4 IPv6 address and sketches a set of recommendations. > >> >> > >> >> > >> >> > >> >> > >> >> > >> >>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. > >> >> > >> >>The IETF Secretariat > >> >> > >> >> > >> >> > >> > > >> > >> > > > >_______________________________________________ > >pcp mailing list > >pcp@ietf.org > >https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Mon Aug 12 03:41:05 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94EF811E818F for ; Mon, 12 Aug 2013 03:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRjE6eAb8X9Q for ; Mon, 12 Aug 2013 03:40:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 14EB721E80DA for ; Mon, 12 Aug 2013 02:12:30 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 3D20718D19C; Mon, 12 Aug 2013 11:12:27 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 19F494C066; Mon, 12 Aug 2013 11:12:27 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 12 Aug 2013 11:12:27 +0200 From: To: "Tirumaleswar Reddy (tireddy)" , Suresh Kumar Vinapamula Venkata , "pcp@ietf.org" Date: Mon, 12 Aug 2013 11:12:26 +0200 Thread-Topic: [pcp] New Version Notification for draft-vinapamula-softwire-dslite-prefix-binding-00.txt Thread-Index: AQHOk6BWft4hVQbid0e2qbPIabDZjpmM+XMggAQqnlCAABgfoIAAD/Zg Message-ID: <94C682931C08B048B7A8645303FDC9F36EEC7E976A@PUEXCB1B.nanterre.francetelecom.fr> References: <913383AAA69FF945B8F946018B75898A1901012D@xmb-rcd-x10.cisco.com> <94C682931C08B048B7A8645303FDC9F36EEC7E96E2@PUEXCB1B.nanterre.francetelecom.fr> <913383AAA69FF945B8F946018B75898A1901023B@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A1901023B@xmb-rcd-x10.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.12.62421 Subject: Re: [pcp] New Version Notification for draft-vinapamula-softwire-dslite-prefix-binding-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 10:41:10 -0000 Re-, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] >Envoy=E9=A0: lundi 12 ao=FBt 2013 10:53 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN; Suresh Kumar Vinapamula Venkata; >pcp@ietf.org >Objet=A0: RE: [pcp] New Version Notification for draft-vinapamula-softwire= - >dslite-prefix-binding-00.txt > >Hi Med, > >Please see inline > >> -----Original Message----- >> From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] >> Sent: Monday, August 12, 2013 12:26 PM >> To: Tirumaleswar Reddy (tireddy); Suresh Kumar Vinapamula Venkata; >> pcp@ietf.org >> Subject: RE: [pcp] New Version Notification for draft-vinapamula- >softwire- >> dslite-prefix-binding-00.txt >> >> Hi Tiru, >> >> Please see inline. >> >> Cheers, >> Med >> >> >-----Message d'origine----- >> >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >> >Tirumaleswar Reddy (tireddy) >> >Envoy=E9=A0: lundi 12 ao=FBt 2013 07:35 >> >=C0=A0: Suresh Kumar Vinapamula Venkata; pcp@ietf.org >> >Objet=A0: Re: [pcp] New Version Notification for draft-vinapamula- >softwire- >> >dslite-prefix-binding-00.txt >> > >> >Hi Suresh, >> > >> >Interesting problem. >> > >> >Comments: >> > >> >[1] Any specific reason for mentioning EIM, EIF in section 3 ? >> > >> >I mean PCP server always show the behavior of EIM, EIF. >> >> [Med] That text applies for all mapping types maintained by the AFTR. Th= e >> statement is not specific to PCP. >> >> > >> >[2] Step 2 in section 4; >> > >> >I think SP already track the number of flows, bandwidth utilization, >> >congestion caused by the subscriber etc using architecture like Policy >> >Charging and control (PCC). >> > >> >clarify why any new policy changes are required to track subscribers >> >because of DS-lite ? >> >> [Med] The point of that step is to explicitly require policies to be >enforced >> per subscriber and not per softwire. In order to avoid explicitly >configuring >> IPv6 prefixes, the text suggest to configure the length of the prefix >assigned >> to subscribers in that domain(e.g., 56 or 64). Doing so, would allow to >> include stale mappings in the quota in the event a new IPv6 address (fro= m >the >> same prefix) is assigned to the B4 element. > >If policies are enforced per subscriber then I guess there is no need to >clear the >mapping (clear the NAT entries) even if IPv6 address changes (but prefix i= s >not changed). > [Med] Yes, entries are not cleared but are migrated to the new IPv6 address= . This is indicated in Step 3: 3. In the event a new IPv6 address is assigned to B4, the AFTR SHOULD migrate existing state to be bound to the new B4's IP address. This ensures the traffic destined to the previous IPv6 address will redirected to the new IPv6 address. The destination address for tunneling return traffic SHOULD be the last seen address from the CPE. The source address of the tunnel would remain same as AFTR. >> > >> >[3] The other way to solve the problem could be store B4 address in >stable >> >storage to handle router reload/crashes etc >> >> [Med] This is a constraint on the B4 side. There some contexts which >requires >> that address to change for some reasons (e.g., avoid receiving >unsolicited >> traffic). The document explains how the service is not interrupted: >migrate >> state to the new B4 IPv6 address. > >If more details are provided in the draft on scenarios which mandate the >address to change it will help. [Med] Will consider updating this (old) text:=20 However, there can be change in B4 address for any reason, may be because of change in CPE device or may be because of security extensions enabled in generating the IPv6 address. > >> >> > >> >[4] >> >a) For CPE WAN IPv6 prefix change - would there be a "make before break= " >> >scenario for prefix re-numbering ? >> >> [Med] The CPE is not supposed to maintain the old IPv6 prefix. The text >> focuses on what happens if a new IPv6 prefix is assigned. > >By "make before break" I was implying maintain both old and new IPv6 >prefixes thus giving sometime for migration like being discussed in RFC >4191. [Med] This makes some assumptions on the way prefixes are assigned by the n= etwork and also the PCP client can uses the lifetime of assigned prefixes t= o clear mappings and install new ones. Retrieving the same external IP addr= ess and ports will depend on the hold-down timers configured on the AFTR si= de. Note, there is no way to indicate to the AFTR/PCP Server to migrate sta= te from an old prefix to a new one. > >> >> >b) Step 4 - How different is this problem when compared with pure-IPv6 >only >> >devices ? >> >> [Med] IPv6-only hosts can learn new IPv6 prefix from the new assigned >prefix. >> In the DS-Lite context, hosts located behind the CPE may be IPv4-only an= d >as >> such they have no means to be aware new IPv6 prefix is assigned to the >CPE. >> >> > >> >[5] >> > >> >Provide more details on why mappings cannot be re-used with the IPv6 >> >address change (but with no prefix change) and the need to clear >mappings. >> >What is the problem in associating existing IPv4 mappings with a new >IPv6 >> >address derived from the same prefix ? >> > >> >[6] Step 6 in Section 4 - clarify what do mean by "clear all resources >in >> >use" ? (Are you referring to resetting the TCP connections ?) >> >> [Med] clearing all NAT entries in the AFTR (including TCP sessions). > >OK. > >> >> > >> >[7] Include reference to security considerations given in >> >http://tools.ietf.org/html/draft-ietf-pcp-dslite-00 >> > clarify what you mean by "active softwires per subscriber" in step = 1 >of >> >section 4 and default value of 1 ? >> >> [Med] i.e., active IPv4-in-IPv6 tunnel per subscriber. > >Ok. >Any specific reason why it could be more than 1 ? [Med] more than 1 may be configured for open wi-fi services for example: a = tunnel for traffic belonging to the owner of the CPE and another tunnel for= the traffic of visiting hosts.=20 > >> >> > clarify what you mean by "stable prefix" ? >> >> [Med] i.e., the same prefix is assigned to the CPE. In other words, avoi= d >> renumbering ;-) > >Got it. Is it possible in future that for privacy reasons renumbering coul= d >happen more frequently ? [Med] One typical use case I have in mind is to avoid SPIT if the same IPv6= address used by the B4 is also used by a SIP User agent co-located in the = CPE. Generating random addresses can be an efficient way to reduce SPIT-lik= e attacks. > >--Tiru. > >> >> > >> >Cheers, >> >-Tiru. >> > >> >> -----Original Message----- >> >> From: Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net] >> >> Sent: Wednesday, August 07, 2013 5:51 AM >> >> To: pcp@ietf.org >> >> Subject: Re: [pcp] New Version Notification for draft-vinapamula- >> >softwire- >> >> dslite-prefix-binding-00.txt >> >> >> >> Dear All, >> >> >> >> Please refer to the issue#4 discussed in the document >> >> http://tools.ietf.org/agenda/87/slides/slides-87-pcp-14.pdf (slide 6)= . >> >> This is further discussed in the below draft. >> >> >> >> Please review and comment. >> >> >> >> -Suresh >> >> >> >> > >> >> >On 7/29/13 10:27 AM, "internet-drafts@ietf.org" > >drafts@ietf.org> >> >> >wrote: >> >> > >> >> >> >> >> >>A new version of I-D, >> >> >>draft-vinapamula-softwire-dslite-prefix-binding-00.txt >> >> >>has been successfully submitted by Suresh Vinapamula and posted to >the >> >> >>IETF repository. >> >> >> >> >> >>Filename: draft-vinapamula-softwire-dslite-prefix-binding >> >> >>Revision: 00 >> >> >>Title: Recommendation for Prefix Binding in the Softwire >DS- >> >Lite >> >> >>Context >> >> >>Creation date: 2013-07-29 >> >> >>Group: Individual Submission >> >> >>Number of pages: 5 >> >> >>URL: >> >> >>http://www.ietf.org/internet-drafts/draft-vinapamula-softwire- >dslite- >> >pref >> >> >>i >> >> >>x-binding-00.txt >> >> >>Status: >> >> >>http://datatracker.ietf.org/doc/draft-vinapamula-softwire-dslite- >> >prefix-b >> >> >>i >> >> >>nding >> >> >>Htmlized: >> >> >>http://tools.ietf.org/html/draft-vinapamula-softwire-dslite-prefix- >> >bindin >> >> >>g >> >> >>-00 >> >> >> >> >> >> >> >> >>Abstract: >> >> >> This document describes possible issues induced by the change of >the >> >> >> B4 IPv6 address and sketches a set of recommendations. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>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= . >> >> >> >> >> >>The IETF Secretariat >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> > >> >_______________________________________________ >> >pcp mailing list >> >pcp@ietf.org >> >https://www.ietf.org/mailman/listinfo/pcp From tireddy@cisco.com Mon Aug 12 04:10:37 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FC821E8084 for ; Mon, 12 Aug 2013 04:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVPVJ+0B4NAx for ; Mon, 12 Aug 2013 04:10:13 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE5321F9E5A for ; Mon, 12 Aug 2013 03:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10237; q=dns/txt; s=iport; t=1376302331; x=1377511931; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Btfr13V3TLkQaYpRB0Kpx3QZ1HqnUYQAW9q31cn5Jpo=; b=VelvgHVSZzYcJlBs8NFMhY1NB+Nwy3guz2nMtrUNWTrbvdXPf1WVZ/PK eHV1s0S31Wns6EIrqacBEdHvLDVXYIcY1h8DRXatKOcY9r4bF5xKcMkvZ /LdM1W/Nok37rb52XcR74v6I/IEVaBjJ0PLKeHab/B8JSdXcf449T6I8m w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAIq0CFKtJXHB/2dsb2JhbABagwY1UL5WgRoWdIIkAQEBAgIBAQFrCQ4EAgEIEQEDAQELHQcnCxQDBggCBAESCAGIBwy2CI8HBH84BoMVdgOIdYsYhQOQJYFhgTqBaUE X-IronPort-AV: E=Sophos;i="4.89,861,1367971200"; d="scan'208";a="246177970" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 12 Aug 2013 10:10:47 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7CAAk2H028669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Aug 2013 10:10:46 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 05:10:46 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" , "Suresh Kumar Vinapamula Venkata" , "pcp@ietf.org" Thread-Topic: [pcp] New Version Notification for draft-vinapamula-softwire-dslite-prefix-binding-00.txt Thread-Index: AQHOk6BWft4hVQbid0e2qbPIabDZjpmM+XMggAQqnlCAABgfoIAAD/ZggAAMvPA= Date: Mon, 12 Aug 2013 10:10:46 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A190102F6@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A1901012D@xmb-rcd-x10.cisco.com> <94C682931C08B048B7A8645303FDC9F36EEC7E96E2@PUEXCB1B.nanterre.francetelecom.fr> <913383AAA69FF945B8F946018B75898A1901023B@xmb-rcd-x10.cisco.com> <94C682931C08B048B7A8645303FDC9F36EEC7E976A@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEC7E976A@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] New Version Notification for draft-vinapamula-softwire-dslite-prefix-binding-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 11:10:37 -0000 Hi Med, Please see inline=20 > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Monday, August 12, 2013 2:42 PM > To: Tirumaleswar Reddy (tireddy); Suresh Kumar Vinapamula Venkata; > pcp@ietf.org > Subject: RE: [pcp] New Version Notification for draft-vinapamula-softwire= - > dslite-prefix-binding-00.txt >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De=A0: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > >Envoy=E9=A0: lundi 12 ao=FBt 2013 10:53 > >=C0=A0: BOUCADAIR Mohamed OLNC/OLN; Suresh Kumar Vinapamula Venkata; > >pcp@ietf.org > >Objet=A0: RE: [pcp] New Version Notification for draft-vinapamula-softwi= re- > >dslite-prefix-binding-00.txt > > > >Hi Med, > > > >Please see inline > > > >> -----Original Message----- > >> From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.co= m] > >> Sent: Monday, August 12, 2013 12:26 PM > >> To: Tirumaleswar Reddy (tireddy); Suresh Kumar Vinapamula Venkata; > >> pcp@ietf.org > >> Subject: RE: [pcp] New Version Notification for draft-vinapamula- > >softwire- > >> dslite-prefix-binding-00.txt > >> > >> Hi Tiru, > >> > >> Please see inline. > >> > >> Cheers, > >> Med > >> > >> >-----Message d'origine----- > >> >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part = de > >> >Tirumaleswar Reddy (tireddy) > >> >Envoy=E9=A0: lundi 12 ao=FBt 2013 07:35 > >> >=C0=A0: Suresh Kumar Vinapamula Venkata; pcp@ietf.org > >> >Objet=A0: Re: [pcp] New Version Notification for draft-vinapamula- > >softwire- > >> >dslite-prefix-binding-00.txt > >> > > >> >Hi Suresh, > >> > > >> >Interesting problem. > >> > > >> >Comments: > >> > > >> >[1] Any specific reason for mentioning EIM, EIF in section 3 ? > >> > > >> >I mean PCP server always show the behavior of EIM, EIF. > >> > >> [Med] That text applies for all mapping types maintained by the AFTR. = The > >> statement is not specific to PCP. > >> > >> > > >> >[2] Step 2 in section 4; > >> > > >> >I think SP already track the number of flows, bandwidth utilization, > >> >congestion caused by the subscriber etc using architecture like Polic= y > >> >Charging and control (PCC). > >> > > >> >clarify why any new policy changes are required to track subscribers > >> >because of DS-lite ? > >> > >> [Med] The point of that step is to explicitly require policies to be > >enforced > >> per subscriber and not per softwire. In order to avoid explicitly > >configuring > >> IPv6 prefixes, the text suggest to configure the length of the prefix > >assigned > >> to subscribers in that domain(e.g., 56 or 64). Doing so, would allow t= o > >> include stale mappings in the quota in the event a new IPv6 address (f= rom > >the > >> same prefix) is assigned to the B4 element. > > > >If policies are enforced per subscriber then I guess there is no need to > >clear the > >mapping (clear the NAT entries) even if IPv6 address changes (but prefix= is > >not changed). > > >=20 > [Med] Yes, entries are not cleared but are migrated to the new IPv6 addre= ss. > This is indicated in Step 3: >=20 > 3. In the event a new IPv6 address is assigned to B4, the AFTR > SHOULD migrate existing state to be bound to the new B4's IP > address. This ensures the traffic destined to the previous IPv6 > address will redirected to the new IPv6 address. The destination > address for tunneling return traffic SHOULD be the last seen > address from the CPE. The source address of the tunnel would > remain same as AFTR. That clarifies my doubt, Thanks. >=20 > >> > > >> >[3] The other way to solve the problem could be store B4 address in > >stable > >> >storage to handle router reload/crashes etc > >> > >> [Med] This is a constraint on the B4 side. There some contexts which > >requires > >> that address to change for some reasons (e.g., avoid receiving > >unsolicited > >> traffic). The document explains how the service is not interrupted: > >migrate > >> state to the new B4 IPv6 address. > > > >If more details are provided in the draft on scenarios which mandate the > >address to change it will help. >=20 > [Med] Will consider updating this (old) text: >=20 > However, there can be change in B4 address for any reason, may be > because of change in CPE device or may be because of security > extensions enabled in generating the IPv6 address. Ok. >=20 > > > >> > >> > > >> >[4] > >> >a) For CPE WAN IPv6 prefix change - would there be a "make before bre= ak" > >> >scenario for prefix re-numbering ? > >> > >> [Med] The CPE is not supposed to maintain the old IPv6 prefix. The tex= t > >> focuses on what happens if a new IPv6 prefix is assigned. > > > >By "make before break" I was implying maintain both old and new IPv6 > >prefixes thus giving sometime for migration like being discussed in RFC > >4191. >=20 > [Med] This makes some assumptions on the way prefixes are assigned by the > network and also the PCP client can uses the lifetime of assigned prefixe= s to > clear mappings and install new ones. Retrieving the same external IP addr= ess > and ports will depend on the hold-down timers configured on the AFTR side= . > Note, there is no way to indicate to the AFTR/PCP Server to migrate state= from > an old prefix to a new one. Yes. >=20 > > > >> > >> >b) Step 4 - How different is this problem when compared with pure-IPv= 6 > >only > >> >devices ? > >> > >> [Med] IPv6-only hosts can learn new IPv6 prefix from the new assigned > >prefix. > >> In the DS-Lite context, hosts located behind the CPE may be IPv4-only = and > >as > >> such they have no means to be aware new IPv6 prefix is assigned to the > >CPE. > >> > >> > > >> >[5] > >> > > >> >Provide more details on why mappings cannot be re-used with the IPv6 > >> >address change (but with no prefix change) and the need to clear > >mappings. > >> >What is the problem in associating existing IPv4 mappings with a new > >IPv6 > >> >address derived from the same prefix ? > >> > > >> >[6] Step 6 in Section 4 - clarify what do mean by "clear all resource= s > >in > >> >use" ? (Are you referring to resetting the TCP connections ?) > >> > >> [Med] clearing all NAT entries in the AFTR (including TCP sessions). > > > >OK. > > > >> > >> > > >> >[7] Include reference to security considerations given in > >> >http://tools.ietf.org/html/draft-ietf-pcp-dslite-00 > >> > clarify what you mean by "active softwires per subscriber" in ste= p 1 > >of > >> >section 4 and default value of 1 ? > >> > >> [Med] i.e., active IPv4-in-IPv6 tunnel per subscriber. > > > >Ok. > >Any specific reason why it could be more than 1 ? >=20 > [Med] more than 1 may be configured for open wi-fi services for example: = a > tunnel for traffic belonging to the owner of the CPE and another tunnel f= or > the traffic of visiting hosts. >=20 > > > >> > >> > clarify what you mean by "stable prefix" ? > >> > >> [Med] i.e., the same prefix is assigned to the CPE. In other words, av= oid > >> renumbering ;-) > > > >Got it. Is it possible in future that for privacy reasons renumbering co= uld > >happen more frequently ? >=20 > [Med] One typical use case I have in mind is to avoid SPIT if the same IP= v6 > address used by the B4 is also used by a SIP User agent co-located in the= CPE. > Generating random addresses can be an efficient way to reduce SPIT-like > attacks. --Tiru. >=20 > > > >--Tiru. > > > >> > >> > > >> >Cheers, > >> >-Tiru. > >> > > >> >> -----Original Message----- > >> >> From: Suresh Kumar Vinapamula Venkata [mailto:sureshk@juniper.net] > >> >> Sent: Wednesday, August 07, 2013 5:51 AM > >> >> To: pcp@ietf.org > >> >> Subject: Re: [pcp] New Version Notification for draft-vinapamula- > >> >softwire- > >> >> dslite-prefix-binding-00.txt > >> >> > >> >> Dear All, > >> >> > >> >> Please refer to the issue#4 discussed in the document > >> >> http://tools.ietf.org/agenda/87/slides/slides-87-pcp-14.pdf (slide = 6). > >> >> This is further discussed in the below draft. > >> >> > >> >> Please review and comment. > >> >> > >> >> -Suresh > >> >> > >> >> > > >> >> >On 7/29/13 10:27 AM, "internet-drafts@ietf.org" >> >drafts@ietf.org> > >> >> >wrote: > >> >> > > >> >> >> > >> >> >>A new version of I-D, > >> >> >>draft-vinapamula-softwire-dslite-prefix-binding-00.txt > >> >> >>has been successfully submitted by Suresh Vinapamula and posted t= o > >the > >> >> >>IETF repository. > >> >> >> > >> >> >>Filename: draft-vinapamula-softwire-dslite-prefix-binding > >> >> >>Revision: 00 > >> >> >>Title: Recommendation for Prefix Binding in the Softwire > >DS- > >> >Lite > >> >> >>Context > >> >> >>Creation date: 2013-07-29 > >> >> >>Group: Individual Submission > >> >> >>Number of pages: 5 > >> >> >>URL: > >> >> >>http://www.ietf.org/internet-drafts/draft-vinapamula-softwire- > >dslite- > >> >pref > >> >> >>i > >> >> >>x-binding-00.txt > >> >> >>Status: > >> >> >>http://datatracker.ietf.org/doc/draft-vinapamula-softwire-dslite- > >> >prefix-b > >> >> >>i > >> >> >>nding > >> >> >>Htmlized: > >> >> >>http://tools.ietf.org/html/draft-vinapamula-softwire-dslite-prefi= x- > >> >bindin > >> >> >>g > >> >> >>-00 > >> >> >> > >> >> >> > >> >> >>Abstract: > >> >> >> This document describes possible issues induced by the change = of > >the > >> >> >> B4 IPv6 address and sketches a set of recommendations. > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >>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.o= rg. > >> >> >> > >> >> >>The IETF Secretariat > >> >> >> > >> >> >> > >> >> >> > >> >> > > >> >> > >> >> > >> > > >> >_______________________________________________ > >> >pcp mailing list > >> >pcp@ietf.org > >> >https://www.ietf.org/mailman/listinfo/pcp From rmohanr@cisco.com Mon Aug 12 22:04:29 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739DC21F9A05 for ; Mon, 12 Aug 2013 22:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbuaC2Pm8drB for ; Mon, 12 Aug 2013 22:04:19 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E006221F99F3 for ; Mon, 12 Aug 2013 22:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1098; q=dns/txt; s=iport; t=1376370259; x=1377579859; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Oxh2fOBKpfeON6SG3nTVOJryJc7uJto6SBir5bAGiQo=; b=HmhJ1DOI59jWLNO1CwuPJpLqPSvrXcjXlQozHteErjoDtX29sjX7r7wP nk3RN/rxtuTKNA1HgScEhwHR+/Rl0vp4poN01zEPFGxM9dz3kCWqHPltF 5sJe70VUG+hY9/oTF+zgGJllY+xRSR35WlQJQOwIDKRYkIxnijtCuarnL M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwGACC9CVKtJXG8/2dsb2JhbABbgwY1UL5RgRwWbQeCJAEBAQQdHTQXBgEIEQQBAQsUBT0dCAIEEwiICAyWTKBAjnWBHDgGgxV2A5kQkCWBYYE6gXE5 X-IronPort-AV: E=Sophos;i="4.89,866,1367971200"; d="scan'208";a="246650283" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 13 Aug 2013 05:04:18 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7D54IIh000604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 13 Aug 2013 05:04:18 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.17]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 00:04:17 -0500 From: "Ram Mohan R (rmohanr)" To: "pcp@ietf.org" Thread-Topic: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) Thread-Index: AQHOjFORrIMjf8sOSUiRMwszh5KQt5mMm2mggAbBEwA= Date: Tue, 13 Aug 2013 05:04:17 +0000 Message-ID: In-Reply-To: <913383AAA69FF945B8F946018B75898A1900F74A@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: [72.163.212.136] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 05:04:29 -0000 I support adoption of this document. One comment that you can take care in the next revision- We can add some text on how this document will interact with consent messages that would be sent for webRTC flows Ram > > >-----Original Message----- >From: Reinaldo Penno (repenno) >Sent: Monday, July 29, 2013 3:52 PM >To: pcp@ietf.org >Subject: [pcp] WG Call for Adoption: Optimizing NAT and Firewall >Keepalives Using Port Control Protocol (PCP) > >Hello, > >This email starts a 2-week consensus call on adopting "Optimizing NAT and >Firewall Keepalives Using Port Control Protocol (PCP)" as a WG item. > > Title : Optimizing NAT and Firewall Keepalives Using Port Control >Protocol (PCP) > Author(s) : T. Reddy et al > Filename : draft-reddy-pcp-optimize-keepalives-01 > URL : >http://tools.ietf.org/html/draft-reddy-pcp-optimize-keepalives-01 > >Please read the current revision and state you opinion either for or >against adoption in the mailing list. > >The call for adoption ends 12th August 2013. > >Thanks, > >Chairs > > > From mohamed.boucadair@orange.com Mon Aug 12 22:51:57 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0614F11E8139 for ; Mon, 12 Aug 2013 22:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDivpegymRkQ for ; Mon, 12 Aug 2013 22:51:53 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B0BD711E813D for ; Mon, 12 Aug 2013 22:51:49 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 5D87E22CC37; Tue, 13 Aug 2013 07:51:46 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 4096035C048; Tue, 13 Aug 2013 07:51:46 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Tue, 13 Aug 2013 07:51:46 +0200 From: To: Ted Lemon , Tirumaleswar Reddy Date: Tue, 13 Aug 2013 07:51:45 +0200 Thread-Topic: [pcp] Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6XcmPGFapJ8ucdQTCWUg2ao6LIQgAdqk4A Message-ID: <94C682931C08B048B7A8645303FDC9F36EEC7E988D@PUEXCB1B.nanterre.francetelecom.fr> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> <3e7fd3c6a757446f8269079cecfffea0@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249F48@mbx-01.win.nominum.com> <913383AAA69FF945B8F946018B75898A1900EFA0@xmb-rcd-x10.cisco.com> <8D23D4052ABE7A4490E77B1A012B63077524B544@mbx-01.win.nominum.com> <913383AAA69FF945B8F946018B75898A190101CB@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.13.40334 Cc: "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 05:51:57 -0000 Hi Ted, all, One additional comment: the current document does not mix multi-interface i= ssues with multiple server case. A device with multiple interfaces may disc= over one single server while a mono-interfaced device may discover multiple= servers.=20 >From a PCP perspective, the goal is to increase the chance to get connectiv= ity and be reachable from outside. A host in a domain which include multipl= e firewalls, multiple NATs4, etc. will need: * to discover all external IP addresses/port in order to publish them to re= mote parties. * to open pinholes in all FWs located in the boundary of a given domain: be= cause a local domain may not have the control on the entry point to be sele= cted when entering a domain (this is traditionally called inbound TE). Cheers, Med >-----Message d'origine----- >De=A0: Ted Lemon [mailto:ted.lemon@nominum.com] >Envoy=E9=A0: lundi 12 ao=FBt 2013 17:41 >=C0=A0: Tirumaleswar Reddy >Cc=A0: Dave Thaler; mohamed.boucadair@; pcp@; draft-ietf-pcp-server- >selection@ >Objet=A0: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 > >On Aug 12, 2013, at 3:01 AM, Tirumaleswar Reddy (tireddy) > wrote: >> In the above scenario both Firewalls are managed by the same >administrative domain, I have read the draft >http://tools.ietf.org/html/draft-anipko-mif-mpvd-arch-02 but could not >figure why two PVD are required for this use case ? > >The motivation for treating these as separate provisioning domains is that >we want a device that is inside a multihomed network to provide the same >experience as a device that is at the edge of the same multihomed network. >In order for that to be the case, the two external links need to be treate= d >as separate provisioning domains. > >It's true that the firewalls may be managed by the same entity, but >treating them as separate provisioning domains has several advantages. >First, that's what you want to do anyway-you just want to do it outside th= e >PVD model, with your server selection model. Secondly, from the >perspective of the application, the fact that the two firewalls are >operated by the same entity is immaterial. What matters is that they >connect to two separate network service providers. Doing this with >provisioning domains groups relevant information in a way that allows the >application to make meaningful choices about its connection to the network= . >If you separate out provisioning domains and server selection, the >application has a _much_ harder problem to solve. From mohamed.boucadair@orange.com Mon Aug 12 23:26:27 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41E521E80C4 for ; Mon, 12 Aug 2013 23:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nveD0Yn0kfKD for ; Mon, 12 Aug 2013 23:26:23 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 92EC821E80BB for ; Mon, 12 Aug 2013 23:26:23 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 8B60A2DC343 for ; Tue, 13 Aug 2013 08:26:22 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 730E127C05B for ; Tue, 13 Aug 2013 08:26:22 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Tue, 13 Aug 2013 08:26:22 +0200 From: To: "pcp@ietf.org" Date: Tue, 13 Aug 2013 08:26:20 +0200 Thread-Topic: draft-ietf-pcp-dhcp: multiple pcp servers Thread-Index: Ac6X7gQ2XmMDKA+0QwG2szzsANBXzQ== Message-ID: <94C682931C08B048B7A8645303FDC9F36EEC7E9894@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.13.54217 Subject: [pcp] draft-ietf-pcp-dhcp: multiple pcp servers X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 06:26:28 -0000 Dear all, The design of the DHCP PCP option (http://tools.ietf.org/html/draft-ietf-pc= p-dhcp-08) assumes: (1) multiple pcp servers may be received from the same DHCP server. (2) one pcp server may be reachable with multiple IP addresses.=20 (3) when multiple pcp servers are returned, the pcp client will need to con= tact all these servers. =20 (4) It is up to an administrative entity to return one or multiple pcp serv= ers. No restriction is made by design. FWIW, this design was in the draft since -02. Dave is echo'ing a comment which objects this design and advocates for rest= ricting the design to return only one pcp server and it is up to the admini= strative entity to sync the state in all enabled PCP servers. IMO, this obj= ection is not technically sound, at least for the following reasons: (1) The protocol cannot discover in one single request all external IP addr= esses and port numbers. Imagine the case where a NPTv6 and NAT64 boxes are = deployed. The PCP client has no means to learn with one single request to a= single PCP server both the external IPv4 address (assigned by the NAT64 de= vice) and the external IPv6 address assigned by the NPTv6 box. The same iss= ue is encountered when multiple NAT configured with distinct pool are in pl= ace.=20 =20 (2) A host connected to a multi-homed domain, in which FW are located at th= e border router in front of each adjacent domain, will need to open pinhole= s in these FW if it want to receive incoming traffic from a remote peer.=20 (3) The protocol does not specify how state synchronization is to be achiev= ed between several PCP servers. The task is even complex when these pcp ser= vers are controlling functions of distinct types (e.g., NAT44, FW, NAT64, P= ort Range Router, etc.). Other issues are raised (see to the pcp-server-sel= ection thread) (4) Mandating one and only one pcp server is to be returned is really deplo= yment-specific. This assumption will induce a lot of complexity at the netw= ork side For those who are objecting the design as currently documented in -07, it i= s time to raise your concern (preferably with the technical arguments that = motivate your point). If no technical argument is made, the current design = will be maintained as it is.=20 Cheers, Med -----Message d'origine----- De=A0: BOUCADAIR Mohamed OLNC/OLN=20 Envoy=E9=A0: lundi 12 ao=FBt 2013 07:56 =C0=A0: 'Dave Thaler'; Ted Lemon Cc=A0: Reinaldo Penno (repenno) (repenno@cisco.com); Dan Wing (dwing@cisco.= com) Objet=A0: RE: PCP DHCP I-D: your feedback is needed Hi Dave, I disagree to put the constraint on the network deploying many PCP servers = to coordinate state instantiating. This is a deployment specific assumption= which is not trivial to honor.=20 A domain may deploy various pcp server controlling functions which are not = of the same nature, e.g., a domain may deploy: * one or multiple nat64 provisioned to IPv6-only hosts * one or multiple nptv6 provisioned to IPv6-only and dual stack hosts * one or multiple nat44 provisioned to IPv4-only and dual stack hosts * one or multiple IPv4 fw=20 * one or multiple IPv6 fw * multiple flow-based access routers * etc. The design as currently document in the pcp server selection draft (and its= dhcp instantiation) does not make any deployment assumption. As such: * an administrative entity can return one single IP address but instead it = must ensure state are installed in other servers. * an administrative entity can return multiple servers; it is up to the cli= ent to contact these servers to install the state.=20 This is much more better than constraining the design by non-valid deployme= nt assumptions. I agree, this should be discussed in the list. Cheers, Med >-----Message d'origine----- >De=A0: Dave Thaler [mailto:dthaler@microsoft.com] >Envoy=E9=A0: mercredi 7 ao=FBt 2013 19:56 >=C0=A0: Ted Lemon; BOUCADAIR Mohamed OLNC/OLN >Cc=A0: Reinaldo Penno (repenno) (repenno@cisco.com); Dan Wing >(dwing@cisco.com) >Objet=A0: RE: PCP DHCP I-D: your feedback is needed > >I think this thread should move to the main WG mailing list, so Ted if you >agree, >please forward/respond on this thread there. > >This is related to my comments on draft-ietf-pcp-server-selection-01.txt. > >If the app needs semantics of "contact each PCP server" then you need to >know >how to distinguish PCP servers. Now more recently various members of the >WG (e.g. Stuart) have disputed the notion that an app needs to "contact >each PCP >server" and so we do not have consensus that this is required. Stuart >proposed >that it's the PCP server's job to coordinate with any other servers manage= d >by >the same entity (or to steal a term from MIF... within the same >provisioning domain). >No one has given a counter argument, and so I said in email we should star= t >with that >assumption. > >You do need to distinguish provisioning domains (for reasons discussed in >MIF that >apply to PCP like they do to anything else). So the only remaining >interesting case >I think is figure 2 in section A.2 of draft-ietf-pcp-server-selection- >01.txt where if >you have a local gateway with a DHCP server (e.g. a home gateway) that's >multi-homed >to two external provisioning domains each with their own PCP server(s), >what do you >get from DHCP? I think the best answer here is to make the local gateway >be a >PCP proxy, and so DHCP just gives you its address. > >In such a solution, I believe there is no need to differentiate between >multiple >IPs of the same server vs multiple IPs of different servers. That is, you >communicate >with any one server IP, and you assume that it will take care of making >sure that >all servers with any of those IPs get the info. > >I believe this then removes any new concepts from DHCP and requires no >additional support in DHCP servers. > >-Dave > >> -----Original Message----- >> From: Ted Lemon [mailto:Ted.Lemon@nominum.com] >> Sent: Wednesday, August 7, 2013 8:26 AM >> To: mohamed.boucadair@orange.com >> Cc: Dave Thaler; Reinaldo Penno (repenno) (repenno@cisco.com); Dan Wing >> (dwing@cisco.com) >> Subject: Re: PCP DHCP I-D: your feedback is needed >> >> On Aug 7, 2013, at 3:00 AM, mohamed.boucadair@orange.com wrote: >> > Ok, done. >> >> Thanks. >> >> Can you explain your motivation for adding new text differentiating >between >> multiple IP addresses that refer to the same PCP server, and multiple IP >> addresses that refer to different PCP servers? Is this something the >working >> group asked to have added to the document? I think this is a new >concept in >> the current document, and of course, it requires special support in the >DHCP >> server and DHCP client just for PCP. >> >> This is not the only issue with your current set of edits to the >document, but >> I'd just like to get clarity on this one issue before proceeding on to >the next. >> > > From praspati@cisco.com Tue Aug 13 01:05:00 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671A521E80D5 for ; Tue, 13 Aug 2013 01:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkGmwGMaxd7r for ; Tue, 13 Aug 2013 01:04:55 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9D421E8097 for ; Tue, 13 Aug 2013 01:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8131; q=dns/txt; s=iport; t=1376381095; x=1377590695; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=QfoOAd7tAugQFamDE9HAs0yQt3YWduDESKihfR1esP0=; b=m6e3CQFvXFLjQoHGs9AgaHkp+5CHMi+HRb+i07uFqlGMIAz+4a8LpUA7 NayZN4JlvVaGUBcABj5svZMpSyxh8fXkdZQVdzupCzA9TngPpJlusd3YE wi+4MiI8Z7M6+ul+v4jkOPeyrGSNRp4h0YahLZmEOf3Bkj2Ln24a4+O88 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFAFXnCVKtJV2d/2dsb2JhbABbgwY1UL5VgRwWdIIkAQEBBAEBAWsXBgEIEQQBAQEKHS4LFAkIAgQBEggTh3UMtzeObAmBHDgGgxV2A4h1kBuQJYMbgXE5 X-IronPort-AV: E=Sophos;i="4.89,867,1367971200"; d="scan'208";a="246426105" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 13 Aug 2013 08:04:54 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7D84sZa014183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Aug 2013 08:04:54 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.106]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 03:04:54 -0500 From: "Prashanth Patil (praspati)" To: "mohamed.boucadair@orange.com" , "pcp@ietf.org" Thread-Topic: [pcp] draft-ietf-pcp-dhcp: multiple pcp servers Thread-Index: AQHOl/vKqj3PqU8UM0KRp10S67PvCA== Date: Tue, 13 Aug 2013 08:04:53 +0000 Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEC7E9894@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.68.21.165] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] draft-ietf-pcp-dhcp: multiple pcp servers X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 08:05:00 -0000 I agree with what's been currently described in the draft today i.e if a PCP Client receives multiple PCP servers, it should contact all of them independently (not to be confused with a single PCP server reachable over multiple IP addresses). The list should be treated as a list of active PCP servers purposefully deployed and not a list of primary and backup servers. If a deployment is designed to have a master PCP server that syncs to other PCP servers, then the PCP client should only learn about that PCP server and nothing else. There are some serious concerns about this approach that need to be sorted out if we wish to support this =AD the master PCP server will essentially be a PCP proxy with a lot of additional capability. -Prashanth On 13/08/13 11:56 AM, "mohamed.boucadair@orange.com" wrote: >Dear all, > >The design of the DHCP PCP option >(http://tools.ietf.org/html/draft-ietf-pcp-dhcp-08) assumes: >(1) multiple pcp servers may be received from the same DHCP server. >(2) one pcp server may be reachable with multiple IP addresses. >(3) when multiple pcp servers are returned, the pcp client will need to >contact all these servers. >(4) It is up to an administrative entity to return one or multiple pcp >servers. No restriction is made by design. > >FWIW, this design was in the draft since -02. > >Dave is echo'ing a comment which objects this design and advocates for >restricting the design to return only one pcp server and it is up to the >administrative entity to sync the state in all enabled PCP servers. IMO, >this objection is not technically sound, at least for the following >reasons: > >(1) The protocol cannot discover in one single request all external IP >addresses and port numbers. Imagine the case where a NPTv6 and NAT64 >boxes are deployed. The PCP client has no means to learn with one single >request to a single PCP server both the external IPv4 address (assigned >by the NAT64 device) and the external IPv6 address assigned by the NPTv6 >box. The same issue is encountered when multiple NAT configured with >distinct pool are in place. > =20 >(2) A host connected to a multi-homed domain, in which FW are located at >the border router in front of each adjacent domain, will need to open >pinholes in these FW if it want to receive incoming traffic from a remote >peer.=20 > >(3) The protocol does not specify how state synchronization is to be >achieved between several PCP servers. The task is even complex when these >pcp servers are controlling functions of distinct types (e.g., NAT44, FW, >NAT64, Port Range Router, etc.). Other issues are raised (see to the >pcp-server-selection thread) > >(4) Mandating one and only one pcp server is to be returned is really >deployment-specific. This assumption will induce a lot of complexity at >the network side > >For those who are objecting the design as currently documented in -07, it >is time to raise your concern (preferably with the technical arguments >that motivate your point). If no technical argument is made, the current >design will be maintained as it is. > >Cheers, >Med > >-----Message d'origine----- >De : BOUCADAIR Mohamed OLNC/OLN >Envoy=E9 : lundi 12 ao=FBt 2013 07:56 >=C0 : 'Dave Thaler'; Ted Lemon >Cc : Reinaldo Penno (repenno) (repenno@cisco.com); Dan Wing >(dwing@cisco.com) >Objet : RE: PCP DHCP I-D: your feedback is needed > >Hi Dave, > >I disagree to put the constraint on the network deploying many PCP >servers to coordinate state instantiating. This is a deployment specific >assumption which is not trivial to honor. > >A domain may deploy various pcp server controlling functions which are >not of the same nature, e.g., a domain may deploy: >* one or multiple nat64 provisioned to IPv6-only hosts >* one or multiple nptv6 provisioned to IPv6-only and dual stack hosts >* one or multiple nat44 provisioned to IPv4-only and dual stack hosts >* one or multiple IPv4 fw >* one or multiple IPv6 fw >* multiple flow-based access routers >* etc. > >The design as currently document in the pcp server selection draft (and >its dhcp instantiation) does not make any deployment assumption. As such: >* an administrative entity can return one single IP address but instead >it must ensure state are installed in other servers. >* an administrative entity can return multiple servers; it is up to the >client to contact these servers to install the state. > >This is much more better than constraining the design by non-valid >deployment assumptions. > >I agree, this should be discussed in the list. > >Cheers, >Med > >>-----Message d'origine----- >>De : Dave Thaler [mailto:dthaler@microsoft.com] >>Envoy=E9 : mercredi 7 ao=FBt 2013 19:56 >>=C0 : Ted Lemon; BOUCADAIR Mohamed OLNC/OLN >>Cc : Reinaldo Penno (repenno) (repenno@cisco.com); Dan Wing >>(dwing@cisco.com) >>Objet : RE: PCP DHCP I-D: your feedback is needed >> >>I think this thread should move to the main WG mailing list, so Ted if >>you >>agree, >>please forward/respond on this thread there. >> >>This is related to my comments on draft-ietf-pcp-server-selection-01.txt. >> >>If the app needs semantics of "contact each PCP server" then you need to >>know >>how to distinguish PCP servers. Now more recently various members of the >>WG (e.g. Stuart) have disputed the notion that an app needs to "contact >>each PCP >>server" and so we do not have consensus that this is required. Stuart >>proposed >>that it's the PCP server's job to coordinate with any other servers >>managed >>by >>the same entity (or to steal a term from MIF... within the same >>provisioning domain). >>No one has given a counter argument, and so I said in email we should >>start >>with that >>assumption. >> >>You do need to distinguish provisioning domains (for reasons discussed in >>MIF that >>apply to PCP like they do to anything else). So the only remaining >>interesting case >>I think is figure 2 in section A.2 of draft-ietf-pcp-server-selection- >>01.txt where if >>you have a local gateway with a DHCP server (e.g. a home gateway) that's >>multi-homed >>to two external provisioning domains each with their own PCP server(s), >>what do you >>get from DHCP? I think the best answer here is to make the local gateway >>be a >>PCP proxy, and so DHCP just gives you its address. >> >>In such a solution, I believe there is no need to differentiate between >>multiple >>IPs of the same server vs multiple IPs of different servers. That is, >>you >>communicate >>with any one server IP, and you assume that it will take care of making >>sure that >>all servers with any of those IPs get the info. >> >>I believe this then removes any new concepts from DHCP and requires no >>additional support in DHCP servers. >> >>-Dave >> >>> -----Original Message----- >>> From: Ted Lemon [mailto:Ted.Lemon@nominum.com] >>> Sent: Wednesday, August 7, 2013 8:26 AM >>> To: mohamed.boucadair@orange.com >>> Cc: Dave Thaler; Reinaldo Penno (repenno) (repenno@cisco.com); Dan Wing >>> (dwing@cisco.com) >>> Subject: Re: PCP DHCP I-D: your feedback is needed >>> >>> On Aug 7, 2013, at 3:00 AM, mohamed.boucadair@orange.com wrote: >>> > Ok, done. >>> >>> Thanks. >>> >>> Can you explain your motivation for adding new text differentiating >>between >>> multiple IP addresses that refer to the same PCP server, and multiple >>>IP >>> addresses that refer to different PCP servers? Is this something the >>working >>> group asked to have added to the document? I think this is a new >>concept in >>> the current document, and of course, it requires special support in the >>DHCP >>> server and DHCP client just for PCP. >>> >>> This is not the only issue with your current set of edits to the >>document, but >>> I'd just like to get clarity on this one issue before proceeding on to >>the next. >>> >> >> > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Tue Aug 13 06:12:18 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526E121F9A78 for ; Tue, 13 Aug 2013 06:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JM0DbMeY1dgj for ; Tue, 13 Aug 2013 06:12:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id D6B3811E816D for ; Tue, 13 Aug 2013 06:12:09 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 87FCA22E043; Tue, 13 Aug 2013 15:12:08 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 6BCFD238048; Tue, 13 Aug 2013 15:12:08 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Tue, 13 Aug 2013 15:12:08 +0200 From: To: Ted Lemon Date: Tue, 13 Aug 2013 15:12:06 +0200 Thread-Topic: [pcp] draft-ietf-pcp-dhcp: multiple pcp servers Thread-Index: Ac6YI1tCxIzD9SvfTKWT9V+RB9xUvgAA1JDQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EEC7E99A9@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EEC7E9894@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: "pcp@ietf.org" Subject: Re: [pcp] draft-ietf-pcp-dhcp: multiple pcp servers X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 13:12:18 -0000 Ted, Some comments are listed below: * The design in -08 does not differ from previous versions: multiple instan= ces of the option were described in previous versions. What has been change= d is only the encoding: use an IP address instead of names. * The design does not extend RFC3315 which does not exclude an option to ap= pear several times. * As you can notice, no normative language is used in the server guideline = section. This is to accommodate existing implementations.=20 * There are already existing DHCP option specification documents which allo= w to return multiple options (e.g., RFC 5908, RFC 6731, RFC 6784, etc.) * What is important IMHO is to make sure the client is expecting to receive= multiple options.=20 Cheers, Med >-----Message d'origine----- >De=A0: Ted Lemon [mailto:ted.lemon@nominum.com] >Envoy=E9=A0: mardi 13 ao=FBt 2013 14:48 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN >Cc=A0: pcp@ >Objet=A0: Re: [pcp] draft-ietf-pcp-dhcp: multiple pcp servers > >On Aug 13, 2013, at 2:26 AM, mohamed.boucadair@orange.com wrote: >> The design of the DHCP PCP option (http://tools.ietf.org/html/draft-ietf= - >pcp-dhcp-08) assumes: >> (1) multiple pcp servers may be received from the same DHCP server. >> (2) one pcp server may be reachable with multiple IP addresses. >> (3) when multiple pcp servers are returned, the pcp client will need to >contact all these servers. >> (4) It is up to an administrative entity to return one or multiple pcp >servers. No restriction is made by design. > >BTW, Med presents this as if it is the consensus of the working group, lon= g >since decided, but I would like the working group to consider the >practicality of the proposal and not just the shopping list of features >that Med has presented here. I do not doubt that the working group >previously agreed to this shopping list, but I am a bit skeptical that all >involved actually understood what the proposal would do in terms of its >impact on the DHCP protocol. > >The current DHCP PCP option draft that Med has published differs from >previous drafts in that it uses DHCP option structure to convey semantics. >Like the previous proposal, this new proposal extends the DHCP protocol an= d >winds up updating RFC3315 to add new functionality that will require code >changes on all DHCP servers and clients. > >The reason this is the case is that the DHCP server indicates to the DHCP >client how many PCP servers there are by sending a PCP server option per >PCP server. And it indicates that a PCP server has multiple IP addresses >by sending multiple IP addresses in a single PCP option. So DHCP servers >have to be able to do both of these things: send multiple PCP options, and >send multiple IP addresses per option. This is not functionality present >in current DHCP servers. > >If the working group wishes to extend the DHCP protocol in this way, this >would be out of scope for the PCP working group-the work would have to be >done in the DHC working group. The DHC working group is likely to make >just such an extension, which would apply to all DHCP options, in order to >support multiple provisioning domains, but that is future work. > >What would be most expedient for _this_ working group would be to define a >simple option that delivers one or more IP addresses of PCP servers. Thi= s >is something that could be finished soon, and used soon. I would argue >that it is up to the client what it wants to do with those IP addresses; i= f >the addresses refer to multiple PCP servers, that is something that can be >discovered using the PCP protocol, and need not be conveyed in a DHCP >option. From Ted.Lemon@nominum.com Tue Aug 13 07:34:52 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A4B11E815C for ; Tue, 13 Aug 2013 07:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RqnR5geUGNv for ; Tue, 13 Aug 2013 07:34:46 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id DB66F21E811A for ; Tue, 13 Aug 2013 07:34:45 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUgpEBZ1XFB93sqAA934z5hsqWr9e7NV0@postini.com; Tue, 13 Aug 2013 07:34:45 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 53A821B827D for ; Tue, 13 Aug 2013 07:34:45 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4D9BB19006C; Tue, 13 Aug 2013 07:34:45 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 13 Aug 2013 07:34:45 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1793.4\)) From: Ted Lemon In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEC7E99A8@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 13 Aug 2013 10:34:41 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <5C06CABF-5797-484F-A8F9-ED2795CE0EE6@nominum.com> References: <94C682931C08B048B7A8645303FDC9F36EEC7E9894@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EEC7E99A8@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1793.4) X-Originating-IP: [192.168.1.10] Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-dhcp: multiple pcp servers X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 14:34:52 -0000 On Aug 13, 2013, at 9:11 AM, mohamed.boucadair@orange.com wrote: > * The design in -08 does not differ from previous versions: multiple = instances of the option were described in previous versions. What has = been changed is only the encoding: use an IP address instead of names. Perhaps that's so. I've been so focused on the really big problems = with previous versions of the draft that I didn't notice this one, if it = was in fact present. > * The design does not extend RFC3315 which does not exclude an option = to appear several times. Yes, it does. This is why work of this sort needs to be done in the = DHC working group, not in the PCP working group: that is where the = expertise on DHCP is. You think that because it is possible to = represent this data in a DHCP packet, that no changes are required in = the protocol. But in fact in order to implement what you have = documented in the current draft, all DHCP servers and DHCP clients will = have to be modified. That is what it means to update the DHCP = protocol. Show me where in RFC 3315 there is text describing how DHCP = servers can indicate multiple servers by sending multiple options, and = can indicate multiple IP addresses on the same server by including them = in the same option. > * As you can notice, no normative language is used in the server = guideline section. This is to accommodate existing implementations.=20 An extension is required to get the behavior this document requires. = That is all that is needed for the document to be a protocol extension. = If you fail to specify the details of how that extension works, that = doesn't mean you haven't extended the protocol: it just means you've = done an incomplete job of it. > * There are already existing DHCP option specification documents which = allow to return multiple options (e.g., RFC 5908, RFC 6731, RFC 6784, = etc.) Yes, that's true. See above. > * What is important IMHO is to make sure the client is expecting to = receive multiple options.=20 That's certainly the most important part of this protocol extension, = yes. To be clear, it isn't enough that the client be prepared to = accept multiple options; clients can already do that. What is needed = is for the client to accept multiple options _and do the right thing_ = with them. From mohamed.boucadair@orange.com Tue Aug 13 08:05:51 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1151721E813B; Tue, 13 Aug 2013 08:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDWEsoSp8hyU; Tue, 13 Aug 2013 08:05:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2B521E8167; Tue, 13 Aug 2013 08:05:45 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id B94A9325BD6; Tue, 13 Aug 2013 17:05:44 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 7D3BA4C060; Tue, 13 Aug 2013 17:05:44 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 13 Aug 2013 17:05:44 +0200 From: To: Ted Lemon Date: Tue, 13 Aug 2013 17:05:42 +0200 Thread-Topic: [pcp] draft-ietf-pcp-dhcp: multiple pcp servers Thread-Index: Ac6YMkNrU0f2lDfGQdWaco5tLR+YAQAAK6tg Message-ID: <94C682931C08B048B7A8645303FDC9F36EEC7E99DA@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EEC7E9894@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36EEC7E99A8@PUEXCB1B.nanterre.francetelecom.fr> <5C06CABF-5797-484F-A8F9-ED2795CE0EE6@nominum.com> In-Reply-To: <5C06CABF-5797-484F-A8F9-ED2795CE0EE6@nominum.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.28.101520 Cc: "dhcwg@ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] draft-ietf-pcp-dhcp: multiple pcp servers X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 15:05:51 -0000 Re-, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Ted Lemon [mailto:ted.lemon@nominum.com] >Envoy=E9=A0: mardi 13 ao=FBt 2013 16:35 >=C0=A0: BOUCADAIR Mohamed IMT/OLN >Cc=A0: pcp@ietf.org >Objet=A0: Re: [pcp] draft-ietf-pcp-dhcp: multiple pcp servers > >On Aug 13, 2013, at 9:11 AM, mohamed.boucadair@orange.com wrote: > >> * The design does not extend RFC3315 which does not exclude an option to >appear several times. > >Yes, it does. This is why work of this sort needs to be done in the DHC >working group, not in the PCP working group: that is where the expertise o= n >DHCP is. [Med] Fully agree. Apologies for not ccing dhcwg earlier (now cced). The in= itial message can be found here: http://www.ietf.org/mail-archive/web/pcp/c= urrent/msg03327.html=20 You think that because it is possible to represent this data in >a DHCP packet, that no changes are required in the protocol. But in fact >in order to implement what you have documented in the current draft, all >DHCP servers and DHCP clients will have to be modified. That is what it >means to update the DHCP protocol. Show me where in RFC 3315 there is >text describing how DHCP servers can indicate multiple servers by sending >multiple options, and can indicate multiple IP addresses on the same serve= r >by including them in the same option. [Med] RFC3315 says the following: "Unless otherwise noted, each option may appear only in the options area of a DHCP message and may appear only once. If an option does appear multiple times, each instance is considered separate and the data areas of the options MUST NOT be concatenated or otherwise combined." RFC 3315 does not need to describe what is conveyed inside each instance of= the option and how that information is configured to the server. IMHO, thi= s is the responsibility of the option specification documents.=20 I agree there are some aspects which need to be discussed in a more generic= dhcp document such as the name resolution behavior at the dhcp server side= . What to do if both an IPv4 address and IPv6 addresses are returned, and s= o on. I'm referring to this text from the draft: The DHCP server may be configured with one or multiple FQDNs of the PCP server(s). In such case, the DHCP server must resolve these FQDNs into one or a list of IP addresses from pre-configured DNS server(s). If multiple FQDNs are configured to the DHCP server, the DHCP server must include multiple OPTION_PCP_SERVER instances; each of them carries one or a list of IP addresses that resulted from the FQDN resolution. DHCPv4 servers supporting PCP server option must resolve any configured FQDN into an IPv4 address while DHCPv6 servers may resolve any configured FQDN into an IPv6 and/or IPv4 address. If an IPv4 address is retrieved by the DHCPv6 server, the corresponding IPv4-mapped IPv6 address is included in the OPTION_PCP_SERVER DHPCv6 option. If both IPv4 and IPv6 addresses are retrieved by the DHCPv6 server, these addresses are included in the same OPTION_PCP_SERVER DHPCv6 option (IPv4 addresses are represented as IPv4-mapped IPv6 addresses). Discussion: The motivation for this design is to accommodate deployment cases where an IPv4 connectivity service is provided while only DHPCv6 is in use (e.g., an IPv4-only PCP server in a DS-Lite context [RFC6333]).=20 If this discussion is included in [I-D.lemon-dhc-topo-conf], this would be = great and will let me remove that text from this one. > >> * As you can notice, no normative language is used in the server >guideline section. This is to accommodate existing implementations. > >An extension is required to get the behavior this document requires. Tha= t >is all that is needed for the document to be a protocol extension. If yo= u >fail to specify the details of how that extension works, that doesn't mean >you haven't extended the protocol: it just means you've done an incomplete >job of it. [Med] That section is only about configuration not about protocol extension= . I see you call this protocol extension.=20 > >> * There are already existing DHCP option specification documents which >allow to return multiple options (e.g., RFC 5908, RFC 6731, RFC 6784, etc.= ) > >Yes, that's true. See above. > >> * What is important IMHO is to make sure the client is expecting to >receive multiple options. > >That's certainly the most important part of this protocol extension, yes. >To be clear, it isn't enough that the client be prepared to accept multipl= e >options; clients can already do that. What is needed is for the client t= o >accept multiple options _and do the right thing_ with them. [Med] Agree, this is why a normative reference to draft-ietf-pcp-server-sel= ection is cited. The WG decided to remove that part from this draft and spe= cify it in the generic pcp server selection I-D (which is not specific to d= hcp).=20 From tireddy@cisco.com Wed Aug 14 02:21:48 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC0521E8090 for ; Wed, 14 Aug 2013 02:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cilKMvB-5mnE for ; Wed, 14 Aug 2013 02:21:42 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id BC45A21E809D for ; Wed, 14 Aug 2013 02:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8643; q=dns/txt; s=iport; t=1376472101; x=1377681701; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PiKzr7OfJhRBl6e9bKt8d/+V0/ScAZtSoHpOIIvSzFo=; b=IdB5wCiq5pUy0haj1DTYn74t4nl01Zbb1pRQ9QO0I8AQ9bx/gwkD+Ec2 kJVvDLS+26pIc5V+GjiVjqpDAUIppGVe6ht4zaOp8HY6uVUZZutrgby7p V8QIXCxTuAHIEkysoCJSaHVVqe52Q/29FHFLlz3CZL+RuNiw37RoFno2t o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsHAOJKC1KtJV2c/2dsb2JhbABbgwY1UL5igSMWbQeCJAEBAQMBAQEBawsFBwQCAQgRBAEBAQodBycLFAkIAgQOBQgTh28GDLkmjm+BHDEHBoMVdgOIdZAckCSDG4FxOQ X-IronPort-AV: E=Sophos;i="4.89,875,1367971200"; d="scan'208";a="247211270" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 14 Aug 2013 09:21:38 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7E9Lcie032283 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Aug 2013 09:21:38 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.191]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 14 Aug 2013 04:21:38 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" Thread-Topic: [pcp] draft-ietf-pcp-dhcp: multiple pcp servers Thread-Index: AQHOmMMT3iKXDUtyYkegn5NsaBnqkZmUbG4Q Date: Wed, 14 Aug 2013 09:21:38 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1901F271@xmb-rcd-x10.cisco.com> References: <94C682931C08B048B7A8645303FDC9F36EEC7E9894@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] draft-ietf-pcp-dhcp: multiple pcp servers X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 09:21:48 -0000 I agree with Med, the current design should be maintained. The other reason= s would be: In scenario http://tools.ietf.org/html/draft-ietf-pcp-server-selection-01#a= ppendix-A.1 PCP client would want to send PCP request with FLOWDATA option = to=20 both rtr1 and rtr2, so that it can prioritize the source addresses (ICE hos= t candidates) based on FLOWDATA response (if the requested flow characteris= tics can be met or not or partially met). This mechanism will help the clie= nt (ICE agent) to get the responses directly from rtr1 and rtr2 which will = help to prioritize the ICE candidates and send offer/answer. we are working on a draft on How PCP can be used to influence the host's IC= E candidate selection algorithm and plan to use the current design which so= lves the problem for both multi-homing and MIF scenarios. --Tiru. =20 > On 13/08/13 11:56 AM, "mohamed.boucadair@orange.com" > wrote: >=20 > >Dear all, > > > >The design of the DHCP PCP option > >(http://tools.ietf.org/html/draft-ietf-pcp-dhcp-08) assumes: > >(1) multiple pcp servers may be received from the same DHCP server. > >(2) one pcp server may be reachable with multiple IP addresses. > >(3) when multiple pcp servers are returned, the pcp client will need to > >contact all these servers. > >(4) It is up to an administrative entity to return one or multiple pcp > >servers. No restriction is made by design. > > > >FWIW, this design was in the draft since -02. > > > >Dave is echo'ing a comment which objects this design and advocates for > >restricting the design to return only one pcp server and it is up to the > >administrative entity to sync the state in all enabled PCP servers. IMO, > >this objection is not technically sound, at least for the following > >reasons: > > > >(1) The protocol cannot discover in one single request all external IP > >addresses and port numbers. Imagine the case where a NPTv6 and NAT64 > >boxes are deployed. The PCP client has no means to learn with one single > >request to a single PCP server both the external IPv4 address (assigned > >by the NAT64 device) and the external IPv6 address assigned by the NPTv6 > >box. The same issue is encountered when multiple NAT configured with > >distinct pool are in place. > > > >(2) A host connected to a multi-homed domain, in which FW are located at > >the border router in front of each adjacent domain, will need to open > >pinholes in these FW if it want to receive incoming traffic from a remot= e > >peer. > > > >(3) The protocol does not specify how state synchronization is to be > >achieved between several PCP servers. The task is even complex when thes= e > >pcp servers are controlling functions of distinct types (e.g., NAT44, FW= , > >NAT64, Port Range Router, etc.). Other issues are raised (see to the > >pcp-server-selection thread) > > > >(4) Mandating one and only one pcp server is to be returned is really > >deployment-specific. This assumption will induce a lot of complexity at > >the network side > > > >For those who are objecting the design as currently documented in -07, i= t > >is time to raise your concern (preferably with the technical arguments > >that motivate your point). If no technical argument is made, the current > >design will be maintained as it is. > > > >Cheers, > >Med > > > >-----Message d'origine----- > >De : BOUCADAIR Mohamed OLNC/OLN > >Envoy=E9 : lundi 12 ao=FBt 2013 07:56 > >=C0 : 'Dave Thaler'; Ted Lemon > >Cc : Reinaldo Penno (repenno) (repenno@cisco.com); Dan Wing > >(dwing@cisco.com) > >Objet : RE: PCP DHCP I-D: your feedback is needed > > > >Hi Dave, > > > >I disagree to put the constraint on the network deploying many PCP > >servers to coordinate state instantiating. This is a deployment specific > >assumption which is not trivial to honor. > > > >A domain may deploy various pcp server controlling functions which are > >not of the same nature, e.g., a domain may deploy: > >* one or multiple nat64 provisioned to IPv6-only hosts > >* one or multiple nptv6 provisioned to IPv6-only and dual stack hosts > >* one or multiple nat44 provisioned to IPv4-only and dual stack hosts > >* one or multiple IPv4 fw > >* one or multiple IPv6 fw > >* multiple flow-based access routers > >* etc. > > > >The design as currently document in the pcp server selection draft (and > >its dhcp instantiation) does not make any deployment assumption. As such= : > >* an administrative entity can return one single IP address but instead > >it must ensure state are installed in other servers. > >* an administrative entity can return multiple servers; it is up to the > >client to contact these servers to install the state. > > > >This is much more better than constraining the design by non-valid > >deployment assumptions. > > > >I agree, this should be discussed in the list. > > > >Cheers, > >Med > > > >>-----Message d'origine----- > >>De : Dave Thaler [mailto:dthaler@microsoft.com] > >>Envoy=E9 : mercredi 7 ao=FBt 2013 19:56 > >>=C0 : Ted Lemon; BOUCADAIR Mohamed OLNC/OLN > >>Cc : Reinaldo Penno (repenno) (repenno@cisco.com); Dan Wing > >>(dwing@cisco.com) > >>Objet : RE: PCP DHCP I-D: your feedback is needed > >> > >>I think this thread should move to the main WG mailing list, so Ted if > >>you > >>agree, > >>please forward/respond on this thread there. > >> > >>This is related to my comments on draft-ietf-pcp-server-selection-01.tx= t. > >> > >>If the app needs semantics of "contact each PCP server" then you need t= o > >>know > >>how to distinguish PCP servers. Now more recently various members of t= he > >>WG (e.g. Stuart) have disputed the notion that an app needs to "contact > >>each PCP > >>server" and so we do not have consensus that this is required. Stuart > >>proposed > >>that it's the PCP server's job to coordinate with any other servers > >>managed > >>by > >>the same entity (or to steal a term from MIF... within the same > >>provisioning domain). > >>No one has given a counter argument, and so I said in email we should > >>start > >>with that > >>assumption. > >> > >>You do need to distinguish provisioning domains (for reasons discussed = in > >>MIF that > >>apply to PCP like they do to anything else). So the only remaining > >>interesting case > >>I think is figure 2 in section A.2 of draft-ietf-pcp-server-selection- > >>01.txt where if > >>you have a local gateway with a DHCP server (e.g. a home gateway) that'= s > >>multi-homed > >>to two external provisioning domains each with their own PCP server(s), > >>what do you > >>get from DHCP? I think the best answer here is to make the local gatew= ay > >>be a > >>PCP proxy, and so DHCP just gives you its address. > >> > >>In such a solution, I believe there is no need to differentiate between > >>multiple > >>IPs of the same server vs multiple IPs of different servers. That is, > >>you > >>communicate > >>with any one server IP, and you assume that it will take care of making > >>sure that > >>all servers with any of those IPs get the info. > >> > >>I believe this then removes any new concepts from DHCP and requires no > >>additional support in DHCP servers. > >> > >>-Dave > >> > >>> -----Original Message----- > >>> From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > >>> Sent: Wednesday, August 7, 2013 8:26 AM > >>> To: mohamed.boucadair@orange.com > >>> Cc: Dave Thaler; Reinaldo Penno (repenno) (repenno@cisco.com); Dan Wi= ng > >>> (dwing@cisco.com) > >>> Subject: Re: PCP DHCP I-D: your feedback is needed > >>> > >>> On Aug 7, 2013, at 3:00 AM, mohamed.boucadair@orange.com wrote: > >>> > Ok, done. > >>> > >>> Thanks. > >>> > >>> Can you explain your motivation for adding new text differentiating > >>between > >>> multiple IP addresses that refer to the same PCP server, and multiple > >>>IP > >>> addresses that refer to different PCP servers? Is this something th= e > >>working > >>> group asked to have added to the document? I think this is a new > >>concept in > >>> the current document, and of course, it requires special support in t= he > >>DHCP > >>> server and DHCP client just for PCP. > >>> > >>> This is not the only issue with your current set of edits to the > >>document, but > >>> I'd just like to get clarity on this one issue before proceeding on t= o > >>the next. > >>> > >> > >> > > > >_______________________________________________ > >pcp mailing list > >pcp@ietf.org > >https://www.ietf.org/mailman/listinfo/pcp From alper.yegin@yegin.org Wed Aug 14 10:00:56 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BAA21F9EF4 for ; Wed, 14 Aug 2013 10:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9MuVdyeH-8m for ; Wed, 14 Aug 2013 10:00:47 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 905EA21F994C for ; Wed, 14 Aug 2013 10:00:44 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Lw2r7-1WC9dl3d1x-017Wd7; Wed, 14 Aug 2013 13:00:43 -0400 From: Alper Yegin Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Aug 2013 20:00:44 +0300 Message-Id: <2E25F372-58FF-482F-9210-5526953A08D0@yegin.org> To: pcp@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:KOWQw6Apkzhf6gAVpF91VvExTxFU3LOYmhid7uFaPow ZLugUb3J1sBArljQiNDCXAth0NN0ARmDNXgT8VR0P6jLVi/4cJ KpPSeGEuTdZ/nHBHU4dA3/UMsWx/aRU6mbOJTd2sLWIoabzsm1 ozzxq+VqdDrkRRiAQaWy+3BLp6jzPN84uzZsHyDFAhD+E0vxt5 vaTis8S6RXAaIBLoqgwyRsEFD8rIh5/3GEPA6sMtl7JZHIVqce QTCOOpG08RKTf47se0aH5aSacZgzDX4JS7ngh+/AAosnPP5gN7 9eHA/oa3OkytGAYowDSuhxDEEHfyshsMwJNnBHuz4ordfwpcou tmGt1JV1nXRMjKfpHb28FJwHZ/CNzzdTxF+k3TGzkE0wQ23GzJ 15lsA8wKrCtNA== Subject: [pcp] draft-chen-pcp-mobile-deployment-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 17:00:56 -0000 Hello, Regarding the authentication considerations=85. Wouldn't a 3GPP network = be a candidate to use PCP w/o authentication? We could rely on lower-layer security as a substitute for PCP-layer = security (much like what DHCP does). Alper From tireddy@cisco.com Thu Aug 15 09:08:53 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C98711E8165 for ; Thu, 15 Aug 2013 09:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vq47Vxb8MXvI for ; Thu, 15 Aug 2013 09:08:44 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8614611E81E3 for ; Thu, 15 Aug 2013 09:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=578; q=dns/txt; s=iport; t=1376582924; x=1377792524; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=mlvqfN2kl69Eb5LopLcch3htDhuEQ0ka5DaJB20O8tU=; b=E+/nqghYZ/0aJOdfTLCIPkoyuz0kwdaM5/NkM2XxBcWGKLV0dzaivgEA eWh/lXshU13a3JQxWPH/XaRkIxC6hJCQffLMz4d/06ZvpG2QcPrWiMXap +dJV8SyYZMOOJl7hq0U/BNDz3lje/e6ooD3sCwZhhbBMPmBrUsicPMQdM 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowFALT8DFKtJXHA/2dsb2JhbABbgwaBBYJSvECBIRZ0giQBAQEDATpEBwQCAQgRBAEBCxQJBzIUCQgCBAESCIgCBrlwkB84BoMVdwOpNoMbgio X-IronPort-AV: E=Sophos;i="4.89,886,1367971200"; d="scan'208";a="247730113" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 15 Aug 2013 16:08:43 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7FG8hHh001557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Aug 2013 16:08:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.191]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 15 Aug 2013 11:08:43 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Alper Yegin , "pcp@ietf.org" Thread-Topic: [pcp] draft-chen-pcp-mobile-deployment-04 Thread-Index: AQHOmSB/3F0kWtX2802J7iT4q3jv2JmWKACg Date: Thu, 15 Aug 2013 16:08:43 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1902003F@xmb-rcd-x10.cisco.com> References: <2E25F372-58FF-482F-9210-5526953A08D0@yegin.org> In-Reply-To: <2E25F372-58FF-482F-9210-5526953A08D0@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.65.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] draft-chen-pcp-mobile-deployment-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 16:08:53 -0000 > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Wednesday, August 14, 2013 10:31 PM > To: pcp@ietf.org > Subject: [pcp] draft-chen-pcp-mobile-deployment-04 >=20 > Hello, >=20 > Regarding the authentication considerations.... Wouldn't a 3GPP network b= e a > candidate to use PCP w/o authentication ? Can you provide more details why in 3GPP network PCP auth is not required ? --Tiru. > We could rely on lower-layer security as a substitute for PCP-layer secur= ity > (much like what DHCP does). >=20 > Alper >=20 From alper.yegin@yegin.org Thu Aug 15 13:46:09 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E9F11E81B7 for ; Thu, 15 Aug 2013 13:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKfYXiv0pkPd for ; Thu, 15 Aug 2013 13:46:03 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA9011E81AF for ; Thu, 15 Aug 2013 13:45:59 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0Mhi8Z-1VWOdB0Ebb-00M61a; Thu, 15 Aug 2013 16:45:53 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <913383AAA69FF945B8F946018B75898A1902003F@xmb-rcd-x10.cisco.com> Date: Thu, 15 Aug 2013 23:45:51 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <241A5C64-7861-4501-A04E-DF3D99203E18@yegin.org> References: <2E25F372-58FF-482F-9210-5526953A08D0@yegin.org> <913383AAA69FF945B8F946018B75898A1902003F@xmb-rcd-x10.cisco.com> To: Tirumaleswar Reddy (tireddy) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:10+m2XoBHXJYRP2+XCzByZJtKE7gMI2kbvzR0/q+XHY AzNmbGyNk7a5Q/RuSBYhtsK+6fbEYQgppnaIr0u3N4IftLjVDj MwXp3YVFgz5nHFZEiyHtle+yovrPCnNYLxCA9FgLcQnzE3ByBS 6bJAlq+osd5Cr1yuHxlw+kW2pw2FrYMxCsoyJaXV2M1WVVrbEK 8YslruetOrAK7XEhh81XCS635kXD6eUuiln0rl5ZM7bhHRj727 u/fYWeMIx9mrxR2XWnaS50XikqvbtxpGbOeTM2LlBb/7xyzB/N D45xClhCnzBR8MXU11A44VC1nTXF5EAiacwwYqRc8iy4g1voVx JLig89CIRHZ9ESijX23IeLRpbliWdPSgpUlHJtLnvIEi6ySOqz gfiCG5XJTmKDA== Cc: "pcp@ietf.org" Subject: Re: [pcp] draft-chen-pcp-mobile-deployment-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 20:46:09 -0000 On Aug 15, 2013, at 7:08 PM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: Alper Yegin [mailto:alper.yegin@yegin.org] >> Sent: Wednesday, August 14, 2013 10:31 PM >> To: pcp@ietf.org >> Subject: [pcp] draft-chen-pcp-mobile-deployment-04 >>=20 >> Hello, >>=20 >> Regarding the authentication considerations.... Wouldn't a 3GPP = network be a >> candidate to use PCP w/o authentication ? >=20 > Can you provide more details why in 3GPP network PCP auth is not = required ? >=20 Both the PCP client and the PCP server are inside the 3GPP network which = is secured at L2. Alper > --Tiru. >=20 >> We could rely on lower-layer security as a substitute for PCP-layer = security >> (much like what DHCP does). >>=20 >> Alper >>=20 >=20 From cheshire@apple.com Thu Aug 15 19:06:51 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC56011E80F4 for ; Thu, 15 Aug 2013 19:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8RafhYl79VN for ; Thu, 15 Aug 2013 19:06:43 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id C3ECF11E8233 for ; Thu, 15 Aug 2013 19:06:43 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Received: from relay7.apple.com ([17.128.113.101]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MRL00L83PULSPZ0@mail-out.apple.com> for pcp@ietf.org; Thu, 15 Aug 2013 19:06:42 -0700 (PDT) X-AuditID: 11807165-b7f916d000007313-2e-520d89328d66 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id BB.4F.29459.2398D025; Thu, 15 Aug 2013 19:06:42 -0700 (PDT) Received: from chesh1.apple.com (chesh1.apple.com [17.193.13.41]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MRL00M4QPV54O40@spicerack.apple.com> for pcp@ietf.org; Thu, 15 Aug 2013 19:06:42 -0700 (PDT) From: Stuart Cheshire In-reply-to: <694128ccd41842df95f28fc29b7e0413@BY2PR03MB269.namprd03.prod.outlook.com> Date: Thu, 15 Aug 2013 19:06:41 -0700 Content-transfer-encoding: quoted-printable Message-id: <9AE1155A-BF2E-452B-9855-60B3F8B0AF37@apple.com> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> <3e7fd3c6a757446f8269079cecfffea0@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249F48@mbx-01.win.nominum.com> <913383AAA69FF945B8F946018B75898A1900EFA0@xmb-rcd-x10.cisco.com> <694128ccd41842df95f28fc29b7e0413@BY2PR03MB269.namprd03.prod.outlook.com> To: "pcp@ietf.org" X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUi2FCsoWvUyRtk0DOF32Lysd+sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuLXqMHvBdLmK3WcXszcwTpLoYuTkkBAwkeic8IENwhaTuHBv PZDNxSEkMJlJ4vLtR1DOCiaJmw9egVUxC2hJrN95nAnE5hXQk9g84wU7iC0s4Cjxen0HC4jN BlTz4vMVsHpOgQiJyVP+M4LYLAKqEivbbjNDzDGSWPz3EAuErS3x5N0FVoiZNhJ3D99igli8 hU2ia0EbWLOIgKLEgW03gJZxAJ0qK7Hzd9IERoFZSE6aheSkWUjGLmBkXsUoUJSak1hprpdY UJCTqpecn7uJERx6hak7GBuXWx1iFOBgVOLhjWjjDhJiTSwrrsw9xCjBwawkwrtOhTdIiDcl sbIqtSg/vqg0J7X4EKM0B4uSOO/9ryxBQgLpiSWp2ampBalFMFkmDk6pBsb5Jh2tXqVaR94V 3pr5TO215WQVyW87Pr723n7ddJbNxmNGyg8/LNhxfvbpx2lt8uKLj126LrjVV3y3lNoVF7ZP 20Tmn53+O6LvFv+MpbdPsSbKvhOrvfC128LWoO7IjZq3ZT06n1sNmvYummCyIaV6XtifxNlO ReqXLjw8On/C6ydh2+82KGztVGIpzkg01GIuKk4EAAAziuQ5AgAA Cc: draft-ietf-pcp-server-selection@tools.ietf.org Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 02:06:52 -0000 On 8 Aug, 2013, at 07:28, Dave Thaler wrote: > Stuart asserted that communicating with one is sufficient, and simpler = for the=20 > client, because it's the PCP server's job to communicate with the = other ones > to permit incoming ICE connectivity checks. If you disagree with = that, > please respond with a technical argument as to why having the client > communicate with both is better than having one server communicate=20 > with the other. Dave has represented my opinion accurately, but I'll elaborate a little. Today, a network client makes a NAT mapping (or a firewall hole) by = sending an outbound TCP SYN. That is all. If there are nested NATs, the = client doesn't have to know about that. If there are parallel NATs with = multiple network ingress and egress points, then the client doesn't have = to know about that either. The NAT that sees the outbound TCP SYN is = responsible for communicating with its NAT peers to ensure that the = right state is created so that inbound traffic is handled correctly. Right now the Mac OS X and iOS PCP client handles only a single PCP = server. I suspect it will only ever handle a single PCP server. I = suspect that many consumer electronics products like network security = cameras will also only support a single PCP server. So if you're a = network router vendor that's selling a product that lets the customer = load-balance across multiple ingress and egress paths, then you'd better = make it look like a single PCP server to the client, or it won't work = and you won't be able to sell it. If you're providing nested NAT, then = you'd better make it look *exactly* like a single PCP server to the = client (i.e. recursive PCP), or it won't work and you won't be able to = sell it. I had originally advocated that the PCP client sends its PCP requests to = a fixed well-known anycast address, and it's up to the network to do the = right thing with that. In a simple network with a single NAT, the NAT = intercepts the PCP request and handles it. In a more complicated = network, the network may have to do more complicated things, but that's = transparent to the client. However, I was not successful arguing for a fixed well-known any cast = address, so instead the client sends its requests to its default router. = I suspect Mac OS X and iOS may only ever send their PCP requests to = their default router. This means that if you want to sell some fancy network product that = supports parallel and/or nested NATs and firewalls, it had better work = with clients that only send requests to their default router, because = that's all you're going to see in the field for quite some time. It's easy to write documents telling PCP clients what they should be = doing, but I'd like to see some vendors stepping up and volunteering for = that commitment. Do we have a vendor of some $49 network security camera = volunteering to support multiple PCP servers? How would that even work? = If it requires *any* user configuration, it's a non-starter. Once you = accept manual user configuration, it's easier to just make some port = mappings by hand. The win of PCP is that it allows plug-and-play zero = configuration operation. The moment the user has to configure the device = with the address of its PCP server, it's easier to configure the NAT = gateway with a manual port mapping. And if you suppose a DHCP option to = do this configuration, the home gateway has to be updated to support = that DHCP option, and if you have to update the home gateway then it's = easier to put recursive PCP support into the gateway (works today with = all PCP clients) than it is to add support for the PCP DHCP option = (doesn't work until clients are updated to understand the new option). Stuart Cheshire From Ted.Lemon@nominum.com Thu Aug 15 19:37:31 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7AE21F9D96 for ; Thu, 15 Aug 2013 19:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VWb0FGChzJT for ; Thu, 15 Aug 2013 19:37:24 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id D2AE321F9F1F for ; Thu, 15 Aug 2013 19:36:54 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUg2QRjlRAT5a5gYoLu/PzpnRa+VpGfct@postini.com; Thu, 15 Aug 2013 19:36:54 PDT Received: by shell-too.nominum.com (Postfix, from userid 1029) id 44BF21B82B4; Thu, 15 Aug 2013 19:36:54 -0700 (PDT) To: pcp@ietf.org Message-Id: <20130816023654.44BF21B82B4@shell-too.nominum.com> Date: Thu, 15 Aug 2013 19:36:54 -0700 (PDT) From: Ted.Lemon@nominum.com (Ted Lemon) Subject: [pcp] Test, please ignore X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 02:37:31 -0000 Sorry for this test message, hopefully it will be moderated away. I am trying to figure out why whenever I reply to IETF mailing lists now my message goes into moderation. If you actually see this message please accept my apologies for disturbing you. From dwing@cisco.com Thu Aug 15 19:49:05 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D2F11E80D2 for ; Thu, 15 Aug 2013 19:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.044 X-Spam-Level: X-Spam-Status: No, score=-110.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSl6tGVUOgNG for ; Thu, 15 Aug 2013 19:49:00 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id BC5F221F9A33 for ; Thu, 15 Aug 2013 19:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4834; q=dns/txt; s=iport; t=1376621340; x=1377830940; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=jCsM3FlLLliDhR/jodwg9BZsFXh4Fsgo+3UGgmIJ0ig=; b=H0o60UtWN2vT0UixHYX/yBCSeyInXfXa7m/YKTPYZXZSMFi65Kz5pqD/ OdN0SnhZ3UFcc0dnu2LV+vT7fY5AvnRQ49RYqJLYRw5BPxrrdx8Eq6/In 0al2N+WjAvPYsS+6SKJ3920HvEABP6M6m/idiKrNAeV4xmWijC6QzEz62 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAAOSDVKrRDoH/2dsb2JhbABbgwY1v2WBJhZ0giQBAQEDAQEBAQssKwkLBQsjLicwBhMeh2wFDboNBJBQB4MbdwOJLY43kVKBYYFaHA X-IronPort-AV: E=Sophos;i="4.89,891,1367971200"; d="scan'208";a="89230501" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 16 Aug 2013 02:49:00 +0000 Received: from sjc-vpn5-1481.cisco.com (sjc-vpn5-1481.cisco.com [10.21.93.201]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7G2mwcG017838; Fri, 16 Aug 2013 02:48:58 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <9AE1155A-BF2E-452B-9855-60B3F8B0AF37@apple.com> Date: Thu, 15 Aug 2013 19:48:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6F41587A-A7F9-489B-BDD3-7954906AC664@cisco.com> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> <3e7fd3c6a757446f8269079cecfffea0@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249F48@mbx-01.win.nominum.com> <913383AAA69FF945B8F946018B75898A1900EFA0@xmb-rcd-x10.cisco.com> <694128ccd41842df95f28fc29b7e0413@BY2PR03MB269.namprd03.prod.outlook.com> <9AE1155A-BF2E-452B-9855-60B3F8B0AF37@apple.com> To: Stuart Cheshire X-Mailer: Apple Mail (2.1508) Cc: draft-ietf-pcp-server-selection@tools.ietf.org, "pcp@ietf.org" Subject: [pcp] well-known address for PCP [was Re: Comments on draft-ietf-pcp-server-selection-01] X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 02:49:05 -0000 On Aug 15, 2013, at 7:06 PM, Stuart Cheshire wrote: > On 8 Aug, 2013, at 07:28, Dave Thaler wrote: >=20 >> Stuart asserted that communicating with one is sufficient, and = simpler for the=20 >> client, because it's the PCP server's job to communicate with the = other ones >> to permit incoming ICE connectivity checks. If you disagree with = that, >> please respond with a technical argument as to why having the client >> communicate with both is better than having one server communicate=20 >> with the other. >=20 > Dave has represented my opinion accurately, but I'll elaborate a = little. >=20 > Today, a network client makes a NAT mapping (or a firewall hole) by = sending an outbound TCP SYN. That is all. If there are nested NATs, the = client doesn't have to know about that. If there are parallel NATs with = multiple network ingress and egress points, then the client doesn't have = to know about that either. The NAT that sees the outbound TCP SYN is = responsible for communicating with its NAT peers to ensure that the = right state is created so that inbound traffic is handled correctly. >=20 > Right now the Mac OS X and iOS PCP client handles only a single PCP = server. I suspect it will only ever handle a single PCP server. I = suspect that many consumer electronics products like network security = cameras will also only support a single PCP server. So if you're a = network router vendor that's selling a product that lets the customer = load-balance across multiple ingress and egress paths, then you'd better = make it look like a single PCP server to the client, or it won't work = and you won't be able to sell it. If you're providing nested NAT, then = you'd better make it look *exactly* like a single PCP server to the = client (i.e. recursive PCP), or it won't work and you won't be able to = sell it. >=20 > I had originally advocated that the PCP client sends its PCP requests = to a fixed well-known anycast address, and it's up to the network to do = the right thing with that. In a simple network with a single NAT, the = NAT intercepts the PCP request and handles it. In a more complicated = network, the network may have to do more complicated things, but that's = transparent to the client. >=20 > However, I was not successful arguing for a fixed well-known any cast = address, so instead the client sends its requests to its default router. = I suspect Mac OS X and iOS may only ever send their PCP requests to = their default router. We have encountered use cases where such a well-known anycast address = would be very useful, most notably with draft-wing-pcp-flowdata where an = existing non-PCP-aware router or NAT is in the local network and the ISP = is operating a PCP-speaking and draft-wing-pcp-flowdata-aware router, = and we want to use draft-wing-pcp-flowdata to ask the ISP to provide = differentiated service for a certain flow (e.g., make Skype or Netflix = work better than BitTorrent in the downstream direction). Reinaldo = wrote up draft-kiesel-pcp-ip-based-srv-disc, but as it wasn't on PCP's = agenda I have not researched how Reinaldo's proposal differs from = draft-cheshire-pcp-anycast. -d > This means that if you want to sell some fancy network product that = supports parallel and/or nested NATs and firewalls, it had better work = with clients that only send requests to their default router, because = that's all you're going to see in the field for quite some time. >=20 > It's easy to write documents telling PCP clients what they should be = doing, but I'd like to see some vendors stepping up and volunteering for = that commitment. Do we have a vendor of some $49 network security camera = volunteering to support multiple PCP servers? How would that even work? = If it requires *any* user configuration, it's a non-starter. Once you = accept manual user configuration, it's easier to just make some port = mappings by hand. The win of PCP is that it allows plug-and-play zero = configuration operation. The moment the user has to configure the device = with the address of its PCP server, it's easier to configure the NAT = gateway with a manual port mapping. And if you suppose a DHCP option to = do this configuration, the home gateway has to be updated to support = that DHCP option, and if you have to update the home gateway then it's = easier to put recursive PCP support into the gateway (works today with = all PCP clients) than it is to add support for the PCP DHCP option (d > oesn't work until clients are updated to understand the new option). >=20 > Stuart Cheshire >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From Ted.Lemon@nominum.com Thu Aug 15 20:25:59 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50E911E80E0 for ; Thu, 15 Aug 2013 20:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jk67a43iCXOJ for ; Thu, 15 Aug 2013 20:25:53 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD0211E80D2 for ; Thu, 15 Aug 2013 20:25:53 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUg2bwKg+SEse58azw7xqedfkJ6NMVLPe@postini.com; Thu, 15 Aug 2013 20:25:53 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8B51C1B827E for ; Thu, 15 Aug 2013 20:25:52 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7016919006C for ; Thu, 15 Aug 2013 20:25:52 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 15 Aug 2013 20:25:45 -0700 From: Ted Lemon To: PCP Working Group Thread-Topic: [pcp] Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6SN4UBylvrgKNiQjOEzEfANBzc7AAMCTHwAFEmB5AAD8zuAAAOFskA///lHYCAAHUBcP//jZOAgAB1A1CAAC9dQIAATVqwgAuey4D//8EZgIAASFUAgAAMqAA= Date: Fri, 16 Aug 2013 03:25:45 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307752576C9@mbx-01.win.nominum.com> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> <3e7fd3c6a757446f8269079cecfffea0@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249F48@mbx-01.win.nominum.com> <913383AAA69FF945B8F946018B75898A1900EFA0@xmb-rcd-x10.cisco.com> <694128ccd41842df95f28fc29b7e0413@BY2PR03MB269.namprd03.prod.outlook.com> <9AE1155A-BF2E-452B-9855-60B3F8B0AF37@apple.com> <8B8B0805-B3DD-40F5-AC46-86FFD553FE79@nominum.com> <090DFDE1-83C5-4C02-89BD-7321AA5EDD3A@cisco.com> In-Reply-To: <090DFDE1-83C5-4C02-89BD-7321AA5EDD3A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <6E389D8F68C87D42A2F97129BF6EBCE6@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 03:26:00 -0000 On Aug 15, 2013, at 10:40 PM, Dan Wing wrote: > Only one of them would get a TCP SYN that the host sends off the local ne= twork. Same logic -- whatever that logic -- would determine which default = router is used by PCP. Hm, well, right. So there's only one PCP server in this situation. You t= hink you configured two, but only one will ever be used, until we have supp= ort for multiple provisioning domains. From repenno@cisco.com Fri Aug 16 02:58:56 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B86811E812B for ; Fri, 16 Aug 2013 02:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGfDbjuWiveW for ; Fri, 16 Aug 2013 02:58:51 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8F52911E8106 for ; Fri, 16 Aug 2013 02:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5841; q=dns/txt; s=iport; t=1376647131; x=1377856731; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=LQodFtrO6/widwRHTHDsbKpb0rbUzZ6lh45B1BVYul0=; b=E2GPv5G14Hkbz0roYch3T3NOzgdNmv/yolEIsOaojieEF2pB/FsToge0 2o77InSySn4o2ReCR6f8a1jdRM6XWf61CvUJ6OMI/HGJrDDzjtSAU4s5F /yFdDKs8mjUPBDORnP6dWYXN/G49mQdFanVzHrlU8UVNd/7+QR7Jo3YA0 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAAH3DVKtJV2a/2dsb2JhbABbgwY1Ub8cgScWdIIkAQEBBAEBAQssKwkLEgEIGAoUNwslAgQBDQUIFodyDLorBJAfMQeDG3cDqTmBYYE7gio X-IronPort-AV: E=Sophos;i="4.89,894,1367971200"; d="scan'208";a="248064054" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 16 Aug 2013 09:58:50 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7G9wokL018221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 16 Aug 2013 09:58:50 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.180]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 16 Aug 2013 04:58:50 -0500 From: "Reinaldo Penno (repenno)" To: "Dan Wing (dwing)" , Stuart Cheshire Thread-Topic: [pcp] well-known address for PCP [was Re: Comments on draft-ietf-pcp-server-selection-01] Thread-Index: AQHOmmc0rl9rS2/1kU2afkfK7VJyRQ== Date: Fri, 16 Aug 2013 09:58:49 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604091093CD@xmb-rcd-x04.cisco.com> In-Reply-To: <6F41587A-A7F9-489B-BDD3-7954906AC664@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.243.101] Content-Type: text/plain; charset="us-ascii" Content-ID: <6D128586A69F4D40ACADB91A7B556A51@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-pcp-server-selection@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] well-known address for PCP [was Re: Comments on draft-ietf-pcp-server-selection-01] X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 09:58:56 -0000 We discussed it during the meeting and offline a few times. There is basically a lot of overlap between the two proposals. The difference is what should be done when there are two PCP Servers in the network. The classical case is asymmetric routing where PCP Servers are firewalls. Other cases are associated with FLOW data such as getting info from network as to what is the most appropriate link to use, etc. Some folks believe firewalls should synch state amongst themselves. Others believe PCP client should discover and talk to both PCP Servers. The crux of the issue is where do you want to put the burden. A PCP Server vendor for enterprises, ISPs might want the client to carry its weight and a client vendor probably wants the server to do all work. -Reinaldo On 8/15/13 11:48 PM, "Dan Wing" wrote: > >On Aug 15, 2013, at 7:06 PM, Stuart Cheshire wrote: > >> On 8 Aug, 2013, at 07:28, Dave Thaler wrote: >>=20 >>> Stuart asserted that communicating with one is sufficient, and simpler >>>for the=20 >>> client, because it's the PCP server's job to communicate with the >>>other ones >>> to permit incoming ICE connectivity checks. If you disagree with that, >>> please respond with a technical argument as to why having the client >>> communicate with both is better than having one server communicate >>> with the other. >>=20 >> Dave has represented my opinion accurately, but I'll elaborate a little. >>=20 >> Today, a network client makes a NAT mapping (or a firewall hole) by >>sending an outbound TCP SYN. That is all. If there are nested NATs, the >>client doesn't have to know about that. If there are parallel NATs with >>multiple network ingress and egress points, then the client doesn't have >>to know about that either. The NAT that sees the outbound TCP SYN is >>responsible for communicating with its NAT peers to ensure that the >>right state is created so that inbound traffic is handled correctly. >>=20 >> Right now the Mac OS X and iOS PCP client handles only a single PCP >>server. I suspect it will only ever handle a single PCP server. I >>suspect that many consumer electronics products like network security >>cameras will also only support a single PCP server. So if you're a >>network router vendor that's selling a product that lets the customer >>load-balance across multiple ingress and egress paths, then you'd better >>make it look like a single PCP server to the client, or it won't work >>and you won't be able to sell it. If you're providing nested NAT, then >>you'd better make it look *exactly* like a single PCP server to the >>client (i.e. recursive PCP), or it won't work and you won't be able to >>sell it. >>=20 >> I had originally advocated that the PCP client sends its PCP requests >>to a fixed well-known anycast address, and it's up to the network to do >>the right thing with that. In a simple network with a single NAT, the >>NAT intercepts the PCP request and handles it. In a more complicated >>network, the network may have to do more complicated things, but that's >>transparent to the client. >>=20 >> However, I was not successful arguing for a fixed well-known any cast >>address, so instead the client sends its requests to its default router. >>I suspect Mac OS X and iOS may only ever send their PCP requests to >>their default router. > >We have encountered use cases where such a well-known anycast address >would be very useful, most notably with draft-wing-pcp-flowdata where an >existing non-PCP-aware router or NAT is in the local network and the ISP >is operating a PCP-speaking and draft-wing-pcp-flowdata-aware router, and >we want to use draft-wing-pcp-flowdata to ask the ISP to provide >differentiated service for a certain flow (e.g., make Skype or Netflix >work better than BitTorrent in the downstream direction). Reinaldo wrote >up draft-kiesel-pcp-ip-based-srv-disc, but as it wasn't on PCP's agenda I >have not researched how Reinaldo's proposal differs from >draft-cheshire-pcp-anycast. > >-d > > >> This means that if you want to sell some fancy network product that >>supports parallel and/or nested NATs and firewalls, it had better work >>with clients that only send requests to their default router, because >>that's all you're going to see in the field for quite some time. >>=20 >> It's easy to write documents telling PCP clients what they should be >>doing, but I'd like to see some vendors stepping up and volunteering for >>that commitment. Do we have a vendor of some $49 network security camera >>volunteering to support multiple PCP servers? How would that even work? >>If it requires *any* user configuration, it's a non-starter. Once you >>accept manual user configuration, it's easier to just make some port >>mappings by hand. The win of PCP is that it allows plug-and-play zero >>configuration operation. The moment the user has to configure the device >>with the address of its PCP server, it's easier to configure the NAT >>gateway with a manual port mapping. And if you suppose a DHCP option to >>do this configuration, the home gateway has to be updated to support >>that DHCP option, and if you have to update the home gateway then it's >>easier to put recursive PCP support into the gateway (works today with >>all PCP clients) than it is to add support for the PCP DHCP option > (d >> oesn't work until clients are updated to understand the new option). >>=20 >> Stuart Cheshire >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From tireddy@cisco.com Fri Aug 16 03:52:59 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAC411E8101 for ; Fri, 16 Aug 2013 03:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PyfDUTsMVKm for ; Fri, 16 Aug 2013 03:52:54 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0072F11E812D for ; Fri, 16 Aug 2013 03:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1450; q=dns/txt; s=iport; t=1376650374; x=1377859974; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pUippmFoiqOIS0Cg1GFMgE1R+Wub/EjR3kyDwEBU3rY=; b=VUJ6MY5ooAYw+zSLdiG9ierSYi7AAoB/DIos2Kkj02ldviU+1IIGpFtD EfS8k7RtDLE33kpA/kUUPwD5eALnmIBFUWFveRn+DQYXUxOGFOsMSErLi QVov3BLWkhKOPmtDZUKJbx1JG6JSWaEntrhpeX/ekeRms2yhQNIVmMaON E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAG8DDlKtJXG8/2dsb2JhbABbgwaBBr8cgSYWdIIkAQEBAwE6PwwEAgEIEQQBAQEKFAkHMhQJCAIEDgUIiAIGugiOeYEmMQcGgxV3A6k5gxyBcTk X-IronPort-AV: E=Sophos;i="4.89,894,1367971200"; d="scan'208";a="248065518" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 16 Aug 2013 10:52:53 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7GAqr03016200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 16 Aug 2013 10:52:53 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.191]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Fri, 16 Aug 2013 05:52:52 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Alper Yegin Thread-Topic: [pcp] draft-chen-pcp-mobile-deployment-04 Thread-Index: AQHOmSB/3F0kWtX2802J7iT4q3jv2JmWKACggADqa4CAAB3oAA== Date: Fri, 16 Aug 2013 10:52:52 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A1902060D@xmb-rcd-x10.cisco.com> References: <2E25F372-58FF-482F-9210-5526953A08D0@yegin.org> <913383AAA69FF945B8F946018B75898A1902003F@xmb-rcd-x10.cisco.com> <241A5C64-7861-4501-A04E-DF3D99203E18@yegin.org> In-Reply-To: <241A5C64-7861-4501-A04E-DF3D99203E18@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.71.212] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] draft-chen-pcp-mobile-deployment-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 10:52:59 -0000 > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Friday, August 16, 2013 2:16 AM > To: Tirumaleswar Reddy (tireddy) > Cc: pcp@ietf.org > Subject: Re: [pcp] draft-chen-pcp-mobile-deployment-04 >=20 >=20 > On Aug 15, 2013, at 7:08 PM, Tirumaleswar Reddy (tireddy) wrote: >=20 > >> -----Original Message----- > >> From: Alper Yegin [mailto:alper.yegin@yegin.org] > >> Sent: Wednesday, August 14, 2013 10:31 PM > >> To: pcp@ietf.org > >> Subject: [pcp] draft-chen-pcp-mobile-deployment-04 > >> > >> Hello, > >> > >> Regarding the authentication considerations.... Wouldn't a 3GPP networ= k be > a > >> candidate to use PCP w/o authentication ? > > > > Can you provide more details why in 3GPP network PCP auth is not requir= ed ? > > >=20 > Both the PCP client and the PCP server are inside the 3GPP network which = is > secured at L2. Yes, but in various scenarios like PMIPv6 - Mobile Node (MN) will be access= ing the PCP server in the Home network (3GPP network) through MAG but local= access network (Hot Spot) may not offer L2 security. Hence I think the rec= ommendation should be for PCP server in 3GPP network to support PCP authent= ication. --Tiru. >=20 > Alper >=20 >=20 >=20 >=20 >=20 > > --Tiru. > > > >> We could rely on lower-layer security as a substitute for PCP-layer > security > >> (much like what DHCP does). > >> > >> Alper > >> > > From dwing@cisco.com Fri Aug 16 07:31:00 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B878311E8226 for ; Fri, 16 Aug 2013 07:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.229 X-Spam-Level: X-Spam-Status: No, score=-110.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKlwsURcxGlM for ; Fri, 16 Aug 2013 07:30:56 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4733A11E80FA for ; Fri, 16 Aug 2013 07:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6772; q=dns/txt; s=iport; t=1376663456; x=1377873056; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=kmWi/Ky72e6PaxemBr8CFGwIp8dD9M9U920zv8Bserc=; b=eUQ+mbK6dqBuz/easzFvtnIjhIO70/AM2YZtwhhe3MPD35GiUhgL5Lf0 xLrTXB3xTk9yTGUQgR1AwsxSJcYhJcDPaFBCCF6hIlsDnYFoY1OAL4cX6 m9C3X+Q7MHYIILHENhgmQNuPTsHvdcLl+Ls6v4133EDSW9bzE9/jPlwD6 s=; X-IronPort-AV: E=Sophos;i="4.89,895,1367971200"; d="scan'208";a="89327225" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 16 Aug 2013 14:30:55 +0000 Received: from sjc-vpn5-1481.cisco.com (sjc-vpn5-1481.cisco.com [10.21.93.201]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7GEUrFg013669; Fri, 16 Aug 2013 14:30:53 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604091093CD@xmb-rcd-x04.cisco.com> Date: Fri, 16 Aug 2013 07:30:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9B758849-679E-45DF-AE8C-DCE4BE08123A@cisco.com> References: <45A697A8FFD7CF48BCF2BE7E106F0604091093CD@xmb-rcd-x04.cisco.com> To: Reinaldo Penno (repenno) X-Mailer: Apple Mail (2.1508) Cc: Stuart Cheshire , "draft-ietf-pcp-server-selection@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] well-known address for PCP [was Re: Comments on draft-ietf-pcp-server-selection-01] X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 14:31:00 -0000 On Aug 16, 2013, at 2:58 AM, Reinaldo Penno (repenno) = wrote: > We discussed it during the meeting and offline a few times. There is > basically a lot of overlap between the two proposals. The difference = is > what should be done when there are two PCP Servers in the network. The > classical case is asymmetric routing where PCP Servers are firewalls. > Other cases are associated with FLOW data such as getting info from > network as to what is the most appropriate link to use, etc. >=20 > Some folks believe firewalls should synch state amongst themselves. = Others > believe PCP client should discover and talk to both PCP Servers. The = crux > of the issue is where do you want to put the burden. A PCP Server = vendor > for enterprises, ISPs might want the client to carry its weight and a > client vendor probably wants the server to do all work. Yes, that was discussed at the meeting. But if there is one, and only one, IANA-assigned PCP server address = (anycast address), the design questions around firewall synchronization = and communicating to multiple PCP servers fall out, because there is = only one IANA-assigned PCP server address and thus only one PCP server. = If the host has multiple interfaces, there can be one PCP server on each = interface, but that does not create the problems you describe above. -d > -Reinaldo >=20 >=20 >=20 > On 8/15/13 11:48 PM, "Dan Wing" wrote: >=20 >>=20 >> On Aug 15, 2013, at 7:06 PM, Stuart Cheshire = wrote: >>=20 >>> On 8 Aug, 2013, at 07:28, Dave Thaler wrote: >>>=20 >>>> Stuart asserted that communicating with one is sufficient, and = simpler >>>> for the=20 >>>> client, because it's the PCP server's job to communicate with the >>>> other ones >>>> to permit incoming ICE connectivity checks. If you disagree with = that, >>>> please respond with a technical argument as to why having the = client >>>> communicate with both is better than having one server communicate >>>> with the other. >>>=20 >>> Dave has represented my opinion accurately, but I'll elaborate a = little. >>>=20 >>> Today, a network client makes a NAT mapping (or a firewall hole) by >>> sending an outbound TCP SYN. That is all. If there are nested NATs, = the >>> client doesn't have to know about that. If there are parallel NATs = with >>> multiple network ingress and egress points, then the client doesn't = have >>> to know about that either. The NAT that sees the outbound TCP SYN is >>> responsible for communicating with its NAT peers to ensure that the >>> right state is created so that inbound traffic is handled correctly. >>>=20 >>> Right now the Mac OS X and iOS PCP client handles only a single PCP >>> server. I suspect it will only ever handle a single PCP server. I >>> suspect that many consumer electronics products like network = security >>> cameras will also only support a single PCP server. So if you're a >>> network router vendor that's selling a product that lets the = customer >>> load-balance across multiple ingress and egress paths, then you'd = better >>> make it look like a single PCP server to the client, or it won't = work >>> and you won't be able to sell it. If you're providing nested NAT, = then >>> you'd better make it look *exactly* like a single PCP server to the >>> client (i.e. recursive PCP), or it won't work and you won't be able = to >>> sell it. >>>=20 >>> I had originally advocated that the PCP client sends its PCP = requests >>> to a fixed well-known anycast address, and it's up to the network to = do >>> the right thing with that. In a simple network with a single NAT, = the >>> NAT intercepts the PCP request and handles it. In a more complicated >>> network, the network may have to do more complicated things, but = that's >>> transparent to the client. >>>=20 >>> However, I was not successful arguing for a fixed well-known any = cast >>> address, so instead the client sends its requests to its default = router. >>> I suspect Mac OS X and iOS may only ever send their PCP requests to >>> their default router. >>=20 >> We have encountered use cases where such a well-known anycast address >> would be very useful, most notably with draft-wing-pcp-flowdata where = an >> existing non-PCP-aware router or NAT is in the local network and the = ISP >> is operating a PCP-speaking and draft-wing-pcp-flowdata-aware router, = and >> we want to use draft-wing-pcp-flowdata to ask the ISP to provide >> differentiated service for a certain flow (e.g., make Skype or = Netflix >> work better than BitTorrent in the downstream direction). Reinaldo = wrote >> up draft-kiesel-pcp-ip-based-srv-disc, but as it wasn't on PCP's = agenda I >> have not researched how Reinaldo's proposal differs from >> draft-cheshire-pcp-anycast. >>=20 >> -d >>=20 >>=20 >>> This means that if you want to sell some fancy network product that >>> supports parallel and/or nested NATs and firewalls, it had better = work >>> with clients that only send requests to their default router, = because >>> that's all you're going to see in the field for quite some time. >>>=20 >>> It's easy to write documents telling PCP clients what they should be >>> doing, but I'd like to see some vendors stepping up and volunteering = for >>> that commitment. Do we have a vendor of some $49 network security = camera >>> volunteering to support multiple PCP servers? How would that even = work? >>> If it requires *any* user configuration, it's a non-starter. Once = you >>> accept manual user configuration, it's easier to just make some port >>> mappings by hand. The win of PCP is that it allows plug-and-play = zero >>> configuration operation. The moment the user has to configure the = device >>> with the address of its PCP server, it's easier to configure the NAT >>> gateway with a manual port mapping. And if you suppose a DHCP option = to >>> do this configuration, the home gateway has to be updated to support >>> that DHCP option, and if you have to update the home gateway then = it's >>> easier to put recursive PCP support into the gateway (works today = with >>> all PCP clients) than it is to add support for the PCP DHCP option >> (d >>> oesn't work until clients are updated to understand the new option). >>>=20 >>> Stuart Cheshire >>>=20 >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >=20 From eckert@cisco.com Sat Aug 17 01:01:23 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B55121F9CAD for ; Sat, 17 Aug 2013 01:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.209 X-Spam-Level: X-Spam-Status: No, score=-9.209 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, PLING_QUERY=1.39, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuIDDDTIH0Gr for ; Sat, 17 Aug 2013 01:01:18 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 60F9221F99DE for ; Sat, 17 Aug 2013 01:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1458; q=dns/txt; s=iport; t=1376726478; x=1377936078; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=G2Ceadb8ui71Xed0kgQMxO6S2MHxdM3VJO/kTsuq4hc=; b=QBCNCcHwZ/dQwX9jtRCKtBmzDJE9V/poE4xQzovnBqS/HBln2vgFovNW lSUq5vPWquph+rfXIR+8IkgDKg/wVAbfGveWEbJqgm3Y5FWIlqT7n92QY YSK3NU4vWV/PxwJkOZ9SPzBWAoTvQq3Ukm8GyEJQEwUvieqTUzxg9O3Rf Y=; X-IronPort-AV: E=Sophos;i="4.89,900,1367971200"; d="scan'208";a="89316644" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 17 Aug 2013 08:01:15 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7H81Ebl000943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Aug 2013 08:01:14 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r7H81EwW015706; Sat, 17 Aug 2013 01:01:14 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r7H81Dr3015703; Sat, 17 Aug 2013 01:01:13 -0700 Date: Sat, 17 Aug 2013 01:01:13 -0700 From: Toerless Eckert To: Dan Wing , Reinaldo Penno , Stuart Cheshire Message-ID: <20130817080113.GA15272@cisco.com> References: <45A697A8FFD7CF48BCF2BE7E106F0604091093CD@xmb-rcd-x04.cisco.com> <9B758849-679E-45DF-AE8C-DCE4BE08123A@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9B758849-679E-45DF-AE8C-DCE4BE08123A@cisco.com> User-Agent: Mutt/1.4.2.2i Cc: "draft-ietf-pcp-server-selection@tools.ietf.org" , pcp@ietf.org Subject: [pcp] Multiple anycast adresses for PCP server selection... ?! (yes, to be on the safe side). X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 08:01:23 -0000 In general, i am a big fan of anycast, but i am not sure i feel comfortable understanding all the challenges using it with PCP target deployment cases. To elaborate a bit more on a case that i am worried about: Anycast will make people (ok: me) think that we can get PCP to work even if the maybe best onpath devices do not support it. So if i assume that the home-gateway and access-node (both the best onpath devices) can for some reasons not support PCP and i start putting PCP onto some nearby devices, eg: The main media-center in the home and some "server" in the PCP. Great. Beng able to do this was one benefit of not using a strict onpath signaling method with PCP. But how do i do this with ONE anycast address. Assume the PCP server in the home uses that anycast address. It will have a real tough time sending packets to the same anycast address to reach the server in the POP. That's why i suggested we may want at least to ask for a few anycast addresses, and then figure out how to use them. For example, clients would always only have to know adress1, PCP server in the home binds to adress1, but sends (as proxy) to address2, which would reach then the PCP server in the POP. The server in the POP could of corse listen to both adress1 and address2, so that the PCP server in the POP could listen to eg: address1, address2, so it will work whether or not there is a PCP server in the home. Cheers Toerless From zehn.cao@gmail.com Mon Aug 19 01:00:29 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96DF11E820C for ; Mon, 19 Aug 2013 01:00:28 -0700 (PDT) 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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHy7P+aSFvBl for ; Mon, 19 Aug 2013 01:00:28 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBE411E8211 for ; Mon, 19 Aug 2013 01:00:27 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so3215947wgg.0 for ; Mon, 19 Aug 2013 01:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vy6cyFkj1+LI7wN0eVMYoKKs2sdwan9q5S8o5h637BE=; b=RJkO/hxaYH5pe5gm9tZqBPKUT/mHFX5dUidGImh6ZaBT5rCwCwUzy5MUmtONWAqrLi Ped9v+B4pz3Bcm7xFZQQhEJDj5UrNj+TZ1tf4r5Arf1z80er0pUb5NYecyKDeLAHr577 8kb45PEmtK1G2ifx3QpOZ/vKFjVt6QAOJfKXX1Apii0yFo6YCXZTUD6wZxawmHcNuHWn yjm1caZAh10qRLoU2wG61xTWATc8WWUSWhBVoyAXw9n5upoV5+/KPMKTGmauscgIA72k pWJ+jrQvjnvbTDdiib6ltTUd4BdTaMtnOfbNzQQUuYjyo3uxRxUeOS7GDKCcIB+gvfOK A/2A== MIME-Version: 1.0 X-Received: by 10.180.100.225 with SMTP id fb1mr7180877wib.22.1376899226588; Mon, 19 Aug 2013 01:00:26 -0700 (PDT) Received: by 10.216.90.201 with HTTP; Mon, 19 Aug 2013 01:00:26 -0700 (PDT) In-Reply-To: <241A5C64-7861-4501-A04E-DF3D99203E18@yegin.org> References: <2E25F372-58FF-482F-9210-5526953A08D0@yegin.org> <913383AAA69FF945B8F946018B75898A1902003F@xmb-rcd-x10.cisco.com> <241A5C64-7861-4501-A04E-DF3D99203E18@yegin.org> Date: Mon, 19 Aug 2013 16:00:26 +0800 Message-ID: From: "Cao,Zhen" To: Alper Yegin Content-Type: text/plain; charset=ISO-8859-1 Cc: "pcp@ietf.org" , Tirumaleswar Reddy Subject: Re: [pcp] draft-chen-pcp-mobile-deployment-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 08:00:29 -0000 >> Can you provide more details why in 3GPP network PCP auth is not required ? >> > > Both the PCP client and the PCP server are inside the 3GPP network which is secured at L2. The PCP server may be a standalone server on the Gi-LAN, where the 3GPP layer 2 protection does not suffice? -cz From mohamed.boucadair@orange.com Mon Aug 19 02:49:08 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2173711E8211 for ; Mon, 19 Aug 2013 02:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3z3NujD-O-oP for ; Mon, 19 Aug 2013 02:49:03 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9C12621F9C2C for ; Mon, 19 Aug 2013 02:49:02 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 0C5FE22E7FE; Mon, 19 Aug 2013 11:49:02 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id E281B27C077; Mon, 19 Aug 2013 11:49:01 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 19 Aug 2013 11:49:01 +0200 From: To: Stuart Cheshire , "pcp@ietf.org" Date: Mon, 19 Aug 2013 11:48:59 +0200 Thread-Topic: [pcp] Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6aJUl4JUqiKpWkQHOXqtS1RBeedwCms6vg Message-ID: <94C682931C08B048B7A8645303FDC9F36EEDD8AF96@PUEXCB1B.nanterre.francetelecom.fr> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> <3e7fd3c6a757446f8269079cecfffea0@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249F48@mbx-01.win.nominum.com> <913383AAA69FF945B8F946018B75898A1900EFA0@xmb-rcd-x10.cisco.com> <694128ccd41842df95f28fc29b7e0413@BY2PR03MB269.namprd03.prod.outlook.com> <9AE1155A-BF2E-452B-9855-60B3F8B0AF37@apple.com> In-Reply-To: <9AE1155A-BF2E-452B-9855-60B3F8B0AF37@apple.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.19.70322 Cc: "draft-ietf-pcp-server-selection@tools.ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 09:49:08 -0000 Stuart, What you described is really deployment-specific with a focus on the CPE de= ployment model. There are other deployment cases where PCP can be used to interact with mul= tiple servers and not one, e.g.,: * non-NAT devices in order to allow for incoming packets to be forwarded ap= propriated to an internal host: a typical example is a multi-homed site whi= ch cannot force the entry point to be used by incoming packets. If you have= a firewall in each Border Router, you will need typically to open pinholes= in those FW. * NAT devices which assigns addresses of distinct address families. A typic= al example is two devices: the first one is a NAT64 while the second one is= NPTv6. The discovery of the external IPv4 address assigned by the NAT64 an= d the external IPv6 address assigned by the NPTv6 is need to help establish= ing communications with remote IPvx hosts. * multi-interfaces device which interfaces with multiple flow-aware access = router. * Etc. Because this is deployment-specific, draft-ietf-pcp-server-selection does n= ot assume how many servers will be enabled. It does specify the behavior to= accommodate any deployment model: * having one server to contact (with one or multiple IP addresses) * contact multiple servers in parallel. Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >Stuart Cheshire >Envoy=E9=A0: vendredi 16 ao=FBt 2013 04:07 >=C0=A0: pcp@ietf.org >Cc=A0: draft-ietf-pcp-server-selection@tools.ietf.org >Objet=A0: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 > >On 8 Aug, 2013, at 07:28, Dave Thaler wrote: > >> Stuart asserted that communicating with one is sufficient, and simpler >for the >> client, because it's the PCP server's job to communicate with the other >ones >> to permit incoming ICE connectivity checks. If you disagree with that, >> please respond with a technical argument as to why having the client >> communicate with both is better than having one server communicate >> with the other. > >Dave has represented my opinion accurately, but I'll elaborate a little. > >Today, a network client makes a NAT mapping (or a firewall hole) by sendin= g >an outbound TCP SYN. That is all. If there are nested NATs, the client >doesn't have to know about that. If there are parallel NATs with multiple >network ingress and egress points, then the client doesn't have to know >about that either. The NAT that sees the outbound TCP SYN is responsible >for communicating with its NAT peers to ensure that the right state is >created so that inbound traffic is handled correctly. > >Right now the Mac OS X and iOS PCP client handles only a single PCP server= . >I suspect it will only ever handle a single PCP server. I suspect that man= y >consumer electronics products like network security cameras will also only >support a single PCP server. So if you're a network router vendor that's >selling a product that lets the customer load-balance across multiple >ingress and egress paths, then you'd better make it look like a single PCP >server to the client, or it won't work and you won't be able to sell it. I= f >you're providing nested NAT, then you'd better make it look *exactly* like >a single PCP server to the client (i.e. recursive PCP), or it won't work >and you won't be able to sell it. > >I had originally advocated that the PCP client sends its PCP requests to a >fixed well-known anycast address, and it's up to the network to do the >right thing with that. In a simple network with a single NAT, the NAT >intercepts the PCP request and handles it. In a more complicated network, >the network may have to do more complicated things, but that's transparent >to the client. > >However, I was not successful arguing for a fixed well-known any cast >address, so instead the client sends its requests to its default router. I >suspect Mac OS X and iOS may only ever send their PCP requests to their >default router. > >This means that if you want to sell some fancy network product that >supports parallel and/or nested NATs and firewalls, it had better work wit= h >clients that only send requests to their default router, because that's al= l >you're going to see in the field for quite some time. > >It's easy to write documents telling PCP clients what they should be doing= , >but I'd like to see some vendors stepping up and volunteering for that >commitment. Do we have a vendor of some $49 network security camera >volunteering to support multiple PCP servers? How would that even work? If >it requires *any* user configuration, it's a non-starter. Once you accept >manual user configuration, it's easier to just make some port mappings by >hand. The win of PCP is that it allows plug-and-play zero configuration >operation. The moment the user has to configure the device with the addres= s >of its PCP server, it's easier to configure the NAT gateway with a manual >port mapping. And if you suppose a DHCP option to do this configuration, >the home gateway has to be updated to support that DHCP option, and if you >have to update the home gateway then it's easier to put recursive PCP >support into the gateway (works today with all PCP clients) than it is to >add support for the PCP DHCP option (d > oesn't work until clients are updated to understand the new option). > >Stuart Cheshire > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Mon Aug 19 02:51:05 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B50221F88B7 for ; Mon, 19 Aug 2013 02:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgLtJEKSB7gc for ; Mon, 19 Aug 2013 02:50:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 404C921F889C for ; Mon, 19 Aug 2013 02:50:59 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 0B75E3B5F8E; Mon, 19 Aug 2013 11:50:58 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id DD5BA27C05B; Mon, 19 Aug 2013 11:50:57 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 19 Aug 2013 11:50:57 +0200 From: To: Dan Wing , Ted Lemon Date: Mon, 19 Aug 2013 11:50:56 +0200 Thread-Topic: [pcp] Comments on draft-ietf-pcp-server-selection-01 Thread-Index: Ac6aKf/L739wwXgjS+S0Ud2Kv7rA5wCl2vHw Message-ID: <94C682931C08B048B7A8645303FDC9F36EEDD8AF97@PUEXCB1B.nanterre.francetelecom.fr> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> <3e7fd3c6a757446f8269079cecfffea0@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249F48@mbx-01.win.nominum.com> <913383AAA69FF945B8F946018B75898A1900EFA0@xmb-rcd-x10.cisco.com> <694128ccd41842df95f28fc29b7e0413@BY2PR03MB269.namprd03.prod.outlook.com> <9AE1155A-BF2E-452B-9855-60B3F8B0AF37@apple.com> <8B8B0805-B3DD-40F5-AC46-86FFD553FE79@nominum.com> <090DFDE1-83C5-4C02-89BD-7321AA5EDD3A@cisco.com> In-Reply-To: <090DFDE1-83C5-4C02-89BD-7321AA5EDD3A@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.19.70322 Cc: Stuart Cheshire , "draft-ietf-pcp-server-selection@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 09:51:05 -0000 Hi Dan, That's does not work for incoming packets in some specific cases. Imagine t= wo default routers with PCP-controlled firewall function.=20 Cheers, Med >-----Message d'origine----- >De=A0: Dan Wing [mailto:dwing@cisco.com] >Envoy=E9=A0: vendredi 16 ao=FBt 2013 04:40 >=C0=A0: Ted Lemon >Cc=A0: Stuart Cheshire; pcp@; draft-ietf-pcp-server-selection@tools.ietf.o= rg >Objet=A0: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 > > >On Aug 15, 2013, at 7:21 PM, Ted Lemon wrote: > >> On Aug 15, 2013, at 10:06 PM, Stuart Cheshire wrote= : >>> However, I was not successful arguing for a fixed well-known any cast >address, so instead the client sends its requests to its default router. I >suspect Mac OS X and iOS may only ever send their PCP requests to their >default router. >> >> Wait, what? What happens if there are two default routers? > >Only one of them would get a TCP SYN that the host sends off the local >network. Same logic -- whatever that logic -- would determine which >default router is used by PCP. > >-d From mohamed.boucadair@orange.com Mon Aug 19 04:20:57 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7476E21F997A for ; Mon, 19 Aug 2013 04:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC9NiSnbGz3w for ; Mon, 19 Aug 2013 04:20:52 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D8CF621F99AD for ; Mon, 19 Aug 2013 04:20:47 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 7F7D922E7B1; Mon, 19 Aug 2013 13:20:44 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 58967238061; Mon, 19 Aug 2013 13:20:44 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Mon, 19 Aug 2013 13:20:43 +0200 From: To: Dan Wing , Stuart Cheshire Date: Mon, 19 Aug 2013 13:20:40 +0200 Thread-Topic: [pcp] well-known address for PCP [was Re: Comments on draft-ietf-pcp-server-selection-01] Thread-Index: Ac6aKy82RiuXg2XZSBWJ6vmfnYVNGQCoSv8A Message-ID: <94C682931C08B048B7A8645303FDC9F36EEDD8AFBC@PUEXCB1B.nanterre.francetelecom.fr> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> <3e7fd3c6a757446f8269079cecfffea0@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249F48@mbx-01.win.nominum.com> <913383AAA69FF945B8F946018B75898A1900EFA0@xmb-rcd-x10.cisco.com> <694128ccd41842df95f28fc29b7e0413@BY2PR03MB269.namprd03.prod.outlook.com> <9AE1155A-BF2E-452B-9855-60B3F8B0AF37@apple.com> <6F41587A-A7F9-489B-BDD3-7954906AC664@cisco.com> In-Reply-To: <6F41587A-A7F9-489B-BDD3-7954906AC664@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: "draft-ietf-pcp-server-selection@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] well-known address for PCP [was Re: Comments on draft-ietf-pcp-server-selection-01] X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 11:20:57 -0000 Dan, For the typical use case you mentioned (i.e., PCP service operated by an op= erator), having an explicit provisioning means to enabled/disable PCP servi= ce is more likely for various reasons such as: * Avoid overloading the network with useless traffic (e.g., limit the usage= of radio resources for the mobile network).=20 * Flow-based access control policies may not be managed by an on-path devic= e (e.g., separate PCP server and PCP-controlled device model) * Multiple flow-based policies may be enforced at multiple entry points. Ha= ving a means to interact with all of them in // is likely to be required. * The node which enforces the flow-based policies may not be able to relay = the request to another upstream PCP-controlled device (e.g., not explicitly= configured to do so) * The anycast-based model will require Epoch values are appropriately confi= gured in multiple servers listening on the same address; if not the client = won't be able to detect state loss when a failure occurs. * The anycast-based model cannot work in the proxy model if non-explicit se= rver(s) is configured to the proxy: this is a simple forwarding issue (the = proxy should listen on anycast address and use that same address to reach t= he upstream server). =20 Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Da= n >Wing >Envoy=E9=A0: vendredi 16 ao=FBt 2013 04:49 >=C0=A0: Stuart Cheshire >Cc=A0: draft-ietf-pcp-server-selection@tools.ietf.org; pcp@ietf.org >Objet=A0: [pcp] well-known address for PCP [was Re: Comments on draft-ietf= - >pcp-server-selection-01] > > >On Aug 15, 2013, at 7:06 PM, Stuart Cheshire wrote: > >> On 8 Aug, 2013, at 07:28, Dave Thaler wrote: >> >>> Stuart asserted that communicating with one is sufficient, and simpler >for the >>> client, because it's the PCP server's job to communicate with the other >ones >>> to permit incoming ICE connectivity checks. If you disagree with that, >>> please respond with a technical argument as to why having the client >>> communicate with both is better than having one server communicate >>> with the other. >> >> Dave has represented my opinion accurately, but I'll elaborate a little. >> >> Today, a network client makes a NAT mapping (or a firewall hole) by >sending an outbound TCP SYN. That is all. If there are nested NATs, the >client doesn't have to know about that. If there are parallel NATs with >multiple network ingress and egress points, then the client doesn't have t= o >know about that either. The NAT that sees the outbound TCP SYN is >responsible for communicating with its NAT peers to ensure that the right >state is created so that inbound traffic is handled correctly. >> >> Right now the Mac OS X and iOS PCP client handles only a single PCP >server. I suspect it will only ever handle a single PCP server. I suspect >that many consumer electronics products like network security cameras will >also only support a single PCP server. So if you're a network router vendo= r >that's selling a product that lets the customer load-balance across >multiple ingress and egress paths, then you'd better make it look like a >single PCP server to the client, or it won't work and you won't be able to >sell it. If you're providing nested NAT, then you'd better make it look >*exactly* like a single PCP server to the client (i.e. recursive PCP), or >it won't work and you won't be able to sell it. >> >> I had originally advocated that the PCP client sends its PCP requests to >a fixed well-known anycast address, and it's up to the network to do the >right thing with that. In a simple network with a single NAT, the NAT >intercepts the PCP request and handles it. In a more complicated network, >the network may have to do more complicated things, but that's transparent >to the client. >> >> However, I was not successful arguing for a fixed well-known any cast >address, so instead the client sends its requests to its default router. I >suspect Mac OS X and iOS may only ever send their PCP requests to their >default router. > >We have encountered use cases where such a well-known anycast address woul= d >be very useful, most notably with draft-wing-pcp-flowdata where an existin= g >non-PCP-aware router or NAT is in the local network and the ISP is >operating a PCP-speaking and draft-wing-pcp-flowdata-aware router, and we >want to use draft-wing-pcp-flowdata to ask the ISP to provide >differentiated service for a certain flow (e.g., make Skype or Netflix wor= k >better than BitTorrent in the downstream direction). Reinaldo wrote up >draft-kiesel-pcp-ip-based-srv-disc, but as it wasn't on PCP's agenda I hav= e >not researched how Reinaldo's proposal differs from draft-cheshire-pcp- >anycast. > >-d > > >> This means that if you want to sell some fancy network product that >supports parallel and/or nested NATs and firewalls, it had better work wit= h >clients that only send requests to their default router, because that's al= l >you're going to see in the field for quite some time. >> >> It's easy to write documents telling PCP clients what they should be >doing, but I'd like to see some vendors stepping up and volunteering for >that commitment. Do we have a vendor of some $49 network security camera >volunteering to support multiple PCP servers? How would that even work? If >it requires *any* user configuration, it's a non-starter. Once you accept >manual user configuration, it's easier to just make some port mappings by >hand. The win of PCP is that it allows plug-and-play zero configuration >operation. The moment the user has to configure the device with the addres= s >of its PCP server, it's easier to configure the NAT gateway with a manual >port mapping. And if you suppose a DHCP option to do this configuration, >the home gateway has to be updated to support that DHCP option, and if you >have to update the home gateway then it's easier to put recursive PCP >support into the gateway (works today with all PCP clients) than it is to >add support for the PCP DHCP option > (d >> oesn't work until clients are updated to understand the new option). >> >> Stuart Cheshire >> >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Mon Aug 19 06:12:02 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7AC11E8276 for ; Mon, 19 Aug 2013 06:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y25XNktDwIkL for ; Mon, 19 Aug 2013 06:11:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 343A211E827C for ; Mon, 19 Aug 2013 06:11:57 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 287CB22E533 for ; Mon, 19 Aug 2013 15:11:56 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 111AB4C060 for ; Mon, 19 Aug 2013 15:11:56 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 19 Aug 2013 15:11:55 +0200 From: To: "pcp@ietf.org" Date: Mon, 19 Aug 2013 15:11:53 +0200 Thread-Topic: I-D Action: draft-boucadair-pcp-deployment-cases-00.txt Thread-Index: Ac6c3Jpe5ECfRjo+S2SSSvl5Ih6EtAAAN87A Message-ID: <94C682931C08B048B7A8645303FDC9F36EEDD8B020@PUEXCB1B.nanterre.francetelecom.fr> References: <20130819130358.6339.30812.idtracker@ietfa.amsl.com> In-Reply-To: <20130819130358.6339.30812.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.28.101520 Subject: [pcp] TR: I-D Action: draft-boucadair-pcp-deployment-cases-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 13:12:02 -0000 FYI. The document lists many PCP deployment models.=20 This document can be used to understand the impact of the use of anycast ad= dress(es). Cheers, Med -----Message d'origine----- De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]= De la part de internet-drafts@ietf.org Envoy=E9=A0: lundi 19 ao=FBt 2013 15:04 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-boucadair-pcp-deployment-cases-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : PCP Deployment Models Author(s) : Mohamed Boucadair Filename : draft-boucadair-pcp-deployment-cases-00.txt Pages : 11 Date : 2013-08-19 Abstract: This document lists a set of PCP deployment models. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-pcp-deployment-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-pcp-deployment-cases-00 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From dwing@cisco.com Mon Aug 19 09:40:44 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D7011E8136 for ; Mon, 19 Aug 2013 09:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.322 X-Spam-Level: X-Spam-Status: No, score=-110.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mqIQKpZ9htJ for ; Mon, 19 Aug 2013 09:40:39 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 946C111E812F for ; Mon, 19 Aug 2013 09:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1731; q=dns/txt; s=iport; t=1376930439; x=1378140039; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=SwHkHN9MEujPuFhZwNdBI1lJjU3dFUY9Pgj317XkOms=; b=gJRMAL1/E+Z/ia+z9tSKBMeEbu52qEjkvJgK5wH9xPyj3bP0DtmzXKI0 yyQAxvkVYNDjauQSO2YP8zA+5XuydS8WATe2Txt3w7Oy08xlKIhTeBG/T ZdgLQvRKEx3y0CTppdrsOVG8bUaGG1Uy6RM8Gsy9zWryxyH+e9vHHBWft 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHZJElKrRDoH/2dsb2JhbABagwfAOIEhFnSCJAEBAQMBeQULCxgnB0YRGYgKBbZIkC0zBxaDBXcDiS2ON4YpiyyDPBw X-IronPort-AV: E=Sophos;i="4.89,914,1367971200"; d="scan'208";a="89535435" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 19 Aug 2013 16:40:38 +0000 Received: from [10.21.102.166] ([10.21.102.166]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7JGeaIq004755; Mon, 19 Aug 2013 16:40:36 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEDD8AF97@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 19 Aug 2013 09:40:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <36A7AF65-73DB-43EC-B52E-B1D369F693CD@cisco.com> References: <30b1cc1894564c29940db80068308797@BN1PR03MB267.namprd03.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36EE99C9035@PUEXCB1B.nanterre.francetelecom.fr> <09252e8f703e474e94db05bcf38d6571@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249BED@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775249E3D@mbx-01.win.nominum.com> <3e7fd3c6a757446f8269079cecfffea0@BY2PR03MB269.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775249F48@mbx-01.win.nominum.com> <913383AAA69FF945B8F946018B75898A1900EFA0@xmb-rcd-x10.cisco.com> <694128ccd41842df95f28fc29b7e0413@BY2PR03MB269.namprd03.prod.outlook.com> <9AE1155A-BF2E-452B-9855-60B3F8B0AF37@apple.com> <8B8B0805-B3DD-40F5-AC46-86FFD553FE79@nominum.com> <090DFDE1-83C5-4C02-89BD-7321AA5EDD3A@cisco.com> <94C682931C08B048B7A8645303FDC9F36EEDD8AF9 7@PUEXCB1B.nanterre.francetelecom.fr> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.1508) Cc: Stuart Cheshire , "draft-ietf-pcp-server-selection@tools.ietf.org" , "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 16:40:45 -0000 On Aug 19, 2013, at 2:50 AM, mohamed.boucadair@orange.com wrote: > Hi Dan, >=20 > That's does not work for incoming packets in some specific cases. = Imagine two default routers with PCP-controlled firewall function.=20 You're describing a situation where we use MAP to 'listen', and accept = connections on both of those different networks. Yes, that works = differently than sending a TCP SYN. For that to work with an anycast = address, the two PCP-controlled firewalls would have to synchronize = state amongst themselves, or don't use anycast in such a network = topology and leave the PCP client to communicate with the several PCP = servers itself. -d >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Dan Wing [mailto:dwing@cisco.com] >> Envoy=E9 : vendredi 16 ao=FBt 2013 04:40 >> =C0 : Ted Lemon >> Cc : Stuart Cheshire; pcp@; = draft-ietf-pcp-server-selection@tools.ietf.org >> Objet : Re: [pcp] Comments on draft-ietf-pcp-server-selection-01 >>=20 >>=20 >> On Aug 15, 2013, at 7:21 PM, Ted Lemon wrote: >>=20 >>> On Aug 15, 2013, at 10:06 PM, Stuart Cheshire = wrote: >>>> However, I was not successful arguing for a fixed well-known any = cast >> address, so instead the client sends its requests to its default = router. I >> suspect Mac OS X and iOS may only ever send their PCP requests to = their >> default router. >>>=20 >>> Wait, what? What happens if there are two default routers? >>=20 >> Only one of them would get a TCP SYN that the host sends off the = local >> network. Same logic -- whatever that logic -- would determine which >> default router is used by PCP. >>=20 >> -d >=20 From sebi@gw01.ehlo.wurstkaes.de Mon Aug 19 13:33:21 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662A411E82C5 for ; Mon, 19 Aug 2013 13:33:21 -0700 (PDT) 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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAbocOblskMX for ; Mon, 19 Aug 2013 13:33:21 -0700 (PDT) Received: from gw01.ehlo.wurstkaes.de (gw01.ehlo.wurstkaes.de [IPv6:2a02:a00:e000:116::41]) by ietfa.amsl.com (Postfix) with ESMTP id D264911E80EF for ; Mon, 19 Aug 2013 13:33:20 -0700 (PDT) Received: from sebi by gw01.ehlo.wurstkaes.de with local (Exim 4.72) (envelope-from ) id 1VBW8T-0006OA-GR; Mon, 19 Aug 2013 22:33:09 +0200 Date: Mon, 19 Aug 2013 22:33:09 +0200 From: Sebastian Kiesel To: mohamed.boucadair@orange.com Message-ID: <20130819203309.GB1867@gw01.ehlo.wurstkaes.de> References: <20130626134028.17581.26454.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> Accept-Languages: en, de Organization: my personal mail account User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "pcp@ietf.org" Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 20:33:21 -0000 Hi, On Wed, Jun 26, 2013 at 05:04:52PM +0200, mohamed.boucadair@orange.com wrote: > Dear all, > > I submitted this short I-D to explain how PCP can be used in IPv6 SIP deployments (with a focus on the managed networks case). > Objet: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt I have read this draft and I think this is a very interesting topic. However, it is not very clear to me what the key message of this draft is. I think there are at least two topics that deserve investigation and discussion, with different target audiences: 1. A gap analysis for PCP, i.e., tell the PCP folks what should be changed or added to PCP to better support this use case (if any). 2. Tell the SIP folks about PCP and its benefits. IMO this chapter should start with a short discussion what's new compared to older (managed) NAT/Firewall traversal approaches, e.g., MIDCOM [RFC5190, RFC4540] and NSIS [RFC5973]. Is the interaction really straightforward, or are there any pitfalls (e.g., [draft-kiesel-mmusic-firewall-sip-00]) to consider? Cheers Sebastian From mohamed.boucadair@orange.com Mon Aug 19 22:23:30 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DB711E81B1 for ; Mon, 19 Aug 2013 22:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX3jx2Lxvoj9 for ; Mon, 19 Aug 2013 22:23:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 06CD821F9E00 for ; Mon, 19 Aug 2013 22:23:23 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id A4C1C3B658F; Tue, 20 Aug 2013 07:23:20 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 8BCA24C06B; Tue, 20 Aug 2013 07:23:20 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Tue, 20 Aug 2013 07:23:20 +0200 From: To: Sebastian Kiesel Date: Tue, 20 Aug 2013 07:23:18 +0200 Thread-Topic: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt Thread-Index: Ac6dG1fo0T6ILevaRvi9u44vqQwwDQASL8uw Message-ID: <94C682931C08B048B7A8645303FDC9F36EEDD8B0E7@PUEXCB1B.nanterre.francetelecom.fr> References: <20130626134028.17581.26454.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> <20130819203309.GB1867@gw01.ehlo.wurstkaes.de> In-Reply-To: <20130819203309.GB1867@gw01.ehlo.wurstkaes.de> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.28.101520 Cc: "pcp@ietf.org" Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 05:23:30 -0000 Hi Sebastien, IMO, the PCP WG has adopted required extensions to ease SIP deployments (e.= g., preserve parity, contiguous ports, discover nat64 prefix, etc.). This i= s why the main motivation for writing the document was your point (2): the = document is to be seen as a dissemination effort towards SIP community to l= et them be aware about PCP and how PCP can solve complications encountered = in SIP environments.=20 The document was on purpose scoped to the managed networks case (this is th= e widely deployed SIP model). Considerations on how PCP can be of great hel= p to ICE & cie are discussed in another document (e.g., ICE-lite, firewall = traversal, etc.). Any contribution and suggestions to better enhance the document, its readab= ility, raise new issues, etc. are more than welcome.=20 Cheers, Med=20 >-----Message d'origine----- >De=A0: Sebastian Kiesel [mailto:ietf-pcp@skiesel.de] >Envoy=E9=A0: lundi 19 ao=FBt 2013 22:33 >=C0=A0: BOUCADAIR Mohamed IMT/OLN >Cc=A0: pcp@ietf.org >Objet=A0: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt > >Hi, > >On Wed, Jun 26, 2013 at 05:04:52PM +0200, mohamed.boucadair@orange.com >wrote: >> Dear all, >> >> I submitted this short I-D to explain how PCP can be used in IPv6 SIP >deployments (with a focus on the managed networks case). > >> Objet: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt > >I have read this draft and I think this is a very interesting topic. >However, it is not very clear to me what the key message of this draft is. > >I think there are at least two topics that deserve investigation and >discussion, with different target audiences: > >1. A gap analysis for PCP, i.e., tell the PCP folks what should be >changed or added to PCP to better support this use case (if any). > >2. Tell the SIP folks about PCP and its benefits. IMO this chapter >should start with a short discussion what's new compared to older >(managed) NAT/Firewall traversal approaches, e.g., MIDCOM [RFC5190, >RFC4540] and NSIS [RFC5973]. Is the interaction really straightforward, >or are there any pitfalls (e.g., [draft-kiesel-mmusic-firewall-sip-00]) to >consider? > > >Cheers >Sebastian From sebi@gw01.ehlo.wurstkaes.de Tue Aug 20 05:19:10 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA3111E80D5 for ; Tue, 20 Aug 2013 05:19:10 -0700 (PDT) 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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJ3x49XDDXCb for ; Tue, 20 Aug 2013 05:19:09 -0700 (PDT) Received: from gw01.ehlo.wurstkaes.de (gw01.ehlo.wurstkaes.de [IPv6:2a02:a00:e000:116::41]) by ietfa.amsl.com (Postfix) with ESMTP id C594D11E8217 for ; Tue, 20 Aug 2013 05:19:08 -0700 (PDT) Received: from sebi by gw01.ehlo.wurstkaes.de with local (Exim 4.72) (envelope-from ) id 1VBkts-0003RQ-6a; Tue, 20 Aug 2013 14:19:04 +0200 Date: Tue, 20 Aug 2013 14:19:04 +0200 From: Sebastian Kiesel To: mohamed.boucadair@orange.com Message-ID: <20130820121904.GC1867@gw01.ehlo.wurstkaes.de> References: <20130626134028.17581.26454.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> <20130819203309.GB1867@gw01.ehlo.wurstkaes.de> <94C682931C08B048B7A8645303FDC9F36EEDD8B0E7@PUEXCB1B.nanterre.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EEDD8B0E7@PUEXCB1B.nanterre.francetelecom.fr> Accept-Languages: en, de Organization: my personal mail account User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "pcp@ietf.org" Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 12:19:10 -0000 Hi Med, if the goal is dissemination IMO there should be a "what's new compared to other approaches" section - the SIP/RTP-NAT/Firewall traversal problem is not new after all. On the one hand, there are the "hole punching" and relay based approaches, e.g., STUN/TURN/ICE, which do not directly interact with the NAT/firewall. Probably more suitable for unmanaged networks, so no need to go into details. Btw: how do you define "managed network case"? On the other hand, there are the approaches based on signaling to the NAT/Firewall, and PCP is really not the first protocol that falls into this category. There were attempts inside IETF (MIDCOM, SIMCO, NSIS) and outside (UPnP, H.248), so what's new? just my 2 cents... Sebastian On Tue, Aug 20, 2013 at 07:23:18AM +0200, mohamed.boucadair@orange.com wrote: > Hi Sebastien, > > IMO, the PCP WG has adopted required extensions to ease SIP > deployments (e.g., preserve parity, contiguous ports, discover nat64 > prefix, etc.). This is why the main motivation for writing the > document was your point (2): the document is to be seen as a > dissemination effort towards SIP community to let them be aware about > PCP and how PCP can solve complications encountered in SIP > environments. > > The document was on purpose scoped to the managed networks case (this > is the widely deployed SIP model). Considerations on how PCP can be of > great help to ICE & cie are discussed in another document (e.g., > ICE-lite, firewall traversal, etc.). > > Any contribution and suggestions to better enhance the document, its > readability, raise new issues, etc. are more than welcome. > > Cheers, > Med > > >-----Message d'origine----- > >De : Sebastian Kiesel [mailto:ietf-pcp@skiesel.de] > >Envoyé : lundi 19 août 2013 22:33 > >À : BOUCADAIR Mohamed IMT/OLN > >Cc : pcp@ietf.org > >Objet : Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt > > > >Hi, > > > >On Wed, Jun 26, 2013 at 05:04:52PM +0200, mohamed.boucadair@orange.com > >wrote: > >> Dear all, > >> > >> I submitted this short I-D to explain how PCP can be used in IPv6 SIP > >deployments (with a focus on the managed networks case). > > > >> Objet: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt > > > >I have read this draft and I think this is a very interesting topic. > >However, it is not very clear to me what the key message of this draft is. > > > >I think there are at least two topics that deserve investigation and > >discussion, with different target audiences: > > > >1. A gap analysis for PCP, i.e., tell the PCP folks what should be > >changed or added to PCP to better support this use case (if any). > > > >2. Tell the SIP folks about PCP and its benefits. IMO this chapter > >should start with a short discussion what's new compared to older > >(managed) NAT/Firewall traversal approaches, e.g., MIDCOM [RFC5190, > >RFC4540] and NSIS [RFC5973]. Is the interaction really straightforward, > >or are there any pitfalls (e.g., [draft-kiesel-mmusic-firewall-sip-00]) to > >consider? > > > > > >Cheers > >Sebastian From mohamed.boucadair@orange.com Tue Aug 20 06:35:01 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CDF11E80D9 for ; Tue, 20 Aug 2013 06:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjDUOVRly7TZ for ; Tue, 20 Aug 2013 06:34:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9288B11E80C5 for ; Tue, 20 Aug 2013 06:34:51 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id D4D7718D4EF; Tue, 20 Aug 2013 15:34:50 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id B7DF435C045; Tue, 20 Aug 2013 15:34:50 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Tue, 20 Aug 2013 15:34:50 +0200 From: To: Sebastian Kiesel Date: Tue, 20 Aug 2013 15:34:49 +0200 Thread-Topic: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt Thread-Index: Ac6dn3g7krAQqIVmRw2GFyL2uDkyOwACe/aQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EEDD8B242@PUEXCB1B.nanterre.francetelecom.fr> References: <20130626134028.17581.26454.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> <20130819203309.GB1867@gw01.ehlo.wurstkaes.de> <94C682931C08B048B7A8645303FDC9F36EEDD8B0E7@PUEXCB1B.nanterre.francetelecom.fr> <20130820121904.GC1867@gw01.ehlo.wurstkaes.de> In-Reply-To: <20130820121904.GC1867@gw01.ehlo.wurstkaes.de> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.20.72416 Cc: "pcp@ietf.org" Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 13:35:01 -0000 Re-, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: Sebastian Kiesel [mailto:ietf-pcp@skiesel.de] >Envoy=E9=A0: mardi 20 ao=FBt 2013 14:19 >=C0=A0: BOUCADAIR Mohamed IMT/OLN >Cc=A0: pcp@ietf.org >Objet=A0: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt > >Hi Med, > >if the goal is dissemination IMO there should be a "what's new compared >to other approaches" section - the SIP/RTP-NAT/Firewall traversal >problem is not new after all. [Med] Agree. > >On the one hand, there are the "hole punching" and relay based >approaches, e.g., STUN/TURN/ICE, which do not directly interact >with the NAT/firewall. Probably more suitable for unmanaged networks, >so no need to go into details. > >Btw: how do you define "managed network case"? [Med] managed network refers to the deployment scenario where both the serv= ice infrastructure and the underlying network infrastructure are operated b= y the same administrative entity. This will be added to the next revision o= f the draft. > >On the other hand, there are the approaches based on signaling to the >NAT/Firewall, and PCP is really not the first protocol that falls into >this category. There were attempts inside IETF (MIDCOM, SIMCO, NSIS) >and outside (UPnP, H.248), so what's new? [Med] For example parity bit preservation, contiguous port set and the disc= overy of PREFIX64 to ease NAT64 are all new features not supported by none = of the mechanisms you listed. > >just my 2 cents... >Sebastian > > >On Tue, Aug 20, 2013 at 07:23:18AM +0200, mohamed.boucadair@orange.com >wrote: >> Hi Sebastien, >> >> IMO, the PCP WG has adopted required extensions to ease SIP >> deployments (e.g., preserve parity, contiguous ports, discover nat64 >> prefix, etc.). This is why the main motivation for writing the >> document was your point (2): the document is to be seen as a >> dissemination effort towards SIP community to let them be aware about >> PCP and how PCP can solve complications encountered in SIP >> environments. >> >> The document was on purpose scoped to the managed networks case (this >> is the widely deployed SIP model). Considerations on how PCP can be of >> great help to ICE & cie are discussed in another document (e.g., >> ICE-lite, firewall traversal, etc.). >> >> Any contribution and suggestions to better enhance the document, its >> readability, raise new issues, etc. are more than welcome. >> >> Cheers, >> Med >> >> >-----Message d'origine----- >> >De=A0: Sebastian Kiesel [mailto:ietf-pcp@skiesel.de] >> >Envoy=E9=A0: lundi 19 ao=FBt 2013 22:33 >> >=C0=A0: BOUCADAIR Mohamed IMT/OLN >> >Cc=A0: pcp@ietf.org >> >Objet=A0: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt >> > >> >Hi, >> > >> >On Wed, Jun 26, 2013 at 05:04:52PM +0200, mohamed.boucadair@orange.com >> >wrote: >> >> Dear all, >> >> >> >> I submitted this short I-D to explain how PCP can be used in IPv6 SIP >> >deployments (with a focus on the managed networks case). >> > >> >> Objet: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt >> > >> >I have read this draft and I think this is a very interesting topic. >> >However, it is not very clear to me what the key message of this draft >is. >> > >> >I think there are at least two topics that deserve investigation and >> >discussion, with different target audiences: >> > >> >1. A gap analysis for PCP, i.e., tell the PCP folks what should be >> >changed or added to PCP to better support this use case (if any). >> > >> >2. Tell the SIP folks about PCP and its benefits. IMO this chapter >> >should start with a short discussion what's new compared to older >> >(managed) NAT/Firewall traversal approaches, e.g., MIDCOM [RFC5190, >> >RFC4540] and NSIS [RFC5973]. Is the interaction really straightforward, >> >or are there any pitfalls (e.g., [draft-kiesel-mmusic-firewall-sip-00]) >to >> >consider? >> > >> > >> >Cheers >> >Sebastian From repenno@cisco.com Fri Aug 23 02:56:05 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD1511E821F for ; Fri, 23 Aug 2013 02:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FA3EZGAOCvGZ for ; Fri, 23 Aug 2013 02:56:00 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 424AE11E8169 for ; Fri, 23 Aug 2013 02:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1005; q=dns/txt; s=iport; t=1377251760; x=1378461360; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=ckggKpFuZm00dVGhbWqlDqNyi1UUuJG1EMh/IXGG8Ro=; b=SbcqS5nTxoonp0IQDb0205SXqB9GtKTIFsnMmK/z8jxDHcIMd3XX8UPI Nl68vM134fIWsc6fitY/Ob8Vgdv9DmrPBUtRcBGMSdWky0thUaY3btXEr KAWCKYpBegN1/yJwMjbymA/J5gn4jVrS5gHK39ssfoRYDzrhGRVWm8kzd U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowFAEgxF1KtJXG8/2dsb2JhbABagwc1Ub9+gR8WbQeCJAEBAQQBAQEaHTQdAQgYChQFMgslAgQTCIgIDJVRoTaPHYEYOIMbewOZE5AtgWSBO4FyOQ X-IronPort-AV: E=Sophos;i="4.89,940,1367971200"; d="scan'208";a="250827565" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 23 Aug 2013 09:55:53 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7N9truQ023836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 23 Aug 2013 09:55:53 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.201]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Fri, 23 Aug 2013 04:55:52 -0500 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) Thread-Index: AQHOjEWHMNpikDyP/E6vAANE1noeMpmLf62AgBdXNAA= Date: Fri, 23 Aug 2013 09:55:51 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604091292D6@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.253.50] Content-Type: text/plain; charset="us-ascii" Content-ID: <96037558DD37374890AAD0C925CC087E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 09:56:05 -0000 This WG Call of adoption has finished. The conclusion is that there is consensus and support to adopt this document as a WG item. > >On 29/07/13 3:52 PM, "Reinaldo Penno (repenno)" wrote: > >>Hello, >> >>This email starts a 2-week consensus call on adopting "Optimizing NAT and >>Firewall Keepalives Using Port Control Protocol (PCP)" as a WG item. >> >> Title : Optimizing NAT and Firewall Keepalives Using Port >>Control >>Protocol (PCP) >> Author(s) : T. Reddy et al >> Filename : draft-reddy-pcp-optimize-keepalives-01 >> URL : >>http://tools.ietf.org/html/draft-reddy-pcp-optimize-keepalives-01 >> >>Please read the current revision and state you opinion either for or >>against adoption in the mailing list. >> >>The call for adoption ends 12th August 2013. >> >>Thanks, >> >>Chairs >> >>_______________________________________________ >>pcp mailing list >>pcp@ietf.org >>https://www.ietf.org/mailman/listinfo/pcp > From internet-drafts@ietf.org Fri Aug 23 03:23:09 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED1F11E82C5; Fri, 23 Aug 2013 03:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5D1CfEBeCvFE; Fri, 23 Aug 2013 03:23:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC12821F9AA2; Fri, 23 Aug 2013 03:23:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130823102308.27614.98166.idtracker@ietfa.amsl.com> Date: Fri, 23 Aug 2013 03:23:08 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-optimize-keepalives-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 10:23:09 -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 : Optimizing NAT and Firewall Keepalives Using Port Contro= l Protocol (PCP) Author(s) : Tirumaleswar Reddy Markus Isomaki Dan Wing Prashanth Patil Filename : draft-ietf-pcp-optimize-keepalives-00.txt Pages : 15 Date : 2013-08-19 Abstract: This document describes how Port Control Protocol is useful to reduce NAT and firewall keepalive messages for a variety of applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-optimize-keepalives There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-optimize-keepalives-00 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 tireddy@cisco.com Fri Aug 23 05:27:01 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5B511E82F1 for ; Fri, 23 Aug 2013 05:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzQlcw1drZ+x for ; Fri, 23 Aug 2013 05:26:56 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D53E011E82FA for ; Fri, 23 Aug 2013 05:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1739; q=dns/txt; s=iport; t=1377260815; x=1378470415; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=+rXu4gv/TYVes1CgBsrkwbl2J9GBVPKdYt3n87Mfr7E=; b=fG8HRhAD7ZaAGO5DUrEIMRJPByZxefTxZmWsdAA0h4yHUmaa0J/mS7zs 9Tuj6Oik7xUqGzweEvKLUWkA7fTJIjYMy8TOVyy91lFJRhyCMs9l4JitY zujaNfVx+VN32wnUnk1haVloA2asJL0Hbx2TCIjU3OYy302p8eMtMYpeY s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAG5UF1KtJV2b/2dsb2JhbABagwc1Ub9+gR8WdIIkAQEBAwEdHTQXBAIBCBEEAQELFAULMh0IAgQBEgiIAgYMtnSPHYEYOAaDFXsDmROQLYFkgTuBcjk X-IronPort-AV: E=Sophos;i="4.89,941,1367971200"; d="scan'208";a="250893657" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 23 Aug 2013 12:26:54 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7NCQsl0019137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 23 Aug 2013 12:26:54 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.8]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Fri, 23 Aug 2013 07:26:53 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Ram Mohan R (rmohanr)" , "pcp@ietf.org" Thread-Topic: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) Thread-Index: AQHOjFORrIMjf8sOSUiRMwszh5KQt5mixnpA Date: Fri, 23 Aug 2013 12:26:53 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A19030F64@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A1900F74A@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.47.246] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 12:27:01 -0000 > -----Original Message----- > From: Ram Mohan R (rmohanr) > Sent: Tuesday, August 13, 2013 10:34 AM > To: pcp@ietf.org > Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall > Keepalives Using Port Control Protocol (PCP) >=20 > I support adoption of this document. >=20 > One comment that you can take care in the next revision- > We can add some text on how this document will interact with consent > messages that would be sent for webRTC flows Using PCP to increase the lifetime will be useful when not actively sending= traffic i.e. when consent is not used. Planning to update draft "PCP Consi= derations for WebRTC Usage" http://tools.ietf.org/html/draft-penno-rtcweb-p= cp-00#section-3.6 with more details. --Tiru. >=20 > Ram >=20 > > > > > >-----Original Message----- > >From: Reinaldo Penno (repenno) > >Sent: Monday, July 29, 2013 3:52 PM > >To: pcp@ietf.org > >Subject: [pcp] WG Call for Adoption: Optimizing NAT and Firewall > >Keepalives Using Port Control Protocol (PCP) > > > >Hello, > > > >This email starts a 2-week consensus call on adopting "Optimizing NAT an= d > >Firewall Keepalives Using Port Control Protocol (PCP)" as a WG item. > > > > Title : Optimizing NAT and Firewall Keepalives Using Port Contr= ol > >Protocol (PCP) > > Author(s) : T. Reddy et al > > Filename : draft-reddy-pcp-optimize-keepalives-01 > > URL : > >http://tools.ietf.org/html/draft-reddy-pcp-optimize-keepalives-01 > > > >Please read the current revision and state you opinion either for or > >against adoption in the mailing list. > > > >The call for adoption ends 12th August 2013. > > > >Thanks, > > > >Chairs > > > > > > >=20 >=20 From tireddy@cisco.com Fri Aug 23 05:34:10 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586FA11E80F4 for ; Fri, 23 Aug 2013 05:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7QVOMz2lz8j for ; Fri, 23 Aug 2013 05:34:05 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 870BE21F81FF for ; Fri, 23 Aug 2013 05:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1696; q=dns/txt; s=iport; t=1377261245; x=1378470845; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oj41Mzq9kv8lcwRoL1w2pbvtG2Ab/0E4Byjh3cSgnMk=; b=iC6iXp9yfn8dDv4pITFOy31025wuqCkQ3X9BvY8c92R6ROsktldbpPbp daFy9Hr3qsK70wdHJpIYfTJ2tSMMGjc/eBxjF86/CMldqgtWHcJqO5Ict QhFRnDWWeOeMpQsSVP4cWeySI0RSAkSFMN+pffn0y+xyJ9oCXuwRNTCHm Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAFZWF1KtJV2Y/2dsb2JhbABagwc1Ub9+gR8WdIIkAQEBAwE6PwwEAgEIDgMEAQEBChQJBzIUCQgCBAENBQgTh28GDLZ3kDUxBwaDFXsDmROQLYMfgis X-IronPort-AV: E=Sophos;i="4.89,941,1367971200"; d="scan'208";a="250705253" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 23 Aug 2013 12:34:04 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7NCY4YO004436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Aug 2013 12:34:04 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.8]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 23 Aug 2013 07:34:02 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Sebastian Kiesel , "mohamed.boucadair@orange.com" Thread-Topic: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt Thread-Index: AQHOndeCX1a06Q1Jd0WrPGbRAngbYpmivVow Date: Fri, 23 Aug 2013 12:34:02 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A19030F7B@xmb-rcd-x10.cisco.com> References: <20130626134028.17581.26454.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> <20130819203309.GB1867@gw01.ehlo.wurstkaes.de> In-Reply-To: <20130819203309.GB1867@gw01.ehlo.wurstkaes.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.47.246] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 12:34:10 -0000 > -----Original Message----- > From: Sebastian Kiesel [mailto:ietf-pcp@skiesel.de] > Sent: Tuesday, August 20, 2013 2:03 AM > To: mohamed.boucadair@orange.com > Cc: pcp@ietf.org > Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt >=20 > Hi, >=20 > On Wed, Jun 26, 2013 at 05:04:52PM +0200, mohamed.boucadair@orange.com wr= ote: > > Dear all, > > > > I submitted this short I-D to explain how PCP can be used in IPv6 SIP > deployments (with a focus on the managed networks case). >=20 > > Objet: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt >=20 > I have read this draft and I think this is a very interesting topic. > However, it is not very clear to me what the key message of this draft is= . >=20 > I think there are at least two topics that deserve investigation and > discussion, with different target audiences: >=20 > 1. A gap analysis for PCP, i.e., tell the PCP folks what should be > changed or added to PCP to better support this use case (if any). >=20 > 2. Tell the SIP folks about PCP and its benefits. IMO this chapter > should start with a short discussion what's new compared to older > (managed) NAT/Firewall traversal approaches, e.g., MIDCOM [RFC5190, > RFC4540] and NSIS [RFC5973]. Is the interaction really straightforward, > or are there any pitfalls (e.g., [draft-kiesel-mmusic-firewall-sip-00]) t= o > consider? The problems discussed in draft-kiesel-mmusic-firewall-sip-00 can also be a= ddressed using PCP http://tools.ietf.org/html/draft-wing-pcp-third-party-au= thz-00; we have taken example of WebRTC in the draft to explain the problem= s and solution. -Tiru. >=20 >=20 > Cheers > Sebastian From sebi@gw01.ehlo.wurstkaes.de Mon Aug 26 10:59:53 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8E121F9B92 for ; Mon, 26 Aug 2013 10:59:52 -0700 (PDT) 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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztdbLzDsWYEF for ; Mon, 26 Aug 2013 10:59:52 -0700 (PDT) Received: from gw01.ehlo.wurstkaes.de (gw01.ehlo.wurstkaes.de [IPv6:2a02:a00:e000:116::41]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1FA21F9AD8 for ; Mon, 26 Aug 2013 10:59:45 -0700 (PDT) Received: from sebi by gw01.ehlo.wurstkaes.de with local (Exim 4.72) (envelope-from ) id 1VE14b-0002al-Ex; Mon, 26 Aug 2013 19:59:29 +0200 Date: Mon, 26 Aug 2013 19:59:29 +0200 From: Sebastian Kiesel To: "Tirumaleswar Reddy (tireddy)" Message-ID: <20130826175929.GD1867@gw01.ehlo.wurstkaes.de> References: <20130626134028.17581.26454.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> <20130819203309.GB1867@gw01.ehlo.wurstkaes.de> <913383AAA69FF945B8F946018B75898A19030F7B@xmb-rcd-x10.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <913383AAA69FF945B8F946018B75898A19030F7B@xmb-rcd-x10.cisco.com> Accept-Languages: en, de Organization: my personal mail account User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "pcp@ietf.org" Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 17:59:53 -0000 Hi, On Fri, Aug 23, 2013 at 12:34:02PM +0000, Tirumaleswar Reddy (tireddy) wrote: > > -----Original Message----- > > From: Sebastian Kiesel [mailto:ietf-pcp@skiesel.de] > > Sent: Tuesday, August 20, 2013 2:03 AM > > To: mohamed.boucadair@orange.com > > Cc: pcp@ietf.org > > Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt > > > > Hi, > > > > On Wed, Jun 26, 2013 at 05:04:52PM +0200, mohamed.boucadair@orange.com wrote: > > > Dear all, > > > > > > I submitted this short I-D to explain how PCP can be used in IPv6 SIP > > deployments (with a focus on the managed networks case). > > > > > Objet: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt > > > > I have read this draft and I think this is a very interesting topic. > > However, it is not very clear to me what the key message of this draft is. > > > > I think there are at least two topics that deserve investigation and > > discussion, with different target audiences: > > > > 1. A gap analysis for PCP, i.e., tell the PCP folks what should be > > changed or added to PCP to better support this use case (if any). > > > > 2. Tell the SIP folks about PCP and its benefits. IMO this chapter > > should start with a short discussion what's new compared to older > > (managed) NAT/Firewall traversal approaches, e.g., MIDCOM [RFC5190, > > RFC4540] and NSIS [RFC5973]. Is the interaction really straightforward, > > or are there any pitfalls (e.g., [draft-kiesel-mmusic-firewall-sip-00]) to > > consider? > > The problems discussed in draft-kiesel-mmusic-firewall-sip-00 can also > be addressed using PCP > http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-00; we > have taken example of WebRTC in the draft to explain the problems and > solution. I wouldn't say that draft-wing-pcp-third-party-authz-00 addresses the problems identified in draft-kiesel-mmusic-firewall-sip-00 - it's more like it avoids them by using a rather different solution approach, which might have other drawbacks. Once upon a time some people thought that with MIDCOM, a SIP B2BUA would be able to control a firewall on the RTP media path, completely transparent for the user agents. draft-kiesel-mmusic-firewall-sip-00 summarizes problems with that approach and argues that at least for the handling of error conditions there must be some limited support in the user agents. Adding a PCP client to the SIP phone avoids these problems, but seems to be more, not less, additional effort. Sebastian p.s.: speaking of draft-wing-pcp-third-party-authz-00: this draft could be improved by explaining more explicitly how Figure 1 is related to Figure 3. Specifically, what is the relation between "WebRTC Server" and "Authorization Server"? From tireddy@cisco.com Mon Aug 26 22:37:49 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDA811E8286 for ; Mon, 26 Aug 2013 22:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELqZmqsPHkNF for ; Mon, 26 Aug 2013 22:37:44 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD9911E8143 for ; Mon, 26 Aug 2013 22:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3329; q=dns/txt; s=iport; t=1377581864; x=1378791464; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FfBg4/GXMwTj0pNxBjWHrHX338rRurBU5TR5qvyKmNE=; b=Zul4bwvJUYUD2qk3IhdwBMivCYI/9Cdvv03QNFIKpzSKSj5S6DJJStpx kwKdDtWpKao7FSwdHI4qfIw+wggqLjDPGuxOIRuDcNovsxR2+a9noFf0z PZSDjd7dXcexGdvWmY1QVHfpvhtTuxKQg32a3rzw4010ZZvZ4sk6GG7Hq 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssGAOQ5HFKtJV2d/2dsb2JhbABagwc1UcAqgSEWbQeCJAEBAQQBAQFrCwwEAgEIEQQBAQsdBycLFAkIAgQOBQgBh3gMuBmQRjECBQaDFn0DiHmQIosLhSmDHoIq X-IronPort-AV: E=Sophos;i="4.89,965,1367971200"; d="scan'208";a="252011318" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 27 Aug 2013 05:37:43 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7R5bhKR018788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Aug 2013 05:37:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.8]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 27 Aug 2013 00:37:43 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" Thread-Topic: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt Thread-Index: AQHOcp9hX1a06Q1Jd0WrPGbRAngbYpmkB3sQ Date: Tue, 27 Aug 2013 05:37:42 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A19032570@xmb-rcd-x10.cisco.com> References: <20130626134028.17581.26454.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.54.103] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 05:37:49 -0000 Hi Med, comments=20 [1] The title is "PCP for IPv6-enabled SIP Deployments" but the draft also = discusses problems related to IPv4 networks as well. [2] can you provide more details on what "managed networks" are considered = for this draft (Mobile, Enterprise etc); An example of "managed network" wi= th a diagram will be helpful. [3] comments on section 2.7 a) If the SIP server is deployed in the EPC of 3GPP network, SIP server itself= can signal the network to prioritize the media streams. Is setting DSCP values required in such networks ? b)=20 You may want to create a separate draft for DSCP_POLICY and explain How it = can used with http://tools.ietf.org/html/draft-ietf-rtcweb-qos-00 which def= ines default set of DSCP code point values, PCP FLOWDATA option etc.=20 [4]=20 I guess administrator can change the policy table to prefer IPv4 addresses = over IPv6 addresses as discussed in RFC 6724 and you may want to recommend = in the draft that in such deployments (sections 3.1, 3.2) it is recommended= to have higher precedence for IPv6. [6] You may also want to add that PCP can also be used to Optimize IPv6 Fir= ewall Keepalives. [7] If managed networks like Enterprise are considered, technique discussed= in http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-00 would be= useful. [8]Referring to the SIP Flow example in https://tools.ietf.org/html/draft-i= etf-pcp-nat64-prefix64-04#section-5.2 would be useful. -Tiru. > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Wednesday, June 26, 2013 8:35 PM > To: pcp@ietf.org; mmusic@ietf.org; dispatch@ietf.org > Subject: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt >=20 > Dear all, >=20 > I submitted this short I-D to explain how PCP can be used in IPv6 SIP > deployments (with a focus on the managed networks case). >=20 > Cheers, > Med >=20 > -----Message d'origine----- > De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.or= g] De > la part de internet-drafts@ietf.org > Envoy=E9=A0: mercredi 26 juin 2013 15:40 > =C0=A0: i-d-announce@ietf.org > Objet=A0: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : PCP for IPv6-enabled SIP Deployments > Author(s) : Mohamed Boucadair > Filename : draft-boucadair-pcp-sip-ipv6-00.txt > Pages : 7 > Date : 2013-06-26 >=20 > Abstract: > This document discusses how PCP can be used in IPv6-enabled SIP > deployments. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ipv6 >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From tireddy@cisco.com Tue Aug 27 06:01:56 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D7311E8326 for ; Tue, 27 Aug 2013 06:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjrcSyzS6zJt for ; Tue, 27 Aug 2013 06:01:51 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B5B1211E8317 for ; Tue, 27 Aug 2013 06:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3916; q=dns/txt; s=iport; t=1377608511; x=1378818111; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8TUfRyWAatSFkE4bAxxerfxskYNZC1pxbOdhYgAS2gM=; b=lmII3F0L8bOjps8urxe0H4AGLAC+nTkKfxGVJZDneiKa8WGXu/pDHXVo Z//KBurw8U7PRCK79m7fRQ/UUGLLL9QDmMVJB5mXAGReEfR1JeNg5H5Dq XMJ8xV2N2HXb+fAuOzK/iEcAOzE2c+fm1sLpNRLorebKf2kWC7Mhc24Wd k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAO6hHFKtJV2d/2dsb2JhbABagwc1UcAjgSYWdIIkAQEBAwE6OAcFBwQCAQgOAwQBAQEKFAkHMhQJCAIEDgUIE4dgBgy4Xo4aC4EOMQcGgxZ9A5kckDODIIFoQg X-IronPort-AV: E=Sophos;i="4.89,968,1367971200"; d="scan'208";a="252130339" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 27 Aug 2013 13:01:51 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7RD1n0b004832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Aug 2013 13:01:49 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.8]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Tue, 27 Aug 2013 08:01:49 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Sebastian Kiesel Thread-Topic: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt Thread-Index: AQHOndeCX1a06Q1Jd0WrPGbRAngbYpmivVowgAVmzYCAAG+9UA== Date: Tue, 27 Aug 2013 13:01:48 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A190328AE@xmb-rcd-x10.cisco.com> References: <20130626134028.17581.26454.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> <20130819203309.GB1867@gw01.ehlo.wurstkaes.de> <913383AAA69FF945B8F946018B75898A19030F7B@xmb-rcd-x10.cisco.com> <20130826175929.GD1867@gw01.ehlo.wurstkaes.de> In-Reply-To: <20130826175929.GD1867@gw01.ehlo.wurstkaes.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.124.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 13:01:56 -0000 > -----Original Message----- > From: Sebastian Kiesel [mailto:ietf-pcp@skiesel.de] > Sent: Monday, August 26, 2013 11:29 PM > To: Tirumaleswar Reddy (tireddy) > Cc: mohamed.boucadair@orange.com; pcp@ietf.org > Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt >=20 > Hi, >=20 > On Fri, Aug 23, 2013 at 12:34:02PM +0000, Tirumaleswar Reddy (tireddy) wr= ote: > > > -----Original Message----- > > > From: Sebastian Kiesel [mailto:ietf-pcp@skiesel.de] > > > Sent: Tuesday, August 20, 2013 2:03 AM > > > To: mohamed.boucadair@orange.com > > > Cc: pcp@ietf.org > > > Subject: Re: [pcp] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.tx= t > > > > > > Hi, > > > > > > On Wed, Jun 26, 2013 at 05:04:52PM +0200, mohamed.boucadair@orange.co= m > wrote: > > > > Dear all, > > > > > > > > I submitted this short I-D to explain how PCP can be used in IPv6 S= IP > > > deployments (with a focus on the managed networks case). > > > > > > > Objet: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt > > > > > > I have read this draft and I think this is a very interesting topic. > > > However, it is not very clear to me what the key message of this draf= t is. > > > > > > I think there are at least two topics that deserve investigation and > > > discussion, with different target audiences: > > > > > > 1. A gap analysis for PCP, i.e., tell the PCP folks what should be > > > changed or added to PCP to better support this use case (if any). > > > > > > 2. Tell the SIP folks about PCP and its benefits. IMO this chapter > > > should start with a short discussion what's new compared to older > > > (managed) NAT/Firewall traversal approaches, e.g., MIDCOM [RFC5190, > > > RFC4540] and NSIS [RFC5973]. Is the interaction really straightforwar= d, > > > or are there any pitfalls (e.g., [draft-kiesel-mmusic-firewall-sip-00= ]) to > > > consider? > > > > The problems discussed in draft-kiesel-mmusic-firewall-sip-00 can also > > be addressed using PCP > > http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-00; we > > have taken example of WebRTC in the draft to explain the problems and > > solution. >=20 >=20 > I wouldn't say that draft-wing-pcp-third-party-authz-00 addresses the > problems identified in draft-kiesel-mmusic-firewall-sip-00 - it's more > like it avoids them by using a rather different solution approach, which > might have other drawbacks. >=20 > Once upon a time some people thought that with MIDCOM, a SIP B2BUA would > be able to control a firewall on the RTP media path, completely > transparent for the user agents. =20 Yes, PCP solves that problem using PCP THIRD_PARTY option (http://tools.iet= f.org/html/rfc6887#section-13.1), where SIPB2BUA can act as PCP client. But for scenarios where the Application Server is outside the site (for exa= mple over-the-top services) it will not be able to use PCP THIRD_PARTY opti= on, draft-wing-pcp-third-party-authz-00 is targeted to such use cases to so= lve both Firewall and QOS problems (http://tools.ietf.org/html/draft-penno-= pcp-mobile-qos-00)=20 > draft-kiesel-mmusic-firewall-sip-00 > summarizes problems with that approach and argues that at least for the > handling of error conditions there must be some limited support in the > user agents. Adding a PCP client to the SIP phone avoids these problems, > but seems to be more, not less, additional effort. >=20 >=20 > Sebastian >=20 >=20 > p.s.: speaking of draft-wing-pcp-third-party-authz-00: this draft could > be improved by explaining more explicitly how Figure 1 is related to > Figure 3. =20 Sure, will update in the next version of the draft. > Specifically, what is the relation between "WebRTC Server" > and "Authorization Server" ? PCP client is host (Alice); PCP server is PCP-controlled firewall; Authoriz= ation server is WebRTC Server. --Tiru. From Markus.Isomaki@nokia.com Tue Aug 27 06:11:28 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF92011E8302 for ; Tue, 27 Aug 2013 06:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiT45buTxLlv for ; Tue, 27 Aug 2013 06:11:24 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 33FA011E830B for ; Tue, 27 Aug 2013 06:11:23 -0700 (PDT) Received: from smtp.mgd.nokia.com ([65.54.30.49]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r7RDBK0s032072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 27 Aug 2013 16:11:21 +0300 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.88]) by 008-AM1MMR2-015.mgdnok.nokia.com ([65.54.30.49]) with mapi id 14.03.0136.001; Tue, 27 Aug 2013 13:11:20 +0000 From: To: , , Thread-Topic: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) Thread-Index: AQHOjFORrIMjf8sOSUiRMwszh5KQt5mixnpAgAZq7iA= Date: Tue, 27 Aug 2013 13:11:19 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A1900F74A@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A19030F64@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A19030F64@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.5.9.3 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Imb/kNG8e5MBaAZCGWp2zCcmriI8lnVAfaV3+HkLL5QL0vdF69Z7XYn5GAjjV6RI9UB67e/BoNoOXYTiGPj5VJmDApl0RaDBWu7287tfJVrILsR5Dwm0Mm+M40rzp2zHrKTWcMFeptNvmWIRKM0u7hMBFFjF9kWgOHkJNz2+zN3DLJXhG2tCXj/Rap+FNYfqJmnY+xnLdm9OLCBmcjtcPzo7mPGVzXhEWPROcplGqWOGXdDXUOjsXY/My0yfrsOYeB2hFTSVMeSrE/iAGQ06PYCrvEQGZGgN655Fd6I3dhevKi35XSOvwA3YSzwwUkM+lQ== x-originating-ip: [10.236.10.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Nokia-AV: Clean Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 13:11:29 -0000 Hi Tiru, Ram, This might be better asked on the RTCWEB or MMUSIC WG lists, but since it c= ame up here: When thinking about WebRTC's P2P traffic flows (audio, video or data channe= l), the keepalive reduction becomes relevant only when there are long perio= ds when no application traffic is being sent -- but still for some reason, = such as responsiveness, it is not possible to tear down the P2P "associatio= n" for that period. There may be such cases even for audio or video streams= , but it seems that the most realistic case is when only a data channel is = up. My understanding was that the consent refreshes would need to be sent quite= frequently at all times. But are there situations where a P2P association = would be up, while yet consent refreshes would not flow? If so, PCP would i= ndeed become handy for instance prolonging the default 30 second UDP timeou= t to, say, 5 minutes. That would be basically the only way for a small batt= ery powered device to keep that P2P connection up for hours without drainin= g its battery. But as said, often it might be a better design to tear the data channel dow= n after a few minutes of no traffic and set it up ASAP when either end has = something to send. In that case only the signaling connection (TLS/TCP) wou= ld need to stay up for long time, and for that PCP works nicely.=20 Markus=20 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > ext Tirumaleswar Reddy (tireddy) > Sent: 23 August, 2013 15:27 > To: Ram Mohan R (rmohanr); pcp@ietf.org > Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall > Keepalives Using Port Control Protocol (PCP) >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) > > Sent: Tuesday, August 13, 2013 10:34 AM > > To: pcp@ietf.org > > Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall > > Keepalives Using Port Control Protocol (PCP) > > > > I support adoption of this document. > > > > One comment that you can take care in the next revision- We can add > > some text on how this document will interact with consent messages > > that would be sent for webRTC flows >=20 > Using PCP to increase the lifetime will be useful when not actively sendi= ng > traffic i.e. when consent is not used. Planning to update draft "PCP > Considerations for WebRTC Usage" http://tools.ietf.org/html/draft-penno- > rtcweb-pcp-00#section-3.6 with more details. >=20 > --Tiru. >=20 > > > > Ram > > > > > > > > > > >-----Original Message----- > > >From: Reinaldo Penno (repenno) > > >Sent: Monday, July 29, 2013 3:52 PM > > >To: pcp@ietf.org > > >Subject: [pcp] WG Call for Adoption: Optimizing NAT and Firewall > > >Keepalives Using Port Control Protocol (PCP) > > > > > >Hello, > > > > > >This email starts a 2-week consensus call on adopting "Optimizing NAT > > >and Firewall Keepalives Using Port Control Protocol (PCP)" as a WG ite= m. > > > > > > Title : Optimizing NAT and Firewall Keepalives Using Port Con= trol > > >Protocol (PCP) > > > Author(s) : T. Reddy et al > > > Filename : draft-reddy-pcp-optimize-keepalives-01 > > > URL : > > >http://tools.ietf.org/html/draft-reddy-pcp-optimize-keepalives-01 > > > > > >Please read the current revision and state you opinion either for or > > >against adoption in the mailing list. > > > > > >The call for adoption ends 12th August 2013. > > > > > >Thanks, > > > > > >Chairs > > > > > > > > > > > > > >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From achatz@forthnetgroup.gr Wed Aug 28 04:50:39 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963E711E8132 for ; Wed, 28 Aug 2013 04:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8id2mD6-qHRD for ; Wed, 28 Aug 2013 04:50:31 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 7485B21F9FDA for ; Wed, 28 Aug 2013 04:50:30 -0700 (PDT) Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-03.forthnet.gr (8.14.4/8.14.4) with ESMTP id r7SBoSGl003081 for ; Wed, 28 Aug 2013 14:50:28 +0300 Received: from MX-IN-11.forthnet.gr (mx-in-11.forthnet.gr [193.92.150.31]) by mx-av-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id r7SBoS9W002672 for ; Wed, 28 Aug 2013 14:50:28 +0300 Received: from [192.168.1.2] (194.219.240.252.dsl.dyn.forthnet.gr [194.219.240.252]) by MX-IN-11.forthnet.gr (8.14.4/8.14.4) with ESMTP id r7SBoQNn024996; Wed, 28 Aug 2013 14:50:27 +0300 Authentication-Results: MX-IN-11.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; spf=pass Authentication-Results: MX-IN-11.forthnet.gr header.from=achatz@forthnetgroup.gr; sender-id=pass Message-ID: <521DE3FD.5050802@forthnetgroup.gr> Date: Wed, 28 Aug 2013 14:50:21 +0300 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20 MIME-Version: 1.0 To: pcp@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [pcp] Question about THIRD_PARTY option in DS-Lite PCP Client (not Proxy) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 11:50:40 -0000 I'm reading draft-ietf-pcp-dslite-00: In the plain mode the B4, the customer end-point of the DS-Lite IPv6 tunnel, implements a PCP proxy ([I-D.ietf-pcp-proxy ]) function and uses UDP over IPv6 with the AFTR to send PCP requests and receive PCP responses. The B4 MUST source PCP requests with the IPv6 address of its DS-Lite tunnel end-point and MUST use a THIRD PARTY option either empty or carrying the IPv4 internal address of the mappings. I'm testing a DS-Lite CPE running a PCP client (PCP Proxy is disabled) and i'm trying to create some manual/static mappings through its port-forwarding GUI. What i'm seeing inside the MAP request is the THIRD PARTY option using as "Internal IP address" the local host ip address i define in the port forwarding setup (i.e 192.168.1.2). This ip address belongs just to a dummy host (running a web server), without any PCP/NAT-PMP/UPnP/etc. functionality. Is this expected? -- Tassos From repenno@cisco.com Wed Aug 28 07:44:30 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2930D21F9B94 for ; Wed, 28 Aug 2013 07:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJhBP-zZVgmS for ; Wed, 28 Aug 2013 07:44:25 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4550621F9AEF for ; Wed, 28 Aug 2013 07:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1804; q=dns/txt; s=iport; t=1377701065; x=1378910665; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=3qrWlHelasD7dkcZldrE2Tt06YFoEWsX/WmO3Clz+3k=; b=RXf/9XBOGwnu9zqZCByNfAoobHIjBGluRMQELs3L5aNeHzj9bvyN+YAL spjYp3srTPn0h9PRa83lzKT4LGztsQZSTZ/Hohmz4Rbr+NRQqQVlsAC+U ayK/khe/wYzKZx0QYTkl4IyXukfRdjRnYB9iMS+x+EsZ8aoUW0l79FtlM s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAIAMHlKtJXG8/2dsb2JhbABbgwc1UcAqgR8WdIImAQQBAQE3NB0BCA4UFDcLJQIEARIIh3kMuSOPMziDHH0DmR6JAIc0gyCCKg X-IronPort-AV: E=Sophos;i="4.89,976,1367971200"; d="scan'208";a="252655187" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 28 Aug 2013 14:44:13 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7SEiCTH017282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 28 Aug 2013 14:44:12 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.201]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Wed, 28 Aug 2013 09:44:12 -0500 From: "Reinaldo Penno (repenno)" To: Tassos Chatzithomaoglou , "pcp@ietf.org" Thread-Topic: [pcp] Question about THIRD_PARTY option in DS-Lite PCP Client (not Proxy) Thread-Index: AQHOo/0P6RhUbZuSKUOYVEtry6+UPg== Date: Wed, 28 Aug 2013 14:44:12 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040912A43B@xmb-rcd-x04.cisco.com> In-Reply-To: <521DE3FD.5050802@forthnetgroup.gr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.253.180] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Question about THIRD_PARTY option in DS-Lite PCP Client (not Proxy) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 14:44:30 -0000 Seems right - as assuming your DS-Lite CPE does not apply NAT as well. The PCP request created by the CPE will allocated a public IP:port in the AFTR. When external/incoming packets match this external public IP:port they will be translated to this internal IP (192.168.1.2) and tunneled over v6 to the CPE. The CPE will decap the v6 and forward the regular IPv4 packet to its destination. If you DS-Lite CPE also does NAT that's another story. The internal IP should be the WAN facing IPv4. On 8/28/13 8:50 AM, "Tassos Chatzithomaoglou" wrote: >I'm reading draft-ietf-pcp-dslite-00: > > In the plain mode the B4, the customer end-point of the DS-Lite IPv6 > tunnel, implements a PCP proxy ([I-D.ietf-pcp-proxy >y>]) function and > uses UDP over IPv6 with the AFTR to send PCP requests and receive PCP > responses. > > The B4 MUST source PCP requests with the IPv6 address of its DS-Lite > tunnel end-point and MUST use a THIRD PARTY option either empty or > carrying the IPv4 internal address of the mappings. > >I'm testing a DS-Lite CPE running a PCP client (PCP Proxy is disabled) >and i'm trying to create some manual/static mappings through its >port-forwarding GUI. >What i'm seeing inside the MAP request is the THIRD PARTY option using as >"Internal IP address" the local host ip address i define in the port >forwarding setup (i.e 192.168.1.2). >This ip address belongs just to a dummy host (running a web server), >without any PCP/NAT-PMP/UPnP/etc. functionality. > >Is this expected? > >--=20 >Tassos > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From achatz@forthnetgroup.gr Wed Aug 28 08:04:21 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD52D21F8DDD for ; Wed, 28 Aug 2013 08:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXL4hNWMPPRE for ; Wed, 28 Aug 2013 08:04:05 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFE511E8195 for ; Wed, 28 Aug 2013 08:04:04 -0700 (PDT) Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id r7SF3xdG028648; Wed, 28 Aug 2013 18:03:59 +0300 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.30]) by mx-av-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id r7SF3xR1025297; Wed, 28 Aug 2013 18:03:59 +0300 Received: from [192.168.1.2] (194.219.240.252.dsl.dyn.forthnet.gr [194.219.240.252]) by MX-IN-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id r7SF3wsN023876; Wed, 28 Aug 2013 18:03:59 +0300 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; spf=pass Authentication-Results: MX-IN-05.forthnet.gr header.from=achatz@forthnetgroup.gr; sender-id=pass Message-ID: <521E115A.1040609@forthnetgroup.gr> Date: Wed, 28 Aug 2013 18:03:54 +0300 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20 MIME-Version: 1.0 To: "Reinaldo Penno (repenno)" , "pcp@ietf.org" References: <45A697A8FFD7CF48BCF2BE7E106F06040912A43B@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040912A43B@xmb-rcd-x04.cisco.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [pcp] Question about THIRD_PARTY option in DS-Lite PCP Client (not Proxy) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 15:04:21 -0000 Thanks Reinaldo. That's my understanding too, after reading the case "HTTP-Triggered PCP Client Model" in draft-boucadair-pcp-deployment-cases. Question to draft-ietf-pcp-dslite authors: Although i had asked this in the past, are there any plans to add PCP Client in draft-ietf-pcp-dslite? We surely gonna use this functionality. -- Tassos Reinaldo Penno (repenno) wrote on 28/8/2013 17:44: > Seems right - as assuming your DS-Lite CPE does not apply NAT as well. > > The PCP request created by the CPE will allocated a public IP:port in the > AFTR. When external/incoming packets match this external public IP:port > they will be translated to this internal IP (192.168.1.2) and tunneled > over v6 to the CPE. The CPE will decap the v6 and forward the regular IPv4 > packet to its destination. > > If you DS-Lite CPE also does NAT that's another story. The internal IP > should be the WAN facing IPv4. > > On 8/28/13 8:50 AM, "Tassos Chatzithomaoglou" > wrote: > >> I'm reading draft-ietf-pcp-dslite-00: >> >> In the plain mode the B4, the customer end-point of the DS-Lite IPv6 >> tunnel, implements a PCP proxy ([I-D.ietf-pcp-proxy >> > y>]) function and >> uses UDP over IPv6 with the AFTR to send PCP requests and receive PCP >> responses. >> >> The B4 MUST source PCP requests with the IPv6 address of its DS-Lite >> tunnel end-point and MUST use a THIRD PARTY option either empty or >> carrying the IPv4 internal address of the mappings. >> >> I'm testing a DS-Lite CPE running a PCP client (PCP Proxy is disabled) >> and i'm trying to create some manual/static mappings through its >> port-forwarding GUI. >> What i'm seeing inside the MAP request is the THIRD PARTY option using as >> "Internal IP address" the local host ip address i define in the port >> forwarding setup (i.e 192.168.1.2). >> This ip address belongs just to a dummy host (running a web server), >> without any PCP/NAT-PMP/UPnP/etc. functionality. >> >> Is this expected? >> >> -- >> Tassos >> >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > > From mperumal@cisco.com Fri Aug 30 00:05:55 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521D521F99DC for ; Fri, 30 Aug 2013 00:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QK7GTovOT0x for ; Fri, 30 Aug 2013 00:05:43 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 67F7421F997B for ; Fri, 30 Aug 2013 00:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5137; q=dns/txt; s=iport; t=1377846343; x=1379055943; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=5V/vphRMA+8ANgJkBSk+hq1dNuM/l7k8vQ/ZeDXYsw0=; b=MzxVMI4GHjo7STVxcnE1np9qGA4bCINqZCYVuoOetcv3bY2yu3yhdpG/ BiEohoc2I6AZiJDy3hRvbqgqonr4otU0uU2wvG0Z+QQkj4yVopeMQS1Tn 31Tu+lduNeTtUrvMXqJUzw/TVtXUm52MmdazCyeMsYk11EZfYqU+PHf12 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAHhDIFKtJXHB/2dsb2JhbABagwc1UcBPgR8WdIIkAQEBBAEBARodNBcEAgEIEQQBAQsUBQQHJwsUCQgCBAESCId5DLk8jiUGgRg4BoMWgQADmSKQN4FjgT2BcTk X-IronPort-AV: E=Sophos;i="4.89,989,1367971200"; d="scan'208";a="253589174" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 30 Aug 2013 07:05:41 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7U75fZo001587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Aug 2013 07:05:41 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.198]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 30 Aug 2013 02:05:41 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Markus.Isomaki@nokia.com" , "Tirumaleswar Reddy (tireddy)" , "Ram Mohan R (rmohanr)" , "pcp@ietf.org" Thread-Topic: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) Thread-Index: AQHOjFORrIMjf8sOSUiRMwszh5KQt5mixnpAgAZq7iCABFNHEA== Date: Fri, 30 Aug 2013 07:05:40 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A1900F74A@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A19030F64@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.178] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 07:05:55 -0000 Hi Markus, |My understanding was that the consent refreshes would need to be=20 |sent quite frequently at all times. But are there situations where=20 |a P2P association would be up, while yet consent refreshes would not |flow? If so, PCP would indeed become handy for instance prolonging=20 |the default 30 second UDP timeout to, say, 5 minutes. That would be |basically the only way for a small battery powered device to keep |that P2P connection up for hours without draining its battery. Yes, there are situations where a P2P association would be up while consent= refreshes wouldn't flow. This is where one of endpoints is only receiving = traffic and not sending anything (or sending infrequently). Consent freshne= ss is needed only when traffic is sent. When the endpoint is not sending tr= affic consent freshness is unnecessary. Muthu |-----Original Message----- |From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Mark= us.Isomaki@nokia.com |Sent: Tuesday, August 27, 2013 6:41 PM |To: Tirumaleswar Reddy (tireddy); Ram Mohan R (rmohanr); pcp@ietf.org |Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall Keepa= lives Using Port Control |Protocol (PCP) | |Hi Tiru, Ram, | |This might be better asked on the RTCWEB or MMUSIC WG lists, but since it = came up here: | |When thinking about WebRTC's P2P traffic flows (audio, video or data chann= el), the keepalive reduction |becomes relevant only when there are long periods when no application traf= fic is being sent -- but |still for some reason, such as responsiveness, it is not possible to tear = down the P2P "association" |for that period. There may be such cases even for audio or video streams, = but it seems that the most |realistic case is when only a data channel is up. | |My understanding was that the consent refreshes would need to be sent quit= e frequently at all times. |But are there situations where a P2P association would be up, while yet co= nsent refreshes would not |flow? If so, PCP would indeed become handy for instance prolonging the def= ault 30 second UDP timeout |to, say, 5 minutes. That would be basically the only way for a small batte= ry powered device to keep |that P2P connection up for hours without draining its battery. | |But as said, often it might be a better design to tear the data channel do= wn after a few minutes of no |traffic and set it up ASAP when either end has something to send. In that = case only the signaling |connection (TLS/TCP) would need to stay up for long time, and for that PCP= works nicely. | |Markus | |> -----Original Message----- |> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of |> ext Tirumaleswar Reddy (tireddy) |> Sent: 23 August, 2013 15:27 |> To: Ram Mohan R (rmohanr); pcp@ietf.org |> Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall |> Keepalives Using Port Control Protocol (PCP) |> |> > -----Original Message----- |> > From: Ram Mohan R (rmohanr) |> > Sent: Tuesday, August 13, 2013 10:34 AM |> > To: pcp@ietf.org |> > Subject: Re: [pcp] WG Call for Adoption: Optimizing NAT and Firewall |> > Keepalives Using Port Control Protocol (PCP) |> > |> > I support adoption of this document. |> > |> > One comment that you can take care in the next revision- We can add |> > some text on how this document will interact with consent messages |> > that would be sent for webRTC flows |> |> Using PCP to increase the lifetime will be useful when not actively send= ing |> traffic i.e. when consent is not used. Planning to update draft "PCP |> Considerations for WebRTC Usage" http://tools.ietf.org/html/draft-penno- |> rtcweb-pcp-00#section-3.6 with more details. |> |> --Tiru. |> |> > |> > Ram |> > |> > > |> > > |> > >-----Original Message----- |> > >From: Reinaldo Penno (repenno) |> > >Sent: Monday, July 29, 2013 3:52 PM |> > >To: pcp@ietf.org |> > >Subject: [pcp] WG Call for Adoption: Optimizing NAT and Firewall |> > >Keepalives Using Port Control Protocol (PCP) |> > > |> > >Hello, |> > > |> > >This email starts a 2-week consensus call on adopting "Optimizing NAT |> > >and Firewall Keepalives Using Port Control Protocol (PCP)" as a WG it= em. |> > > |> > > Title : Optimizing NAT and Firewall Keepalives Using Port Co= ntrol |> > >Protocol (PCP) |> > > Author(s) : T. Reddy et al |> > > Filename : draft-reddy-pcp-optimize-keepalives-01 |> > > URL : |> > >http://tools.ietf.org/html/draft-reddy-pcp-optimize-keepalives-01 |> > > |> > >Please read the current revision and state you opinion either for or |> > >against adoption in the mailing list. |> > > |> > >The call for adoption ends 12th August 2013. |> > > |> > >Thanks, |> > > |> > >Chairs |> > > |> > > |> > > |> > |> > |> |> _______________________________________________ |> pcp mailing list |> pcp@ietf.org |> https://www.ietf.org/mailman/listinfo/pcp |_______________________________________________ |pcp mailing list |pcp@ietf.org |https://www.ietf.org/mailman/listinfo/pcp