From Francis.Dupont@fdupont.fr Tue Feb 1 00:22:42 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEA5D3A6B58 for ; Tue, 1 Feb 2011 00:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LaGwdqEaAM5 for ; Tue, 1 Feb 2011 00:22:42 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id BB8DA3A6B07 for ; Tue, 1 Feb 2011 00:22:41 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p118PvIO057033; Tue, 1 Feb 2011 09:25:57 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102010825.p118PvIO057033@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange-ftgroup.com In-reply-to: Your message of Tue, 01 Feb 2011 08:34:14 +0100. <26213_1296545655_4D47B777_26213_6192_1_94C682931C08B048B7A8645303FDC9F33C4376DA52@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 01 Feb 2011 09:25:57 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "pcp@ietf.org" Subject: Re: [pcp] UPnP IGD interworking [was RE: PCP failure scenarios & PCP state synchronization procedure] X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 08:22:42 -0000 In your previous mail you wrote: In fact, we have proposed in http://tools.ietf.org/html/draft-boucadair-pcp-failure-00 the GET and GETNEXT methods to sync the state between the PCP Client and PCP Server because we think not all CPEs will be able to store the mappings in a permanent storage. +1 The CPE is squeezed between hosts and the CGN so it has to rely on both if it can't use stable storage for itself. BTW this requires a way to store more information on the CGN side but it is easy to show this problem is the same than identifying different applications sharing a host. State reliability is important imho to consider. This is not considered as it should be in the current base pcp spec. +1 (and there is no good reason as a document is available...) Thanks Francis.Dupont@fdupontf.fr From mohamed.boucadair@orange-ftgroup.com Tue Feb 1 05:24:44 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA053A6F4F for ; Tue, 1 Feb 2011 05:24:43 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOUO4wbi3lTs for ; Tue, 1 Feb 2011 05:24:42 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 7F8CB3A6F56 for ; Tue, 1 Feb 2011 05:24:42 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 6AE5418C2AC; Tue, 1 Feb 2011 14:27:58 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 4B96A238062; Tue, 1 Feb 2011 14:27:58 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Tue, 1 Feb 2011 14:27:58 +0100 From: To: "pcp@ietf.org" Date: Tue, 1 Feb 2011 14:27:57 +0100 Thread-Topic: Reservation of Pair of Ports with PCP (I-D.pcp-rtp-rtcp-00) Thread-Index: AcvCEHCWcHgsFDSVTkSGSBJLsAl5bwAAmC7A Message-ID: <20706_1296566878_4D480A5E_20706_7634_1_94C682931C08B048B7A8645303FDC9F33C4376DCDC@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/mixed; boundary="_002_94C682931C08B048B7A8645303FDC9F33C4376DCDCPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.1.110319 Subject: [pcp] Reservation of Pair of Ports with PCP (I-D.pcp-rtp-rtcp-00) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 13:24:44 -0000 --_002_94C682931C08B048B7A8645303FDC9F33C4376DCDCPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, We edited a document to describe why a feature to allow reserving a pair of= port is needed.=20 Comments and suggestions are welcome. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de Internet-Drafts@ietf.org Envoy=E9 : mardi 1 f=E9vrier 2011 14:00 =C0 : i-d-announce@ietf.org Objet : I-D Action:draft-boucadair-pcp-rtp-rtcp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Reservation of Pair of Ports with PCP Author(s) : M. Boucadair, S. Sivakumar Filename : draft-boucadair-pcp-rtp-rtcp-00.txt Pages : 14 Date : 2011-02-01 This document defines a new PCP Option to reserve a pair of ports in a PCP-controlled device. This new PCP Option eases the traversal of NAT for RTP/RTCP flows. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-pcp-rtp-rtcp-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** --_002_94C682931C08B048B7A8645303FDC9F33C4376DCDCPUEXCB1Bnante_ Content-Type: message/external-body; name="draft-boucadair-pcp-rtp-rtcp-00.url" Content-Description: draft-boucadair-pcp-rtp-rtcp-00.url Content-Disposition: attachment; filename="draft-boucadair-pcp-rtp-rtcp-00.url"; size=96; creation-date="Tue, 01 Feb 2011 14:03:37 GMT"; modification-date="Tue, 01 Feb 2011 14:03:37 GMT" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1ib3VjYWRhaXItcGNwLXJ0cC1ydGNwLTAwLnR4dA0K --_002_94C682931C08B048B7A8645303FDC9F33C4376DCDCPUEXCB1Bnante_-- From Francis.Dupont@fdupont.fr Thu Feb 3 05:12:34 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED513A692F for ; Thu, 3 Feb 2011 05:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fpza-2yCvwBY for ; Thu, 3 Feb 2011 05:12:33 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 447703A692C for ; Thu, 3 Feb 2011 05:12:33 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p13DFtiD052167 for ; Thu, 3 Feb 2011 14:15:55 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102031315.p13DFtiD052167@givry.fdupont.fr> From: Francis Dupont To: pcp@ietf.org Date: Thu, 03 Feb 2011 14:15:55 +0100 Sender: Francis.Dupont@fdupont.fr Subject: [pcp] stateless NAT & co X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 13:12:34 -0000 I don't fully understand: - how a stateless NAT (i.e., NAT but not NAPT) is managed - how an address-to-address mapping can be created - when CANNOT_FORWARD_PORT_ZERO should be returned My understanding of the external port in mapping creation (i.e., lifetime > 0) requests is: - without HONOR_EXTERNAL_PORT it is only a hint, i.e., if it is available it will be returned but if it is not available any not-zero external port may be returned instead - with HONOR_EXTERNAL_PORT the given port will be assigned and returned or the CANNOT_HONOR_EXTERNAL_PORT error will be raised. So the value 0 with HONOR_EXTERNAL_PORT doesn't make sense (IMHO a MALFORMED_OPTION should be raised). Now with a NAT which doesn't translate port a mapping creation cannot fail. Internal and external ports will be always the same in responses. Note a firewall is a NAT which translates nothing so a sub case. So: - what is the intented behavior for a zero protocol and zero internal port in a mapping creation request? - is the correct definition of CANNOT_FORWARD_PORT_ZERO? IMHO it is a good name for a failure in the previous operation. Thanks Francis.Dupont@fdupont.fr From dwing@cisco.com Fri Feb 4 10:04:56 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8652D3A69AF for ; Fri, 4 Feb 2011 10:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.54 X-Spam-Level: X-Spam-Status: No, score=-110.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fg+mqycTkPuE for ; Fri, 4 Feb 2011 10:04:55 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 41BE73A6968 for ; Fri, 4 Feb 2011 10:04:55 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMBAIvPS02rR7Hu/2dsb2JhbACWT4FljHlznj6bIoVaBIR6 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 04 Feb 2011 18:08:20 +0000 Received: from dwingWS ([10.32.240.197]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p14I8KVo009001; Fri, 4 Feb 2011 18:08:20 GMT From: "Dan Wing" To: "'Francis Dupont'" , References: <201102031315.p13DFtiD052167@givry.fdupont.fr> In-Reply-To: <201102031315.p13DFtiD052167@givry.fdupont.fr> Date: Fri, 4 Feb 2011 10:08:20 -0800 Message-ID: <05f201cbc496$8190f390$84b2dab0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvDpI5SzzYOsiMFQh2v4SeDxy+jQAA8aO3Q Content-Language: en-us Subject: Re: [pcp] stateless NAT & co X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 18:04:56 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Francis Dupont > Sent: Thursday, February 03, 2011 5:16 AM > To: pcp@ietf.org > Subject: [pcp] stateless NAT & co > > I don't fully understand: > - how a stateless NAT (i.e., NAT but not NAPT) is managed > - how an address-to-address mapping can be created > - when CANNOT_FORWARD_PORT_ZERO should be returned > > My understanding of the external port in mapping creation (i.e., > lifetime > 0) requests is: > - without HONOR_EXTERNAL_PORT it is only a hint, i.e., > if it is available it will be returned but if it is not > available any not-zero external port may be returned instead > - with HONOR_EXTERNAL_PORT the given port will be assigned and > returned or the CANNOT_HONOR_EXTERNAL_PORT error will be raised. > So the value 0 with HONOR_EXTERNAL_PORT doesn't make sense > (IMHO a MALFORMED_OPTION should be raised). > > Now with a NAT which doesn't translate port a mapping creation > cannot fail. Internal and external ports will be always the same > in responses. Note a firewall is a NAT which translates nothing > so a sub case. > > So: > - what is the intented behavior for a zero protocol and zero > internal port in a mapping creation request? The intent was to allow "forward me everything". However, this seems problematic. I propose that we reduce the scope of PCP to only create mappings for protocols with port numbers (TCP, UDP, SCTP, DCCP). If people need other stuff mapped (e.g., IPsec ESP, RSVP, etc.), we may need new OpCodes or may need to explain how the existing OpCodes can be used for those port-"less" protocols. Does that sound reasonable to everyone? -d > - is the correct definition of CANNOT_FORWARD_PORT_ZERO? > IMHO it is a good name for a failure in the previous operation. > > Thanks > > Francis.Dupont@fdupont.fr > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From Francis.Dupont@fdupont.fr Fri Feb 4 13:41:47 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E26DC3A67F2 for ; Fri, 4 Feb 2011 13:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2IZ7sPXzc4D for ; Fri, 4 Feb 2011 13:41:47 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id EB51C3A68FC for ; Fri, 4 Feb 2011 13:41:46 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p14LjBWJ071404; Fri, 4 Feb 2011 22:45:12 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102042145.p14LjBWJ071404@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Fri, 04 Feb 2011 10:08:20 PST. <05f201cbc496$8190f390$84b2dab0$@com> Date: Fri, 04 Feb 2011 22:45:11 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] stateless NAT & co X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 21:41:48 -0000 In your previous mail you wrote: > So: > - what is the intented behavior for a zero protocol and zero > internal port in a mapping creation request? The intent was to allow "forward me everything". However, this seems problematic. => I don't think so in particular if the CANNOT_FORWARD_PORT_ZERO error code is (re)defined to mean it is not supported. I propose that we reduce the scope of PCP to only create mappings for protocols with port numbers (TCP, UDP, SCTP, DCCP). If people need other stuff mapped (e.g., IPsec ESP, RSVP, etc.), we may need new OpCodes or may need to explain how the existing OpCodes can be used for those port-"less" protocols. Does that sound reasonable to everyone? => IMHO there is no reason to limit the protocol as the port 0 is reserved for UDP and TCP. But if we want a map all operation I'd prefer to define it with protocol=0 too. BTW it makes sense with PIN66 too. Thanks Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Sat Feb 5 00:47:19 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 807023A6888 for ; Sat, 5 Feb 2011 00:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmwYuqn2sdKk for ; Sat, 5 Feb 2011 00:47:18 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 976BC3A685A for ; Sat, 5 Feb 2011 00:47:18 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p158ojOB011778 for ; Sat, 5 Feb 2011 09:50:45 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102050850.p158ojOB011778@givry.fdupont.fr> From: Francis Dupont To: pcp@ietf.org Date: Sat, 05 Feb 2011 09:50:45 +0100 Sender: Francis.Dupont@fdupont.fr Subject: [pcp] who is the PCP client in DS-Lite encapsulation mode? X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 08:47:19 -0000 In the encapsulation mode for DS-Lite, the term PCP client is ambiguous because of the encapsulation. I suggest to make the B4 the client because it makes the "same public address" decision easier to apply. Regards Francis.Dupont@fdupont.fr From rpenno@juniper.net Mon Feb 7 12:34:20 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92B663A6EAA for ; Mon, 7 Feb 2011 12:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPTS5p3PHCAF for ; Mon, 7 Feb 2011 12:34:19 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 4445A3A6E94 for ; Mon, 7 Feb 2011 12:34:19 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTVBXT1WReZJd/FF8eNhXU5cxbnFgYfkt@postini.com; Mon, 07 Feb 2011 12:34:24 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 7 Feb 2011 12:33:00 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 7 Feb 2011 15:33:07 -0500 From: Reinaldo Penno To: "pcp@ietf.org" Date: Mon, 7 Feb 2011 15:33:05 -0500 Thread-Topic: Review of pcp-base-3 Thread-Index: AcuxGnH/oFEq0BUFQIqUfjE7XufIxwABnQoQAA6BC4AAFMrhsAAdWvDwAERBjVABKGP/kAPMCE3E Message-ID: In-Reply-To: <12343_1295441711_4D36DF2F_12343_748393_1_94C682931C08B048B7A8645303FDC9F33C401F04D7@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] Review of pcp-base-3 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 20:34:20 -0000 Hi, Some comments and questions on base-03. A) "2.3. Single-homed Customer Premise Network" What about the scenario (which we discussed) where there is a single route to the Internet but other interfaces/routes to VoD/IPTV, VoIP, etc? Is this in or out of scope? AFAIK this is quite common in broadband network= s with setup boxes, integrated CPEs and others. B) "5.1. Request Header" The 'reserve' field seems to serve more as padding to get 16-bit aligned. I wonder if we can move 'reserve' to end of the 16-bit boundary and therefore have a 52-bit contiguous field which can be sliced and diced in different ways in the future. C) " OpCode: 8 reserved bits, MUST be sent as 0, MUST be ignored when received." s/OpCode/Reserved D) " If several Options are included in a PCP request or response, they can be encoded in any order by the PCP client. " Are we positive we do not want to recommend some ordering to facilitate parsing and sanity checking much like IPv6 extension headers, SDP, etc? E) I think some clarification is needed below. Since I'm not sure the original intention, I will just ask some questions inline. " If the "P" bit in the OpCode is set, o the PCP server MUST only generate a positive PCP response if it can successfully process the PCP request and this Option." [Reinaldo] What if there are other options in the request? For example, if PCP server processes options 1 and 2 but finds out it can not process 3, it needs to rollback 1 and 2 in order to send back a negative response. Alternatively, PCP server needs to scan request for options with 'P' bit set, try to satisfy those. Still, if there is more than one, and, say, the second one fails, it needs to rollback the first one and send a negative response? " o if the PCP server does not implement this Option, it MUST generate a failure response without including this Option in the response. [Reinaldo] Same comments as above o If the PCP server does implement this Option, but cannot perform the function indicated by this Option, it MUST generate a failure response and include this Option (and its arguments) in the response." [Reinaldo] Same comments above. I'm confused by all possible scenarios. If options are interdependent, then it would be extra confusing. F) " A host operating a server (e.g., a web server) listens for traffic on a port (but never sends traffic from that port." Typo, need to remove parenthesis '(but'. Also, maybe rephrase to '.. But never initiates outbound connections from that port' G) " PIN66=3D3: create a forwarding pinhole between an internal IPv6 address and public IPv6 address (e.g., NPTv6 or firewall)" NPTv6? Is it something new or it is supposed to be NAT66? H) " A PCP client can request the explicit deletion of all UDP or TCP mappings by sending a PCP request with a PIN OpCode with external port, internal port, and lifetime set to 0. " Does this mean that is the client is dual-stack, it should send up to 4 messages to make sure there are no stale mappings? OpCode PIN44-TCP, PIN66-TCP, PIN44-UDP, PIN66-UDP. If it supports SCCT and DCCP, then 8 messages? I) "8.4.1. Maintaining Same External IP Address If there are active mappings associated with a given subscriber (see Section 10.5) -- created via dynamic assignment, by PCP or any other means -- subsequent PCP mapping requests belonging to the same subscriber MUST use the same external IP address. This follows the intent of REQ-1 of [I-D.ietf-behave-lsn-requirements]." What about static port forwarding mappings? Do such static mappings also mandate that PCP use the external port forwarding IP configured? The client has no way of knowing until it requests the first mapping, after that it could use the same external IP. Furthermore, should dynamic mappings use the external IP configured in a port forwarding mapping as well? Since dynamic mappings influence how PCP selects external IP addresses, and static port forwarding influences dynami= c mappings, then port forwarding also influence PCP? J) "8.4.3. Pinhole Deletion A pinhole MUST be deleted by the PCP Server upon the expiry of its lifetime, or upon request from the PCP client. In order to prevent another subscriber from receiving unwanted traffic, the PCP server SHOULD NOT assign that same external port to another host for 120 seconds (MSL, [RFC0793])." In the case of connect-then-lifetime how this could not be enforced? K) "8.5.1. REMOTE_PEER_FILTER" Can a network prefix be specified? Specifying each IP address individually seems a non-starter L) " To delete all pinholes for all hosts associated with this subscriber, an all-zero internal IP address is used." If a server can not delete all pinholes, what should it send on the response? Should such deletions be atomic - all or nothing? M) " PEER6=3D5: Set or query lifetime for flow from IPv6 address to a remote peer's IPv6 address." PEER6=3D6? N) " 2. Hosts behind the B4 element with either include a PCP client or UPnP IGD client." s/with/will O) "10.1.2. Encapsulation Mode 10.1.3. Plain IPv6 Mode" These modes are not mutually exclusive. A home can have IPv6 and IPv4 clients. PCP requests from IPv4 clients can go through the DS-Lite and plai= n IPv6 requests (whether for NAT66 or NAT64) can go natively. =20 =20 From dwing@cisco.com Mon Feb 7 12:54:44 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FD013A6ECD for ; Mon, 7 Feb 2011 12:54:44 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkkEScOoEfjZ for ; Mon, 7 Feb 2011 12:54:43 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7E6CC3A6ECC for ; Mon, 7 Feb 2011 12:54:43 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgBAMHqT02rR7Ht/2dsb2JhbACWRz+BJox2c553mxKFWgSEeg Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 07 Feb 2011 20:54:48 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p17Ksmqr020178; Mon, 7 Feb 2011 20:54:48 GMT From: "Dan Wing" To: References: Your message of Fri, 04 Feb 2011 10:08:20 PST. <05f201cbc496$8190f390$84b2dab0$@com> <201102042145.p14LjBWJ071404@givry.fdupont.fr> In-Reply-To: <201102042145.p14LjBWJ071404@givry.fdupont.fr> Date: Mon, 7 Feb 2011 12:54:48 -0800 Message-ID: <0d4d01cbc709$42046b10$c60d4130$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvEtNXHDhgY1AElT1GXDzYrFtarbQCVCm1A Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] stateless NAT & co X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 20:54:44 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Friday, February 04, 2011 1:45 PM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] stateless NAT & co > > > In your previous mail you wrote: > > > So: > > - what is the intented behavior for a zero protocol and zero > > internal port in a mapping creation request? > > The intent was to allow "forward me everything". However, this > seems problematic. > > => I don't think so in particular if the CANNOT_FORWARD_PORT_ZERO > error code is (re)defined to mean it is not supported. > > I propose that we reduce the scope of PCP > to only create mappings for protocols with port numbers (TCP, > UDP, SCTP, DCCP). If people need other stuff mapped (e.g., > IPsec ESP, RSVP, etc.), we may need new OpCodes or may need > to explain how the existing OpCodes can be used for those > port-"less" protocols. > > Does that sound reasonable to everyone? > > => IMHO there is no reason to limit the protocol as > the port 0 is reserved for UDP and TCP. But if we want a map all > operation I'd prefer to define it with protocol=0 too. > BTW it makes sense with PIN66 too. I admit the existing text in -03 does not properly support "forward everything to me". For -04, I added text saying we have reduced the scope of PCP. If folks object, and want this supported, let's figure out how to get PCP to best express this. -d From dwing@cisco.com Mon Feb 7 14:52:48 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F4B3A6FB3 for ; Mon, 7 Feb 2011 14:52:47 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaLG9DnR9dsk for ; Mon, 7 Feb 2011 14:52:45 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 567E93A6EA8 for ; Mon, 7 Feb 2011 14:52:45 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloBAKsFUE2rR7H+/2dsb2JhbACWSoFljHZznkONbY0phVoEhHo Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 07 Feb 2011 22:52:50 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p17MqoWD015552; Mon, 7 Feb 2011 22:52:50 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , References: <12343_1295441711_4D36DF2F_12343_748393_1_94C682931C08B048B7A8645303FDC9F33C401F04D7@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Date: Mon, 7 Feb 2011 14:52:50 -0800 Message-ID: <003301cbc719$bf162340$3d4269c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuxGnH/oFEq0BUFQIqUfjE7XufIxwABnQoQAA6BC4AAFMrhsAAdWvDwAERBjVABKGP/kAPMCE3EAAOQilA= Content-Language: en-us Subject: Re: [pcp] Review of pcp-base-3 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 22:52:48 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Reinaldo Penno > Sent: Monday, February 07, 2011 12:33 PM > To: pcp@ietf.org > Subject: [pcp] Review of pcp-base-3 > > Hi, > > Some comments and questions on base-03. > > > A) > > "2.3. Single-homed Customer Premise Network" > > What about the scenario (which we discussed) where there is a single > route > to the Internet but other interfaces/routes to VoD/IPTV, VoIP, etc? > > Is this in or out of scope? AFAIK this is quite common in broadband > networks with setup boxes, integrated CPEs and others. I don't see how to make this work. Do you have ideas? > B) > > "5.1. Request Header" > > The 'reserve' field seems to serve more as padding to get 16-bit > aligned. > > I wonder if we can move 'reserve' to end of the 16-bit boundary and > therefore have a 52-bit contiguous field which can be sliced and diced > in different ways in the future. So, you are suggesting change from: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|Ver=0|reserve|R| OpCode | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved (48 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ to +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|Ver=0|R| OpCode | | +-+-+-+-+-+-+-+-+-+-+-+-+ Reserved (52 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ that seems reasonable to me. I'll make that change in -04. > C) > > " OpCode: 8 reserved bits, MUST be sent as 0, MUST be ignored when > received." > > s/OpCode/Reserved > > > D) > > " If several Options are > included in a PCP request or response, they can be encoded in any > order by the PCP client. " > > Are we positive we do not want to recommend some ordering to facilitate > parsing and sanity checking much like IPv6 extension headers, SDP, etc? If we define such a rule (e.g., lowest valued to highest valued), then we need to explain what happens when they are in a different order (return an error, or Be Liberal In What You Receive?). If it's valuable, please propose a straw man. > E) > > I think some clarification is needed below. Since I'm not sure the > original > intention, I will just ask some questions inline. > > > " If the "P" bit in the OpCode is set, > > o the PCP server MUST only generate a positive PCP response if it > can successfully process the PCP request and this Option." > > [Reinaldo] What if there are other options in the request? For example, > if > PCP server processes options 1 and 2 but finds out it can not process > 3, it > needs to rollback 1 and 2 in order to send back a negative response. The intent which I am hoping to convey is that all of the mandatory-to-process options have to be processed successfully to get a SUCCESS. Failure to process any mandatory-to-process option causes a failure response. Clarified to now read: If the "P" bit in an OpCode is set, * the PCP server MUST only generate a positive PCP response if it can successfully process the PCP request, and this Option, and other Options with the "P" bit set. > Alternatively, PCP server needs to scan request for options with 'P' > bit > set, try to satisfy those. Still, if there is more than one, and, say, > the > second one fails, it needs to rollback the first one and send a > negative response? I don't know what you mean by 'rollback to the first one'. > " o if the PCP server does not implement this Option, it MUST > generate > a failure response without including this Option in the response. > > [Reinaldo] Same comments as above > > o If the PCP server does implement this Option, but cannot perform > the function indicated by this Option, it MUST generate a failure > response and include this Option (and its arguments) in the > response." > > [Reinaldo] Same comments above. I'm confused by all possible scenarios. > If options are interdependent, then it would be extra confusing. I would encourage the community to not define such options. > F) > > " A host operating a server (e.g., a web server) listens for traffic > on > a port (but never sends traffic from that port." > > Typo, need to remove parenthesis '(but'. > > Also, maybe rephrase to '.. But never initiates outbound connections > from > that port' That section is now cleaner in -04. > G) > > " PIN66=3: create a forwarding pinhole between an internal IPv6 > address and public IPv6 address (e.g., NPTv6 or firewall)" > > NPTv6? Is it something new or it is supposed to be NAT66? It's been renamed to "Network Prefix Translation IPv6", see the title abbreviation at the top of each page of http://tools.ietf.org/html/draft-mrw-nat66-07. However, I removed references to NAT66 / NPTv6 from -04. > H) > > " A PCP client can request the explicit deletion of all UDP or TCP > mappings by sending a PCP request with a PIN OpCode with external > port, internal port, and lifetime set to 0. " > > Does this mean that is the client is dual-stack, it should send up to 4 > messages to make sure there are no stale mappings? OpCode PIN44-TCP, > PIN66-TCP, PIN44-UDP, PIN66-UDP. In -04, I have collapsed the PIN44, PIN64, PIN46, and PIN66 messages to simply PIN4 and PIN6. With that change, if the PCP client has an interface, and wants to delete mappings to that interface, it needs to send one message for each protocol (TCP, UDP, etc.). It doesn't matter if the client is dual-stack or not. Consider, for example, a client with both a wired IPv4 Ethernet interface and an IPv4 WiFi interface. That client would need to send two messages on both interfaces. > If it supports SCCT and DCCP, then 8 messages? 8 with the PINxy messages. But in -04, that would now be 4 messages. I believe, from your question, you are implying this is too many messages to send, and you want this optimized? This is related to Francis's recent emails to PCP, I believe, where PCP is currently insufficient in allowing "any" protocol to be mapped to an internal host. If we add that, we can easily add the ability to delete "any" mapping. > I) > > "8.4.1. Maintaining Same External IP Address > > If there are active mappings associated with a given subscriber (see > Section 10.5) -- created via dynamic assignment, by PCP or any other > means -- subsequent PCP mapping requests belonging to the same > subscriber MUST use the same external IP address. This follows the > intent of REQ-1 of [I-D.ietf-behave-lsn-requirements]." > > > What about static port forwarding mappings? That is covered by the "any other means" phrase in the quoted paragraph. > Do such static mappings > also > mandate that PCP use the external port forwarding IP configured? The > client > has no way of knowing until it requests the first mapping, after that > it > could use the same external IP. > > Furthermore, should dynamic mappings use the external IP configured in > a > port forwarding mapping as well? Since dynamic mappings influence how > PCP > selects external IP addresses, and static port forwarding influences > dynamic > mappings, then port forwarding also influence PCP? They all need to be the same. If this is a problem for an implementation (and I can certainly see how it can be a problem), we need to understand if this might break an application. It seems safest to require them all use the same public IP address, of course. > J) > > "8.4.3. Pinhole Deletion > > A pinhole MUST be deleted by the PCP Server upon the expiry of its > lifetime, or upon request from the PCP client. > > In order to prevent another subscriber from receiving unwanted > traffic, the PCP server SHOULD NOT assign that same external port to > another host for 120 seconds (MSL, [RFC0793])." > > In the case of connect-then-lifetime how this could not be enforced? Connect-then-lifetime uses the PEER OpCodes and does not create a pinhole (pinholes are created with the PIN OpCodes). The intent of the PEER opcodes is that they don't change the NAT's existing behavior (whatever that behavior might be). > K) > > "8.5.1. REMOTE_PEER_FILTER" > > Can a network prefix be specified? Specifying each IP address > individually seems a non-starter Added to -04. Thanks. > L) > > " To delete all pinholes for all hosts associated with this > subscriber, > an all-zero internal IP address is used." > > If a server can not delete all pinholes, what should it send on the > response? Should such deletions be atomic - all or nothing? Section 8.4 says: If the PCP server is unable to delete a port mapping, for example, because the mapping was manually configured by a configuration tool, the PCP server MUST still delete as many port mappings as possible, and respond with the result code UNABLE_TO_DELETE_ALL. > M) > > " PEER6=5: Set or query lifetime for flow from IPv6 address to a > remote peer's IPv6 address." > > PEER6=6? > > N) > > " 2. Hosts behind the B4 element with either include a PCP client or > UPnP IGD client." > > s/with/will > > O) > > "10.1.2. Encapsulation Mode > > 10.1.3. Plain IPv6 Mode" > > These modes are not mutually exclusive. A home can have IPv6 and IPv4 > clients. PCP requests from IPv4 clients can go through the DS-Lite and > plain > IPv6 requests (whether for NAT66 or NAT64) can go natively. So, you're saying Issue #13 http://trac.tools.ietf.org/wg/pcp/trac/ticket/13 is wrong -- that is, we don't need to decide Issue #13. Rather, for DS-Lite, both encapsulation modes have to always be supported? -d From Francis.Dupont@fdupont.fr Mon Feb 7 15:11:36 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C13923A6FB3 for ; Mon, 7 Feb 2011 15:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkJ2c-dj-GQj for ; Mon, 7 Feb 2011 15:11:29 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id B87E93A6E93 for ; Mon, 7 Feb 2011 15:11:25 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p17NBUiu039509; Tue, 8 Feb 2011 00:11:30 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102072311.p17NBUiu039509@givry.fdupont.fr> From: Francis Dupont To: Reinaldo Penno In-reply-to: Your message of Mon, 07 Feb 2011 15:33:05 EST. Date: Tue, 08 Feb 2011 00:11:30 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "pcp@ietf.org" Subject: Re: [pcp] Review of pcp-base-3 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 23:11:36 -0000 In your previous mail you wrote: L) " To delete all pinholes for all hosts associated with this subscriber, an all-zero internal IP address is used." If a server can not delete all pinholes, what should it send on the response? Should such deletions be atomic - all or nothing? => this shows again that we need a GET/GETNEXT operation to recover partial multiple deletes. Note we have the same issue with UPnP IGD 2.0 DeletePortMappingRange()... Regards Francis.Dupont@fdupont.fr From Internet-Drafts@ietf.org Mon Feb 7 15:15:02 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2FCD3A6FC9; Mon, 7 Feb 2011 15:15:02 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsEj+Ub77aAJ; Mon, 7 Feb 2011 15:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC19F3A69E7; Mon, 7 Feb 2011 15:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110207231501.27449.10186.idtracker@localhost> Date: Mon, 07 Feb 2011 15:15:01 -0800 Cc: pcp@ietf.org Subject: [pcp] I-D Action:draft-ietf-pcp-base-04.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 23:15:02 -0000 --NextPart 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 : Port Control Protocol (PCP) Author(s) : D. Wing, et al. Filename : draft-ietf-pcp-base-04.txt Pages : 54 Date : 2011-02-07 Port Control Protocol allows a host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall to an IPv6 or IPv4 host, and also allows a host to optimize its NAT keepalive messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcp-base-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-07151311.I-D@ietf.org> --NextPart-- From Francis.Dupont@fdupont.fr Mon Feb 7 15:44:03 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 313053A6FAE for ; Mon, 7 Feb 2011 15:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0pV8tEfmJmp for ; Mon, 7 Feb 2011 15:44:02 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 28ED63A6B0D for ; Mon, 7 Feb 2011 15:44:01 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p17Ni6V4041610; Tue, 8 Feb 2011 00:44:06 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102072344.p17Ni6V4041610@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Mon, 07 Feb 2011 14:52:50 PST. <003301cbc719$bf162340$3d4269c0$@com> Date: Tue, 08 Feb 2011 00:44:06 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] Review of pcp-base-3 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 23:44:03 -0000 In your previous mail you wrote: So, you are suggesting change from: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|Ver=0|reserve|R| OpCode | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved (48 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ to +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|Ver=0|R| OpCode | | +-+-+-+-+-+-+-+-+-+-+-+-+ Reserved (52 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ that seems reasonable to me. I'll make that change in -04. => It doesn't seen a good idea to me: please keep the OpCode on a 8 bit boundary! Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Mon Feb 7 15:50:56 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B10FC3A6FDA for ; Mon, 7 Feb 2011 15:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUcXTXHzqjSz for ; Mon, 7 Feb 2011 15:50:55 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 461B93A6FD9 for ; Mon, 7 Feb 2011 15:50:55 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p17Np0jD041970; Tue, 8 Feb 2011 00:51:00 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102072351.p17Np0jD041970@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Mon, 07 Feb 2011 14:52:50 PST. <003301cbc719$bf162340$3d4269c0$@com> Date: Tue, 08 Feb 2011 00:51:00 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] Review of pcp-base-3 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 23:50:56 -0000 In your previous mail you wrote: With that change, if the PCP client has an interface, and wants to delete mappings to that interface, it needs to send one message for each protocol (TCP, UDP, etc.). => Why not support protocol=0 to delete all mappings? > If it supports SCCT and DCCP, then 8 messages? 8 with the PINxy messages. But in -04, that would now be 4 messages. => you mean 256 messages in fact... This is related to Francis's recent emails to PCP, I believe, where PCP is currently insufficient in allowing "any" protocol to be mapped to an internal host. If we add that, we can easily add the ability to delete "any" mapping. => note it was about any protocol with any port, i.e., any IP packet. But of course I am strongly in favor of this for deletion, per protocol delete all is silly (the only reason to still provide it is for IWF). Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Mon Feb 7 15:59:06 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A683A6FE4 for ; Mon, 7 Feb 2011 15:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgCyY+I5difp for ; Mon, 7 Feb 2011 15:59:05 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 2F6D53A6FDC for ; Mon, 7 Feb 2011 15:59:05 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p17NxAqX042499; Tue, 8 Feb 2011 00:59:10 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102072359.p17NxAqX042499@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Mon, 07 Feb 2011 14:52:50 PST. <003301cbc719$bf162340$3d4269c0$@com> Date: Tue, 08 Feb 2011 00:59:10 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] Review of pcp-base-3 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 23:59:06 -0000 In your previous mail you wrote: > O) > > "10.1.2. Encapsulation Mode > > 10.1.3. Plain IPv6 Mode" > > These modes are not mutually exclusive. A home can have IPv6 and IPv4 > clients. PCP requests from IPv4 clients can go through the DS-Lite and > plain > IPv6 requests (whether for NAT66 or NAT64) can go natively. So, you're saying Issue #13 http://trac.tools.ietf.org/wg/pcp/trac/ticket/13 is wrong -- that is, we don't need to decide Issue #13. Rather, for DS-Lite, both encapsulation modes have to always be supported? => no, Reinaldo put the Encapsulation vs Plain Mode outside the DS-Lite context and concluded they are not exclusive. IMHO he was wrong because DS-Lite uses PIN44 only but with the base-04 changes I haven't yet read perhaps a door is open now... BTW Encapsulation Mode is still different from anything else because messages are encapsulated so are different from PIN44 over IPv6 UDP. Regards Francis.Dupont@fdupont.fr From dwing@cisco.com Mon Feb 7 16:02:45 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D90A23A6EA0 for ; Mon, 7 Feb 2011 16:02:45 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQqFOvPizIf5 for ; Mon, 7 Feb 2011 16:02:44 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C1AB83A6E77 for ; Mon, 7 Feb 2011 16:02:44 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswFAEAXUE2rR7Ht/2dsb2JhbACXCoEmjHZznjmbFIVaBIR6 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 08 Feb 2011 00:02:50 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1802okv014900 for ; Tue, 8 Feb 2011 00:02:50 GMT From: "Dan Wing" To: Date: Mon, 7 Feb 2011 16:02:49 -0800 Message-ID: <009101cbc723$865bff70$9313fe50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvHI4YchV5ek3jnTsWxcQFiOLvSmw== Content-Language: en-us Subject: [pcp] draft-ietf-pcp-base-04 posted X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 00:02:46 -0000 Available at http://tools.ietf.org/html/draft-ietf-pcp-base-04. For diffs, click Diff1 or Diff2 at the top. -d ----- A.1. Changes from draft-ietf-pcp-base-03 to -04 o "Pinhole" and "PIN" changed to "mapping" and "MAP". o Reduced from four MAP OpCodes to two. This was done by implicitly using the address family of the PCP message itself. o New option THIRD_PARTY, to more carefully split out the case where a mapping is created to a different host within the home. o Integrated a lot of editorial changes from Stuart and Francis. o Removed nested NAT text into another document, including the IANA- registered IP addresses for the PCP server. o Removed suggestion (MAY) that PCP server reserve UDP when it maps TCP. Nobody seems to need that. o Clearly added NAT and NAPT, such as in residential NATs, as within scope for PCP. o HONOR_EXTERNAL_PORT renamed to PREFER_FAILURE o Added 'Lifetime' field to the common PCP header, which replaces the functions of the 'temporary' and 'permanent' error types of the previous version. o Allow arbitrary Options to be included in PCP response, so that PCP server can indicate un-supported PCP Options. Satisfies PCP Issue #19 o Reduced scope to only deal with mapping protocols that have port numbers. o Reduced scope to not support DMZ-style forwarding. o Clarified version negotiation. From dwing@cisco.com Mon Feb 7 16:27:30 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1DB3A6C8B for ; Mon, 7 Feb 2011 16:27:30 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYKp5Ol5ifvA for ; Mon, 7 Feb 2011 16:27:29 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B04BA3A6B0A for ; Mon, 7 Feb 2011 16:27:29 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkBAOwcUE2rR7Hu/2dsb2JhbACWSz+BJox2c55pmxCFWgSEeg Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 08 Feb 2011 00:27:35 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p180RYt4028600; Tue, 8 Feb 2011 00:27:34 GMT From: "Dan Wing" To: References: Your message of Mon, 07 Feb 2011 14:52:50 PST. <003301cbc719$bf162340$3d4269c0$@com> <201102072344.p17Ni6V4041610@givry.fdupont.fr> In-Reply-To: <201102072344.p17Ni6V4041610@givry.fdupont.fr> Date: Mon, 7 Feb 2011 16:27:34 -0800 Message-ID: <00b401cbc726$fb600610$f2201230$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvHIQyiG0jmC2PyRQmyStfRtUD/IwABXudQ Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] Review of pcp-base-3 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 00:27:30 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Monday, February 07, 2011 3:44 PM > To: Dan Wing > Cc: 'Reinaldo Penno'; pcp@ietf.org > Subject: Re: [pcp] Review of pcp-base-3 ... > that seems reasonable to me. I'll make that change in -04. > > => It doesn't seen a good idea to me: please keep the OpCode on a 8 bit > boundary! Good point. I'll back out that change for -05. -d From rpenno@juniper.net Mon Feb 7 18:50:52 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8C43A6BE1 for ; Mon, 7 Feb 2011 18:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJ03zMkxbPed for ; Mon, 7 Feb 2011 18:50:51 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 695953A6BAB for ; Mon, 7 Feb 2011 18:50:45 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTVCvip683R7wgvpC0rRU09qwAQnXYItO@postini.com; Mon, 07 Feb 2011 18:50:53 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 7 Feb 2011 18:48:52 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 7 Feb 2011 21:48:59 -0500 From: Reinaldo Penno To: Francis Dupont , Dan Wing Date: Mon, 7 Feb 2011 21:48:57 -0500 Thread-Topic: [pcp] Review of pcp-base-3 Thread-Index: AcvHIQTfDrVgnQTRRaemYf7oC5sYqAAGbYk/ Message-ID: In-Reply-To: <201102072344.p17Ni6V4041610@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Review of pcp-base-3 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 02:50:52 -0000 The Opcode today is 7bits and not 8-bit aligned in the response. If that is a concern, let me suggest growing the Opcode 4 more bits and get rid of the first reserve field. This will make the Opcode response header 16-bit aligned and make the header easier with just one reserved field. On 2/7/11 3:44 PM, "Francis Dupont" wrote: > In your previous mail you wrote: >=20 > So, you are suggesting change from: > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|Ver=3D0|reserve|R| OpCode | = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved (48 bits) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =20 > to > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|Ver=3D0|R| OpCode | = | > +-+-+-+-+-+-+-+-+-+-+-+-+ Reserved (52 bits) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =20 > that seems reasonable to me. I'll make that change in -04. > =20 > =3D> It doesn't seen a good idea to me: please keep the OpCode on a 8 bit > boundary! >=20 > Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Tue Feb 8 04:39:45 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B9F13A6C80 for ; Tue, 8 Feb 2011 04:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lo0GEqRlZ60B for ; Tue, 8 Feb 2011 04:39:44 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 7A5853A712E for ; Tue, 8 Feb 2011 04:39:40 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p18CdkgY088658; Tue, 8 Feb 2011 13:39:46 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102081239.p18CdkgY088658@givry.fdupont.fr> From: Francis Dupont To: Reinaldo Penno In-reply-to: Your message of Mon, 07 Feb 2011 21:48:57 EST. Date: Tue, 08 Feb 2011 13:39:46 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "pcp@ietf.org" Subject: Re: [pcp] Review of pcp-base-3 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 12:39:45 -0000 In your previous mail you wrote: The Opcode today is 7bits and not 8-bit aligned in the response. If that is a concern, let me suggest growing the Opcode 4 more bits and get rid of the first reserve field. This will make the Opcode response header 16-bit aligned and make the header easier with just one reserved field. => agreed Francis.Dupont@fdupont.fr From dwing@cisco.com Tue Feb 8 09:07:46 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41D003A6811 for ; Tue, 8 Feb 2011 09:07:46 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ga7vc0iSdiCn for ; Tue, 8 Feb 2011 09:07:45 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 84C233A680B for ; Tue, 8 Feb 2011 09:07:45 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHwHUU2rR7Ht/2dsb2JhbACYPIx3c6AdmzKFWgSEew Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2011 17:07:51 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p18H7pnK024314; Tue, 8 Feb 2011 17:07:51 GMT From: "Dan Wing" To: , "'Reinaldo Penno'" References: Your message of Mon, 07 Feb 2011 21:48:57 EST. <201102081239.p18CdkgY088658@givry.fdupont.fr> In-Reply-To: <201102081239.p18CdkgY088658@givry.fdupont.fr> Date: Tue, 8 Feb 2011 09:07:51 -0800 Message-ID: <02ac01cbc7b2$b8409f20$28c1dd60$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvHjUkLHhAO1GH+SxS5LHnLPnfT7QAJCLdw Content-Language: en-us Cc: pcp@ietf.org Subject: [pcp] PCP packet layout [was RE: Review of pcp-base-3] X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:07:46 -0000 > In your previous mail you wrote: > > The Opcode today is 7bits and not 8-bit aligned in the response. If > that is > a concern, let me suggest growing the Opcode 4 more bits and get rid > of the > first reserve field. This will make the Opcode response header 16- > bit > aligned and make the header easier with just one reserved field. > > => agreed I don't see a future that would exceed today's 2^7 OpCodes. Today there are only 6 OpCodes that anyone has defined (PIN4, PIN6, PEER4, PEER6, GET, GETNEXT). It seems risky to consume bits with OpCode space when we may need to use the reserved bits in the response header. How about the following, which provides 8-bit alignment of OpCode and Result Code, and keeps all the reserved space together: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|Ver=0| Reserved | Result Code |R| OpCode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -d From trac@tools.ietf.org Tue Feb 8 09:45:05 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B522E3A6816 for ; Tue, 8 Feb 2011 09:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqtbjiqjDAOE for ; Tue, 8 Feb 2011 09:45:05 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 199013A67AD for ; Tue, 8 Feb 2011 09:45:05 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pmrcm-0006zD-D6; Tue, 08 Feb 2011 09:45:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com X-Trac-Project: pcp Date: Tue, 08 Feb 2011 17:45:12 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/8#comment:4 Message-ID: <062.439c92c867957073f63345bf3bc29f84@tools.ietf.org> References: <053.999884c54e878c73d1845f362e743c3b@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <053.999884c54e878c73d1845f362e743c3b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] base #8 (closed): PCP server discovery methods X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:45:05 -0000 #8: PCP server discovery methods Changes (by dwing@…): * status: assigned => closed * resolution: => fixed Comment: In -04, the IANA-assigned address was removed. The steps are now: Prior to sending its first PCP message, the PCP client determines which servers to use. The PCP client tries the following to get a list of PCP servers: 1. if a PCP server is configured (e.g., in a configuration file), the address(es) of the PCP server(s) are used as the list of PCP server(s), else; 2. if DHCP indicates the PCP server(s), the address(es) of the indicated PCP server(s) are used as the list of PCP server(s), else; 3. the address of the default router is used as the PCP server. This issue is now marked Resolved. -- --------------------------------+------------------------------------------- Reporter: dwing@… | Owner: dwing@… Type: defect | Status: closed Priority: critical | Milestone: Component: base | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Tue Feb 8 10:03:14 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B8043A67E2 for ; Tue, 8 Feb 2011 10:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFUGv1EfMIZt for ; Tue, 8 Feb 2011 10:03:13 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AACFA3A672E for ; Tue, 8 Feb 2011 10:03:13 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PmruK-0002bY-FN; Tue, 08 Feb 2011 10:03:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com X-Trac-Project: pcp Date: Tue, 08 Feb 2011 18:03:20 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/21#comment:2 Message-ID: <068.2b4602177a03d02183633ec142f6a93e@tools.ietf.org> References: <059.0275ce5ca293fedfa74f2743d6cea37d@tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <059.0275ce5ca293fedfa74f2743d6cea37d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] base #21 (closed): Epoch=0 amplification attack X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:03:14 -0000 #21: Epoch=0 amplification attack Changes (by dwing@…): * status: new => closed * resolution: => fixed Comment: adding to -05: {{{ When the PCP server reduces its Epoch value, the PCP clients will send PCP requests to refresh their mappings. The PCP server needs to be scaled appropriately to accomodate this traffic. Because PCP lacks a mechanism to simultaneously inform all PCP clients of the Epoch value, the PCP clients will not flood the PCP server simultaneously when the PCP server reduces its Epoch value. }}} -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: dwing@… Type: defect | Status: closed Priority: minor | Milestone: Component: base | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Tue Feb 8 10:20:00 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BD9F3A67FD for ; Tue, 8 Feb 2011 10:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGTXvaIQwua6 for ; Tue, 8 Feb 2011 10:19:59 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4E5643A6803 for ; Tue, 8 Feb 2011 10:19:59 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PmsAY-0001RH-TC; Tue, 08 Feb 2011 10:20:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com X-Trac-Project: pcp Date: Tue, 08 Feb 2011 18:20:06 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/9#comment:2 Message-ID: <062.d27a5d6dd6a0bc630c41dbcb1ca544d6@tools.ietf.org> References: <053.1b1c6f67de455592fb5940d895b67860@tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <053.1b1c6f67de455592fb5940d895b67860@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] base #9 (assigned): Are PCP-created mappings different from TCP SYN-created ones X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:20:00 -0000 X-List-Received-Date: Tue, 08 Feb 2011 18:20:00 -0000 #9: Are PCP-created mappings different from TCP SYN-created ones Comment(by dwing@…): In -03, different OpCodes were created for incoming connections versus extending the lifetime of an existing session. In -03, they were called PIN and PEER. In -04, PIN was renamed to MAP (and simplified). The PEER OpCode is exactly like a normal TCP SYN -- in that sense, it is exactly the same as a dynamically-created mapping, the only difference is learning the timeout of the mapping. No new or exciting security exposure with PEER. The MAP OpCode, however, is different. The PCP request describes the port on the local host for the mapping. It might include the THIRD_PARTY option to describe another host belonging to the same subscriber. In both cases, this is different from a normal dynamic connection. -- --------------------------------+------------------------------------------- Reporter: dwing@… | Owner: dwing@… Type: defect | Status: assigned Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Tue Feb 8 10:23:14 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A19E3A67FC for ; Tue, 8 Feb 2011 10:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlZOA3dSXamD for ; Tue, 8 Feb 2011 10:23:11 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C600A3A681C for ; Tue, 8 Feb 2011 10:22:59 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PmsDT-0007PL-Ea; Tue, 08 Feb 2011 10:23:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com X-Trac-Project: pcp Date: Tue, 08 Feb 2011 18:23:07 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/35#comment:3 Message-ID: <062.d8b389bae487b3543eb2c3a36ffdf972@tools.ietf.org> References: <053.b2b17c91c0f5b0d4ee1c339d09ccde0f@tools.ietf.org> X-Trac-Ticket-ID: 35 In-Reply-To: <053.b2b17c91c0f5b0d4ee1c339d09ccde0f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] base #35 (closed): clients don't know address family of server X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:23:14 -0000 #35: clients don't know address family of server Changes (by dwing@…): * status: reopened => closed * resolution: => fixed Comment: In -05, will add: {{{ The rendezvous function will support IPv4, IPv6, or both. Depending on that support and the application's support of IPv4 or IPv6, the PCP client will need an IPv4 or IPv6 mapping or both. }}} to the "Introduction to PIN and PEER OpCodes?" section. -- -----------------------------+---------------------------------------------- Reporter: dwing@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Ticket URL: pcp From dwing@cisco.com Tue Feb 8 10:30:18 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970133A6820 for ; Tue, 8 Feb 2011 10:30:18 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyl6eyo01S39 for ; Tue, 8 Feb 2011 10:30:17 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 608F63A680B for ; Tue, 8 Feb 2011 10:30:17 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwGAAAaUU2rR7Hu/2dsb2JhbACXFoEmjHdzoSqbNYVaBIR7 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 08 Feb 2011 18:30:25 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p18IUOwo009326 for ; Tue, 8 Feb 2011 18:30:24 GMT From: "Dan Wing" To: Date: Tue, 8 Feb 2011 10:30:25 -0800 Message-ID: <031d01cbc7be$40baf8e0$c230eaa0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvHvkCAlupmqjZASOOVbxbZgEjZOQ== Content-Language: en-us Subject: [pcp] Issue 16 discussion: PCP lifetime expiration with active traffic X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:30:18 -0000 http://trac.tools.ietf.org/wg/pcp/trac/ticket/16 Description: A PCP-allocated port has a lifetime associated with it. When that lifetime expires, do we want to simply delete the mapping or do we want active inside->outside traffic (using that mapping) to keep the connection alive? The difference requires the NAT (and/or PCP server) to remember which mappings have been created with PCP (which should be deleted strictly on their expiration time) versus which mappings have been created by dynamic outbound connections (e.g., TCP SYN) (which should have their mapping lifetimes extended when active inside->outside traffic is seen). I would like to close this issue. Note this issue applies only to MAP4 and MAP6 OpCodes (which create an incoming mapping), because we have already decided that the PEER4 and PEER6 OpCodes (which query and [possibly] adjust the lifetime of an implicit dynamic mapping (e.g., TCP SYN)) will not modify the NAT's existing behavior. Please discuss the merits of: * immediately terminating the mapping when the PCP-controlled lifetime expires, even if there is active traffic. As stated above, this requires the NAT remember this mapping was created by a MAP OpCode. It might remember this by using a certain port range, or a bit in its mapping table, or whatever else the implementation wants to do. OR * keep the mapping alive as long as there is inside->outside traffic. -d From adurand@juniper.net Tue Feb 8 10:55:12 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C56053A6843; Tue, 8 Feb 2011 10:55:12 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0PwcuPmdh75; Tue, 8 Feb 2011 10:55:11 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id E5BD13A6845; Tue, 8 Feb 2011 10:54:59 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTVGRix/Q90sKnx5a0FuTkwmREfHFKZo2@postini.com; Tue, 08 Feb 2011 10:55:13 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 8 Feb 2011 10:54:36 -0800 From: Alain Durand To: "pcp@ietf.org" , "ietf-secretariat@ietf.org" Date: Tue, 8 Feb 2011 10:54:40 -0800 Thread-Topic: PCP webex interim meeting: 2/22/2011 Thread-Index: AcvHwacPoklBc6mkT2m3NDJe/ww8qw== Message-ID: <804FF569-5095-4502-97D5-76C7CFD791A8@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ralph Droms Subject: [pcp] PCP webex interim meeting: 2/22/2011 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:55:13 -0000 Dear wg members. We will organize a PCP interim webex meeting on 2/22 at 7am PST. Dial-in information & agenda will come later. - Alain From rpenno@juniper.net Tue Feb 8 13:07:32 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C47923A683A for ; Tue, 8 Feb 2011 13:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkKzZJCHjqXe for ; Tue, 8 Feb 2011 13:07:32 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 149483A67F3 for ; Tue, 8 Feb 2011 13:07:31 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTVGwmh2ak1s3+kpQmUne8+Jqy1w4UTMl@postini.com; Tue, 08 Feb 2011 13:07:39 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 8 Feb 2011 13:06:57 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 8 Feb 2011 16:07:06 -0500 From: Reinaldo Penno To: Dan Wing , "pcp@ietf.org" Date: Tue, 8 Feb 2011 16:07:04 -0500 Thread-Topic: [pcp] Issue 16 discussion: PCP lifetime expiration with active traffic Thread-Index: AcvHvkCAlupmqjZASOOVbxbZgEjZOQAFeI/5 Message-ID: In-Reply-To: <031d01cbc7be$40baf8e0$c230eaa0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Issue 16 discussion: PCP lifetime expiration with active traffic X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:07:32 -0000 On 2/8/11 10:30 AM, "Dan Wing" wrote: > Please discuss the merits of: >=20 > * immediately terminating the mapping when the PCP-controlled > lifetime expires, even if there is active traffic. As > stated above, this requires the NAT remember this mapping > was created by a MAP OpCode. It might remember this by > using a certain port range, or a bit in its mapping table, > or whatever else the implementation wants to do. > OR > * keep the mapping alive as long as there is inside->outside > traffic. The former is more consistent with the lifetime definition but I think in actual deployments customers will prefer the latter. From wwwrun@core3.amsl.com Tue Feb 8 13:59:16 2011 Return-Path: X-Original-To: pcp@ietf.org Delivered-To: pcp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 1720F3A689C; Tue, 8 Feb 2011 13:59:15 -0800 (PST) From: IETF Secretariat To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110208215916.1720F3A689C@core3.amsl.com> Date: Tue, 8 Feb 2011 13:59:16 -0800 (PST) Cc: pcp@ietf.org Subject: [pcp] PCP WG Virtual Interim Meeting, February 22, 2011 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:59:16 -0000 The PCP Working Group will hold a virtual interim meeting on February 22, 2011 at 7:00 AM PST. The agenda and WebEx dial-in information will follow on the PCP mailing list (http://www.ietf.org/mail-archive/web/pcp/). From trac@tools.ietf.org Tue Feb 8 14:57:16 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60493A681D for ; Tue, 8 Feb 2011 14:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPgCXhX5JUEi for ; Tue, 8 Feb 2011 14:57:16 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9880B3A680D for ; Tue, 8 Feb 2011 14:57:13 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PmwUr-0004FG-JB; Tue, 08 Feb 2011 14:57:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com X-Trac-Project: pcp Date: Tue, 08 Feb 2011 22:57:21 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/24#comment:3 Message-ID: <062.ce6ded295cb968cebc1bba7f2038de41@tools.ietf.org> References: <053.c36c1daca80be11ae021721d8d265b20@tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <053.c36c1daca80be11ae021721d8d265b20@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:57:17 -0000 #24: PCP mappings same public IP address as dynamic mappings Changes (by dwing@…): * status: reopened => closed * resolution: => fixed Comment: In -05, this will now read: {{{ Once an internal host has no implicit dynamic mappings and has no explicit dynamic mappings in the PCP-controlled device, a subsequent PCP request for that internal host MAY be assigned to a different external IP address. Generally, this re-assignment would occur when a CGN device is load balancing newly-seen hosts to its public IPv4 address pool. }}} -- --------------------------------+------------------------------------------- Reporter: dwing@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Tue Feb 8 14:59:37 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EC5F3A680C for ; Tue, 8 Feb 2011 14:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2L5QaxfG-xZW for ; Tue, 8 Feb 2011 14:59:36 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C0D523A67A1 for ; Tue, 8 Feb 2011 14:59:36 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PmwX9-0004Hs-AR; Tue, 08 Feb 2011 14:59:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 08 Feb 2011 22:59:43 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/25#comment:3 Message-ID: <055.82a696293197a2e9fdb8f8de7d026058@tools.ietf.org> References: <046.30263ace2ef32519967dceae4b122815@tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <046.30263ace2ef32519967dceae4b122815@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, dthaler@microsoft.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] base #25 (new): Nested NAT support X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:59:37 -0000 #25: Nested NAT support Changes (by dwing@…): * owner: => dwing@… Comment: nested NAT will be handled in a separate document, draft-wing-pcp-nested- nat -- --------------------------------+------------------------------------------- Reporter: multiple | Owner: dwing@… Type: enhancement | Status: new Priority: major | Milestone: Component: base | Version: 1.0 Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: pcp From Francis.Dupont@fdupont.fr Wed Feb 9 04:14:30 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5E13A696A for ; Wed, 9 Feb 2011 04:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNjza9kkdoJq for ; Wed, 9 Feb 2011 04:14:29 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 9AA813A6945 for ; Wed, 9 Feb 2011 04:14:29 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p19CEcR0075952; Wed, 9 Feb 2011 13:14:38 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102091214.p19CEcR0075952@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Tue, 08 Feb 2011 09:07:51 PST. <02ac01cbc7b2$b8409f20$28c1dd60$@com> Date: Wed, 09 Feb 2011 13:14:38 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] PCP packet layout [was RE: Review of pcp-base-3] X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 12:14:30 -0000 In your previous mail you wrote: I don't see a future that would exceed today's 2^7 OpCodes. => if you believe this why not go to one octet including the first bit for the version and one octet including the response bit for the OpCode? How about the following, which provides 8-bit alignment of OpCode and Result Code, and keeps all the reserved space together: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|Ver=0| Reserved | Result Code |R| OpCode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ => I don't understand the gratuitous shuffle of fields... Francis.Dupont@fdupont.fr (very disappointed by base-04) From Francis.Dupont@fdupont.fr Wed Feb 9 04:38:29 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F5E3A6967 for ; Wed, 9 Feb 2011 04:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FXcyilqqAUG for ; Wed, 9 Feb 2011 04:38:29 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id A8D633A696A for ; Wed, 9 Feb 2011 04:38:28 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p19CcbPI077348; Wed, 9 Feb 2011 13:38:37 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102091238.p19CcbPI077348@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Mon, 07 Feb 2011 16:02:49 PST. <009101cbc723$865bff70$9313fe50$@com> Date: Wed, 09 Feb 2011 13:38:37 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-04 posted X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 12:38:29 -0000 Where/when major changes in this spec were discussed? IMHO we have a problem of procedure here... Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Wed Feb 9 04:46:38 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29A123A69B3 for ; Wed, 9 Feb 2011 04:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZ9RBhObdWhp for ; Wed, 9 Feb 2011 04:46:37 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 204CD3A69AC for ; Wed, 9 Feb 2011 04:46:36 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p19CkkK2077851; Wed, 9 Feb 2011 13:46:46 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102091246.p19CkkK2077851@givry.fdupont.fr> From: Francis Dupont To: "pcp issue tracker" In-reply-to: Your message of Tue, 08 Feb 2011 18:20:06 GMT. <062.d27a5d6dd6a0bc630c41dbcb1ca544d6@tools.ietf.org> Date: Wed, 09 Feb 2011 13:46:46 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] base #9 (assigned): Are PCP-created mappings different from TCP SYN-created ones X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 12:46:38 -0000 In your previous mail you wrote: > The MAP OpCode, however, is different. The PCP request describes the port > on the local host for the mapping. It might include the THIRD_PARTY > option to describe another host belonging to the same subscriber. In both > cases, this is different from a normal dynamic connection. => IMHO the main difference is if the NAT doesn't implement EIM/EIF then the security properties are critically different, i.e., it is far easy for an attacker to (ab)use a PCP mapping (called explicit dynamic mapping in base-04) than a (implicit) dynamic mapping. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Wed Feb 9 04:51:07 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33CA3A69B9 for ; Wed, 9 Feb 2011 04:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFVwyC15s6jP for ; Wed, 9 Feb 2011 04:51:06 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 845433A69C1 for ; Wed, 9 Feb 2011 04:51:06 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p19CpF2T078155; Wed, 9 Feb 2011 13:51:15 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102091251.p19CpF2T078155@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Tue, 08 Feb 2011 10:30:25 PST. <031d01cbc7be$40baf8e0$c230eaa0$@com> Date: Wed, 09 Feb 2011 13:51:15 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] Issue 16 discussion: PCP lifetime expiration with active traffic X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 12:51:07 -0000 In your previous mail you wrote: http://trac.tools.ietf.org/wg/pcp/trac/ticket/16 Description: A PCP-allocated port has a lifetime associated with it. When that lifetime expires, do we want to simply delete the mapping or do we want active inside->outside traffic (using that mapping) to keep the connection alive? The difference requires the NAT (and/or PCP server) to remember which mappings have been created with PCP (which should be deleted strictly on their expiration time) versus which mappings have been created by dynamic outbound connections (e.g., TCP SYN) (which should have their mapping lifetimes extended when active inside->outside traffic is seen). I would like to close this issue. Note this issue applies only to MAP4 and MAP6 OpCodes (which create an incoming mapping), because we have already decided that the PEER4 and PEER6 OpCodes (which query and [possibly] adjust the lifetime of an implicit dynamic mapping (e.g., TCP SYN)) will not modify the NAT's existing behavior. Please discuss the merits of: * immediately terminating the mapping when the PCP-controlled lifetime expires, even if there is active traffic. As stated above, this requires the NAT remember this mapping was created by a MAP OpCode. It might remember this by using a certain port range, or a bit in its mapping table, or whatever else the implementation wants to do. OR * keep the mapping alive as long as there is inside->outside traffic. => there are two sides for possible answers: - from the NAT point of view it is mainly a matter of implementation. With an EIM/EIF NAT no difference (second option) is easier, with other NATs it is the opposite. - from the client point of view the real question is whether the client expects an explicit dynamic mapping to survive its expiry or worst its explicit deletion. IMHO the answer is no, this is why I am in favor of the first option with at least a SHOULD. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Wed Feb 9 06:05:59 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CFBB3A69CC for ; Wed, 9 Feb 2011 06:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xk+w5iZZrB75 for ; Wed, 9 Feb 2011 06:05:57 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 2F8273A69AD for ; Wed, 9 Feb 2011 06:05:57 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p19E66AB082875 for ; Wed, 9 Feb 2011 15:06:06 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102091406.p19E66AB082875@givry.fdupont.fr> From: Francis Dupont To: pcp@ietf.org Date: Wed, 09 Feb 2011 15:06:06 +0100 Sender: Francis.Dupont@fdupont.fr Subject: [pcp] brief review of base-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 14:05:59 -0000 Base-04 is full of random/unsound changes and of course major issues of previous versions are no addressed... Here is a short list of points I wish to get fixed in 05: (3 page 6) - internal vs target address definitions are confusing. It seems the rule is the internal address is either the source address of the request or when it exists the target address from the THIRD_PARTY option. Note as I believe the THIRD_PARTY option brings nothing I'd like to go back to the base-03 stuff about internal addresses. (3 page 7) - in Mapping Types: result of PCP requests -> result of PCP MAP requests - later: "E.g. a PCP request to create a mapping that ^ missing ',' here, request -> MAP request already exists as a static mapping will return a successful result, confirming that the requested mapping exists." With which assigned lifetime? Does this work too for deletion? IMHO the easiest is to step back to failure (not authorized) (5.2 page 10) - IMHO it is a bad idea to include the lifetime in fixed header and only for the assigned lifetime. I understand the reason but there are other ways to introduce a hold down on errors, a new option for instance. (5.2 page 11) - I like the halfway renewal: it makes more sense than previous specs. But I don't have the same opinion about SERVER_OVERLOADED as it introduces a major security issue, in particular without a reasonable maximum hold time. (5.3 page 12) - MALFORMED_OPTION response code -> MALFORMED_OPTION result code - later: in "it MUST generate a failure response": which one? As a general comment this kind of text should be made more accurate, i.e., fails -> fails with XXX result code. (6.1.2 page 15) - with a 12 octet fixed header the minimum response size is 12. - later: the wording is confusing. IMHO there should be the UNSUPP_VERSION case and the other error case. (6.1.2 page 16) - (twice) i.e. -> i.e., (6.1.4 page 17) - there is an ambiguity about the Epoch: the text says "Mappings" but if a NAT loses its implicit dynamic mappings but not its explicit dynamic mappings should it reset its Epoch? BTW it is not possible to directly recover from the lost of implicit dynamic mappings so my opinion is the answer should be no, i.e., only the persistence of explicit dynamic mappings (and static mappings even they are out of scope) matters. (6.2 page 18) - "other fields assigned by the PCP server set to 0" is obviously not enough. BTW at least the Epoch value is an exception... (6.3.1 page 18) - please add a reference to the figure (which is unfortunately on another page): the current text is unreadable. (6.3.1 page 19) - PLEASE DON'T USE "TBD" VALUES (6.3.1 page 19) - I suggest has length: 1 -> has length: >= 1 in order to support more than 4 unprocessed options (even I don't believe it'll happen :-) (7.3 page 22) last sentence: hte -> the (8 page 23) - (twice) public -> external (BTW not only 'public address' is not defined but it is not a synonym as it is more specific) (8.1 page 24) - request and response packet formats were aligned so either they are going to be aligned again or this sentence removed (of course I prefer the first solution) - later: it doesn't make sense to keep the requested lifetime in the OpCode when it was moved to the header, I strongly suggest to go back to the previous layout with the lifetime in the OpCode part. - later: the Protocol field description was lost in editing... (8.1 page 25) e.g. -> e.g., (8.2 page 26) - IMPLICIT_MAPPING_EXISTS (ex AMBIGUOUS) was forgotten (8.3 page 26) - the "an all-zero internal IP address" should be a an all-zero target IP address shouldn't it? (8.[34] pages 26-29) - the current organization is a full mess, for instance why the text of the previous point is in processing a response when obviously it is about forming a request? (8.3 page 27) - please remove external stuff from "A response is matched with a request by comparing the protocol, internal IP address, internal port, external address and external port." (8.3 page 27) - please add the protocol (set to 0) into "To do this, the PCP client sends a MAP request with external port, internal port, and lifetime set to 0." (8.4 page 28) - please detail: "the PCP server MUST return a response indicating that the assigned external port is the same as the internal port." (8.4.2 page 29) - If I understand well the new lifetime rules, when the requested lifetime is > 0 but 'too small' it is round up to the minimum (120 seconds), isn't it? (8.4.4 page 30) - as I already complained about, subscriber renumbering raises a security issue too. (8.5.1 page 31) - the restriction for DS-Lite is a (too) strong constraint. - later: it doesn't make sense to give decisions about the local home security to the ISP. In conclusion this new option doesn't bring more security. At the opposite it clearly removes functionality. - later: I have no idea at all about the use of the protocol field. - this option is partially defined (there is a form for option definition, please use it) (8.5.2 page 32) - MAP44, ... -> MAP4, ... (8.5.3 page 33) - the MUST NOT is silly: I'd like to be free to use the option, i.e., I'll publish code using it and not only for IWF. (8.6 pages 34 & all) - to be replaced by the specific document so I simply ignore it (9.1 page 36) - issue again about "share a similar packet layout for both requests and responses." (9.1 page 37) - note the internal address field was kept. - later: Requested lifetime too. (9.4 page 40) - please define "its configured maximum lifetime value" (I have no idea about what this means) (10.1.3 page 41) - BTW Plain IPv6 Mode is trivially incompatible with the new MAPx's. (11 pages 44 & all) - to be replaced by the specific document so I simply ignore it (12 pages 47-48) - still nothing about explicit dynamic mapping theft... Seriously you have less than 4 weeks to fix this or the PCP WG session at Prague will be 'intesting'. (http://en.wikipedia.org/wiki/May_you_live_in_interesting_times) Regards Francis.Dupont@fdupont.fr From dwing@cisco.com Wed Feb 9 07:51:22 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 073053A67AF for ; Wed, 9 Feb 2011 07:51:22 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIS1yidK9xyY for ; Wed, 9 Feb 2011 07:51:21 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E42263A6767 for ; Wed, 9 Feb 2011 07:51:20 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUBADpHUk2rR7Ht/2dsb2JhbACWaT+BJox2c6E0mxiFXASEfw Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 09 Feb 2011 15:51:30 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p19FpUrt001658; Wed, 9 Feb 2011 15:51:30 GMT From: "Dan Wing" To: References: Your message of Mon, 07 Feb 2011 16:02:49 PST. <009101cbc723$865bff70$9313fe50$@com> <201102091238.p19CcbPI077348@givry.fdupont.fr> In-Reply-To: <201102091238.p19CcbPI077348@givry.fdupont.fr> Date: Wed, 9 Feb 2011 07:51:30 -0800 Message-ID: <06dd01cbc871$381522c0$a83f6840$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvIVlUPTltZ4jGHQuqXugB+uIwfDgAGoZdg Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-04 posted X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 15:51:22 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Wednesday, February 09, 2011 4:39 AM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] draft-ietf-pcp-base-04 posted > > Where/when major changes in this spec were discussed? Please be more specific. > IMHO we have a problem of procedure here... Major issues are in the tracker, and documented as text is integrated to close them or new information is available. Those emails are automatically sent to the PCP mailing list. For example, http://www.ietf.org/mail-archive/web/pcp/current/msg00767.html Reply-all to those messages if there is an objection. -d From dwing@cisco.com Wed Feb 9 08:01:30 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61F813A67AE for ; Wed, 9 Feb 2011 08:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.149 X-Spam-Level: X-Spam-Status: No, score=-109.149 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiIU-rz3+A76 for ; Wed, 9 Feb 2011 08:01:29 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7289B3A659A for ; Wed, 9 Feb 2011 08:01:29 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJRJUk2rRN+K/2dsb2JhbACYTox2c6EimxiFXASEfw Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 09 Feb 2011 16:01:39 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p19G1dm4007754; Wed, 9 Feb 2011 16:01:39 GMT From: "Dan Wing" To: , "'pcp issue tracker'" References: Your message of Tue, 08 Feb 2011 18:20:06 GMT. <062.d27a5d6dd6a0bc630c41dbcb1ca544d6@tools.ietf.org> <201102091246.p19CkkK2077851@givry.fdupont.fr> In-Reply-To: <201102091246.p19CkkK2077851@givry.fdupont.fr> Date: Wed, 9 Feb 2011 08:01:38 -0800 Message-ID: <06df01cbc872$a2cc5c40$e86514c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvIV25kHNulw4e3R0uq8MEjyOYj5wAGwvGA Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] base #9 (assigned): Are PCP-created mappings different from TCP SYN-created ones X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 16:01:30 -0000 > In your previous mail you wrote: > > > The MAP OpCode, however, is different. The PCP request describes > the port > > on the local host for the mapping. It might include the > THIRD_PARTY > > option to describe another host belonging to the same subscriber. > In both > > cases, this is different from a normal dynamic connection. > > => IMHO the main difference is if the NAT doesn't implement EIM/EIF > then > the security properties are critically different, i.e., it is far easy > for > an attacker to (ab)use a PCP mapping (called explicit dynamic mapping > in > base-04) than a (implicit) dynamic mapping. An attacker, running a PCP client on the victim host, to open NAT (or firewall) mappings, so that the attacker can send packets from the Internet to the victim host? -d From Francis.Dupont@fdupont.fr Wed Feb 9 08:42:30 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 125AE3A67D1 for ; Wed, 9 Feb 2011 08:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6izStf1VpiUL for ; Wed, 9 Feb 2011 08:42:29 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 11B533A69CD for ; Wed, 9 Feb 2011 08:42:28 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p19Ggbmk092442; Wed, 9 Feb 2011 17:42:38 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102091642.p19Ggbmk092442@givry.fdupont.fr> From: Francis Dupont To: "pcp issue tracker" In-reply-to: Your message of Tue, 08 Feb 2011 22:57:21 GMT. <062.ce6ded295cb968cebc1bba7f2038de41@tools.ietf.org> Date: Wed, 09 Feb 2011 17:42:37 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 16:42:30 -0000 I strongly disagree: the external address must be per subscriber, not per host (or per host only when there is no subscriber, BTW DS-Lite requires per subscriber (cf REQ-1 of draft-ietf-behave-lsn-requirements-00.txt) and for the CGN side of NAT444 hosts are not visible so I don't know there is a case where one can see a difference). Regards Francis.Dupont@fdupont.fr PS: for IWF IGD the State Variables, including ExternaIPAddress, are clearly global (i.e., per WANIPConnection service instance). So per control point ExternaIPAddress is *not* allowed. From dwing@cisco.com Wed Feb 9 09:30:38 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 216643A6846 for ; Wed, 9 Feb 2011 09:30:38 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7H52EyL2KLQ for ; Wed, 9 Feb 2011 09:30:36 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 48E2E3A67B5 for ; Wed, 9 Feb 2011 09:30:36 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUBALldUk2rR7Ht/2dsb2JhbACWbT+BJox2c6B7myOFXASEfw Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 09 Feb 2011 17:30:46 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p19HUknV025935; Wed, 9 Feb 2011 17:30:46 GMT From: "Dan Wing" To: References: Your message of Tue, 08 Feb 2011 22:57:21 GMT. <062.ce6ded295cb968cebc1bba7f2038de41@tools.ietf.org> <201102091642.p19Ggbmk092442@givry.fdupont.fr> In-Reply-To: <201102091642.p19Ggbmk092442@givry.fdupont.fr> Date: Wed, 9 Feb 2011 09:30:45 -0800 Message-ID: <075501cbc87f$15b9c8d0$412d5a70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvIeGeaozHd1RUWQ9q10lBXE0UO5AAApdcw Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 17:30:38 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Wednesday, February 09, 2011 8:43 AM > To: pcp issue tracker > Cc: dwing@cisco.com; pcp@ietf.org > Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP > address as dynamic mappings > > I strongly disagree: the external address must be per subscriber, > not per host (or per host only when there is no subscriber, > BTW DS-Lite requires per subscriber (cf REQ-1 of > draft-ietf-behave-lsn-requirements-00.txt) and for the CGN > side of NAT444 hosts are not visible so I don't know there is > a case where one can see a difference). > > Regards > > Francis.Dupont@fdupont.fr > > PS: for IWF IGD the State Variables, including ExternaIPAddress, > are clearly global (i.e., per WANIPConnection service instance). > So per control point ExternaIPAddress is *not* allowed. The text in -05 (which isn't yet published) currently says: 8.4.1. Maintaining Same External IP Address If there are active mappings associated with a given subscriber (see Section 10.5) -- created via dynamic assignment, by PCP or any other means -- subsequent PCP mapping requests belonging to the same subscriber MUST use the same external IP address. This follows the intent of REQ-1 of [I-D.ietf-behave-lsn-requirements]. Once an internal host has no implicit dynamic mappings and has no explicit dynamic mappings in the PCP-controlled device, a subsequent PCP request for that internal host MAY be assigned to a different external IP address. Generally, this re-assignment would occur when a CGN device is load balancing newly-seen hosts to its public IPv4 address pool. If I understand correctly, you want the second paragraph to replace "internal host" with "all hosts belonging to a given subscriber"? -d From Francis.Dupont@fdupont.fr Wed Feb 9 09:37:00 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76E343A67A5 for ; Wed, 9 Feb 2011 09:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4le+CxUBF6it for ; Wed, 9 Feb 2011 09:36:59 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 62A813A6811 for ; Wed, 9 Feb 2011 09:36:59 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p19Hb86r096473; Wed, 9 Feb 2011 18:37:08 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102091737.p19Hb86r096473@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Wed, 09 Feb 2011 07:51:30 PST. <06dd01cbc871$381522c0$a83f6840$@com> Date: Wed, 09 Feb 2011 18:37:08 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-04 posted X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 17:37:00 -0000 In your previous mail you wrote: > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Wednesday, February 09, 2011 4:39 AM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] draft-ietf-pcp-base-04 posted > > Where/when major changes in this spec were discussed? Please be more specific. => move the assigned lifetime to the fixed header, remove the internal address, etc. > IMHO we have a problem of procedure here... Major issues are in the tracker, and documented as text is integrated to close them or new information is available. Those emails are automatically sent to the PCP mailing list. For example, http://www.ietf.org/mail-archive/web/pcp/current/msg00767.html Reply-all to those messages if there is an objection. => so what are the tickets for the two examples I cited? Regards Francis.Dupont@fdupont.fr PS: Obviously the base document editing is not driven by the tracker... (BTW do not take this on attack against you but there is clearly something wrong in the way the base document is (or not) improved). From trac@tools.ietf.org Wed Feb 9 09:52:44 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B780C3A67BD for ; Wed, 9 Feb 2011 09:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y941gm+OweIH for ; Wed, 9 Feb 2011 09:52:44 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 10C043A67A5 for ; Wed, 9 Feb 2011 09:52:44 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PnEDm-0004Za-B9; Wed, 09 Feb 2011 09:52:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com X-Trac-Project: pcp Date: Wed, 09 Feb 2011 17:52:54 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/24#comment:4 Message-ID: <062.c051be6889bed610b1ea6609ad717c0f@tools.ietf.org> References: <053.c36c1daca80be11ae021721d8d265b20@tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <053.c36c1daca80be11ae021721d8d265b20@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 17:52:44 -0000 #24: PCP mappings same public IP address as dynamic mappings Comment(by dwing@…): New option, UNPROCESSED, was added in -04. This issue is closed. -- --------------------------------+------------------------------------------- Reporter: dwing@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: pcp From rpenno@juniper.net Wed Feb 9 11:31:04 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA183A69F5 for ; Wed, 9 Feb 2011 11:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaKzTsoNuwAJ for ; Wed, 9 Feb 2011 11:31:03 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id ED9D23A69F1 for ; Wed, 9 Feb 2011 11:30:56 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTVLreh5wkHi6rmALQEg1H/kRcpef/hgj@postini.com; Wed, 09 Feb 2011 11:31:09 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 9 Feb 2011 11:27:05 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 9 Feb 2011 14:27:15 -0500 From: Reinaldo Penno To: Dan Wing , "Francis.Dupont@fdupont.fr" Date: Wed, 9 Feb 2011 14:27:13 -0500 Thread-Topic: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings Thread-Index: AcvIeGeaozHd1RUWQ9q10lBXE0UO5AAApdcwAAUW0Ro= Message-ID: In-Reply-To: <075501cbc87f$15b9c8d0$412d5a70$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 19:31:04 -0000 I think this requirement needs more discussion. Maybe 'LSN requirements' wa= s too focused on NAT444 because that is the history of the document. A 'subscriber' can be an enterprise over IPoE, PPP, and many others. You ca= n only map all hosts within a subscriber to the same public if you know which hosts belong to a subscriber to begin with. This is not always the case. On 2/9/11 9:30 AM, "Dan Wing" wrote: >> -----Original Message----- >> From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] >> Sent: Wednesday, February 09, 2011 8:43 AM >> To: pcp issue tracker >> Cc: dwing@cisco.com; pcp@ietf.org >> Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP >> address as dynamic mappings >>=20 >> I strongly disagree: the external address must be per subscriber, >> not per host (or per host only when there is no subscriber, >> BTW DS-Lite requires per subscriber (cf REQ-1 of >> draft-ietf-behave-lsn-requirements-00.txt) and for the CGN >> side of NAT444 hosts are not visible so I don't know there is >> a case where one can see a difference). >>=20 >> Regards >>=20 >> Francis.Dupont@fdupont.fr >>=20 >> PS: for IWF IGD the State Variables, including ExternaIPAddress, >> are clearly global (i.e., per WANIPConnection service instance). >> So per control point ExternaIPAddress is *not* allowed. >=20 > The text in -05 (which isn't yet published) currently says: >=20 > 8.4.1. Maintaining Same External IP Address >=20 > If there are active mappings associated with a given subscriber (see > Section 10.5) -- created via dynamic assignment, by PCP or any other > means -- subsequent PCP mapping requests belonging to the same > subscriber MUST use the same external IP address. This follows the > intent of REQ-1 of [I-D.ietf-behave-lsn-requirements]. >=20 > Once an internal host has no implicit dynamic mappings and has no > explicit dynamic mappings in the PCP-controlled device, a subsequent > PCP request for that internal host MAY be assigned to a different > external IP address. Generally, this re-assignment would occur when > a CGN device is load balancing newly-seen hosts to its public IPv4 > address pool. >=20 > If I understand correctly, you want the second paragraph to replace > "internal host" with "all hosts belonging to a given subscriber"? >=20 > -d >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From Francis.Dupont@fdupont.fr Wed Feb 9 15:03:59 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D81A13A684F for ; Wed, 9 Feb 2011 15:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aw3Sd67WiJHE for ; Wed, 9 Feb 2011 15:03:59 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id C27A43A67FA for ; Wed, 9 Feb 2011 15:03:58 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p19N485G016592; Thu, 10 Feb 2011 00:04:08 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102092304.p19N485G016592@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Wed, 09 Feb 2011 08:01:38 PST. <06df01cbc872$a2cc5c40$e86514c0$@com> Date: Thu, 10 Feb 2011 00:04:08 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org, 'pcp issue tracker' Subject: Re: [pcp] base #9 (assigned): Are PCP-created mappings different from TCP SYN-created ones X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 23:04:00 -0000 In your previous mail you wrote: > it is far easier for an attacker to (ab)use a PCP mapping (called > explicit dynamic mapping in base-04) than a (implicit) dynamic > mapping. An attacker, running a PCP client on the victim host, => no, an attacker in the Internet. so that the attacker can send packets from the Internet to the victim host? Francis.Dupont@fdupont.fr PS: I don't understand why I have to discuss about it: it is in the EIF specs (in the reason of not requiring unconditionally EIF). From Francis.Dupont@fdupont.fr Wed Feb 9 15:16:05 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DBFA3A67AC for ; Wed, 9 Feb 2011 15:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SNonntjTNh3 for ; Wed, 9 Feb 2011 15:16:04 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 934C93A65A6 for ; Wed, 9 Feb 2011 15:16:04 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p19NGBRw017436; Thu, 10 Feb 2011 00:16:11 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102092316.p19NGBRw017436@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Wed, 09 Feb 2011 09:30:45 PST. <075501cbc87f$15b9c8d0$412d5a70$@com> Date: Thu, 10 Feb 2011 00:16:11 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 23:16:05 -0000 In your previous mail you wrote: The text in -05 (which isn't yet published) currently says: 8.4.1. Maintaining Same External IP Address If there are active mappings associated with a given subscriber (see Section 10.5) -- created via dynamic assignment, by PCP or any other means -- subsequent PCP mapping requests belonging to the same subscriber MUST use the same external IP address. This follows the intent of REQ-1 of [I-D.ietf-behave-lsn-requirements]. Once an internal host has no implicit dynamic mappings and has no explicit dynamic mappings in the PCP-controlled device, a subsequent PCP request for that internal host MAY be assigned to a different external IP address. Generally, this re-assignment would occur when a CGN device is load balancing newly-seen hosts to its public IPv4 address pool. If I understand correctly, you want the second paragraph to replace "internal host" with "all hosts belonging to a given subscriber"? => yes and I believe 'has no mapping of any kind' is better than 'has no implicit ... and has no explicit...'. BTW I can't see how with your proposed wording the first and second paragraphs are compatible. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Wed Feb 9 15:21:12 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08CFE3A672F for ; Wed, 9 Feb 2011 15:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaVHzGX8nHay for ; Wed, 9 Feb 2011 15:21:11 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id E15A73A65A6 for ; Wed, 9 Feb 2011 15:21:10 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p19NLJaP017786; Thu, 10 Feb 2011 00:21:20 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102092321.p19NLJaP017786@givry.fdupont.fr> From: Francis Dupont To: "pcp issue tracker" In-reply-to: Your message of Wed, 09 Feb 2011 17:52:54 GMT. <062.c051be6889bed610b1ea6609ad717c0f@tools.ietf.org> Date: Thu, 10 Feb 2011 00:21:19 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 23:21:12 -0000 I am afraid the ticket number is not #24 (IMHO it is #19)... Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Wed Feb 9 15:40:55 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B1033A672E for ; Wed, 9 Feb 2011 15:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NY98sS6CK--5 for ; Wed, 9 Feb 2011 15:40:54 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 315F23A65A6 for ; Wed, 9 Feb 2011 15:40:54 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p19Nf4cK019080; Thu, 10 Feb 2011 00:41:04 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102092341.p19Nf4cK019080@givry.fdupont.fr> From: Francis Dupont To: Reinaldo Penno In-reply-to: Your message of Wed, 09 Feb 2011 14:27:13 EST. Date: Thu, 10 Feb 2011 00:41:04 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "pcp@ietf.org" Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 23:40:55 -0000 In your previous mail you wrote: I think this requirement needs more discussion. Maybe 'LSN requirements' was too focused on NAT444 because that is the history of the document. => I agree it seems CGNs/LSNs are only DS-Lite AFTRs and the ISP side of NAT444. Both are very similar so if someone invents a third option many details won't match. A 'subscriber' can be an enterprise over IPoE, PPP, and many others. You can only map all hosts within a subscriber to the same public if you know which hosts belong to a subscriber to begin with. This is not always the case. => I am afraid the subscriber notion is essential for the security, so the other case has a major security issue which is addressed in a way I'd like to know before going further. Regards Francis.Dupont@fdupont.fr From dwing@cisco.com Wed Feb 9 15:44:43 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A1EE3A67F3 for ; Wed, 9 Feb 2011 15:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.632 X-Spam-Level: X-Spam-Status: No, score=-109.632 tagged_above=-999 required=5 tests=[AWL=0.967, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMawKTJlfrjH for ; Wed, 9 Feb 2011 15:44:42 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0217B3A672F for ; Wed, 9 Feb 2011 15:44:42 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikBAMq1Uk2rRN+K/2dsb2JhbACXCIFljHdzoDObLIVcBIR/ X-IronPort-AV: E=Sophos;i="4.60,448,1291593600"; d="scan'208";a="260382198" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2011 23:44:52 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p19NiqqN005101; Wed, 9 Feb 2011 23:44:52 GMT From: "Dan Wing" To: References: Your message of Wed, 09 Feb 2011 07:51:30 PST. <06dd01cbc871$381522c0$a83f6840$@com> <201102091737.p19Hb86r096473@givry.fdupont.fr> In-Reply-To: <201102091737.p19Hb86r096473@givry.fdupont.fr> Date: Wed, 9 Feb 2011 15:44:51 -0800 Message-ID: <077801cbc8b3$586498c0$092dca40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvIf/4eMyNbfxAAT7Sef4EP7YFoMQAAbHuQ Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-04 posted X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 23:44:43 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Wednesday, February 09, 2011 9:37 AM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] draft-ietf-pcp-base-04 posted > > > In your previous mail you wrote: > > > -----Original Message----- > > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > > Sent: Wednesday, February 09, 2011 4:39 AM > > To: Dan Wing > > Cc: pcp@ietf.org > > Subject: Re: [pcp] draft-ietf-pcp-base-04 posted > > > > Where/when major changes in this spec were discussed? > > Please be more specific. > > => move the assigned lifetime to the fixed header, The semantic change to the protocol was changing from permanent/temporary errors to returning a "retry in [seconds]" field. The "temporary" and "permanent" errors were problematic, because a "permanent" condition could actually solve itself sometime in the future (e.g., PCP server was too busy), and a hint is needed to tell the client how long "temporary" might be (a few seconds or a few minutes). I originally added text for an option called RETRY_IN. However, this option was only sent some times (not on every error), which made the protocol more fragile. So, for reasons similar to the decision to put Epoch in all packets, the RETRY value is in all packets. Once that was done, it seemed efficient to have one field used for both the RETRY value (which is only used on errors) and the same field for the LIFETIME value (which is only used on success). There are other ways this could be designed, of course -- such as, for example, always adding the RETRY_IN option to error responses. > remove the internal address, etc. This was done to simplify the PCP client implementation. PCP is mostly expected to be used by hosts wanting to open connections to themselves. So specifying the internal-ip-address is redundant, as it matches the source IP address of the PCP packet itself. This change also allows reducing from 4 OpCodes (PIN44, PIN64, PIN46, PIN66) to two opcodes (MAP4, MAP6). This also simplifies PCP clients with multiple interfaces (e.g., an IPv4 address from Ethernet and another IPv4 address from Wifi, or a dual-stack client). For the cases where a 3rd party mapping is needed, the new THIRD_PARTY option makes it very clear to both the PCP client and the PCP server that a 3rd party mapping is desired. This change did not change the semantics of the protocol -- the protocol still does the same thing and allows the same functions. It just does it in a simpler manner. > > IMHO we have a problem of procedure here... > > Major issues are in the tracker, and documented as text is > integrated to close them or new information is available. Those > emails are automatically sent to the PCP mailing list. For example, > http://www.ietf.org/mail-archive/web/pcp/current/msg00767.html > > Reply-all to those messages if there is an objection. > > => so what are the tickets for the two examples I cited? Those two changes reduce the protocol's complexity, without changing its semantics. Glancing at the various tickets, most concern semantic changes. -d > Regards > > Francis.Dupont@fdupont.fr > > PS: Obviously the base document editing is not driven by > the tracker... (BTW do not take this on attack against you > but there is clearly something wrong in the way the base > document is (or not) improved). From dwing@cisco.com Wed Feb 9 15:44:43 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A7173A672F for ; Wed, 9 Feb 2011 15:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.874 X-Spam-Level: X-Spam-Status: No, score=-109.874 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0hVdRgcc+sh for ; Wed, 9 Feb 2011 15:44:42 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id ACF6E3A67AC for ; Wed, 9 Feb 2011 15:44:42 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoBAMq1Uk2rRN+K/2dsb2JhbACXCD+BJox3c6AzmyyFXASEfw X-IronPort-AV: E=Sophos;i="4.60,448,1291593600"; d="scan'208";a="308620401" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 09 Feb 2011 23:44:53 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p19NiqqO005101; Wed, 9 Feb 2011 23:44:53 GMT From: "Dan Wing" To: References: Your message of Tue, 08 Feb 2011 09:07:51 PST. <02ac01cbc7b2$b8409f20$28c1dd60$@com> <201102091214.p19CEcR0075952@givry.fdupont.fr> In-Reply-To: <201102091214.p19CEcR0075952@givry.fdupont.fr> Date: Wed, 9 Feb 2011 15:44:51 -0800 Message-ID: <077901cbc8b3$58b48d80$0a1da880$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvIUvAG44T7Cz3+QTeOnEIipwTxfgAQ5tSQ Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] PCP packet layout [was RE: Review of pcp-base-3] X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 23:44:43 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Wednesday, February 09, 2011 4:15 AM > To: Dan Wing > Cc: 'Reinaldo Penno'; pcp@ietf.org > Subject: Re: PCP packet layout [was RE: [pcp] Review of pcp-base-3] > > > In your previous mail you wrote: > > I don't see a future that would exceed today's 2^7 OpCodes. > > => if you believe this why not go to one octet including the first bit > for the version and one octet including the response bit for the > OpCode? > > > How about the following, which provides 8-bit alignment of OpCode > and Result Code, and keeps all the reserved space together: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|Ver=0| Reserved | Result Code |R| OpCode | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > => I don't understand the gratuitous shuffle of fields... Reinaldo suggested having two sections of 'reserved' bits could be reduced to have one section of 'reserved' bits. -d > Francis.Dupont@fdupont.fr (very disappointed by base-04) > > From dwing@cisco.com Wed Feb 9 18:14:21 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 423593A6826 for ; Wed, 9 Feb 2011 18:14:21 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsyZI3SH+tqW for ; Wed, 9 Feb 2011 18:14:18 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 36A5F3A67FA for ; Wed, 9 Feb 2011 18:14:18 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikBAPLYUk2rR7H+/2dsb2JhbACXDoFljHdzn02bL4MYAQSCPwSEfw X-IronPort-AV: E=Sophos;i="4.60,448,1291593600"; d="scan'208";a="308670480" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 10 Feb 2011 02:14:29 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1A2ESFk002501; Thu, 10 Feb 2011 02:14:29 GMT From: "Dan Wing" To: "'Francis Dupont'" , References: <201102091406.p19E66AB082875@givry.fdupont.fr> In-Reply-To: <201102091406.p19E66AB082875@givry.fdupont.fr> Date: Wed, 9 Feb 2011 18:14:28 -0800 Message-ID: <098a01cbc8c8$3f47b6f0$bdd724d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvIYpOrUokAmoyTRoGu2K521BvY6AANkDIg Content-Language: en-us Subject: Re: [pcp] brief review of base-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 02:14:21 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Francis Dupont > Sent: Wednesday, February 09, 2011 6:06 AM > To: pcp@ietf.org > Subject: [pcp] brief review of base-04 > > Base-04 is full of random/unsound changes and of course > major issues of previous versions are no addressed... > > Here is a short list of points I wish to get fixed in 05: > > (3 page 6) > - internal vs target address definitions are confusing. > It seems the rule is the internal address is either the > source address of the request or when it exists the target > address from the THIRD_PARTY option. Editing error. The definition should be talking about the THIRD_PARTY option, rather than a Target Address. Corrected on my local version. > Note as I believe the THIRD_PARTY option brings nothing > I'd like to go back to the base-03 stuff about internal > addresses. Using a separate option brings several advantages that I described in another email (which is in flight to the PCP mailer as I type this response). > (3 page 7) > - in Mapping Types: result of PCP requests -> result of > PCP MAP requests Fixed. Thanks. > - later: > "E.g. a PCP request to create a mapping that > ^ missing ',' here, request -> MAP request Fixed. Thanks. > already exists as a static mapping will return a successful > result, confirming that the requested mapping exists." > > With which assigned lifetime? With the lifetime the PCP server wants to use. Typically, the PCP server would extend the lifetime based on the requested-lifetime. Does this need to be spelled out in this example?? > Does this work too for deletion? Yes, section 8.4 says: " If the PCP client attempts to delete a mapping that does not exist, the success response code is returned." > IMHO the easiest is to step back to failure (not authorized) I don't follow. > (5.2 page 10) > - IMHO it is a bad idea to include the lifetime in fixed header > and only for the assigned lifetime. > I understand the reason but there are other ways to introduce > a hold down on errors, a new option for instance. There are two issues here: (1) adding a RETRY field, and (2) overloading that field to indicate lifetime (on success responses) and retry (on error responses). Yes, a separate option might be better. I had text in an interim version of the document that did exactly that. It didn't seem the best way to handle retries -- especially for things like malformed requests, where the response's RETRY_IN option would (?) need to be at the end of the copied request. Would removing the overloading be acceptable? That is, just have the field in the common header indicate the RETRY value, and leave LIFETIME in the OpCodes themselves? > (5.2 page 11) > - I like the halfway renewal: it makes more sense than previous > specs. > But I don't have the same opinion about SERVER_OVERLOADED as > it introduces a major security issue, in particular without > a reasonable maximum hold time. I'm sorry, what is the major security issue? That an on-path device might spoof the PCP Server and send back SERVER_OVERLOADED?? Or something else? > (5.3 page 12) > - MALFORMED_OPTION response code -> MALFORMED_OPTION result code Tx. Fixed. > - later: in "it MUST generate a failure response": which one? Added "with code UNSUPP_OPTION or MALFORMED OPTION (as appropriate)". > As a general comment this kind of text should be made more > accurate, i.e., fails -> fails with XXX result code. Most of the client processing and server processing needs a serious cleanup. I acknowledge that still needs to be done. > (6.1.2 page 15) > - with a 12 octet fixed header the minimum response size is 12. Thanks. Fixed. > - later: the wording is confusing. IMHO there should be the > UNSUPP_VERSION case and the other error case. I moved the existing version text into its own new section, and added a pointer to that section. > (6.1.2 page 16) > - (twice) i.e. -> i.e., Fixed. > (6.1.4 page 17) > - there is an ambiguity about the Epoch: the text says "Mappings" > but if a NAT loses its implicit dynamic mappings but not its > explicit dynamic mappings should it reset its Epoch? > BTW it is not possible to directly recover from the lost of > implicit dynamic mappings so my opinion is the answer should > be no, i.e., only the persistence of explicit dynamic mappings Agreed. Clarified with: If the PCP server resets or loses the state of its explicit dynamic Mappings (that is, those mappings created by PCP MAP requests), it MUST reset its Epoch time to 0. > (and static mappings even they are out of scope) matters. I don't see the value in that, because the PCP client can't recreate those anyway. > (6.2 page 18) > - "other fields assigned by the PCP server set to 0" is obviously > not enough. BTW at least the Epoch value is an exception... > > (6.3.1 page 18) > - please add a reference to the figure (which is unfortunately > on another page): the current text is unreadable. Ok. > (6.3.1 page 19) > - PLEASE DON'T USE "TBD" VALUES It's a simple #define to change the values. I'll make it 1. > (6.3.1 page 19) > - I suggest has length: 1 -> has length: >= 1 > in order to support more than 4 unprocessed options > (even I don't believe it'll happen :-) Doing so complicates the protocol, and adds another test case that is likely to be missed. If we need more than 4, I would rather just double this up to 8, and still allow this option to appear only once. It seems 4 is sufficient. But, we have the space so I will double its size. > (7.3 page 22) last sentence: hte -> the Thanks, fixed. > (8 page 23) > - (twice) public -> external > (BTW not only 'public address' is not defined but it is not > a synonym as it is more specific) Thanks. Fixed. > (8.1 page 24) > - request and response packet formats were aligned so either > they are going to be aligned again or this sentence removed > (of course I prefer the first solution) Sorry, that change wasn't intentional. Fixing that in the next version so the response aligns with the request. > - later: it doesn't make sense to keep the requested lifetime > in the OpCode when it was moved to the header, I strongly suggest > to go back to the previous layout with the lifetime in the > OpCode part. Editing mistake. I expect have a separate thread on overloading Lifetime/Retry_In, based on that other email I sent to the PCP mailing list. > - later: the Protocol field description was lost in editing... Fixed. > (8.1 page 25) e.g. -> e.g., > > (8.2 page 26) > - IMPLICIT_MAPPING_EXISTS (ex AMBIGUOUS) was forgotten Re-added similar text from an earlier version, If the response code is IMPLICIT_MAPPING EXISTS, it indicates the PCP client is attempting to use MAP when an implicit dynamic connection already exists for the same internal host and internal port. This can occur with certain types of NATs. When this is received, the PCP client has to choose a different internal port and send a new PCP request specifying that port. > (8.3 page 26) > - the "an all-zero internal IP address" should be a > an all-zero target IP address shouldn't it? Editing error in the definition section; everything is now using 'internal IP address'. Is 'target IP address' clearer than 'internal IP address'? Thinking about it now, it feels clearer to use 'target'. Thoughts? > (8.[34] pages 26-29) > - the current organization is a full mess, for instance > why the text of the previous point is in processing a > response when obviously it is about forming a request? Agreed. Right now it is: [Client] Generating and Sending a Request [Client] Processing a Response General PCP Server Operation I plan change the organization for general, MAP, and PEER have the following document layout: x.y. Processing Requests and Responses x.y.1. client generating a request x.y.2. server processing a request and generating a response x.y.3. client processing a response > (8.3 page 27) > - please remove external stuff from > "A response is matched with a request by comparing the protocol, > internal IP address, internal port, external address and external > port." Thanks for catching that. Fixed. > (8.3 page 27) > - please add the protocol (set to 0) into > "To do this, the PCP client sends a MAP request with external port, > internal port, and lifetime set to 0." Done. > (8.4 page 28) > - please detail: > "the PCP server MUST return a response indicating that > the assigned external port is the same as the internal port." Clarified to read: If the requested external port is 0, and the PCP-controlled device does not change port numbers (that is, it does not do port translation), and the PCP-controlled device permits all ports to be forwarded to the internal IP address, the PCP server generates successful response with assigned external port set to 0. > (8.4.2 page 29) > - If I understand well the new lifetime rules, when the > requested lifetime is > 0 but 'too small' it is round up > to the minimum (120 seconds), isn't it? Yes. That's been the case since draft-ietf-pcp-base-00. But I recall you mentioned there is a problem with that when interworking with other protocols. The intent of the PCP server's configured minimum is to avoid PCP protocol chatter with really short lifetimes. Clearly a one second lifetime is silly, as it will time out before a refresh can be performed, and the client is likely to lose incoming data. 120 seconds feels a reasonable suggestion for many networks. > (8.4.4 page 30) > - as I already complained about, subscriber renumbering raises > a security issue too. The text in 8.4.4 of -04 already says: "This same problem can occur if an IP address is re-assigned today, without PCP and without an ISP-operated CGN. The solution is the same as today: the problems associated with subscriber renumbering are eliminated if the ISP avoids re-assigning IP addresses to different subscribers." I do not see anything that PCP can do about an ISP renumbering a subscriber and the related mis-direction of traffic to the subscriber's old IP address. > (8.5.1 page 31) > - the restriction for DS-Lite is a (too) strong constraint. It says: For Dual-Stack Lite deployments, the PCP server only supports this option if the source IPv4 address is the B4's source IP address. the reason for that restriction is that if a DS-Lite user wants to set up a 3rd party mapping, the user has to first authenticate themselves to the B4 device (e.g., HTTP login using their administrative password), and then have the B4 issue the PCP request with the THIRD_PARTY option. Any other restriction to the use of THIRD_PARTY starts moving us towards requiring the CGN and the subscriber to share a password. If you, or anyone, has a better idea, I'm all ears to hear about it. > - later: it doesn't make sense to give decisions about the > local home security to the ISP. It isn't. The decision rests with the home user that can login to the B4 element on their premises. If you, or anyone, has a better idea, I'm all ears to hear about it. > In conclusion this new option doesn't bring more security. It is not intended to bring more security. It is intended to simplify the PCP client's operation, make the intent for a 3rd party mapping clearer (presence or absence of an option is clearer than comparing IP address in the PCP payload with source IP address). > At the opposite it clearly removes functionality. The THIRD_PARTY option does not remove functionality at all. I do concur that the limit on dual-stack lite, namely: For Dual-Stack Lite deployments, the PCP server only supports this option if the source IPv4 address is the B4's source IP address. does remove functionality. That is intended. And that is functionality that could have equally well been removed with the -03 packet layout (which had internal-ip-address in the MAP payload). > - later: I have no idea at all about the use of the protocol field. > > - this option is partially defined (there is a form for option > definition, please use it) I just noticed a mistake in -04. THIRD_PARTY needs a different definition than what is in -04. Specifically, the current text assumes the MAP4 OpCode or MAP6 OpCode dictates the address family of the internal IP address. However, that is only true with a firewall, NAT44, or NAT66. It wouldn't be true with NAT64 or NAT46. So, I just adjusted it to read: Internal IP address of the mapping. If the length of this Option is 1, this is a 32-bit IPv4 address. If the length of this Option is 4, this is a 128-bit IPv6 address. > (8.5.2 page 32) > - MAP44, ... -> MAP4, ... Thanks. Fixed. > (8.5.3 page 33) > - the MUST NOT is silly: I'd like to be free to use the option, > i.e., I'll publish code using it and not only for IWF. I guess you're referring to PCP clients other than IGD interworking clients MUST NOT use this option because it results in inefficient operation, and they cannot safely assume that all PCP servers will implement it. > (8.6 pages 34 & all) > - to be replaced by the specific document so I simply ignore it You're referring to: 8.6. PCP Mapping State Maintenance . . . . . . . . . . . . . . 34 8.6.1. Recreating Mappings . . . . . . . . . . . . . . . . . 34 8.6.2. Maintaining Mappings . . . . . . . . . . . . . . . . . 35 ? I don't believe there are plans to remove that to a separate document -- the only plans to remove anything to a separate document are UPnP interworking (which isn't covered in 8.6), and the nested NAT (which will eventually be published as draft-wing-pcp-nested-nat, using ideas I have presented at the PCP interim meetings, ftp://ftp-eng.cisco.com/dwing/pcp/pcp-nested-nat.pdf). > (9.1 page 36) > - issue again about "share a similar packet layout for > both requests and responses." This is related to the removal of lifetime. Let's figure out how to solve that in the other thread, and I'll make them align. This is an inadvertent editing mistake. > (9.1 page 37) > - note the internal address field was kept. > > - later: Requested lifetime too. > > (9.4 page 40) > - please define "its configured maximum lifetime value" > (I have no idea about what this means) adjusted to read: Otherwise, the PCP server chooses the smaller of the requested lifetime and its configured maximum lifetime value (which might be the same value as for PIN mappings (), or might be a different value), and sets the lifetime of the existing mapping. > (10.1.3 page 41) > - BTW Plain IPv6 Mode is trivially incompatible with the new MAPx's. For reference, it -04 says: 10.1.3. Plain IPv6 Mode Another alternative for deployment of PCP in a DS-Lite context is to rely on a PCP Proxy in the B4 element. Protocol exchanges between the PCP Proxy and the PCP server are conveyed using plain IPv6 (no tunnelling is used). Nevertheless, the IPv6 address used as source address by the PCP Proxy MUST be the same as the one used by the B4 element. I don't see the incompatibility. When the B4 element receives PCP requests from hosts, and wants to send them to the server, it adds the THIRD_PARTY option to the request. Seems compatible to my mind. > (11 pages 44 & all) > - to be replaced by the specific document so I simply ignore it Fair. > (12 pages 47-48) > - still nothing about explicit dynamic mapping theft... > Seriously you have less than 4 weeks to fix this or > the PCP WG session at Prague will be 'intesting'. > (http://en.wikipedia.org/wiki/May_you_live_in_interesting_times) -d > > Regards > > Francis.Dupont@fdupont.fr > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From dwing@cisco.com Wed Feb 9 18:34:11 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4B703A680C for ; Wed, 9 Feb 2011 18:34:11 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1FgKraqQDtm for ; Wed, 9 Feb 2011 18:34:09 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id CAA3F3A67FA for ; Wed, 9 Feb 2011 18:34:09 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikBAHXdUk2rR7Ht/2dsb2JhbACXDoFljHdzn1GbL4VcBIR/ X-IronPort-AV: E=Sophos;i="4.60,449,1291593600"; d="scan'208";a="327689919" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 10 Feb 2011 02:34:20 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1A2YKQi029351; Thu, 10 Feb 2011 02:34:20 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , References: <075501cbc87f$15b9c8d0$412d5a70$@com> In-Reply-To: Date: Wed, 9 Feb 2011 18:34:20 -0800 Message-ID: <099101cbc8cb$056e44a0$104acde0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvIeGeaozHd1RUWQ9q10lBXE0UO5AAApdcwAAUW0RoADtITsA== Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 02:34:12 -0000 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Wednesday, February 09, 2011 11:27 AM > To: Dan Wing; Francis.Dupont@fdupont.fr > Cc: pcp@ietf.org > Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP > address as dynamic mappings > > I think this requirement needs more discussion. Maybe 'LSN > requirements' was > too focused on NAT444 because that is the history of the document. > > A 'subscriber' can be an enterprise over IPoE, PPP, and many others. > You can > only map all hosts within a subscriber to the same public if you know > which > hosts belong to a subscriber to begin with. This is not always the > case. And there could, I suppose, be more hosts at a subscriber's site than can be mapped to a single IPv4 address. For example, 100 hosts and the ISP wants to give every host 1000 ports. Q: does anything break if two hosts, belonging to the same subscriber, are given different external IPv4 addresses? Today, without CGN, that happens all the time anyway. -d > > > On 2/9/11 9:30 AM, "Dan Wing" wrote: > > >> -----Original Message----- > >> From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > >> Sent: Wednesday, February 09, 2011 8:43 AM > >> To: pcp issue tracker > >> Cc: dwing@cisco.com; pcp@ietf.org > >> Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP > >> address as dynamic mappings > >> > >> I strongly disagree: the external address must be per subscriber, > >> not per host (or per host only when there is no subscriber, > >> BTW DS-Lite requires per subscriber (cf REQ-1 of > >> draft-ietf-behave-lsn-requirements-00.txt) and for the CGN > >> side of NAT444 hosts are not visible so I don't know there is > >> a case where one can see a difference). > >> > >> Regards > >> > >> Francis.Dupont@fdupont.fr > >> > >> PS: for IWF IGD the State Variables, including ExternaIPAddress, > >> are clearly global (i.e., per WANIPConnection service instance). > >> So per control point ExternaIPAddress is *not* allowed. > > > > The text in -05 (which isn't yet published) currently says: > > > > 8.4.1. Maintaining Same External IP Address > > > > If there are active mappings associated with a given subscriber > (see > > Section 10.5) -- created via dynamic assignment, by PCP or any > other > > means -- subsequent PCP mapping requests belonging to the same > > subscriber MUST use the same external IP address. This follows > the > > intent of REQ-1 of [I-D.ietf-behave-lsn-requirements]. > > > > Once an internal host has no implicit dynamic mappings and has no > > explicit dynamic mappings in the PCP-controlled device, a > subsequent > > PCP request for that internal host MAY be assigned to a different > > external IP address. Generally, this re-assignment would occur > when > > a CGN device is load balancing newly-seen hosts to its public IPv4 > > address pool. > > > > If I understand correctly, you want the second paragraph to replace > > "internal host" with "all hosts belonging to a given subscriber"? > > > > -d > > > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp From rpenno@juniper.net Wed Feb 9 18:36:01 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E1A3A6837 for ; Wed, 9 Feb 2011 18:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1AK7lUj3tLX for ; Wed, 9 Feb 2011 18:36:00 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 7542B3A680C for ; Wed, 9 Feb 2011 18:35:56 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTVNPFtaXSqmSwqzq840TnioL+0K9cXR9@postini.com; Wed, 09 Feb 2011 18:36:11 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 9 Feb 2011 18:34:37 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 9 Feb 2011 21:34:48 -0500 From: Reinaldo Penno To: Francis Dupont Date: Wed, 9 Feb 2011 21:34:42 -0500 Thread-Topic: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings Thread-Index: AcvIstVe2GL50U/mSWeBg0ykhsfgWQAGDzfn Message-ID: In-Reply-To: <201102092341.p19Nf4cK019080@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 02:36:01 -0000 On 2/9/11 3:41 PM, "Francis Dupont" wrote: > In your previous mail you wrote: >=20 > I think this requirement needs more discussion. Maybe 'LSN > requirements' was too focused on NAT444 because that is the history > of the document. > =20 > =3D> I agree it seems CGNs/LSNs are only DS-Lite AFTRs and the ISP > side of NAT444. Both are very similar so if someone invents a > third option many details won't match. The example I gave already exists today. Enterprises/Branches that go through a CGN that has more than one NAT public IP address for the enterprise. In this case, the CGN should not map all hosts in the enterpris= e to a single public IP otherwise it will not make use of all public IP addresses. In general in the case of a centralized CGN (as opposed to a CGN in a BNG o= r similar) I'm not sure how the mapping of 'subscriber' to the same one (or more) public IPs can be guaranteed by PCP. Are you suggesting some sort of 'subscriber ID' in PCP? >=20 > A 'subscriber' can be an enterprise over IPoE, PPP, and many > others. You can only map all hosts within a subscriber to the same > public if you know which hosts belong to a subscriber to begin > with. This is not always the case. > =20 > =3D> I am afraid the subscriber notion is essential for the security, > so the other case has a major security issue which is addressed in > a way I'd like to know before going further. Can you elaborate how the notion of subscriber is essential to security? =20 > =20 > Regards >=20 > Francis.Dupont@fdupont.fr From dwing@cisco.com Wed Feb 9 19:32:18 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5FAD3A680C for ; Wed, 9 Feb 2011 19:32:18 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jgl0ta-n9WIN for ; Wed, 9 Feb 2011 19:32:18 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id F28A93A67A3 for ; Wed, 9 Feb 2011 19:32:17 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoBAIbqUk2rR7Ht/2dsb2JhbACXDj+BJox3c6AMmyuFXASEfw X-IronPort-AV: E=Sophos;i="4.60,450,1291593600"; d="scan'208";a="260472051" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 10 Feb 2011 03:32:28 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1A3WSjl026914; Thu, 10 Feb 2011 03:32:28 GMT From: "Dan Wing" To: References: Your message of Wed, 09 Feb 2011 08:01:38 PST. <06df01cbc872$a2cc5c40$e86514c0$@com> <201102092304.p19N485G016592@givry.fdupont.fr> In-Reply-To: <201102092304.p19N485G016592@givry.fdupont.fr> Date: Wed, 9 Feb 2011 19:32:28 -0800 Message-ID: <0a1201cbc8d3$24accc30$6e066490$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvIra2+3HqB4b9tRP6ZTyHRSYOPIAAJVotA Content-Language: en-us Cc: pcp@ietf.org, 'pcp issue tracker' Subject: Re: [pcp] base #9 (assigned): Are PCP-created mappings different from TCP SYN-created ones X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 03:32:18 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Wednesday, February 09, 2011 3:04 PM > To: Dan Wing > Cc: 'pcp issue tracker'; pcp@ietf.org > Subject: Re: [pcp] base #9 (assigned): Are PCP-created mappings > different from TCP SYN-created ones > > > In your previous mail you wrote: > > > it is far easier for an attacker to (ab)use a PCP mapping (called > > explicit dynamic mapping in base-04) than a (implicit) dynamic > > mapping. > > An attacker, running a PCP client on the victim host, > > => no, an attacker in the Internet. > > so that the attacker can send packets from the Internet to the > victim host? > > Francis.Dupont@fdupont.fr > > PS: I don't understand why I have to discuss about it: Because I don't understand the attack vector. Maybe someone else understands the attack vector you're describing. -d > it is in the EIF specs (in the reason of not requiring > unconditionally EIF). From mohamed.boucadair@orange-ftgroup.com Wed Feb 9 22:34:48 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E619E3A68A9 for ; Wed, 9 Feb 2011 22:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcK0CFRmZbIU for ; Wed, 9 Feb 2011 22:34:47 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id B473F3A6879 for ; Wed, 9 Feb 2011 22:34:46 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id E61CD18C1DA; Thu, 10 Feb 2011 07:34:56 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A913B23804B; Thu, 10 Feb 2011 07:34:56 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 10 Feb 2011 07:34:56 +0100 From: To: Dan Wing , "Francis.Dupont@fdupont.fr" Date: Thu, 10 Feb 2011 07:34:54 +0100 Thread-Topic: Internal IP address & lifetime (was RE: [pcp] draft-ietf-pcp-base-04 posted) Thread-Index: AcvIf/4eMyNbfxAAT7Sef4EP7YFoMQAAbHuQABoufjA= Message-ID: <31083_1297319696_4D538710_31083_34119_1_94C682931C08B048B7A8645303FDC9F33C443B8A53@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Wed, 09 Feb 2011 07:51:30 PST. <06dd01cbc871$381522c0$a83f6840$@com> <201102091737.p19Hb86r096473@givry.fdupont.fr> <077801cbc8b3$586498c0$092dca40$@com> In-Reply-To: <077801cbc8b3$586498c0$092dca40$@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.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.9.180323 Cc: "pcp@ietf.org" Subject: [pcp] Internal IP address & lifetime (was RE: draft-ietf-pcp-base-04 posted) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 06:34:49 -0000 Hi Dan,=20 I like the two Opcodes instead of 4, this is what I asked for in http://www= .ietf.org/mail-archive/web/pcp/current/msg00256.html.=20 But I don't agree with removing the internal IP address from the message la= yout and moving the lifetime to the PCP header. Can you please roll-back to the version we have earlier since we are not su= re about the implications of such change on various aspects of the protocol= : IWF, detect a NAT in the path, etc? Thank you. Cheers, Med -----Message d'origine----- De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Dan W= ing Envoy=E9 : jeudi 10 f=E9vrier 2011 00:45 =C0 : Francis.Dupont@fdupont.fr Cc : pcp@ietf.org Objet : Re: [pcp] draft-ietf-pcp-base-04 posted > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Wednesday, February 09, 2011 9:37 AM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] draft-ietf-pcp-base-04 posted >=20 >=20 > In your previous mail you wrote: >=20 > > -----Original Message----- > > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > > Sent: Wednesday, February 09, 2011 4:39 AM > > To: Dan Wing > > Cc: pcp@ietf.org > > Subject: Re: [pcp] draft-ietf-pcp-base-04 posted > > > > Where/when major changes in this spec were discussed? >=20 > Please be more specific. >=20 > =3D> move the assigned lifetime to the fixed header, The semantic change to the protocol was changing from=20 permanent/temporary errors to returning a "retry in [seconds]"=20 field. The "temporary" and "permanent" errors were problematic, because a=20 "permanent" condition could actually solve itself sometime in=20 the future (e.g., PCP server was too busy), and a hint is needed to tell the client how long "temporary" might be (a few seconds or a few minutes). I originally added text for an option called RETRY_IN. However,=20 this option was only sent some times (not on every error), which made the protocol more fragile. So, for reasons similar to the decision to put Epoch in all packets, the RETRY value=20 is in all packets.=20=20 Once that was done, it seemed efficient to have one field=20 used for both the RETRY value (which is only used on=20 errors) and the same field for the LIFETIME value (which=20 is only used on success).=20=20 There are other ways this could be designed, of course --=20 such as, for example, always adding the RETRY_IN option to error responses. > remove the internal address, etc. This was done to simplify the PCP client implementation. PCP is mostly expected to be used by hosts wanting to open connections to themselves. So specifying the internal-ip-address is redundant, as it matches the source IP address of the PCP packet itself. This=20 change also allows reducing from 4 OpCodes (PIN44, PIN64, PIN46, PIN66) to two opcodes (MAP4, MAP6). This also simplifies PCP clients with multiple interfaces=20 (e.g., an IPv4 address from Ethernet and another IPv4=20 address from Wifi, or a dual-stack client). For the cases where a 3rd party mapping is needed, the new THIRD_PARTY option makes it very clear to both the PCP client and the PCP server that a 3rd party mapping is desired.=20=20 This change did not change the semantics of the protocol -- the protocol still does the same thing and allows the same functions. It just does it in a simpler manner. > > IMHO we have a problem of procedure here... >=20 > Major issues are in the tracker, and documented as text is > integrated to close them or new information is available. Those > emails are automatically sent to the PCP mailing list. For example, > http://www.ietf.org/mail-archive/web/pcp/current/msg00767.html >=20 > Reply-all to those messages if there is an objection. >=20 > =3D> so what are the tickets for the two examples I cited? Those two changes reduce the protocol's complexity, without changing its semantics. Glancing at the various tickets, most concern semantic changes. -d > Regards >=20 > Francis.Dupont@fdupont.fr >=20 > PS: Obviously the base document editing is not driven by > the tracker... (BTW do not take this on attack against you > but there is clearly something wrong in the way the base > document is (or not) improved). _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From Francis.Dupont@fdupont.fr Thu Feb 10 00:29:39 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1103E3A69F3 for ; Thu, 10 Feb 2011 00:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIKdYi8E-5E5 for ; Thu, 10 Feb 2011 00:29:37 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 299DE3A6915 for ; Thu, 10 Feb 2011 00:29:37 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1A8TmQt051392; Thu, 10 Feb 2011 09:29:48 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102100829.p1A8TmQt051392@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Wed, 09 Feb 2011 15:44:51 PST. <077801cbc8b3$586498c0$092dca40$@com> Date: Thu, 10 Feb 2011 09:29:48 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-04 posted X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 08:29:39 -0000 In your previous mail you wrote: > > Where/when major changes in this spec were discussed? > > Please be more specific. > > => move the assigned lifetime to the fixed header, The semantic change to the protocol was changing from permanent/temporary errors to returning a "retry in [seconds]" field. => I'll do three answers to your messages, the first one about the procedure, the second and third about the changes themselves. It seems the changes were not discussed at all and there was no ticket about them. From my point of view, this shows only we have a severe procedure problem (or no procedure at all). > => so what are the tickets for the two examples I cited? Those two changes reduce the protocol's complexity, without changing its semantics. => I disagree: adding a hold down timing on errors is clearly a semantics change. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Thu Feb 10 00:39:29 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B876D3A69F3 for ; Thu, 10 Feb 2011 00:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htrtP0hHPmPi for ; Thu, 10 Feb 2011 00:39:28 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 500363A69F2 for ; Thu, 10 Feb 2011 00:39:28 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1A8ddir051970; Thu, 10 Feb 2011 09:39:39 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102100839.p1A8ddir051970@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Wed, 09 Feb 2011 15:44:51 PST. <077801cbc8b3$586498c0$092dca40$@com> Date: Thu, 10 Feb 2011 09:39:39 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-04 posted X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 08:39:29 -0000 In your previous mail you wrote: > => move the assigned lifetime to the fixed header, The semantic change to the protocol was changing from permanent/temporary errors to returning a "retry in [seconds]" field. => I understand the idea but: - this timer doesn't make sense for many errors, in particular all mal-formed/unsupported stuff, so IMHO an option is better - the side effect to get different layout for requests and response OpCodes (or with other words to have no place for the requested lifetime) is greater than the advantage. The "temporary" and "permanent" errors were problematic, because a "permanent" condition could actually solve itself sometime in the future (e.g., PCP server was too busy), and a hint is needed to tell the client how long "temporary" might be (a few seconds or a few minutes). => my point is not about temporary vs. permanent even I am not sure it was in the mailing list itself. I originally added text for an option called RETRY_IN. However, this option was only sent some times (not on every error), which made the protocol more fragile. So, for reasons similar to the decision to put Epoch in all packets, the RETRY value is in all packets. => I can't see why to put an optional value in an option is a problem. Perhaps you concern is about parsing of the response but all errors with an impact on parsing are permanent. Once that was done, it seemed efficient to have one field used for both the RETRY value (which is only used on errors) and the same field for the LIFETIME value (which is only used on success). => used in requests and in success response. There are other ways this could be designed, of course -- such as, for example, always adding the RETRY_IN option to error responses. => I can't see the use of RETRY_IN for permanent errors. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Thu Feb 10 00:51:14 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 535933A69B7 for ; Thu, 10 Feb 2011 00:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjkXi9hU3VH2 for ; Thu, 10 Feb 2011 00:51:13 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 4BDFE3A6933 for ; Thu, 10 Feb 2011 00:51:13 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1A8pO1I052666; Thu, 10 Feb 2011 09:51:24 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102100851.p1A8pO1I052666@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Wed, 09 Feb 2011 15:44:51 PST. <077801cbc8b3$586498c0$092dca40$@com> Date: Thu, 10 Feb 2011 09:51:24 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-04 posted X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 08:51:14 -0000 In your previous mail you wrote: > remove the internal address This was done to simplify the PCP client implementation. PCP is mostly expected to be used by hosts wanting to open connections to themselves. So specifying the internal-ip-address is redundant, as it matches the source IP address of the PCP packet itself. => obviously you never wrote an IPv6 application (:-). This change also allows reducing from 4 OpCodes (PIN44, PIN64, PIN46, PIN66) to two opcodes (MAP4, MAP6). => this could be a good idea but it is clearly a change in the semantics as it is no longer possible to perform a PIN44/MAP4 operation from an IPv6 source, e.g., DS-Lite plain IPv6 mode. This also simplifies PCP clients with multiple interfaces (e.g., an IPv4 address from Ethernet and another IPv4 address from Wifi, or a dual-stack client). => I am not convinced as you exchange filling a field by calling a system call. For the cases where a 3rd party mapping is needed, the new THIRD_PARTY option makes it very clear to both the PCP client and the PCP server that a 3rd party mapping is desired. => at the limit this proves the NOT_AUTHORIZED result code can be raised in too many different cases (and coding a PCP server I really think it is an issue, a new ticket please) but IMHO the new THIRD_PARTY option is there mainly to catch all cases where the internal address and the source address are not the same. A proof is the spec says nothing about the source==target case. This change did not change the semantics of the protocol -- the protocol still does the same thing and allows the same functions. It just does it in a simpler manner. => I strongly disagree. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Thu Feb 10 00:58:41 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3F13A692D for ; Thu, 10 Feb 2011 00:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOJZN4hUi7wy for ; Thu, 10 Feb 2011 00:58:40 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 3639E3A693B for ; Thu, 10 Feb 2011 00:58:40 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1A8wpWe053091; Thu, 10 Feb 2011 09:58:51 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102100858.p1A8wpWe053091@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Wed, 09 Feb 2011 15:44:51 PST. <077901cbc8b3$58b48d80$0a1da880$@com> Date: Thu, 10 Feb 2011 09:58:51 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] PCP packet layout [was RE: Review of pcp-base-3] X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 08:58:41 -0000 In your previous mail you wrote: > How about the following, which provides 8-bit alignment of OpCode > and Result Code, and keeps all the reserved space together: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|Ver=0| Reserved | Result Code |R| OpCode | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > => I don't understand the gratuitous shuffle of fields... Reinaldo suggested having two sections of 'reserved' bits could be reduced to have one section of 'reserved' bits. => this doesn't explain the swap between Result Code and OpCode. Regards Francis.Dupont@fdupont.fr PS: to lower the level of changes and to get one reserved field, I propose: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Version = 0 |R| OpCode | Reserved | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From Francis.Dupont@fdupont.fr Thu Feb 10 01:47:14 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921F73A6933 for ; Thu, 10 Feb 2011 01:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itvOqvQVzYAs for ; Thu, 10 Feb 2011 01:47:13 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 9B0333A6929 for ; Thu, 10 Feb 2011 01:47:12 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1A9lNUP056129; Thu, 10 Feb 2011 10:47:23 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102100947.p1A9lNUP056129@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Wed, 09 Feb 2011 18:14:28 PST. <098a01cbc8c8$3f47b6f0$bdd724d0$@com> Date: Thu, 10 Feb 2011 10:47:23 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] brief review of base-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 09:47:14 -0000 In your previous mail you wrote: > Note as I believe the THIRD_PARTY option brings nothing > I'd like to go back to the base-03 stuff about internal > addresses. Using a separate option brings several advantages that I described in another email (which is in flight to the PCP mailer as I type this response). => I don't see these advantages nor a discussion of this major change in the list. > already exists as a static mapping will return a successful > result, confirming that the requested mapping exists." > > With which assigned lifetime? With the lifetime the PCP server wants to use. Typically, the PCP server would extend the lifetime based on the requested-lifetime. Does this need to be spelled out in this example?? => I can't parse your answer: we are talking about *static* mappings so they have by definition infinite lifetimes. > Does this work too for deletion? Yes, section 8.4 says: " If the PCP client attempts to delete a mapping that does not exist, the success response code is returned." => in this text the 'a mapping' is 'an explicit dynamic mapping' so what happens when a request is received for the deletion of a static mapping? Note I consider that PCP allowed to delete static mappings as a security concern. > IMHO the easiest is to step back to failure (not authorized) I don't follow. => I propose to return the NOT_AUTHORIZED (or a better new result code) result code for operations on static mappings. > (5.2 page 10) > - IMHO it is a bad idea to include the lifetime in fixed header > and only for the assigned lifetime. > I understand the reason but there are other ways to introduce > a hold down on errors, a new option for instance. There are two issues here: (1) adding a RETRY field, and (2) overloading that field to indicate lifetime (on success responses) and retry (on error responses). Yes, a separate option might be better. I had text in an interim version of the document that did exactly that. It didn't seem the best way to handle retries -- especially for things like malformed requests, where the response's RETRY_IN option would (?) need to be at the end of the copied request. => I've understood this was the reason for your choice but a malformed request by definition raises a permanent error so there is no need for a RETRY_IN option. Would removing the overloading be acceptable? That is, just have the field in the common header indicate the RETRY value, and leave LIFETIME in the OpCodes themselves? => not only removing the overloading is acceptable but it is the only acceptable option. > (5.2 page 11) > - I like the halfway renewal: it makes more sense than previous > specs. > But I don't have the same opinion about SERVER_OVERLOADED as > it introduces a major security issue, in particular without > a reasonable maximum hold time. I'm sorry, what is the major security issue? That an on-path device might spoof the PCP Server and send back SERVER_OVERLOADED?? Or something else? => spoofed SERVER_OVERLOADED with silly retry values. > (6.1.4 page 17) > - there is an ambiguity about the Epoch: the text says "Mappings" > but if a NAT loses its implicit dynamic mappings but not its > explicit dynamic mappings should it reset its Epoch? > BTW it is not possible to directly recover from the lost of > implicit dynamic mappings so my opinion is the answer should > be no, i.e., only the persistence of explicit dynamic mappings Agreed. Clarified with: If the PCP server resets or loses the state of its explicit dynamic Mappings (that is, those mappings created by PCP MAP requests), it MUST reset its Epoch time to 0. => thanks! > (6.3.1 page 19) > - I suggest has length: 1 -> has length: >= 1 > in order to support more than 4 unprocessed options > (even I don't believe it'll happen :-) Doing so complicates the protocol, and adds another test case that is likely to be missed. If we need more than 4, I would rather just double this up to 8, and still allow this option to appear only once. It seems 4 is sufficient. But, we have the space so I will double its size. => oops, what I tried to suggest is to change the length from 'one only' to 'equal or greater than one'. I do not see anything that PCP can do about an ISP renumbering a subscriber and the related mis-direction of traffic to the subscriber's old IP address. => we could say it is a major security problem. > (8.5.1 page 31) > - the restriction for DS-Lite is a (too) strong constraint. => yes, you can't at the same time push the encapsulation mode for direct host - PCP server communication and add this kind of constraints. It says: For Dual-Stack Lite deployments, the PCP server only supports this option if the source IPv4 address is the B4's source IP address. the reason for that restriction is that if a DS-Lite user wants to set up a 3rd party mapping, the user has to first authenticate themselves to the B4 device (e.g., HTTP login using their administrative password), and then have the B4 issue the PCP request with the THIRD_PARTY option. => so you adopted one of my arguments in favor of the plain mode: the B4 should have a greater role in PCP message relaying so the encapsulation mode simplicity is just an illusion. Any other restriction to the use of THIRD_PARTY starts moving us towards requiring the CGN and the subscriber to share a password. => password? is it a joke? If you, or anyone, has a better idea, I'm all ears to hear about it. => I already explained my ideas about the home security and even there are some still open points obviously the THIRD_PARTY option can't help at all. > - later: it doesn't make sense to give decisions about the > local home security to the ISP. It isn't. The decision rests with the home user that can login to the B4 element on their premises. => quoting the 8.5.1 text: "the ISP MUST determine its own policy for how to identify the trusted device within the subscriber's home." > At the opposite it clearly removes functionality. The THIRD_PARTY option does not remove functionality at all. => I already answered: the source address and the internal address must share the same address family and this is new. (note this comment is from the 04 in the repository, i.e., the not fixed version as it was the only available version). > - this option is partially defined (there is a form for option > definition, please use it) I just noticed a mistake in -04. THIRD_PARTY needs a different definition than what is in -04. Specifically, the current text assumes the MAP4 OpCode or MAP6 OpCode dictates the address family of the internal IP address. However, that is only true with a firewall, NAT44, or NAT66. It wouldn't be true with NAT64 or NAT46. So, I just adjusted it to read: Internal IP address of the mapping. If the length of this Option is 1, this is a 32-bit IPv4 address. If the length of this Option is 4, this is a 128-bit IPv6 address. => this changes many things... > (8.5.3 page 33) > - the MUST NOT is silly: I'd like to be free to use the option, > i.e., I'll publish code using it and not only for IWF. I guess you're referring to => good guess PCP clients other than IGD interworking clients MUST NOT use this option because it results in inefficient operation, and they cannot safely assume that all PCP servers will implement it. > (8.6 pages 34 & all) > - to be replaced by the specific document so I simply ignore it You're referring to: 8.6. PCP Mapping State Maintenance . . . . . . . . . . . . . . 34 8.6.1. Recreating Mappings . . . . . . . . . . . . . . . . . 34 8.6.2. Maintaining Mappings . . . . . . . . . . . . . . . . . 35 => yes I don't believe there are plans to remove that to a separate document -- => replace != remove > (9.4 page 40) > - please define "its configured maximum lifetime value" > (I have no idea about what this means) adjusted to read: Otherwise, the PCP server chooses the smaller of the requested lifetime and its configured maximum lifetime value (which might be the same value as for PIN mappings ^^^ MAP (), or might be a different value), and sets the lifetime of the existing mapping. => I still don't know what is "its configured maximum lifetime value". I don't see the incompatibility. When the B4 element receives PCP requests from hosts, and wants to send them to the server, it adds the THIRD_PARTY option to the request. Seems compatible to my mind. => not with the THIRD_PARTY option in the published unfixed -04. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Thu Feb 10 04:15:36 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D27C3A6A18 for ; Thu, 10 Feb 2011 04:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2NN-UC8Vmkf for ; Thu, 10 Feb 2011 04:15:35 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 5F43E3A698E for ; Thu, 10 Feb 2011 04:15:35 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1ACFkQp065426 for ; Thu, 10 Feb 2011 13:15:46 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102101215.p1ACFkQp065426@givry.fdupont.fr> From: Francis Dupont To: pcp@ietf.org Date: Thu, 10 Feb 2011 13:15:46 +0100 Sender: Francis.Dupont@fdupont.fr Subject: [pcp] proposal about internal addresses X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 12:15:36 -0000 Here is a counter-proposal about internal addresses, based on the fact the THIRD_PARTY option disadvantages (for instance it makes a PCP relay far more complex) are greater than advantages. I propose to go back to 03 layout, i.e., the internal address is included in MAP and PEER OpCodes. The supposed simplicity in PCP clients is IMHO an API issue, I suggest to not improve it inside the protocol but to ask for an API routine which fills the field from the socket local address. Of course the section 7 is the right place to illustrate this. If to reduce the number of OpCodes is considered as a good thing I propose to reuse the External_AF PEER idea. BTW it should be in this case a good idea to make MAP and PEER OpCodes more similar, i.e., to maximize code sharing in programs. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Thu Feb 10 05:24:07 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A2523A6985 for ; Thu, 10 Feb 2011 05:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bD2Pe7q-UkG1 for ; Thu, 10 Feb 2011 05:24:06 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id CD01C3A6984 for ; Thu, 10 Feb 2011 05:24:05 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1ADOHcJ069560 for ; Thu, 10 Feb 2011 14:24:17 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102101324.p1ADOHcJ069560@givry.fdupont.fr> From: Francis Dupont To: pcp@ietf.org Date: Thu, 10 Feb 2011 14:24:17 +0100 Sender: Francis.Dupont@fdupont.fr Subject: [pcp] about errors X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 13:24:07 -0000 Currently errors are: - UNSUPP_{VERSION,OPCODE,OPTION,PROTOCOL} - MALFORMED_{OPTION,REQUEST} - UNSPECIFIED_ERROR - SERVER_OVERLOADED - NETWORK_FAILURE - NO_RESOURCES - NOT_AUTHORIZED - USER_EX_QUOTA - CANNOT_PROVIDE_EXTERNAL_PORT (ex CANNOT_HONOR_EXTERNAL_PORT BTW 8.5.3 still uses the old name in 04) - UNABLE_TO_DELETE_ALL - NONEXIST_PEER - IMPLICIT_MAPPING_EXISTS The UNSUPP_VERSION is special as only the first word of the message makes sense. UNSUPP_*, MALFORMED_* and some cases of NOT_AUTHORIZED are permanent: if the request is resent the same failure response will be returned. Some are clearly transient, i.e., they are bound to a condition which can be cleared: - some cases of NOT_AUTHORIZED - SERVER_OVERLOADED, NETWORK_FAILURE, NO_RESOURCES, USER_EX_QUOTA, CANNOT_PROVIDE_EXTERNAL_PORT, NONEXIST_PEER, IMPLICIT_MAPPING_EXISTS and IMHO most cases of UNABLE_TO_DELETE_ALL. I have nothing against the "please retry after this delay" idea but in most cases the PCP server has no idea of when the condition will be cleared, so I am afraid it can't give a really useful indication to the PCP client other than it is a transient error so you can retry later. But this information is bound to the result code, so I think it is better to add a comment in the spec with a suggested delay, and to split ambiguous result code, beginning by NOT_AUTHORIZED which is already too overloaded. UNABLE_TO_DELETE_ALL is a good candidate too. About the SERVER_OVERLOADED, I asked again the specified behavior to be simply to drop messages which can't be processed. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Thu Feb 10 05:32:39 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FD4C3A69A4 for ; Thu, 10 Feb 2011 05:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ij7CX6nky8Yl for ; Thu, 10 Feb 2011 05:32:38 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 475083A69B2 for ; Thu, 10 Feb 2011 05:32:38 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1ADWnlN070065; Thu, 10 Feb 2011 14:32:49 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102101332.p1ADWnlN070065@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Wed, 09 Feb 2011 18:34:20 PST. <099101cbc8cb$056e44a0$104acde0$@com> Date: Thu, 10 Feb 2011 14:32:49 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 13:32:39 -0000 In your previous mail you wrote: And there could, I suppose, be more hosts at a subscriber's site than can be mapped to a single IPv4 address. For example, 100 hosts and the ISP wants to give every host 1000 ports. => usually the ISP ignores the number of hosts, i.e., the only use of the host notion at the ISP level is a different internal address (of course this supposes first there is not a NAT hidding hosts). Q: does anything break if two hosts, belonging to the same subscriber, are given different external IPv4 addresses? Today, without CGN, that happens all the time anyway. => I can't parse your statement: the term external address makes sense only where there is a NAT, and with a NAT only one address is visible. And to answer to the question, yes it breaks applications. Now if you'd like to discuss this, IMHO the behave WG is the right place. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Thu Feb 10 05:36:07 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DAFD3A69AE for ; Thu, 10 Feb 2011 05:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8iuaey6xwnr for ; Thu, 10 Feb 2011 05:36:06 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 86D333A69A4 for ; Thu, 10 Feb 2011 05:36:04 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1ADaG0Y070330; Thu, 10 Feb 2011 14:36:16 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102101336.p1ADaG0Y070330@givry.fdupont.fr> From: Francis Dupont To: Reinaldo Penno In-reply-to: Your message of Wed, 09 Feb 2011 21:34:42 EST. Date: Thu, 10 Feb 2011 14:36:16 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "pcp@ietf.org" Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 13:36:07 -0000 In your previous mail you wrote: The example I gave already exists today. Enterprises/Branches that go through a CGN that has more than one NAT public IP address for the enterprise. In this case, the CGN should not map all hosts in the enterprise to a single public IP otherwise it will not make use of all public IP addresses. => as you suggest there is no notion of subscriber in an enterprise NAT, so the one external address per subscriber simply doesn't apply. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Thu Feb 10 05:41:17 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11EBB3A69CB for ; Thu, 10 Feb 2011 05:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oWvbP-KGcME for ; Thu, 10 Feb 2011 05:41:16 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 09EBA3A69AE for ; Thu, 10 Feb 2011 05:41:15 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1ADfRDH070633; Thu, 10 Feb 2011 14:41:27 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102101341.p1ADfRDH070633@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Wed, 09 Feb 2011 19:32:28 PST. <0a1201cbc8d3$24accc30$6e066490$@com> Date: Thu, 10 Feb 2011 14:41:27 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org, 'pcp issue tracker' Subject: Re: [pcp] base #9 (assigned): Are PCP-created mappings different from TCP SYN-created ones X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 13:41:17 -0000 In your previous mail you wrote: > PS: I don't understand why I have to discuss about it: Because I don't understand the attack vector. Maybe someone else understands the attack vector you're describing. => from RFC 4787: Filtering independently of the external endpoint is not as secure: An unauthorized packet could get through a specific port while the port was kept open if it was lucky enough to find the port open. In theory, filtering based on both IP address and port is more secure than filtering based only on the IP address (because the external endpoint could, in reality, be two endpoints behind another NAT, where one of the two endpoints is an attacker). This explicitely states EIF is less secure than APDF. Regards Francis.Dupont@fdupont.fr From rpenno@juniper.net Thu Feb 10 07:38:39 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBA293A6886 for ; Thu, 10 Feb 2011 07:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmAZB34ypJr9 for ; Thu, 10 Feb 2011 07:38:39 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 3EA3F3A67EC for ; Thu, 10 Feb 2011 07:38:36 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTVQGiAyen3WD91PLrLb3pxs11kD7scWM@postini.com; Thu, 10 Feb 2011 07:38:51 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 10 Feb 2011 07:38:00 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 10 Feb 2011 10:38:12 -0500 From: Reinaldo Penno To: Francis Dupont Date: Thu, 10 Feb 2011 10:38:10 -0500 Thread-Topic: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings Thread-Index: AcvJJ455xBx8lyLxRH2yCf/BE0zm0QAEPa2A Message-ID: In-Reply-To: <201102101336.p1ADaG0Y070330@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 15:38:40 -0000 There is a very specific definition of a subscriber; this subscriber gets specific H-QoS, filtering, pay differentiated fee, have AAA enabled, etc. But I'm afraid it does not fit the model you are advocating. Can you elaborate on what you said about the notion of subscriber is essential for security? On 2/10/11 5:36 AM, "Francis Dupont" wrote: > In your previous mail you wrote: >=20 > The example I gave already exists today. Enterprises/Branches that go > through a CGN that has more than one NAT public IP address for the > enterprise. In this case, the CGN should not map all hosts in the > enterprise > to a single public IP otherwise it will not make use of all public IP > addresses. > =20 > =3D> as you suggest there is no notion of subscriber in an enterprise NAT= , > so the one external address per subscriber simply doesn't apply. > =20 > Regards >=20 > Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Thu Feb 10 08:14:16 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9181D3A6A35 for ; Thu, 10 Feb 2011 08:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85S-FJSStRsV for ; Thu, 10 Feb 2011 08:14:15 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 0DA833A6A22 for ; Thu, 10 Feb 2011 08:14:14 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1AGERrN080054 for ; Thu, 10 Feb 2011 17:14:27 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102101614.p1AGERrN080054@givry.fdupont.fr> From: Francis Dupont To: pcp@ietf.org Date: Thu, 10 Feb 2011 17:14:27 +0100 Sender: Francis.Dupont@fdupont.fr Subject: [pcp] state maintenance summary X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 16:14:16 -0000 The state maintenance document could be split into 3 items: - a general model which explains failure cases and how to recover from them. - a request for a mechanism to store disambiguating information at aggregation points, e.g., between applications or in an IWF. - a proposal for a GET/GETNEXT exchange. I'd like to get tickets about the 3 items in order to discuss about them. Regards Francis.Dupont@fdupont.fr From dwing@cisco.com Thu Feb 10 08:29:45 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B9E43A67A2 for ; Thu, 10 Feb 2011 08:29:45 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOVcQS9JeQQp for ; Thu, 10 Feb 2011 08:29:44 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 497BD3A659A for ; Thu, 10 Feb 2011 08:29:44 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcBAO2gU01AZnwN/2dsb2JhbACXDT+BJox3c554m0KFXASFAQ X-IronPort-AV: E=Sophos;i="4.60,451,1291593600"; d="scan'208";a="213890667" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 10 Feb 2011 16:29:56 +0000 Received: from dwingWS ([10.32.240.198]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1AGTtCe014237; Thu, 10 Feb 2011 16:29:56 GMT From: "Dan Wing" To: References: Your message of Wed, 09 Feb 2011 15:44:51 PST. <077801cbc8b3$586498c0$092dca40$@com> <201102100851.p1A8pO1I052666@givry.fdupont.fr> In-Reply-To: <201102100851.p1A8pO1I052666@givry.fdupont.fr> Date: Thu, 10 Feb 2011 08:29:55 -0800 Message-ID: <0b7c01cbc93f$c0bfd0b0$423f7210$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvI/7Y/C7aqak88Q1uOey90znDNfgAP3ETA Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-04 posted X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 16:29:45 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Thursday, February 10, 2011 12:51 AM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] draft-ietf-pcp-base-04 posted > > > In your previous mail you wrote: > > > remove the internal address > > This was done to simplify the PCP client implementation. > PCP is mostly expected to be used by hosts wanting to > open connections to themselves. So specifying the > internal-ip-address is redundant, as it matches the > source IP address of the PCP packet itself. > > => obviously you never wrote an IPv6 application (:-). > > This change also allows reducing from 4 OpCodes (PIN44, > PIN64, PIN46, PIN66) to two opcodes (MAP4, MAP6). > > => this could be a good idea but it is clearly a change > in the semantics as it is no longer possible to perform > a PIN44/MAP4 operation from an IPv6 source, e.g., > DS-Lite plain IPv6 mode. Yes, it is still possible for an IPv6 node to get an IPv4 mapping. It sends a MAP4 request from its IPv6 interface to the PCP server's IPv6 address. > This also simplifies PCP clients with multiple interfaces > (e.g., an IPv4 address from Ethernet and another IPv4 > address from Wifi, or a dual-stack client). > > => I am not convinced as you exchange filling a field by > calling a system call. > > For the cases where a 3rd party mapping is needed, the new > THIRD_PARTY option makes it very clear to both the > PCP client and the PCP server that a 3rd party mapping > is desired. > > => at the limit this proves the NOT_AUTHORIZED result code > can be raised in too many different cases (and coding a > PCP server I really think it is an issue, a new ticket > please) What do you want the ticket to say? > but IMHO the new THIRD_PARTY option is there > mainly to catch all cases where the internal address and > the source address are not the same. Yes, that is exactly the purpose of the THIRD_PARTY option. > A proof is the > spec says nothing about the source==target case. -d > This change did not change the semantics of the > protocol -- the protocol still does the same thing > and allows the same functions. It just does it in > a simpler manner. > > => I strongly disagree. > > Regards > > Francis.Dupont@fdupont.fr From dwing@cisco.com Thu Feb 10 08:57:21 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F11163A6A44 for ; Thu, 10 Feb 2011 08:57:20 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAVloJS1PoXn for ; Thu, 10 Feb 2011 08:57:19 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 646DB3A6987 for ; Thu, 10 Feb 2011 08:57:19 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQBAC+oU02rR7H+/2dsb2JhbACXDYFljHdznn2bQIJ9GwEEgj8EhQE X-IronPort-AV: E=Sophos;i="4.60,451,1291593600"; d="scan'208";a="327986538" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 10 Feb 2011 16:57:30 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1AGvV38024564; Thu, 10 Feb 2011 16:57:31 GMT From: "Dan Wing" To: References: Your message of Wed, 09 Feb 2011 18:14:28 PST. <098a01cbc8c8$3f47b6f0$bdd724d0$@com> <201102100947.p1A9lNUP056129@givry.fdupont.fr> In-Reply-To: <201102100947.p1A9lNUP056129@givry.fdupont.fr> Date: Thu, 10 Feb 2011 08:57:31 -0800 Message-ID: <0b9f01cbc943$9b38bdd0$d1aa3970$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvJB4mPjZGYkUhURNCyOJTM8pdzPQAOO4Cg Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] brief review of base-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 16:57:21 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Thursday, February 10, 2011 1:47 AM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] brief review of base-04 > > > In your previous mail you wrote: > > > Note as I believe the THIRD_PARTY option brings nothing > > I'd like to go back to the base-03 stuff about internal > > addresses. > > Using a separate option brings several advantages that I > described in another email (which is in flight to the PCP > mailer as I type this response). > > => I don't see these advantages nor a discussion of this > major change in the list. Then, let's start with the agreement that this is the discussion. Nothing is cast in stone; this is an I-D. I am trying my best to simplify the protocol based on 100s of emails and and discussions. And I do make mistakes. > > already exists as a static mapping will return a successful > > result, confirming that the requested mapping exists." > > > > With which assigned lifetime? > > With the lifetime the PCP server wants to use. Typically, > the PCP server would extend the lifetime based on the > requested-lifetime. Does this need to be spelled out in > this example?? > > => I can't parse your answer: we are talking about *static* > mappings so they have by definition infinite lifetimes. I do not understand the purpose of discussing static mappings (created with a CLI) and how/why they affect PCP or how/why they affect implicit dynamic mappings (e.g., TCP SYN). Is there an application or a protocol that breaks if they get assigned different public IP addresses? I can see where PCP and implicit dynamic mappings need to be on the same public IP address. But I don't see a similar need for static mappings (created with a CLI) to be on the same public address. And I don't believe the PCP specification can create such a rule, either; obviously the PCP specification can't create a rule that implicit dynamic mappings and static mappings have to be on the same public IP address, because PCP is only defining PCP and can only define rules for itself. > > Does this work too for deletion? > > Yes, section 8.4 says: > > " If the PCP client attempts to delete a mapping that > does not exist, the success response code is returned." > > => in this text the 'a mapping' is 'an explicit dynamic > mapping' so what happens when a request is received > for the deletion of a static mapping? Static mappings can't be deleted by PCP. That is the purpose of the UNABLE_TO_DELETE_ALL result code: "If the PCP client attempts to delete a port mapping which was manually assigned by some kind of configuration tool, the PCP server MUST respond with UNABLE_TO_DELETE_ALL result code, but the other fields are encoded as described above." > Note I consider that PCP allowed to delete static mappings as > a security concern. > > > IMHO the easiest is to step back to failure (not authorized) > > I don't follow. > > => I propose to return the NOT_AUTHORIZED (or a better new > result code) result code for operations on static mappings. > > > (5.2 page 10) > > - IMHO it is a bad idea to include the lifetime in fixed header > > and only for the assigned lifetime. > > I understand the reason but there are other ways to introduce > > a hold down on errors, a new option for instance. > > There are two issues here: (1) adding a RETRY field, and (2) > overloading that field to indicate lifetime (on success > responses) and retry (on error responses). > > Yes, a separate option might be better. I had text in an interim > version of the document that did exactly that. It didn't seem the > best way to handle retries -- especially for things like > malformed requests, where the response's RETRY_IN option > would (?) need to be at the end of the copied request. > > => I've understood this was the reason for your choice Good. I wasn't sure if the reason for the change was understood. Thanks. That's something. > but > a malformed request by definition raises a permanent error > so there is no need for a RETRY_IN option. > > Would removing the overloading be acceptable? That is, > just have the field in the common header indicate the > RETRY value, and leave LIFETIME in the OpCodes themselves? > > => not only removing the overloading is acceptable but > it is the only acceptable option. > > > (5.2 page 11) > > - I like the halfway renewal: it makes more sense than previous > > specs. > > But I don't have the same opinion about SERVER_OVERLOADED as > > it introduces a major security issue, in particular without > > a reasonable maximum hold time. > > I'm sorry, what is the major security issue? That an on-path device > might spoof the PCP Server and send back SERVER_OVERLOADED?? Or > something else? > > => spoofed SERVER_OVERLOADED with silly retry values. That concern is not unique to SERVER_OVERLOADED, is it? > > (6.1.4 page 17) > > - there is an ambiguity about the Epoch: the text says > "Mappings" > > but if a NAT loses its implicit dynamic mappings but not its > > explicit dynamic mappings should it reset its Epoch? > > BTW it is not possible to directly recover from the lost of > > implicit dynamic mappings so my opinion is the answer should > > be no, i.e., only the persistence of explicit dynamic mappings > > Agreed. Clarified with: > > If the PCP server resets or loses the state of its > explicit dynamic Mappings (that is, those mappings created > by PCP MAP requests), it MUST reset its Epoch time to 0. > > => thanks! > > > (6.3.1 page 19) > > - I suggest has length: 1 -> has length: >= 1 > > in order to support more than 4 unprocessed options > > (even I don't believe it'll happen :-) > > Doing so complicates the protocol, and adds another test case that > is likely to be missed. If we need more than 4, I would rather > just double this up to 8, and still allow this option to appear > only once. It seems 4 is sufficient. But, we have the space > so I will double its size. > > => oops, what I tried to suggest is to change the length from > 'one only' to 'equal or greater than one'. I understand that was your suggestion. But this gets risky, because (a) this is an error condition, and we all know that error paths in code are never as well-tested as success paths, (b) this error condition would be the only PCP option defined in the base protocol that can occur multiple times, (c) the only way to cause this error is to send a PCP request with a bunch of not-yet-defined mandatory-to-process options. These code paths would not be very robust in the client or the server. > I do not see anything that PCP can do about an ISP renumbering a > subscriber and the related mis-direction of traffic to the > subscriber's > old IP address. > > => we could say it is a major security problem. But ISP renumbering is not unique to PCP (PCP doesn't cause the renumbering), and ISP renumbering is not made worse because of the existence of PCP (nor is ISP renumbering made worse because of the existence of a CGN or a firewall). > > (8.5.1 page 31) > > - the restriction for DS-Lite is a (too) strong constraint. > > => yes, you can't at the same time push the encapsulation mode > for direct host - PCP server communication and add this kind of > constraints. > > It says: > > For Dual-Stack Lite deployments, the PCP server only supports > this > option if the source IPv4 address is the B4's source IP address. > > the reason for that restriction is that if a DS-Lite user wants to > set up a 3rd party mapping, the user has to first authenticate > themselves to the B4 device (e.g., HTTP login using their > administrative password), and then have the B4 issue the PCP > request with the THIRD_PARTY option. > > => so you adopted one of my arguments in favor of the plain mode: > the B4 should have a greater role in PCP message relaying so the > encapsulation mode simplicity is just an illusion. I welcome assistance with adjusting the text discussing Encapsulation/Plain mode. > Any other restriction to the use of THIRD_PARTY starts moving us > towards requiring the CGN and the subscriber to share a password. > > => password? is it a joke? > > If you, or anyone, has a better idea, I'm all ears to hear about it. > > => I already explained my ideas about the home security and even > there are some still open points obviously the THIRD_PARTY option > can't help at all. > > > - later: it doesn't make sense to give decisions about the > > local home security to the ISP. > > It isn't. The decision rests with the home user that can > login to the B4 element on their premises. > > => quoting the 8.5.1 text: > > "the ISP MUST determine its own policy for how to identify > the trusted device within the subscriber's home." > > > At the opposite it clearly removes functionality. > > The THIRD_PARTY option does not remove functionality at all. > > => I already answered: the source address and the internal > address must share the same address family and this is new. > (note this comment is from the 04 in the repository, i.e., > the not fixed version as it was the only available version). > > > - this option is partially defined (there is a form for option > > definition, please use it) > > I just noticed a mistake in -04. THIRD_PARTY needs a different > definition than what is in -04. Specifically, the current text > assumes the MAP4 OpCode or MAP6 OpCode dictates the address > family of the internal IP address. However, that is only > true with a firewall, NAT44, or NAT66. It wouldn't be true > with NAT64 or NAT46. So, I just adjusted it to read: > > Internal IP > address of the mapping. If the length of this Option > is > 1, this is a 32-bit IPv4 address. If the length of > this > Option is 4, this is a 128-bit IPv6 address. > > => this changes many things... > > > (8.5.3 page 33) > > - the MUST NOT is silly: I'd like to be free to use the option, > > i.e., I'll publish code using it and not only for IWF. > > I guess you're referring to > > => good guess > > PCP clients > other than IGD interworking clients MUST NOT use this option > because > it results in inefficient operation, and they cannot safely > assume > that all PCP servers will implement it. And you'd like it to be a SHOULD NOT? It _does_ result in inefficient operation, and I can certainly see how a CGN would want to deprecate (not support) that option in the future, because a requested-for port simply cannot be forced (it will already be used by another subscriber). > > (8.6 pages 34 & all) > > - to be replaced by the specific document so I simply ignore it > > You're referring to: > > 8.6. PCP Mapping State Maintenance . . . . . . . . . . . . . . > 34 > 8.6.1. Recreating Mappings . . . . . . . . . . . . . . . . . > 34 > 8.6.2. Maintaining Mappings . . . . . . . . . . . . . . . . . > 35 > > => yes > > I don't believe there are plans to remove that to a separate > document -- > > => replace != remove > > > (9.4 page 40) > > - please define "its configured maximum lifetime value" > > (I have no idea about what this means) > > adjusted to read: > > Otherwise, the PCP server chooses the smaller of the > requested lifetime and its configured maximum lifetime value > (which > might be the same value as for PIN mappings > ^^^ MAP Tx, fixed that. > (), or might be a different value), > and > sets the lifetime of the existing mapping. > > => I still don't know what is "its configured maximum lifetime value". A CLI setting, a #define'd value, or so on. > I don't see the incompatibility. When the B4 element receives > PCP requests from hosts, and wants to send them to the server, it > adds the THIRD_PARTY option to the request. Seems compatible to my > mind. > > => not with the THIRD_PARTY option in the published unfixed -04. Yes, I made a mistake in -04. -d > Regards > > Francis.Dupont@fdupont.fr From dwing@cisco.com Thu Feb 10 08:58:25 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B6203A6987 for ; Thu, 10 Feb 2011 08:58:25 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmeBTTScfUm2 for ; Thu, 10 Feb 2011 08:58:24 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 99FC83A67B2 for ; Thu, 10 Feb 2011 08:58:24 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcBAC+oU02rR7H+/2dsb2JhbACXDT+BJox3c559m0CFXASFAQ X-IronPort-AV: E=Sophos;i="4.60,451,1291593600"; d="scan'208";a="327987037" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 10 Feb 2011 16:58:35 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1AGwaui025544; Thu, 10 Feb 2011 16:58:36 GMT From: "Dan Wing" To: References: Your message of Wed, 09 Feb 2011 18:34:20 PST. <099101cbc8cb$056e44a0$104acde0$@com> <201102101332.p1ADWnlN070065@givry.fdupont.fr> In-Reply-To: <201102101332.p1ADWnlN070065@givry.fdupont.fr> Date: Thu, 10 Feb 2011 08:58:36 -0800 Message-ID: <0ba001cbc943$c2355ce0$46a016a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvJJxopoFOXDbevQDOeoX8XtJ7g2gAHKGsw Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 16:58:25 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Thursday, February 10, 2011 5:33 AM > To: Dan Wing > Cc: 'Reinaldo Penno'; pcp@ietf.org > Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP > address as dynamic mappings > > > In your previous mail you wrote: > > And there could, I suppose, be more hosts at a subscriber's site > than can be mapped to a single IPv4 address. For example, 100 hosts > and the ISP wants to give every host 1000 ports. > > => usually the ISP ignores the number of hosts, i.e., the only use > of the host notion at the ISP level is a different internal address > (of course this supposes first there is not a NAT hidding hosts). > > Q: does anything break if two hosts, belonging to the same > subscriber, > are given different external IPv4 addresses? Today, without CGN, > that happens all the time anyway. > > => I can't parse your statement: the term external address makes sense > only where there is a NAT, and with a NAT only one address is visible. > > And to answer to the question, yes it breaks applications. Name one. -d > Now if you'd like to discuss this, IMHO the behave WG is the right > place. > > Regards > > Francis.Dupont@fdupont.fr From dwing@cisco.com Thu Feb 10 09:02:54 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293483A69FA for ; Thu, 10 Feb 2011 09:02:54 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQS-sSbr3vrx for ; Thu, 10 Feb 2011 09:02:53 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E4B213A659B for ; Thu, 10 Feb 2011 09:02:52 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcBACSpU02rR7Hu/2dsb2JhbACXDT+BJox3c556m0CFXASFAQ X-IronPort-AV: E=Sophos;i="4.60,451,1291593600"; d="scan'208";a="661584685" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 10 Feb 2011 17:03:05 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1AH35Md020438; Thu, 10 Feb 2011 17:03:05 GMT From: "Dan Wing" To: References: Your message of Wed, 09 Feb 2011 19:32:28 PST. <0a1201cbc8d3$24accc30$6e066490$@com> <201102101341.p1ADfRDH070633@givry.fdupont.fr> In-Reply-To: <201102101341.p1ADfRDH070633@givry.fdupont.fr> Date: Thu, 10 Feb 2011 09:03:04 -0800 Message-ID: <0ba101cbc944$62446640$26cd32c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvJKDxvyps+YIpMR8u5n7wMsh9MRQAG6D1Q Content-Language: en-us Cc: pcp@ietf.org, 'pcp issue tracker' Subject: Re: [pcp] base #9 (assigned): Are PCP-created mappings different from TCP SYN-created ones X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 17:02:54 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Thursday, February 10, 2011 5:41 AM > To: Dan Wing > Cc: 'pcp issue tracker'; pcp@ietf.org > Subject: Re: [pcp] base #9 (assigned): Are PCP-created mappings > different from TCP SYN-created ones > > > In your previous mail you wrote: > > > PS: I don't understand why I have to discuss about it: > > Because I don't understand the attack vector. Maybe someone > else understands the attack vector you're describing. > > => from RFC 4787: > > Filtering independently of the external > endpoint is not as secure: An unauthorized packet could get > through a specific port while the port was kept open if it was > lucky enough to find the port open. In theory, filtering based > on > both IP address and port is more secure than filtering based only > on the IP address (because the external endpoint could, in > reality, be two endpoints behind another NAT, where one of the > two > endpoints is an attacker). > > This explicitely states EIF is less secure than APDF. *Nodding agreement*. So you're saying that a PCP-created mapping, because it allows any host on the Internet to send a packet to the host, creates a security vulnerability. But that is what happens when a host wants to run a server, on today's Internet (without a CGN and without PCP): the host has to accept incoming connections from hosts on the Internet. That is, after all, the definition of "running a server". PCP's MAP OpCodes are intended to support that. That's their job, that is why they exist, and that's why we have those PCP OpCodes. I hope to have time, today, to craft some text for the Security Considerations section so that instead of going back and forth in email we can have straw man text to discuss. That's the only way to make forward progress. -d From Francis.Dupont@fdupont.fr Thu Feb 10 09:13:07 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEA643A67B4 for ; Thu, 10 Feb 2011 09:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CryrA7Y9YrCh for ; Thu, 10 Feb 2011 09:13:07 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id E7B343A63CA for ; Thu, 10 Feb 2011 09:13:06 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1AHDJM8083761; Thu, 10 Feb 2011 18:13:19 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102101713.p1AHDJM8083761@givry.fdupont.fr> From: Francis Dupont To: Reinaldo Penno In-reply-to: Your message of Thu, 10 Feb 2011 10:38:10 EST. Date: Thu, 10 Feb 2011 18:13:19 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "pcp@ietf.org" Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 17:13:08 -0000 In your previous mail you wrote: There is a very specific definition of a subscriber; this subscriber gets specific H-QoS, filtering, pay differentiated fee, have AAA enabled, etc. But I'm afraid it does not fit the model you are advocating. => I use the definition from base-04 (3 page 8 and 10.5 pages 42 and 43). Can you elaborate on what you said about the notion of subscriber is essential for security? => the subscriber security is in fact the strict separation between subscribers, so not only the notion could not be loose but the way a subscriber can be identified is critical. (cf 10.5) Note we have only two security level: the security inside a subscriber and the security between subscribers. This is why we are in trouble with enterprise NATs which don't fit in any of them. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Thu Feb 10 09:19:02 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DADA3A6A56 for ; Thu, 10 Feb 2011 09:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RPGGZXcX38i for ; Thu, 10 Feb 2011 09:19:00 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 605CF3A6A4C for ; Thu, 10 Feb 2011 09:19:00 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1AHJCEI084150 for ; Thu, 10 Feb 2011 18:19:12 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102101719.p1AHJCEI084150@givry.fdupont.fr> From: Francis Dupont To: pcp@ietf.org Date: Thu, 10 Feb 2011 18:19:12 +0100 Sender: Francis.Dupont@fdupont.fr Subject: [pcp] updated security model X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 17:19:02 -0000 This is an updated version of the security model for the NAT operations of PCP. First I embrace and extend the base-04 terminology. TERMINOLOGY >From draft-wing-pcp-base-04.txt section 3: - Mappings (divided in the 3 types below) - implicit dynamic mapping - explicit dynamic mapping - static mapping - Port Forwarding (this is the function, the object being a mapping) - PCP Client - PCP Server - Interworking Function (abbrev IWF) I extend IWF to PCP proxies, i.e., an IWF maps a pcp, including PCP itself, to PCP. - subscriber - host (note as in base-04 a 'host' is in fact an Internal Host) New definitions: - 'a pcp' (lower case): a way (PCP, UPnP-IGD, NAT-PMP, CLI, web page, etc) to manage explicit dynamic or static mappings on a NAT. By convention in this text, when an explicit dynamic mapping is not explicitely managed by a pcp, it is managed by PCP, i.e., an explicit dynamic mapping is either managed by PCP or explicitely managed by another way. Of course static mappings are managed by a pcp which is not PCP. - requesting application (abbrev RA): an application running on a host which sends PCP requests (i.e., a PCP terminal client) - home network (abbrev HN): a LAN or a collection of LANs where are the hosts. The home network is supposed to be one domain for trust/security. - home gateway (abbrev HG): the device between the HN and the external network. It can be a NAT/firewall, runs IWF, etc. It is a privileged point of control for PCP. - infrastructure: the network(s) between the HG and the CGN. The infrastructure is supposed to be fully on the control of the Internet Service Provider providing the CGN service. - carrier-grade NAT (abbrev CGN): a NAT/firewall of an Internet Service Provider providing a NAT/firewall service for subscribers. - to manage explicit dynamic or static mappings: to create / delete / list explicit dynamic or static mappings - administrator: a person which can perform operations (including but not limited to manage operations) on a NAT/firewall - to steal/theft of an explicit dynamic or static mapping: to create an explicit dynamic or static mapping with the same external address and port than used by another entity - to renumber: for an entity identified by an address to change this address. The term applies to hosts (identified by the internal address) and subscribers in some scenarios (identified by the HG infrastructure address). After this point, the document will only address explicit dynamic mappings but in fact the same considerations apply to static mappings, but there is no concensus about whether PCP applies only to explicit dynamic mapping or to both explicit dynamic and static mappings. The hierarchy is RA - host - subscriber. SCENARIOS Legacy scenario using IWF: HN <---------------------------------------------> host HG +------------+ +------------------+ | legacy RA |--- a pcp ---| IWF - PCP server |--- Internet +------------+ +------------------+ Legacy scenario using PCP: HN <--------------------------------> host HG +-------+ +------------+ | RA |--- PCP ---| PCP server |--- Internet +-------+ +------------+ The idea is to reason on the legacy scenario using PCP and to map results when possible to the legacy scenario using IWF. So from this point the HN is supposed to have been upgraded to directly use PCP. DS-Lite scenario: HN infrastructure <-------------------------><-------------------------------> host HG CGN +-------+ +-----+ +------------+ | RA |--- PCP ---| IWF | -- IPv6 tunnel -- | PCP server | --- Internet +-------+ +-----+ +------------+ with: - the HG is a Basic Bridging BroadBand (B4) - the CGN is an Address Family Transition Router (AFTR) - the infrastructure transports IPv4 packets encapsulated into IPv6 - subscribers are identified by the HG/B4 IPv6 address NAT444 scenario: HN infrastructure <------------------------------------><-----------------> host HG CGN +-------+ +----------------+ +------------+ | RA |--- PCP ---| IWF/PCP server | --- | PCP server | --- Internet +-------+ +----------------+ +------------+ with: - the HG runs a NAT/firewall so it provides a PCP server for its control and at the same time an IWF for the CGN - the infrastructure addressing should be in a dedicated /8 - subscriber are identified by the HG address on the infrastructure We are interested only by the not-home part: the home part can be considered as a special case of the legacy scenario. I still need descriptions for NATxy (64, 46, etc). The enterprise NAT description is an issue: only a flat organization can map to the legacy scenario. SECURITY ANALYSIS The theft of explicit dynamic mappings is considered to be the key threat: the idea is if users are protected against this threat then other threats as not authorized creations or deletions of explicit dynamic mappings are impossible too (the logic is if any is possible then theft is possible). between RAs: I propose to not address security issue between two RAs running on the same host inside PCP. BTW usually two applications can't bind the same port so this doesn't introduce operational problems. To summary the proposal is to accept the vulnerability in PCP and to rely on the host operating system to address it if/when it can/should. Note this implies an RA is authorized to manage its host explicit dynamic mappings. between hosts: a host is identified by the internal address so either: - a host is authorized to manage explicit dynamic mappings on the behalf of another host so to use an internal address which is not its address. - a host is not authorized to do this and the IWF or PCP server on the HG receiving PCP requests from a host must check the PCP request source address and the internal address are the same. We can recommend this check to be implemented (BTW it is built-in in NAT-PMP and optional in UPnP-IGD), but what to propose for the default? Note the check restricts the management of subscriber explicit dynamic mappings to the HG administrator, the same role/entity than for host renumbering. theft in the home: if the HG as a NAT loses its state and may re-assign a previously assigned external address and port, this opens a race where a host can steal another host explicit dynamic mappings. There are two possible answers: - this vulnerability is acceptable - this vulnerability is not acceptable and the HG is required to keep its state in stable storage. IMHO the first is right for a real residential HN, i.e., with a consumer-grade NAT which has no reliable stable storage. The second is better for an enterprise NAT. Note: it is possible to remove the vulnerability by using a new external address and/or port pool but this raises operational concerns. I propose a simple way to decide: as legacy pcp's (UPnP IGD 1.0 for instance) don't provide a protection against this threat if a legacy pcp is reasonably application then the vulnerability is acceptable, if it is not then stable storage is required, i.e., the pcp's supported by the IWF show what should be the default. between subscribers: - a subscriber is not authorized to manage explicit dynamic mappings on the behalf of another subscriber. So the PCP server of a CGN is required to check the subscriber identity (typically the HG address on the infrastructure). - a subscribe is not authorized to steal another subscriber explicit dynamic mappings. So the PCP server of a CGN is required to keep its state (explicit dynamic mappings and subscriber identities) in stable storage when it re-assigns external addresses and/or ports from the same pool. These have some direct consequences: - scenarios with subscribers require a per subscriber authentication. (this is for scenarios with subscribers other than DS-Lite and NAT444) - if the subscriber identity is the HG address on the infrastructure, some measures must be taken to ensure a subscriber can't use the address of another subscriber, i.e., access control on the infrastructure including ingress filtering. (with other words the identification should be able to provide authentication) - the support of subscriber renumbering requires a subscriber authentication which is not based on addresses. summary: (to be written if/when consensus will be reached) Regards Francis.Dupont@fdupont.fr From dwing@cisco.com Thu Feb 10 09:21:14 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AD7D3A6A4C for ; Thu, 10 Feb 2011 09:21:14 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2uSm8zJk5Vi for ; Thu, 10 Feb 2011 09:21:13 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4C0EA3A6A25 for ; Thu, 10 Feb 2011 09:21:13 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQBAOCsU02rR7H+/2dsb2JhbACXDYFljHdznnqbQ4VcBIUB X-IronPort-AV: E=Sophos;i="4.60,451,1291593600"; d="scan'208";a="328000208" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 10 Feb 2011 17:21:26 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1AHLPbl022104; Thu, 10 Feb 2011 17:21:25 GMT From: "Dan Wing" To: "'Francis Dupont'" , References: <201102101215.p1ACFkQp065426@givry.fdupont.fr> In-Reply-To: <201102101215.p1ACFkQp065426@givry.fdupont.fr> Date: Thu, 10 Feb 2011 09:21:25 -0800 Message-ID: <0bcf01cbc946$f232cba0$d69862e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvJHEckipwDzsqCR4Ct2Is11wvSqgAKd4cQ Content-Language: en-us Subject: Re: [pcp] proposal about internal addresses X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 17:21:14 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Francis Dupont > Sent: Thursday, February 10, 2011 4:16 AM > To: pcp@ietf.org > Subject: [pcp] proposal about internal addresses > > Here is a counter-proposal about internal addresses, > based on the fact the THIRD_PARTY option disadvantages > (for instance it makes a PCP relay far more complex) > are greater than advantages. > > I propose to go back to 03 layout, i.e., the internal address > is included in MAP and PEER OpCodes. > > The supposed simplicity in PCP clients is IMHO an API issue, > I suggest to not improve it inside the protocol but to ask > for an API routine which fills the field from the > socket local address. Of course the section 7 is the right > place to illustrate this. Another idea is to define a sentinel value to mean "this IP address", such as all zero's (e.g., 0.0.0.0). This, I believe, provides the simplicity for the PCP client implementation. I had considered that, and written text to support it. But I took one of your suggestions from a month or two ago to heart, to move less-used things to options. Third party mappings will be less used than third party mappings, especially as PCP is incorporated into hosts themselves, which are speaking IPv6 and communicating with an IPv6 firewall. A B4 element will be solely doing 3rd party mappings (no matter if it is proxying PCP or proxying UPnP IGD). > If to reduce the number of OpCodes is considered as a good > thing I propose to reuse the External_AF PEER idea. > BTW it should be in this case a good idea to make MAP and > PEER OpCodes more similar, i.e., to maximize code sharing > in programs. That seems acceptable to me. Anyone else? -d > Regards > > Francis.Dupont@fdupont.fr > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From Francis.Dupont@fdupont.fr Thu Feb 10 09:26:17 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28F03A6A4C for ; Thu, 10 Feb 2011 09:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEtPdBXqK+D4 for ; Thu, 10 Feb 2011 09:26:16 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 300563A6A47 for ; Thu, 10 Feb 2011 09:26:16 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1AHQOBt084609; Thu, 10 Feb 2011 18:26:24 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102101726.p1AHQOBt084609@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Thu, 10 Feb 2011 08:29:55 PST. <0b7c01cbc93f$c0bfd0b0$423f7210$@com> Date: Thu, 10 Feb 2011 18:26:24 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-04 posted X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 17:26:17 -0000 In your previous mail you wrote: > => this could be a good idea but it is clearly a change > in the semantics as it is no longer possible to perform > a PIN44/MAP4 operation from an IPv6 source, e.g., > DS-Lite plain IPv6 mode. Yes, it is still possible for an IPv6 node to get an IPv4 mapping. It sends a MAP4 request from its IPv6 interface to the PCP server's IPv6 address. => it is possible in the fixed 04, not in the published 04. This doesn't change the fact this should have been discussed before. > => at the limit this proves the NOT_AUTHORIZED result code > can be raised in too many different cases (and coding a > PCP server I really think it is an issue, a new ticket > please) What do you want the ticket to say? => split the NOT_AUTHORIZED result code according to the different cases it is returned. > but IMHO the new THIRD_PARTY option is there > mainly to catch all cases where the internal address and > the source address are not the same. Yes, that is exactly the purpose of the THIRD_PARTY option. => so to keep an internal address field is a clear alternative. Regards Francis.Dupont@fdupont.fr From rpenno@juniper.net Thu Feb 10 09:52:43 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D37D3A67C2 for ; Thu, 10 Feb 2011 09:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKFI2xbDTe3G for ; Thu, 10 Feb 2011 09:52:42 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 61FFD3A67D8 for ; Thu, 10 Feb 2011 09:52:40 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTVQl9MXkPGpASJ0un6T40L//bOH8S9Cl@postini.com; Thu, 10 Feb 2011 09:52:55 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 10 Feb 2011 09:50:37 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 10 Feb 2011 12:50:49 -0500 From: Reinaldo Penno To: Francis Dupont Date: Thu, 10 Feb 2011 12:50:47 -0500 Thread-Topic: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings Thread-Index: AcvJRdQ/YicBwdFfSAiuhdcoXSNomQABTeuK Message-ID: In-Reply-To: <201102101713.p1AHDJM8083761@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 17:52:43 -0000 On 2/10/11 9:13 AM, "Francis Dupont" wrote: > In your previous mail you wrote: >=20 > There is a very specific definition of a subscriber; this subscriber g= ets > specific H-QoS, filtering, pay differentiated fee, have AAA enabled, e= tc. > But I'm afraid it does not fit the model you are advocating. > =20 > =3D> I use the definition from base-04 (3 page 8 and 10.5 pages 42 and 43= ). " subscriber: an entity provided access to the network. In the case of a commercial ISP, this is typically a single home." This is just a circuit/billing relationship. We should not extrapolate the addressing relationship from this. There are home subscribers with fixed IPv4(s), dynamic, with a bridge devic= e that go through a single layer of NAT (CGN in the network); not to mention SOHO and Enterprise. They can all go trough the same CGN. >=20 > Can you elaborate on what you said about the notion of subscriber is > essential for security? > =20 > =3D> the subscriber security is in fact the strict separation between > subscribers, so not only the notion could not be loose but > the way a subscriber can be identified is critical. (cf 10.5) I think maybe the issue is that in the paragraph below should substitute 'subscriber' by 'PCP Client or third-party device' " The MAP OpCodes require subscriber identification because they allocate resources or adjust resources allocated to a subscriber." It seems natural this change since if we are talking about resources, certainly different hosts/PCP Clients within a 'subscriber' (billing relationship) can ask for different resources. >=20 > Note we have only two security level: the security inside a subscriber > and the security between subscribers. This is why we are in trouble > with enterprise NATs which don't fit in any of them. >=20 > Regards >=20 > Francis.Dupont@fdupont.fr From trac@tools.ietf.org Thu Feb 10 09:54:11 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFCE23A6817 for ; Thu, 10 Feb 2011 09:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JS-NEMh+AT6D for ; Thu, 10 Feb 2011 09:54:08 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2795B3A67C2 for ; Thu, 10 Feb 2011 09:54:08 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pnaii-0001gg-TT; Thu, 10 Feb 2011 09:54:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com, Francis.Dupont@fdupont.fr X-Trac-Project: pcp Date: Thu, 10 Feb 2011 17:54:20 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/37 Message-ID: <063.668e2fa4076137b82bb4d8988e6ed76c@tools.ietf.org> X-Trac-Ticket-ID: 37 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, Francis.Dupont@fdupont.fr, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: [pcp] base #37 (new): create additional NOT_AUTHORIZED result codes X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 17:54:11 -0000 #37: create additional NOT_AUTHORIZED result codes The NOT_AUTHORIZED result code occurs in many situations; need finer result codes for the various types of non-authorized things a client might request. -- ---------------------------------------+------------------------------------ Reporter: Francis.Dupont@… | Owner: dwing@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: ---------------------------------------+------------------------------------ Ticket URL: pcp From dwing@cisco.com Thu Feb 10 09:54:38 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B78583A67C2 for ; Thu, 10 Feb 2011 09:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.019 X-Spam-Level: X-Spam-Status: No, score=-110.019 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiVA4jERoCpo for ; Thu, 10 Feb 2011 09:54:38 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id F342B3A6817 for ; Thu, 10 Feb 2011 09:54:37 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoBAIy1U02rRN+J/2dsb2JhbACXDj+BJox4c58Am0eFXASFAQ X-IronPort-AV: E=Sophos;i="4.60,451,1291593600"; d="scan'208";a="406776076" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 10 Feb 2011 17:54:50 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p1AHsoqR028996; Thu, 10 Feb 2011 17:54:50 GMT From: "Dan Wing" To: References: Your message of Thu, 10 Feb 2011 08:29:55 PST. <0b7c01cbc93f$c0bfd0b0$423f7210$@com> <201102101726.p1AHQOBt084609@givry.fdupont.fr> In-Reply-To: <201102101726.p1AHQOBt084609@givry.fdupont.fr> Date: Thu, 10 Feb 2011 09:54:50 -0800 Message-ID: <0c0b01cbc94b$9d1b3fd0$d751bf70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvJR7n2sp0BS/ZBTyq7L/8j0ifk7gAA9U+Q Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] draft-ietf-pcp-base-04 posted X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 17:54:38 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Thursday, February 10, 2011 9:26 AM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] draft-ietf-pcp-base-04 posted > > > In your previous mail you wrote: > > > => this could be a good idea but it is clearly a change > > in the semantics as it is no longer possible to perform > > a PIN44/MAP4 operation from an IPv6 source, e.g., > > DS-Lite plain IPv6 mode. > > Yes, it is still possible for an IPv6 node to get an IPv4 > mapping. It sends a MAP4 request from its IPv6 interface > to the PCP server's IPv6 address. > > => it is possible in the fixed 04, not in the published 04. > This doesn't change the fact this should have been discussed > before. > > > => at the limit this proves the NOT_AUTHORIZED result code > > can be raised in too many different cases (and coding a > > PCP server I really think it is an issue, a new ticket > > please) > > What do you want the ticket to say? > > => split the NOT_AUTHORIZED result code according to the > different cases it is returned. Ok, I think http://trac.tools.ietf.org/wg/pcp/trac/ticket/37 is what you're looking for. -d > > but IMHO the new THIRD_PARTY option is there > > mainly to catch all cases where the internal address and > > the source address are not the same. > > Yes, that is exactly the purpose of the THIRD_PARTY option. > > => so to keep an internal address field is a clear alternative. > > Regards > > Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Thu Feb 10 09:58:08 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AD9E3A6817 for ; Thu, 10 Feb 2011 09:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XJW-7E6guai for ; Thu, 10 Feb 2011 09:58:07 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id D394C3A67C2 for ; Thu, 10 Feb 2011 09:58:06 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1AHwI38086504; Thu, 10 Feb 2011 18:58:18 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102101758.p1AHwI38086504@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Thu, 10 Feb 2011 08:57:31 PST. <0b9f01cbc943$9b38bdd0$d1aa3970$@com> Date: Thu, 10 Feb 2011 18:58:18 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] brief review of base-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 17:58:08 -0000 In your previous mail you wrote: > => I don't see these advantages nor a discussion of this > major change in the list. Then, let's start with the agreement that this is the discussion. => it is a formal point: the discussion is supposed to happen before, not after. BTW this is not your responsability, it is chairs' one. Nothing is cast in stone; this is an I-D. I am trying my best to simplify the protocol based on 100s of emails and and discussions. And I do make mistakes. => yes as a human you can make mistakes and don't like to go backward (:-). > > already exists as a static mapping will return a successful > > result, confirming that the requested mapping exists." > > > > With which assigned lifetime? > > With the lifetime the PCP server wants to use. Typically, > the PCP server would extend the lifetime based on the > requested-lifetime. Does this need to be spelled out in > this example?? > > => I can't parse your answer: we are talking about *static* > mappings so they have by definition infinite lifetimes. I do not understand the purpose of discussing static mappings (created with a CLI) and how/why they affect PCP or how/why they affect implicit dynamic mappings (e.g., TCP SYN). => IMHO the only question is whether they are manageabled by PCP and IMHO again the answer should be 'no'. Is there an application or a protocol that breaks if they get assigned different public IP addresses? => yes, this is why the behave WG produces a requirement saying all mappings of the same subscriber must get the same external address. I can see where PCP and implicit dynamic mappings need to be on the same public IP address. But I don't see a similar need for static mappings (created with a CLI) to be on the same public address. => explicit dynamic mappings and static mappings are not so different: they are two kinds of port forwarding. And I don't believe the PCP specification can create such a rule, either; obviously the PCP specification can't create a rule that implicit dynamic mappings and static mappings have to be on the same public IP address, because PCP is only defining PCP and can only define rules for itself. => I plainly agree: the PCP specs should only refer to behave WG documents. > > Does this work too for deletion? > > Yes, section 8.4 says: > > " If the PCP client attempts to delete a mapping that > does not exist, the success response code is returned." > > => in this text the 'a mapping' is 'an explicit dynamic > mapping' so what happens when a request is received > for the deletion of a static mapping? Static mappings can't be deleted by PCP. That is the purpose of the UNABLE_TO_DELETE_ALL result code: "If the PCP client attempts to delete a port mapping which was manually assigned by some kind of configuration tool, the PCP server MUST respond with UNABLE_TO_DELETE_ALL result code, but the other fields are encoded as described above." => hum, IMHO the wording should be changed to 'a not explicit dynamic mapping' so it will be clear a PCP delete works only on PCP created mappings. BTW this can lead some implementations to return this result code for any not specific delete request but I can't see why it should be an issue. > => spoofed SERVER_OVERLOADED with silly retry values. That concern is not unique to SERVER_OVERLOADED, is it? => not unique but SERVER_OVERLOADED has no justification. > => oops, what I tried to suggest is to change the length from > 'one only' to 'equal or greater than one'. I understand that was your suggestion. But this gets risky, because (a) this is an error condition, and we all know that error paths in code are never as well-tested as success paths, (b) this error condition would be the only PCP option defined in the base protocol that can occur multiple times, => (b) is another way to handle more than 4 unsupported options. It is a matter of taste. > I do not see anything that PCP can do about an ISP renumbering a > subscriber and the related mis-direction of traffic to the > subscriber's > old IP address. > > => we could say it is a major security problem. But ISP renumbering is not unique to PCP (PCP doesn't cause the renumbering), and ISP renumbering is not made worse because of the existence of PCP (nor is ISP renumbering made worse because of the existence of a CGN or a firewall). => we have a rule in France: you opened the wine bottle, now you have to drink it. So as you consider this problem you should not stop at its bad operational consequences, but to its even worse security consequences. BTW a reference to the security considerations should be enough (of course *improved* security considerations). And you'd like it to be a SHOULD NOT? It _does_ result in inefficient operation, and I can certainly see how a CGN would want to deprecate (not support) that option in the future, because a requested-for port simply cannot be forced (it will already be used by another subscriber). => I use it for renewals and I'll continue to use it in this case, so I don't really care... BTW it is easy to support in a CGN and the fact it doesn't work in the real world is not the CGN programmer fault (I know we agree about this point). > => I still don't know what is "its configured maximum lifetime value". A CLI setting, a #define'd value, or so on. => so it is a new and PCP specific NAT property. Regards Francis.Dupont@fdupont.fr PS: I sent three large messages to the list: - a counter-proposal for the internal address issue - another one about errors - an updated version of the security model From Francis.Dupont@fdupont.fr Thu Feb 10 10:13:21 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F4113A67AB for ; Thu, 10 Feb 2011 10:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsYQJNTq4RBa for ; Thu, 10 Feb 2011 10:13:20 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 9236F3A659A for ; Thu, 10 Feb 2011 10:13:19 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1AIDVXo087539; Thu, 10 Feb 2011 19:13:31 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102101813.p1AIDVXo087539@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Thu, 10 Feb 2011 08:58:36 PST. <0ba001cbc943$c2355ce0$46a016a0$@com> Date: Thu, 10 Feb 2011 19:13:31 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 18:13:21 -0000 In your previous mail you wrote: > And to answer to the question, yes it breaks applications. Name one. => NAT based load balancers and in general internally distributed applications (but the question should be sent to the behave WG mailing list). Regards Francis.Dupont@fdupont.fr PS: note someone who worked at that time for a huge ISP really insisted about this point, so I expect you'll get more/better arguments from people using CGNs (which is not my case :-). From Francis.Dupont@fdupont.fr Thu Feb 10 10:24:17 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAF613A659A for ; Thu, 10 Feb 2011 10:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfkecfzKiIAM for ; Thu, 10 Feb 2011 10:24:17 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id AC07F3A6981 for ; Thu, 10 Feb 2011 10:24:16 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1AIOSsZ088192; Thu, 10 Feb 2011 19:24:28 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102101824.p1AIOSsZ088192@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Thu, 10 Feb 2011 09:03:04 PST. <0ba101cbc944$62446640$26cd32c0$@com> Date: Thu, 10 Feb 2011 19:24:28 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org, 'pcp issue tracker' Subject: Re: [pcp] base #9 (assigned): Are PCP-created mappings different from TCP SYN-created ones X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 18:24:17 -0000 In your previous mail you wrote: > This explicitely states EIF is less secure than APDF. *Nodding agreement*. So you're saying that a PCP-created mapping, because it allows any host on the Internet to send a packet to the host, creates a security vulnerability. => when a NAT is not EIM/EIF, an explicit dynamic mapping is more vulnerable than an implicit dynamic mapping, just from the different filtering. (*) But that is what happens when a host wants to run a server, on today's Internet (without a CGN and without PCP): the host has to accept incoming connections from hosts on the Internet. That is, after all, the definition of "running a server". => yes, I don't say explicit dynamic mappings are bad from the security point of view (but some argued this at the last IETF), just when a NAT is not EIM/EIF... PCP's MAP OpCodes are intended to support that. That's their job, that is why they exist, and that's why we have those PCP OpCodes. I hope to have time, today, to craft some text for the Security Considerations section so that instead of going back and forth in email we can have straw man text to discuss. That's the only way to make forward progress. => I updated my security model so you should get some material (and take benefit of your timezone :-). Regards Francis.Dupont@fdupont.fr PS: (*) port randomization is another point. It can be considered as a needed security feature (in fact it is as soon as one understands what is it), is not very compatible with EIM and of course doesn't make a lot of sense for explicit dynamic mappings (and no sense at all for static mappings). From Francis.Dupont@fdupont.fr Thu Feb 10 10:38:59 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 653343A6824 for ; Thu, 10 Feb 2011 10:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3zfuBo1gyFB for ; Thu, 10 Feb 2011 10:38:58 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 550943A69C3 for ; Thu, 10 Feb 2011 10:38:58 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1AIdAKx089077; Thu, 10 Feb 2011 19:39:10 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102101839.p1AIdAKx089077@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Thu, 10 Feb 2011 09:21:25 PST. <0bcf01cbc946$f232cba0$d69862e0$@com> Date: Thu, 10 Feb 2011 19:39:10 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] proposal about internal addresses X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 18:38:59 -0000 In your previous mail you wrote: > The supposed simplicity in PCP clients is IMHO an API issue, > I suggest to not improve it inside the protocol but to ask > for an API routine which fills the field from the > socket local address. Of course the section 7 is the right > place to illustrate this. Another idea is to define a sentinel value to mean "this IP address", such as all zero's (e.g., 0.0.0.0). => unfortunately the all zero's has already a meaning for deletes (worst, it is a dangerous meaning, i.e., we do want to get it only explicitely). I thought about a magic value too but I couldn't find something which is not ambiguous or already used or painful to use (e.g., 0xff...ff). So I consider now a helper function. Note I am interested by the API too, even it is not in the scope of the PCP WG. And it is both hard to design and even harder to get useful feedback... This, I believe, provides the simplicity for the PCP client implementation. => in fact not (and not at all for IPv6), and the simplicity should come from the API. I had considered that, and written text to support it. But I took one of your suggestions from a month or two ago to heart, to move less-used things to options. => yes, and universally used to the header... But for instance it is at least too soon to move the external address to the header, even with a per-subscriber unique external address it makes sense. > If to reduce the number of OpCodes is considered as a good > thing I propose to reuse the External_AF PEER idea. > BTW it should be in this case a good idea to make MAP and > PEER OpCodes more similar, i.e., to maximize code sharing > in programs. That seems acceptable to me. => so as we have solved the simplicity and the number of OpCode issues is there another good reason to not come back to the internal address in the OpCode? Regards Francis.Dupont@fdupont.fr PS: note for the GET/GETNEXT operation(s) the number of related options should be minimized too. I.e., it is another reason to not put the internal address in an option. From dwing@cisco.com Thu Feb 10 10:43:39 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41E103A6987 for ; Thu, 10 Feb 2011 10:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.116 X-Spam-Level: X-Spam-Status: No, score=-110.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioRG3wHAgzCQ for ; Thu, 10 Feb 2011 10:43:38 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 76A403A6981 for ; Thu, 10 Feb 2011 10:43:38 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoBADfBU02rRN+J/2dsb2JhbACXDz+BJox4c555mzyFXASFAQ X-IronPort-AV: E=Sophos;i="4.60,451,1291593600"; d="scan'208";a="406788793" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 10 Feb 2011 18:43:51 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p1AIho0i003880; Thu, 10 Feb 2011 18:43:50 GMT From: "Dan Wing" To: References: Your message of Thu, 10 Feb 2011 09:03:04 PST. <0ba101cbc944$62446640$26cd32c0$@com> <201102101824.p1AIOSsZ088192@givry.fdupont.fr> In-Reply-To: <201102101824.p1AIOSsZ088192@givry.fdupont.fr> Date: Thu, 10 Feb 2011 10:43:49 -0800 Message-ID: <0c4c01cbc952$75cb9a90$6162cfb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvJT8ewp3/+wdywRDGhfmkfXz3pIAAAl2fg Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] base #9 (assigned): Are PCP-created mappings different from TCP SYN-created ones X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 18:43:39 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Thursday, February 10, 2011 10:24 AM > To: Dan Wing > Cc: 'pcp issue tracker'; pcp@ietf.org > Subject: Re: [pcp] base #9 (assigned): Are PCP-created mappings > different from TCP SYN-created ones > > > In your previous mail you wrote: > > > This explicitely states EIF is less secure than APDF. > > *Nodding agreement*. > > So you're saying that a PCP-created mapping, because it allows any > host on the Internet to send a packet to the host, creates a > security > vulnerability. > > => when a NAT is not EIM/EIF, an explicit dynamic mapping is > more vulnerable than an implicit dynamic mapping, just from > the different filtering. (*) Agreed. But how else to run a server, other than to accept connections from anywhere? And there is the REMOTE_PEER_FILTER option, if the PCP client wants to offload some of its filtering to the PCP-controlled device. But that of course requires the PCP client to know the IP address(es) (or, in -05, the prefix(es)) of the remote peer(s). Which of course is not always possible. > But that is what happens when a host wants to run a server, on > today's Internet (without a CGN and without PCP): the host has to > accept incoming connections from hosts on the Internet. That is, > after all, the definition of "running a server". > > => yes, I don't say explicit dynamic mappings are bad from > the security point of view (but some argued this at the last IETF), > just when a NAT is not EIM/EIF... > > PCP's MAP OpCodes are intended to support that. That's their job, > that is why they exist, and that's why we have those PCP OpCodes. > > I hope to have time, today, to craft some text for the Security > Considerations section so that instead of going back and forth > in email we can have straw man text to discuss. That's the only > way to make forward progress. > > => I updated my security model so you should get some material > (and take benefit of your timezone :-). Yeah, I'm reading through it now. Thanks. -d > Regards > > Francis.Dupont@fdupont.fr > > PS: (*) port randomization is another point. It can be considered > as a needed security feature (in fact it is as soon as one understands > what is it), is not very compatible with EIM and of course doesn't > make a lot of sense for explicit dynamic mappings (and no sense > at all for static mappings). From Francis.Dupont@fdupont.fr Thu Feb 10 10:50:53 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98E8A3A6987 for ; Thu, 10 Feb 2011 10:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPgoZ2ZqFMWV for ; Thu, 10 Feb 2011 10:50:51 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id D6CEE3A6981 for ; Thu, 10 Feb 2011 10:50:50 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1AIp37f089780 for ; Thu, 10 Feb 2011 19:51:03 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102101851.p1AIp37f089780@givry.fdupont.fr> From: Francis Dupont To: pcp@ietf.org Date: Thu, 10 Feb 2011 19:51:03 +0100 Sender: Francis.Dupont@fdupont.fr Subject: [pcp] an idea about REMOTE_PEER_FILTER X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 18:50:53 -0000 We have still some open issues about REMOTE_PEER_FILTER and as it won't be moved to another document we have to address them to make the base document complete. (BTW in base-04 figure 1 28 -> 128) It seems we agree MAP request with a match-all (i.e., zero prefix length and remote peer IP address) REMOTE_PEER_FILTER option should remove all filters. Now we need a way to remove one filter, ideas: - authorize multiple options: the first one is a match-all (i.e., a reset), followed by all wanted filters. As a request is atomic, this can work if the number of filters stays small. - extend the delete operation to delete the filter when there is a filter option. Seems a bit fragile, i.e., I prefer the previous one. - others? Note we need a 'too many filters' result code anyway. Regards Francis.Dupont@fdupont.fr PS: it is strongly related to the ticket #10. From simon.perreault@viagenie.ca Thu Feb 10 11:02:01 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96CC03A6981 for ; Thu, 10 Feb 2011 11:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFPlLkM1bldP for ; Thu, 10 Feb 2011 11:02:00 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 5A6E53A67A4 for ; Thu, 10 Feb 2011 11:02:00 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 520E720DFE for ; Thu, 10 Feb 2011 14:02:12 -0500 (EST) Message-ID: <4D543633.4040208@viagenie.ca> Date: Thu, 10 Feb 2011 14:02:11 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: pcp@ietf.org References: <201102101851.p1AIp37f089780@givry.fdupont.fr> In-Reply-To: <201102101851.p1AIp37f089780@givry.fdupont.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pcp] an idea about REMOTE_PEER_FILTER X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 19:02:01 -0000 On 2011-02-10 13:51, Francis Dupont wrote: > We have still some open issues about REMOTE_PEER_FILTER > and as it won't be moved to another document PCP would be a leaner and better protocol without it. Why not move it to a separate document about firewall control? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dwing@cisco.com Thu Feb 10 11:02:53 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0E93A67A4 for ; Thu, 10 Feb 2011 11:02:53 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nw6fnv4fNq9j for ; Thu, 10 Feb 2011 11:02:52 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6D5FE3A6981 for ; Thu, 10 Feb 2011 11:02:52 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwBAEXFU02rR7Hu/2dsb2JhbACXD4FljHhznn+bPoVcBIUB X-IronPort-AV: E=Sophos;i="4.60,451,1291593600"; d="scan'208";a="661619739" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 10 Feb 2011 19:03:05 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1AJ35FG011057; Thu, 10 Feb 2011 19:03:05 GMT From: "Dan Wing" To: References: Your message of Thu, 10 Feb 2011 09:21:25 PST. <0bcf01cbc946$f232cba0$d69862e0$@com> <201102101839.p1AIdAKx089077@givry.fdupont.fr> In-Reply-To: <201102101839.p1AIdAKx089077@givry.fdupont.fr> Date: Thu, 10 Feb 2011 11:03:05 -0800 Message-ID: <0c5601cbc955$25d12de0$717389a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvJUdcwN92OIqNMRQq1CmJoI3lq0AAAeFFg Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] proposal about internal addresses X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 19:02:53 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Thursday, February 10, 2011 10:39 AM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] proposal about internal addresses > > > In your previous mail you wrote: > > > The supposed simplicity in PCP clients is IMHO an API issue, > > I suggest to not improve it inside the protocol but to ask > > for an API routine which fills the field from the > > socket local address. Of course the section 7 is the right > > place to illustrate this. > > Another idea is to define a sentinel value to mean "this > IP address", such as all zero's (e.g., 0.0.0.0). > > => unfortunately the all zero's has already a meaning > for deletes (worst, it is a dangerous meaning, i.e., > we do want to get it only explicitely). There has not been a meaning for all-zero in the internal IP address. All-zero has only been meaningful for lifetime (where it means delete a mapping), port (where it means 'all ports'), and, in -05, for protocol (where it means 'all protocols supported by the PCP server'). However, port=0 and protocol=0 are wildcards; internal-ip-address=0 would have a different meaning. I find that cumbersome and a likely cause of confusion. > I thought about a magic value too but I couldn't find > something which is not ambiguous or already used or > painful to use (e.g., 0xff...ff). So I consider now > a helper function. Yes, and that sort of thinking is exactly what led me towards a separate THIRD_PARTY option. > Note I am interested by the API too, even it is not > in the scope of the PCP WG. And it is both hard to > design and even harder to get useful feedback... Dave Thaler analyzed the existing port mapping APIs in both OSX and Windows, starting at slide 3 of http://www.ietf.org/proceedings/77/slides/softwire-2.pdf He may have some ideas on how those APIs can express the 'map my address' versus 'map a different address'. > This, I believe, provides the simplicity for the PCP client > implementation. > > => in fact not (and not at all for IPv6), I don't see how it makes IPv6 worse. Maybe you could elaborate. > and the simplicity > should come from the API. Well, someone is writing that API -- either someone at Apple or Microsoft for their respective frameworks. And if an application is running without a framework underneath it, someone will code PCP from scratch. > I had considered that, and written text > to support it. But I took one of your suggestions from a > month or two ago to heart, to move less-used things to > options. > > => yes, and universally used to the header... > But for instance it is at least too soon to move the > external address to the header, even with a per-subscriber > unique external address it makes sense. > > > If to reduce the number of OpCodes is considered as a good > > thing I propose to reuse the External_AF PEER idea. > > BTW it should be in this case a good idea to make MAP and > > PEER OpCodes more similar, i.e., to maximize code sharing > > in programs. > > That seems acceptable to me. > > => so as we have solved the simplicity and the number of OpCode > issues is there another good reason to not come back to the > internal address in the OpCode? I'm fine to eliminate THIRD_PARTY. But only if we can figure out a way for the 'internal-ip-address' to carry an indication that it to be ignored -- this allows the PCP client to simply be a UDP client application. Otherwise, it needs to bind to a specific interface or needs to figure out which interface its packet will egress. Obviously, obviously, that is not impossible. But it complicates the PCP client, could be implemented wrong, and provides no additional function to the protocol. > PS: note for the GET/GETNEXT operation(s) the number of > related options should be minimized too. I.e., it is > another reason to not put the internal address in an option. -d From dwing@cisco.com Thu Feb 10 11:03:31 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C2D33A6A5A for ; Thu, 10 Feb 2011 11:03:31 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g50cVv8sPeSM for ; Thu, 10 Feb 2011 11:03:30 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 0B5D73A6987 for ; Thu, 10 Feb 2011 11:03:30 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoBAInFU02rR7Hu/2dsb2JhbACXDz+BJox4c58Bmz+FXASFAQ X-IronPort-AV: E=Sophos;i="4.60,451,1291593600"; d="scan'208";a="308994232" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 10 Feb 2011 19:03:43 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1AJ3ggx011499; Thu, 10 Feb 2011 19:03:42 GMT From: "Dan Wing" To: References: Your message of Thu, 10 Feb 2011 08:58:36 PST. <0ba001cbc943$c2355ce0$46a016a0$@com> <201102101813.p1AIDVXo087539@givry.fdupont.fr> In-Reply-To: <201102101813.p1AIDVXo087539@givry.fdupont.fr> Date: Thu, 10 Feb 2011 11:03:42 -0800 Message-ID: <0c6c01cbc955$3c406f50$b4c14df0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvJTj99qHYMxKA1TGu2DioPS6KRPgABuj6Q Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 19:03:31 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Thursday, February 10, 2011 10:14 AM > To: Dan Wing > Cc: 'Reinaldo Penno'; pcp@ietf.org > Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP > address as dynamic mappings > > > In your previous mail you wrote: > > > And to answer to the question, yes it breaks applications. > > Name one. > > => NAT based load balancers and in general internally distributed > applications (but the question should be sent to the behave WG > mailing list). NAT based load balancers, in front of servers, such as an HTTP server?? -d > Regards > > Francis.Dupont@fdupont.fr > > PS: note someone who worked at that time for a huge ISP really > insisted about this point, so I expect you'll get more/better > arguments from people using CGNs (which is not my case :-). From Francis.Dupont@fdupont.fr Thu Feb 10 11:08:44 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D25953A67D1 for ; Thu, 10 Feb 2011 11:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50XXW2mfaClb for ; Thu, 10 Feb 2011 11:08:44 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id B44893A67A4 for ; Thu, 10 Feb 2011 11:08:43 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1AJ8tSU090967; Thu, 10 Feb 2011 20:08:55 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102101908.p1AJ8tSU090967@givry.fdupont.fr> From: Francis Dupont To: Reinaldo Penno In-reply-to: Your message of Thu, 10 Feb 2011 12:50:47 EST. Date: Thu, 10 Feb 2011 20:08:55 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "pcp@ietf.org" Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 19:08:44 -0000 In your previous mail you wrote: This is just a circuit/billing relationship. ^^^^^^^ => it is enough for me (and it should be enough for any for-profit ISP too :-) We should not extrapolate the addressing relationship from this. => we apply the behave requirement which says a subscriber should get an unique external address. (of course the opposite is not true: an external address can be (and will be) shared between several subscribers. There are home subscribers with fixed IPv4(s), dynamic, with a bridge device that go through a single layer of NAT (CGN in the network); not to mention SOHO and Enterprise. They can all go trough the same CGN. => this is a subscriber-ID issue. IMHO as soon as there is a reliable one it is fine. Note without a reliable subscriber-ID the provided service is for free (:-). I think maybe the issue is that in the paragraph below should substitute 'subscriber' by 'PCP Client or third-party device' " The MAP OpCodes require subscriber identification because they allocate resources or adjust resources allocated to a subscriber." => I should not have the same interpretation of the term resources as this text seems fine for me. It seems natural this change since if we are talking about resources, certainly different hosts/PCP Clients within a 'subscriber' (billing relationship) can ask for different resources. => I can't follow your logic. What does really matter is the billing and there is an one-to-one relationship between bills and subscribers. Regards Francis.Dupont@fdupont.fr PS: draft-ietf-behave-lsn-requirements-00 uses the term CPE in place of subscriber. IMHO we are better for the reasons I explained but what is the opinion? From rpenno@juniper.net Thu Feb 10 11:20:05 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE3243A67E4 for ; Thu, 10 Feb 2011 11:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eblzBh9A6LYx for ; Thu, 10 Feb 2011 11:20:04 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id C806F3A67A4 for ; Thu, 10 Feb 2011 11:20:02 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTVQ6b/pusQd5pHl2iHmrp4hD4c64QIxW@postini.com; Thu, 10 Feb 2011 11:20:17 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 10 Feb 2011 11:19:08 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 10 Feb 2011 14:19:20 -0500 From: Reinaldo Penno To: Francis Dupont , "pcp@ietf.org" Date: Thu, 10 Feb 2011 14:19:17 -0500 Thread-Topic: [pcp] updated security model Thread-Index: AcvJRqc5anproVxWRLyBy9eAlpoS7QAEMG37 Message-ID: In-Reply-To: <201102101719.p1AHJCEI084150@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] updated security model X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 19:20:05 -0000 I do not think we can throw security concerns that have requirements built into them without a reasonable discussion of how ISPs can or should meet them.=20 If you want just to flag some security issues that is fine but saying '...i= s required' needs more discussion. A PCP Server by itself does not know how t= o map a subscriber to IP address(es). If you are requiring this then there is an implicit mandate for a PCP Server to hook into the ISP's subscriber database.=20 Let's take the case of DS-Lite where a B4(CPE) sends requests to a PCP Server: If the CPE gets a delegated /56 there is nothing that says which IPv6 address should be used to establish the tunnel. There is nothing that says that the CPE can (or not) after some time switch to another IPv6 and swap tunnels. And there is nothing precluding a CPE from having more than one tunnel. An ISP might (or not) have a policy in place but that is an enforcement issue. Therefore, we can mandate that PCP messages use the same source IPv6 addres= s of the tunnel but this address can change dynamically and even if after reboot the CPE gets the same exact delegated /56. Thanks, Reinaldo On 2/10/11 9:19 AM, "Francis Dupont" wrote: >between subscribers: > - a subscriber is not authorized to manage explicit dynamic mappings > on the behalf of another subscriber. So the PCP server of a CGN is > required to check the subscriber identity (typically the HG address > on the infrastructure). >... > These have some direct consequences: > - scenarios with subscribers require a per subscriber authentication. > (this is for scenarios with subscribers other than DS-Lite and NAT444) From dwing@cisco.com Thu Feb 10 11:22:31 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09353A69CA for ; Thu, 10 Feb 2011 11:22:31 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Nh-p77d8Kfs for ; Thu, 10 Feb 2011 11:22:30 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 5E20C3A686A for ; Thu, 10 Feb 2011 11:22:30 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwBAC/JU02rR7H+/2dsb2JhbACXDYFljHhznwSbQIVcBIUB X-IronPort-AV: E=Sophos;i="4.60,451,1291593600"; d="scan'208";a="260917748" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 10 Feb 2011 19:22:43 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1AJMg1Y014024; Thu, 10 Feb 2011 19:22:42 GMT From: "Dan Wing" To: References: Your message of Thu, 10 Feb 2011 08:57:31 PST. <0b9f01cbc943$9b38bdd0$d1aa3970$@com> <201102101758.p1AHwI38086504@givry.fdupont.fr> In-Reply-To: <201102101758.p1AHwI38086504@givry.fdupont.fr> Date: Thu, 10 Feb 2011 11:22:42 -0800 Message-ID: <0c8b01cbc957$e3d9ca70$ab8d5f50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvJTCektS93GNbPRYu68Ro2At2XowAAB9gw Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] brief review of base-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 19:22:31 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Thursday, February 10, 2011 9:58 AM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] brief review of base-04 > > > In your previous mail you wrote: > > > => I don't see these advantages nor a discussion of this > > major change in the list. > > Then, let's start with the agreement that this is the > discussion. > > => it is a formal point: the discussion is supposed to happen > before, not after. BTW this is not your responsability, > it is chairs' one. > > Nothing is cast in stone; this is an I-D. I am trying my > best to simplify the protocol based on 100s of emails and > and discussions. And I do make mistakes. > > => yes as a human you can make mistakes and don't like to > go backward (:-). > > > > already exists as a static mapping will return a successful > > > result, confirming that the requested mapping exists." > > > > > > With which assigned lifetime? > > > > With the lifetime the PCP server wants to use. Typically, > > the PCP server would extend the lifetime based on the > > requested-lifetime. Does this need to be spelled out in > > this example?? > > > > => I can't parse your answer: we are talking about *static* > > mappings so they have by definition infinite lifetimes. > > I do not understand the purpose of discussing static mappings > (created with a CLI) and how/why they affect PCP or how/why > they affect implicit dynamic mappings (e.g., TCP SYN). > > => IMHO the only question is whether they are manageabled by PCP > and IMHO again the answer should be 'no'. > > Is there an application or a protocol that breaks if they get > assigned different public IP addresses? > > => yes, this is why the behave WG produces a requirement saying > all mappings of the same subscriber must get the same external > address. BEHAVE only says the implicit dynamic mappings need to be on the same public IP address. I expect PCP needs to also have its explicit dynamic mappings on that same public IP address. > I can see where > PCP and implicit dynamic mappings need to be on the same > public IP address. But I don't see a similar need for > static mappings (created with a CLI) to be on the same > public address. > > => explicit dynamic mappings and static mappings are not so > different: they are two kinds of port forwarding. I don't see how we can do anything more than "SHOULD be the same", though. Afterall, PCP is not defining how static (CLI) mappings are done. > And I don't believe the PCP specification > can create such a rule, either; obviously the PCP > specification can't create a rule that implicit dynamic > mappings and static mappings have to be on the same public > IP address, because PCP is only defining PCP and can only > define rules for itself. > > => I plainly agree: the PCP specs should only refer to > behave WG documents. > > > > Does this work too for deletion? > > > > Yes, section 8.4 says: > > > > " If the PCP client attempts to delete a mapping that > > does not exist, the success response code is returned." > > > > => in this text the 'a mapping' is 'an explicit dynamic > > mapping' so what happens when a request is received > > for the deletion of a static mapping? > > Static mappings can't be deleted by PCP. That is the > purpose of the UNABLE_TO_DELETE_ALL result code: > > "If the PCP client attempts to delete > a port mapping which was manually assigned by some kind of > configuration tool, the PCP server MUST respond with > UNABLE_TO_DELETE_ALL result code, but the other fields are > encoded as > described above." > > => hum, IMHO the wording should be changed to 'a not explicit > dynamic mapping' so it will be clear a PCP delete works only > on PCP created mappings. BTW this can lead some implementations > to return this result code for any not specific delete request > but I can't see why it should be an issue. How is this: PCP MAP requests only control mappings created by MAP requests. So, f the PCP client attempts to delete a static port mapping (i.e., a mapping created outside of PCP itself), the PCP server deletes all of the PCP-created mappings but MUST respond with UNABLE_TO_DELETE_ALL result code, with the other fields encoded as described above. > > => spoofed SERVER_OVERLOADED with silly retry values. > > That concern is not unique to SERVER_OVERLOADED, is it? > > => not unique but SERVER_OVERLOADED has no justification. Ok. Let's separate the two problems. I do agree that the PCP server can simply discard PCP messages if it's too busy. The expectation of SERVER_OVERLOADED is similar to IP's ECN (early congestion notification), to provide back-pressure *before* the server is completely overloaded. Of course once completely overloaded, it is cheaper (less processing) to discard packets rather than generate a SERVER_OVERLOADED response. > > => oops, what I tried to suggest is to change the length from > > 'one only' to 'equal or greater than one'. > > I understand that was your suggestion. But this gets risky, because > (a) this is an error condition, and we all know that error paths > in code are never as well-tested as success paths, (b) this error > condition would be the only PCP option defined in the base > protocol that can occur multiple times, > > => (b) is another way to handle more than 4 unsupported options. > It is a matter of taste. > > > I do not see anything that PCP can do about an ISP renumbering > a > > subscriber and the related mis-direction of traffic to the > > subscriber's > > old IP address. > > > > => we could say it is a major security problem. > > But ISP renumbering is not unique to PCP (PCP doesn't cause the > renumbering), and ISP renumbering is not made worse because of > the existence of PCP (nor is ISP renumbering made worse because > of the existence of a CGN or a firewall). > > => we have a rule in France: you opened the wine bottle, now you have > to drink it. So as you consider this problem you should not stop > at its bad operational consequences, but to its even worse security > consequences. BTW a reference to the security considerations should > be enough (of course *improved* security considerations). Yes. And I hope to work security considerations today. > And you'd like it to be a SHOULD NOT? It _does_ result in > inefficient > operation, and I can certainly see how a CGN would want to deprecate > (not support) that option in the future, because a requested-for > port > simply cannot be forced (it will already be used by another > subscriber). > > => I use it for renewals and I'll continue to use it in this case, > so I don't really care... > BTW it is easy to support in a CGN and the fact it doesn't work in the > real world is not the CGN programmer fault (I know we agree about this > point). > > > => I still don't know what is "its configured maximum lifetime > value". > > A CLI setting, a #define'd value, or so on. > > => so it is a new and PCP specific NAT property. Not at all. Every NAPT, today, has a configured maximum lifetime value. -d > Regards > > Francis.Dupont@fdupont.fr > > PS: I sent three large messages to the list: > - a counter-proposal for the internal address issue > > - another one about errors > > - an updated version of the security model From rpenno@juniper.net Thu Feb 10 11:24:12 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9A1D3A686A for ; Thu, 10 Feb 2011 11:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+Q5-9ilZDfh for ; Thu, 10 Feb 2011 11:24:09 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 01D763A69DA for ; Thu, 10 Feb 2011 11:24:06 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTVQ7Y6lSg2MSmcpEWRyZS8RHlzx5w0mA@postini.com; Thu, 10 Feb 2011 11:24:21 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 10 Feb 2011 11:23:54 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 10 Feb 2011 14:24:06 -0500 From: Reinaldo Penno To: Francis Dupont Date: Thu, 10 Feb 2011 14:24:05 -0500 Thread-Topic: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings Thread-Index: AcvJVgcsRA7CWdySSnmZzxvqRCMboQAAg1py Message-ID: In-Reply-To: <201102101908.p1AJ8tSU090967@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 19:24:12 -0000 The LSN requirements document? This document will evolve considerably and this discussion is very relevant to it. If it the document refers to CPE and the CPE is bridged and each host gets it own address how can this be enforced? Again, there is implicit assumptio= n of two layers of NAT and furthermore that the first layer has just one address and second has a single address assigned to the first layer. PCP can state those assumptions or can ask BEHAVE to clarify them. On 2/10/11 11:08 AM, "Francis Dupont" wrote: > =3D> we apply the behave requirement which says a subscriber > should get an unique external address. (of course the opposite > is not true: an external address can be (and will be) shared > between several subscribers. From dwing@cisco.com Thu Feb 10 12:06:33 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AECB3A6A6A for ; Thu, 10 Feb 2011 12:06:33 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBg+n2pVCW1Z for ; Thu, 10 Feb 2011 12:06:32 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 837A93A69E4 for ; Thu, 10 Feb 2011 12:06:32 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwBAH7UU02rR7Hu/2dsb2JhbACXDYFljHhznxmbOYVcBIUBjEI X-IronPort-AV: E=Sophos;i="4.60,451,1291593600"; d="scan'208";a="661635937" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 10 Feb 2011 20:06:45 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1AK6icQ008805; Thu, 10 Feb 2011 20:06:45 GMT From: "Dan Wing" To: "'Francis Dupont'" , References: <201102101851.p1AIp37f089780@givry.fdupont.fr> In-Reply-To: <201102101851.p1AIp37f089780@givry.fdupont.fr> Date: Thu, 10 Feb 2011 12:06:44 -0800 Message-ID: <0cbd01cbc95e$0adff7b0$209fe710$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvJU4KNKCb+cMk7Qq2bS4WZq1KU2AACklhw Content-Language: en-us Subject: Re: [pcp] an idea about REMOTE_PEER_FILTER X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 20:06:33 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Francis Dupont > Sent: Thursday, February 10, 2011 10:51 AM > To: pcp@ietf.org > Subject: [pcp] an idea about REMOTE_PEER_FILTER > > We have still some open issues about REMOTE_PEER_FILTER > and as it won't be moved to another document we have > to address them to make the base document complete. > > (BTW in base-04 figure 1 28 -> 128) > > It seems we agree MAP request with a match-all > (i.e., zero prefix length and remote peer IP address) > REMOTE_PEER_FILTER option should remove all filters. > > Now we need a way to remove one filter, ideas: > - authorize multiple options: the first one > is a match-all (i.e., a reset), > followed by all wanted filters. > > As a request is atomic, this can work if > the number of filters stays small. > > - extend the delete operation to delete > the filter when there is a filter option. > Seems a bit fragile, i.e., I prefer the previous one. > > - others? > > Note we need a 'too many filters' result code anyway. > > Regards > > Francis.Dupont@fdupont.fr > > PS: it is strongly related to the ticket #10. I like that idea. Here is the text which I believe captures what you describe above: 8.5.2. REMOTE_PEER_FILTER This Option indicates packet filtering is desired. The remote peer port and remote peer IP Address indicate the permitted remote peer's source IP address and port for packets from the Internet. The remote peer prefix length indicates the length of the remote peer's IP address that is significant; this allows a single Option to permit an entire subnet. After processing this MAP request and generating a successful response, the PCP-controlled device will simply drop packets with a source IP address, transport, or port that do not match the fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | prefix-length | Remote Peer Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Remote Peer IP address (32 bits if MAP4, : : 1 28 bits if MAP6) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ These fields are described below: Reserved: 8 reserved bits, MUST be sent as 0 and MUST be ignored when received. prefix-length: indicates how many bits of the IPv4 or IPv6 address are relevant for this filter. The value 0 indicates "no filter", and will remove all previous filters. See below for detail. Remote Peer Port: the port number of the remote peer. The value 0 indicates "all ports" Remote Peer IP address: The IP address of the remote peer. This Option: name: REMOTE_PEER_FILTER number: 128 is valid for OpCodes: MAP4, MAP6 is included in responses: MUST, if it appeared in the request. length: 2 if used with MAP4, 5 if used with MAP6 may appear in: requests maximum occurrences: as many as fit within maximum PCP message size Because of interactions with dynamic ports this Option MUST only be used by a client that is operating a server (that is, using the MAP OpCode), as this ensures that no other application will be assigned the same ephemeral port for its outgoing connection. Other use by a PCP client is NOT RECOMMENDED and will cause some UNSAF NAT traversal mechanisms [RFC3424] to fail where they would have otherwise succeeded, breaking other applications running on this same host. The prefix-length indicates how many bits of the IPv6 address or IPv4 address are used for the filter. For MAP4, a prefix-length of 32 indicates the entire IPv4 address is used. For MAP6, a prefix-length of 128 indicates the entire IPv6 address is used. For MAP4 the minimum prefix-length value is 0 and the maximum value is 32. For MAP6 the minimum prefix-length value is 0 and the maximum value is 128. Values outside those range cause an MALFORMED_OPTION response code. If multiple occurrences of REMOTE_PEER_FILTER exist, they are processed in the same order received. To remove all existing filters, the prefix-length 0 is used. To change an existing filter, the PCP client sends a MAP request containing two REMOTE_PEER_FILTER options, the first option containing a prefix-length of 0 (to delete all existing filters) and the second containing the new remote peer's IP address and port. To allow an additional remote peer to an existing filtered mapping, a new MAP request is sent with the REMOTE_PEER_FILTER. The PCP server or the PCP-controlled device is expected to have a limit on the number of remote peers it can support. This limit might be as small as one. If a MAP request would exceed this limit, the entire MAP request is rejected with the result code EXCESSIVE_FILTERS, and the state on the PCP server is unchanged. [Ed. Note: If a filter is created, and minutes later a normal MAP refresh occurs, do we want an indication in the response that there is some filtering?? Seems useful. Of course, there might be so many filters that we can't list them all in the response. So perhaps just an indication?] -d From rpenno@juniper.net Thu Feb 10 13:29:12 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D172C3A6A8F for ; Thu, 10 Feb 2011 13:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4S-Pj1qJdoLZ for ; Thu, 10 Feb 2011 13:29:10 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 0D7613A6A25 for ; Thu, 10 Feb 2011 13:29:07 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTVRYsAOlZbcodGasub5GPX7Dkpe6fYyp@postini.com; Thu, 10 Feb 2011 13:29:23 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 10 Feb 2011 13:26:51 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 10 Feb 2011 16:27:03 -0500 From: Reinaldo Penno To: Dan Wing , 'Francis Dupont' , "pcp@ietf.org" Date: Thu, 10 Feb 2011 16:27:01 -0500 Thread-Topic: [pcp] an idea about REMOTE_PEER_FILTER Thread-Index: AcvJU4KNKCb+cMk7Qq2bS4WZq1KU2AACklhwAALdRk8= Message-ID: In-Reply-To: <0cbd01cbc95e$0adff7b0$209fe710$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] an idea about REMOTE_PEER_FILTER X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 21:29:12 -0000 I think most of it is okay. I'm a little uneasy with prefix length 0 meanin= g delete if without any prefixes and meaning change with prefixes. These overloading semantics are usually not very good in the long run. For example, if I receive a message with prefix length 0 I would ignore the rest of the message and delete everything. But now, depending on what comes later in the packet I need to make a decision. But anyway, if others like it we can go with it. On 2/10/11 12:06 PM, "Dan Wing" wrote: > To change an existing filter, the PCP client sends a MAP request > containing two REMOTE_PEER_FILTER options, the first option > containing a prefix-length of 0 (to delete all existing filters) and > the second containing the new remote peer's IP address and port. To > allow an additional remote peer to an existing filtered mapping, a > new MAP request is sent with the REMOTE_PEER_FILTER. From Francis.Dupont@fdupont.fr Thu Feb 10 15:21:02 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E76E53A6A63 for ; Thu, 10 Feb 2011 15:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAvyUmIKt+ZV for ; Thu, 10 Feb 2011 15:21:01 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id BA0A83A6849 for ; Thu, 10 Feb 2011 15:21:00 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1ANLD3a006399; Fri, 11 Feb 2011 00:21:13 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102102321.p1ANLD3a006399@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Thu, 10 Feb 2011 11:03:05 PST. <0c5601cbc955$25d12de0$717389a0$@com> Date: Fri, 11 Feb 2011 00:21:13 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] proposal about internal addresses X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 23:21:03 -0000 In your previous mail you wrote: There has not been a meaning for all-zero in the internal IP address. => delete all subscriber mapping. > I thought about a magic value too but I couldn't find > something which is not ambiguous or already used or > painful to use (e.g., 0xff...ff). So I consider now > a helper function. Yes, and that sort of thinking is exactly what led me towards a separate THIRD_PARTY option. => but my argument is the problem is an API problem so the solution should not be in the protocol. > This, I believe, provides the simplicity for the PCP client > implementation. > > => in fact not (and not at all for IPv6), I don't see how it makes IPv6 worse. Maybe you could elaborate. => a recurrent issue with IPv6 is an interface has more than one address so with Murphy's help you never get the address you expect. So it is very usual to explicitly bind() an active socket to just be sure the right address is used with IPv6, and this is more complex than to fill an internal address field. At the next IETF I'll get 15 year old experience in writing IPv6 applications... > and the simplicity should come from the API. Well, someone is writing that API -- either someone at Apple or Microsoft for their respective frameworks. And if an application is running without a framework underneath it, someone will code PCP from scratch. => a PCP client API is part of my PCP work. > That seems acceptable to me. > > => so as we have solved the simplicity and the number of OpCode > issues is there another good reason to not come back to the > internal address in the OpCode? I'm fine to eliminate THIRD_PARTY. But only if we can figure out a way for the 'internal-ip-address' to carry an indication that it to be ignored -- this allows the PCP client to simply be a UDP client application. => this is a requirement to put on the API (a loose requirement as API considerations are only in section 7 examples). Otherwise, it needs to bind to a specific interface or needs to figure out which interface its packet will egress. Obviously, obviously, that is not impossible. But it complicates the PCP client, could be implemented wrong, and provides no additional function to the protocol. => this has to be handled by the API (it is a part of the high level character of the API :-). For instance in my API I have an option for a sockaddr source and as I explained I'll add a fill the internal address field in the request template helper function the next time I'll edit the corresponding files (.h, .c and .docbook)... Regards Francis.Dupont@fdupont.fr From dwing@cisco.com Thu Feb 10 15:31:24 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D53F3A6B04 for ; Thu, 10 Feb 2011 15:31:24 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJt7zFoUF36R for ; Thu, 10 Feb 2011 15:31:23 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 543E73A6AFD for ; Thu, 10 Feb 2011 15:31:23 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQBAA0EVE2rR7H+/2dsb2JhbACXEoFljHhzoEubLYVcBIUBjEM X-IronPort-AV: E=Sophos;i="4.60,452,1291593600"; d="scan'208";a="258349397" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 10 Feb 2011 23:31:36 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1ANVarj014052; Thu, 10 Feb 2011 23:31:36 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , "'Francis Dupont'" , References: <0cbd01cbc95e$0adff7b0$209fe710$@com> In-Reply-To: Date: Thu, 10 Feb 2011 15:31:36 -0800 Message-ID: <0d4b01cbc97a$a8d474c0$fa7d5e40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvJU4KNKCb+cMk7Qq2bS4WZq1KU2AACklhwAALdRk8ABECRYA== Content-Language: en-us Subject: Re: [pcp] an idea about REMOTE_PEER_FILTER X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 23:31:24 -0000 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, February 10, 2011 1:27 PM > To: Dan Wing; 'Francis Dupont'; pcp@ietf.org > Subject: Re: [pcp] an idea about REMOTE_PEER_FILTER > > I think most of it is okay. I'm a little uneasy with prefix length 0 > meaning > delete if without any prefixes and meaning change with prefixes. These > overloading semantics are usually not very good in the long run. If the prefix length is zero, it really isn't overloading anything -- just like lifetime=0 really isn't overloading anything. Consider, for example, an IPv4 address with a prefix length of 32. That means the entire IPv4 address is the filter. A prefix length of 24 means only the first 24 bits ("Class C") are part of the filter. A prefix length of 0 means that none of the bits are part of the filter. That can have only one meaning: you don't want any filter. > For example, if I receive a message with prefix length 0 I would ignore > the > rest of the message and delete everything. The text says the options are processed in order. Which means if there are two options, the first doing a delete (prefix-length=0) and the second adding a filter, then the existing filter(s) are all removed and replaced with the new filter. > But now, depending on what comes > later in the packet I need to make a decision. "Decision" means it isn't specific enough (that is, the text is too vague). I don't see where the server decides anything, or the meaning is unclear. If there is something, please point it out. -d > But anyway, if others like it we can go with it. > > > On 2/10/11 12:06 PM, "Dan Wing" wrote: > > > To change an existing filter, the PCP client sends a MAP request > > containing two REMOTE_PEER_FILTER options, the first option > > containing a prefix-length of 0 (to delete all existing filters) > and > > the second containing the new remote peer's IP address and port. > To > > allow an additional remote peer to an existing filtered mapping, a > > new MAP request is sent with the REMOTE_PEER_FILTER. From rpenno@juniper.net Thu Feb 10 15:49:07 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533B63A6ADC for ; Thu, 10 Feb 2011 15:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77-6D7uKUXCZ for ; Thu, 10 Feb 2011 15:49:06 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 574713A6B02 for ; Thu, 10 Feb 2011 15:49:04 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTVR5fSW0iGq0RQbDksIjdb9BQnjhkjFu@postini.com; Thu, 10 Feb 2011 15:49:19 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 10 Feb 2011 15:47:47 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 10 Feb 2011 18:48:00 -0500 From: Reinaldo Penno To: Dan Wing , 'Francis Dupont' , "pcp@ietf.org" Date: Thu, 10 Feb 2011 18:47:57 -0500 Thread-Topic: [pcp] an idea about REMOTE_PEER_FILTER Thread-Index: AcvJU4KNKCb+cMk7Qq2bS4WZq1KU2AACklhwAALdRk8ABECRYAAAq3oW Message-ID: In-Reply-To: <0d4b01cbc97a$a8d474c0$fa7d5e40$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] an idea about REMOTE_PEER_FILTER X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 23:49:07 -0000 Ohh, this isn't really a 'change' as in an incremental update. This means that if I want to add to the filter a single subnet I need to insert in the message a delete plus all the existing subnets and the new subnet. If I want to delete a subnet it is a similar process. On 2/10/11 3:31 PM, "Dan Wing" wrote: > The text says the options are processed in order. Which means if > there are two options, the first doing a delete (prefix-length=3D0) > and the second adding a filter, then the existing filter(s) are > all removed and replaced with the new filter. From Francis.Dupont@fdupont.fr Thu Feb 10 15:53:38 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA9F53A6AF7 for ; Thu, 10 Feb 2011 15:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVUTA4VlB1LE for ; Thu, 10 Feb 2011 15:53:37 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 9BFE43A6ADC for ; Thu, 10 Feb 2011 15:53:37 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1ANro32008273; Fri, 11 Feb 2011 00:53:50 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102102353.p1ANro32008273@givry.fdupont.fr> From: Francis Dupont To: Reinaldo Penno In-reply-to: Your message of Thu, 10 Feb 2011 14:19:17 EST. Date: Fri, 11 Feb 2011 00:53:50 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "pcp@ietf.org" Subject: Re: [pcp] updated security model X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 23:53:39 -0000 In your previous mail you wrote: I do not think we can throw security concerns that have requirements built into them without a reasonable discussion of how ISPs can or should meet them. => I have a concern about the word 'throw' but I can't believe you mean 'throw away': clearly it is the opposite. BTW requirements are not gratuitous: they follow the usual security logic: there is a threat, the threat is not acceptable, a counter-measure to the threat is to do xxx, in the context the threat applies xxx is required. If you want just to flag some security issues that is fine but saying '...is required' needs more discussion. => I agree but this means to find a way to break the logic chain I've just explained. A PCP Server by itself does not know how to map a subscriber to IP address(es). => the subscriber-ID doesn't need to be an address but in scenarios where there are subscribers a reliable subscriber-ID is required (and not only for pure security, as I explained it is first required for billing). Now in the two scenarios I detailed because I know them well the subscriber-ID is an address. If you are requiring this then there is an implicit mandate for a PCP Server to hook into the ISP's subscriber database. => this is the next step: pure security doesn't mandate this because it is enough to identify subscribers between them, i.e., to implement the "same subscriber" function. But I agree a hook to the subscriber DB helps advanded features, different per subscriber services for instance, or subscriber renumbering when the subscriber-ID is an address. Let's take the case of DS-Lite where a B4(CPE) sends requests to a PCP Server: If the CPE gets a delegated /56 there is nothing that says which IPv6 address should be used to establish the tunnel. There is nothing that says that the CPE can (or not) after some time switch to another IPv6 and swap tunnels. And there is nothing precluding a CPE from having more than one tunnel. => in this case (which implicitly use the plain mode) you have two choices: - you don't matter if the PCP client is really the B4 and the subscriber-ID is the /56 - you don't want to be flexible and you require one address (and one tunnel) In fact it is bound to the way the B4 gets its IPv6 address: if one address is assigned to it then it makes sense to require the B4 to use it. An ISP might (or not) have a policy in place but that is an enforcement issue. Therefore, we can mandate that PCP messages use the same source IPv6 address of the tunnel but this address can change dynamically and even if after reboot the CPE gets the same exact delegated /56. => the recommended (but not enforced) way for the B4 is to use DHCPv6 to get its IPv6 addresses and a prefix for the home network. In this case you get a stable IPv6 address you can enforce. > These have some direct consequences: > - scenarios with subscribers require a per subscriber authentication. > (this is for scenarios with subscribers other than DS-Lite and NAT444) => I considered the issue as solved for DS-Lite and NAT444, and as opened for scenarios I don't know well or I don't know yet. Now what is your concern: the requirement itself, the definition of the term subscriber, or the ways to meet the requirement? Regards Francis.Dupont@fdupont.fr PS: note there likely are some scenarios where in fact strong mutual authentication between the subscriber CPE and the PCP server is required. At least the insecure infrastructure case is an example. From dwing@cisco.com Thu Feb 10 16:20:57 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3CD33A6AF1 for ; Thu, 10 Feb 2011 16:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.237 X-Spam-Level: X-Spam-Status: No, score=-110.237 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHBfZx6dYBeM for ; Thu, 10 Feb 2011 16:20:56 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D0C5F3A67D4 for ; Thu, 10 Feb 2011 16:20:56 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQBAMQPVE2rRN+J/2dsb2JhbACXEoFljHhzoGWbLoVcBIUBjEM X-IronPort-AV: E=Sophos;i="4.60,452,1291593600"; d="scan'208";a="406882623" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 11 Feb 2011 00:21:10 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p1B0LAWu016644; Fri, 11 Feb 2011 00:21:10 GMT From: "Dan Wing" To: "'Reinaldo Penno'" , "'Francis Dupont'" , References: <0d4b01cbc97a$a8d474c0$fa7d5e40$@com> In-Reply-To: Date: Thu, 10 Feb 2011 16:21:09 -0800 Message-ID: <0d9001cbc981$954592c0$bfd0b840$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvJU4KNKCb+cMk7Qq2bS4WZq1KU2AACklhwAALdRk8ABECRYAAAq3oWAADLxfA= Content-Language: en-us Subject: Re: [pcp] an idea about REMOTE_PEER_FILTER X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 00:20:57 -0000 > -----Original Message----- > From: Reinaldo Penno [mailto:rpenno@juniper.net] > Sent: Thursday, February 10, 2011 3:48 PM > To: Dan Wing; 'Francis Dupont'; pcp@ietf.org > Subject: Re: [pcp] an idea about REMOTE_PEER_FILTER > > Ohh, this isn't really a 'change' as in an incremental update. Correct. Each additional REMOTE_PEER_FILTER adds an additional permission (remote peer). So for example if the initial MAP request does not contain REMOTE_PEER_FILTER, then anything on the Internet can send traffic. If the initial MAP request (or a subsequent MAP request) contains REMOTE_PEER_FILTER, then all traffic *except* that indicated remote peer is filtered. Sending more REMOTE_PEER_FILTERS adds more remote peers. > This means > that if I want to add to the filter a single subnet I need to insert in > the message a delete plus all the existing subnets and the new subnet. Correct. > If I want to delete a subnet it is a similar process. Correct. This seems reasonable to me; I don't see a need for a bunch of these filters, or for them to be changed too often. If so, we should come up with a better way to delete them. But this is pretty straight forward and provides a reasonable amount of flexibility. -d > > > On 2/10/11 3:31 PM, "Dan Wing" wrote: > > > The text says the options are processed in order. Which means if > > there are two options, the first doing a delete (prefix-length=0) > > and the second adding a filter, then the existing filter(s) are > > all removed and replaced with the new filter. From Francis.Dupont@fdupont.fr Thu Feb 10 16:25:20 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EC773A6813 for ; Thu, 10 Feb 2011 16:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9DZ6gx7laaR for ; Thu, 10 Feb 2011 16:25:19 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 09E323A6B16 for ; Thu, 10 Feb 2011 16:25:18 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1B0PWWF010308; Fri, 11 Feb 2011 01:25:32 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102110025.p1B0PWWF010308@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Thu, 10 Feb 2011 11:22:42 PST. <0c8b01cbc957$e3d9ca70$ab8d5f50$@com> Date: Fri, 11 Feb 2011 01:25:32 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] brief review of base-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 00:25:20 -0000 In your previous mail you wrote: BEHAVE only says the implicit dynamic mappings need to be on the same public IP address. => BEHAVE says: "REQ-1: A LSN MUST allocate one external IP address to each CPE." i.e., there is nothing explicit which limits the requirement to a particular mapping type. I expect PCP needs to also have its explicit dynamic mappings on that same public IP address. => I agree and we should refer to BEHAVE as this is not in the PCP WG scope. > => explicit dynamic mappings and static mappings are not so > different: they are two kinds of port forwarding. I don't see how we can do anything more than "SHOULD be the same", though. Afterall, PCP is not defining how static (CLI) mappings are done. => we can refer to the BEHAVE MUST and apply it to all mappings. Of course it should be fine to check with the BEHAVE WG too. > => hum, IMHO the wording should be changed to 'a not explicit > dynamic mapping' so it will be clear a PCP delete works only > on PCP created mappings. BTW this can lead some implementations > to return this result code for any not specific delete request > but I can't see why it should be an issue. How is this: PCP MAP requests only control mappings created by MAP requests. So, f the PCP client ^i attempts to delete a static port mapping (i.e., a mapping created outside of PCP itself), the PCP server deletes all of the PCP-created mappings but MUST respond with UNABLE_TO_DELETE_ALL result code, with the other fields encoded as described above. => it is in the section >= 3 so the word 'port' is not needed. But my suggestion was not to apply this to static mappings but to all not explicit dynamic mapping, i.e., what is inside the parentheses. > > => spoofed SERVER_OVERLOADED with silly retry values. > > That concern is not unique to SERVER_OVERLOADED, is it? > > => not unique but SERVER_OVERLOADED has no justification. Ok. Let's separate the two problems. I do agree that the PCP server can simply discard PCP messages if it's too busy. The expectation of SERVER_OVERLOADED is similar to IP's ECN (early congestion notification), => no, it is similar to the source quench ICMP. to provide back-pressure *before* the server is completely overloaded. Of course once completely overloaded, it is cheaper (less processing) to discard packets rather than generate a SERVER_OVERLOADED response. => when we discussed the ticket #11, there was a consensus to not introduce a flow control mechanism. So you have to reopen #11 first... > > => I still don't know what is "its configured maximum > lifetime value". > > A CLI setting, a #define'd value, or so on. > > => so it is a new and PCP specific NAT property. Not at all. Every NAPT, today, has a configured maximum lifetime value. => they have many, one per condition, for instance my AFTR has 5 different configured maximum lifetimes... so I have nothing against a 6th one (:-). Regards Francis.Dupont@fdupont.fr PS: UDP, ICMP echo, TCP (opening, open, closing). And I don't count fragment and hold down. BTW I don't believe you want the open TCP one even it is usually the largest because it would be simpler to send a TCP probe. From dwing@cisco.com Thu Feb 10 16:27:41 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC17B3A6B24 for ; Thu, 10 Feb 2011 16:27:41 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eo+BYC3fdl3L for ; Thu, 10 Feb 2011 16:27:40 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B4C2E3A6A70 for ; Thu, 10 Feb 2011 16:27:40 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQBAGoRVE2rR7Ht/2dsb2JhbACXEoFljHhzoGubLoVcBIUB X-IronPort-AV: E=Sophos;i="4.60,452,1291593600"; d="scan'208";a="661675574" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 11 Feb 2011 00:27:54 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1B0Rrjh008709; Fri, 11 Feb 2011 00:27:54 GMT From: "Dan Wing" To: References: Your message of Thu, 10 Feb 2011 11:03:05 PST. <0c5601cbc955$25d12de0$717389a0$@com> <201102102321.p1ANLD3a006399@givry.fdupont.fr> In-Reply-To: <201102102321.p1ANLD3a006399@givry.fdupont.fr> Date: Thu, 10 Feb 2011 16:27:53 -0800 Message-ID: <0d9201cbc982$85f887e0$91e997a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvJeTxLLDuUfjjfRcaWR6p0A3aPxQACHv4A Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] proposal about internal addresses X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 00:27:41 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Thursday, February 10, 2011 3:21 PM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] proposal about internal addresses > > > In your previous mail you wrote: > > There has not been a meaning for all-zero in the > internal IP address. > > => delete all subscriber mapping. You're right. Thanks. I had forgotten that. I see that I missed editing text about it when adding THIRD_PARTY. > > I thought about a magic value too but I couldn't find > > something which is not ambiguous or already used or > > painful to use (e.g., 0xff...ff). So I consider now > > a helper function. > > Yes, and that sort of thinking is exactly what led me > towards a separate THIRD_PARTY option. > > => but my argument is the problem is an API problem > so the solution should not be in the protocol. > > > This, I believe, provides the simplicity for the PCP client > > implementation. > > > > => in fact not (and not at all for IPv6), > > I don't see how it makes IPv6 worse. Maybe you could elaborate. > > => a recurrent issue with IPv6 is an interface has more than > one address so with Murphy's help you never get the address > you expect. So it is very usual to explicitly bind() an > active socket to just be sure the right address is used with IPv6, > and this is more complex than to fill an internal address field. That internal address field has to *match* that source address. That is my worry. > At the next IETF I'll get 15 year old experience in writing IPv6 > applications... > > > and the simplicity should come from the API. > > Well, someone is writing that API -- either someone at Apple > or Microsoft for their respective frameworks. And if an > application is running without a framework underneath it, > someone will code PCP from scratch. > > => a PCP client API is part of my PCP work. > > > That seems acceptable to me. > > > > => so as we have solved the simplicity and the number of OpCode > > issues is there another good reason to not come back to the > > internal address in the OpCode? > > I'm fine to eliminate THIRD_PARTY. But only if we can figure > out a way for the 'internal-ip-address' to carry an indication > that it to be ignored -- this allows the PCP client to simply > be a UDP client application. > > => this is a requirement to put on the API (a loose requirement > as API considerations are only in section 7 examples). > > Otherwise, it needs to bind > to a specific interface or needs to figure out which interface > its packet will egress. Obviously, obviously, that is not > impossible. But it complicates the PCP client, could be > implemented wrong, and provides no additional function > to the protocol. > > => this has to be handled by the API (it is a part of > the high level character of the API :-). > > For instance in my API I have an option for a sockaddr source > and as I explained I'll add a fill the internal address field > in the request template helper function the next time I'll edit > the corresponding files (.h, .c and .docbook)... So, your confidence is high that everyone else implementing PCP will do this correctly, including multiple interfaces and (as you point out) multiple IPv6 addresses on one interface? And including properly using IPv6 privacy addresses (use them for ephemeral servers such as games or telephone calls, but not for long-lived servers such as the webcam running for years and years). I don't share that confidence. Removing this from the protocol means it *can't* be done wrong. Much of PCP is designed that way -- if it can't be done wrong, we eliminate test cases, and the associated human error. -d From Francis.Dupont@fdupont.fr Thu Feb 10 16:34:34 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19E713A6B25 for ; Thu, 10 Feb 2011 16:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASXxTInbWF+X for ; Thu, 10 Feb 2011 16:34:33 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id E87BC3A6B09 for ; Thu, 10 Feb 2011 16:34:32 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1B0YjHL010850; Fri, 11 Feb 2011 01:34:45 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102110034.p1B0YjHL010850@givry.fdupont.fr> From: Francis Dupont To: Reinaldo Penno In-reply-to: Your message of Thu, 10 Feb 2011 14:24:05 EST. Date: Fri, 11 Feb 2011 01:34:45 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "pcp@ietf.org" Subject: Re: [pcp] base #24 (closed): PCP mappings same public IP address as dynamic mappings X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 00:34:34 -0000 In your previous mail you wrote: The LSN requirements document? => yes, it replaces a document which is explicitly referenced by the DS-Lite I-D. This document will evolve considerably and this discussion is very relevant to it. => yes of course but it is a BEHAVE document. If it the document refers to CPE and the CPE is bridged and each host gets it own address how can this be enforced? => it doesn't matter as soon there is either no subscriber or a reliable subscriber-ID (the MAC address?). Again, there is implicit assumption of two layers of NAT and furthermore that the first layer has just one address and second has a single address assigned to the first layer. => I don't believe there is an implicit assumption for NAT444 but clearly NAT444 is in the scope and is expected to become a common way to deploy CGNs aka LSNs. PCP can state those assumptions or can ask BEHAVE to clarify them. => I am in favor of both: there should not be some implicit assumptions even if this limits the applicability of PCP today. Regards Francis.Dupont@fdupont.fr From rpenno@juniper.net Thu Feb 10 16:44:06 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33533A6B16 for ; Thu, 10 Feb 2011 16:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wahfY3SWr25H for ; Thu, 10 Feb 2011 16:44:05 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 6AE473A6823 for ; Thu, 10 Feb 2011 16:44:04 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTVSGYYiXM7toGEwEQoNnmJE0/iY6LvQf@postini.com; Thu, 10 Feb 2011 16:44:19 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 10 Feb 2011 16:42:57 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 10 Feb 2011 19:43:11 -0500 From: Reinaldo Penno To: Francis Dupont Date: Thu, 10 Feb 2011 19:43:09 -0500 Thread-Topic: [pcp] updated security model Thread-Index: AcvJfcbBI0k09L8DRhy3NKVPeAhUVgABuCNa Message-ID: In-Reply-To: <201102102353.p1ANro32008273@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] updated security model X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 00:44:07 -0000 On 2/10/11 3:53 PM, "Francis Dupont" wrote: > In your previous mail you wrote: >=20 > I do not think we can throw security concerns that have requirements b= uilt > into them without a reasonable discussion of how ISPs can or should me= et > them. > =20 > =3D> I have a concern about the word 'throw' but I can't believe you > mean 'throw away': clearly it is the opposite. Yes, of course. > BTW requirements are not gratuitous: they follow the usual security logic= : > there is a threat, the threat is not acceptable, I guess it depends who you ask. The trade-off between the operational of th= e whole solution and acceptable security risks need to be analyzed. > a counter-measure to > the threat is to do xxx, in the context the threat applies xxx is require= d. >=20 > If you want just to flag some security issues that is fine but saying > '...is > required' needs more discussion. >=20 > =3D> I agree but this means to find a way to break the logic chain > I've just explained. > > A PCP Server by itself does not know how to map a subscriber to IP > address(es). >=20 > =3D> the subscriber-ID doesn't need to be an address but in scenarios > where there are subscribers a reliable subscriber-ID is required > (and not only for pure security, as I explained it is first required > for billing). Now in the two scenarios I detailed because I know them > well the subscriber-ID is an address. >=20 > If you are requiring this then there is an implicit mandate for a > PCP Server to hook into the ISP's subscriber database. > =20 > =3D> this is the next step: pure security doesn't mandate this because > it is enough to identify subscribers between them, i.e., to implement > the "same subscriber" function. But I agree a hook to the subscriber > DB helps advanded features, different per subscriber services for instanc= e, > or subscriber renumbering when the subscriber-ID is an address. >=20 > Let's take the case of DS-Lite where a B4(CPE) sends requests to a PCP > Server: > =20 > If the CPE gets a delegated /56 there is nothing that says which IPv6 > address should be used to establish the tunnel. There is nothing that = says > that the CPE can (or not) after some time switch to another IPv6 and s= wap > tunnels. And there is nothing precluding a CPE from having more than o= ne > tunnel. > =20 > =3D> in this case (which implicitly use the plain mode) you have two choi= ces: > - you don't matter if the PCP client is really the B4 and the subscriber= -ID > is the /56 > - you don't want to be flexible and you require one address (and one tun= nel) > In fact it is bound to the way the B4 gets its IPv6 address: if one addre= ss > is assigned to it then it makes sense to require the B4 to use it. But we can not solve this here (maybe Broadband Forum) so how can we enforc= e what you propose? >=20 > An ISP might (or not) have a policy in place but that is an enforcemen= t > issue. > =20 > Therefore, we can mandate that PCP messages use the same source IPv6 > address > of the tunnel but this address can change dynamically and even if afte= r > reboot the CPE gets the same exact delegated /56. > =20 > =3D> the recommended (but not enforced) way for the B4 is to use DHCPv6 t= o > get its IPv6 addresses and a prefix for the home network. In this case > you get a stable IPv6 address you can enforce. Much like you argued that many NATs do not implement EIM, lots of deploymen= t will not use DHCPv6 and therefore I'm still not sure how we can enforce wha= t you propose. > =20 >> These have some direct consequences: >> - scenarios with subscribers require a per subscriber authentication. >> (this is for scenarios with subscribers other than DS-Lite and NAT444) >=20 > =3D> I considered the issue as solved for DS-Lite and NAT444, and as open= ed > for scenarios I don't know well or I don't know yet. I can only agree if we spell out all the constraints for both types of deployments (which are considerable - and therefore might make the security requirement questionable). >=20 > Now what is your concern: the requirement itself, the definition of > the term subscriber, or the ways to meet the requirement? All, but instead of this back and forth it is better if ISPs chime in, give= n the many different network deployments if this security assessment makes sense, the trade-offs vs. deploying the solution and how/if it can be solved. >=20 > Regards >=20 > Francis.Dupont@fdupont.fr >=20 > PS: note there likely are some scenarios where in fact strong mutual > authentication between the subscriber CPE and the PCP server is required. > At least the insecure infrastructure case is an example. From dwing@cisco.com Thu Feb 10 17:03:30 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43E8F3A6B24 for ; Thu, 10 Feb 2011 17:03:30 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rF0TdxBh-02 for ; Thu, 10 Feb 2011 17:03:29 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1437C3A6AFC for ; Thu, 10 Feb 2011 17:03:29 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQBAAoaVE2rR7Ht/2dsb2JhbACXE4FljHhzoG2bLIVcBIUB X-IronPort-AV: E=Sophos;i="4.60,452,1291593600"; d="scan'208";a="261096245" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 11 Feb 2011 01:03:42 +0000 Received: from dwingWS ([10.32.240.198]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1B13gD3001522; Fri, 11 Feb 2011 01:03:42 GMT From: "Dan Wing" To: References: Your message of Thu, 10 Feb 2011 11:22:42 PST. <0c8b01cbc957$e3d9ca70$ab8d5f50$@com> <201102110025.p1B0PWWF010308@givry.fdupont.fr> In-Reply-To: <201102110025.p1B0PWWF010308@givry.fdupont.fr> Date: Thu, 10 Feb 2011 17:03:42 -0800 Message-ID: <0db001cbc987$86719630$9354c290$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvJgj00e6vmbzvmRnKn8t1/GXrqIgAAci1w Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] brief review of base-04 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 01:03:30 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Thursday, February 10, 2011 4:26 PM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] brief review of base-04 > > > In your previous mail you wrote: > > BEHAVE only says the implicit dynamic mappings need to be > on the same public IP address. > > => BEHAVE says: > "REQ-1: A LSN MUST allocate one external IP address to each CPE." > > i.e., there is nothing explicit which limits the requirement > to a particular mapping type. > > I expect PCP needs to also have its explicit dynamic mappings > on that same public IP address. > > => I agree and we should refer to BEHAVE as this is not in > the PCP WG scope. > > > => explicit dynamic mappings and static mappings are not so > > different: they are two kinds of port forwarding. > > I don't see how we can do anything more than "SHOULD be > the same", though. Afterall, PCP is not defining how > static (CLI) mappings are done. > > => we can refer to the BEHAVE MUST and apply it to all mappings. > Of course it should be fine to check with the BEHAVE WG too. > > > => hum, IMHO the wording should be changed to 'a not explicit > > dynamic mapping' so it will be clear a PCP delete works only > > on PCP created mappings. BTW this can lead some implementations > > to return this result code for any not specific delete request > > but I can't see why it should be an issue. > > How is this: > > PCP MAP requests only control > mappings created by MAP requests. So, f the PCP client > ^i > attempts to delete a static port mapping (i.e., a mapping > created outside of PCP itself), the PCP server deletes all > of > the PCP-created mappings but MUST respond with > UNABLE_TO_DELETE_ALL result code, with the other fields > encoded as described above. > > => it is in the section >= 3 so the word 'port' is not needed. > But my suggestion was not to apply this to static mappings but > to all not explicit dynamic mapping, i.e., what is inside the > parentheses. Adjusted that text. The 'maintaining external address' is venturing beyond the MAP OpCode itself, so I moved it to a new section and rewrote most of it. I now have this. You will see the text requires implicit and explicit mappings be the same, and recommends static mappings be the same. I am still struggling to understand what breaks if static mappings are different -- "NAT load balancing" doesn't explain the problem to me. 10. Considerations for MAP and PEER OpCodes 10.1. Maintaining Same External IP Address It is REQUIRED that the PCP-controlled device assign the same external IP address PCP-created explicit dynamic mappings and to implicit dynamic mappings. It is RECOMMENDED that static mappings (e.g., those created by a command language interface on the PCP server or PCP-controlled device) also be assigned to the same IP address. Once all internal hosts belonging to a given subscriber have no implicit dynamic mappings and have no explicit dynamic mappings in the PCP-controlled device, a subsequent PCP request for that internal host MAY be assigned to a different external IP address. Generally, this re-assignment would occur when a CGN device is load balancing newly-seen hosts to its public IPv4 address pool. > > > => spoofed SERVER_OVERLOADED with silly retry values. > > > > That concern is not unique to SERVER_OVERLOADED, is it? > > > > => not unique but SERVER_OVERLOADED has no justification. > > Ok. Let's separate the two problems. I do agree that the > PCP server can simply discard PCP messages if it's too busy. > The expectation of SERVER_OVERLOADED is similar to IP's > ECN (early congestion notification), > > => no, it is similar to the source quench ICMP. Yes, it's quite similar to source quench. Which fell out of favor because off-path attackers could spoof the ICMP source quench, because ICMP source quench didn't include much information in the packet, and TCP implementations didn't validate the data that was contained in them. Very much like the off-path RST attacks described in various papers that can still happen today (with large windows). > to provide back-pressure > *before* the server is completely overloaded. Of course > once completely overloaded, it is cheaper (less processing) > to discard packets rather than generate a SERVER_OVERLOADED > response. > > => when we discussed the ticket #11, there was a consensus > to not introduce a flow control mechanism. So you have to > reopen #11 first... Ticket #11 was only about existing contradiction in that version of the specification. The decision was to allow the client to send traffic however fast it wanted. I'll go read your proposal on how to handle errors. I believe there is a good idea in there that should bear some fruit towards moving us all forward. > > > => I still don't know what is "its configured maximum > > lifetime value". > > > > A CLI setting, a #define'd value, or so on. > > > > => so it is a new and PCP specific NAT property. > > Not at all. > > Every NAPT, today, has a configured maximum lifetime value. > > => they have many, one per condition, for instance my AFTR has > 5 different configured maximum lifetimes... so I have nothing > against a 6th one (:-). No, it is still not a new lifetime. A TCP connection, once established, has a lifetime. This is the amount of time that no data is sent or received across the TCP session before the NAT times it out. This has a value, let's call it the "configured maximum lifetime value". That is the value returned. Please suggest a wording change if the existing text is unclear. I don't see how to improve it. Text reads: "Otherwise, the PCP server chooses the smaller of the requested lifetime and its configured maximum lifetime value (which might be the same value as for mappings (created with the MAP OpCode, ), or might be a different value), and sets the lifetime of the existing mapping." -d > Regards > > Francis.Dupont@fdupont.fr > > PS: UDP, ICMP echo, TCP (opening, open, closing). And I don't > count fragment and hold down. BTW I don't believe you want > the open TCP one even it is usually the largest because > it would be simpler to send a TCP probe. From trac@tools.ietf.org Thu Feb 10 17:33:12 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44F183A6A8F for ; Thu, 10 Feb 2011 17:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.196 X-Spam-Level: X-Spam-Status: No, score=-102.196 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfGamDMqEwEt for ; Thu, 10 Feb 2011 17:33:11 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 053D83A672F for ; Thu, 10 Feb 2011 17:33:11 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pnhsy-0000Gs-OU; Thu, 10 Feb 2011 17:33:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com X-Trac-Project: pcp Date: Fri, 11 Feb 2011 01:33:21 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/10#comment:3 Message-ID: <062.10bdd2f4b0ea65d1a04523dfecf6538d@tools.ietf.org> References: <053.e4eb3896c167b7dd11a6f1bfffcd9fdb@tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <053.e4eb3896c167b7dd11a6f1bfffcd9fdb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] UPnP interop #10 (closed): Firewall (address-dependent filter) support X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 01:33:12 -0000 #10: Firewall (address-dependent filter) support Changes (by dwing@…): * status: new => closed * resolution: => fixed Comment: Closed, with this text that will appear in -05: {{{ 8.5.2. REMOTE_PEER_FILTER This Option indicates packet filtering is desired. The remote peer port and remote peer IP Address indicate the permitted remote peer's source IP address and port for packets from the Internet. The remote peer prefix length indicates the length of the remote peer's IP address that is significant; this allows a single Option to permit an entire subnet. After processing this MAP request and generating a successful response, the PCP-controlled device will simply drop packets with a source IP address, transport, or port that do not match the fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | prefix-length | Remote Peer Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Remote Peer IP address (32 bits if MAP4, : : 1 28 bits if MAP6) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ These fields are described below: Reserved: 8 reserved bits, MUST be sent as 0 and MUST be ignored when received. prefix-length: indicates how many bits of the IPv4 or IPv6 address are relevant for this filter. The value 0 indicates "no filter", and will remove all previous filters. See below for detail. Remote Peer Port: the port number of the remote peer. The value 0 indicates "all ports" Remote Peer IP address: The IP address of the remote peer. This Option: name: REMOTE_PEER_FILTER number: 128 is valid for OpCodes: MAP4, MAP6 is included in responses: MUST, if it appeared in the request. length: 2 if used with MAP4, 5 if used with MAP6 may appear in: requests maximum occurrences: as many as fit within maximum PCP message size Because of interactions with dynamic ports this Option MUST only be used by a client that is operating a server (that is, using the MAP OpCode), as this ensures that no other application will be assigned the same ephemeral port for its outgoing connection. Other use by a PCP client is NOT RECOMMENDED and will cause some UNSAF NAT traversal mechanisms [RFC3424] to fail where they would have otherwise succeeded, breaking other applications running on this same host. The prefix-length indicates how many bits of the IPv6 address or IPv4 address are used for the filter. For MAP4, a prefix-length of 32 indicates the entire IPv4 address is used. For MAP6, a prefix-length of 128 indicates the entire IPv6 address is used. For MAP4 the minimum prefix-length value is 0 and the maximum value is 32. For MAP6 the minimum prefix-length value is 0 and the maximum value is 128. Values outside those range cause an MALFORMED_OPTION response code. If multiple occurrences of REMOTE_PEER_FILTER exist, they are processed in the same order received. To remove all existing filters, the prefix-length 0 is used. To change an existing filter, the PCP client sends a MAP request containing two REMOTE_PEER_FILTER options, the first option containing a prefix-length of 0 (to delete all existing filters) and the second containing the new remote peer's IP address and port. To allow an additional remote peer to an existing filtered mapping, a new MAP request is sent with the REMOTE_PEER_FILTER. The PCP server or the PCP-controlled device is expected to have a limit on the number of remote peers it can support. This limit might be as small as one. If a MAP request would exceed this limit, the entire MAP request is rejected with the result code EXCESSIVE_REMOTE_PEERS, and the state on the PCP server is unchanged. }}} -- --------------------------------+------------------------------------------- Reporter: dwing@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: UPnP interop | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: pcp From dwing@cisco.com Fri Feb 11 15:52:13 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39CE3A69D1 for ; Fri, 11 Feb 2011 15:52:13 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2klVqu6ALBIk for ; Fri, 11 Feb 2011 15:52:12 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 6380E3A6838 for ; Fri, 11 Feb 2011 15:52:12 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoBALtZVU2rR7Ht/2dsb2JhbACXID+BJox5c6BKmy+FXQSFAQ X-IronPort-AV: E=Sophos;i="4.60,458,1291593600"; d="scan'208";a="261637371" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 11 Feb 2011 23:52:28 +0000 Received: from dwingWS ([128.107.106.254]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1BNqSSK003424; Fri, 11 Feb 2011 23:52:28 GMT From: "Dan Wing" To: References: Your message of Wed, 09 Feb 2011 15:44:51 PST. <077901cbc8b3$58b48d80$0a1da880$@com> <201102100858.p1A8wpWe053091@givry.fdupont.fr> In-Reply-To: <201102100858.p1A8wpWe053091@givry.fdupont.fr> Date: Fri, 11 Feb 2011 15:52:28 -0800 Message-ID: <11cd01cbca46$bd655f90$38301eb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvJAL98y6leIwCqSFK49M/ugLUX0QAPwK4g Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] PCP packet layout [was RE: Review of pcp-base-3] X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 23:52:13 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Thursday, February 10, 2011 12:59 AM > To: Dan Wing > Cc: 'Reinaldo Penno'; pcp@ietf.org > Subject: Re: PCP packet layout [was RE: [pcp] Review of pcp-base-3] > > > In your previous mail you wrote: > > > How about the following, which provides 8-bit alignment of > OpCode > > and Result Code, and keeps all the reserved space together: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 > 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > > |1|Ver=0| Reserved | Result Code |R| OpCode > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+ > > > > => I don't understand the gratuitous shuffle of fields... > > Reinaldo suggested having two sections of 'reserved' bits could > be reduced to have one section of 'reserved' bits. > > => this doesn't explain the swap between Result Code and OpCode. > > Regards > > Francis.Dupont@fdupont.fr > > PS: to lower the level of changes and to get one reserved field, > I propose: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| Version = 0 |R| OpCode | Reserved | Result Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ There are only a few weeks to get this specification done, and proposals like this are helpful to keep the specification moving forward quickly. Thanks. I'll put this into -05. -d From trac@tools.ietf.org Mon Feb 14 10:44:57 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6C943A6D90 for ; Mon, 14 Feb 2011 10:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TkWP7cLZdBc for ; Mon, 14 Feb 2011 10:44:57 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2CD6B3A6D98 for ; Mon, 14 Feb 2011 10:44:57 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pp3QF-0007WD-Tm; Mon, 14 Feb 2011 10:45:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: Francis.Dupont@fdupont.fr X-Trac-Project: pcp Date: Mon, 14 Feb 2011 18:45:19 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/38 Message-ID: <063.06897a694fc1efd1fd9e3b89438a850e@tools.ietf.org> X-Trac-Ticket-ID: 38 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: Francis.Dupont@fdupont.fr, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: [pcp] base #38 (new): state maintenance: create a general failure model, discussing how to recover from failures X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 18:44:58 -0000 #38: state maintenance: create a general failure model, discussing how to recover from failures The state maintenance document could be split into 3 items: - a general model which explains failure cases and how to recover from them. -- ---------------------------------------+------------------------------------ Reporter: Francis.Dupont@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: ---------------------------------------+------------------------------------ Ticket URL: pcp From trac@tools.ietf.org Mon Feb 14 10:45:45 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3339D3A6D97 for ; Mon, 14 Feb 2011 10:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5K9Rb9fT0Tir for ; Mon, 14 Feb 2011 10:45:44 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5DB6D3A6D90 for ; Mon, 14 Feb 2011 10:45:44 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pp3R2-0007bM-3m; Mon, 14 Feb 2011 10:46:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: Francis.Dupont@fdupont.fr X-Trac-Project: pcp Date: Mon, 14 Feb 2011 18:46:08 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/39 Message-ID: <063.64430b7776423acd30eca9fe118ccd14@tools.ietf.org> X-Trac-Ticket-ID: 39 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: Francis.Dupont@fdupont.fr, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: [pcp] base #39 (new): mechanism to store disambiguating information at aggregation points X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 18:45:45 -0000 #39: mechanism to store disambiguating information at aggregation points a request for a mechanism to store disambiguating information at aggregation points, e.g., between applications or in an IWF. -- ---------------------------------------+------------------------------------ Reporter: Francis.Dupont@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: ---------------------------------------+------------------------------------ Ticket URL: pcp From trac@tools.ietf.org Mon Feb 14 10:47:58 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E444C3A6A00 for ; Mon, 14 Feb 2011 10:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pR5EUSttuyul for ; Mon, 14 Feb 2011 10:47:58 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 391113A67BD for ; Mon, 14 Feb 2011 10:47:58 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pp3TB-0003Ny-VD; Mon, 14 Feb 2011 10:48:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: Francis.Dupont@fdupont.fr X-Trac-Project: pcp Date: Mon, 14 Feb 2011 18:48:21 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/40 Message-ID: <063.611325149aac24967d384f719a25fe3f@tools.ietf.org> X-Trac-Ticket-ID: 40 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: Francis.Dupont@fdupont.fr, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: [pcp] base #40 (new): proposal for a GET/GETNEXT exchange X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 18:47:59 -0000 #40: proposal for a GET/GETNEXT exchange a proposal for a GET/GETNEXT exchange [http://tools.ietf.org/html/draft-boucadair-pcp-failure-00] -- ---------------------------------------+------------------------------------ Reporter: Francis.Dupont@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: ---------------------------------------+------------------------------------ Ticket URL: pcp From dwing@cisco.com Mon Feb 14 10:48:50 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044A93A6A15 for ; Mon, 14 Feb 2011 10:48:50 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkBaePNIWAEE for ; Mon, 14 Feb 2011 10:48:49 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 416D73A67BD for ; Mon, 14 Feb 2011 10:48:49 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4BACcIWU2rR7Hu/2dsb2JhbACXM4FljHhzoBGbJ4VeBIUE X-IronPort-AV: E=Sophos;i="4.60,469,1291593600"; d="scan'208";a="329637877" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 14 Feb 2011 18:49:12 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1EInCeB016735; Mon, 14 Feb 2011 18:49:12 GMT From: "Dan Wing" To: "'Francis Dupont'" , References: <201102101614.p1AGERrN080054@givry.fdupont.fr> In-Reply-To: <201102101614.p1AGERrN080054@givry.fdupont.fr> Date: Mon, 14 Feb 2011 10:49:12 -0800 Message-ID: <00c001cbcc77$df3fdc70$9dbf9550$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvJPaBQAgq/cCOVRaOlSE4Nq/rLAQDOTX/w Content-Language: en-us Subject: Re: [pcp] state maintenance summary X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 18:48:50 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Francis Dupont > Sent: Thursday, February 10, 2011 8:14 AM > To: pcp@ietf.org > Subject: [pcp] state maintenance summary > > The state maintenance document could be split into 3 items: What state maintenance document are you referring to? > - a general model which explains failure cases and how > to recover from them. Ticket #38 > - a request for a mechanism to store disambiguating information > at aggregation points, e.g., between applications or in an IWF. Ticket #39 > - a proposal for a GET/GETNEXT exchange. Ticket #40 > I'd like to get tickets about the 3 items in order to > discuss about them. We can certainly discuss things without tickets. -d > Regards > > Francis.Dupont@fdupont.fr > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From dwing@cisco.com Mon Feb 14 11:44:40 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 000253A6DB1 for ; Mon, 14 Feb 2011 11:44:39 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrRxVPOxZCTo for ; Mon, 14 Feb 2011 11:44:39 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5C06E3A6D9B for ; Mon, 14 Feb 2011 11:44:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1956; q=dns/txt; s=amsiport01001; t=1297712702; x=1298922302; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=BLEvfGXySYSfaKTfmhH8f3h1bTcV78ttjGGXyAaeePY=; b=MHiKeEQHC6IvHDTo2Ov4tFrCnrLptiplvX6kIJDKKJPFbk9bFdFMpJo1 H/L64ws2x9cm2AcC0l3o6SCGgNoc86W3jwPftRwuwrSXpZJDdmu5pLYIA dce0GKtGmlr3L3vBS354CIVV6mYF0VMhEvsO7V7xbvBmszLkYQREh859Q Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAEYVWU2Q/khLgWdsb2JhbACXNIFljHgVAQEWIiSgKJslhV4EhQQ X-IronPort-AV: E=Sophos;i="4.60,469,1291593600"; d="scan'208";a="76257496" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2011 19:45:01 +0000 Received: from dwingWS ([10.32.240.194]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p1EJitCW008076; Mon, 14 Feb 2011 19:44:57 GMT From: "Dan Wing" To: "'Francis Dupont'" , References: <201102101215.p1ACFkQp065426@givry.fdupont.fr> In-Reply-To: <201102101215.p1ACFkQp065426@givry.fdupont.fr> Date: Mon, 14 Feb 2011 11:44:50 -0800 Message-ID: <00f401cbcc7f$a8c9ee30$fa5dca90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvJHEckipwDzsqCR4Ct2Is11wvSqgDYazig Content-Language: en-us Subject: Re: [pcp] proposal about internal addresses X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 19:44:40 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Francis Dupont > Sent: Thursday, February 10, 2011 4:16 AM > To: pcp@ietf.org > Subject: [pcp] proposal about internal addresses > > Here is a counter-proposal about internal addresses, > based on the fact the THIRD_PARTY option disadvantages > (for instance it makes a PCP relay far more complex) > are greater than advantages. THIRD_PARTY makes a normal PCP client easier, because the PCP client doesn't need any code to cause its PCP request to egress the proper interface. This is important because after using MAP and receiving a TCP SYN, the host will send a TCP SYNACK and that needs to use the correct interface. Using the host's address preferences, rather than doing it in a PCP library which hopes to mimic the host's address preference, is far safer. A proxy would need to copy the source IP address of the PCP request into the THIRD_PARTY option. I admit that is a change to proxy behavior. But I don't understand how that makes the proxy "far more complex". Can you elaborate? -d > I propose to go back to 03 layout, i.e., the internal address > is included in MAP and PEER OpCodes. > > The supposed simplicity in PCP clients is IMHO an API issue, > I suggest to not improve it inside the protocol but to ask > for an API routine which fills the field from the > socket local address. Of course the section 7 is the right > place to illustrate this. > > If to reduce the number of OpCodes is considered as a good > thing I propose to reuse the External_AF PEER idea. > BTW it should be in this case a good idea to make MAP and > PEER OpCodes more similar, i.e., to maximize code sharing > in programs. > > Regards > > Francis.Dupont@fdupont.fr > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange-ftgroup.com Tue Feb 15 01:07:00 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2C673A6C7E for ; Tue, 15 Feb 2011 01:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6GijmONPgzR for ; Tue, 15 Feb 2011 01:06:59 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 9B94E3A6B5B for ; Tue, 15 Feb 2011 01:06:59 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 7B48A22C45D; Tue, 15 Feb 2011 10:07:23 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 542434C013; Tue, 15 Feb 2011 10:07:23 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Tue, 15 Feb 2011 10:07:23 +0100 From: To: Francis Dupont , Dan Wing Date: Tue, 15 Feb 2011 10:07:21 +0100 Thread-Topic: [pcp] proposal about internal addresses Thread-Index: AcvJHEWraUzH/eFySK6PcYjZTPXAaQDzACGQ Message-ID: <2828_1297760843_4D5A424B_2828_17102_1_94C682931C08B048B7A8645303FDC9F33C444C7F25@PUEXCB1B.nanterre.francetelecom.fr> References: <201102101215.p1ACFkQp065426@givry.fdupont.fr> In-Reply-To: <201102101215.p1ACFkQp065426@givry.fdupont.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.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.14.160319 Cc: "pcp@ietf.org" Subject: Re: [pcp] proposal about internal addresses X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 09:07:00 -0000 Hi Francis, Dan, I echo Francis's comment. I read the e-mails exchanged on this issue. I'm not sure there is a strong = argument for the usage of THIRD_PARTY Option. I suggest to remove this Opti= on and include back the internal IP address to the MAP request/response.=20 Thanks, Med=20=20 -----Message d'origine----- De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Franc= is Dupont Envoy=E9 : jeudi 10 f=E9vrier 2011 13:16 =C0 : pcp@ietf.org Objet : [pcp] proposal about internal addresses Here is a counter-proposal about internal addresses, based on the fact the THIRD_PARTY option disadvantages (for instance it makes a PCP relay far more complex) are greater than advantages. I propose to go back to 03 layout, i.e., the internal address is included in MAP and PEER OpCodes. The supposed simplicity in PCP clients is IMHO an API issue, I suggest to not improve it inside the protocol but to ask for an API routine which fills the field from the socket local address. Of course the section 7 is the right place to illustrate this. If to reduce the number of OpCodes is considered as a good thing I propose to reuse the External_AF PEER idea. BTW it should be in this case a good idea to make MAP and PEER OpCodes more similar, i.e., to maximize code sharing in programs. Regards Francis.Dupont@fdupont.fr _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From dwing@cisco.com Thu Feb 17 10:10:30 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF6D3A6E07 for ; Thu, 17 Feb 2011 10:10:30 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BarnuWGal1tX for ; Thu, 17 Feb 2011 10:10:28 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id CB22D3A6D6C for ; Thu, 17 Feb 2011 10:10:28 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAL/zXE2rR7H+/2dsb2JhbACZMoxmc6BDm0yDAYJdBIUK X-IronPort-AV: E=Sophos;i="4.60,487,1291593600"; d="scan'208";a="261542345" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 17 Feb 2011 18:11:00 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1HIB0YE028896 for ; Thu, 17 Feb 2011 18:11:00 GMT From: "Dan Wing" To: Date: Thu, 17 Feb 2011 10:10:59 -0800 Message-ID: <054701cbcece$07c49660$174dc320$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvOzgeDHzHCw2XHT0GKb92cHioPwg== Content-Language: en-us Subject: [pcp] feedback on security considerations X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 18:10:30 -0000 Please provide feedback on the re-written security considerations section, below, which is planned for inclusion in the upcoming pcp-base-05. Two notes, related to changes in the upcoming -05 that are reflected in the Security Considerations text you will review below: * In -05, the THIRD_PARTY option will be removed and internal-ip-address (Target IP address) will be in the MAP message itself. This restores the location of the internal address as with previous versions of pcp-base. * While editing -05, I found the text was simplified by using "Target IP Address" to refer to the internal host that will receive incoming packets that are mapped. You will notice Target Address and Target IP Address used below. -d ----- 12. Security Considerations The PCP client's source port SHOULD be randomly generated [RFC6056]. The PCP server MUST only listen for requests from its internal interfaces, and MUST NOT listen for requests on its Internet-facing interfaces. This document defines Port Control Protocol and two types of OpCodes, PEER and MAP. The PEER OpCode allows querying and extending (if permitted) the lifetime of an existing implicit dynamic mapping, so a host can reduce its keepalive messages. The MAP OpCode allows creating a mapping so a host can receive incoming unsolicited connections from the Internet in order to run a server. The PEER OpCode does not introduce any new security considerations. On today's Internet, ISPs do not typically filter incoming traffic for their subscribers. However, when an ISP introduces stateful address sharing with a NAPT device, such filtering will occur as a side effect. Filtering will also occur with IPv6 CPE [I-D.ietf-v6ops-cpe-simple-security]. The MAP OpCode allows a PCP client to create a mapping so that a host can receive inbound traffic and operate a server. Security considerations for the MAP OpCode are described in the following sections. 12.1. Denial of Service Because the state created in a NAPT or firewall, a per-subscriber quota will likely exist for both implicit dynamic mappings (e.g., outgoing TCP connections) and explicit dynamic mappings (PCP). A subscriber might make an excessive number of implicit or explicit dynamic mappings, consuming an inordinate number of ports, causing a denial of service to other subscribers. Thus, it is RECOMMENDED that subscribers be limited to a reasonable number of explicit dynamic mappings. Note: this is similar to guidance for implicit dynamic mappings [I-D.ietf-behave-lsn-requirements]). 12.2. Ingress Filtering It is important to prevent a subscriber from creating a mapping for another subscriber, because this allows incoming packets from the Internet and consumes the other user's mapping quota. Both implicit dynamic mappings (e.g., outgoing TCP connections) and explicit dynamic mappings (PCP) need ingress filtering [RFC2827]. Ingress filtering MUST be performed by the edge router or aggregation router to drop packets which have a source address not belonging to the subscriber. Ingress filtering prevents the source IP address of a PCP message from being spoofed. 12.3. Validating Target Address The MAP OpCode contains a Target Address field, which allows a PCP client to create an explicit dynamic mapping for another host. This is called a "third party mapping" and is used in specific cases. A PCP server implemented in a customer premise router MUST generate an UNAUTH_TARGET_ADDRESS response if it receives a PCP MCP request with a Target Address that does not match the source IP address of that request. This is because third party mappings using PCP within a subscriber's home network are prohibited. If such a mapping is desired, the user needs to interact out-of-band with their customer premise router to create a third party mapping (e.g., using its administrative interface). In contrast, a PCP server implemented outside of a customer premise router, such as by a service provider, does allow third party mappings. However, a third party mapping can only be performed by the subscriber's customer premise router and only to devices belonging to the same subscriber. The end result is that hosts within the customer premise can only create mappings for themselves, and administrative access to the customer premise router is required to create mappings for other hosts within the home. To enforce these restrictions, the PCP server needs certain knowledge about the network's subscribers. It needs to determine the IP address of the subscriber's customer premise router and to determine the IP subnet assigned to the subscriber. This knowledge might be dynamic (e.g., database query into the service provider's user database for every incoming PCP request), might be a table (e.g., subscribers with a certain IPv4 network prefix all have an IPv4 /24, other IPv4 prefixes have an IPv4 /32, certain IPv6 prefixes have an have an IPv6 /32, and so on), or might be very static (e.g., all subscribers have one IPv4 address). If there are multiple addresses assigned to a subscriber, the PCP server allows the highest-numbered address to perform third party mappings. On a network supporting PCP with multiple addresses assigned to a subscriber, the highest- numbered host SHOULD be the subscriber's customer premise router. Upon receiving a MAP request where the Target Address does not match the source IP address of the request, the PCP server determines if the source IP address of the request is the subscriber's highest numbered address, following the procedure in the previous paragraph. If not, the PCP server MUST generate an UNAUTH_SOURCE_ADDRESS error. Then the PCP server determines if the Target Address belongs to the same subscriber as the source IP address of the PCP packet, using the procedure described in the previous paragraph. If not, the PCP server MUST generate an UNAUTH_TARGET_ADDRESS error. From pselkirk@isc.org Thu Feb 17 10:18:06 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED9E13A6E26 for ; Thu, 17 Feb 2011 10:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pll8uc7NoRmy for ; Thu, 17 Feb 2011 10:18:06 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id E35C33A6E19 for ; Thu, 17 Feb 2011 10:18:05 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 95B185F98F2 for ; Thu, 17 Feb 2011 18:18:22 +0000 (UTC) (envelope-from pselkirk@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10300) id CA4E1216C36; Thu, 17 Feb 2011 18:18:20 +0000 (UTC) From: Paul Selkirk To: pcp@ietf.org In-Reply-To: <0d4b01cbc97a$a8d474c0$fa7d5e40$@com> (dwing@cisco.com) References: <0cbd01cbc95e$0adff7b0$209fe710$@com> <0d4b01cbc97a$a8d474c0$fa7d5e40$@com> Date: Thu, 17 Feb 2011 18:18:20 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [pcp] an idea about REMOTE_PEER_FILTER X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 18:18:07 -0000 [Sent on behalf of Francis:] In your previous mail you wrote: > But now, depending on what comes > later in the packet I need to make a decision. "Decision" means it isn't specific enough (that is, the text is too vague). I don't see where the server decides anything, or the meaning is unclear. If there is something, please point it out. => in my proposal I used the argument that the request processing is atomic, i.e., all or none of the options are processed. I believe it is the point Reinaldo liked to be clarified. Regards PS: in the hairiest case, delete followed by filters, this means it should be implemented by as a filter list replace (or in two passes). Francis.Dupont@fdupont.fr ---------------- And a few thoughts of my own: Section 5.3 (Options) says options may be encoded in any order, but does not say anything about processing order. Section 8.5.2 (REMOTE_PEER_FILTER) is I think the only place where processing order is discussed. The very presence of the UNPROCESSED response option in the spec means that request processing is not atomic in the all-or-nothing sense, at least as it applies to the entire request, but it would be good to have this stated clearly. REMOTE_PEER_FILTER is option #128, which means the "P" bit is set, which means processing follows the logic in 6.3.1. If any REMOTE_PEER_FILTER option fails, there is one UNPROCESSED response option for REMOTE_PEER_FILTER, which leaves the filter in an ambiguous state, which I think is the crux of Francis's comment about atomicity - does the server roll back the filter state, or leave it in the state of the last successful filter operation? Is leaving a broken filter acceptable? Regardless of whether the operation is atomic or not, the server has no way to indicate which REMOTE_PEER_FILTER request option failed, and the client has no way to query about the state of filtering, so it can only delete all filters and try again. paul From dwing@cisco.com Thu Feb 17 11:26:17 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97D713A6E4A for ; Thu, 17 Feb 2011 11:26:17 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmD7yhR9u+aN for ; Thu, 17 Feb 2011 11:26:16 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 4B0E13A6D31 for ; Thu, 17 Feb 2011 11:26:16 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggBACEFXU2rR7H+/2dsb2JhbACXUIFljGZzoCKbTIVeBIUKjFo X-IronPort-AV: E=Sophos;i="4.62,181,1297036800"; d="scan'208";a="265362760" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 17 Feb 2011 19:26:47 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1HJQlTF013195; Thu, 17 Feb 2011 19:26:47 GMT From: "Dan Wing" To: "'Paul Selkirk'" , References: <0cbd01cbc95e$0adff7b0$209fe710$@com> <0d4b01cbc97a$a8d474c0$fa7d5e40$@com> In-Reply-To: Date: Thu, 17 Feb 2011 11:26:47 -0800 Message-ID: <05ba01cbced8$9e459850$dad0c8f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvOzxsxvAJ/WP9qQVGqQGCqytGESwACJerQ Content-Language: en-us Subject: Re: [pcp] an idea about REMOTE_PEER_FILTER X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 19:26:17 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Paul Selkirk > Sent: Thursday, February 17, 2011 10:18 AM > To: pcp@ietf.org > Subject: Re: [pcp] an idea about REMOTE_PEER_FILTER > > [Sent on behalf of Francis:] > > In your previous mail you wrote: > > > But now, depending on what comes > > later in the packet I need to make a decision. > > "Decision" means it isn't specific enough (that is, the text is > too vague). I don't see where the server decides anything, or > the meaning is unclear. If there is something, please point it > out. > > => in my proposal I used the argument that the request processing is > atomic, i.e., all or none of the options are processed. > I believe it is the point Reinaldo liked to be clarified. Ok. How is the following revised text: If multiple occurrences of REMOTE_PEER_FILTER exist in the same MAP request, they are processed in the same order received, and they MUST all be successfully processed or return an error (e.g., MALFORMED_OPTION if one of the options was malformed). As with other PCP errors, returning an error causes no state to be changed in the PCP server or in the PCP-controlled device. > Regards > > PS: in the hairiest case, delete followed by filters, this means it > should be implemented by as a filter list replace (or in two passes). I don't see the purpose of a delete (lifetime=0) with the REMOTE_PEER_FILTER option. How about we just prohibit that with the following new text: If a MAP request has a lifetime of 0 and contains the REMOTE_PEER_FILTER option, the error MALFORMED_OPTION is returned. > Francis.Dupont@fdupont.fr > > ---------------- > And a few thoughts of my own: > > Section 5.3 (Options) says options may be encoded in any order, but > does not say anything about processing order. Added: and are processed in the order received > Section 8.5.2 > (REMOTE_PEER_FILTER) is I think the only place where processing order > is discussed. The very presence of the UNPROCESSED response option in > the spec means that request processing is not atomic in the > all-or-nothing sense, at least as it applies to the entire request, but > it would be good to have this stated clearly. Added to Section 5.3, "Options": If, while processing an option, an error is encountered that causes a PCP error response to be generated, the PCP request causes no state change in the PCP server or the PCP-controlled device. > REMOTE_PEER_FILTER is option #128, which means the "P" bit is set, > which > means processing follows the logic in 6.3.1. If any REMOTE_PEER_FILTER > option fails, there is one UNPROCESSED response option for > REMOTE_PEER_FILTER, which leaves the filter in an ambiguous state, > which > I think is the crux of Francis's comment about atomicity - does the > server roll back the filter state, or leave it in the state of the last > successful filter operation? Is leaving a broken filter acceptable? It rolls back. If the above proposed text doesn't clarify it sufficiently, please let me know. > Regardless of whether the operation is atomic or not, the server has no > way to indicate which REMOTE_PEER_FILTER request option failed, Correct. > and the > client has no way to query about the state of filtering, so it can only > delete all filters and try again. Yep. -d > > paul > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From pselkirk@isc.org Thu Feb 17 14:37:15 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D1D73A6EF4 for ; Thu, 17 Feb 2011 14:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qz94sI+3eg15 for ; Thu, 17 Feb 2011 14:37:14 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 377423A6EFA for ; Thu, 17 Feb 2011 14:35:34 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 22149C9428; Thu, 17 Feb 2011 22:36:04 +0000 (UTC) (envelope-from pselkirk@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10300) id 182FC216C22; Thu, 17 Feb 2011 22:36:04 +0000 (UTC) From: Paul Selkirk To: "Dan Wing" In-Reply-To: <05ba01cbced8$9e459850$dad0c8f0$@com> (dwing@cisco.com) References: <0cbd01cbc95e$0adff7b0$209fe710$@com> <0d4b01cbc97a$a8d474c0$fa7d5e40$@com> <05ba01cbced8$9e459850$dad0c8f0$@com> Date: Thu, 17 Feb 2011 22:36:04 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] an idea about REMOTE_PEER_FILTER X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 22:37:16 -0000 > > => in my proposal I used the argument that the request processing is > > atomic, i.e., all or none of the options are processed. > > I believe it is the point Reinaldo liked to be clarified. > > Ok. How is the following revised text: > > If multiple occurrences of REMOTE_PEER_FILTER exist in > the same MAP request, they are processed in the same order > received, and they MUST all be successfully processed or > return an error (e.g., MALFORMED_OPTION if one of the > options was malformed). As with other PCP errors, returning an > error causes no state to be changed in the PCP server or in > the PCP-controlled device. Does this say anything that's not covered by the revised section 5.3? > > PS: in the hairiest case, delete followed by filters, this means it > > should be implemented by as a filter list replace (or in two passes). > > I don't see the purpose of a delete (lifetime=0) with the > REMOTE_PEER_FILTER option. How about we just prohibit that with > the following new text: > > If a MAP > request has a lifetime of 0 and contains the > REMOTE_PEER_FILTER option, the error MALFORMED_OPTION is > returned. I think he meant "delete filter" (prefix=0), not "delete mapping". But it's not a bad idea to spell out error conditions. > > Section 5.3 (Options) says options may be encoded in any order, but > > does not say anything about processing order. > > Added: > > and are processed in the order received Okay. > > Section 8.5.2 > > (REMOTE_PEER_FILTER) is I think the only place where processing order > > is discussed. The very presence of the UNPROCESSED response option in > > the spec means that request processing is not atomic in the > > all-or-nothing sense, at least as it applies to the entire request, but > > it would be good to have this stated clearly. > > Added to Section 5.3, "Options": > > If, while processing an option, an error is encountered that causes a > PCP error response to be generated, the PCP request causes no state > change in the PCP server or the PCP-controlled device. Just to clarify, if any part of the request fails, the whole request fails, and the PCP server rolls back any changes it may have made while processing the request. paul From Francis.Dupont@fdupont.fr Thu Feb 17 16:28:42 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A50D3A6F72 for ; Thu, 17 Feb 2011 16:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNAzNKRcpjz4 for ; Thu, 17 Feb 2011 16:28:41 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id A19ED3A6DDE for ; Thu, 17 Feb 2011 16:28:40 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1I0TCXw029605; Fri, 18 Feb 2011 01:29:12 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102180029.p1I0TCXw029605@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Thu, 17 Feb 2011 11:26:47 PST. <05ba01cbced8$9e459850$dad0c8f0$@com> Date: Fri, 18 Feb 2011 01:29:12 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] an idea about REMOTE_PEER_FILTER X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 00:28:42 -0000 In your previous mail you wrote: > PS: in the hairiest case, delete followed by filters, this means it > should be implemented by as a filter list replace (or in two passes). I don't see the purpose of a delete (lifetime=0) with the => oops, I mean delete (prefix length=0) aka reset. REMOTE_PEER_FILTER option. How about we just prohibit that with the following new text: If a MAP request has a lifetime of 0 and contains the REMOTE_PEER_FILTER option, the error MALFORMED_OPTION is returned. => yes of course. Regards Francis.Dupont@fdupont.fr From jacniq@gmail.com Thu Feb 17 17:28:28 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8CE3A6C72 for ; Thu, 17 Feb 2011 17:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+47tXtbVx1D for ; Thu, 17 Feb 2011 17:28:27 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 037893A6C28 for ; Thu, 17 Feb 2011 17:28:26 -0800 (PST) Received: by gwb20 with SMTP id 20so1522303gwb.31 for ; Thu, 17 Feb 2011 17:28:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=v8hCUWFYuU3NiwTgcjKl95sC+B3sT5NM0LYw2JDZNDk=; b=G7ta+6/P4Ne0MASFrc5Er+tbdUrg6LCZNMh82xAC63eOMjCIkoGUDW9PcmJqGLSlZm 9aVqLHxFdAc1/7YXR9T4xFxZf+cuQGgYDVlPwY1ftvhqDhTRZPc8daDhtlLbjC9NyqKp c0N/wdMzDYMTMTEmmBpFRe8ju6/6+tMWjOVY8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=B3E3QSIZgINz5zSUqteWdSJ4melQOHlVXkMEkjfHCGgFkWk64kh6LR60CnsJO0T3Sv FavXP0eKeeEAXilvz1HOHUIxS7RJTrZ+ka6hxiu3OM2gSzAwQ7kbwkyyEaTAroQBl37c Nn0IcTe/sLMnsK8XKvyZ49RLAxCm6/yA+kI8E= MIME-Version: 1.0 Received: by 10.151.78.13 with SMTP id f13mr287155ybl.135.1297992537369; Thu, 17 Feb 2011 17:28:57 -0800 (PST) Received: by 10.147.31.34 with HTTP; Thu, 17 Feb 2011 17:28:57 -0800 (PST) In-Reply-To: <00f401cbcc7f$a8c9ee30$fa5dca90$@com> References: <201102101215.p1ACFkQp065426@givry.fdupont.fr> <00f401cbcc7f$a8c9ee30$fa5dca90$@com> Date: Fri, 18 Feb 2011 09:28:57 +0800 Message-ID: From: Jacni Qin To: Dan Wing Content-Type: multipart/alternative; boundary=0015174bdcd01c6c8f049c8470cc Cc: pcp@ietf.org Subject: Re: [pcp] proposal about internal addresses X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 01:28:28 -0000 --0015174bdcd01c6c8f049c8470cc Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 15, 2011 at 3:44 AM, Dan Wing wrote: > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > > Francis Dupont > > Sent: Thursday, February 10, 2011 4:16 AM > > To: pcp@ietf.org > > Subject: [pcp] proposal about internal addresses > > > > Here is a counter-proposal about internal addresses, > > based on the fact the THIRD_PARTY option disadvantages > > (for instance it makes a PCP relay far more complex) > > are greater than advantages. > > THIRD_PARTY makes a normal PCP client easier, because the PCP > client doesn't need any code to cause its PCP request to egress > the proper interface. This is important because after using > MAP and receiving a TCP SYN, the host will send a TCP SYNACK > and that needs to use the correct interface. Using the host's > address preferences, rather than doing it in a PCP library > which hopes to mimic the host's address preference, is far > safer. > Jacni>: +1, the third party is a special case and the THIRD-PARTY option seems to be fair enough for that. In normal cases, the current layout is simpler. Wondering if it will work better for nested NAT, maybe if the internal port is taken away as well? Not sure. ;-) Cheers, Jacni > A proxy would need to copy the source IP address of the > PCP request into the THIRD_PARTY option. I admit that is > a change to proxy behavior. But I don't understand how that > makes the proxy "far more complex". Can you elaborate? > > -d > > > I propose to go back to 03 layout, i.e., the internal address > > is included in MAP and PEER OpCodes. > > > > The supposed simplicity in PCP clients is IMHO an API issue, > > I suggest to not improve it inside the protocol but to ask > > for an API routine which fills the field from the > > socket local address. Of course the section 7 is the right > > place to illustrate this. > > > > If to reduce the number of OpCodes is considered as a good > > thing I propose to reuse the External_AF PEER idea. > > BTW it should be in this case a good idea to make MAP and > > PEER OpCodes more similar, i.e., to maximize code sharing > > in programs. > > > > Regards > > > > Francis.Dupont@fdupont.fr > > _______________________________________________ > > 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 > --0015174bdcd01c6c8f049c8470cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 15, 2011 at 3:44 AM, Dan Wing <dwing@cisco.com> w= rote:
> -----Original Message-----
> From: pcp-bo= unces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of
> Francis Dupont
> Sent: Thursday, February 10, 2011 4:16 AM
> To: pcp@ietf.org=
> Subject: [pcp] proposal about internal addresses
>
> Here is a counter-proposal about internal addresses,
> based on the fact the THIRD_PARTY option disadvantages
> (for instance it makes a PCP relay far more complex)
> are greater than advantages.

THIRD_PARTY makes a normal PCP client easier, because the PCP
client doesn't need any code to cause its PCP request to egress
the proper interface. =A0This is important because after using
MAP and receiving a TCP SYN, the host will send a TCP SYNACK
and that needs to use the correct interface. =A0Using the host's
address preferences, rather than doing it in a PCP library
which hopes to mimic the host's address preference, is far
safer.
=A0
Jacni>: +1, the third party is a special case and the THIRD-PARTY optio= n seems to be fair enough for that.
In normal cases, the current layout = is simpler. Wondering if it will work better for nested NAT, maybe if the i= nternal port is taken away as well? Not sure. ;-)

Cheers,
Jacni


A proxy would need to copy the source IP address of the
PCP request into the THIRD_PARTY option. =A0I admit that is
a change to proxy behavior. =A0But I don't understand how that
makes the proxy "far more complex". =A0Can you elaborate?

-d

> I propose to go back to 03 layout, i.e., the internal address
> is included in MAP and PEER OpCodes.
>
> The supposed simplicity in PCP clients is IMHO an API issue,
> I suggest to not improve it inside the protocol but to ask
> for an API routine which fills the field from the
> socket local address. Of course the section 7 is the right
> place to illustrate this.
>
> If to reduce the number of OpCodes is considered as a good
> thing I propose to reuse the External_AF PEER idea.
> BTW it should be in this case a good idea to make MAP and
> PEER OpCodes more similar, i.e., to maximize code sharing
> in programs.
>
> Regards
>
> Francis= .Dupont@fdupont.fr
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp

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

--0015174bdcd01c6c8f049c8470cc-- From mohamed.boucadair@orange-ftgroup.com Thu Feb 17 23:42:45 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776413A6DAC for ; Thu, 17 Feb 2011 23:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwfvjyJfhP3D for ; Thu, 17 Feb 2011 23:42:44 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id D4BCC3A6D72 for ; Thu, 17 Feb 2011 23:42:43 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id C76A618C1A3 for ; Fri, 18 Feb 2011 08:43:15 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id ABF9C4C069 for ; Fri, 18 Feb 2011 08:43:15 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Fri, 18 Feb 2011 08:43:15 +0100 From: To: "pcp@ietf.org" Date: Fri, 18 Feb 2011 08:43:14 +0100 Thread-Topic: DNS Indirection Thread-Index: AcvPP3/kiIaFko4xRQSDjrN8nhXyAA== Message-ID: <3155_1298014995_4D5E2313_3155_348950_1_94C682931C08B048B7A8645303FDC9F33C444C8C5F@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: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33C444C8C5FPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.18.50315 Subject: [pcp] DNS Indirection X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 07:42:45 -0000 --_000_94C682931C08B048B7A8645303FDC9F33C444C8C5FPUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Dear all, We would like to have a feedback about an open question we have in http://tools.ietf.org/html/draft-bpw-pcp-dhcp-02 (Section 5.2): [Ed. Is there a value to consider a level of indirection (e.g., SRV)? (1) to use an arbitrary port number for PCP Server instead of the default port, (2) detect whether a security channel is in use (using the transport protocol)] The current text assumes there is no indirection. Cheers, Med ******************************************************************************** IMPORTANT. Les informations contenues dans ce message électronique y compris les fichiers attachés sont strictement confidentielles et peuvent être protégées par la loi. Ce message électronique est destiné exclusivement au(x) destinataire(s) mentionné(s) ci-dessus. Si vous avez reçu ce message par erreur ou s'il ne vous est pas destiné, veuillez immédiatement le signaler à l'expéditeur et effacer ce message et tous les fichiers éventuellement attachés. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message électronique est susceptible d'altération. A ce titre, le Groupe France Télécom décline toute responsabilité notamment s'il a été altéré, déformé ou falsifié. De même, il appartient au destinataire de s'assurer de l'absence de tout virus.    IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure of this message is prohibited.  Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ******************************************************************************** --_000_94C682931C08B048B7A8645303FDC9F33C444C8C5FPUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit
Dear all,
 
We would like to have a feedback about an open question we have in http://tools.ietf.org/html/draft-bpw-pcp-dhcp-02 (Section 5.2):
 
      [Ed.  Is there a value to consider a level of indirection (e.g.,
      SRV)? (1) to use an arbitrary port number for PCP Server instead
      of the default port, (2) detect whether a security channel is in
      use (using the transport protocol)]
The current text assumes there is no indirection.
 
Cheers,
Med
********************************************************************************

IMPORTANT. 
Les informations contenues dans ce message électronique y compris les fichiers attachés sont strictement confidentielles et peuvent être protégées par la loi.
Ce message électronique est destiné exclusivement au(x) destinataire(s) mentionné(s) ci-dessus. 
Si vous avez reçu ce message par erreur ou s'il ne vous est pas destiné, veuillez immédiatement le signaler à l'expéditeur et effacer ce message et tous les fichiers éventuellement attachés.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. 
Tout message électronique est susceptible d'altération.
A ce titre, le Groupe France Télécom décline toute responsabilité notamment s'il a été altéré, déformé ou falsifié.
De même, il appartient au destinataire de s'assurer de l'absence de tout virus.
  
IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure of this message is prohibited. 
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.

********************************************************************************
--_000_94C682931C08B048B7A8645303FDC9F33C444C8C5FPUEXCB1Bnante_-- From dwing@cisco.com Fri Feb 18 08:28:07 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16F093A6DFD for ; Fri, 18 Feb 2011 08:28:07 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec0+e99AcSgN for ; Fri, 18 Feb 2011 08:28:05 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DF5DC3A6C8D for ; Fri, 18 Feb 2011 08:28:05 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBABotXk2rR7Ht/2dsb2JhbACXXIFljGRzoBybN4VeBIULjU8 X-IronPort-AV: E=Sophos;i="4.62,188,1297036800"; d="scan'208";a="408911410" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 18 Feb 2011 16:28:39 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1IGSdpH001506; Fri, 18 Feb 2011 16:28:39 GMT From: "Dan Wing" To: "'Jacni Qin'" References: <201102101215.p1ACFkQp065426@givry.fdupont.fr> <00f401cbcc7f$a8c9ee30$fa5dca90$@com> In-Reply-To: Date: Fri, 18 Feb 2011 08:28:39 -0800 Message-ID: <09c901cbcf88$e6606510$b3212f30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvPCzrn31iDsewSQXaJT9Ut251dpQAfYM4w Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] proposal about internal addresses X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 16:28:07 -0000 > -----Original Message----- > From: Jacni Qin [mailto:jacniq@gmail.com] > Sent: Thursday, February 17, 2011 5:29 PM > To: Dan Wing > Cc: Francis Dupont; pcp@ietf.org > Subject: Re: [pcp] proposal about internal addresses > > > > > On Tue, Feb 15, 2011 at 3:44 AM, Dan Wing wrote: > > > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On > Behalf Of > > Francis Dupont > > Sent: Thursday, February 10, 2011 4:16 AM > > To: pcp@ietf.org > > > Subject: [pcp] proposal about internal addresses > > > > Here is a counter-proposal about internal addresses, > > based on the fact the THIRD_PARTY option disadvantages > > (for instance it makes a PCP relay far more complex) > > are greater than advantages. > > > THIRD_PARTY makes a normal PCP client easier, because the PCP > client doesn't need any code to cause its PCP request to egress > the proper interface. This is important because after using > MAP and receiving a TCP SYN, the host will send a TCP SYNACK > and that needs to use the correct interface. Using the host's > address preferences, rather than doing it in a PCP library > which hopes to mimic the host's address preference, is far > safer. > > > > Jacni>: +1, the third party is a special case and the THIRD-PARTY > option seems to be fair enough for that. > In normal cases, the current layout is simpler. Thanks for your support of the separate THIRD_PARTY option. I wish we had more feedback from other people in the WG. > Wondering if it will > work better for nested NAT, maybe if the internal port is taken away as > well? Not sure. ;-) Can't remove the port, because (unlike STUN) the PCP source port is not the target-source-port on the host. -d > Cheers, > Jacni > > > > > A proxy would need to copy the source IP address of the > PCP request into the THIRD_PARTY option. I admit that is > a change to proxy behavior. But I don't understand how that > makes the proxy "far more complex". Can you elaborate? > > -d > > > > I propose to go back to 03 layout, i.e., the internal address > > is included in MAP and PEER OpCodes. > > > > The supposed simplicity in PCP clients is IMHO an API issue, > > I suggest to not improve it inside the protocol but to ask > > for an API routine which fills the field from the > > socket local address. Of course the section 7 is the right > > place to illustrate this. > > > > If to reduce the number of OpCodes is considered as a good > > thing I propose to reuse the External_AF PEER idea. > > BTW it should be in this case a good idea to make MAP and > > PEER OpCodes more similar, i.e., to maximize code sharing > > in programs. > > > > Regards > > > > Francis.Dupont@fdupont.fr > > _______________________________________________ > > 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 dwing@cisco.com Fri Feb 18 10:57:03 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8150B3A6E66 for ; Fri, 18 Feb 2011 10:57:03 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-rvyX-5ZVIY for ; Fri, 18 Feb 2011 10:57:02 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id AFAE53A6E1F for ; Fri, 18 Feb 2011 10:57:02 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAJ5PXk2rR7Ht/2dsb2JhbACXXIFljGRzn2ObN4VeBIUL X-IronPort-AV: E=Sophos;i="4.62,188,1297036800"; d="scan'208";a="262050684" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 18 Feb 2011 18:57:32 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1IIvUjX017924; Fri, 18 Feb 2011 18:57:31 GMT From: "Dan Wing" To: , References: <3155_1298014995_4D5E2313_3155_348950_1_94C682931C08B048B7A8645303FDC9F33C444C8C5F@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <3155_1298014995_4D5E2313_3155_348950_1_94C682931C08B048B7A8645303FDC9F33C444C8C5F@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 18 Feb 2011 10:57:29 -0800 Message-ID: <0ab201cbcf9d$b2414c30$16c3e490$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvPP3/kiIaFko4xRQSDjrN8nhXyAAAXXPhg Content-Language: en-us Subject: Re: [pcp] DNS Indirection X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 18:57:03 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange-ftgroup.com > Sent: Thursday, February 17, 2011 11:43 PM > To: pcp@ietf.org > Subject: [pcp] DNS Indirection > > Dear all, > > We would like to have a feedback about an open question we have in > http://tools.ietf.org/html/draft-bpw-pcp-dhcp-02 (Section 5.2): > > [Ed. Is there a value to consider a level of indirection (e.g., > SRV)? (1) to use an arbitrary port number for PCP Server instead > of the default port, (2) detect whether a security channel is in > use (using the transport protocol)] > > The current text assumes there is no indirection. There is value in SRV. But there is additional complexity and additional failure modes. To my knowledge the only (relatively) widely deployed application that uses SRV in real life is XMPP. Just last year, Cisco bumped into a bug where our devices borked SRV responses that were longer than expected. (1) would be neat to have, but I am not convinced we necessarily need it. (2) can be done without SRV; lots of protocols without SRV already negotiate or force upgrading to a secure channel. I vote for K.I.S.S. That is, don't do SRV. -d From bschlies@cisco.com Fri Feb 18 12:00:51 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8D313A6FD3 for ; Fri, 18 Feb 2011 12:00:51 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUIYrZ3hwIqi for ; Fri, 18 Feb 2011 12:00:50 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C79223A708A for ; Fri, 18 Feb 2011 12:00:40 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAERfXk2tJV2Y/2dsb2JhbACmKHOfU5s2hV4EhQuHBoNA X-IronPort-AV: E=Sophos;i="4.62,188,1297036800"; d="scan'208";a="217346510" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 18 Feb 2011 20:00:21 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p1IK0Lfx021661; Fri, 18 Feb 2011 20:00:21 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Feb 2011 14:00:21 -0600 Received: from 10.21.145.121 ([10.21.145.121]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([128.107.191.79]) with Microsoft Exchange Server HTTP-DAV ; Fri, 18 Feb 2011 20:00:21 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 18 Feb 2011 14:00:20 -0600 From: Benson Schliesser To: Dan Wing , , Message-ID: Thread-Topic: [pcp] DNS Indirection Thread-Index: AcvPP3/kiIaFko4xRQSDjrN8nhXyAAAXXPhgAAJhIno= In-Reply-To: <0ab201cbcf9d$b2414c30$16c3e490$@com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Feb 2011 20:00:21.0858 (UTC) FILETIME=[79682420:01CBCFA6] Subject: Re: [pcp] DNS Indirection X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 20:00:52 -0000 On 2/18/11 12:57 PM, "Dan Wing" wrote: > There is value in SRV. But there is additional complexity and additional > failure modes. To my knowledge the only (relatively) widely deployed > application that uses SRV in real life is XMPP. Microsoft Active Directory leverages SRV fairly extensively. But I understand your point. > I vote for K.I.S.S. That is, don't do SRV. I agree. If discovery isn't needed, e.g. because the server is naturally in the data path (like a NAT or Firewall), then I'm not sure the benefits (flexibility?) offset the risks of adding another layer that might fail. Cheers, -Benson From dthaler@microsoft.com Mon Feb 21 11:44:02 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 949823A716A for ; Mon, 21 Feb 2011 11:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.362 X-Spam-Level: X-Spam-Status: No, score=-110.362 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pL+gkiBGaC7o for ; Mon, 21 Feb 2011 11:43:56 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 653B63A716B for ; Mon, 21 Feb 2011 11:43:56 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 21 Feb 2011 11:44:38 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.270.2; Mon, 21 Feb 2011 11:44:37 -0800 Received: from TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com ([169.254.5.26]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Mon, 21 Feb 2011 11:44:37 -0800 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: February interim meeting info Thread-Index: AcvR/3YcHmsupeJoSd2xnrjJzMCUMg== Date: Mon, 21 Feb 2011 19:44:37 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653AF7C339@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653AF7C339TK5EX14MBXW605w_" MIME-Version: 1.0 Subject: [pcp] February interim meeting info X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 19:44:02 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653AF7C339TK5EX14MBXW605w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks to Dan Wing for providing WebEx hosting again... Topic: PCP Working Group Date: Tuesday, February 22, 2011 Time: 7:00 am, Pacific Standard Time (San Francisco, GMT-08:00) Meeting Num= ber: 200 288 330 Meeting Password: ietf ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D160191142&UID=3D0&PW=3DNNTUxM= DhjZmNh &RT=3DMiM0 2. Enter your name and email address. 3. Enter the meeting password: ietf 4. Click "Join Now". To view in other time zones or languages, please click the link: https://cisco.webex.com/ciscosales/j.php?ED=3D160191142&UID=3D0&PW=3DNNTUxM= DhjZmNh &ORT=3DMiM0 ---------------------------------------------------------------- ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes ---------------------------------------------------------------- The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area. Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.co= m/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/mc 2. On the left navigation bar, click "Support". You can contact me at: dwing@cisco.com 1-408-853 4197 To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link: https://cisco.webex.com/ciscosales/j.php?ED=3D160191142&UID=3D0&ICS=3DMI&LD= =3D1&RD=3D2 &ST=3D1&SHA2=3D6qSGHu/bnx5ltYGa/lWS6UVH6i9ma8Svt6Y1WyeEMO0=3D&RT=3DMiM0 The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://cisco.webex.com/ciscosales/systemdiagnosis.php Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+14085256800x200288330# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. --_000_9B57C850BB53634CACEC56EF4853FF653AF7C339TK5EX14MBXW605w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks to Dan= Wing for providing WebEx hosting again…

 

Topic: PCP Working G= roup

Date: Tuesday, February 22, 2011=

Time: 7:00 am, Pacific Standard Time= (San Francisco, GMT-08:00) Meeting Number: 200 288 330 Meeting Password: i= etf

 

-------------------------------------------------------

To join the online meeting (Now from mobile= devices!)

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

1. Go t= o

https:/= /cisco.webex.com/ciscosales/j.php?ED=3D160191142&UID=3D0&PW=3DNNTUx= MDhjZmNh

&RT=3DMiM0

2. Enter your name and email address.

3. Enter the meeting password: ietf

4. Click "Join Now".

 

To vi= ew in other time zones or languages, please click the link:

=

https://cisco.webex.com= /ciscosales/j.php?ED=3D160191142&UID=3D0&PW=3DNNTUxMDhjZmNh

&ORT=3DMiM0

 

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

ALERT:Toll-Free Dial Restrictions for (408) and (919) Area = Codes

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

 

The affected toll free numbers a= re: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for th= e RTP area.

 

Please dial the local access number for your area from= the list below:

- San Jose/Milpitas= (408) area: 525-6800

- RTP (919) are= a: 392-3330

 

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

To join the teleconference only

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

1. Dial into Cisco We= bEx (view all Global Access Numbers at http://cisco.com/en/US/about/do= ing_business/conferencing/index.html

2. Follow the prompts to enter the Meeting Number (listed above) or Acc= ess Code followed by the # sign.

 

San Jose, CA: +1.408.525.6800 RTP= : +1.919.392.3330

 <= /p>

US/Canada: +1.866.432.9903 United Kingdom: +44.2= 0.8824.0117

 

India: +91.80.4350.1111 Germany: +49.619.6773.9002

 

Japan: +81.3.5763.9394 China: +86.10.8515.5666

 

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

For assistance

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

1. Go to https://cisco= .webex.com/ciscosales/mc

2. On th= e left navigation bar, click "Support".

 

You can contac= t me at:

dwing@cisco.com

1-408-853= 4197

 

To add this meeting to your calendar program (for example M= icrosoft Outlook), click this link:

= https://cisco.webex.com/ciscosales= /j.php?ED=3D160191142&UID=3D0&ICS=3DMI&LD=3D1&RD=3D2

&ST=3D1&SHA2=3D6qSGHu/bnx5ltYGa= /lWS6UVH6i9ma8Svt6Y1WyeEMO0=3D&RT=3DMiM0

 

The playback of UCF (= Universal Communications Format) rich media files requires appropriate play= ers. To view this type of rich media files in the meeting, please check whe= ther you have the players installed on your computer by going to https://cisco.webe= x.com/ciscosales/systemdiagnosis.php

 

Sign up for a free trial = of WebEx

http://www.webex.com/go/mcemfreetrial =

 

http://www.webex.com

 

CCP:+14085= 256800x200288330#

 <= /p>

IMPORTANT NOTICE: This WebEx service includes a = feature that allows audio and any documents and other materials exchanged o= r viewed during the session to be recorded. By joining this session, you au= tomatically consent to such recordings. If you do not consent to the record= ing, discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such recordings = may be subject to discovery in the event of litigation.

= --_000_9B57C850BB53634CACEC56EF4853FF653AF7C339TK5EX14MBXW605w_-- From pselkirk@isc.org Mon Feb 21 18:34:06 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A43B43A67EA for ; Mon, 21 Feb 2011 18:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+y48GKFB1hZ for ; Mon, 21 Feb 2011 18:34:05 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id BBCC33A67E5 for ; Mon, 21 Feb 2011 18:34:04 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 78CD35F984C for ; Tue, 22 Feb 2011 02:34:32 +0000 (UTC) (envelope-from pselkirk@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10300) id 7FEDD216C22; Tue, 22 Feb 2011 02:34:30 +0000 (UTC) From: Paul Selkirk To: pcp@ietf.org Date: Tue, 22 Feb 2011 02:34:30 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [pcp] UPnP and IPv6 firewall X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 02:34:07 -0000 [Sent on behalf of Francis] The UPnP IPv6 firewall control API was publishd (URL http://upnp.org/specs/gw/UPnP-gw-WANIPv6FirewallControl-v1-Service.pdf) and IMHO it has some interesting ideas (and don't forget UPnP IGD 2.0 is a serious competitor to PCP). I suggest to get it waiting for base-05. Regards Francis.Dupont@fdupont.fr From pselkirk@isc.org Mon Feb 21 18:48:40 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8D53A67FC for ; Mon, 21 Feb 2011 18:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=1.133, BAYES_00=-2.599, GB_I_INVITATION=-2, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fy-XUJs5uRZu for ; Mon, 21 Feb 2011 18:48:39 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 7E2573A67F6 for ; Mon, 21 Feb 2011 18:48:39 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 2E2E1C9427; Tue, 22 Feb 2011 02:49:16 +0000 (UTC) (envelope-from pselkirk@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10300) id 2059C216C22; Tue, 22 Feb 2011 02:49:16 +0000 (UTC) From: Paul Selkirk To: "Dan Wing" In-Reply-To: <09c901cbcf88$e6606510$b3212f30$@com> (dwing@cisco.com) References: <201102101215.p1ACFkQp065426@givry.fdupont.fr> <00f401cbcc7f$a8c9ee30$fa5dca90$@com> <09c901cbcf88$e6606510$b3212f30$@com> Date: Tue, 22 Feb 2011 02:49:16 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] proposal about internal addresses X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 02:48:40 -0000 > Thanks for your support of the separate THIRD_PARTY option. I wish > we had more feedback from other people in the WG. FWIW, I fully support the THIRD_PARTY option. The "internal address" is only going to be used in DS-Lite and certain corner cases like your webcam. Otherwise, the internal address field makes no sense, and having it in the main header is an invitation to misconfiguration or outright mischief. paul From dwing@cisco.com Mon Feb 21 19:05:17 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B26E53A67F8 for ; Mon, 21 Feb 2011 19:05:17 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWjoNs1ZX5v2 for ; Mon, 21 Feb 2011 19:05:16 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id BA8AA3A67FD for ; Mon, 21 Feb 2011 19:05:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=652; q=dns/txt; s=iport; t=1298343960; x=1299553560; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=OAkxUM+E/zuhN/g8uSXXfIfqe3AvTU79i/QYZnoR0PU=; b=MZD2pT5qwiU+HlIpy+F0wZlu+qh9moLj/QTssutf74gJNuKx0z0ILrO9 pOzSKBm4uGo1o6DKaxy7jfMMeFB5wzD5MOnKbO45xdMCHkkUm+aNaJ9YS /6crPBiJsxjnSlbpDNc569YQns7/ipjeL+w3mZheC+OiQFbApltObEQMr Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQHAF+3Yk2rR7Ht/2dsb2JhbACYNYEmjGdzn0+bZ4VeBIUN X-IronPort-AV: E=Sophos;i="4.62,204,1297036800"; d="scan'208";a="263424541" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 22 Feb 2011 03:05:45 +0000 Received: from dwingWS (sjc-vpn4-871.cisco.com [10.21.83.102]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1M35jKI005201; Tue, 22 Feb 2011 03:05:45 GMT From: "Dan Wing" To: Date: Mon, 21 Feb 2011 19:05:45 -0800 Message-ID: <135801cbd23d$65f20930$31d61b90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvSPWWvDkRZx0w9Qwqpjf751X6UAg== Content-Language: en-us Cc: draft-ietf-pcp-base@tools.ietf.org Subject: [pcp] -05 posted X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 03:05:17 -0000 I just posted -05. Changes are shown in Appendix A.1. http://tools.ietf.org/html/draft-ietf-pcp-base-05 The diffs are a bit difficult this time because the three processing sections (for General, MAP, and PEER) have been re-organized to discuss client generating a request, server processing the request, and client processing the response. Unresolved, in this version, is what to do with the THIRD_PARTY option for the MAP4 and MAP6 OpCodes. The text is (roughly) the same as -04 regarding THIRD_PARTY, and the OpCode is still in the document. We need to discuss THIRD_PARTY on tomorrow's interim meeting, among other topics. -d From Internet-Drafts@ietf.org Mon Feb 21 19:15:02 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714F73A6807; Mon, 21 Feb 2011 19:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.63 X-Spam-Level: X-Spam-Status: No, score=-102.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zw3UO4HWyAdQ; Mon, 21 Feb 2011 19:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9992C3A6804; Mon, 21 Feb 2011 19:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110222031501.8965.72030.idtracker@localhost> Date: Mon, 21 Feb 2011 19:15:01 -0800 Cc: pcp@ietf.org Subject: [pcp] I-D Action:draft-ietf-pcp-base-05.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 03:15:02 -0000 --NextPart 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 : Port Control Protocol (PCP) Author(s) : D. Wing, et al. Filename : draft-ietf-pcp-base-05.txt Pages : 55 Date : 2011-02-21 Port Control Protocol allows a host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall to an IPv6 or IPv4 host, and also allows a host to optimize its NAT keepalive messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcp-base-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-21190134.I-D@ietf.org> --NextPart-- From xiaohong.deng@orange-ftgroup.com Mon Feb 21 20:19:21 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C66F53A680C for ; Mon, 21 Feb 2011 20:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pURk74x8nViD for ; Mon, 21 Feb 2011 20:19:20 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 6986D3A67F3 for ; Mon, 21 Feb 2011 20:19:20 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 92089858003; Tue, 22 Feb 2011 05:25:24 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 86D1C760003; Tue, 22 Feb 2011 05:25:24 +0100 (CET) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Feb 2011 05:20:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBD247.C4DCD56C" Date: Tue, 22 Feb 2011 12:19:58 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC015384D5@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653AF7C339@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE:[pcp] I-D Action:draft-ietf-pcp-base-05.txt Thread-Index: AcvSR8RPM/ohIgkfRBqOVZ0jiBElUA== References: <9B57C850BB53634CACEC56EF4853FF653AF7C339@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> From: To: , X-OriginalArrivalTime: 22 Feb 2011 04:20:02.0842 (UTC) FILETIME=[C6B47FA0:01CBD247] Subject: Re: [pcp] I-D Action:draft-ietf-pcp-base-05.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 04:19:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD247.C4DCD56C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello Dan, =20 The requested lifetime field is missing in the MAP OpCode Request format, in Figure9. =20 =20 Xiaohong ________________________________ * From: Internet-Drafts at ietf.org =20 * To: i-d-announce at ietf.org * Cc: pcp at ietf.org =20 * Date: Mon, 21 Feb 2011 19:15:01 -0800=20 * List-id: PCP wg discussion list =20 ________________________________ 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 : Port Control Protocol (PCP) Author(s) : D. Wing, et al. Filename : draft-ietf-pcp-base-05.txt Pages : 55 Date : 2011-02-21 Port Control Protocol allows a host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall to an IPv6 or IPv4 host, and also allows a host to optimize its NAT keepalive messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =20 =09 ------_=_NextPart_001_01CBD247.C4DCD56C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hello=20 Dan,

 

The=20 requested lifetime field is missing in the MAP OpCode Request format, in = Figure9.  =20

  

Xiaohong

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           : Port Control Protocol (PCP)
	Author(s)       : D. Wing, et al.
	Filename        : draft-ietf-pcp-base-05.txt
	Pages           : 55
	Date            : 2011-02-21

Port Control Protocol allows a host to control how incoming IPv6 or
IPv4 packets are translated and forwarded by a network address
translator (NAT) or simple firewall to an IPv6 or IPv4 host, and also
allows a host to optimize its NAT keepalive messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-05=
.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcp-base= -05.txt>=20
------_=_NextPart_001_01CBD247.C4DCD56C-- From jacniq@gmail.com Mon Feb 21 22:51:28 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D565A3A67E3 for ; Mon, 21 Feb 2011 22:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBAv3CwTzd5O for ; Mon, 21 Feb 2011 22:51:23 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 1AF653A67A4 for ; Mon, 21 Feb 2011 22:51:23 -0800 (PST) Received: by ywi6 with SMTP id 6so1604450ywi.31 for ; Mon, 21 Feb 2011 22:52:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1cBDSaDnshfhZL9DP/ms3Cx7c7CduzbG+jCUzGeBf3c=; b=gBdntsE0Tsixre5r5ZITYkyTliR1ss7vIRet1cUyOSgkVNCL/6/M0b9xkS7Pq1ZzV0 3tRR83RkO1kIyyxanqxvCfIBIN8yUwifPNsvneAaa5pLAhnDM0sECR69PPuOb1Qt7Ed8 4g921mW263enNo4rObQeflK3G1bPamXq6MNuU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cJlxTM25JiMgz19YNKZ2t0LzZXF0Gr2qqDY/rlhADgkBSO1mMa0Xs0dUL4hDfkCzAb dT5JTvBk6plpENSN+qH0uEYL9h1VB1mxUQ2mNtdlm7zlnUC4Yl0UCeiZMUffyO9Cz7Nw bFsy1AXvTq2HLL3SY3n4amxmH/J760YdpasVw= MIME-Version: 1.0 Received: by 10.236.110.6 with SMTP id t6mr4175142yhg.49.1298357526342; Mon, 21 Feb 2011 22:52:06 -0800 (PST) Received: by 10.147.41.16 with HTTP; Mon, 21 Feb 2011 22:52:06 -0800 (PST) In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC015384D5@ch-mailsrv.rd.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653AF7C339@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> <0962B0BEF842A24191AD9BE41A8DD2FC015384D5@ch-mailsrv.rd.francetelecom.fr> Date: Tue, 22 Feb 2011 14:52:06 +0800 Message-ID: From: Jacni Qin To: xiaohong.deng@orange-ftgroup.com Content-Type: multipart/alternative; boundary=0023547c9015262fdd049cd96b49 Cc: pcp@ietf.org Subject: Re: [pcp] I-D Action:draft-ietf-pcp-base-05.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 06:51:29 -0000 --0023547c9015262fdd049cd96b49 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 22, 2011 at 12:19 PM, wrote: > Hello Dan, > > > > The requested lifetime field is missing in the MAP OpCode Request format, > in Figure9. > Jacni>: The lifetime field was removed from the common header... > > > Xiaohong > > ------------------------------ > > - *From*: Internet-Drafts at ietf.org > - *To*: i-d-announce at ietf.org > - *Cc*: pcp at ietf.org > - *Date*: Mon, 21 Feb 2011 19:15:01 -0800 > - *List-id*: PCP wg discussion list > > ------------------------------ > > 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 : Port Control Protocol (PCP) > Author(s) : D. Wing, et al. > Filename : draft-ietf-pcp-base-05.txt > Pages : 55 > Date : 2011-02-21 > > Port Control Protocol allows a host to control how incoming IPv6 or > IPv4 packets are translated and forwarded by a network address > translator (NAT) or simple firewall to an IPv6 or IPv4 host, and also > allows a host to optimize its NAT keepalive messages. > > A URL for this Internet-Draft is:http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-05.txt > > Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > > --0023547c9015262fdd049cd96b49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 22, 2011 at 12:19 PM, <xiaohong.deng@orange-ftgroup.com>= wrote:

=

Hello=20 Dan,

=C2=A0

The=20 requested lifetime field is missing in the MAP OpCode Request format, in=20 Figure9.=C2=A0=C2=A0=20

<= /h1>

Jacni>: Th= e lifetime field was removed from the common header...

=C2=A0=C2=A0

Xiaohong

 

A New Internet-Draft is availa=
ble from the on-line Internet-Drafts directories.
This draft is a work item of the Port Control Protocol Working Group of the=
 IETF.


	Title           : Port Control Protocol (PCP)
	Author(s)       : D. Wing, et al.
	Filename        : draft-ietf-pcp-base-05.txt
	Pages           : 55
	Date            : 2011-02-21

Port Control Protocol allows a host to control how incoming IPv6 or
IPv4 packets are translated and forwarded by a network address
translator (NAT) or simple firewall to an IPv6 or IPv4 host, and also
allows a host to optimize its NAT keepalive messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draf=
t-ietf-pcp-base-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-dra= fts/draft-ietf-pcp-base-05.txt>=20
<= /font>

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


--0023547c9015262fdd049cd96b49-- From xiaohong.deng@orange-ftgroup.com Mon Feb 21 22:59:16 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F77C3A677C for ; Mon, 21 Feb 2011 22:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5cIg3L8jCw2 for ; Mon, 21 Feb 2011 22:59:15 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id C1AE43A67A4 for ; Mon, 21 Feb 2011 22:59:14 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 96E49858001; Tue, 22 Feb 2011 08:05:19 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 8C97C760003; Tue, 22 Feb 2011 08:05:19 +0100 (CET) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Feb 2011 07:59:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBD25E.1BF658BC" Date: Tue, 22 Feb 2011 14:59:54 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0153851A@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [pcp] I-D Action:draft-ietf-pcp-base-05.txt Thread-Index: AcvSXQe2uqo0LtsWTvmzCKepUPnxcQAAG3hQ References: <9B57C850BB53634CACEC56EF4853FF653AF7C339@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com><0962B0BEF842A24191AD9BE41A8DD2FC015384D5@ch-mailsrv.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 22 Feb 2011 06:59:57.0995 (UTC) FILETIME=[1DDCA7B0:01CBD25E] Cc: pcp@ietf.org Subject: Re: [pcp] I-D Action:draft-ietf-pcp-base-05.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 06:59:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD25E.1BF658BC Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable On Tue, Feb 22, 2011 at 12:19 PM, wrote: Hello Dan, =20 The requested lifetime field is missing in the MAP OpCode Request format, in Figure9. =20 Jacni>: The lifetime field was removed from the common header... =20 I was not talking about the common header and the figure 9 is about MAP OpCode Request header. =20 Xiaohong =09 ________________________________ * From: Internet-Drafts at ietf.org =20 * To: i-d-announce at ietf.org =20 * Cc: pcp at ietf.org =20 * Date: Mon, 21 Feb 2011 19:15:01 -0800=20 * List-id: PCP wg discussion list =20 ________________________________ 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. =09 =09 Title : Port Control Protocol (PCP) Author(s) : D. Wing, et al. Filename : draft-ietf-pcp-base-05.txt Pages : 55 Date : 2011-02-21 =09 Port Control Protocol allows a host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall to an IPv6 or IPv4 host, and also allows a host to optimize its NAT keepalive messages. =09 A URL for this Internet-Draft is: =09 http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-05.txt =09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =09 =20 =09 _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp =09 =09 ------_=_NextPart_001_01CBD25E.1BF658BC Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 22, 2011 at 12:19 PM, <xiaohong.deng@orange-ftg= roup.com>=20 wrote:

Hello Dan,

 

The requested lifetime field is missing in the MAP OpCode = Request=20 format, in Figure9.  =20 =

Jacni>: The lifetime field was = removed=20 from the common header... 
 
 I was not talking about the common = header and the=20 figure 9 is about MAP OpCode Request = header.

  

Xiaohong

 

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           : Port Control Protocol (PCP)
	Author(s)       : D. Wing, et al.
	Filename        : draft-ietf-pcp-base-05.txt
	Pages           : 55
	Date            : 2011-02-21

Port Control Protocol allows a host to control how incoming IPv6 or
IPv4 packets are translated and forwarded by a network address
translator (NAT) or simple firewall to an IPv6 or IPv4 host, and also
allows a host to optimize its NAT keepalive messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-05=
.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcp-base= -05.txt>=20

_____________________________________= __________
pcp=20 mailing list
pcp@ietf.org
https://www.ietf.org/mailman/listinfo/pcp


------_=_NextPart_001_01CBD25E.1BF658BC-- From jacniq@gmail.com Mon Feb 21 23:06:34 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E23EF3A67D9 for ; Mon, 21 Feb 2011 23:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.009 X-Spam-Level: X-Spam-Status: No, score=-3.009 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfrNvS-GBsyQ for ; Mon, 21 Feb 2011 23:06:33 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 18DAB3A677C for ; Mon, 21 Feb 2011 23:06:33 -0800 (PST) Received: by ywi6 with SMTP id 6so1608872ywi.31 for ; Mon, 21 Feb 2011 23:07:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=12GiHbdFZODKVazZi7jHh7IqoEY5Tzk11CHsdzO1ylk=; b=grCWe8OpEzDetw3C7L8Mqhv3vw7J5UdyorjBkSWc0u7UzmUmDclbuBv3RIrWrh5BkP d0vTbWB7C2HV2hPPj44ALXguNvpPBDEarMPxGGkFrb482AUGo8UJdPHP0HZCTNFrekp6 mcQNcSV66c6N0IUhED5EvkqsFz6LK63fvyW7c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pecbAwG+1Gs80A1+iWi4m4fiIeEtgQSfmQnOJtR0jhxyQLArZIqfTtIXs0EJStEJRW jQy1alA0Ht5mbOqYFr/I80SUHCk81M6cFMqfCmnCE2tgQQ2J7N0rMpGHK4cyUo1pk+f9 inhakeM1N7AE9hNKPabgAVukB4zD05pd9dbaE= MIME-Version: 1.0 Received: by 10.91.1.2 with SMTP id d2mr3066621agi.43.1298358436399; Mon, 21 Feb 2011 23:07:16 -0800 (PST) Received: by 10.147.41.16 with HTTP; Mon, 21 Feb 2011 23:07:16 -0800 (PST) In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC0153851A@ch-mailsrv.rd.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653AF7C339@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> <0962B0BEF842A24191AD9BE41A8DD2FC015384D5@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0153851A@ch-mailsrv.rd.francetelecom.fr> Date: Tue, 22 Feb 2011 15:07:16 +0800 Message-ID: From: Jacni Qin To: xiaohong.deng@orange-ftgroup.com Content-Type: multipart/alternative; boundary=0016362842e4648aec049cd9a148 Cc: pcp@ietf.org Subject: Re: [pcp] I-D Action:draft-ietf-pcp-base-05.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 07:06:35 -0000 --0016362842e4648aec049cd9a148 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 22, 2011 at 2:59 PM, wrote: > On Tue, Feb 22, 2011 at 12:19 PM, wrote: > > Hello Dan, >> >> >> >> The requested lifetime field is missing in the MAP OpCode Request format, >> in Figure9. >> > Jacni>: The lifetime field was removed from the common header... > > I was not talking about the common header and the figure 9 is about MAP > OpCode Request header. > > Jacni>: Sorry, I read your carelessly. Without it, the client can't easily delete a given mapping. > >> >> Xiaohong >> >> ------------------------------ >> >> - *From*: Internet-Drafts at ietf.org >> - *To*: i-d-announce at ietf.org >> - *Cc*: pcp at ietf.org >> - *Date*: Mon, 21 Feb 2011 19:15:01 -0800 >> - *List-id*: PCP wg discussion list >> >> ------------------------------ >> >> 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 : Port Control Protocol (PCP) >> Author(s) : D. Wing, et al. >> Filename : draft-ietf-pcp-base-05.txt >> Pages : 55 >> Date : 2011-02-21 >> >> Port Control Protocol allows a host to control how incoming IPv6 or >> IPv4 packets are translated and forwarded by a network address >> translator (NAT) or simple firewall to an IPv6 or IPv4 host, and also >> allows a host to optimize its NAT keepalive messages. >> >> A URL for this Internet-Draft is:http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-05.txt >> >> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >> >> > --0016362842e4648aec049cd9a148 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 22, 2011 at 2:59 PM, <xiaohong.deng@orange-ftgroup.com><= /span> wrote:
On Tue, Feb 22, 2011 at 12:19 PM, <xiaohong.deng@orang= e-ftgroup.com>=20 wrote:

Hello Dan,

=C2=A0

The requested lifetime field is missing in the MAP OpCode= Request=20 format, in Figure9.=C2=A0=C2=A0=20

Jacni>: The lifetime field was = removed=20 from the common header...=C2=A0
=C2=A0
=C2=A0I=C2=A0was not talking about the comm= on header and the=20 figure 9 is about MAP OpCode Request header.<= /div>
Jacni>: Sorry, I read your carelessly. Without it, the client can= 't easily delete a given mapping.

= =C2=A0=C2=A0

Xiaohong

 

A New Internet-Draft is available from the on-line Internet-D=
rafts directories.
This draft is a work item of the Port Control Protocol Working Group of the=
 IETF.


	Title           : Port Control Protocol (PCP)
	Author(s)       : D. Wing, et al.
	Filename        : draft-ietf-pcp-base-05.txt
	Pages           : 55
	Date            : 2011-02-21

Port Control Protocol allows a host to control how incoming IPv6 or
IPv4 packets are translated and forwarded by a network address
translator (NAT) or simple firewall to an IPv6 or IPv4 host, and also
allows a host to optimize its NAT keepalive messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draf=
t-ietf-pcp-base-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet= -drafts/draft-ietf-pcp-base-05.txt>=20

_____________________________________________= __
pcp=20 mailing list
pcp@i= etf.org
https://www.ietf.org/mailman/listinfo/pcp



--0016362842e4648aec049cd9a148-- From xiaohong.deng@orange-ftgroup.com Mon Feb 21 23:13:02 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9203A67ED for ; Mon, 21 Feb 2011 23:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.764 X-Spam-Level: X-Spam-Status: No, score=-0.764 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxrqBUzDX0tE for ; Mon, 21 Feb 2011 23:12:47 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 5713E3A67EF for ; Mon, 21 Feb 2011 23:12:43 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F22FCFC4012; Tue, 22 Feb 2011 08:13:30 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id E0810FC400D; Tue, 22 Feb 2011 08:13:30 +0100 (CET) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Feb 2011 08:13:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBD25F.FD7B14A7" Date: Tue, 22 Feb 2011 15:13:21 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0156B94A@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [pcp] I-D Action:draft-ietf-pcp-base-05.txt Thread-Index: AcvSXyZwLr4PVdx0SpWh1oCoKyYR0QAADzaQ References: <9B57C850BB53634CACEC56EF4853FF653AF7C339@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com><0962B0BEF842A24191AD9BE41A8DD2FC015384D5@ch-mailsrv.rd.francetelecom.fr><0962B0BEF842A24191AD9BE41A8DD2FC0153851A@ch-mailsrv.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 22 Feb 2011 07:13:25.0280 (UTC) FILETIME=[FF0A9200:01CBD25F] Cc: pcp@ietf.org Subject: Re: [pcp] I-D Action:draft-ietf-pcp-base-05.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 07:13:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBD25F.FD7B14A7 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 On Tue, Feb 22, 2011 at 2:59 PM, wrote: =09 On Tue, Feb 22, 2011 at 12:19 PM, wrote: =09 Hello Dan, =20 The requested lifetime field is missing in the MAP OpCode Request format, in Figure9. =20 Jacni>: The lifetime field was removed from the common header...=20 =20 I was not talking about the common header and the figure 9 is about MAP OpCode Request header. Jacni>: Sorry, I read your carelessly. Without it, the client can't easily delete a given mapping.=20 =20 Yes, that's why it made me suprised when the first time I noticed it,but I guess it's just a typo because there is an explaination of the requested lifetime field right after the figure 9. =20 =09 =20 Xiaohong =09 ________________________________ * From: Internet-Drafts at ietf.org =20 * To: i-d-announce at ietf.org =20 * Cc: pcp at ietf.org =20 * Date: Mon, 21 Feb 2011 19:15:01 -0800=20 * List-id: PCP wg discussion list =20 ________________________________ 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. =09 =09 Title : Port Control Protocol (PCP) Author(s) : D. Wing, et al. Filename : draft-ietf-pcp-base-05.txt Pages : 55 Date : 2011-02-21 =09 Port Control Protocol allows a host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall to an IPv6 or IPv4 host, and also allows a host to optimize its NAT keepalive messages. =09 A URL for this Internet-Draft is: =09 http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-05.txt =09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =09 =20 =09 =09 _______________________________________________ pcp mailing list pcp@ietf.org =09 https://www.ietf.org/mailman/listinfo/pcp =09 =09 ------_=_NextPart_001_01CBD25F.FD7B14A7 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
 
On Tue, Feb 22, 2011 at 2:59 PM, <xiaohong.deng@orange-ftg= roup.com>=20 wrote:
On Tue, Feb 22, 2011 at 12:19 PM, <xiaohong.deng@orange-ftgroup.com>=20 wrote:

Hello Dan,

 

The requested lifetime field is missing in the MAP = OpCode Request=20 format, in Figure9.  =20 =

Jacni>: The lifetime field = was=20 removed from the common header... 
 
 I was not talking about the = common=20 header and the figure 9 is about MAP OpCode Request=20 = header.
Jacni>: Sorry, I read your = carelessly.=20 Without it, the client can't easily delete a given mapping. 
 
Yes, that's why it = made me=20 suprised when the first time I noticed it,but I guess = it's just=20 a typo because there is an explaination of the requested lifetime field = right after=20 the figure=20 = 9.  
=

  

Xiaohong

 

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           : Port Control Protocol (PCP)
	Author(s)       : D. Wing, et al.
	Filename        : draft-ietf-pcp-base-05.txt
	Pages           : 55
	Date            : 2011-02-21

Port Control Protocol allows a host to control how incoming IPv6 or
IPv4 packets are translated and forwarded by a network address
translator (NAT) or simple firewall to an IPv6 or IPv4 host, and also
allows a host to optimize its NAT keepalive messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-05=
.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcp-base= -05.txt>=20

_____________________________________= __________
pcp=20 mailing list
pcp@ietf.org
https://www.ietf.org/mailman/listinfo/pcp



= ------_=_NextPart_001_01CBD25F.FD7B14A7-- From xiaohong.deng@orange-ftgroup.com Mon Feb 21 23:18:25 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8773A67E7 for ; Mon, 21 Feb 2011 23:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.806 X-Spam-Level: X-Spam-Status: No, score=-2.806 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nfI0Mqg0upS for ; Mon, 21 Feb 2011 23:18:24 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 7A0D53A677C for ; Mon, 21 Feb 2011 23:18:24 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 94F2C760007; Tue, 22 Feb 2011 08:24:29 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 8CCE3760002; Tue, 22 Feb 2011 08:24:29 +0100 (CET) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Feb 2011 08:19:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Feb 2011 15:19:03 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0156B94F@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC015384FA@ch-mailsrv.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [pcp] proposal about internal addresses Thread-Index: AcvSWu75AEbbLKgTTtSQhlGW/wfqkAAAEYWg References: <0ab201cbcf9d$b2414c30$16c3e490$@com> <0962B0BEF842A24191AD9BE41A8DD2FC015384FA@ch-mailsrv.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 22 Feb 2011 07:19:08.0002 (UTC) FILETIME=[CB51CC20:01CBD260] Cc: pcp@ietf.org Subject: Re: [pcp] proposal about internal addresses X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 07:18:25 -0000 |THIRD_PARTY makes a normal PCP client easier, because the PCP=20 |client doesn't need any code to cause its PCP request to=20 |egress the proper interface. This is important because after=20 |using MAP and receiving a TCP SYN, the host will send a TCP=20 |SYNACK and that needs to use the correct interface. Using the=20 |host's address preferences, rather than doing it in a PCP=20 |library which hopes to mimic the host's address preference, is=20 |far safer. =3D=3D>Agreed. |A proxy would need to copy the source IP address of the PCP=20 |request into the THIRD_PARTY option. I admit that is a change=20 |to proxy behavior. But I don't understand how that makes the=20 |proxy "far more complex". Can you elaborate? =3D=3D> I don't see it makes the proxy far more complex, the PCP proxy can simply copy the source address of the received packet into the THIRD_PARTY option. But due to the deeper header decoding, it may impact the PCP header decoding speed of the PCP server when the internal address is in the optional header instead of=20 in the fixed Opcode specified area. Therefore the PCP server, especially=20 those who are embeded in the CGN, may need hardware to accelerate=20 packet decoding. Hence, THIRD_PARTY option might be benificial in future, but I wonder=20 if it's too eairly to move internal ip address into this option. | |-d From trac@tools.ietf.org Tue Feb 22 06:50:21 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BFFB3A6903 for ; Tue, 22 Feb 2011 06:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7P-kz63hnEZ for ; Tue, 22 Feb 2011 06:50:19 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 71BCA3A68F6 for ; Tue, 22 Feb 2011 06:50:19 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PrtZu-00042e-8R; Tue, 22 Feb 2011 06:51:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dthaler@microsoft.com, dwing@cisco.com X-Trac-Project: pcp Date: Tue, 22 Feb 2011 14:51:02 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/10#comment:4 Message-ID: <062.068e56a394e29ed17046caa6b348da3e@tools.ietf.org> References: <053.e4eb3896c167b7dd11a6f1bfffcd9fdb@tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <053.e4eb3896c167b7dd11a6f1bfffcd9fdb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dthaler@microsoft.com, dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #10: Firewall (address-dependent filter) support X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 14:50:21 -0000 #10: Firewall (address-dependent filter) support Changes (by dthaler@…): * component: UPnP interop => Firewall -- --------------------------------+------------------------------------------- Reporter: dwing@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: Firewall | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Tue Feb 22 07:52:31 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCE163A689B for ; Tue, 22 Feb 2011 07:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6PW4VriZRXC for ; Tue, 22 Feb 2011 07:52:31 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C4BB03A6892 for ; Tue, 22 Feb 2011 07:52:30 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PruY7-0000BS-85; Tue, 22 Feb 2011 07:53:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 22 Feb 2011 15:53:15 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/5#comment:2 Message-ID: <055.9ec65ded056a75cb2b51396d7cd1e219@tools.ietf.org> References: <046.a9a020e73872fae1ac8624b71547ce81@tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <046.a9a020e73872fae1ac8624b71547ce81@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dthaler@microsoft.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #5: Channel security mechanism X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 15:52:32 -0000 #5: Channel security mechanism Comment(by dthaler@…): Things you can do with a SYN: nothing needed Things you cannot do with a SYN: * Things that affect yourself: mitigate with normal source spoofing mitigations * Things that affect others: webcam case, ISP managing own device case -- --------------------------------+------------------------------------------- Reporter: multiple | Owner: Type: enhancement | Status: new Priority: critical | Milestone: Component: base | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Tue Feb 22 08:14:20 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76F383A690D for ; Tue, 22 Feb 2011 08:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.201 X-Spam-Level: X-Spam-Status: No, score=-102.201 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QVRQi3mwkii for ; Tue, 22 Feb 2011 08:14:19 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C4DC73A68EE for ; Tue, 22 Feb 2011 08:14:19 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PrutD-0000Vu-B7; Tue, 22 Feb 2011 08:15:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 22 Feb 2011 16:15:03 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/28#comment:1 Message-ID: <055.8bf26a5b50a7a2cd760b7853367f5056@tools.ietf.org> References: <046.fbbd11187f5ec1ce2f12aba141f6977f@tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <046.fbbd11187f5ec1ce2f12aba141f6977f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, dthaler@microsoft.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #28: UPnP/NAT-PMP Interop functionality in base spec or separate specs X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 16:14:20 -0000 #28: UPnP/NAT-PMP Interop functionality in base spec or separate specs Changes (by dthaler@…): * owner: => dwing@… Comment: Agreed on February 2011 interim call to move into a separate spec for next rev. -- --------------------------------+------------------------------------------- Reporter: multiple | Owner: dwing@… Type: task | Status: new Priority: minor | Milestone: Component: UPnP interop | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: pcp From dwing@cisco.com Tue Feb 22 08:24:24 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F7303A6919 for ; Tue, 22 Feb 2011 08:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7Bms7quQTIw for ; Tue, 22 Feb 2011 08:24:22 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 2D70F3A692D for ; Tue, 22 Feb 2011 08:24:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2248; q=dns/txt; s=iport; t=1298391906; x=1299601506; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=wRXogGRNtVW9jZuw4yQWAVkB6mqk2W892OYFsQwDTyE=; b=CpLyQZXYg9Bm1+7Wn9h4SCdqlvQGZm2CqzGW537QyQcUrJLdid1RFzdy nWHB8pB4pzMgpPV9QfPDISdtvqpRE3KK1aFdFEarJWDffxMrRlHjokXaS /MmElG4bkDaE4fpTOIHvsWDv6FwglLJlVHaGiLfdQnfMZm1qTso68APdD Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIBALNxY02rR7Ht/2dsb2JhbACXVD+BJoxlc6Ium1iFXgSFDY1R X-IronPort-AV: E=Sophos;i="4.62,207,1297036800"; d="scan'208";a="313796846" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 22 Feb 2011 16:25:05 +0000 Received: from dwingWS ([10.89.9.183]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1MGP4Kn028163; Tue, 22 Feb 2011 16:25:05 GMT From: "Dan Wing" To: References: <9B57C850BB53634CACEC56EF4853FF653AF7C339@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com><0962B0BEF842A24191AD9BE41A8DD2FC015384D5@ch-mailsrv.rd.francetelecom.fr><0962B0BEF842A24191AD9BE41A8DD2FC0153851A@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0156B94A@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC0156B94A@ch-mailsrv.rd.francetelecom.fr> Date: Tue, 22 Feb 2011 08:25:04 -0800 Message-ID: <14a801cbd2ad$105719f0$31054dd0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvSXyZwLr4PVdx0SpWh1oCoKyYR0QAADzaQABKlWQA= Content-Language: en-us Cc: pcp@ietf.org Subject: [pcp] Figure 9: [was RE: I-D Action:draft-ietf-pcp-base-05.txt] X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 16:24:24 -0000 > -----Original Message----- > From: xiaohong.deng@orange-ftgroup.com [mailto:xiaohong.deng@orange- > ftgroup.com] > Sent: Monday, February 21, 2011 11:13 PM > To: jacniq@gmail.com > Cc: dwing@cisco.com; pcp@ietf.org > Subject: RE: [pcp] I-D Action:draft-ietf-pcp-base-05.txt > > > > On Tue, Feb 22, 2011 at 2:59 PM, ftgroup.com> wrote: > > > On Tue, Feb 22, 2011 at 12:19 PM, ftgroup.com> wrote: > > > > Hello Dan, > > > > The requested lifetime field is missing in the > MAP OpCode Request format, in Figure9. > > > Jacni>: The lifetime field was removed from the > common header... > > I was not talking about the common header and the > figure 9 is about MAP OpCode Request header. > > Jacni>: Sorry, I read your carelessly. Without it, the client > can't easily delete a given mapping. > > Yes, that's why it made me suprised when the first time I noticed > it,but I guess it's just a typo because there is an explaination of the > requested lifetime field right after the figure 9. Thanks for catching it. It was an editing error. Figure 9 should have included a 'requested lifetime'. The corrected packet layout is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Reserved (24 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Requested external IP address (32 or 128, depending on OpCode): : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | internal port | requested external port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: MAP OpCode Request Packet Format This will be fixed in -06. -d From trac@tools.ietf.org Tue Feb 22 08:26:52 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8CC33A6910 for ; Tue, 22 Feb 2011 08:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQdeSo1UQv44 for ; Tue, 22 Feb 2011 08:26:51 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3D4F93A68EE for ; Tue, 22 Feb 2011 08:26:51 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Prv5M-0008Em-1F; Tue, 22 Feb 2011 08:27:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 22 Feb 2011 16:27:36 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/33#comment:1 Message-ID: <062.f1c707f2a22aa2da446a73c73ce502f8@tools.ietf.org> References: <053.7ee030084aa57871c688fbc788671e28@tools.ietf.org> X-Trac-Ticket-ID: 33 In-Reply-To: <053.7ee030084aa57871c688fbc788671e28@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dthaler@microsoft.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #33: 3rd party mappings: create/destroy X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 16:26:52 -0000 #33: 3rd party mappings: create/destroy Comment(by dthaler@…): Consensus that this is needed, need to decide whether in option or main header. Issue is possible buggy clients, as observed with SIP, that put in IP address of the wrong interface. Strawman is THIRD_PARTY is an option, but there's an order specified for options. Downside is that IW-GW needs special handling, but already has to have special handling either way. Alternative is to use all-zeroes address in main header. Will send question to mailing list. See also issue #5 about security. -- -----------------------------+---------------------------------------------- Reporter: dwing@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: -----------------------------+---------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Tue Feb 22 08:40:19 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B3E33A6915 for ; Tue, 22 Feb 2011 08:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHcmrCY24tyU for ; Tue, 22 Feb 2011 08:40:18 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AE1BE3A6940 for ; Tue, 22 Feb 2011 08:40:18 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PrvIN-00037n-5u; Tue, 22 Feb 2011 08:41:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 22 Feb 2011 16:41:03 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/5#comment:3 Message-ID: <055.a90cc088ebad300cf431504d75c665f4@tools.ietf.org> References: <046.a9a020e73872fae1ac8624b71547ce81@tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <046.a9a020e73872fae1ac8624b71547ce81@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dthaler@microsoft.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #5: Channel security mechanism X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 16:40:19 -0000 #5: Channel security mechanism Changes (by dthaler@…): * status: new => closed * resolution: => fixed Comment: Strawman is: PCP not capable of opening ports for another subscriber. Section 8.8 covers opening ports for another IP within same subscriber IP address range, and no additional security is present for that case. Need to update "administrative interface" text to be clear that's non-PCP (e.g., web interface). -- --------------------------------+------------------------------------------- Reporter: multiple | Owner: Type: enhancement | Status: closed Priority: critical | Milestone: Component: base | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: pcp From mohamed.boucadair@orange-ftgroup.com Tue Feb 22 09:03:33 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB59B3A6930 for ; Tue, 22 Feb 2011 09:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.171 X-Spam-Level: X-Spam-Status: No, score=-3.171 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-ZgGe-hEv6Y for ; Tue, 22 Feb 2011 09:03:33 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id C1D2B3A6924 for ; Tue, 22 Feb 2011 09:03:32 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 906EC18C122; Tue, 22 Feb 2011 18:04:16 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 715F235C018; Tue, 22 Feb 2011 18:04:16 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Tue, 22 Feb 2011 18:04:16 +0100 From: To: Dan Wing , "pcp@ietf.org" Date: Tue, 22 Feb 2011 18:04:14 +0100 Thread-Topic: [pcp] DNS Indirection Thread-Index: AcvPP3/kiIaFko4xRQSDjrN8nhXyAAAXXPhgAMVZcDA= Message-ID: <20027_1298394256_4D63EC90_20027_174071_1_94C682931C08B048B7A8645303FDC9F33C45773671@PUEXCB1B.nanterre.francetelecom.fr> References: <3155_1298014995_4D5E2313_3155_348950_1_94C682931C08B048B7A8645303FDC9F33C444C8C5F@PUEXCB1B.nanterre.francetelecom.fr> <0ab201cbcf9d$b2414c30$16c3e490$@com> In-Reply-To: <0ab201cbcf9d$b2414c30$16c3e490$@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.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.22.143317 Subject: Re: [pcp] DNS Indirection X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 17:03:34 -0000 Hi Dan, I fully agree with your analysis.=20 I will remove that note from the I-D and add a sentence to record this.=20 Cheers, Med=20 -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : vendredi 18 f=E9vrier 2011 19:57 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; pcp@ietf.org Objet : RE: [pcp] DNS Indirection > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange-ftgroup.com > Sent: Thursday, February 17, 2011 11:43 PM > To: pcp@ietf.org > Subject: [pcp] DNS Indirection >=20 > Dear all, >=20 > We would like to have a feedback about an open question we have in > http://tools.ietf.org/html/draft-bpw-pcp-dhcp-02 (Section 5.2): >=20 > [Ed. Is there a value to consider a level of indirection (e.g., > SRV)? (1) to use an arbitrary port number for PCP Server instead > of the default port, (2) detect whether a security channel is in > use (using the transport protocol)] >=20 > The current text assumes there is no indirection. There is value in SRV. But there is additional complexity and additional failure modes. To my knowledge the only (relatively) widely deployed application that uses SRV in real life is XMPP. Just last year, Cisco=20 bumped into a bug where our devices borked SRV responses that were=20 longer than expected. (1) would be neat to have, but I am not convinced we necessarily need it. (2) can be done without SRV; lots of protocols without SRV already negotiate or force upgrading to a secure channel. I vote for K.I.S.S. That is, don't do SRV. -d ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From trac@tools.ietf.org Tue Feb 22 09:06:14 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CA573A6924 for ; Tue, 22 Feb 2011 09:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HujHmTdKyDxS for ; Tue, 22 Feb 2011 09:06:13 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 497293A68DC for ; Tue, 22 Feb 2011 09:06:13 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PrvhR-0007QX-Qa; Tue, 22 Feb 2011 09:06:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dthaler@microsoft.com, dwing@cisco.com X-Trac-Project: pcp Date: Tue, 22 Feb 2011 17:06:57 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/13#comment:3 Message-ID: <062.e01e5ebcc305d7e7a94b71ee5c76fa25@tools.ietf.org> References: <053.a0bcfe3bfc790d5de6e2861c6c3677b6@tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <053.a0bcfe3bfc790d5de6e2861c6c3677b6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dthaler@microsoft.com, dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #13: DS-lite interaction X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 17:06:14 -0000 #13: DS-lite interaction Comment(by dthaler@…): Strawman: encapsulation mode with a relay -- --------------------------------+------------------------------------------- Reporter: dwing@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: pcp From pselkirk@isc.org Tue Feb 22 09:09:09 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F4BE3A6932 for ; Tue, 22 Feb 2011 09:09:09 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: unexpected end of preamble X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_00=-2.599, MISSING_MIME_HB_SEP=2.119, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaUi4-tnI5Me for ; Tue, 22 Feb 2011 09:09:08 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id DB6323A6924 for ; Tue, 22 Feb 2011 09:09:07 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 10E8CC9429 for ; Tue, 22 Feb 2011 17:09:50 +0000 (UTC) (envelope-from pselkirk@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10300) id 075C8216C31; Tue, 22 Feb 2011 17:09:50 +0000 (UTC) From: Paul Selkirk To: pcp@ietf.org Content-Type: multipart/mixed; boundary="-" Date: Tue, 22 Feb 2011 17:09:50 +0000 Message-ID: MIME-Version: 1.0 Subject: [pcp] interim meeting notes X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 17:09:09 -0000 [raw notes; send corrections as necessary] PCP Working Group Interim Meeting, 22 February 2011 Dan Wing Dave Thaler Alain Durand Francis Dupont Gang Chen Jacni Qin James Huang Jari Arkko(?) Latrive Eric Mohamed Boucadair Paul Selkirk Reinaldo Penno Simon Perreault Thomas Zhang Xiaohong Deng We had an extended design team meeting last month, no official consensus, but tried to make some progress on the document. Will post minutes to the mailing list. Status update (Dan): published -04, -05 PIN -> MAP, reduced MAP opcodes from 4 to 2 move nested NAT text to a separate document renamed HONOR_EXTERNAL_PORT to PREFER_FAILURE might be interested in moving this from base doc to UPnP IWF doc lifetime -> common header (-04) -> opcode headers (-05) reduced scope to protocols that have ports tweaked packet header layout request forwarding all ports return lifetime in error response as a hint for when to retry #28: UPnP/NAT-PMP Interop functionality in base spec or separate specs No objections to creating a separate IWF docs Move PREFER_FAILURE (mandatory-to-process) option to UPnP IWF doc? Francis: keep this option in the main spec Dave: define the format of the option in one place, specify list of options that should/must support possibly in another place Alain: server behavior is specified in base document, iwf/relay behavior is specified in another document Forward all ports? (no issue tracker #) i.e. allow user to create a DMZ Dave: There are things you can do with syns, which don't require additional security; and things you can't do with syns, which may require extra security. This is the second sort. Dan: no compelling scenario Francis; NAT66, IPv6 firewall Dave: these are potentially interesting, but not hearing a strong request for this functionality Alain: protocol 0, port 0 are unsupported in request #5: Channel security mechanism currently nothing in the pcp document to address this what should we recommend under pcp? DTLS, IPSec? only to protect operations that don't correspond to tcp syn Dave: should we not worry about things that can only be done through source address spoofing? Alain: if spoofing is possible, we have bigger problems Dave: constrain to THIRD_PARTY scenario Alain: webcam case; ISP managing own device Dave: webcam requires protocol solution; ISP may have proprietary solution Alain: THIRD_PARTY option can only be added by CPE Alain: in ds-lite case, B4 must use 192.0.0.0/29 source addr Alain: put text in THIRD_PARTY option similar to ds-lite spec Francis: AFTR element should do authentication, leave auth out of PCP spec #33: 3rd party mappings: create/destroy THIRD_PARTY option or internal address in main header? Dan: if in main header, server can't distinguish between attempted third party mapping vs broken client Francis: add wild-card flag bits to opcode headers Alain: simplify the life of the cpe, or simplify the life of the app Xiaohong: having an option complicates parsing of request, because option order is not fixed (slow path) Francis: having relay add an option may cause packet to become too big Reinaldo: should have at least recommended order for options (create a ticket for that) Alain: straw man proposal: THIRD_PARTY option, order of options Francis: option messes transparent third-party relay, can't get target address at fixed place in packet Alain: would like to hear from anyone else: is this an unacceptable level of pain? Dan: option makes it obvious what the client is trying to do in the request Dan: IWF has to do the work anyway, just as likely to get it wrong; makes it harder for the client to get it wrong Dan: SIP soft-phones are historically unable to deal with multiple interfaces, don't expect PCP implementations to be any better Dave: if anything that requires additional security must be an option, then THIRD_PARTY would need to be an option Dave: straw man for #5: if third-party request comes in on same customer port (tunnel, circuit id) as requested address, no additional security is needed; if not on same port, configure ACLs or other local security mechanism Dave: close #5: PCP is not capable of opening ports for another subscriber. Section 8.8 covers opening ports for another IP within same subscriber IP address range, and no additional security is present for that case. #13: ds-lite interaction Alain: straw man: encapsulation mode with relay (third-party option) Francis: encapsulation complicates the server implementation Alain: can we request a nat64 port opening over ipv4 or just ipv6? Dan: today the only discovery option is default gateway, so pcp requests are going to have to be relayed anyway Med: because we have the proxy anyway, plain ipv6 mode is simpler Alain: have Reinaldo do analysis of the different mechanisms Dave: thanks for coming, see you in Prague Alain: we should have another interim meeting before two weeks from today = March 8; same bat time, same bat place From trac@tools.ietf.org Tue Feb 22 09:12:35 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D7573A694D for ; Tue, 22 Feb 2011 09:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMw+xEGojwGE for ; Tue, 22 Feb 2011 09:12:34 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E61D83A6951 for ; Tue, 22 Feb 2011 09:12:34 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Prvnb-0008Q0-Ri; Tue, 22 Feb 2011 09:13:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 22 Feb 2011 17:13:19 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/5#comment:4 Message-ID: <055.7a787750b0f6ab262324a345ade2f8b2@tools.ietf.org> References: <046.a9a020e73872fae1ac8624b71547ce81@tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <046.a9a020e73872fae1ac8624b71547ce81@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dthaler@microsoft.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #5: Channel security mechanism X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 17:12:35 -0000 #5: Channel security mechanism Comment(by dthaler@…): Another strawman idea to consider is: if an admin wants to restrict the ability to do certain PCP operations (e.g., open ports for another IP), then those operations should be defined as options. An implementation can then support the ability to have an ACL of some (implementation-specific) sort, covering a list of such options. -- --------------------------------+------------------------------------------- Reporter: multiple | Owner: Type: enhancement | Status: closed Priority: critical | Milestone: Component: base | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: pcp From adurand@juniper.net Tue Feb 22 09:45:48 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3FF83A6957; Tue, 22 Feb 2011 09:45:48 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wh1Iaf9fGhCj; Tue, 22 Feb 2011 09:45:48 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 2550F3A68FA; Tue, 22 Feb 2011 09:45:43 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTWP2dP32kU8rMIIVu000rUBpz6OR5RWm@postini.com; Tue, 22 Feb 2011 09:46:33 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 22 Feb 2011 09:44:29 -0800 From: Alain Durand To: "pcp@ietf.org" , "ietf-secretariat@ietf.org" Date: Tue, 22 Feb 2011 09:45:01 -0800 Thread-Topic: PCP webex interim meeting on 3/8/2011 Thread-Index: AcvSuCc9uq2Obh4NR/640hOzV8Ql3A== Message-ID: <92C07C78-0CD1-450A-A012-736324EC5821@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] PCP webex interim meeting on 3/8/2011 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 17:45:49 -0000 Dear wg members. We will organize a PCP interim webex meeting on 3/8/2011 at 7am PST. Dial-in information & agenda will come later. - Alain From trac@tools.ietf.org Tue Feb 22 10:34:50 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90A063A696D for ; Tue, 22 Feb 2011 10:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szQbWGEGbIhX for ; Tue, 22 Feb 2011 10:34:49 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5D92D3A695C for ; Tue, 22 Feb 2011 10:34:49 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Prx5C-0008LI-Eh; Tue, 22 Feb 2011 10:35:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com X-Trac-Project: pcp Date: Tue, 22 Feb 2011 18:35:34 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/41 Message-ID: <053.c37df69b4fd40c068b4bcba0ef1fe3c6@tools.ietf.org> X-Trac-Ticket-ID: 41 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: [pcp] #41: PCP Options need to have a specific order, to ease processing X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 18:34:51 -0000 #41: PCP Options need to have a specific order, to ease processing PCP Options need to have a specific order, to ease processing especially on the server. dwing proposal: I propose doing the following: 1. Currently, the optional-to-process options are 0-127, and mandatory-to-process options are 128-255. I propose swapping this, so the mandatory-to-process options are numbered lowest. 2. new text for the General PCP Client processing section: If more than one Option is included in a PCP request, the Options MUST be ordered from the lowest-numbered option to the highest numbered option. 3. new text for the General PCP Server processing section: If more than one Option is present in the PCP request, and they are not ordered by lowest-numbered to highest- numbered, the PCP server MUST generate a MISORDERED_OPTION error response. -- -----------------------------+---------------------------------------------- Reporter: dwing@… | Owner: dwing@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: -----------------------------+---------------------------------------------- Ticket URL: pcp From dwing@cisco.com Tue Feb 22 10:35:14 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FEB73A695D for ; Tue, 22 Feb 2011 10:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.59 X-Spam-Level: X-Spam-Status: No, score=-110.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gT4ct-ts9R8H for ; Tue, 22 Feb 2011 10:35:11 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 761333A695C for ; Tue, 22 Feb 2011 10:35:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=914; q=dns/txt; s=iport; t=1298399756; x=1299609356; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=ogbKSNZ9j5NsvGqeizgMBDjKP6JOZecHRyfXzzOB7dM=; b=Qzelo+pj1TQfdugl4kHY2R35Zr6VwWXytTpkKYULBEoGThl6RGPGBU4R z3MGrv/waHIU0hGMWQskXyksxYFJ6JXi+s6RmbEf4wyJTuzVC7taW+e5M WuSnnQ/FpJrvWA979ZQS2eUOBES1JvG3IRKnMJ4VW8Sm+VMxltY1NidAz c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAHAHGQY02rR7Hu/2dsb2JhbACYDoEmjGZzokqbW4VeBIUN X-IronPort-AV: E=Sophos;i="4.62,207,1297036800"; d="scan'208";a="333620136" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 22 Feb 2011 18:35:55 +0000 Received: from dwingWS ([10.89.9.183]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1MIZtbS003732 for ; Tue, 22 Feb 2011 18:35:55 GMT From: "Dan Wing" To: Date: Tue, 22 Feb 2011 10:35:54 -0800 Message-ID: <157901cbd2bf$573308e0$05991aa0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvSv1aQeJbJyXX/QpWJkKS2ZEqnGA== Content-Language: en-us Subject: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 18:35:14 -0000 During today's PCP call, it was proposed to add suggested ordering for PCP options, which is new ticket #41, http://trac.tools.ietf.org/wg/pcp/trac/ticket/41 I propose the following: 1. Currently, the optional-to-process options are 0-127, and mandatory-to-process options are 128-255. I propose swapping this, so the mandatory-to-process options are numbered lowest. 2. new text for the General PCP Client processing section: If more than one Option is included in a PCP request, the Options MUST be ordered from the lowest numbered option to the highest numbered option. 3. new text for the General PCP Server processing section: If more than one Option is present in the PCP request, and they are not ordered from lowest numbered Option to highest numbered Option, the PCP server MUST generate a MISORDERED_OPTIONS error response. Comments or feedback? -d From simon.perreault@viagenie.ca Tue Feb 22 10:41:22 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27E13A6916 for ; Tue, 22 Feb 2011 10:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AGAMJCBkChm for ; Tue, 22 Feb 2011 10:41:18 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 4C30F3A68C8 for ; Tue, 22 Feb 2011 10:41:18 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8C19D21F17 for ; Tue, 22 Feb 2011 13:42:01 -0500 (EST) Message-ID: <4D640379.2090009@viagenie.ca> Date: Tue, 22 Feb 2011 13:42:01 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: pcp@ietf.org References: <157901cbd2bf$573308e0$05991aa0$@com> In-Reply-To: <157901cbd2bf$573308e0$05991aa0$@com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 18:41:22 -0000 On 2011-02-22 13:35, Dan Wing wrote: > During today's PCP call, it was proposed to add suggested ordering for PCP > options Can you please summarize why this is a good idea? Specifically, what optimizations would this allow the server to perform? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From trac@tools.ietf.org Tue Feb 22 10:44:15 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D69B13A6973 for ; Tue, 22 Feb 2011 10:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.167 X-Spam-Level: X-Spam-Status: No, score=-102.167 tagged_above=-999 required=5 tests=[AWL=-0.366, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUYgcqkMi+Fl for ; Tue, 22 Feb 2011 10:44:15 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 250E03A695F for ; Tue, 22 Feb 2011 10:44:15 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PrxEJ-0002Af-H6; Tue, 22 Feb 2011 10:44:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 22 Feb 2011 18:44:59 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/28#comment:2 Message-ID: <055.0e9ba942b8126cc69b887bf9a4e647dc@tools.ietf.org> References: <046.fbbd11187f5ec1ce2f12aba141f6977f@tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <046.fbbd11187f5ec1ce2f12aba141f6977f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, dthaler@microsoft.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #28: UPnP/NAT-PMP Interop functionality in base spec or separate specs X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 18:44:16 -0000 #28: UPnP/NAT-PMP Interop functionality in base spec or separate specs Changes (by dwing@…): * status: new => closed * resolution: => fixed Comment: As of -05, the UPnP interworking details were removed from the base document. The bast document now points to http://tools.ietf.org/html /draft-bpw-pcp-upnp-igd-interworking Closed. -- --------------------------------+------------------------------------------- Reporter: multiple | Owner: dwing@… Type: task | Status: closed Priority: minor | Milestone: Component: UPnP interop | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: pcp From dthaler@microsoft.com Tue Feb 22 12:37:06 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D2F3A68F9 for ; Tue, 22 Feb 2011 12:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.415 X-Spam-Level: X-Spam-Status: No, score=-110.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4DNAgiVVkWF for ; Tue, 22 Feb 2011 12:37:05 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id A41F63A68F4 for ; Tue, 22 Feb 2011 12:37:05 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 22 Feb 2011 12:37:49 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.270.2; Tue, 22 Feb 2011 12:37:49 -0800 Received: from TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com ([169.254.5.26]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Tue, 22 Feb 2011 12:37:48 -0800 From: Dave Thaler To: Dan Wing , "pcp@ietf.org" Thread-Topic: [pcp] Option ordering, ticket #41 Thread-Index: AcvSv1aQeJbJyXX/QpWJkKS2ZEqnGAAENW4A Date: Tue, 22 Feb 2011 20:37:48 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653AF846C0@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> References: <157901cbd2bf$573308e0$05991aa0$@com> In-Reply-To: <157901cbd2bf$573308e0$05991aa0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 20:37:06 -0000 I like this in general. It makes me wonder though whether we should leave a gap between existing op= tions, to allow for future insertion requirements? Or maybe we just reser= ve the lowest numbered value in case we ever need to add an "option orderin= g option" at some point in the future. -Dave > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dan > Wing > Sent: Tuesday, February 22, 2011 10:36 AM > To: pcp@ietf.org > Subject: [pcp] Option ordering, ticket #41 >=20 > During today's PCP call, it was proposed to add suggested ordering for PC= P > options, which is new ticket #41, > http://trac.tools.ietf.org/wg/pcp/trac/ticket/41 >=20 > I propose the following: >=20 >=20 > 1. Currently, the optional-to-process options are 0-127, and mandatory-t= o- > process options are 128-255. I propose swapping this, so the mandatory-t= o- > process options are numbered lowest. >=20 > 2. new text for the General PCP Client processing section: >=20 > If more than one Option is included in a PCP request, the > Options MUST be ordered from the lowest numbered option to > the highest numbered option. >=20 > 3. new text for the General PCP Server processing section: >=20 > If more than one Option is present in the PCP request, > and they are not ordered from lowest numbered Option > to highest numbered Option, the PCP server MUST generate > a MISORDERED_OPTIONS error response. >=20 >=20 > Comments or feedback? >=20 > -d >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From adurand@juniper.net Tue Feb 22 12:43:57 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF7213A6891 for ; Tue, 22 Feb 2011 12:43:57 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WyEewOZPRJv for ; Tue, 22 Feb 2011 12:43:57 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id D3AC63A67B0 for ; Tue, 22 Feb 2011 12:43:56 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTWQgON8C0zhXaCcYc9CTCyNrs5n4KF6V@postini.com; Tue, 22 Feb 2011 12:44:42 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 22 Feb 2011 12:42:51 -0800 From: Alain Durand To: Dave Thaler Date: Tue, 22 Feb 2011 12:43:23 -0800 Thread-Topic: [pcp] Option ordering, ticket #41 Thread-Index: AcvS0RKN3ZvwTrPRTYmrhxPYMvg5Mw== Message-ID: <47F9645A-6E04-4F7B-84CE-197C74F168A9@juniper.net> References: <157901cbd2bf$573308e0$05991aa0$@com> <9B57C850BB53634CACEC56EF4853FF653AF846C0@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653AF846C0@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 20:43:58 -0000 The issue with options in IPv6 is that, if you do not care about them, you = still have to process them one by one before finding the transport header..= . This is something that middle-boxes using hardware acceleration do not like= . In PCP, options are at the end of the packet, so this should be much less o= f an issue. - Alain. On Feb 22, 2011, at 3:37 PM, Dave Thaler wrote: > I like this in general. > It makes me wonder though whether we should leave a gap between existing = options, to allow for future insertion requirements? Or maybe we just res= erve the lowest numbered value in case we ever need to add an "option order= ing option" at some point in the future. >=20 > -Dave >=20 >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Da= n >> Wing >> Sent: Tuesday, February 22, 2011 10:36 AM >> To: pcp@ietf.org >> Subject: [pcp] Option ordering, ticket #41 >>=20 >> During today's PCP call, it was proposed to add suggested ordering for P= CP >> options, which is new ticket #41, >> http://trac.tools.ietf.org/wg/pcp/trac/ticket/41 >>=20 >> I propose the following: >>=20 >>=20 >> 1. Currently, the optional-to-process options are 0-127, and mandatory-= to- >> process options are 128-255. I propose swapping this, so the mandatory-= to- >> process options are numbered lowest. >>=20 >> 2. new text for the General PCP Client processing section: >>=20 >> If more than one Option is included in a PCP request, the >> Options MUST be ordered from the lowest numbered option to >> the highest numbered option. >>=20 >> 3. new text for the General PCP Server processing section: >>=20 >> If more than one Option is present in the PCP request, >> and they are not ordered from lowest numbered Option >> to highest numbered Option, the PCP server MUST generate >> a MISORDERED_OPTIONS error response. >>=20 >>=20 >> Comments or feedback? >>=20 >> -d >>=20 >>=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 From dwing@cisco.com Tue Feb 22 13:10:17 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E4973A6916 for ; Tue, 22 Feb 2011 13:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.59 X-Spam-Level: X-Spam-Status: No, score=-110.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F0sdIsfcgRh for ; Tue, 22 Feb 2011 13:10:16 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 4CE743A6905 for ; Tue, 22 Feb 2011 13:10:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2088; q=dns/txt; s=iport; t=1298409061; x=1299618661; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=o7xEy3h5/9HwsiVz8Jk4T2H2iUY8eTKxnot5Mn1X/hM=; b=TvGUYeYOoFFlyLuavGrEKmdXCgYGgY6Ku9ZPHo+YO1dJcqMygTqBh/ae NVKG+pptSA32lbmOBpH9le/+S5xyGYJfIU6i2zytrEhiFnx6FU3F/lcWt DwekuwIO+elvGu4Dt9AlKq2YOVEbzTQqVYPS91EIcPDHCbe1F/Z1emMEQ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBALu0Y02rR7H+/2dsb2JhbACXVIFljGdzoh6bVoVeBIUN X-IronPort-AV: E=Sophos;i="4.62,207,1297036800"; d="scan'208";a="268709459" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 22 Feb 2011 21:10:54 +0000 Received: from dwingWS ([10.89.9.183]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1MLArGj016334; Tue, 22 Feb 2011 21:10:53 GMT From: "Dan Wing" To: "'Dave Thaler'" , References: <157901cbd2bf$573308e0$05991aa0$@com> <9B57C850BB53634CACEC56EF4853FF653AF846C0@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653AF846C0@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> Date: Tue, 22 Feb 2011 13:10:52 -0800 Message-ID: <165101cbd2d4$fd47c530$f7d74f90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvSv1aQeJbJyXX/QpWJkKS2ZEqnGAAENW4AAAEqkuA= Content-Language: en-us Subject: Re: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 21:10:17 -0000 > -----Original Message----- > From: Dave Thaler [mailto:dthaler@microsoft.com] > Sent: Tuesday, February 22, 2011 12:38 PM > To: Dan Wing; pcp@ietf.org > Subject: RE: [pcp] Option ordering, ticket #41 > > I like this in general. > It makes me wonder though whether we should leave a gap between > existing options, to allow for future insertion requirements? Like line numbering in BASIC? Do you expect we would "prioritize" the options somehow, in importance or something?? > Or > maybe we just reserve the lowest numbered value in case we ever need to > add an "option ordering option" at some point in the future. -d > -Dave > > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Dan > > Wing > > Sent: Tuesday, February 22, 2011 10:36 AM > > To: pcp@ietf.org > > Subject: [pcp] Option ordering, ticket #41 > > > > During today's PCP call, it was proposed to add suggested ordering > for PCP > > options, which is new ticket #41, > > http://trac.tools.ietf.org/wg/pcp/trac/ticket/41 > > > > I propose the following: > > > > > > 1. Currently, the optional-to-process options are 0-127, and > mandatory-to- > > process options are 128-255. I propose swapping this, so the > mandatory-to- > > process options are numbered lowest. > > > > 2. new text for the General PCP Client processing section: > > > > If more than one Option is included in a PCP request, the > > Options MUST be ordered from the lowest numbered option to > > the highest numbered option. > > > > 3. new text for the General PCP Server processing section: > > > > If more than one Option is present in the PCP request, > > and they are not ordered from lowest numbered Option > > to highest numbered Option, the PCP server MUST generate > > a MISORDERED_OPTIONS error response. > > > > > > Comments or feedback? > > > > -d > > > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp From trac@tools.ietf.org Tue Feb 22 14:22:11 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A94F3A6981 for ; Tue, 22 Feb 2011 14:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+NtYQkVPDL8 for ; Tue, 22 Feb 2011 14:22:10 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AE6D03A697A for ; Tue, 22 Feb 2011 14:22:10 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Ps0dB-0005So-Em; Tue, 22 Feb 2011 14:22:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dthaler@microsoft.com, dwing@cisco.com, tena@huawei.com X-Trac-Project: pcp Date: Tue, 22 Feb 2011 22:22:53 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/10#comment:5 Message-ID: <062.8dc93d82ab1a7249d6c79e0c011b2020@tools.ietf.org> References: <053.e4eb3896c167b7dd11a6f1bfffcd9fdb@tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <053.e4eb3896c167b7dd11a6f1bfffcd9fdb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dthaler@microsoft.com, dwing@cisco.com, tena@huawei.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #10: Firewall (address-dependent filter) support X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 22:22:11 -0000 #10: Firewall (address-dependent filter) support Comment(by tena@…): Replying to [comment:4 dthaler@…]: Agreed this method, actually it allows PCP server can have black list function. But is there any security issue of this black list function? For some user, REMOTE_PEER_FILTER options can only filter the remote peer related to this user's IP. I did not see related description on this specification. -- --------------------------------+------------------------------------------- Reporter: dwing@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: Firewall | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: pcp From dwing@cisco.com Tue Feb 22 16:07:21 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 673003A65A5 for ; Tue, 22 Feb 2011 16:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.291 X-Spam-Level: X-Spam-Status: No, score=-110.291 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzCYG6DZl-3D for ; Tue, 22 Feb 2011 16:07:20 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 7A48F3A635F for ; Tue, 22 Feb 2011 16:07:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2421; q=dns/txt; s=iport; t=1298419686; x=1299629286; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=eAvwwtbJaRmahZnFPR6LVjYc4k/CvO/dyefnPBgtNdc=; b=QCfMcngL0BFB2p0um/SjIOS5aLCWCRw20/XdKwUCKQVg+UrsUAYCIQ+8 girxI9te+jA6xugGbqGNLWbKbFWqdVcXZMh4ZzFOEF+RpiNL+tT+1rYF8 0TeSsZxMbz4UpVH05733kJ15QsObfk0lfXiogAM3GNZ2PLuuV9UkddOj9 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0BALbeY02rR7Ht/2dsb2JhbACEIJM2P4EmjGdzoTuKe5BYgSeDQXYEhQ0 X-IronPort-AV: E=Sophos;i="4.62,209,1297036800"; d="scan'208";a="264008482" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 23 Feb 2011 00:08:05 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1N084fY006757; Wed, 23 Feb 2011 00:08:05 GMT From: "Dan Wing" To: References: <053.b7ab218e1afd86908d988f82b6167bd8@trac.tools.ietf.org> <062.acd62f4ef08eca72c1306b26d34be6d9@trac.tools.ietf.org> In-Reply-To: <062.acd62f4ef08eca72c1306b26d34be6d9@trac.tools.ietf.org> Date: Tue, 22 Feb 2011 16:08:04 -0800 Message-ID: <176401cbd2ed$be6c45c0$3b44d140$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvS4Vqe9x/yapu6TLes/iaY89fC/wACbsQA Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] base #17 (closed): using PCP to reduce application-level keepalive traffic X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 00:07:21 -0000 > -----Original Message----- > From: pcp issue tracker [mailto:trac@trac.tools.ietf.org] > Sent: Tuesday, February 22, 2011 2:39 PM > To: dwing@cisco.com; tena@huawei.com > Cc: pcp@ietf.org > Subject: Re: [pcp] base #17 (closed): using PCP to reduce application- > level keepalive traffic >=20 > #17: using PCP to reduce application-level keepalive traffic >=20 >=20 > Comment(by tena@=E2=80=A6): >=20 >=20 > = =E4=B8=AA=E4=BA=BA=E8=B5=9E=E6=88=90=EF=BC=8C=E7=94=A8PCP=E6=9D=A5=E5=87=8F= =E5=B0=91=E5=BA=94=E7=94=A8keepalive=E6=B5=81=E9=87=8F=E7=9A=84=EF=BC=8C=E4= =BD=86=E8=A7=89=E5=BE=97NAT=E8=A1=A8=E9=A1=B9=E8=B6=85=E6=97=B6=E9=9C=80=E8= =A6=81=E6=98=8E=E7=A1=AE=EF=BC=8C=E7=94=A8PCP=E6=B6=88=E6=81=AF > = =E6=97=B6=EF=BC=8C=E5=B0=B1=E4=B8=8D=E8=A6=81=E7=94=A8=E5=BA=94=E7=94=A8=E7= =9A=84keepalive > = =E6=9D=A5=E5=88=B7=E6=96=B0NAT=E8=A1=A8=E9=A1=B9=E7=9A=84=E6=97=B6=E9=97=B4= =E3=80=82 > I support using PCP to reduce application-level keepalive traffic. > However, I think the NAT entries expiring out should be specified > clearly, > if using PCP message, don't use application's keepalive to refresh = NAT > entries time. So, that would mean that once an application sends a PEER request to=20 query the lifetime of the mapping, the application will forever have=20 to re-send PEER requests to keep the mapping alive. This seems counter-intuitive. What is the advantage of requiring the application to send occasional PEER requests, instead of allowing it to just send its normal application traffic? As an example, I don't see the purpose of requiring the application to always send PEER messages if the Lifetime is 5 minutes and the=20 application is normally sending traffic more frequently (e.g., a=20 presence application routinely updates presence information of=20 peers or of the client). Sending the subsequent PEER messages is extra load on the network (undesirable in general but especially for wireless devices). Of course, if the Lifetime is _less_ than the application's normal traffic, the application could use PEER to extend the lifetime.=20 But, in this case too, I would myself prefer the application be allowed to send an application message which it might want to do for other reasons, rather than being forced to send a PEER request. Can you provide more details on why you are suggesting PEER be re-sent forever? -d From dwing@cisco.com Tue Feb 22 16:08:46 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3976D3A65A5 for ; Tue, 22 Feb 2011 16:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.009 X-Spam-Level: X-Spam-Status: No, score=-110.009 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnJUOOHgeVPm for ; Tue, 22 Feb 2011 16:08:45 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 798113A635F for ; Tue, 22 Feb 2011 16:08:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=883; q=dns/txt; s=iport; t=1298419771; x=1299629371; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=GJWeAINTxAdtEbaueoPE/oCvLhloQWfUOEgPMN7Zerc=; b=c/n2fZYFcXTrQqrCkB9FZR71joyyPu1MiFfdyUK+AiTztVI6RLW9bxHx O1+C8SORzLCFrvJtwSPoYXg4PheV0S0WdErhPF+b4I/WJ3+Nzo4fRPJho 4CG6n3zJTTVH62S8a7INOfZhDDrIbNiIP4w6HvivE6zEntGN9Vmfyghxd s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBALbeY02rRN+J/2dsb2JhbACEIJM2gWWMZ3OhO4p7kFiBJ4NBdgSFDQ X-IronPort-AV: E=Sophos;i="4.62,209,1297036800"; d="scan'208";a="663921058" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 23 Feb 2011 00:09:31 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p1N09U1G001254; Wed, 23 Feb 2011 00:09:31 GMT From: "Dan Wing" To: , References: <053.e4eb3896c167b7dd11a6f1bfffcd9fdb@tools.ietf.org> <062.8dc93d82ab1a7249d6c79e0c011b2020@tools.ietf.org> In-Reply-To: <062.8dc93d82ab1a7249d6c79e0c011b2020@tools.ietf.org> Date: Tue, 22 Feb 2011 16:09:30 -0800 Message-ID: <176501cbd2ed$f184de90$d48e9bb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvS3xFNptadPraBSD+Yem8xvRrcQgADsNRw Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] #10: Firewall (address-dependent filter) support X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 00:08:46 -0000 > -----Original Message----- > From: pcp issue tracker [mailto:trac@tools.ietf.org] > Sent: Tuesday, February 22, 2011 2:23 PM > To: dthaler@microsoft.com; dwing@cisco.com; tena@huawei.com > Cc: pcp@ietf.org > Subject: Re: [pcp] #10: Firewall (address-dependent filter) support >=20 > #10: Firewall (address-dependent filter) support >=20 >=20 > Comment(by tena@=E2=80=A6): >=20 > Replying to [comment:4 dthaler@=E2=80=A6]: > Agreed this method, actually it allows PCP server can have black list > function. > But is there any security issue of this black list function? Such as? > For some user, REMOTE_PEER_FILTER options can only filter the remote > peer > related to this user's IP. I did not see related description on this > specification. If there is a mistake in the document, can you point at the section=20 and text that is wrong? -d From wwwrun@core3.amsl.com Wed Feb 23 07:35:10 2011 Return-Path: X-Original-To: pcp@ietf.org Delivered-To: pcp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 9B4843A68F3; Wed, 23 Feb 2011 07:35:08 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110223153509.9B4843A68F3@core3.amsl.com> Date: Wed, 23 Feb 2011 07:35:09 -0800 (PST) Cc: pcp@ietf.org Subject: [pcp] PCP WG Virtual Interim Meeting, March 8, 2011 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 15:35:10 -0000 The PCP Working Group will hold a virtual interim meeting on March 8, 2011 at 7:00 AM PST. The agenda and WebEx dial-in information will follow on the PCP mailing list (http://www.ietf.org/mail-archive/web/pcp/). From rpenno@juniper.net Wed Feb 23 07:39:23 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAB0B3A6845 for ; Wed, 23 Feb 2011 07:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYIjFz1WGcbG for ; Wed, 23 Feb 2011 07:39:22 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 6603C3A68F3 for ; Wed, 23 Feb 2011 07:39:18 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTWUqVV0yGS7nXogGyqpjmZ6juCrsemDm@postini.com; Wed, 23 Feb 2011 07:40:10 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 23 Feb 2011 07:35:28 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 23 Feb 2011 10:36:02 -0500 From: Reinaldo Penno To: pcp issue tracker , "dwing@cisco.com" Date: Wed, 23 Feb 2011 10:36:00 -0500 Thread-Topic: [pcp] #41: PCP Options need to have a specific order, to ease processing Thread-Index: AcvSv05x6y/6pdGvSb+l6pEZUm/A0QAsBCjv Message-ID: In-Reply-To: <053.c37df69b4fd40c068b4bcba0ef1fe3c6@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] #41: PCP Options need to have a specific order, to ease processing X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 15:39:23 -0000 Looks good. On 2/22/11 10:35 AM, "pcp issue tracker" wrote: > #41: PCP Options need to have a specific order, to ease processing PCP > Options need to have a specific order, to ease processing especially on the > server. dwing proposal: I propose doing the following: 1. Currently, > the optional-to-process options are 0-127, and mandatory-to-process options > are 128-255. I propose swapping this, so the mandatory-to-process options > are numbered lowest. 2. new text for the General PCP Client processing > section: If more than one Option is included in a PCP request, the > Options MUST be ordered from the lowest-numbered option to the highest > numbered option. 3. new text for the General PCP Server processing > section: If more than one Option is present in the PCP request, and > they are not ordered by lowest-numbered to highest- numbered, the PCP > server MUST generate a MISORDERED_OPTION error response. -- >=20 -----------------------------+---------------------------------------------= - > Reporter: dwing@=8A | Owner: dwing@=8A =20 Type: defect > | Status: new =20 Priority: major | Milestone: >=20 Component: base | Version: =20 Severity: - > | Keywords: =20 >=20 -----------------------------+---------------------------------------------= - >=20 Ticket URL: pcp > _______________________________________________ > pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp From simon.perreault@viagenie.ca Wed Feb 23 07:50:17 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E45A53A6835 for ; Wed, 23 Feb 2011 07:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnYQffOL55xA for ; Wed, 23 Feb 2011 07:50:12 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 577843A68FE for ; Wed, 23 Feb 2011 07:50:10 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 340E321BBB for ; Wed, 23 Feb 2011 10:50:52 -0500 (EST) Message-ID: <4D652CDB.4040802@viagenie.ca> Date: Wed, 23 Feb 2011 10:50:51 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: pcp@ietf.org References: <157901cbd2bf$573308e0$05991aa0$@com> <9B57C850BB53634CACEC56EF4853FF653AF846C0@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> <47F9645A-6E04-4F7B-84CE-197C74F168A9@juniper.net> In-Reply-To: <47F9645A-6E04-4F7B-84CE-197C74F168A9@juniper.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 15:50:17 -0000 On 2011-02-22 15:43, Alain Durand wrote: > The issue with options in IPv6 is that, if you do not care about them, you still have to process them one by one before finding the transport header... > This is something that middle-boxes using hardware acceleration do not like. > In PCP, options are at the end of the packet, so this should be much less of an issue. So it looks like there is no reason why we would be doing this. I don't see how it could make the server's life any easier. If nobody can come up with a justification, we're just imposing an arbitrary constraint on the protocol. I can certainly live with that constraint. It's just that usually I prefer those of the justified kind.... ;) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dwing@cisco.com Wed Feb 23 16:31:27 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F0E63A6960 for ; Wed, 23 Feb 2011 16:31:27 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHANkr83p4wu for ; Wed, 23 Feb 2011 16:31:26 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 863C63A659A for ; Wed, 23 Feb 2011 16:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1558; q=dns/txt; s=iport; t=1298507535; x=1299717135; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=DVNThP6MkH46s75X4Luhh850If0/UBzV+xaky3qtOIc=; b=XaUpoguOENEIv1dSmz70J4/UqJdXHynNJaiv+jxVBxwyfrd1zYkNCEYz 7ZwbeoZRhYrG+481JQ6tFX+uWyAWQIaPahf+o26o6/+USNymiSJH75HrY Mg80N50hhn52WV7Z0RP0tFHdaoGpQ0qGKDl6ZVI+N9xIE1hyVFo6N5zHX M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAAw2ZU2rRN+J/2dsb2JhbACXUoFljGhzoE6bX4VeBIUN X-IronPort-AV: E=Sophos;i="4.62,214,1297036800"; d="scan'208";a="264531451" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 24 Feb 2011 00:32:14 +0000 Received: from dwingWS ([128.107.115.25]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p1O0WEnt023867; Thu, 24 Feb 2011 00:32:14 GMT From: "Dan Wing" To: "'Simon Perreault'" , References: <157901cbd2bf$573308e0$05991aa0$@com> <9B57C850BB53634CACEC56EF4853FF653AF846C0@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> <47F9645A-6E04-4F7B-84CE-197C74F168A9@juniper.net> <4D652CDB.4040802@viagenie.ca> In-Reply-To: <4D652CDB.4040802@viagenie.ca> Date: Wed, 23 Feb 2011 16:32:14 -0800 Message-ID: <1d2301cbd3ba$48a8c930$d9fa5b90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvTcX6phIuj5AGGQXCQBj4Rd2Dp3gASEfmg Content-Language: en-us Subject: Re: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 00:31:27 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Simon Perreault > Sent: Wednesday, February 23, 2011 7:51 AM > To: pcp@ietf.org > Subject: Re: [pcp] Option ordering, ticket #41 > > On 2011-02-22 15:43, Alain Durand wrote: > > The issue with options in IPv6 is that, if you do not care about > them, you still have to process them one by one before finding the > transport header... > > This is something that middle-boxes using hardware acceleration do > not like. > > In PCP, options are at the end of the packet, so this should be much > less of an issue. > > So it looks like there is no reason why we would be doing this. I don't > see how it could make the server's life any easier. If nobody can come > up with a justification, we're just imposing an arbitrary constraint on > the protocol. > > I can certainly live with that constraint. It's just that usually I > prefer those of the justified kind.... ;) I believe it was Xiaohong Deng, in the interim, that supported the idea of ordering the options, to help hardware implementations. I know we are not doing a hardware implementation of PCP, but other vendors might be. It could help, though, to require the mandatory-to-process options be listed first, so that a PCP server can parse through the packet until it (a) hits the first non-mandatory-to-process option or (b) hits a mandatory-to-process option that it cannot process. But this is a pretty minor optimization in the scheme of things. -d From rpenno@juniper.net Wed Feb 23 16:42:54 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9466F3A691A for ; Wed, 23 Feb 2011 16:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+h0fic6A2RN for ; Wed, 23 Feb 2011 16:42:53 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id E02EF3A659A for ; Wed, 23 Feb 2011 16:42:51 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTWWpvDyh+2YgiKyi8mK+K8zpMU57I/k7@postini.com; Wed, 23 Feb 2011 16:43:41 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 23 Feb 2011 16:37:51 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 23 Feb 2011 19:38:26 -0500 From: Reinaldo Penno To: Dan Wing , 'Simon Perreault' , "pcp@ietf.org" Date: Wed, 23 Feb 2011 19:38:23 -0500 Thread-Topic: [pcp] Option ordering, ticket #41 Thread-Index: AcvTcX6phIuj5AGGQXCQBj4Rd2Dp3gASEfmgAABXan4= Message-ID: In-Reply-To: <1d2301cbd3ba$48a8c930$d9fa5b90$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 00:42:54 -0000 I also support Ordering + mandatory-to-process first for the same reasons. On 2/23/11 4:32 PM, "Dan Wing" wrote: >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of >> Simon Perreault >> Sent: Wednesday, February 23, 2011 7:51 AM >> To: pcp@ietf.org >> Subject: Re: [pcp] Option ordering, ticket #41 >>=20 >> On 2011-02-22 15:43, Alain Durand wrote: >>> The issue with options in IPv6 is that, if you do not care about >> them, you still have to process them one by one before finding the >> transport header... >>> This is something that middle-boxes using hardware acceleration do >> not like. >>> In PCP, options are at the end of the packet, so this should be much >> less of an issue. >>=20 >> So it looks like there is no reason why we would be doing this. I don't >> see how it could make the server's life any easier. If nobody can come >> up with a justification, we're just imposing an arbitrary constraint on >> the protocol. >>=20 >> I can certainly live with that constraint. It's just that usually I >> prefer those of the justified kind.... ;) >=20 > I believe it was Xiaohong Deng, in the interim, that supported the > idea of ordering the options, to help hardware implementations. I > know we are not doing a hardware implementation of PCP, but other > vendors might be. >=20 > It could help, though, to require the mandatory-to-process > options be listed first, so that a PCP server can parse through > the packet until it (a) hits the first non-mandatory-to-process > option or (b) hits a mandatory-to-process option that it cannot > process. But this is a pretty minor optimization in the scheme > of things. >=20 > -d >=20 >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From simon.perreault@viagenie.ca Thu Feb 24 06:29:13 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE07B3A69FE for ; Thu, 24 Feb 2011 06:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tl8peV9NAh6I for ; Thu, 24 Feb 2011 06:29:13 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 939BA3A6A05 for ; Thu, 24 Feb 2011 06:29:12 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4119721B97; Thu, 24 Feb 2011 09:30:01 -0500 (EST) Message-ID: <4D666B68.3090900@viagenie.ca> Date: Thu, 24 Feb 2011 09:30:00 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dan Wing References: <157901cbd2bf$573308e0$05991aa0$@com> <9B57C850BB53634CACEC56EF4853FF653AF846C0@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> <47F9645A-6E04-4F7B-84CE-197C74F168A9@juniper.net> <4D652CDB.4040802@viagenie.ca> <1d2301cbd3ba$48a8c930$d9fa5b90$@com> In-Reply-To: <1d2301cbd3ba$48a8c930$d9fa5b90$@com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pcp@ietf.org Subject: Re: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 14:29:14 -0000 On 2011-02-23 19:32, Dan Wing wrote: > I believe it was Xiaohong Deng, in the interim, that supported the > idea of ordering the options, to help hardware implementations. I > know we are not doing a hardware implementation of PCP, but other > vendors might be. Would it be impolite to expect a technical justification from the person asking for the constraint? I mean, I see people agreeing with the demand, but I still have not seen any justification. > It could help, though, to require the mandatory-to-process > options be listed first, so that a PCP server can parse through > the packet until it (a) hits the first non-mandatory-to-process > option or (b) hits a mandatory-to-process option that it cannot > process. But this is a pretty minor optimization in the scheme > of things. Agreed. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From adurand@juniper.net Thu Feb 24 06:40:37 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3C7B3A6B38 for ; Thu, 24 Feb 2011 06:40:37 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3ONf7wfeHAT for ; Thu, 24 Feb 2011 06:40:36 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 8C4F73A6A06 for ; Thu, 24 Feb 2011 06:40:36 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTWZuFFo5YuTq0jKRU5NP6WOQAxF5FuEa@postini.com; Thu, 24 Feb 2011 06:41:26 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 24 Feb 2011 06:34:54 -0800 From: Alain Durand To: Simon Perreault Date: Thu, 24 Feb 2011 06:35:28 -0800 Thread-Topic: [pcp] Option ordering, ticket #41 Thread-Index: AcvUMAAriCLHN2mLRYqSPc95OhQclA== Message-ID: References: <157901cbd2bf$573308e0$05991aa0$@com> <9B57C850BB53634CACEC56EF4853FF653AF846C0@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> <47F9645A-6E04-4F7B-84CE-197C74F168A9@juniper.net> <4D652CDB.4040802@viagenie.ca> <1d2301cbd3ba$48a8c930$d9fa5b90$@com> <4D666B68.3090900@viagenie.ca> In-Reply-To: <4D666B68.3090900@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 14:40:37 -0000 The best justification I've heard so far is that HW may or may not want to = support 'optional' options. By ordering them and putting the mandatory one first, as soon as a non-nand= atory option is seen, the server can stop processing the packet. It will not have to go through the list trying to fi= nd a subsequent mandatory option. That seems to me a reasonable request attached to a small price tag. - Alain.=20 On Feb 24, 2011, at 9:30 AM, Simon Perreault wrote: > On 2011-02-23 19:32, Dan Wing wrote: >> I believe it was Xiaohong Deng, in the interim, that supported the >> idea of ordering the options, to help hardware implementations. I >> know we are not doing a hardware implementation of PCP, but other >> vendors might be. >=20 > Would it be impolite to expect a technical justification from the person > asking for the constraint? >=20 > I mean, I see people agreeing with the demand, but I still have not seen > any justification. >=20 >> It could help, though, to require the mandatory-to-process >> options be listed first, so that a PCP server can parse through >> the packet until it (a) hits the first non-mandatory-to-process >> option or (b) hits a mandatory-to-process option that it cannot >> process. But this is a pretty minor optimization in the scheme >> of things. >=20 > Agreed. >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From simon.perreault@viagenie.ca Thu Feb 24 06:54:12 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C16583A69FE for ; Thu, 24 Feb 2011 06:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUcEbfMe0KfJ for ; Thu, 24 Feb 2011 06:54:11 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 6D7C93A69FA for ; Thu, 24 Feb 2011 06:54:11 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 797A920EFE; Thu, 24 Feb 2011 09:55:00 -0500 (EST) Message-ID: <4D667143.8080208@viagenie.ca> Date: Thu, 24 Feb 2011 09:54:59 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alain Durand References: <157901cbd2bf$573308e0$05991aa0$@com> <9B57C850BB53634CACEC56EF4853FF653AF846C0@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> <47F9645A-6E04-4F7B-84CE-197C74F168A9@juniper.net> <4D652CDB.4040802@viagenie.ca> <1d2301cbd3ba$48a8c930$d9fa5b90$@com> <4D666B68.3090900@viagenie.ca> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pcp@ietf.org" Subject: Re: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 14:54:12 -0000 On 2011-02-24 09:35, Alain Durand wrote: > The best justification I've heard so far is that HW may or may not want to support 'optional' options. > By ordering them and putting the mandatory one first, as soon as a non-nandatory option is seen, the server can stop > processing the packet. It will not have to go through the list trying to find a subsequent mandatory option. Thanks, got it. > That seems to me a reasonable request attached to a small price tag. I have a different opinion, but as I said earlier, I can live with that. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From rpenno@juniper.net Thu Feb 24 08:27:25 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D63883A63CB for ; Thu, 24 Feb 2011 08:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jcl2LIsxKrac for ; Thu, 24 Feb 2011 08:27:24 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 579D23A67B4 for ; Thu, 24 Feb 2011 08:27:23 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTWaHHWHEOq0KBIZ829qw2wnh4mne7IsL@postini.com; Thu, 24 Feb 2011 08:28:14 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 24 Feb 2011 08:26:25 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 24 Feb 2011 11:27:00 -0500 From: Reinaldo Penno To: Alain Durand , Simon Perreault Date: Thu, 24 Feb 2011 11:26:57 -0500 Thread-Topic: [pcp] Option ordering, ticket #41 Thread-Index: AcvUMAAriCLHN2mLRYqSPc95OhQclAAD6dsg Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 16:27:25 -0000 So, If there are mandatory options 1, 4 and optional 6, 8 the packet would have 1, 4, 6, 8 Correct? On 2/24/11 6:35 AM, "Alain Durand" wrote: > The best justification I've heard so far is that HW may or may not want t= o > support 'optional' options. > By ordering them and putting the mandatory one first, as soon as a > non-nandatory option is seen, the server can stop > processing the packet. It will not have to go through the list trying to = find > a subsequent mandatory option. >=20 > That seems to me a reasonable request attached to a small price tag. >=20 > - Alain.=20 >=20 >=20 >=20 > On Feb 24, 2011, at 9:30 AM, Simon Perreault wrote: >=20 >> On 2011-02-23 19:32, Dan Wing wrote: >>> I believe it was Xiaohong Deng, in the interim, that supported the >>> idea of ordering the options, to help hardware implementations. I >>> know we are not doing a hardware implementation of PCP, but other >>> vendors might be. >>=20 >> Would it be impolite to expect a technical justification from the person >> asking for the constraint? >>=20 >> I mean, I see people agreeing with the demand, but I still have not seen >> any justification. >>=20 >>> It could help, though, to require the mandatory-to-process >>> options be listed first, so that a PCP server can parse through >>> the packet until it (a) hits the first non-mandatory-to-process >>> option or (b) hits a mandatory-to-process option that it cannot >>> process. But this is a pretty minor optimization in the scheme >>> of things. >>=20 >> Agreed. >>=20 >> Simon >> --=20 >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >> _______________________________________________ >> 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 From dwing@cisco.com Thu Feb 24 08:44:02 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C9F83A6407 for ; Thu, 24 Feb 2011 08:44:02 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExuHAu9mGfit for ; Thu, 24 Feb 2011 08:44:01 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 521BA3A63CB for ; Thu, 24 Feb 2011 08:44:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2334; q=dns/txt; s=iport; t=1298565891; x=1299775491; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=vuMUqblB/4icyErB6Go1Tr/U2DCRgiBSiM8Es/JXapU=; b=DG9GfvPRBgQmxTadxfdEKU1T7MWz2GFQAXZKOIypT88DXvpkv0t2FkA2 TpEs+l4Qbuk5RCucKV7+tMLyXqzF0Loa4pz2ND1MXa3fIcub1YAd8REdg NpMCKdZZiT1ipSYxJbLFnRQS0s3kd1yKl7ZvvZ5jlNUaFKTkVnUuzpL6F Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkCAJ8ZZk2tJV2Y/2dsb2JhbACXV4FlhWaCW4Qtc6Igm3aFYASFEA X-IronPort-AV: E=Sophos;i="4.62,219,1297036800"; d="scan'208";a="219300825" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-1.cisco.com with ESMTP; 24 Feb 2011 16:44:50 +0000 Received: from dwingWS ([10.32.240.195]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p1OGioe7019568; Thu, 24 Feb 2011 16:44:50 GMT From: "Dan Wing" To: "'Simon Perreault'" , "'Alain Durand'" References: <157901cbd2bf$573308e0$05991aa0$@com> <9B57C850BB53634CACEC56EF4853FF653AF846C0@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> <47F9645A-6E04-4F7B-84CE-197C74F168A9@juniper.net> <4D652CDB.4040802@viagenie.ca> <1d2301cbd3ba$48a8c930$d9fa5b90$@com> <4D666B68.3090900@viagenie.ca> <4D667143.8080208@viagenie.ca> In-Reply-To: <4D667143.8080208@viagenie.ca> Date: Thu, 24 Feb 2011 08:44:50 -0800 Message-ID: <00d501cbd442$278ec870$76ac5950$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvUMtglrkI6Yo/MS4+Beo0dw7GLFgADh7vA Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 16:44:02 -0000 While editing the text, I ran into a sticky problem. The text will say the request needs to use a specific order for the options. That's fine. However, a client might have a bug (yes, bugs happen), causing the client to send options in a different order. Let's imagine the client sends the options in the order: mandatory-to-process optional-to-process mandatory-to-process When the server receives this message, and it is expecting the options in a certain order, the server might stop processing at that first optional-to-process option. This seems to be a problem. The only way the server can realize the options were sent out of order is to look at all the options. While editing, the best text I can come up with: If the server receives Options that are not in the required order, its behavior for processing all of the Options is unspecified and is implementation-dependent. This feels somewhat dirty. I don't like it, because it creates inconsistency in the protocol. A PCP server that is liberal in what it accepts could accept out-of-order Options and process them properly. But a PCP server that is following the specification would return an error, choke, or have broken operation (from the perspective of the PCP client). -d > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Thursday, February 24, 2011 6:55 AM > To: Alain Durand > Cc: Dan Wing; pcp@ietf.org > Subject: Re: [pcp] Option ordering, ticket #41 > > On 2011-02-24 09:35, Alain Durand wrote: > > The best justification I've heard so far is that HW may or may not > want to support 'optional' options. > > By ordering them and putting the mandatory one first, as soon as a > non-nandatory option is seen, the server can stop > > processing the packet. It will not have to go through the list trying > to find a subsequent mandatory option. > > Thanks, got it. > > > That seems to me a reasonable request attached to a small price tag. > > I have a different opinion, but as I said earlier, I can live with > that. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca From marc.blanchet@viagenie.ca Thu Feb 24 08:55:57 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1840B3A677E for ; Thu, 24 Feb 2011 08:55:57 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wj4WSVs+1NON for ; Thu, 24 Feb 2011 08:55:56 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 949E73A6765 for ; Thu, 24 Feb 2011 08:55:55 -0800 (PST) Received: from mbl.local (bas5-montreal45-1279510288.dsl.bell.ca [76.67.199.16]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9233F21B97 for ; Thu, 24 Feb 2011 11:56:44 -0500 (EST) Message-ID: <4D668DCB.8080706@viagenie.ca> Date: Thu, 24 Feb 2011 11:56:43 -0500 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: pcp@ietf.org References: <157901cbd2bf$573308e0$05991aa0$@com> <9B57C850BB53634CACEC56EF4853FF653AF846C0@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> <47F9645A-6E04-4F7B-84CE-197C74F168A9@juniper.net> <4D652CDB.4040802@viagenie.ca> <1d2301cbd3ba$48a8c930$d9fa5b90$@com> <4D666B68.3090900@viagenie.ca> <4D667143.8080208@viagenie.ca> <00d501cbd442$278ec870$76ac5950$@com> In-Reply-To: <00d501cbd442$278ec870$76ac5950$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 16:55:57 -0000 why not the ietf moto: should send in order, be prepared to receive in any order. Marc. Le 11-02-24 11:44, Dan Wing a écrit : > While editing the text, I ran into a sticky problem. The text will say the > request needs to use a specific order for the options. That's fine. > However, a client might have a bug (yes, bugs happen), causing the client to > send options in a different order. Let's imagine the client sends the > options in the order: > > mandatory-to-process > optional-to-process > mandatory-to-process > > When the server receives this message, and it is expecting the options in a > certain order, the server might stop processing at that first > optional-to-process option. This seems to be a problem. The only way the > server can realize the options were sent out of order is to look at all the > options. While editing, the best text I can come up with: > > If the server receives Options that are not in the required order, its > behavior for processing all of the Options is unspecified and is > implementation-dependent. > > This feels somewhat dirty. I don't like it, because it creates > inconsistency in the protocol. A PCP server that is liberal in what it > accepts could accept out-of-order Options and process them properly. But a > PCP server that is following the specification would return an error, choke, > or have broken operation (from the perspective of the PCP client). > > -d > > >> -----Original Message----- >> From: Simon Perreault [mailto:simon.perreault@viagenie.ca] >> Sent: Thursday, February 24, 2011 6:55 AM >> To: Alain Durand >> Cc: Dan Wing; pcp@ietf.org >> Subject: Re: [pcp] Option ordering, ticket #41 >> >> On 2011-02-24 09:35, Alain Durand wrote: >>> The best justification I've heard so far is that HW may or may not >> want to support 'optional' options. >>> By ordering them and putting the mandatory one first, as soon as a >> non-nandatory option is seen, the server can stop >>> processing the packet. It will not have to go through the list trying >> to find a subsequent mandatory option. >> >> Thanks, got it. >> >>> That seems to me a reasonable request attached to a small price tag. >> >> I have a different opinion, but as I said earlier, I can live with >> that. >> >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca From adurand@juniper.net Thu Feb 24 08:56:52 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28743A6765 for ; Thu, 24 Feb 2011 08:56:52 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-dIyX-hYUD7 for ; Thu, 24 Feb 2011 08:56:51 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 986993A66B4 for ; Thu, 24 Feb 2011 08:56:51 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTWaOBMRoI8WnFxsjeZbD+XMVHvzO0FHF@postini.com; Thu, 24 Feb 2011 08:57:42 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 24 Feb 2011 08:54:47 -0800 From: Alain Durand To: Dan Wing Date: Thu, 24 Feb 2011 08:55:22 -0800 Thread-Topic: [pcp] Option ordering, ticket #41 Thread-Index: AcvUQ4rs7GQUB4kRR6q23vlDmyXhiQ== Message-ID: <01EEB8C8-614A-4ED3-818B-D5B2F2FBA407@juniper.net> References: <157901cbd2bf$573308e0$05991aa0$@com> <9B57C850BB53634CACEC56EF4853FF653AF846C0@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> <47F9645A-6E04-4F7B-84CE-197C74F168A9@juniper.net> <4D652CDB.4040802@viagenie.ca> <1d2301cbd3ba$48a8c930$d9fa5b90$@com> <4D666B68.3090900@viagenie.ca> <4D667143.8080208@viagenie.ca> <00d501cbd442$278ec870$76ac5950$@com> In-Reply-To: <00d501cbd442$278ec870$76ac5950$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 16:56:52 -0000 This is what MUST are for. The client MUST order option. The server MAY discard out of order options. - Alain. On Feb 24, 2011, at 11:44 AM, Dan Wing wrote: > While editing the text, I ran into a sticky problem. The text will say t= he > request needs to use a specific order for the options. That's fine. > However, a client might have a bug (yes, bugs happen), causing the client= to > send options in a different order. Let's imagine the client sends the > options in the order: >=20 > mandatory-to-process > optional-to-process > mandatory-to-process >=20 > When the server receives this message, and it is expecting the options in= a > certain order, the server might stop processing at that first > optional-to-process option. This seems to be a problem. The only way th= e > server can realize the options were sent out of order is to look at all t= he > options. While editing, the best text I can come up with: >=20 > If the server receives Options that are not in the required order, its > behavior for processing all of the Options is unspecified and is > implementation-dependent. =20 >=20 > This feels somewhat dirty. I don't like it, because it creates > inconsistency in the protocol. A PCP server that is liberal in what it > accepts could accept out-of-order Options and process them properly. But= a > PCP server that is following the specification would return an error, cho= ke, > or have broken operation (from the perspective of the PCP client). >=20 > -d >=20 >=20 >> -----Original Message----- >> From: Simon Perreault [mailto:simon.perreault@viagenie.ca] >> Sent: Thursday, February 24, 2011 6:55 AM >> To: Alain Durand >> Cc: Dan Wing; pcp@ietf.org >> Subject: Re: [pcp] Option ordering, ticket #41 >>=20 >> On 2011-02-24 09:35, Alain Durand wrote: >>> The best justification I've heard so far is that HW may or may not >> want to support 'optional' options. >>> By ordering them and putting the mandatory one first, as soon as a >> non-nandatory option is seen, the server can stop >>> processing the packet. It will not have to go through the list trying >> to find a subsequent mandatory option. >>=20 >> Thanks, got it. >>=20 >>> That seems to me a reasonable request attached to a small price tag. >>=20 >> I have a different opinion, but as I said earlier, I can live with >> that. >>=20 >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >=20 From rpenno@juniper.net Thu Feb 24 09:07:40 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BDFF3A677E for ; Thu, 24 Feb 2011 09:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IZTf2C0emZY for ; Thu, 24 Feb 2011 09:07:38 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id A204E3A63CB for ; Thu, 24 Feb 2011 09:07:35 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTWaQid82GETsiNIvKfwQPJNWVmnygUip@postini.com; Thu, 24 Feb 2011 09:08:28 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 24 Feb 2011 09:04:45 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 24 Feb 2011 12:05:21 -0500 From: Reinaldo Penno To: Marc Blanchet , "pcp@ietf.org" Date: Thu, 24 Feb 2011 12:05:18 -0500 Thread-Topic: [pcp] Option ordering, ticket #41 Thread-Index: AcvUQ9TEuD56c5TvQQmjPzlCMs0rQwAAS5Vo Message-ID: In-Reply-To: <4D668DCB.8080706@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 17:07:40 -0000 As long as prepared to receive only means receiving and nothing else. Something like IPv6. If headers are out of order, no guarantees " IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header which is restricted to appear immediately after an IPv6 header only. Nonetheless, it is strongly advised that sources of IPv6 packets adhere to the above recommended order until and unless subsequent specifications revise that recommendation." On 2/24/11 8:56 AM, "Marc Blanchet" wrote: > why not the ietf moto: should send in order, be prepared to receive in > any order. >=20 > Marc. >=20 > Le 11-02-24 11:44, Dan Wing a =E9crit : >> While editing the text, I ran into a sticky problem. The text will say = the >> request needs to use a specific order for the options. That's fine. >> However, a client might have a bug (yes, bugs happen), causing the clien= t to >> send options in a different order. Let's imagine the client sends the >> options in the order: >>=20 >> mandatory-to-process >> optional-to-process >> mandatory-to-process >>=20 >> When the server receives this message, and it is expecting the options i= n a >> certain order, the server might stop processing at that first >> optional-to-process option. This seems to be a problem. The only way t= he >> server can realize the options were sent out of order is to look at all = the >> options. While editing, the best text I can come up with: >>=20 >> If the server receives Options that are not in the required order, it= s >> behavior for processing all of the Options is unspecified and is >> implementation-dependent. >>=20 >> This feels somewhat dirty. I don't like it, because it creates >> inconsistency in the protocol. A PCP server that is liberal in what it >> accepts could accept out-of-order Options and process them properly. Bu= t a >> PCP server that is following the specification would return an error, ch= oke, >> or have broken operation (from the perspective of the PCP client). >>=20 >> -d >>=20 >>=20 >>> -----Original Message----- >>> From: Simon Perreault [mailto:simon.perreault@viagenie.ca] >>> Sent: Thursday, February 24, 2011 6:55 AM >>> To: Alain Durand >>> Cc: Dan Wing; pcp@ietf.org >>> Subject: Re: [pcp] Option ordering, ticket #41 >>>=20 >>> On 2011-02-24 09:35, Alain Durand wrote: >>>> The best justification I've heard so far is that HW may or may not >>> want to support 'optional' options. >>>> By ordering them and putting the mandatory one first, as soon as a >>> non-nandatory option is seen, the server can stop >>>> processing the packet. It will not have to go through the list trying >>> to find a subsequent mandatory option. >>>=20 >>> Thanks, got it. >>>=20 >>>> That seems to me a reasonable request attached to a small price tag. >>>=20 >>> I have a different opinion, but as I said earlier, I can live with >>> that. >>>=20 >>> Simon >>> -- >>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >>> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >>> STUN/TURN server --> http://numb.viagenie.ca >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >=20 From Francis.Dupont@fdupont.fr Thu Feb 24 09:49:39 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84A673A681E for ; Thu, 24 Feb 2011 09:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqhIv5F1jjR5 for ; Thu, 24 Feb 2011 09:49:38 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 7D46A3A6817 for ; Thu, 24 Feb 2011 09:49:38 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p1OHoRQj027112; Thu, 24 Feb 2011 18:50:27 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201102241750.p1OHoRQj027112@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Wed, 23 Feb 2011 16:32:14 PST. <1d2301cbd3ba$48a8c930$d9fa5b90$@com> Date: Thu, 24 Feb 2011 18:50:27 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 17:49:39 -0000 In your previous mail you wrote: But this is a pretty minor optimization in the scheme of things. => and not for all operations, in particular it makes insert clearly more complex... Regards Francis.Dupont@fdupont.fr From dthaler@microsoft.com Thu Feb 24 10:12:44 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F68B3A6843 for ; Thu, 24 Feb 2011 10:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.469 X-Spam-Level: X-Spam-Status: No, score=-110.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXzFHv3ot+E6 for ; Thu, 24 Feb 2011 10:12:42 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id C83B43A6833 for ; Thu, 24 Feb 2011 10:12:42 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 24 Feb 2011 10:13:33 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.270.2; Thu, 24 Feb 2011 10:13:32 -0800 Received: from TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com ([169.254.5.26]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Thu, 24 Feb 2011 10:13:33 -0800 From: Dave Thaler To: Dan Wing , 'Simon Perreault' , 'Alain Durand' Thread-Topic: [pcp] Option ordering, ticket #41 Thread-Index: AcvSv1aQeJbJyXX/QpWJkKS2ZEqnGAAENW4AABEB2YAAKBMngAASNYcAAB1COAAAADDgAAAArn6AAAPWIwAADbOJMA== Date: Thu, 24 Feb 2011 18:13:31 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653AF89E54@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> References: <157901cbd2bf$573308e0$05991aa0$@com> <9B57C850BB53634CACEC56EF4853FF653AF846C0@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> <47F9645A-6E04-4F7B-84CE-197C74F168A9@juniper.net> <4D652CDB.4040802@viagenie.ca> <1d2301cbd3ba$48a8c930$d9fa5b90$@com> <4D666B68.3090900@viagenie.ca> <4D667143.8080208@viagenie.ca> <00d501cbd442$278ec870$76ac5950$@com> In-Reply-To: <00d501cbd442$278ec870$76ac5950$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 18:12:44 -0000 You could say that=20 > If the server receives Options that are not in the required order, it > MUST fail the request. Then there's no inconsistency, and clients with bugs fail fast. -Dave > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dan > Wing > Sent: Thursday, February 24, 2011 8:45 AM > To: 'Simon Perreault'; 'Alain Durand' > Cc: pcp@ietf.org > Subject: Re: [pcp] Option ordering, ticket #41 >=20 > While editing the text, I ran into a sticky problem. The text will say t= he > request needs to use a specific order for the options. That's fine. > However, a client might have a bug (yes, bugs happen), causing the client= to > send options in a different order. Let's imagine the client sends the op= tions > in the order: >=20 > mandatory-to-process > optional-to-process > mandatory-to-process >=20 > When the server receives this message, and it is expecting the options in= a > certain order, the server might stop processing at that first optional-to= - > process option. This seems to be a problem. The only way the server can > realize the options were sent out of order is to look at all the options.= While > editing, the best text I can come up with: >=20 > If the server receives Options that are not in the required order, its > behavior for processing all of the Options is unspecified and is > implementation-dependent. >=20 > This feels somewhat dirty. I don't like it, because it creates inconsist= ency in > the protocol. A PCP server that is liberal in what it accepts could acce= pt out- > of-order Options and process them properly. But a PCP server that is > following the specification would return an error, choke, or have broken > operation (from the perspective of the PCP client). >=20 > -d >=20 >=20 > > -----Original Message----- > > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > > Sent: Thursday, February 24, 2011 6:55 AM > > To: Alain Durand > > Cc: Dan Wing; pcp@ietf.org > > Subject: Re: [pcp] Option ordering, ticket #41 > > > > On 2011-02-24 09:35, Alain Durand wrote: > > > The best justification I've heard so far is that HW may or may not > > want to support 'optional' options. > > > By ordering them and putting the mandatory one first, as soon as a > > non-nandatory option is seen, the server can stop > > > processing the packet. It will not have to go through the list > > > trying > > to find a subsequent mandatory option. > > > > Thanks, got it. > > > > > That seems to me a reasonable request attached to a small price tag. > > > > I have a different opinion, but as I said earlier, I can live with > > that. > > > > Simon > > -- > > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > > STUN/TURN server --> http://numb.viagenie.ca >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From rpenno@juniper.net Thu Feb 24 11:50:29 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825E83A659B for ; Thu, 24 Feb 2011 11:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIQR9HzoTMTn for ; Thu, 24 Feb 2011 11:50:28 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id C4F9D3A6802 for ; Thu, 24 Feb 2011 11:50:23 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTWa2sBSx06CznCFCBGU65X0R7YWkbO3g@postini.com; Thu, 24 Feb 2011 11:51:18 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 24 Feb 2011 11:48:15 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 24 Feb 2011 14:48:51 -0500 From: Reinaldo Penno To: Dave Thaler , Dan Wing , 'Simon Perreault' , Alain Durand Date: Thu, 24 Feb 2011 14:47:30 -0500 Thread-Topic: [pcp] Option ordering, ticket #41 Thread-Index: AcvSv1aQeJbJyXX/QpWJkKS2ZEqnGAAENW4AABEB2YAAKBMngAASNYcAAB1COAAAADDgAAAArn6AAAPWIwAADbOJMAAYFebI Message-ID: In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653AF89E54@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 19:50:29 -0000 Good point. On 2/24/11 10:13 AM, "Dave Thaler" wrote: > You could say that >> If the server receives Options that are not in the required order, it >> MUST fail the request. >=20 > Then there's no inconsistency, and clients with bugs fail fast. >=20 > -Dave >=20 >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Da= n >> Wing >> Sent: Thursday, February 24, 2011 8:45 AM >> To: 'Simon Perreault'; 'Alain Durand' >> Cc: pcp@ietf.org >> Subject: Re: [pcp] Option ordering, ticket #41 >>=20 >> While editing the text, I ran into a sticky problem. The text will say = the >> request needs to use a specific order for the options. That's fine. >> However, a client might have a bug (yes, bugs happen), causing the clien= t to >> send options in a different order. Let's imagine the client sends the >> options >> in the order: >>=20 >> mandatory-to-process >> optional-to-process >> mandatory-to-process >>=20 >> When the server receives this message, and it is expecting the options i= n a >> certain order, the server might stop processing at that first optional-t= o- >> process option. This seems to be a problem. The only way the server ca= n >> realize the options were sent out of order is to look at all the options= . >> While >> editing, the best text I can come up with: >>=20 >> If the server receives Options that are not in the required order, its >> behavior for processing all of the Options is unspecified and is >> implementation-dependent. >>=20 >> This feels somewhat dirty. I don't like it, because it creates inconsis= tency >> in >> the protocol. A PCP server that is liberal in what it accepts could acc= ept >> out- >> of-order Options and process them properly. But a PCP server that is >> following the specification would return an error, choke, or have broken >> operation (from the perspective of the PCP client). >>=20 >> -d >>=20 >>=20 >>> -----Original Message----- >>> From: Simon Perreault [mailto:simon.perreault@viagenie.ca] >>> Sent: Thursday, February 24, 2011 6:55 AM >>> To: Alain Durand >>> Cc: Dan Wing; pcp@ietf.org >>> Subject: Re: [pcp] Option ordering, ticket #41 >>>=20 >>> On 2011-02-24 09:35, Alain Durand wrote: >>>> The best justification I've heard so far is that HW may or may not >>> want to support 'optional' options. >>>> By ordering them and putting the mandatory one first, as soon as a >>> non-nandatory option is seen, the server can stop >>>> processing the packet. It will not have to go through the list >>>> trying >>> to find a subsequent mandatory option. >>>=20 >>> Thanks, got it. >>>=20 >>>> That seems to me a reasonable request attached to a small price tag. >>>=20 >>> I have a different opinion, but as I said earlier, I can live with >>> that. >>>=20 >>> Simon >>> -- >>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >>> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >>> STUN/TURN server --> http://numb.viagenie.ca >>=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 From pselkirk@isc.org Fri Feb 25 10:45:00 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D47B43A69FA for ; Fri, 25 Feb 2011 10:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WP83PyQVbQQp for ; Fri, 25 Feb 2011 10:45:00 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id D098A3A69F3 for ; Fri, 25 Feb 2011 10:44:59 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 602FDC9429 for ; Fri, 25 Feb 2011 18:45:50 +0000 (UTC) (envelope-from pselkirk@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10300) id 56060216C36; Fri, 25 Feb 2011 18:45:50 +0000 (UTC) From: Paul Selkirk To: pcp@ietf.org Date: Fri, 25 Feb 2011 18:45:50 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [pcp] #33: 3rd party mappings: create/destroy X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 18:45:00 -0000 > Consensus that this is needed, need to decide whether in option or main > header. > > => the alternative is between in option or in OpCode, it was never in > main header. Can the ticket be fixed? (BTW this error occurs twice) Francis makes a technical but salient point here - there's very little actually in the main header. Since the internal address had been in both the PIN and PEER request and response headers, we tended to to think of it as being "in the main header". paul From pselkirk@isc.org Fri Feb 25 11:04:06 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE5FC3A66B4 for ; Fri, 25 Feb 2011 11:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-Q9+7cNYDTu for ; Fri, 25 Feb 2011 11:04:06 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id 1E2BB3A69F5 for ; Fri, 25 Feb 2011 11:04:06 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id B01A25F9863 for ; Fri, 25 Feb 2011 19:04:44 +0000 (UTC) (envelope-from pselkirk@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10300) id E5F4B216C22; Fri, 25 Feb 2011 19:04:42 +0000 (UTC) From: Paul Selkirk To: pcp@ietf.org Date: Fri, 25 Feb 2011 19:04:42 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [pcp] #28: UPnP/NAT-PMP Interop functionality in base spec or separate specs X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 19:04:07 -0000 > As of -05, the UPnP interworking details were removed from the base > document. The bast document now points to http://tools.ietf.org/html > /draft-bpw-pcp-upnp-igd-interworking > > Closed. The UPnP IGD IWF document needs to be adopted as a WG document. I think the chairs can do this by fiat. There is no NAT-PMP IWF document. It should be easy to write, and Francis has volunteered to edit it. There should also be a PCP IWF (aka proxy in this case) document. (Note there are some open problems to implement one, so this is not only about completing the IWF document set.) paul From pselkirk@isc.org Fri Feb 25 11:22:49 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 224813A6840 for ; Fri, 25 Feb 2011 11:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R88fg5Yjcrb4 for ; Fri, 25 Feb 2011 11:22:48 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by core3.amsl.com (Postfix) with ESMTP id 437093A6831 for ; Fri, 25 Feb 2011 11:22:48 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 16B81C9429 for ; Fri, 25 Feb 2011 19:23:39 +0000 (UTC) (envelope-from pselkirk@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10300) id 0CBA2216C36; Fri, 25 Feb 2011 19:23:39 +0000 (UTC) From: Paul Selkirk To: pcp@ietf.org Date: Fri, 25 Feb 2011 19:23:39 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 19:22:49 -0000 This whole discussion is about marginal optimization. In the best case, it reduces the cost of a search from O(n) to O(n/2); in the worst case (inserting an option into a request), it increases the cost from O(1) to O(n). This puts an extra burden on the client, when some have said the client should be kept as simple as possible at any price. It also puts a burden on the server, which now needs to validate option ordering as well as the semantics of the individual options. And it still doesn't support hardware acceleration (the original proposed reason), because options are optional, so you can't predict which ones will be present, even if you can now predict their order. (However, if we're going to order the options, it makes sense to put the mandatory-to-process options first.) paul From rpenno@juniper.net Fri Feb 25 12:05:00 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E65D3A6A32 for ; Fri, 25 Feb 2011 12:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+E5ffWF-PxY for ; Fri, 25 Feb 2011 12:04:59 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 8DE7D3A67FB for ; Fri, 25 Feb 2011 12:04:56 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTWgLnYhWYClGm2thDlPuyCsMqV8lgv1O@postini.com; Fri, 25 Feb 2011 12:05:52 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 25 Feb 2011 12:04:41 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 25 Feb 2011 15:05:18 -0500 From: Reinaldo Penno To: Paul Selkirk , "pcp@ietf.org" Date: Fri, 25 Feb 2011 15:05:16 -0500 Thread-Topic: [pcp] Option ordering, ticket #41 Thread-Index: AcvVIaCV9IyhyoumRZWt8l3iRu0ZTgABbEJI Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Option ordering, ticket #41 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 20:05:00 -0000 Hello, Comments inline. On 2/25/11 11:23 AM, "Paul Selkirk" wrote: > This whole discussion is about marginal optimization. In the best case, > it reduces the cost of a search from O(n) to O(n/2); in the worst case > (inserting an option into a request), it increases the cost from O(1) to > O(n). =20 Right, but a PCP Server processes requests for potentially millions of clients and a PCP client has to deal only with its own requests. So, your reduction in the cost of a search certainly makes a difference. > This puts an extra burden on the client, when some have said the > client should be kept as simple as possible at any price. It also puts > a burden on the server, which now needs to validate option ordering as > well as the semantics of the individual options. Does it? Must order does not necessarily means validation. I thought the validation is implicit, see below. >=20 > And it still doesn't support hardware acceleration (the original > proposed reason), because options are optional, so you can't predict > which ones will be present, even if you can now predict their order. There are multiple ways of looking at this. One example: * If I need to see option '2' and I get to option '3', drop packet. As opposed to scan all options. >=20 > (However, if we're going to order the options, it makes sense to put the > mandatory-to-process options first.) >=20 > paul > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From trac@tools.ietf.org Fri Feb 25 18:14:59 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C88B73A6ABE for ; Fri, 25 Feb 2011 18:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvkEZ3GdYSSC for ; Fri, 25 Feb 2011 18:14:59 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 26FBD3A6ABA for ; Fri, 25 Feb 2011 18:14:59 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pt9hJ-0000Mu-37; Fri, 25 Feb 2011 18:15:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com X-Trac-Project: pcp Date: Sat, 26 Feb 2011 02:15:53 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/42 Message-ID: <053.348753fa222b46fb73d8338a4f353235@tools.ietf.org> X-Trac-Ticket-ID: 42 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: [pcp] #42: PEER OpCode: remove internal-ip-address, introduce THIRD_PARTY OpCode X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 02:14:59 -0000 #42: PEER OpCode: remove internal-ip-address, introduce THIRD_PARTY OpCode Currently, the PEER OpCodes contain an internal IP address in their payloads. They are not necessary (the common case being where an application is trying to determine the lifetime of the NAT/firewall mappings). It seems PEER has even _less_ use for 3rd party query/control than MAP. Like MAP, 3rd party query/ control is only necessary when PCP is being proxied _and_ when the user's CPE is not a NAT (i.e., Dual-Stack Lite). I suggest that internal-ip-address be removed from the PEER OpCodes entirely, and use a separate THIRD_PARTY option. This would bring PEER and MAP to function the same way. -- -----------------------------+---------------------------------------------- Reporter: dwing@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: -----------------------------+---------------------------------------------- Ticket URL: pcp From dwing@cisco.com Fri Feb 25 18:17:07 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71B803A6AC1 for ; Fri, 25 Feb 2011 18:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.33 X-Spam-Level: X-Spam-Status: No, score=-110.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dza-hFhlLs-W for ; Fri, 25 Feb 2011 18:17:06 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B713F3A6ABE for ; Fri, 25 Feb 2011 18:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=919; q=dns/txt; s=iport; t=1298686680; x=1299896280; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=5fLXw9VA68n+7tzgMJsbyJ7UYLyzV7ou6qUISUqR1x0=; b=BN2J8P4MImAQzq1xWD+SylkqQ8AJUx4lQrDzJAplUlmv6YPnL4FtcAPm fgXQy6iDw7FyNyPslxi3+aS2CIgpen0MeZa4EDnPAzOTA0zQb4sHpLpeU dRKvULuajx1JQRW326i/bl89u0I8c135XIr7ev7w9eF4mt1NWptHsfqVu s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0GAC/xZ02rRN+K/2dsb2JhbACYL4EmjG10oR+bT4VgBIUQjGc X-IronPort-AV: E=Sophos;i="4.62,229,1297036800"; d="scan'208";a="335414491" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 26 Feb 2011 02:18:00 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p1Q2I32r010921 for ; Sat, 26 Feb 2011 02:18:03 GMT From: "Dan Wing" To: Date: Fri, 25 Feb 2011 18:18:00 -0800 Message-ID: <08d601cbd55b$6400b7e0$2c0227a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvVW2O0fxCeMtdZTJ2ogistXHwDXg== Content-Language: en-us Subject: [pcp] ticket 42: PEER OpCode: remove internal-ip-address, introduce THIRD_PARTY OpCode X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 02:17:07 -0000 Currently, the PEER OpCodes contain an internal IP address in their payloads. See http://tools.ietf.org/html/draft-ietf-pcp-base-04#page-37 The internal IP address is not necessary for the common case -- the common case being where an application is trying to determine the lifetime of its own NAT/firewall mappings. It seems PEER has even _less_ use for 3rd party query/control than MAP. But like MAP, 3rd party query/control is necessary when PCP is being proxied _and_ when the user's CPE is not a NAT (e.g., the B4 element in a Dual-Stack Lite deployment). I suggest that internal-ip-address be removed from the PEER OpCodes entirely, and use a separate THIRD_PARTY option. This would bring PEER and MAP to function the same way. I just opened a new ticket on that, ticket #42, http://trac.tools.ietf.org/wg/pcp/trac/ticket/42 Please reply to this thread on this topic. -d From dwing@cisco.com Fri Feb 25 18:17:28 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F100F3A6AC1 for ; Fri, 25 Feb 2011 18:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.349 X-Spam-Level: X-Spam-Status: No, score=-110.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3sSlR-YlxC2 for ; Fri, 25 Feb 2011 18:17:27 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 436083A6A57 for ; Fri, 25 Feb 2011 18:17:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1159; q=dns/txt; s=iport; t=1298686701; x=1299896301; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=Bc4IH5mk/rBDJFdNE1z8zqC2GKMvP5Wdh/9EAoxTIxM=; b=BdOotEoM/uJcf2ei5aoPGKHjnNCAai1fOYUQ4MrSEUSKXlnc15/ngu0z coCFpByeI1yAtIxuweDUNdZ1XJNHw16bmMcbImgLL/W7ovPiiYR4rOqh2 xjVwZuxkGQfVZWQBje4jseWdJN53tTDT4hX2bs9ELREqYfSXZtlZcg94I Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAAOLxZ02rRN+K/2dsb2JhbACXcIFljG10oSCbT4VgBIUQ X-IronPort-AV: E=Sophos;i="4.62,230,1297036800"; d="scan'208";a="265609666" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 26 Feb 2011 02:18:20 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p1Q2INMF011039; Sat, 26 Feb 2011 02:18:23 GMT From: "Dan Wing" To: "'Paul Selkirk'" , References: In-Reply-To: Date: Fri, 25 Feb 2011 18:18:20 -0800 Message-ID: <08d701cbd55b$6fd3c1c0$4f7b4540$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvVHD9r7LDaW+KNTKygqn9Qma1ixAAPTYuA Content-Language: en-us Subject: Re: [pcp] #33: 3rd party mappings: create/destroy X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 02:17:28 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Paul Selkirk > Sent: Friday, February 25, 2011 10:46 AM > To: pcp@ietf.org > Subject: Re: [pcp] #33: 3rd party mappings: create/destroy > > > Consensus that this is needed, need to decide whether in option > or main > > header. > > > > => the alternative is between in option or in OpCode, it was never in > > main header. Can the ticket be fixed? (BTW this error occurs twice) > > Francis makes a technical but salient point here - there's very little > actually in the main header. Since the internal address had been in > both the PIN and PEER request and response headers, we tended to to > think of it as being "in the main header". The technical point is that Consensus that this is needed, need to decide whether in option or main header. is incorrect, and that it would be more accurate to have written: Consensus that this is needed, need to decide whether in option or in the MAP and PEER OpCodes. .......^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sure, I made a mistake when I wrote that. -d From dwing@cisco.com Fri Feb 25 18:19:46 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 334A53A6AC1 for ; Fri, 25 Feb 2011 18:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.176 X-Spam-Level: X-Spam-Status: No, score=-110.176 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQTQnt8heqpc for ; Fri, 25 Feb 2011 18:19:45 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3E6A63A6A57 for ; Fri, 25 Feb 2011 18:19:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1197; q=dns/txt; s=iport; t=1298686839; x=1299896439; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=H1YOqXd6K3knh3zbrnmPQc1kVluAxnYQ+1JYHbMEkfo=; b=GPpViQ9YxSsu7Hht0j/p2mJVhOJ3Y+opKiOukxza3Ew2pP/aanDCq7vq GRh1vRV3bdTVo6v6KWUjrCpOdXzNib0Z6/V4e2EpoKzGKcJzhpsTsp28v Lce8UyIkGeleExHOGCPmolJTwCRYGnfUmKNUXu36xKA4Bl0ZNvyX5QXov 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwAAKbxZ02rR7H+/2dsb2JhbACXcIFljG10oR+bT4VgBIUQ X-IronPort-AV: E=Sophos;i="4.62,230,1297036800"; d="scan'208";a="664604571" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 26 Feb 2011 02:20:39 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1Q2Kcu5025141; Sat, 26 Feb 2011 02:20:38 GMT From: "Dan Wing" To: "'Paul Selkirk'" , References: In-Reply-To: Date: Fri, 25 Feb 2011 18:20:38 -0800 Message-ID: <08d801cbd55b$c276b1d0$47641570$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvVHuizu5hkKJUiRGWiEmzgU3mnGQAPI75Q Content-Language: en-us Subject: Re: [pcp] #28: UPnP/NAT-PMP Interop functionality in base spec or separate specs X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 02:19:46 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Paul Selkirk > Sent: Friday, February 25, 2011 11:05 AM > To: pcp@ietf.org > Subject: Re: [pcp] #28: UPnP/NAT-PMP Interop functionality in base spec > or separate specs > > > As of -05, the UPnP interworking details were removed from the > base > > document. The bast document now points to > http://tools.ietf.org/html > > /draft-bpw-pcp-upnp-igd-interworking > > > > Closed. > > The UPnP IGD IWF document needs to be adopted as a WG document. > I think the chairs can do this by fiat. I hope they do that soon. Same with the DHCP document. > There is no NAT-PMP IWF document. It should be easy to write, and > Francis has volunteered to edit it. > > There should also be a PCP IWF (aka proxy in this case) document. > (Note there are some open problems to implement one, so this is not > only about completing the IWF document set.) I would consider that a higher priority than NAT-PMP->PCP, myself, because it is necessary for the Dual-Stack Lite B4 element, a home NAT with CGN ("NAT444"), and probably some other scenarios. -d From dwing@cisco.com Mon Feb 28 08:16:47 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533B73A69F9 for ; Mon, 28 Feb 2011 08:16:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.567 X-Spam-Level: X-Spam-Status: No, score=-110.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15FL3vZ-xiK7 for ; Mon, 28 Feb 2011 08:16:46 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 162AE3A693B for ; Mon, 28 Feb 2011 08:16:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2558; q=dns/txt; s=iport; t=1298909867; x=1300119467; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=jSVHQWVr+vns3es0ldnn4Kgbr2hWkU54jY/322A//R8=; b=VgX5k6lZh0ehzZb8r4KwlkxymPUr7a7enGmATEQQqsGIc7rWHWucM37q 6DzV6djo8QYA2DktXAlNcfUJqko1iLPKVrju+/uY5PdGLJLn8DSuX+aVd zt7rGIdIKnPP+7cUtgFXxqfgsVPpXDi9Tm1zGjMVll0AB3f38HeyklFio k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4IAA9Za02rR7Hu/2dsb2JhbACYMoEmjG90oTCbKIVhBIUQ X-IronPort-AV: E=Sophos;i="4.62,240,1297036800"; d="scan'208";a="271805725" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 28 Feb 2011 16:17:46 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1SGHiCW013385; Mon, 28 Feb 2011 16:17:46 GMT From: "Dan Wing" To: Date: Mon, 28 Feb 2011 08:17:46 -0800 Message-ID: <027801cbd763$09539d80$1bfad880$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvXYwkib5zbeIwMRemUcJlLcBh2iw== Content-language: en-us Subject: [pcp] closing #16 and #17 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 16:16:47 -0000 I would like to close tickets #16 and #17. Recent discussions include http://www.ietf.org/mail-archive/web/pcp/current/msg00896.html and is related to both Ticket #17, "using PCP to reduce application-level keepalive traffic" http://trac.tools.ietf.org/wg/pcp/trac/ticket/17 and to Ticket #16, "PCP lifetime expiration with active traffic", http://trac.tools.ietf.org/wg/pcp/trac/ticket/16 Here are my straw-man proposals. Please tear them down so we can discuss this and reach some consensus: 1. PCP would not define if a MAP-created mapping would be terminated or extended by inside->outside traffic. This means this is an implementation-dependent decision to terminate the mapping once the lifetime expires if there is still inside->outside traffic. Obviously, if a PCP client wants to ensure its MAP-created mapping continue to survive, it would need to re-issue MAP requests periodically. This gives the most implementation flexibility to the PCP-controlled device, and may be necessary in some implementations. However, it also means some lazy PCP clients (which don't re-issue their MAP requests) will work with some PCP servers but will fail with other PCP servers -- an aspect I don't like. 2. PCP would define that if PEER is used, it has no effect on the destruction of the mapping. That is, the client can send just one PEER message, and (potentially) never send any more PEER messages for that mapping. Most critically, the PEER response indicates how long the mapping would survive after _any_ traffic is sent for that mapping. Let me explain, because this uncovers a subtle nuance that I would like to get consensus on. Here is an example scenario: a. client establishes TCP connection to a server (e.g., SIP server, XMPP server) b. client issues a PCP PEER request for that connection c. PEER response indicates lifetime is 30 minutes d. every ~25 minutes, client can keep the mapping alive by sending: 1. PCP PEER request, _or_ 2. TCP traffic to its SIP/XMPP server The interesting part is (2)(d)(1), which I would like to get consensus on writing into the specification. IMHO, this is exactly how NAPT devices function today, and seems likely this is how they would function tomorrow. The advantage of (2)(d)(1) is that a PCP client does not need to consume bandwidth (or processing cycles) to re-sending PEER messages when it would have anyway sent an application-level message. Please provide feedback so I can close #16 and #17. Thanks. -d From simon.perreault@viagenie.ca Mon Feb 28 08:35:34 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2D403A6A10 for ; Mon, 28 Feb 2011 08:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NsBRlyYqufS for ; Mon, 28 Feb 2011 08:35:33 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 0F62C3A687C for ; Mon, 28 Feb 2011 08:35:33 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D368C20CF1 for ; Mon, 28 Feb 2011 11:36:32 -0500 (EST) Message-ID: <4D6BCF10.9090408@viagenie.ca> Date: Mon, 28 Feb 2011 11:36:32 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: pcp@ietf.org References: <027801cbd763$09539d80$1bfad880$@com> In-Reply-To: <027801cbd763$09539d80$1bfad880$@com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pcp] closing #16 and #17 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 16:35:35 -0000 On 2011-02-28 11:17, Dan Wing wrote: > 2. PCP would define that if PEER is used, it has no effect on the > destruction of the mapping. That is, the client can send just one PEER > message, and (potentially) never send any more PEER messages for that > mapping. Most critically, the PEER response indicates how long the mapping > would survive after _any_ traffic is sent for that mapping. Let me explain, > because this uncovers a subtle nuance that I would like to get consensus on. > Here is an example scenario: > a. client establishes TCP connection to a server (e.g., SIP server, XMPP > server) > b. client issues a PCP PEER request for that connection > c. PEER response indicates lifetime is 30 minutes > d. every ~25 minutes, client can keep the mapping alive by sending: > 1. PCP PEER request, _or_ > 2. TCP traffic to its SIP/XMPP server > The interesting part is (2)(d)(1), which I would like to get consensus on > writing into the specification. IMHO, this is exactly how NAPT devices > function today, and seems likely this is how they would function tomorrow. > The advantage of (2)(d)(1) is that a PCP client does not need to consume > bandwidth (or processing cycles) to re-sending PEER messages when it would > have anyway sent an application-level message. It's a good idea, but I think it's hardly implementable. It requires the PCP server to be able to modify the NAT's behaviour when it receives data. I think so far we have worked under the assumption that changing NAT behaviour was out of scope. Another thing: this is a micro-optimization. A client will presumably use the PEER request to enlarge the lifetime. Therefore, keep-alive PEER messages will account for very low traffic already. IMHO this optimization is not worth it. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dwing@cisco.com Mon Feb 28 08:43:01 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CAF03A69F9 for ; Mon, 28 Feb 2011 08:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.567 X-Spam-Level: X-Spam-Status: No, score=-110.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRdChduuyfjg for ; Mon, 28 Feb 2011 08:43:00 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E60F03A6AA4 for ; Mon, 28 Feb 2011 08:42:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2831; q=dns/txt; s=iport; t=1298911441; x=1300121041; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=ux9RXwNpvHzpIyGMr3Xb56WHYVPzwt1gIBvTRXdZrLk=; b=klPSfQxQdF8ggNjHsvzJnHun+b+rrUnQLrJ8iB8FFc6A0O81UN6wU63Z ERISMNNhepaay2kJPjxZtis/MZWAt8SUGZr+HUYw9fXJFSal7e+rVks6U vudMUoJ19AzF3BodvPCElfS7jxKPumrz+W3YMNZND9e4tm/LgBgZWNzLX M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUCAJ9fa02rR7Ht/2dsb2JhbACXc4FlhWaCW4QudKEZmzODEYJQBIUQ X-IronPort-AV: E=Sophos;i="4.62,240,1297036800"; d="scan'208";a="266484158" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 28 Feb 2011 16:44:00 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1SGi0oM005719; Mon, 28 Feb 2011 16:44:00 GMT From: "Dan Wing" To: "'Simon Perreault'" , References: <027801cbd763$09539d80$1bfad880$@com> <4D6BCF10.9090408@viagenie.ca> In-Reply-To: <4D6BCF10.9090408@viagenie.ca> Date: Mon, 28 Feb 2011 08:44:00 -0800 Message-ID: <02d401cbd766$b36d4570$1a47d050$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvXZbBRo3mPYyDaTqG8E2k54yCsfQAALzHw Content-language: en-us Subject: Re: [pcp] closing #16 and #17 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 16:43:01 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Simon Perreault > Sent: Monday, February 28, 2011 8:37 AM > To: pcp@ietf.org > Subject: Re: [pcp] closing #16 and #17 > > On 2011-02-28 11:17, Dan Wing wrote: > > 2. PCP would define that if PEER is used, it has no effect on the > > destruction of the mapping. That is, the client can send just one > PEER > > message, and (potentially) never send any more PEER messages for that > > mapping. Most critically, the PEER response indicates how long the > mapping > > would survive after _any_ traffic is sent for that mapping. Let me > explain, > > because this uncovers a subtle nuance that I would like to get > consensus on. > > Here is an example scenario: > > a. client establishes TCP connection to a server (e.g., SIP > server, XMPP > > server) > > b. client issues a PCP PEER request for that connection > > c. PEER response indicates lifetime is 30 minutes > > d. every ~25 minutes, client can keep the mapping alive by > sending: > > 1. PCP PEER request, _or_ > > 2. TCP traffic to its SIP/XMPP server > > The interesting part is (2)(d)(1), which I would like to get > consensus on > > writing into the specification. IMHO, this is exactly how NAPT > devices > > function today, and seems likely this is how they would function > tomorrow. > > The advantage of (2)(d)(1) is that a PCP client does not need to > consume > > bandwidth (or processing cycles) to re-sending PEER messages when it > would > > have anyway sent an application-level message. > > It's a good idea, but I think it's hardly implementable. It requires > the > PCP server to be able to modify the NAT's behaviour when it receives > data. Not necessarily. Rather, the PCP server need only know that, when new inside->outside traffic arrives, it causes the mapping to be extended by NNN minutes. That is already how most NAPT (and firewall) devices function. > I think so far we have worked under the assumption that changing > NAT behaviour was out of scope. Yes, and my straw-man proposal does not violate that assumption. > Another thing: this is a micro-optimization. A client will presumably > use the PEER request to enlarge the lifetime. Therefore, keep-alive > PEER > messages will account for very low traffic already. Agreed on that point. -d > IMHO this optimization is not worth it. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From simon.perreault@viagenie.ca Mon Feb 28 08:46:26 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5497E3A6A10 for ; Mon, 28 Feb 2011 08:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ki-q-4W5A-oX for ; Mon, 28 Feb 2011 08:46:25 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 125EC3A6AA4 for ; Mon, 28 Feb 2011 08:46:24 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AEA3D20CF1; Mon, 28 Feb 2011 11:47:24 -0500 (EST) Message-ID: <4D6BD19C.7080101@viagenie.ca> Date: Mon, 28 Feb 2011 11:47:24 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dan Wing References: <027801cbd763$09539d80$1bfad880$@com> <4D6BCF10.9090408@viagenie.ca> <02d401cbd766$b36d4570$1a47d050$@com> In-Reply-To: <02d401cbd766$b36d4570$1a47d050$@com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pcp@ietf.org Subject: Re: [pcp] closing #16 and #17 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 16:46:26 -0000 On 2011-02-28 11:44, Dan Wing wrote: > Not necessarily. Rather, the PCP server need only know that, when > new inside->outside traffic arrives, it causes the mapping to be > extended by NNN minutes. That is already how most NAPT (and firewall) > devices function. True, but in many NATs the NNN value is a global setting and cannot be overridden per-session. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From adurand@juniper.net Mon Feb 28 08:57:37 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E2043A6C28 for ; Mon, 28 Feb 2011 08:57:37 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JJ-TZZZHaOv for ; Mon, 28 Feb 2011 08:57:36 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3201C3A6A08 for ; Mon, 28 Feb 2011 08:57:36 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTWvUOkL2ffv55nL9X/IzHT8SptYcLj52@postini.com; Mon, 28 Feb 2011 08:58:37 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 28 Feb 2011 08:51:36 -0800 From: Alain Durand To: Dan Wing Date: Mon, 28 Feb 2011 08:52:18 -0800 Thread-Topic: [pcp] closing #16 and #17 Thread-Index: AcvXZ8MRLDCDd1I9SiyPNTmPnOxHPQ== Message-ID: <987EA95E-0B75-4BD8-B383-C964D5EDE211@juniper.net> References: <027801cbd763$09539d80$1bfad880$@com> <4D6BCF10.9090408@viagenie.ca> <02d401cbd766$b36d4570$1a47d050$@com> In-Reply-To: <02d401cbd766$b36d4570$1a47d050$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] closing #16 and #17 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 16:57:37 -0000 On Feb 28, 2011, at 11:44 AM, Dan Wing wrote: >>> 2. TCP traffic to its SIP/XMPP server >>> The interesting part is (2)(d)(1), which I would like to get >> consensus on >>> writing into the specification. IMHO, this is exactly how NAPT >> devices >>> function today, and seems likely this is how they would function >> tomorrow. >>> The advantage of (2)(d)(1) is that a PCP client does not need to >> consume >>> bandwidth (or processing cycles) to re-sending PEER messages when it >> would >>> have anyway sent an application-level message. >>=20 >> It's a good idea, but I think it's hardly implementable. It requires >> the >> PCP server to be able to modify the NAT's behaviour when it receives >> data. >=20 > Not necessarily. Rather, the PCP server need only know that, when > new inside->outside traffic arrives, it causes the mapping to be > extended by NNN minutes. That is already how most NAPT (and firewall) > devices function. By saying that NAT bindings can be created either by TCP SYN or PCP message= , we have already decided that there is a single binding table shared by what= ever the NAT is normally doing and PCP. So, its is normal then to say that bindi= ng lifetimes are extended the same way. IE, either by explicit PCP signaling or by whate= ver the NAT normally does. The point is that the NNN minutes extensions (decided by the= NAT when seeing traffic) is NOT under the control of PCP and, as such, not under the= control of the app. So, if the app wants to maintain the mapping in place, it better send a new= PCP message anyway. - Alain. From dwing@cisco.com Mon Feb 28 09:00:18 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 058DF3A6C4E for ; Mon, 28 Feb 2011 09:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.568 X-Spam-Level: X-Spam-Status: No, score=-110.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9U1kEreqbmB for ; Mon, 28 Feb 2011 09:00:14 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 2AD953A6C5D for ; Mon, 28 Feb 2011 09:00:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1376; q=dns/txt; s=iport; t=1298912473; x=1300122073; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=RbYIOsQT4o1TNIS5N0Aft/mzLsiDAu8xRinczLHA5Ro=; b=V5TlhTiqP0UdncDrajlrugP3O4bHFbXa6rze1sTAITsb6h58VgkOuUpF mAJ5NV1DFiHVohpOajKaEKUS2eUWjUPZfR5htEkQZGwa4zjbP3r/WiihL kBHJwM8gLd80GC7eJhpJ7qKvGN/8+54CgmfCrvn+PEdWm6jOQSKTPqvks w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAACJja02rR7H+/2dsb2JhbACXc4FljG90oRObNoVhBIUQ X-IronPort-AV: E=Sophos;i="4.62,240,1297036800"; d="scan'208";a="315899661" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 28 Feb 2011 17:01:10 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1SH1AeP016058; Mon, 28 Feb 2011 17:01:10 GMT From: "Dan Wing" To: "'Simon Perreault'" References: <027801cbd763$09539d80$1bfad880$@com> <4D6BCF10.9090408@viagenie.ca> <02d401cbd766$b36d4570$1a47d050$@com> <4D6BD19C.7080101@viagenie.ca> In-Reply-To: <4D6BD19C.7080101@viagenie.ca> Date: Mon, 28 Feb 2011 09:01:10 -0800 Message-ID: <000301cbd769$19749600$4c5dc200$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvXZzKOFxjuGJLtTheXcSaRz60dEwAAXWsw Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] closing #16 and #17 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 17:00:18 -0000 > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Sent: Monday, February 28, 2011 8:47 AM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] closing #16 and #17 > > On 2011-02-28 11:44, Dan Wing wrote: > > Not necessarily. Rather, the PCP server need only know that, when > > new inside->outside traffic arrives, it causes the mapping to be > > extended by NNN minutes. That is already how most NAPT (and > firewall) > > devices function. > > True, but in many NATs the NNN value is a global setting and cannot be > overridden per-session. Agreed. But I believe the following text already allows for exactly that case: If the PCP-controlled device can have its lifetime adjusted, the PCP server uses the smaller of its configured maximum lifetime value and the requested lifetime from the PEER request, and sets the lifetime to that value. (Jacni Qin pointed out the text needed some tweaking, so in -05 it will read: If the PCP-controlled device can extend the lifetime of a mapping, the PCP server uses the smaller of its configured maximum lifetime value and the requested lifetime from the PEER request, and sets the lifetime to that value. The PEER4 or PEER6 OpCodes MUST NOT reduce the lifetime of an existing mapping. ... ) -d From adurand@juniper.net Mon Feb 28 09:01:36 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C72A83A6C42 for ; Mon, 28 Feb 2011 09:01:36 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kf43wGSubOfw for ; Mon, 28 Feb 2011 09:01:36 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id D337E3A6C08 for ; Mon, 28 Feb 2011 09:01:35 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTWvVKxWD+gCfpNRk0sslDxS2akXL08ug@postini.com; Mon, 28 Feb 2011 09:02:37 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 28 Feb 2011 08:54:50 -0800 From: Alain Durand To: Simon Perreault Date: Mon, 28 Feb 2011 08:55:31 -0800 Thread-Topic: [pcp] closing #16 and #17 Thread-Index: AcvXaDZb0f47isZCQI2bM5wtD06agg== Message-ID: References: <027801cbd763$09539d80$1bfad880$@com> <4D6BCF10.9090408@viagenie.ca> <02d401cbd766$b36d4570$1a47d050$@com> <4D6BD19C.7080101@viagenie.ca> In-Reply-To: <4D6BD19C.7080101@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] closing #16 and #17 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 17:01:36 -0000 On Feb 28, 2011, at 11:47 AM, Simon Perreault wrote: > On 2011-02-28 11:44, Dan Wing wrote: >> Not necessarily. Rather, the PCP server need only know that, when >> new inside->outside traffic arrives, it causes the mapping to be >> extended by NNN minutes. That is already how most NAPT (and firewall) >> devices function. >=20 > True, but in many NATs the NNN value is a global setting and cannot be > overridden per-session. What I would object to is that if a session was signaled with PCP to be up = by, say, 25 min, and the normal NAT timer is 3 min, that after the initial 25 min, every tim= e the NAT sees a packet for that flow, it would automatically extend the binding life= time by 25 min. Alain.= From dwing@cisco.com Mon Feb 28 10:10:09 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A75C83A6C54 for ; Mon, 28 Feb 2011 10:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.569 X-Spam-Level: X-Spam-Status: No, score=-110.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9cU96dBj05a for ; Mon, 28 Feb 2011 10:10:08 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 7AA593A6C58 for ; Mon, 28 Feb 2011 10:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1422; q=dns/txt; s=iport; t=1298916669; x=1300126269; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=C+t0zX2RUrKqzMef212Ec+gGi36WND+6emQqfrEAoNs=; b=BKcwyt9YoJoSE/X3IvKV1lGeljnCzMy9vb1YuNBsPPfWBYtPcINkjNNh W1zdIqWIEa5mlJPwKxM5YaD8H4pD8mvBs2tfKF4/ntjpn+XP2hKK7Vudo cHm//+S/Ig7RQQsjYLFduxL77Ogc94z3bR2b/4qgPS4m/jhTJ45tiEjZT U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAABJ0a02rR7Ht/2dsb2JhbACXdIFljG90oGGbRIVhBIUP X-IronPort-AV: E=Sophos;i="4.62,241,1297036800"; d="scan'208";a="336353933" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 28 Feb 2011 18:11:08 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1SIB8We024225; Mon, 28 Feb 2011 18:11:08 GMT From: "Dan Wing" To: "'Alain Durand'" , "'Simon Perreault'" References: <027801cbd763$09539d80$1bfad880$@com> <4D6BCF10.9090408@viagenie.ca> <02d401cbd766$b36d4570$1a47d050$@com> <4D6BD19C.7080101@viagenie.ca> In-Reply-To: Date: Mon, 28 Feb 2011 10:11:08 -0800 Message-ID: <009201cbd772$df913470$9eb39d50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvXaDZb0f47isZCQI2bM5wtD06aggACd+GQ Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] closing #16 and #17 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 18:10:09 -0000 > -----Original Message----- > From: Alain Durand [mailto:adurand@juniper.net] > Sent: Monday, February 28, 2011 8:56 AM > To: Simon Perreault > Cc: Dan Wing; pcp@ietf.org > Subject: Re: [pcp] closing #16 and #17 > > > On Feb 28, 2011, at 11:47 AM, Simon Perreault wrote: > > > On 2011-02-28 11:44, Dan Wing wrote: > >> Not necessarily. Rather, the PCP server need only know that, when > >> new inside->outside traffic arrives, it causes the mapping to be > >> extended by NNN minutes. That is already how most NAPT (and > firewall) > >> devices function. > > > > True, but in many NATs the NNN value is a global setting and cannot > be > > overridden per-session. > > What I would object to is that if a session was signaled with PCP to be > up by, say, 25 min, > and the normal NAT timer is 3 min, that after the initial 25 min, every > time the NAT > sees a packet for that flow, it would automatically extend the binding > lifetime by 25 min. So, the PCP server can either: a. store additional information that the lifetime of this mapping is 25 minutes (rather than the 3 minute default). or b. not extend the lifetime to 25 minutes; rather, extend it only to 3 minutes. This is a tradeoff of memory in the PCP server (a) versus PCP requests on the wire (b). I am hearing a preference for (b). So, I will write it up that way. Thanks. -d From adurand@juniper.net Mon Feb 28 10:22:05 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EC323A6A1B for ; Mon, 28 Feb 2011 10:22:05 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5nq8y7m378T for ; Mon, 28 Feb 2011 10:22:00 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 71C1C3A6A0F for ; Mon, 28 Feb 2011 10:21:59 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTWvoAcollDl16cwZ9UifOLDYde7/S+ya@postini.com; Mon, 28 Feb 2011 10:23:00 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 28 Feb 2011 10:15:43 -0800 From: Alain Durand To: Dan Wing Date: Mon, 28 Feb 2011 10:16:25 -0800 Thread-Topic: [pcp] closing #16 and #17 Thread-Index: AcvXc4NYfCKT8aloSy2VM8gLs55BTg== Message-ID: References: <027801cbd763$09539d80$1bfad880$@com> <4D6BCF10.9090408@viagenie.ca> <02d401cbd766$b36d4570$1a47d050$@com> <4D6BD19C.7080101@viagenie.ca> <009201cbd772$df913470$9eb39d50$@com> In-Reply-To: <009201cbd772$df913470$9eb39d50$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] closing #16 and #17 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 18:22:05 -0000 On Feb 28, 2011, at 1:11 PM, Dan Wing wrote: >>=20 >=20 > So, the PCP server can either: >=20 > a. store additional information that the > lifetime of this mapping is 25 minutes (rather than the=20 > 3 minute default). > or > b. not extend the lifetime to 25 minutes; rather, extend it only > to 3 minutes. >=20 >=20 > This is a tradeoff of memory in the PCP server (a) versus PCP > requests on the wire (b). >=20 > I am hearing a preference for (b). So, I will write it up that > way. Thanks. Another way to say it: - PCP messages create/increase lifetimes by amount negotiated by the app in= the PCP dialog - Packets going through the NAT create/increase lifetimes by the NAT-config= ured amount (unknown to app) Alain.= From rpenno@juniper.net Mon Feb 28 10:38:26 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AB5F3A6C49 for ; Mon, 28 Feb 2011 10:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.591 X-Spam-Level: X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVpL25gMG3sz for ; Mon, 28 Feb 2011 10:38:24 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 1EAA83A6C43 for ; Mon, 28 Feb 2011 10:38:04 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTWvryT6Q1/LPmSWpl1NJXWAkjpqHuIEz@postini.com; Mon, 28 Feb 2011 10:39:25 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 28 Feb 2011 10:36:50 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 28 Feb 2011 13:37:32 -0500 From: Reinaldo Penno To: Alain Durand , Dan Wing Date: Mon, 28 Feb 2011 13:37:30 -0500 Thread-Topic: [pcp] closing #16 and #17 Thread-Index: AcvXc4NYfCKT8aloSy2VM8gLs55BTgAAwq93 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] closing #16 and #17 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 18:38:26 -0000 On 2/28/11 10:16 AM, "Alain Durand" wrote: >=20 > On Feb 28, 2011, at 1:11 PM, Dan Wing wrote: >>>=20 >>=20 >> So, the PCP server can either: >>=20 >> a. store additional information that the >> lifetime of this mapping is 25 minutes (rather than the >> 3 minute default). >> or >> b. not extend the lifetime to 25 minutes; rather, extend it only >> to 3 minutes. >>=20 >>=20 >> This is a tradeoff of memory in the PCP server (a) versus PCP >> requests on the wire (b). >>=20 >> I am hearing a preference for (b). So, I will write it up that >> way. Thanks. >=20 > Another way to say it: >=20 > - PCP messages create/increase lifetimes by amount negotiated by the app = in > the PCP dialog > - Packets going through the NAT create/increase lifetimes by the > NAT-configured amount (unknown to app) It might be one of the 'out of scope' things but a few situations that will surely happen * A packet tries to increase the lifetime beyond the one negotiated by PCP. * PCP tries to reduce the lifetime earlier than one set by the receipt of a previous packet. * PCP asks for a lifetime of, say, 30 minutes but the NAT sees a 4-way close/RST. Should the entry go away? * Several other similar ones.... Thanks, Reinaldo >=20 > Alain. > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From adurand@juniper.net Mon Feb 28 12:07:30 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2997E3A6C5B for ; Mon, 28 Feb 2011 12:07:30 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7z5rNMs2wkyo for ; Mon, 28 Feb 2011 12:07:29 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 2CA9A3A6C0C for ; Mon, 28 Feb 2011 12:07:29 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTWwAvfrjevsRA/2UlTKcdtnKZGaeltTM@postini.com; Mon, 28 Feb 2011 12:08:30 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 28 Feb 2011 12:05:05 -0800 From: Alain Durand To: Reinaldo Penno Date: Mon, 28 Feb 2011 12:05:46 -0800 Thread-Topic: [pcp] closing #16 and #17 Thread-Index: AcvXgso3M1H2NE98THCTqSdc11NlnQ== Message-ID: <4A6924A0-B3F7-4854-A11F-D81D58EF1495@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] closing #16 and #17 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 20:07:30 -0000 On Feb 28, 2011, at 1:37 PM, Reinaldo Penno wrote: >=20 > It might be one of the 'out of scope' things but a few situations that wi= ll > surely happen >=20 > * A packet tries to increase the lifetime beyond the one negotiated by PC= P. Not an issue, per algorithm I mention before. PCP says: set lifetime to 1 min, start counting down. Packet flows, lifetim= e is increased by, say 3 min.=20 =20 > * PCP tries to reduce the lifetime earlier than one set by the receipt of= a > previous packet. Same thing. Nothing bad happens. > * PCP asks for a lifetime of, say, 30 minutes but the NAT sees a 4-way > close/RST. Should the entry go away? This is not different than a NAT sees a packet, reset lifetime counter to 3= min, and then immediately sees a close/RST.=20 The larger point here is that PCP negotiated lifetimes are not an absolute = thing. Things are much easier to understand when you start looking at PCP & NAT bi= nding and one and the same, with 2 different ways to create or extend the lifetim= es. - Alain.= From adurand@juniper.net Mon Feb 28 12:18:47 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840B83A6C86 for ; Mon, 28 Feb 2011 12:18:47 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESbuTXMaY0+j for ; Mon, 28 Feb 2011 12:18:46 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 8FD9E3A6C76 for ; Mon, 28 Feb 2011 12:18:46 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTWwDY2UshU3/Y6brntYtJTl1XN6uq6VT@postini.com; Mon, 28 Feb 2011 12:19:48 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 28 Feb 2011 12:17:50 -0800 From: Alain Durand To: Reinaldo Penno Date: Mon, 28 Feb 2011 12:18:31 -0800 Thread-Topic: [pcp] closing #16 and #17 Thread-Index: AcvXhJHsYYO/VJkXQe2vFz9IpABVvw== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] closing #16 and #17 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 20:18:47 -0000 On Feb 28, 2011, at 3:13 PM, Reinaldo Penno wrote: > I was implying is a technical issue. I think the proposed algorithm needs > some wording much like RFC4787. Something like >=20 > "If security policies allow, the receipt of packet will increase the > lifetime of a binding....", etc. Same for other cases. Thanks for clarifying. Yes, the wording here is important to get the detail= s right. - Alain.= From rpenno@juniper.net Mon Feb 28 12:20:56 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A6AB3A6C91 for ; Mon, 28 Feb 2011 12:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.591 X-Spam-Level: X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuKGHM6yZ8Ue for ; Mon, 28 Feb 2011 12:20:54 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 8E86E3A6C6C for ; Mon, 28 Feb 2011 12:20:53 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTWwD4HHOKQ/rV4iCDCO+SAHjwSYHyFUv@postini.com; Mon, 28 Feb 2011 12:21:55 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 28 Feb 2011 12:13:30 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 28 Feb 2011 15:14:12 -0500 From: Reinaldo Penno To: Alain Durand Date: Mon, 28 Feb 2011 15:13:03 -0500 Thread-Topic: [pcp] closing #16 and #17 Thread-Index: AcvXgso3M1H2NE98THCTqSdc11NlnQAARz+Z Message-ID: In-Reply-To: <4A6924A0-B3F7-4854-A11F-D81D58EF1495@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] closing #16 and #17 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 20:20:56 -0000 I was implying is a technical issue. I think the proposed algorithm needs some wording much like RFC4787. Something like "If security policies allow, the receipt of packet will increase the lifetime of a binding....", etc. Same for other cases. On 2/28/11 12:05 PM, "Alain Durand" wrote: >=20 > On Feb 28, 2011, at 1:37 PM, Reinaldo Penno wrote: >>=20 >> It might be one of the 'out of scope' things but a few situations that w= ill >> surely happen >>=20 >> * A packet tries to increase the lifetime beyond the one negotiated by P= CP. >=20 > Not an issue, per algorithm I mention before. > PCP says: set lifetime to 1 min, start counting down. Packet flows, lifet= ime > is increased by, say 3 min. > =20 >=20 >> * PCP tries to reduce the lifetime earlier than one set by the receipt o= f a >> previous packet. >=20 > Same thing. Nothing bad happens. >=20 >=20 >> * PCP asks for a lifetime of, say, 30 minutes but the NAT sees a 4-way >> close/RST. Should the entry go away? >=20 > This is not different than a NAT sees a packet, reset lifetime counter to= 3 > min, and then immediately > sees a close/RST. >=20 > The larger point here is that PCP negotiated lifetimes are not an absolut= e > thing. > Things are much easier to understand when you start looking at PCP & NAT > binding > and one and the same, with 2 different ways to create or extend the lifet= imes. >=20 > - Alain. From jacniq@gmail.com Mon Feb 28 14:39:51 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E8B23A6C09 for ; Mon, 28 Feb 2011 14:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZfXgozRMLL7 for ; Mon, 28 Feb 2011 14:39:50 -0800 (PST) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by core3.amsl.com (Postfix) with ESMTP id CE2C83A6A21 for ; Mon, 28 Feb 2011 14:39:49 -0800 (PST) Received: by gwj22 with SMTP id 22so2324151gwj.27 for ; Mon, 28 Feb 2011 14:40:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yuVOxZ09F9xXTHAqpSdygcqfFqG+vLCNw/RdGv+6A3s=; b=RI+gjTwy9pnvPQjlExB+izrd52z23wwl4BOZ3R82aau28szH4aTwXyJGAfrvY8xIPT jmrDcT4jD81GAb0+oXDLTNbdfG6+jrFsLO7kH5Gj352IXTan6vxu3ZN7AZmAHK3PgN9W brvKZZSbhlot7p5XP9l44u7BI96tvAUvRfzNY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=caXrQ7pio5Zl6V5PSanVrj4GlkEQ60ECVFh8gEV4uSlpJbaaN3+V0lhoz6n+q1UPyV Dx3xkD0xJk2T8AE8RET/i4UrZEP3gSbmPSvHwIC7P1NxlVUqgGQmErSO90MeuRbwTh68 jvsSu3bmBHYtv9ZUEw0fAyxazIdciAYAWDWUM= MIME-Version: 1.0 Received: by 10.236.103.41 with SMTP id e29mr10719710yhg.11.1298932851005; Mon, 28 Feb 2011 14:40:51 -0800 (PST) Received: by 10.147.41.16 with HTTP; Mon, 28 Feb 2011 14:40:50 -0800 (PST) In-Reply-To: <009201cbd772$df913470$9eb39d50$@com> References: <027801cbd763$09539d80$1bfad880$@com> <4D6BCF10.9090408@viagenie.ca> <02d401cbd766$b36d4570$1a47d050$@com> <4D6BD19C.7080101@viagenie.ca> <009201cbd772$df913470$9eb39d50$@com> Date: Tue, 1 Mar 2011 06:40:50 +0800 Message-ID: From: Jacni Qin To: Dan Wing Content-Type: multipart/alternative; boundary=00235445ba902bd8da049d5f5f41 Cc: pcp@ietf.org Subject: Re: [pcp] closing #16 and #17 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 22:39:51 -0000 --00235445ba902bd8da049d5f5f41 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 1, 2011 at 2:11 AM, Dan Wing wrote: > > -----Original Message----- > > From: Alain Durand [mailto:adurand@juniper.net] > > Sent: Monday, February 28, 2011 8:56 AM > > To: Simon Perreault > > Cc: Dan Wing; pcp@ietf.org > > Subject: Re: [pcp] closing #16 and #17 > > > > > > On Feb 28, 2011, at 11:47 AM, Simon Perreault wrote: > > > > > On 2011-02-28 11:44, Dan Wing wrote: > > >> Not necessarily. Rather, the PCP server need only know that, when > > >> new inside->outside traffic arrives, it causes the mapping to be > > >> extended by NNN minutes. That is already how most NAPT (and > > firewall) > > >> devices function. > > > > > > True, but in many NATs the NNN value is a global setting and cannot > > be > > > overridden per-session. > > > > What I would object to is that if a session was signaled with PCP to be > > up by, say, 25 min, > > and the normal NAT timer is 3 min, that after the initial 25 min, every > > time the NAT > > sees a packet for that flow, it would automatically extend the binding > > lifetime by 25 min. > > So, the PCP server can either: > > a. store additional information that the > lifetime of this mapping is 25 minutes (rather than the > 3 minute default). > or > b. not extend the lifetime to 25 minutes; rather, extend it only > to 3 minutes. > > Jacni>: While in this way, it seems that the "app-keepalive" is not reduced, since the new PCP keepalive is created. Cheers, Jacni > > This is a tradeoff of memory in the PCP server (a) versus PCP > requests on the wire (b). > > I am hearing a preference for (b). So, I will write it up that > way. Thanks. > > -d > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > --00235445ba902bd8da049d5f5f41 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Mar 1, 2011 at 2:11 AM, Dan Wing <dwing@cisco.com> wrote:
> -----Original Message-----
> From: Alain Durand [mailto:adur= and@juniper.net]
> Sent: Monday, February 28, 2011 8:56 AM
> To: Simon Perreault
> Cc: Dan Wing; pcp@ietf.org
> Subject: Re: [pcp] closing #16 and #17
>
>
> On Feb 28, 2011, at 11:47 AM, Simon Perreault = wrote:
>
> > On 2011-02-28 11:44, Dan Wing wrote:
> >> Not necessarily. =A0Rather, the PCP server need only know tha= t, when
> >> new inside->outside traffic arrives, it causes the mapping= to be
> >> extended by NNN minutes. =A0That is already how most NAPT (an= d
> firewall)
> >> devices function.
> >
> > True, but in many NATs the NNN value is a global setting and cann= ot
> be
> > overridden per-session.
>
> What I would object to is that if a session was signaled with PCP to b= e
> up by, say, 25 min,
> and the normal NAT timer is 3 min, that after the initial 25 min, ever= y
> time the NAT
> sees a packet for that flow, it would automatically extend the binding=
> lifetime by 25 min.

So, the PCP server can either:

=A0a. store additional information that the
=A0 =A0 lifetime of this mapping is 25 minutes (rather than the
=A0 =A0 3 minute default).
or
=A0b. not extend the lifetime to 25 minutes; rather, extend it only
=A0 =A0 to 3 minutes.

Jacni>: While in= this way, it seems that the "app-keepalive" is not reduced, sinc= e the new PCP keepalive is created.

Cheers,
Jacni
=A0

This is a tradeoff of memory in the PCP server (a) versus PCP
requests on the wire (b).

I am hearing a preference for (b). =A0So, I will write it up that
way. =A0Thanks.

-d


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

--00235445ba902bd8da049d5f5f41-- From adurand@juniper.net Mon Feb 28 14:48:53 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8F63A6BFA for ; Mon, 28 Feb 2011 14:48:53 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ny8zwCG1ODn3 for ; Mon, 28 Feb 2011 14:48:52 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id 339983A6A21 for ; Mon, 28 Feb 2011 14:48:52 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTWwmj6hKgnV6oAJs4leTwn0nzhMdxvpI@postini.com; Mon, 28 Feb 2011 14:49:54 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 28 Feb 2011 14:45:18 -0800 From: Alain Durand To: Jacni Qin Date: Mon, 28 Feb 2011 14:45:59 -0800 Thread-Topic: [pcp] closing #16 and #17 Thread-Index: AcvXmSwklKQe26sGT26fCl1XhQsoQQ== Message-ID: References: <027801cbd763$09539d80$1bfad880$@com> <4D6BCF10.9090408@viagenie.ca> <02d401cbd766$b36d4570$1a47d050$@com> <4D6BD19C.7080101@viagenie.ca> <009201cbd772$df913470$9eb39d50$@com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] closing #16 and #17 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 22:48:53 -0000 On Feb 28, 2011, at 5:40 PM, Jacni Qin wrote: So, the PCP server can either: a. store additional information that the lifetime of this mapping is 25 minutes (rather than the 3 minute default). or b. not extend the lifetime to 25 minutes; rather, extend it only to 3 minutes. Jacni>: While in this way, it seems that the "app-keepalive" is not reduced= , since the new PCP keepalive is created. Jacni: The App should send a new PCP request before the initial 25 min timeout. Th= e whole discussion here is what happens if the app does not do a PCP renew. - Alain. From trac@tools.ietf.org Mon Feb 28 14:54:16 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF9F73A6CB9 for ; Mon, 28 Feb 2011 14:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhjZgF127ya4 for ; Mon, 28 Feb 2011 14:54:16 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 32B7F3A6CB4 for ; Mon, 28 Feb 2011 14:54:16 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PuBzo-0004TO-ME; Mon, 28 Feb 2011 14:55:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dthaler@microsoft.com, dwing@cisco.com X-Trac-Project: pcp Date: Mon, 28 Feb 2011 22:55:16 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/33#comment:2 Message-ID: <062.707aeb8c374e48fb18efe8a2b649f129@tools.ietf.org> References: <053.7ee030084aa57871c688fbc788671e28@tools.ietf.org> X-Trac-Ticket-ID: 33 In-Reply-To: <053.7ee030084aa57871c688fbc788671e28@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dthaler@microsoft.com, dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #33: 3rd party mappings: create/destroy X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 22:54:16 -0000 #33: 3rd party mappings: create/destroy Changes (by dwing@…): * status: new => closed * resolution: => fixed Comment: consensus appears to be THIRD_PARTY option for MAP. Editor noticed that PEER included the internal-ip-address, so PEER will also be changed to use THIRD_PARTY option. Closed. New text will appear in -06. -- -----------------------------+---------------------------------------------- Reporter: dwing@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Mon Feb 28 15:58:51 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 137C23A6CA5 for ; Mon, 28 Feb 2011 15:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQ8X1AlB4pYG for ; Mon, 28 Feb 2011 15:58:50 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 54B103A6828 for ; Mon, 28 Feb 2011 15:58:50 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PuD0K-0000HJ-5p; Mon, 28 Feb 2011 15:59:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com X-Trac-Project: pcp Date: Mon, 28 Feb 2011 23:59:52 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/37#comment:1 Message-ID: <072.cdd2af3c70db7c7a30376c0c625c992e@tools.ietf.org> References: <063.668e2fa4076137b82bb4d8988e6ed76c@tools.ietf.org> X-Trac-Ticket-ID: 37 In-Reply-To: <063.668e2fa4076137b82bb4d8988e6ed76c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #37: create additional NOT_AUTHORIZED result codes X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 23:58:51 -0000 #37: create additional NOT_AUTHORIZED result codes Comment(by dwing@…): THIRD_PARTY can return UNAUTH_TARGET_ADDRESS and UNAUTH_SOURCE_ADDRESS. Are there more we need. This ticket appears related to http://www.ietf.org/mail- archive/web/pcp/current/msg00806.html -- ---------------------------------------+------------------------------------ Reporter: Francis.Dupont@… | Owner: dwing@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: ---------------------------------------+------------------------------------ Ticket URL: pcp From trac@tools.ietf.org Mon Feb 28 15:59:38 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F01583A6CF0 for ; Mon, 28 Feb 2011 15:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIXq-1O2+PzM for ; Mon, 28 Feb 2011 15:59:37 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 19EB03A6CEA for ; Mon, 28 Feb 2011 15:59:37 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PuD14-0006sY-Nd; Mon, 28 Feb 2011 16:00:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com X-Trac-Project: pcp Date: Tue, 01 Mar 2011 00:00:38 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/42#comment:1 Message-ID: <062.2474f6aa232ddc22d19f584a953a012f@tools.ietf.org> References: <053.348753fa222b46fb73d8338a4f353235@tools.ietf.org> X-Trac-Ticket-ID: 42 In-Reply-To: <053.348753fa222b46fb73d8338a4f353235@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #42: PEER OpCode: remove internal-ip-address, introduce THIRD_PARTY OpCode X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 23:59:38 -0000 #42: PEER OpCode: remove internal-ip-address, introduce THIRD_PARTY OpCode Changes (by dwing@…): * status: new => closed * resolution: => fixed Comment: I have received no feedback on this. I will go ahead with this change. -- -----------------------------+---------------------------------------------- Reporter: dwing@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Mon Feb 28 16:12:41 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A7DB3A6CB1 for ; Mon, 28 Feb 2011 16:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5QoQktVKccN for ; Mon, 28 Feb 2011 16:12:40 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BA8FB3A6A41 for ; Mon, 28 Feb 2011 16:12:40 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PuDDi-00033D-Im; Mon, 28 Feb 2011 16:13:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com X-Trac-Project: pcp Date: Tue, 01 Mar 2011 00:13:42 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/41#comment:1 Message-ID: <062.242fa6fcb1e2b3be92d07c6f21b3f796@tools.ietf.org> References: <053.c37df69b4fd40c068b4bcba0ef1fe3c6@tools.ietf.org> X-Trac-Ticket-ID: 41 In-Reply-To: <053.c37df69b4fd40c068b4bcba0ef1fe3c6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #41: PCP Options need to have a specific order, to ease processing X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 00:12:41 -0000 #41: PCP Options need to have a specific order, to ease processing Changes (by dwing@…): * status: new => closed * resolution: => fixed Comment: -06 will require lower..higher ordering for options. text will include: {{{ If several Options are included in a PCP request or response, they MUST be encoded in numeric order by the PCP client and are processed in the order received. The server MUST reject requests that have mis-ordered options with the MISORDERED_OPTIONS error, and this also includes checking optional-to-process options. }}} -- -----------------------------+---------------------------------------------- Reporter: dwing@… | Owner: dwing@… Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Mon Feb 28 16:16:48 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854943A6CBA for ; Mon, 28 Feb 2011 16:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfKXPeWn8AzP for ; Mon, 28 Feb 2011 16:16:47 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CA0843A69B5 for ; Mon, 28 Feb 2011 16:16:47 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PuDHh-00085u-9o; Mon, 28 Feb 2011 16:17:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com X-Trac-Project: pcp Date: Tue, 01 Mar 2011 00:17:49 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/37#comment:2 Message-ID: <072.3f7e033aedea6052b938166178b52f24@tools.ietf.org> References: <063.668e2fa4076137b82bb4d8988e6ed76c@tools.ietf.org> X-Trac-Ticket-ID: 37 In-Reply-To: <063.668e2fa4076137b82bb4d8988e6ed76c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #37: create additional NOT_AUTHORIZED result codes X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 00:16:48 -0000 #37: create additional NOT_AUTHORIZED result codes Changes (by dwing@…): * status: new => closed * resolution: => fixed Comment: Provide specific error codes that are necessary, and specific examples of what causes them. I am closing this until I hear otherwise. (It can be re-opened.) -- ---------------------------------------+------------------------------------ Reporter: Francis.Dupont@… | Owner: dwing@… Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: pcp From trac@tools.ietf.org Mon Feb 28 17:07:24 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37F03A6D27 for ; Mon, 28 Feb 2011 17:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPHp5-BBfYSO for ; Mon, 28 Feb 2011 17:07:23 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 416893A6CDD for ; Mon, 28 Feb 2011 17:07:23 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PuE4b-00048v-Rt; Mon, 28 Feb 2011 17:08:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com, tena@huawei.com X-Trac-Project: pcp Date: Tue, 01 Mar 2011 01:08:21 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/9#comment:4 Message-ID: <062.db7ef8953e4d5be3325cdabee87f2eca@tools.ietf.org> References: <053.1b1c6f67de455592fb5940d895b67860@tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <053.1b1c6f67de455592fb5940d895b67860@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, tena@huawei.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #9: Are PCP-created mappings different from TCP SYN-created ones X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 01:07:24 -0000 #9: Are PCP-created mappings different from TCP SYN-created ones Changes (by dwing@…): * status: assigned => closed * resolution: => fixed Comment: Tried to walk a line here. Strawman text is as follows: new text in the Server Processing section: {{{ Note: it is implementation-specific if the PCP-controlled device destroys the mapping when the lifetime expires, or if inside->outside traffic keeps the mapping alive. }}} and new text in the Client Processing section: {{{ If the PCP client wishes to keep this mapping alive beyond the indicated lifetime, it SHOULD issue a new PCP request prior to the expiration. That is, inside->outside traffic is not sufficient to ensure the mapping will continue to exist. It is RECOMMENDED to send a single renewal request packet when a mapping is halfway to expiration time, then, if no positive response is received, another single renewal request 3/4 of the way to expiration time, and then another at 7/8 of the way to expiration time, and so on, subject to the constraint that renewal requests MUST NOT be sent less than four seconds apart (a PCP client MUST NOT send an infinite number of ever- closer-together requests in the last few seconds before a mapping expires). }}} -- --------------------------------+------------------------------------------- Reporter: dwing@… | Owner: dwing@… Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: pcp From jacniq@gmail.com Mon Feb 28 17:16:51 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D40C3A6D27 for ; Mon, 28 Feb 2011 17:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXsSiFb5VVge for ; Mon, 28 Feb 2011 17:16:50 -0800 (PST) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by core3.amsl.com (Postfix) with ESMTP id 16AF33A6CB4 for ; Mon, 28 Feb 2011 17:16:50 -0800 (PST) Received: by gwj22 with SMTP id 22so2378491gwj.27 for ; Mon, 28 Feb 2011 17:17:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DxmosxpZ/7oDZbhboRK/dVTR6gWYkGuQeKg7n/29P8E=; b=Uz55ILv5oPkAVZ005FobylWH8yydwdzRF5v5b8d2O8X7M11IDTOVdE+u0av3cfN7vk x0yDSmXiL8jN8R7ZhkyOe/EDDLkSLycRTWoR5RxuArqLRDmQlXHBhG9vleAAB816wGwr YCnXETz82KQm0wFPDhv6zxF32FsAXGkV1FH1U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mtnkxH5YNGpGdGhKwyFFve8gvaOc6XMPQ+j3bSd9ovhowEl7uOz/2lguRivMUDeHHz dHHlgEdHOEVyaIRxJ/ISzBTO5lCX/rKwOq6Ahm1JS3jkj67NJAHM9zyQojq4tmQpTSA0 8MEyfeld1GFESDeNrQauGOGNcsGGletu9ttR4= MIME-Version: 1.0 Received: by 10.146.167.7 with SMTP id p7mr8837600yae.10.1298942271388; Mon, 28 Feb 2011 17:17:51 -0800 (PST) Received: by 10.147.41.16 with HTTP; Mon, 28 Feb 2011 17:17:51 -0800 (PST) In-Reply-To: References: <027801cbd763$09539d80$1bfad880$@com> <4D6BCF10.9090408@viagenie.ca> <02d401cbd766$b36d4570$1a47d050$@com> <4D6BD19C.7080101@viagenie.ca> <009201cbd772$df913470$9eb39d50$@com> Date: Tue, 1 Mar 2011 09:17:51 +0800 Message-ID: From: Jacni Qin To: Alain Durand Content-Type: multipart/alternative; boundary=20cf3054a929ab82d5049d61901b Cc: "pcp@ietf.org" Subject: Re: [pcp] closing #16 and #17 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 01:16:51 -0000 --20cf3054a929ab82d5049d61901b Content-Type: text/plain; charset=ISO-8859-1 Hi Alain, On Tue, Mar 1, 2011 at 6:45 AM, Alain Durand wrote: > > On Feb 28, 2011, at 5:40 PM, Jacni Qin wrote: > > > So, the PCP server can either: > > a. store additional information that the > lifetime of this mapping is 25 minutes (rather than the > 3 minute default). > or > b. not extend the lifetime to 25 minutes; rather, extend it only > to 3 minutes. > > Jacni>: While in this way, it seems that the "app-keepalive" is not > reduced, since the new PCP keepalive is created. > > > Jacni: > > The App should send a new PCP request before the initial 25 min timeout. > The whole discussion here is what happens if the app does not do a PCP > renew. > Jacni>: Sorry, I'm a little confused, if "not extend the lifetime to 25 minutes, rather only to 3 minutes", which means the request for extending lifetime is rejected and the client is told by the response that the mapping would survive for 3 minutes after any traffic is sent for that mapping, then if there are normal active traffics sent anyway, that's ok, otherwise the client will have to maintain the mapping either by sending app-keepalive or re-initiating a PCP. Our goal is to reduce the keepalive (by any means) for mappings, so if the client wants to achieve this it should employ the PCP tools even it is a lazy one. And a PCP server supporting this feature should accept the reasonable PCP request for extending lifetime, and in this case it seems ok for active traffics to reset the lifetime to 25 minutes. Otherwise, the client is indicated that "No, you should be always active, or the mapping will be deleted after 3 minutes", so if I understand it correctly, why do we need the PEER in this case, just to remind the client the exact value of lifetime? Cheers, Jacni - Alain. > > --20cf3054a929ab82d5049d61901b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alain,

On Tue, Mar 1, 2011 at 6:45 AM, Alain Durand &l= t;adurand@juniper.= net> wrote:

On Feb 28, 2011, at 5:40 PM, Jacni Qin wrote:


So, the PCP server can either:

=A0a. store additional information that the
=A0 =A0lifetime of this mapping is 25 minutes (rather than the
=A0 =A03 minute default).
or
=A0b. not extend the lifetime to 25 minutes; rather, extend it only
=A0 =A0to 3 minutes.

Jacni>: While in this way, it seems that the "app-keepalive" i= s not reduced, since the new PCP keepalive is created.


Jacni:

The App should send a new PCP request before the initial 25 min timeout. Th= e whole discussion here is what happens if the app does not do a PCP renew.=

Jacni>: Sorr= y, I'm a little confused, if "not extend the lifetime to 25 minute= s, rather only to 3 minutes", which means the request for extending li= fetime is rejected and the client is told by the response that the mapping = would survive for 3 minutes after any traffic is sent for that mapping, the= n if there are normal active traffics sent anyway, that's ok, otherwise= the client will have to maintain the mapping either by sending app-keepali= ve or re-initiating a PCP.

Our goal is to reduce the keepalive (by any means) for mappings, so if = the client wants to achieve this it should employ the PCP tools even it is = a lazy one. And a PCP server supporting this feature should accept the reas= onable PCP request for extending lifetime, and in this case it seems ok for= active traffics to reset the lifetime to 25 minutes.
Otherwise, the client is indicated that "No, you should be always acti= ve, or the mapping will be deleted after 3 minutes", so if I understan= d it correctly, why do we need the PEER in this case, just to remind the cl= ient the exact value of lifetime?


Cheers,
Jacni


=A0 - Alain.


--20cf3054a929ab82d5049d61901b-- From Internet-Drafts@ietf.org Mon Feb 28 17:30:04 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892A83A6D61; Mon, 28 Feb 2011 17:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auhX+1lAEC2q; Mon, 28 Feb 2011 17:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7B23A6D51; Mon, 28 Feb 2011 17:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110301013002.628.94277.idtracker@localhost> Date: Mon, 28 Feb 2011 17:30:02 -0800 Cc: pcp@ietf.org Subject: [pcp] I-D Action:draft-ietf-pcp-base-06.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 01:30:04 -0000 --NextPart 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 : Port Control Protocol (PCP) Author(s) : D. Wing, et al. Filename : draft-ietf-pcp-base-06.txt Pages : 57 Date : 2011-02-28 Port Control Protocol allows a host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall to an IPv6 or IPv4 host, and also allows a host to optimize its NAT keepalive messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcp-base-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-28171605.I-D@ietf.org> --NextPart-- From adurand@juniper.net Mon Feb 28 17:37:44 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA5893A6D6E for ; Mon, 28 Feb 2011 17:37:44 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ai4semf60fYb for ; Mon, 28 Feb 2011 17:37:44 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id AD91E3A6D6D for ; Mon, 28 Feb 2011 17:37:43 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTWxOImP2fcWjCO4zpBHLjUPFgYEhSc1D@postini.com; Mon, 28 Feb 2011 17:38:45 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 28 Feb 2011 17:28:53 -0800 From: Alain Durand To: Jacni Qin Date: Mon, 28 Feb 2011 17:29:35 -0800 Thread-Topic: [pcp] closing #16 and #17 Thread-Index: AcvXsAaGFcvFhVd6TNGK1yxTHmrFtQ== Message-ID: <4AE50D00-9E43-47E1-871C-7AF30336B11E@juniper.net> References: <027801cbd763$09539d80$1bfad880$@com> <4D6BCF10.9090408@viagenie.ca> <02d401cbd766$b36d4570$1a47d050$@com> <4D6BD19C.7080101@viagenie.ca> <009201cbd772$df913470$9eb39d50$@com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] closing #16 and #17 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 01:37:44 -0000 On Feb 28, 2011, at 8:17 PM, Jacni Qin wrote: Jacni>: Sorry, I'm a little confused, if "not extend the lifetime to 25 min= utes, rather only to 3 minutes", which means the request for extending life= time is rejected and the client is told by the response that the mapping wo= uld survive for 3 minutes after any traffic is sent for that mapping, then = if there are normal active traffics sent anyway, that's ok, otherwise the c= lient will have to maintain the mapping either by sending app-keepalive or = re-initiating a PCP. Jacni: There seems to be some confusion here. Why would the PCP server refuse to extend the lifetime by another 25min? I = can see no reasons... The normal mode of operation is: connect PCP request set lifetime to 25 min [time passes] [less than 25 minutes later] PCP request to set the lifetime to 25min repeat This achieves the stated goal of reducing keep alive. Alain. From dwing@cisco.com Mon Feb 28 17:39:55 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 217883A6D6D for ; Mon, 28 Feb 2011 17:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2HxdCIpjdwO for ; Mon, 28 Feb 2011 17:39:54 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 1DC7D3A6D6A for ; Mon, 28 Feb 2011 17:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1427; q=dns/txt; s=iport; t=1298943656; x=1300153256; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=5+jHPcOuHQrCaLvvP/QPJw3Osnk/6YbBYg7U5+z/Z/8=; b=UoZJZEGRZ8Qt/GvBSZ8TsmDDvkDU0PUAKvobdoFdS5fjzzjfx7EymAdV xU2FPqIjOAX6WAdCrUd5whNfv6egy+TR4kkGzNDTlkjk4rzSWEuinM7PN dhXkpTacybMVvZscRiWA9iev4Zk/lgRlvORCoPT454KIaLsUgQRqkz8Zg A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAHvda02rR7Hu/2dsb2JhbACXdIFljG90n0ybaYVhBIUS X-IronPort-AV: E=Sophos;i="4.62,244,1297036800"; d="scan'208";a="336620994" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 01 Mar 2011 01:40:55 +0000 Received: from dwingWS (dhcp-128-107-104-148.cisco.com [128.107.104.148]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p211etFv007089; Tue, 1 Mar 2011 01:40:55 GMT From: "Dan Wing" To: "'Alain Durand'" , "'Jacni Qin'" References: <027801cbd763$09539d80$1bfad880$@com> <4D6BCF10.9090408@viagenie.ca> <02d401cbd766$b36d4570$1a47d050$@com> <4D6BD19C.7080101@viagenie.ca> <009201cbd772$df913470$9eb39d50$@com> <4AE50D00-9E43-47E1-871C-7AF30336B11E@juniper.net> In-Reply-To: <4AE50D00-9E43-47E1-871C-7AF30336B11E@juniper.net> Date: Mon, 28 Feb 2011 17:40:55 -0800 Message-ID: <03df01cbd7b1$b52c8c90$1f85a5b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvXsAaGFcvFhVd6TNGK1yxTHmrFtQAAYauQ Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] closing #16 and #17 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 01:39:55 -0000 > -----Original Message----- > From: Alain Durand [mailto:adurand@juniper.net] > Sent: Monday, February 28, 2011 5:30 PM > To: Jacni Qin > Cc: Dan Wing; Simon Perreault; pcp@ietf.org > Subject: Re: [pcp] closing #16 and #17 > > > On Feb 28, 2011, at 8:17 PM, Jacni Qin wrote: > > > Jacni>: Sorry, I'm a little confused, if "not extend the lifetime to 25 > minutes, rather only to 3 minutes", which means the request for > extending lifetime is rejected and the client is told by the response > that the mapping would survive for 3 minutes after any traffic is sent > for that mapping, then if there are normal active traffics sent anyway, > that's ok, otherwise the client will have to maintain the mapping > either by sending app-keepalive or re-initiating a PCP. > > Jacni: There seems to be some confusion here. > Why would the PCP server refuse to extend the lifetime by another > 25min? I can see no reasons... > > The normal mode of operation is: > > connect > PCP request set lifetime to 25 min > [time passes] > [less than 25 minutes later] > PCP request to set the lifetime to 25min > repeat > > This achieves the stated goal of reducing keep alive. Jacni's point is that if there is inside->outside traffic that would have kept the mapping alive, the periodic PCP PEER request message (send 'less than 25 minutes later', per your example) is additional traffic. -d From dwing@cisco.com Mon Feb 28 17:40:09 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B123B3A6D74 for ; Mon, 28 Feb 2011 17:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.213 X-Spam-Level: X-Spam-Status: No, score=-110.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJ-L-fr73U48 for ; Mon, 28 Feb 2011 17:40:07 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 3CB853A6D6A for ; Mon, 28 Feb 2011 17:40:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3186; q=dns/txt; s=iport; t=1298943669; x=1300153269; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=1Arx7JZOon1DkgkkfVICQGPJL+avXAa7eIhAeBBa8Qo=; b=lMUBrl0eLdspPPouqFkQgmgFF5dsOgG+aIS+MnI9EWFKy0JOy6f311PZ K5Js5241x6CYNO9I8/xPpm0Hw6QkafZ2nl9McaPKEMn4nZDhAnuWZ9AJC hfp4SWR89sgWj4udg5HBtAFPKzH0eaJnBBCcNFSvmP6uBkpjWM1KYGr85 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwHAA3da02rRN+J/2dsb2JhbACYM4EmjG90n0qbaYVhBIUS X-IronPort-AV: E=Sophos;i="4.62,244,1297036800"; d="scan'208";a="266819632" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 01 Mar 2011 01:41:09 +0000 Received: from dwingWS (dhcp-128-107-104-148.cisco.com [128.107.104.148]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p211f9kC016163; Tue, 1 Mar 2011 01:41:09 GMT From: "Dan Wing" To: Date: Mon, 28 Feb 2011 17:41:08 -0800 Message-ID: <03e001cbd7b1$bcfb2530$36f16f90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvXsbzW/qYWz0gSScqzdfd0LEd0iA== Content-Language: en-us Cc: draft-ietf-pcp-base@tools.ietf.org Subject: [pcp] pcp-base-06 submitted X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 01:40:10 -0000 As editor, I believe all the open issues are now resolved. So, this is really the time for everyone to read the document and see if you agree. If possible, please refer to the tracker Issue number. All issues (including closed) are visible at http://trac.tools.ietf.org/wg/pcp/trac/report/6. The ones marked 'enhancement' are being solved in other documents. Document available at: http://tools.ietf.org/html/draft-ietf-pcp-base-06, and click on PDF at the top for an easy way to print it. Diffs from -05 available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-06.txt and summarized below and also in document's Appendix. -d ----- o DS-Lite: consensus was encapsulation mode. Included a suggestion that the B4 will need to proxy PCP-to-PCP and UPnP-to-PCP. o defined THIRD_PARTY option to work with the PEER OpCode, too. This meant moving it to its own section, and having both MAP and PEER OpCodes reference that common section. o used "target" instead of "internal", in the hopes that clarifies internal address used by PCP itself (for sending its packets) versus the address for MAPpings. o Options are now required to be ordered in requests, and ordering has to be validated by the server. Intent is to ease server processing of mandatory-to-implement options. o Swapped Option values for the mandatory- and optional-to-process Options, so we can have a simple lowest..highest ordering. o added MISORDERED_OPTIONS error. o re-ordered some error messages to cause MALFORMED_REQUEST (which is PCP's most general error response) to be error 1, instead of buried in the middle of the error numbers. o clarified that, after successfully using a PCP server, that PCP server is declared to be non-responsive after 5 failed retransmissions. o tightened up text (which was inaccurate) about how long general PCP processing is to delay when receiving an error and if it should honor OpCode-specific error lifetime. Useful for MAP errors which have an error lifetime. (This all feels awkward to have only some errors with a lifetime.) o Added better discussion of multiple interfaces, including highlighting WiFi+Ethernet. Added discussion of using IPv6 Privacy Addresses and RFC1918 as source addresses for PCP requests. This should finish the section on multi-interface issues. o added some text about why server might send SERVER_OVERLOADED, or might simply discard packets. o Dis-allow internal-port=0, which means we dis-allow using PCP as a DMZ-like function. Instead, ports have to be mapped individually. o Text describing server's processing of PEER is tightened up. o Server's processing of PEER now says it is implementation-specific if a PCP server continues to allow the mapping to exist after a PEER message. Client's processing of PEER says that if client wants mapping to continue to exist, client has to continue to send recurring PEER messages. From adurand@juniper.net Mon Feb 28 18:15:36 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CED23A6CB5 for ; Mon, 28 Feb 2011 18:15:36 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7avvDbNwWLyQ for ; Mon, 28 Feb 2011 18:15:35 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id AD50D3A6C4C for ; Mon, 28 Feb 2011 18:15:35 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTWxXA50B4DvbSt6Vw0jFcCVMKMvW6dfs@postini.com; Mon, 28 Feb 2011 18:16:37 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 28 Feb 2011 18:06:01 -0800 From: Alain Durand To: Dan Wing Date: Mon, 28 Feb 2011 18:06:42 -0800 Thread-Topic: [pcp] closing #16 and #17 Thread-Index: AcvXtTYrWXlFTSo7QkSsE5w26N7e6Q== Message-ID: References: <027801cbd763$09539d80$1bfad880$@com> <4D6BCF10.9090408@viagenie.ca> <02d401cbd766$b36d4570$1a47d050$@com> <4D6BD19C.7080101@viagenie.ca> <009201cbd772$df913470$9eb39d50$@com> <4AE50D00-9E43-47E1-871C-7AF30336B11E@juniper.net> <03df01cbd7b1$b52c8c90$1f85a5b0$@com> In-Reply-To: <03df01cbd7b1$b52c8c90$1f85a5b0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] closing #16 and #17 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 02:15:36 -0000 On Feb 28, 2011, at 8:40 PM, Dan Wing wrote: >=20 > Jacni's point is that if there is inside->outside traffic that > would have kept the mapping alive, the periodic PCP PEER request=20 > message (send 'less than 25 minutes later', per your example) is=20 > additional traffic. Are we really concerned about one extra 2-packet exchange every 25 minutes? - Alain. From jacniq@gmail.com Mon Feb 28 18:25:26 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81B7C3A6C4C for ; Mon, 28 Feb 2011 18:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZCDQ0LVqPKb for ; Mon, 28 Feb 2011 18:25:21 -0800 (PST) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by core3.amsl.com (Postfix) with ESMTP id EC43D3A6959 for ; Mon, 28 Feb 2011 18:25:20 -0800 (PST) Received: by gwj22 with SMTP id 22so2399985gwj.27 for ; Mon, 28 Feb 2011 18:26:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BCItoZiU0OU8ivUMHYcQUl0fS2D3Wu8UJ2kMtO7M4To=; b=VCwTOhQVqhUCdQfRXSMCDrLFwn1o84oQyQVxgk/13Ni3GjmGa7u2TZZP54l0QjZ6KW AAVp7+ZFiFJbS7jfJ2FGbtHFIx7L3v7QvvLQZErYtO88EON8umA/h31pQbOmFu5ItzS7 uVpjvDQmTg2JljFPCPGSrcLOhoGHoXsZXrPXQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=o/hPSWuJ3gkGJvMpNC7+Fs2XFdNci9YV2MMXujKyqVNQAPk+DKjRILjB3axhZjOi5f VeWVguI1u+Yk2B812dGPXlbD8YoAMmWI2qKx01Sq3zfCUEItGCrzNvO31CQXymGjpI0a HeA3z/MQPmZVI1rRHsKM7bNsNobuBSH/BtVk8= MIME-Version: 1.0 Received: by 10.151.8.8 with SMTP id l8mr4422738ybi.94.1298946382544; Mon, 28 Feb 2011 18:26:22 -0800 (PST) Received: by 10.147.41.16 with HTTP; Mon, 28 Feb 2011 18:26:22 -0800 (PST) In-Reply-To: References: <027801cbd763$09539d80$1bfad880$@com> <4D6BCF10.9090408@viagenie.ca> <02d401cbd766$b36d4570$1a47d050$@com> <4D6BD19C.7080101@viagenie.ca> <009201cbd772$df913470$9eb39d50$@com> <4AE50D00-9E43-47E1-871C-7AF30336B11E@juniper.net> <03df01cbd7b1$b52c8c90$1f85a5b0$@com> Date: Tue, 1 Mar 2011 10:26:22 +0800 Message-ID: From: Jacni Qin To: Alain Durand Content-Type: multipart/alternative; boundary=000e0cd40422b6bf3b049d6285bd Cc: "pcp@ietf.org" Subject: Re: [pcp] closing #16 and #17 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 02:25:26 -0000 --000e0cd40422b6bf3b049d6285bd Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 1, 2011 at 10:06 AM, Alain Durand wrote: > > On Feb 28, 2011, at 8:40 PM, Dan Wing wrote: > > > > > Jacni's point is that if there is inside->outside traffic that > > would have kept the mapping alive, the periodic PCP PEER request > > message (send 'less than 25 minutes later', per your example) is > > additional traffic. > > Are we really concerned about one extra 2-packet exchange every 25 minutes? > Jacni>: Another thing is in this way, the mapping can be simply deleted if the timer expires without any concern. Cheers, Jacni > > - Alain. > --000e0cd40422b6bf3b049d6285bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Mar 1, 2011 at 10:06 AM, Alain Durand <adurand@juniper.net> wrote:<= br>

On Feb 28, 2011, at 8:40 PM, Dan Wing wrote:

>
> Jacni's point is that if there is inside->outside traffic that<= br> > would have kept the mapping alive, the periodic PCP PEER request
> message (send 'less than 25 minutes later', per your example) = is
> additional traffic.

Are we really concerned about one extra 2-packet exchange every 25 mi= nutes?

Jacni>= : Another thing is in this way, the mapping can be simply deleted if the ti= mer expires without any concern.

Cheers,
Jacni

=A0 - Alain.

--000e0cd40422b6bf3b049d6285bd-- From trac@tools.ietf.org Mon Feb 28 23:53:11 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B5CB3A6A03 for ; Mon, 28 Feb 2011 23:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJ0Iv3Gi+7GI for ; Mon, 28 Feb 2011 23:53:10 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8FBE53A6A08 for ; Mon, 28 Feb 2011 23:53:10 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PuKPM-0005Xf-TD; Mon, 28 Feb 2011 23:54:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com, tena@huawei.com X-Trac-Project: pcp Date: Tue, 01 Mar 2011 07:54:12 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/17#comment:3 Message-ID: <062.a5539831816944e2b34cfa3a8393b309@tools.ietf.org> References: <053.b7ab218e1afd86908d988f82b6167bd8@tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <053.b7ab218e1afd86908d988f82b6167bd8@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, tena@huawei.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #17: using PCP to reduce application-level keepalive traffic X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 07:53:11 -0000 #17: using PCP to reduce application-level keepalive traffic Comment(by tena@…): (Sorry for late reply, due to travelling) If we use traffic to refresh, the application would not know when the NAT entry set up by PEER message be expired. So I think the entries set by the PEER message should be refreshed and made expired by PEER message. Although it is OK to use application message to refresh NAT entry, I still worry about there is no application message to use for it for some application at all. For example, there is a FTP server in internal network; PCP is used to set up a NAT entry in the NAT device. Before connected to a FTP Client, there is no application message to be used at all. In this case, it still depends on PEER message to refresh. If only use application message to refresh, PCP client cannot recreate the NAT entry when PCP server reboots. Although the application is normally sending traffic more frequently than PEER messages, but if using traffic to refresh, NAT device processing NAT entries would be relatively complicated. If so, NAT entry’s refreshment needs to differentiate PEER message and traffic. If PEER message request is 1 hour, traffic would be more frequent. How each message of traffic to refresh NAT entry? Should each pact refresh the NAT entry 1 hour? I prefer re-sent forever, which makes NAT device process simpler. -- --------------------------------+------------------------------------------- Reporter: dwing@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: pcp