From dwing@cisco.com Mon Jan 3 17:32:10 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 293263A67AB for ; Mon, 3 Jan 2011 17:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.515 X-Spam-Level: X-Spam-Status: No, score=-110.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 KIFdi9xnCFHO for ; Mon, 3 Jan 2011 17:32: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 BC4033A67A7 for ; Mon, 3 Jan 2011 17:32:08 -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: Av0EAFkIIk2rR7Hu/2dsb2JhbACXPox4c6I7mRuFSgSEZQ X-IronPort-AV: E=Sophos;i="4.60,269,1291593600"; d="scan'208";a="309831211" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 04 Jan 2011 01:34:15 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p041YFh2011585; Tue, 4 Jan 2011 01:34:15 GMT From: "Dan Wing" To: , "'Francis Dupont'" References: Your message of Tue, 21 Dec 2010 07:02:10 GMT. <074.2ce024e471569bc9fa049a9d88685836@tools.ietf.org> <201012211057.oBLAvMhZ091467@givry.fdupont.fr> <10f201cba180$8bfe8470$a3fb8d50$@com> <3131_1293551120_4D1A0610_3131_20639_1_94C682931C08B048B7A8645303FDC9F33C3E6198E4@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <3131_1293551120_4D1A0610_3131_20639_1_94C682931C08B048B7A8645303FDC9F33C3E6198E4@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 3 Jan 2011 17:34:15 -0800 Message-ID: <002001cbabaf$7fa8b360$7efa1a20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acug/d57sTvvOiaIT8mG4r4kombLKwAgoFSgAUlghMABQZ8bcA== Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] base #32 (new): Interference between 2 clients on same host 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, 04 Jan 2011 01:32:10 -0000 > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Tuesday, December 28, 2010 7:45 AM > To: Dan Wing; 'Francis Dupont' > Cc: pcp@ietf.org > Subject: RE: [pcp] base #32 (new): Interference between 2 clients on > same host >=20 >=20 > Hi Dan, >=20 > The source IP address/port used by the PCP Client are not "stored" by > the PCP Server. Agreed. However, it stores the internal IP address and internal port, as those are part of the mapping. That's the 48 bits I was referring=20 to, and is where the application is listening for incoming traffic. =20 > This does not solve the issue encountered when several > PCP Clients are co-located on the same host. This application-ID is > required to avoid a PCP Client deleting the mapping instantiated by > another active PCP Client. 1. is there really a problem where one application removes mappings for another application? Or is this something that the market=20 will resolve? =20 2. if we add this functionality, how does a host freshly connecting to the network delete all previous PCP-created mappings? Afterall, the freshly-connecting host won't know the application IDs used by the previous host that used the same internal IP address. =20 This ability to delete all pinholes is currently a feature of PCP: "A client can request the explicit deletion of all its UDP=20 or TCP mappings by sending a PCP request with a PIN OpCode=20 with external port, internal port, and lifetime set to 0.=20 A client MAY choose to do this when it first acquires a=20 new IP address in order to protect itself from port=20 mappings that were performed by a previous owner of the=20 IP address." We could remove that functionality, I suppose -- afterall, hosts do *not* get this sort of "ingress filtering" functionality today=20 when they are assigned an IP address. -d > Cheers, > Med >=20 > -----Message d'origine----- > De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de > Dan Wing > Envoy=E9 : mercredi 22 d=E9cembre 2010 03:33 > =C0 : 'Francis Dupont' > Cc : pcp@ietf.org > Objet : Re: [pcp] base #32 (new): Interference between 2 clients on > same host >=20 > There is already 48-bit application ID, comprised of the source IP > address > and source port. Is that insufficient? Does that not work? >=20 > -d >=20 >=20 > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf = Of > > Francis Dupont > > Sent: Tuesday, December 21, 2010 2:57 AM > > To: pcp issue tracker > > Cc: pcp@ietf.org > > Subject: Re: [pcp] base #32 (new): Interference between 2 clients on > > same host > > > > A new 'per-application ID' option. > > Points to solve: > > - get a good name (not 'client ID' as client is not a free term) > > - mandatory or not (IMHO it must be mandatory or it will be > unusable) > > - fixed length (32 bits seem enough) / maximum length (yes!) > > > > Regards > > > > Francis.Dupont@fdupont.fr > > > > PS: when I say 'mandatory' it is mandatory to process and > > also mandatory to support (as HONOR_EXTERNAL_PORT), i.e., > > a not-optional option (:-). > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp >=20 > ********************************* > This message and any attachments (the "message") are confidential and > intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, > changed or falsified. > If you are not the intended addressee of this message, please cancel = it > immediately and inform the sender. > ******************************** From dwing@cisco.com Mon Jan 3 17:39: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 468C63A67EE for ; Mon, 3 Jan 2011 17:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.517 X-Spam-Level: X-Spam-Status: No, score=-110.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 WHkB+IO3gSZp for ; Mon, 3 Jan 2011 17:39:07 -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 5792B3A67ED for ; Mon, 3 Jan 2011 17:39:07 -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: Av0EAIQJIk2rR7Ht/2dsb2JhbACXP4x4c6JHmRyFSgSEZQ X-IronPort-AV: E=Sophos;i="4.60,269,1291593600"; d="scan'208";a="309834412" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 04 Jan 2011 01:41:14 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p041fE96027722; Tue, 4 Jan 2011 01:41:14 GMT From: "Dan Wing" To: "'Francis Dupont'" , References: <201012271436.oBREaBD9030072@givry.fdupont.fr> In-Reply-To: <201012271436.oBREaBD9030072@givry.fdupont.fr> Date: Mon, 3 Jan 2011 17:41:14 -0800 Message-ID: <002901cbabb0$7928c560$6b7a5020$@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: Acul028NKmsVGUYBRgOWbBO5cX/rDwF1crpA Content-Language: en-us Subject: Re: [pcp] base-02 feedback 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, 04 Jan 2011 01:39:08 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Francis Dupont > Sent: Monday, December 27, 2010 6:36 AM > To: pcp@ietf.org > Subject: [pcp] base-02 feedback > > I am implementing PCP for DS-Lite, I found some issues: > - we need an error code for too short packets: > * packets smaller than 8 bytes should be simply ignored > * packets smaller than the corresponding OpCode should raise an > 'malformed request' fatal error code. > > - we need a maximal size (I propose 1024 bytes: enough for everything > and in general avoiding fragmentation) and a behavior for too large > requests (simply ignoring them is not enough). > BTW the 'malformed request' error code is usable for this too, > the error response should be truncated to 1024. > IMHO we need a new tracker item for this point. Added text to -02 to say maximum is 1024 octets and minimum is 8 octets. Added new MALFORMED_REQUEST error code. > - HONOR_EXTERNAL_PORT must be a mandatory (code >= 128) option. > I understand the reasons to make it optional (code == 6) but this > means > a positive response could be generated without a successfully > processing. Done. It is now 130. > - what to do when a mandatory option is in a request where it makes > no sense, for instance (mandatory) HONOR_EXTERNAL_PORT in a delete > request? > I propose to use MALFORMED_OPTION or a new fatal error code. I added: If an option with value greater than 128 exists but that option does not make sense (e.g., the HONOR_EXTERNAL_PORT option is included in a request with lifetime=0 (indicating a delete request)), the request is invalid and generates a MALFORMED_OPTION error. but I would like to say something better; that text is not specific enough to cause two implementors to do the same sorts of checks. > - I'd like to extended the AMBIGUOUS error code to cases where a > dynamic > mapping conflicts with a requested pinhole. The difference with > the current meaning is a REMOTE_PEER option won't be enough to solve > it. > BTW the error stays transcient. I added: If a dynamic mapping already exists for the internal IP address and internal port, and the REMOTE_PEER option is not included in the request, it is impossible to establish a pinhole. In such a case, the PCP server responds with the error AMBIGIUOS. The client needs to choose a different internal port and send a new PCP request. > - I strongly disagree with the client port text (6.1.1 page 13): > * there is no reason to require port randomization There are reasons, as discussed in draft-ietf-tsvwg-port-randomization. Do you disagree with draft-ietf-tsvwg-port-randomization, or are you saying PCP is immune from the risks described in draft-ietf-tsvwg-port-randomization? > * to bind for port randomization is a heavy requirement for client > implementations We could water this down to leaving it up to the underlying OS to choose the source port for PCP requests, I suppose. > * the 'single UDP port' wording is bad: we should only recommend > a client uses the same source UDP port to (re)transmit a request > to a server (BTW this means the UDP socket should be connected). The server doesn't care what port the PCP request used, so even retransmissions shouldn't matter. > - same text, minor concerns > * The 'repeat 4 times' wording is ambiguous: does it mean there > should be up to 4 retransmits or up to 4 transmits? Adjusted to: This is repeated 4 times (for a total of 5 transmissions to each server). If, after these transmissions, no PCP server has responded the PCP client SHOULD abort the procedure. > * there is nothing about what to do with transient errors > (try another server, restart the whole procedure after XX (I propose > 60) > seconds, etc) Added this, but not sure if this is entirely what you are asking: Upon receiving a response (success or error), the PCP client does not change to a different PCP server. That is, it does not "shop around" trying to find a PCP server to service its (same) request. -d > Regards > > Francis.Dupont@fdupont.fr > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From Francis.Dupont@fdupont.fr Tue Jan 4 00:45: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 E7BB13A6B53 for ; Tue, 4 Jan 2011 00:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=0.050, 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 C7mG+HHpr9oh for ; Tue, 4 Jan 2011 00:45:26 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id CA81A3A6B56 for ; Tue, 4 Jan 2011 00:45: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 p048lVNG004842; Tue, 4 Jan 2011 08:47:31 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101040847.p048lVNG004842@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Mon, 03 Jan 2011 17:34:15 PST. <002001cbabaf$7fa8b360$7efa1a20$@com> Date: Tue, 04 Jan 2011 09:47:31 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] base #32 (new): Interference between 2 clients on same host 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, 04 Jan 2011 08:45:27 -0000 In your previous mail you wrote: > The source IP address/port used by the PCP Client are not "stored" by > the PCP Server. Agreed. However, it stores the internal IP address and internal port, as => and protocol those are part of the mapping. That's the 48 bits I was referring to, and is where the application is listening for incoming traffic. > This does not solve the issue encountered when several > PCP Clients are co-located on the same host. This application-ID is > required to avoid a PCP Client deleting the mapping instantiated by > another active PCP Client. 1. is there really a problem where one application removes mappings for another application? => it is not a security problem but it is surely an operational one. Or is this something that the market will resolve? => or the market could decide PCP is not applicable... 2. if we add this functionality, how does a host freshly connecting to the network delete all previous PCP-created mappings? => by not using an application ID in its 'delete all' request. This ability to delete all pinholes is currently a feature of PCP: "A client can request the explicit deletion of all its UDP ..." => even if I am not fully satisfied by the term 'client' (it should be 'host', BTW 'client' alone should be avoided or replaced by 'PCP client'), this functionality is fine. We could remove that functionality, I suppose -- afterall, hosts do *not* get this sort of "ingress filtering" functionality today when they are assigned an IP address. => I never proposed to remove this 'delete all', just to add a new level of freedom in 'delete all' and similar operations. Regards Francis.Dupont@fdupont.fr From mohamed.boucadair@orange-ftgroup.com Tue Jan 4 02: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 198E73A6B70 for ; Tue, 4 Jan 2011 02:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 EL10nQIAW30p for ; Tue, 4 Jan 2011 02:02:53 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id F2B763A6B59 for ; Tue, 4 Jan 2011 02:02:52 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id D2EAF3B442A; Tue, 4 Jan 2011 11:04:58 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id BAFE018003E; Tue, 4 Jan 2011 11:04:55 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Tue, 4 Jan 2011 11:04:55 +0100 From: To: Dan Wing , 'Francis Dupont' Date: Tue, 4 Jan 2011 11:04:54 +0100 Thread-Topic: [pcp] base #32 (new): Interference between 2 clients on same host Thread-Index: Acug/d57sTvvOiaIT8mG4r4kombLKwAgoFSgAUlghMABQZ8bcAASG8YA Message-ID: <13941_1294135495_4D22F0C7_13941_2340_1_94C682931C08B048B7A8645303FDC9F33C3E61A5FF@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Tue, 21 Dec 2010 07:02:10 GMT. <074.2ce024e471569bc9fa049a9d88685836@tools.ietf.org> <201012211057.oBLAvMhZ091467@givry.fdupont.fr> <10f201cba180$8bfe8470$a3fb8d50$@com> <3131_1293551120_4D1A0610_3131_20639_1_94C682931C08B048B7A8645303FDC9F33C3E6198E4@PUEXCB1B.nanterre.francetelecom.fr> <002001cbabaf$7fa8b360$7efa1a20$@com> In-Reply-To: <002001cbabaf$7fa8b360$7efa1a20$@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.1.4.84217 Cc: "pcp@ietf.org" Subject: Re: [pcp] base #32 (new): Interference between 2 clients on same host 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, 04 Jan 2011 10:02:54 -0000 Hi Dan, Please see inline. Cheers, Med=20 -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : mardi 4 janvier 2011 02:34 =C0 : BOUCADAIR Mohamed NCPI/NAD/TIP; 'Francis Dupont' Cc : pcp@ietf.org Objet : RE: [pcp] base #32 (new): Interference between 2 clients on same ho= st > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Tuesday, December 28, 2010 7:45 AM > To: Dan Wing; 'Francis Dupont' > Cc: pcp@ietf.org > Subject: RE: [pcp] base #32 (new): Interference between 2 clients on > same host >=20 >=20 > Hi Dan, >=20 > The source IP address/port used by the PCP Client are not "stored" by > the PCP Server. Agreed. However, it stores the internal IP address and internal port, as those are part of the mapping. That's the 48 bits I was referring=20 to, and is where the application is listening for incoming traffic. =20 > This does not solve the issue encountered when several > PCP Clients are co-located on the same host. This application-ID is > required to avoid a PCP Client deleting the mapping instantiated by > another active PCP Client. 1. is there really a problem where one application removes mappings for another application? Or is this something that the market=20 will resolve? Med: There is an issue since service degradation may be experienced due to = such behaviour. An application may think it has opened the pinholes in the = PCP-controlled device but no traffic is received...because this pinhole has= been removed by another PCP Client of the same subscriber.=20 =20=20 2. if we add this functionality, how does a host freshly connecting to the network delete all previous PCP-created mappings? Afterall, the freshly-connecting host won't know the application IDs used by the previous host that used the same internal IP address.=20=20 This ability to delete all pinholes is currently a feature of PCP: "A client can request the explicit deletion of all its UDP=20 or TCP mappings by sending a PCP request with a PIN OpCode=20 with external port, internal port, and lifetime set to 0.=20 A client MAY choose to do this when it first acquires a=20 new IP address in order to protect itself from port=20 mappings that were performed by a previous owner of the=20 IP address." We could remove that functionality, I suppose -- afterall, hosts do *not* get this sort of "ingress filtering" functionality today=20 when they are assigned an IP address. Med: IMHO, we need to understand the scenarios we have on the table and the= n decide on how to mitigate them and to make priorities if there is conflic= t(s). The ability to remove mappings is required for various reasons: avoid= service degradation due to unwanted mappings/stale mappings which consume = the per-subscriber port quota, etc. But, issuing delete all mappings for al= l internal IP addresses should not be recommended. FYI, we are editing an I= -D about PCP failure scenarios. We hope this ID helps to understand some of= the scenarios.=20 ********************************* 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 Tue Jan 4 04:04: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 ADA3A3A6B70 for ; Tue, 4 Jan 2011 04:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=0.049, 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 UKeUQSnCcXV0 for ; Tue, 4 Jan 2011 04:04:26 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 9F7BB3A6A29 for ; Tue, 4 Jan 2011 04:04:26 -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 p04C6XD9017040; Tue, 4 Jan 2011 12:06:33 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101041206.p04C6XD9017040@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Mon, 03 Jan 2011 17:41:14 PST. <002901cbabb0$7928c560$6b7a5020$@com> Date: Tue, 04 Jan 2011 13:06:33 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] base-02 feedback 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, 04 Jan 2011 12:04:27 -0000 In your previous mail you wrote: If a dynamic mapping already exists for the internal IP address and internal port, => add protocol too and the REMOTE_PEER option is not included in > - I strongly disagree with the client port text (6.1.1 page 13): > * there is no reason to require port randomization There are reasons, as discussed in draft-ietf-tsvwg-port-randomization. Do you disagree with draft-ietf-tsvwg-port-randomization, or are you saying PCP is immune from the risks described in draft-ietf-tsvwg-port-randomization? => PCP is either special so we have to define something stronger like a nonce mechanism, or not special so it must be considered as a common application protocol (*). So I still strongly disagree and at least this should be in the security considerations. > * to bind for port randomization is a heavy requirement for client > implementations We could water this down to leaving it up to the underlying OS to choose the source port for PCP requests, I suppose. => yes (BTW draft-ietf-tsvwg-port-randomization doesn't suggest to bind client sockets) > * the 'single UDP port' wording is bad: we should only recommend > a client uses the same source UDP port to (re)transmit a request > to a server (BTW this means the UDP socket should be connected). The server doesn't care what port the PCP request used, so even retransmissions shouldn't matter. => the idea was to be able to use the UDP port for delayed response matching. I don't object to put nothing in the document. > * there is nothing about what to do with transient errors > (try another server, restart the whole procedure after XX (I propose > 60) seconds, etc) Added this, but not sure if this is entirely what you are asking: Upon receiving a response (success or error), the PCP client does not change to a different PCP server. That is, it does not "shop around" trying to find a PCP server to service its (same) request. => I am not convinced it is the right thing on a NETWORK_FAILURE... And of course it doesn't address my concern. Regards Francis.Dupont@fdupont.fr PS: I'll print, read and comment the new version for the end of the week. PPS: (*) in fact both are true according to the context: either any attack is possible between the client and the server: strong (stronger than port randomization) security is required, or no attack is possible, e.g., DS-Lite & co: port randomization doesn't bring something. Note I don't say ephemeral port randomization is bad: it is a good idea but it is orthogonal to PCP security requirements. From mohamed.boucadair@orange-ftgroup.com Tue Jan 4 04:34: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 C2BD53A6BAC for ; Tue, 4 Jan 2011 04:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 ll8AnDj9oagj for ; Tue, 4 Jan 2011 04:34:30 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id C28373A6BB6 for ; Tue, 4 Jan 2011 04:34:29 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 6B97D2AC329; Tue, 4 Jan 2011 13:36:35 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 53B8838403A; Tue, 4 Jan 2011 13:36:35 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Tue, 4 Jan 2011 13:36:35 +0100 From: To: Francis Dupont , Dan Wing Date: Tue, 4 Jan 2011 13:36:34 +0100 Thread-Topic: [pcp] base-02 feedback Thread-Index: AcusB9c8J0z/ZM7PRtGE0GfKdGjqLQAAzn7w Message-ID: <29736_1294144595_4D231453_29736_5604_1_94C682931C08B048B7A8645303FDC9F33C3E9FD418@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Mon, 03 Jan 2011 17:41:14 PST. <002901cbabb0$7928c560$6b7a5020$@com> <201101041206.p04C6XD9017040@givry.fdupont.fr> In-Reply-To: <201101041206.p04C6XD9017040@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.1.4.115415 Cc: "pcp@ietf.org" Subject: Re: [pcp] base-02 feedback 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, 04 Jan 2011 12:34:30 -0000 Hi Francis, Since PCP does not support any security feature to prevent against maliciou= s answers; having randomly generated port number makes the attack harder. P= ersonally, I was advocating for having a random 32 bits (transaction-id) + = 16 random bits (port number). But, it seems there was no consensus about th= is. I suggest to maintain the text about port randomization as it is. Cheers, Med -----Message d'origine----- De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Franc= is Dupont Envoy=E9 : mardi 4 janvier 2011 13:07 =C0 : Dan Wing Cc : pcp@ietf.org Objet : Re: [pcp] base-02 feedback In your previous mail you wrote: If a dynamic mapping already exists for the internal IP address=20 and internal port, =3D> add protocol too and the REMOTE_PEER option is not included in=20 =20=20=20 > - I strongly disagree with the client port text (6.1.1 page 13): > * there is no reason to require port randomization =20=20=20 There are reasons, as discussed in draft-ietf-tsvwg-port-randomization. Do you disagree with draft-ietf-tsvwg-port-randomization, or are you saying PCP is immune from the risks described in draft-ietf-tsvwg-port-randomization? =20=20=20 =3D> PCP is either special so we have to define something stronger like a nonce mechanism, or not special so it must be considered as a common application protocol (*). So I still strongly disagree and at least this should be in the security considerations. ********************************* 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 adurand@juniper.net Tue Jan 4 06:42: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 5EE323A6AD9 for ; Tue, 4 Jan 2011 06:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.53 X-Spam-Level: X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 bhqX4yfZlkU7 for ; Tue, 4 Jan 2011 06:42:25 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 990FD3A6A04 for ; Tue, 4 Jan 2011 06:42:25 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTSMyTAZiLgexvo+sKlkg60MWW1r6rrtI@postini.com; Tue, 04 Jan 2011 06:44:33 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, 4 Jan 2011 06:43:46 -0800 From: Alain Durand To: Dan Wing Date: Tue, 4 Jan 2011 06:43:44 -0800 Thread-Topic: [pcp] base #32 (new): Interference between 2 clients on same host Thread-Index: AcusHaGbi0iVsCrgSLqtxTwpG+v/7Q== Message-ID: <2B8B261D-86F3-4F5F-99A2-1504B2AE4B93@juniper.net> References: Your message of Tue, 21 Dec 2010 07:02:10 GMT. <074.2ce024e471569bc9fa049a9d88685836@tools.ietf.org> <201012211057.oBLAvMhZ091467@givry.fdupont.fr> <10f201cba180$8bfe8470$a3fb8d50$@com> <3131_1293551120_4D1A0610_3131_20639_1_94C682931C08B048B7A8645303FDC9F33C3E6198E4@PUEXCB1B.nanterre.francetelecom.fr> <002001cbabaf$7fa8b360$7efa1a20$@com> In-Reply-To: <002001cbabaf$7fa8b360$7efa1a20$@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] base #32 (new): Interference between 2 clients on same host 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, 04 Jan 2011 14:42:26 -0000 On Jan 3, 2011, at 8:34 PM, Dan Wing wrote: >=20 >> This does not solve the issue encountered when several >> PCP Clients are co-located on the same host. This application-ID is >> required to avoid a PCP Client deleting the mapping instantiated by >> another active PCP Client. >=20 > 1. is there really a problem where one application removes mappings > for another application? Or is this something that the market=20 > will resolve? We already solved this issue. In the interim meeting, we agreed to allow for connect then signal, in practice allowing any app on a host to take over the signaling of another app session. - Alain. From Francis.Dupont@fdupont.fr Tue Jan 4 07: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 562DC3A6CA3 for ; Tue, 4 Jan 2011 07:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=0.049, 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 1f6ZFCh3zppK for ; Tue, 4 Jan 2011 07:42:29 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 433FD3A6C9C for ; Tue, 4 Jan 2011 07:42: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 p04FiZPt030273; Tue, 4 Jan 2011 15:44:35 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101041544.p04FiZPt030273@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange-ftgroup.com In-reply-to: Your message of Tue, 04 Jan 2011 13:36:34 +0100. <29736_1294144595_4D231453_29736_5604_1_94C682931C08B048B7A8645303FDC9F33C3E9FD418@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 04 Jan 2011 16:44:35 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "pcp@ietf.org" Subject: Re: [pcp] base-02 feedback 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, 04 Jan 2011 15:42:30 -0000 In your previous mail you wrote: Since PCP does not support any security feature to prevent against malicious answers; having randomly generated port number makes the attack harder. Personally, I was advocating for having a random 32 bits (transaction-id) + 16 random bits (port number). But, it seems there was no consensus about this. => if we need a nonce 16 bits are far from to be enough and IMHO 32+16 too. And according to security analysis in fact either no security feature other than for common traffic is needed (DS_lite case for instance), or mutual authentication (which includes more than a nonce mechanism) is required, so port randomization is either useless or not enough. I suggest to maintain the text about port randomization as it is. => it makes no sense. I still recommend to avoid to give a false sense of security with this kind of things. And if we want to talk about this it should be in the security considerations which are still empty BTW... Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Tue Jan 4 07:51: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 A27C33A6CB7 for ; Tue, 4 Jan 2011 07:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[AWL=0.048, 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 ubVlyQeEEBoh for ; Tue, 4 Jan 2011 07:51:24 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 96D183A6CB6 for ; Tue, 4 Jan 2011 07:51:23 -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 p04FrTsZ030874; Tue, 4 Jan 2011 15:53:29 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101041553.p04FrTsZ030874@givry.fdupont.fr> From: Francis Dupont To: Alain Durand In-reply-to: Your message of Tue, 04 Jan 2011 06:43:44 PST. <2B8B261D-86F3-4F5F-99A2-1504B2AE4B93@juniper.net> Date: Tue, 04 Jan 2011 16:53:29 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "pcp@ietf.org" Subject: Re: [pcp] base #32 (new): Interference between 2 clients on same host 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, 04 Jan 2011 15:51:25 -0000 In your previous mail you wrote: > 1. is there really a problem where one application removes mappings > for another application? => it is implicitly by accident/not an expected effect. We already solved this issue. In the interim meeting, we agreed to allow for connect then signal, in practice allowing any app on a host to take over the signaling of another app session. => the question is not to allow or not, it is to avoid it when it is not intented. Regards Francis.Dupont@fdupont.fr PS: it would be easier to understand with the pcp-failure document (unfortunatly I have the write lock on it, oops). From dwing@cisco.com Tue Jan 4 08:08: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 C234A3A6CDC for ; Tue, 4 Jan 2011 08:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.518 X-Spam-Level: X-Spam-Status: No, score=-110.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 us8IyevSedUn for ; Tue, 4 Jan 2011 08:08:31 -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 CDEFF3A6CB3 for ; Tue, 4 Jan 2011 08:08: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: AoMGAOrUIk2rR7H+/2dsb2JhbACWHYEljHhzoXiZNoVKBIRo X-IronPort-AV: E=Sophos;i="4.60,273,1291593600"; d="scan'208";a="254105801" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 04 Jan 2011 16:10:37 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p04GAahB005060; Tue, 4 Jan 2011 16:10:36 GMT From: "Dan Wing" To: References: Your message of Mon, 03 Jan 2011 17:34:15 PST. <002001cbabaf$7fa8b360$7efa1a20$@com> <201101040847.p048lVNG004842@givry.fdupont.fr> In-Reply-To: <201101040847.p048lVNG004842@givry.fdupont.fr> Date: Tue, 4 Jan 2011 08:10:36 -0800 Message-ID: <018301cbac29$ec63ef40$c52bcdc0$@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: Acur7Ajklf5iJYijTv6L/MFsPnDOiwAPYSNg Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] base #32 (new): Interference between 2 clients on same host 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, 04 Jan 2011 16:08:31 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Tuesday, January 04, 2011 12:48 AM > To: Dan Wing > Cc: mohamed.boucadair@orange-ftgroup.com; pcp@ietf.org > Subject: Re: [pcp] base #32 (new): Interference between 2 clients on > same host > > > In your previous mail you wrote: > > > The source IP address/port used by the PCP Client are not "stored" > by > > the PCP Server. > > Agreed. > > However, it stores the internal IP address and internal port, as > > => and protocol > > those are part of the mapping. That's the 48 bits I was referring > to, and is where the application is listening for incoming > traffic. > > > This does not solve the issue encountered when several > > PCP Clients are co-located on the same host. This application-ID > is > > required to avoid a PCP Client deleting the mapping instantiated > by > > another active PCP Client. > > 1. is there really a problem where one application removes mappings > for another application? > > => it is not a security problem but it is surely an operational one. > > Or is this something that the market will resolve? > > => or the market could decide PCP is not applicable... I don't understand. UPnP IGD does not have such functionality, neither does NAT-PMP. > 2. if we add this functionality, how does a host freshly connecting > to the network delete all previous PCP-created mappings? > > => by not using an application ID in its 'delete all' request. Yes, that's right. What prevents-or-discourages an application from doing that when it initializes? That is, if we add this functionality, will it help the underlying problem of preventing Application A from stepping on Application B's mappings> -d > This ability to delete all pinholes is currently a feature of > PCP: > > "A client can request the explicit deletion of all its UDP > ..." > > => even if I am not fully satisfied by the term 'client' (it should be > 'host', BTW 'client' alone should be avoided or replaced by 'PCP > client'), > this functionality is fine. > > We could remove that functionality, I suppose -- afterall, hosts > do *not* get this sort of "ingress filtering" functionality today > when they are assigned an IP address. > > => I never proposed to remove this 'delete all', just to add a new > level > of freedom in 'delete all' and similar operations. > > Regards > > Francis.Dupont@fdupont.fr From dwing@cisco.com Tue Jan 4 08:12:10 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 3421E3A6CC8 for ; Tue, 4 Jan 2011 08:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.52 X-Spam-Level: X-Spam-Status: No, score=-110.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 7S0M87r9MSrg for ; Tue, 4 Jan 2011 08:12:09 -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 520D23A6CC0 for ; Tue, 4 Jan 2011 08:12:09 -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: Av0EAJ7VIk2rR7Hu/2dsb2JhbACXQox4c6F6mTaCdoJUBIRo X-IronPort-AV: E=Sophos;i="4.60,273,1291593600"; d="scan'208";a="396025238" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 04 Jan 2011 16:14:07 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p04GE7rG008771; Tue, 4 Jan 2011 16:14:07 GMT From: "Dan Wing" To: , "'Francis Dupont'" References: Your message of Tue, 21 Dec 2010 07:02:10 GMT. <074.2ce024e471569bc9fa049a9d88685836@tools.ietf.org> <201012211057.oBLAvMhZ091467@givry.fdupont.fr> <10f201cba180$8bfe8470$a3fb8d50$@com> <3131_1293551120_4D1A0610_3131_20639_1_94C682931C08B048B7A8645303FDC9F33C3E6198E4@PUEXCB1B.nanterre.francetelecom.fr> <002001cbabaf$7fa8b360$7efa1a20$@com> <13941_1294135495_4D22F0C7_13941_2340_1_94C682931C08B048B7A8645303FDC9F33C3E61A5FF@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <13941_1294135495_4D22F0C7_13941_2340_1_94C682931C08B048B7A8645303FDC9F33C3E61A5FF@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 4 Jan 2011 08:14:07 -0800 Message-ID: <018501cbac2a$69d4f8c0$3d7eea40$@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: Acug/d57sTvvOiaIT8mG4r4kombLKwAgoFSgAUlghMABQZ8bcAASG8YAAA1U24A= Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] base #32 (new): Interference between 2 clients on same host 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, 04 Jan 2011 16:12:10 -0000 ... > Med: IMHO, we need to understand the scenarios we have on the table and > then decide on how to mitigate them and to make priorities if there is > conflict(s). The ability to remove mappings is required for various > reasons: avoid service degradation due to unwanted mappings/stale > mappings which consume the per-subscriber port quota, etc. But, issuing > delete all mappings for all internal IP addresses should not be > recommended. That is exactly my point. Let's say we make that recommendation -- it is a reasonable recommendation afterall. With that recommendation, and with the ability to delete all mappings, I do not see the purpose of an Application ID. Because, if we add an Application ID, a rogue application can still delete all mappings, and if we do not add an Application ID, a rogue application can still behave appropriately and not remove mappings for other applications. > FYI, we are editing an I-D about PCP failure scenarios. We > hope this ID helps to understand some of the scenarios. Ok. -d From dwing@cisco.com Tue Jan 4 08:42: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 3824F3A6BF1 for ; Tue, 4 Jan 2011 08:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.495 X-Spam-Level: X-Spam-Status: No, score=-110.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDPSvic3Qisc for ; Tue, 4 Jan 2011 08:42:41 -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 8AE643A6BC5 for ; Tue, 4 Jan 2011 08:42:41 -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: Av0EAJfdIk2rRN+J/2dsb2JhbACXRIx4c6MwmTqFSgSEaA X-IronPort-AV: E=Sophos;i="4.60,273,1291593600"; d="scan'208";a="310078864" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 04 Jan 2011 16:44:46 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p04GikxY004264; Tue, 4 Jan 2011 16:44:46 GMT From: "Dan Wing" To: "'Alain Durand'" References: Your message of Tue, 21 Dec 2010 07:02:10 GMT. <074.2ce024e471569bc9fa049a9d88685836@tools.ietf.org> <201012211057.oBLAvMhZ091467@givry.fdupont.fr> <10f201cba180$8bfe8470$a3fb8d50$@com> <3131_1293551120_4D1A0610_3131_20639_1_94C682931C08B048B7A8645303FDC9F33C3E6198E4@PUEXCB1B.nanterre.francetelecom.fr> <002001cbabaf$7fa8b360$7efa1a20$@com> <2B8B261D-86F3-4F5F-99A2-1504B2AE4B93@juniper.net> In-Reply-To: <2B8B261D-86F3-4F5F-99A2-1504B2AE4B93@juniper.net> Date: Tue, 4 Jan 2011 08:44:46 -0800 Message-ID: <01c301cbac2e$b1eb6be0$15c243a0$@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: AcusHaGbi0iVsCrgSLqtxTwpG+v/7QAEHnlQ Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] base #32 (new): Interference between 2 clients on same host 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, 04 Jan 2011 16:42:42 -0000 > -----Original Message----- > From: Alain Durand [mailto:adurand@juniper.net] > Sent: Tuesday, January 04, 2011 6:44 AM > To: Dan Wing > Cc: mohamed.boucadair@orange-ftgroup.com; Francis Dupont; pcp@ietf.org > Subject: Re: [pcp] base #32 (new): Interference between 2 clients on > same host > > > On Jan 3, 2011, at 8:34 PM, Dan Wing wrote: > > > >> This does not solve the issue encountered when several > >> PCP Clients are co-located on the same host. This application-ID is > >> required to avoid a PCP Client deleting the mapping instantiated by > >> another active PCP Client. > > > > 1. is there really a problem where one application removes mappings > > for another application? Or is this something that the market > > will resolve? > > > We already solved this issue. In the interim meeting, we agreed to > allow > for connect then signal, in practice allowing any app on a host to take > over the signaling of another app session. Great, thanks. I marked issue #32 as 'wontfix', which closes it. http://trac.tools.ietf.org/wg/pcp/trac/ticket/32 -d From dwing@cisco.com Tue Jan 4 08:47: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 0D2DB3A68D5 for ; Tue, 4 Jan 2011 08:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.521 X-Spam-Level: X-Spam-Status: No, score=-110.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 zt3Hln6dNjyu for ; Tue, 4 Jan 2011 08:47:27 -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 23E383A681C for ; Tue, 4 Jan 2011 08:47:27 -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: AoMGAA/eIk2rR7Hu/2dsb2JhbACWH4EljHhzoz+ZOoVKBIRo X-IronPort-AV: E=Sophos;i="4.60,273,1291593600"; d="scan'208";a="300935875" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 04 Jan 2011 16:49:34 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p04GnY4v011583 for ; Tue, 4 Jan 2011 16:49:34 GMT From: "Dan Wing" To: Date: Tue, 4 Jan 2011 08:49:33 -0800 Message-ID: <01c401cbac2f$5d810cd0$18832670$@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: AcusL11HUv2V/I6iRIWHxoP/H9k/NA== Content-Language: en-us Subject: [pcp] multiplexing DTLS and non-DTLS on same port 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, 04 Jan 2011 16:47:28 -0000 I had emailed IANA to get a port assigned for PCP. A comment back from IANA is that we allow PCP to use the same port for secure and unsecured versions -- should we need to do so. (I am not yet convinced we need DTLS for PCP, but let's leave that discussion aside for a moment. Let's assume we do want DTLS for PCP for this email thread.) Thus, I looked at how we might multiplex both DTLS and non-DTLS PCP on the same port. Another protocol, DTLS-SRTP, multiplexes DTLS and SRTP on the same port. They did it this way (from RFC5764): # # The process for demultiplexing a packet is as follows. The receiver # looks at the first byte of the packet. If the value of this byte is # 0 or 1, then the packet is STUN. If the value is in between 128 and # 191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and # RTP are being multiplexed over the same destination port). If the # value is between 20 and 63 (inclusive), the packet is DTLS. This # process is summarized in Figure 3. # # +----------------+ # | 127 < B < 192 -+--> forward to RTP # | | # packet --> | 19 < B < 64 -+--> forward to DTLS # | | # | B < 2 -+--> forward to STUN # +----------------+ # PCP could do something similar. An easy way to achieve it is to force a "1" in the first bit of the common header, so it would change from OLD: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver=0 |reserve|R| OpCode | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NEW: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|Ver=0|reserve|R| OpCode | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ......^ and anything with the first bit set is processed as plain PCP, and anything with the first bit clear is processed as DTLS. This leaves us with 3 bits for version number, which seems plenty. Thoughts? -d From Internet-Drafts@ietf.org Tue Jan 4 09:00: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 14B4F3A6CE3; Tue, 4 Jan 2011 09:00:03 -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.060, 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 NSi-ajIxhXoK; Tue, 4 Jan 2011 09:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E921E3A681C; Tue, 4 Jan 2011 09:00: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.10 Message-ID: <20110104170001.12337.78844.idtracker@localhost> Date: Tue, 04 Jan 2011 09:00:01 -0800 Cc: pcp@ietf.org Subject: [pcp] I-D Action:draft-ietf-pcp-base-02.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, 04 Jan 2011 17:00:03 -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 Filename : draft-ietf-pcp-base-02.txt Pages : 43 Date : 2011-01-04 Port Control Protocol is an address-family independent mechanism to control how incoming packets are forwarded by upstream devices such as network address translators (NATs) and simple IPv6 firewalls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-04084757.I-D@ietf.org> --NextPart-- From Francis.Dupont@fdupont.fr Tue Jan 4 09:03: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 222713A6CD9 for ; Tue, 4 Jan 2011 09:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[AWL=0.048, 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 ZIEr-A2U02k2 for ; Tue, 4 Jan 2011 09:03:38 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 1CFE83A6C75 for ; Tue, 4 Jan 2011 09:03: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 p04H5iuh035425; Tue, 4 Jan 2011 17:05:44 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101041705.p04H5iuh035425@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Mon, 03 Jan 2011 17:41:14 PST. <002901cbabb0$7928c560$6b7a5020$@com> Date: Tue, 04 Jan 2011 18:05:44 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] base-02 feedback 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, 04 Jan 2011 17:03:39 -0000 In your previous mail you wrote: Added text to -02 to say maximum is 1024 octets and minimum is 8 octets. Added new MALFORMED_REQUEST error code. => I am not satisfied with the new text which is IMHO not enough accurate. I propose: - drop (ignoring or log an error) request and response shorter than 8 octets (the idea is one can't do anything with them) - return MALFORMED_REQUEST 1024 octets response on a request longer than 1024 octets - drop (ignoring or log an error) response longer than 1024 octets Now we have to specify when the second check is done, I propose: -1 check length < 8 -2 check version -3 check response bit in opcode -4 check supported opcode -5 check length > 1024 In 2, 4 and 5 the error response length must be <= 1024 The idea is to get useful errors about bad headers if possible. I have another point: what to do with message length not a multiple of 4? Thanks Francis.Dupont@fdupont.fr From dwing@cisco.com Tue Jan 4 09:08: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 37C3C3A6CEB for ; Tue, 4 Jan 2011 09:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.522 X-Spam-Level: X-Spam-Status: No, score=-110.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 cClYIIrRh+Qr for ; Tue, 4 Jan 2011 09:08:28 -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 E70183A6CE5 for ; Tue, 4 Jan 2011 09:08:28 -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: AoMGAHPjIk2rR7H+/2dsb2JhbACWH4EljHhzo0aZBIVKBIRo X-IronPort-AV: E=Sophos;i="4.60,273,1291593600"; d="scan'208";a="310097340" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 04 Jan 2011 17:10:35 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p04HAYg7002479 for ; Tue, 4 Jan 2011 17:10:35 GMT From: "Dan Wing" To: Date: Tue, 4 Jan 2011 09:10:34 -0800 Message-ID: <01fe01cbac32$4cf3cee0$e6db6ca0$@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: AcusMkycEBscV5A+S0a5tTIWxWRBdw== Content-Language: en-us Subject: [pcp] PCP Issue #1, Epoch 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, 04 Jan 2011 17:08:30 -0000 http://trac.tools.ietf.org/wg/pcp/trac/ticket/1 says: > PCP design for both servers that flushes context on reboot vs > servers that maintain state across reboot > -Ie, with or without stable storage > -Usually (not always) CPE vs CGN > * Epoch mechanism is useful in the flush case, not for > stable storage case > * Proposed resolution: > -Keep Epoch I believe we have consensus to keep the Epoch. > -Maybe as a server-side IE? On the last point, "maybe as server-side IE?", there are two ways I see to encode the Epoch: 1. as currently described in draft-ietf-pcp-base-02, which is that every PCP response contains the Epoch. This means *every* OpCode, including new Opcodes we might define in the future, would include the Epoch. The layout is currently this (see **): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver=1 |reserve|R| Opcode | Reserved | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ** | Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : (optional) OpCode-specific response data : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : (optional) Informational Elements : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2. remove the Epoch from the common PCP header, and move it to be part of the PIN44, PIN64, PIN46, and PIN66 OpCodes, like this (see **): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ** | Epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Pinhole Internal IP address (32 or 128, depending on OpCode) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Requested external IP address (32 or 128, depending on OpCode): : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | internal port | requested external port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The advantage of moving the Epoch into the PIN* OpCodes is we free up 4 bytes of space for future OpCodes that might not care about the Epoch. If they do care about the Epoch, those future OpCodes can define the Epoch as part of their packet format. If I don't hear objections, I will be doing (2) in -03. -d From dwing@cisco.com Tue Jan 4 09:14: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 DD5D03A6C0B for ; Tue, 4 Jan 2011 09:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 khjQ145rKNhh for ; Tue, 4 Jan 2011 09:14:46 -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 26D143A6BE0 for ; Tue, 4 Jan 2011 09:14:46 -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: AoMGAJ/kIk2rR7Hu/2dsb2JhbACWH4EljHhzo06ZBIJ2glQEhGg X-IronPort-AV: E=Sophos;i="4.60,273,1291593600"; d="scan'208";a="310103494" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 04 Jan 2011 17:16:53 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p04HGrDv007538 for ; Tue, 4 Jan 2011 17:16:53 GMT From: "Dan Wing" To: Date: Tue, 4 Jan 2011 09:16:52 -0800 Message-ID: <020e01cbac33$2e5764a0$8b062de0$@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: AcusMy4ZXZT4ZVSwS26YOCmcJ8wcXA== Content-Language: en-us Subject: [pcp] pcp-base-02 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, 04 Jan 2011 17:14:47 -0000 I just submitted draft-ietf-pcp-base-02, with the following changes: A.1. Changes from draft-ietf-pcp-base-01 to -02 o more error codes o PCP client source port number should be random o PCP message minimum 8 octets, maximum 1024 octets. o tweaked a lot of text in section 7.4, "Opcode-Specific Server Operation". o opening a pinhole also allows ICMP messages associated with that pinhole. o HONOR_EXTERNAL_PORT value changed to the mandatory-to-process range. o added text recommending applications that are crashing obtain short lifetimes, to avoid consuming subscriber's port quota. -d From Francis.Dupont@fdupont.fr Tue Jan 4 10:16: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 EF55B3A6A32 for ; Tue, 4 Jan 2011 10:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[AWL=0.047, 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 TyetV728FPiz for ; Tue, 4 Jan 2011 10:16:49 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id E79353A699F for ; Tue, 4 Jan 2011 10:16:48 -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 p04IItYq039894; Tue, 4 Jan 2011 18:18:55 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101041818.p04IItYq039894@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Tue, 04 Jan 2011 08:10:36 PST. <018301cbac29$ec63ef40$c52bcdc0$@com> Date: Tue, 04 Jan 2011 19:18:55 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] base #32 (new): Interference between 2 clients on same host 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, 04 Jan 2011 18:16:50 -0000 In your previous mail you wrote: > => or the market could decide PCP is not applicable... I don't understand. UPnP IGD does not have such functionality, neither does NAT-PMP. => it is true for NAT-PMP but not for UPnP IGD: it is one of the use of the PortMappingDescription. What prevents-or-discourages an application from doing that when it initializes? That is, if we add this functionality, will it help the underlying problem of preventing Application A from stepping on Application B's mappings> => as I explained before: if we provide this functionality it should be required for applications which may run not alone on a host, i.e., either there is a PCP agent on the host and applications work with it, or each application runs its own PCP client and must use an application ID (if possible easy to recognize by other instances of the same application). BTW even a central per-host PCP agent has an use of application IDs, or IWFs. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Tue Jan 4 10:23: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 250CD3A699F for ; Tue, 4 Jan 2011 10:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[AWL=0.047, 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 iuxbBwcPj5P4 for ; Tue, 4 Jan 2011 10:23:25 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id B3EC73A6A32 for ; Tue, 4 Jan 2011 10:23:23 -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 p04IPQYh040342; Tue, 4 Jan 2011 18:25:26 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101041825.p04IPQYh040342@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Tue, 04 Jan 2011 08:14:07 PST. <018501cbac2a$69d4f8c0$3d7eea40$@com> Date: Tue, 04 Jan 2011 19:25:26 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] base #32 (new): Interference between 2 clients on same host 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, 04 Jan 2011 18:23:28 -0000 In your previous mail you wrote: That is exactly my point. Let's say we make that recommendation -- it is a reasonable recommendation afterall. With that recommendation, and with the ability to delete all mappings, I do not see the purpose of an Application ID. Because, if we add an Application ID, a rogue application can still delete all mappings, and if we do not add an Application ID, a rogue application can still behave appropriately and not remove mappings for other applications. => you are talking about security: the application ID is not a security feature (there is simply no PCP specific security between applications) but an operational one. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Tue Jan 4 10:28: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 AB66D3A6B75 for ; Tue, 4 Jan 2011 10:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[AWL=0.047, 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 Or-owrp4CO82 for ; Tue, 4 Jan 2011 10:28:18 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 793AA3A6A32 for ; Tue, 4 Jan 2011 10:28:17 -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 p04IUOdP040666; Tue, 4 Jan 2011 18:30:24 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101041830.p04IUOdP040666@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Tue, 04 Jan 2011 08:44:46 PST. <01c301cbac2e$b1eb6be0$15c243a0$@com> Date: Tue, 04 Jan 2011 19:30:24 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] base #32 (new): Interference between 2 clients on same host 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, 04 Jan 2011 18:28:20 -0000 In your previous mail you wrote: Great, thanks. I marked issue #32 as 'wontfix', which closes it. => so now we have the choice between unclose it or to create a similar one with a verb less ambiguous than 'prevent'. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Tue Jan 4 10:35:10 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 BBDD53A6BDB for ; Tue, 4 Jan 2011 10:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[AWL=0.046, 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 mvsI90bbIJZQ for ; Tue, 4 Jan 2011 10:35:08 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id E3ACA3A6A32 for ; Tue, 4 Jan 2011 10:35:07 -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 p04IbEAb041095; Tue, 4 Jan 2011 18:37:14 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101041837.p04IbEAb041095@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Tue, 04 Jan 2011 08:49:33 PST. <01c401cbac2f$5d810cd0$18832670$@com> Date: Tue, 04 Jan 2011 19:37:14 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] multiplexing DTLS and non-DTLS on same port 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, 04 Jan 2011 18:35:10 -0000 In your previous mail you wrote: Another protocol, DTLS-SRTP, multiplexes DTLS and SRTP on the same port. => in fact I have a related question: do we need to support DTLS and non-DTLS multiplexing? It seems if DTLS is required then non-DTLS should be refused, and vice versa. So IMHO we should wait. As you explained we even don't know if DTLS could be used to protect PCP. Regards Francis.Dupont@fdupont.fr From dwing@cisco.com Tue Jan 4 11:09: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 BE7073A6BA7 for ; Tue, 4 Jan 2011 11:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.5 X-Spam-Level: X-Spam-Status: No, score=-110.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upOB996gGs-z for ; Tue, 4 Jan 2011 11:09:02 -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 EB5B63A6A74 for ; Tue, 4 Jan 2011 11:09:02 -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: AoMGAM//Ik2rRN+J/2dsb2JhbACWI4EljHhzo0+YcIVKBIRo X-IronPort-AV: E=Sophos;i="4.60,273,1291593600"; d="scan'208";a="396094480" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 04 Jan 2011 19:11:10 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p04JB9B6017835; Tue, 4 Jan 2011 19:11:10 GMT From: "Dan Wing" To: References: Your message of Tue, 04 Jan 2011 08:10:36 PST. <018301cbac29$ec63ef40$c52bcdc0$@com> <201101041818.p04IItYq039894@givry.fdupont.fr> In-Reply-To: <201101041818.p04IItYq039894@givry.fdupont.fr> Date: Tue, 4 Jan 2011 11:11:09 -0800 Message-ID: <02ee01cbac43$252e78e0$6f8b6aa0$@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: AcusO/j0EXFjon+5QGGZR1vTRmOgzwABRMKA Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] base #32 (new): Interference between 2 clients on same host 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, 04 Jan 2011 19:09:03 -0000 > In your previous mail you wrote: > > > => or the market could decide PCP is not applicable... > > I don't understand. UPnP IGD does not have such functionality, > neither does NAT-PMP. > > => it is true for NAT-PMP but not for UPnP IGD: it is one of the use > of the PortMappingDescription. UPnP IGD 1.0, it says: 2.2.20. PortMappingDescription This is a string representation of a port mapping and is applicable for static and dynamic port mappings. The format of the description string is not specified and is application dependent. If specified, the description string can be displayed to a user via the UI of a control point, enabling easier management of port mappings. The description string for a port mapping (or a set of related port mappings) may or may not be unique across multiple instantiations of an application on multiple nodes in the residential LAN. it doesn't say UPnP IGD control points have to use this information to restrict which ports they delete. I agree they _could_ use the information that way. > What prevents-or-discourages an application from doing that when it > initializes? That is, if we add this functionality, will it help > the underlying problem of preventing Application A from stepping > on Application B's mappings> > > => as I explained before: if we provide this functionality it should > be required for applications which may run not alone on a host, i.e., > either there is a PCP agent on the host and applications work with it, > or each application runs its own PCP client and must use an application > ID > (if possible easy to recognize by other instances of the same > application). > > BTW even a central per-host PCP agent has an use of application IDs, or > IWFs. I propose this be deferred to a separate document, and done as an Option. The Option can work like this: include the Option and its value (e.g., "for the webcam") in the request and, if the PCP server understands it and likes it, the server will positively acknowledge its understanding of that Option in the response. A later attempt to delete the mapping (lifetime=0) will require the Option and same Option value to be included in the request. Would that work? -d From simon.perreault@viagenie.ca Tue Jan 4 11:11: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 C5AB33A6BA7 for ; Tue, 4 Jan 2011 11:11:55 -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 83gWQg0Ph1wP for ; Tue, 4 Jan 2011 11:11:55 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id D9E9B3A6A9B for ; Tue, 4 Jan 2011 11:11:54 -0800 (PST) Received: from balaise.nomis80.org (unknown [IPv6:2001:470:1f11:783:fd92:8207:dbf7:3b2b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 56FDD21158 for ; Tue, 4 Jan 2011 14:14:01 -0500 (EST) Message-ID: <4D237178.4060209@viagenie.ca> Date: Tue, 04 Jan 2011 14:14: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: pcp@ietf.org References: <01c401cbac2f$5d810cd0$18832670$@com> In-Reply-To: <01c401cbac2f$5d810cd0$18832670$@com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pcp] multiplexing DTLS and non-DTLS on same port 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, 04 Jan 2011 19:11:55 -0000 On 01/04/2011 11:49 AM, Dan Wing wrote: > OLD: > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ver=0 |reserve|R| OpCode | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > NEW: > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|Ver=0|reserve|R| OpCode | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ......^ > > and anything with the first bit set is processed as plain PCP, and > anything with the first bit clear is processed as DTLS. This is simple and has been proven to work well in the context of RTP. It will future-proof PCP without any disadvantage. +1 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 Tue Jan 4 11:13: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 410643A6BA7 for ; Tue, 4 Jan 2011 11:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.504 X-Spam-Level: X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srpdOTq0IoIZ for ; Tue, 4 Jan 2011 11:13:36 -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 858883A6A9B for ; Tue, 4 Jan 2011 11:13:36 -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: AoMGAL4AI02rRN+J/2dsb2JhbACWI4EljHhzozuYcIVKBIRo X-IronPort-AV: E=Sophos;i="4.60,273,1291593600"; d="scan'208";a="645182497" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 04 Jan 2011 19:15:43 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p04JFhCv019932; Tue, 4 Jan 2011 19:15:43 GMT From: "Dan Wing" To: References: Your message of Tue, 04 Jan 2011 08:49:33 PST. <01c401cbac2f$5d810cd0$18832670$@com> <201101041837.p04IbEAb041095@givry.fdupont.fr> In-Reply-To: <201101041837.p04IbEAb041095@givry.fdupont.fr> Date: Tue, 4 Jan 2011 11:15:42 -0800 Message-ID: <02f001cbac43$c84013e0$58c03ba0$@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: AcusPnAqDF7aIriDQaq+t4BKpS4SfwABOPkA Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] multiplexing DTLS and non-DTLS on same port 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, 04 Jan 2011 19:13:37 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Tuesday, January 04, 2011 10:37 AM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] multiplexing DTLS and non-DTLS on same port > > > In your previous mail you wrote: > > Another protocol, DTLS-SRTP, multiplexes DTLS and SRTP on the same > port. > > => in fact I have a related question: do we need to support > DTLS and non-DTLS multiplexing? The question, from IANA, is (in a shortened form): if you do add channel security to your protocol, can you do it without consuming an additional port? > It seems if DTLS is required then > non-DTLS should be refused, and vice versa. Yep. But how would we refuse non-DTLS, if not with the ability to multiplex DTLS and non-DTLS on the same port and return a PCP error message? > So IMHO we should wait. Wait on what? Wait to ask IANA for a port? -d > As you explained we even don't know if DTLS > could be used to protect PCP. > > Regards > > Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Tue Jan 4 14:44: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 4B3C43A6A1A for ; Tue, 4 Jan 2011 14:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[AWL=0.046, 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 QfrnvTKOED-n for ; Tue, 4 Jan 2011 14:44:35 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id A4BC63A6A15 for ; Tue, 4 Jan 2011 14:44: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 p04MkdE3056322; Tue, 4 Jan 2011 22:46:39 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101042246.p04MkdE3056322@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Tue, 04 Jan 2011 11:11:09 PST. <02ee01cbac43$252e78e0$6f8b6aa0$@com> Date: Tue, 04 Jan 2011 23:46:39 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] base #32 (new): Interference between 2 clients on same host 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, 04 Jan 2011 22:44:36 -0000 In your previous mail you wrote: it doesn't say UPnP IGD control points have to use this information to restrict which ports they delete. => I didn't say that too: I meant they can. I agree they _could_ use the information that way. => a control point operated by a human will use the information that way (my main issue with port forwarding entries is I never remember some months later what they were for when it is not very obvious. Unfortunately the CPE I use doesn't provide a description field in its interface...) I propose this be deferred to a separate document, and done as an Option. => of course this should be an option! The Option can work like this: include the Option and its value (e.g., "for the webcam") in the request and, if the PCP server understands it and likes it, the server will positively acknowledge its understanding of that Option in the response. => fine A later attempt to delete the mapping (lifetime=0) will require the Option and same Option value to be included in the request. => the constraint on the delete is a bit too high and won't work with a delete all. My idea is a delete with the Option will require the same Option value to be included in the request. BTW this means the wildcard for the Option is to not include the Option. (Remember the addressed issue is operational, not a security one). Thanks Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Tue Jan 4 15: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 C9DE73A6A26 for ; Tue, 4 Jan 2011 15:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.204 X-Spam-Level: X-Spam-Status: No, score=-3.204 tagged_above=-999 required=5 tests=[AWL=0.045, 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 ck5jCBdl+CIy for ; Tue, 4 Jan 2011 15:02:00 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 65A4F3A6A15 for ; Tue, 4 Jan 2011 15:02: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 p04N47bx057514; Tue, 4 Jan 2011 23:04:07 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101042304.p04N47bx057514@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Tue, 04 Jan 2011 11:15:42 PST. <02f001cbac43$c84013e0$58c03ba0$@com> Date: Wed, 05 Jan 2011 00:04:07 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] multiplexing DTLS and non-DTLS on same port 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, 04 Jan 2011 23:02:02 -0000 In your previous mail you wrote: > Another protocol, DTLS-SRTP, multiplexes DTLS and SRTP on the same > port. => BTW SRTP is the only standardized protocol doing this (others reuse the TLS port as they can run over TCP too). > So IMHO we should wait. Wait on what? Wait to ask IANA for a port? => wait on a decision about DTLS use. I can't see a reason to rush to support something we could use. Now the change has no other impact... Regards Francis.Dupont@fdupont.fr PS: If we change the first bytes we can take advantage of this to enlarge the opcode field now too. From dwing@cisco.com Tue Jan 4 16:38: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 A9CEA3A6DD4 for ; Tue, 4 Jan 2011 16:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.525 X-Spam-Level: X-Spam-Status: No, score=-110.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 vtrsIUeXF3BV for ; Tue, 4 Jan 2011 16:38:41 -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 C2C7A3A6DAC for ; Tue, 4 Jan 2011 16:38:41 -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: Al0HAGVNI02rR7Ht/2dsb2JhbACWEIEljHhzpAKYbYVKBIRo X-IronPort-AV: E=Sophos;i="4.60,274,1291593600"; d="scan'208";a="301008829" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 05 Jan 2011 00:40:48 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p050em11025829; Wed, 5 Jan 2011 00:40:48 GMT From: "Dan Wing" To: References: Your message of Tue, 04 Jan 2011 11:11:09 PST. <02ee01cbac43$252e78e0$6f8b6aa0$@com> <201101042246.p04MkdE3056322@givry.fdupont.fr> In-Reply-To: <201101042246.p04MkdE3056322@givry.fdupont.fr> Date: Tue, 4 Jan 2011 16:40:48 -0800 Message-ID: <049c01cbac71$3231fd90$9695f8b0$@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: AcusYU8nY60tQ/kfRZ2GtrmCcoIlVAADmwpQ Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] base #32 (new): Interference between 2 clients on same host 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, 05 Jan 2011 00:38:42 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Tuesday, January 04, 2011 2:47 PM > To: Dan Wing > Cc: mohamed.boucadair@orange-ftgroup.com; pcp@ietf.org > Subject: Re: [pcp] base #32 (new): Interference between 2 clients on > same host > > > In your previous mail you wrote: > > it doesn't say UPnP IGD control points have to use this information > to > restrict which ports they delete. > > => I didn't say that too: I meant they can. Agreed that an application could obtain the list of UPnP IGD mappings and then only delete those with a PortMappingDescription that matches what the application (might have) previously created. > I agree they _could_ use the information that way. > > => a control point operated by a human will use the information that > way > (my main issue with port forwarding entries is I never remember some > months later what they were for when it is not very obvious. > Unfortunately the CPE I use doesn't provide a description field in > its interface...) With PCP, something -- somewhere -- is refreshing the port forwarding entries. They don't last forever. That same thing that refreshes the PCP entries could maintain the text hint for a user. (Or, in the case of the CPE you're using at the moment, it probably wouldn't do that). > I propose this be deferred to a separate document, and done as an > Option. > > => of course this should be an option! > > The Option can work like this: include the Option and > its value (e.g., "for the webcam") in the request and, if the PCP > server understands it and likes it, the server will positively > acknowledge its understanding of that Option in the response. > > => fine > > A later attempt to delete the mapping (lifetime=0) will require the > Option and same Option value to be included in the request. > > => the constraint on the delete is a bit too high and won't work > with a delete all. My idea is a delete with the Option will require > the same Option value to be included in the request. > BTW this means the wildcard for the Option is to not include > the Option. I added what you wrote in the paragraph above to http://trac.tools.ietf.org/wg/pcp/trac/ticket/32 and set it to "open, enhancement" so it can be retrieved later easily. -d > (Remember the addressed issue is operational, not a > security one). > > Thanks > > Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Wed Jan 5 05:58: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 C3E013A6C18 for ; Wed, 5 Jan 2011 05:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.204 X-Spam-Level: X-Spam-Status: No, score=-3.204 tagged_above=-999 required=5 tests=[AWL=0.045, 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 FeDqS6bmYU+4 for ; Wed, 5 Jan 2011 05:58:00 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id AB5643A6C05 for ; Wed, 5 Jan 2011 05:57: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 p05E05vJ011814; Wed, 5 Jan 2011 14:00:05 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101051400.p05E05vJ011814@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Tue, 04 Jan 2011 09:10:34 PST. <01fe01cbac32$4cf3cee0$e6db6ca0$@com> Date: Wed, 05 Jan 2011 15:00:05 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] PCP Issue #1, Epoch 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, 05 Jan 2011 13:58:00 -0000 In your previous mail you wrote: > -Maybe as a server-side IE? On the last point, "maybe as server-side IE?", there are two ways I see to encode the Epoch: => as none of the two ways is about an option (aka IE) I can't see how this is related to the question (:-). 1. as currently described in draft-ietf-pcp-base-02, which is that every PCP response contains the Epoch. This means *every* OpCode, including new Opcodes we might define in the future, would include the Epoch. => if we keep the Epoch with its current meaning it should be in the common header (i.e., 1). I can't see an advantage to put it in each opcode. (nor I can see an advantage in any gratuitous change) The advantage of moving the Epoch into the PIN* OpCodes is we free up 4 bytes of space for future OpCodes that might not care about the Epoch. => 'might not care about the Epoch' is against the design of the Epoch. If I don't hear objections, I will be doing (2) in -03. => I object. Regards Francis.Dupont@fdupont.fr PS: I have a concern about the term Epoch: it means both the Epoch itself and the seconds since start of the Epoch (SSSOE), i.e., the same word is used for absolute and relative views, leading to confusion and/or ambiguity. From Francis.Dupont@fdupont.fr Wed Jan 5 06:10: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 BEB833A6C18 for ; Wed, 5 Jan 2011 06:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.204 X-Spam-Level: X-Spam-Status: No, score=-3.204 tagged_above=-999 required=5 tests=[AWL=0.045, 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 H8-tPkFcQanU for ; Wed, 5 Jan 2011 06:10:54 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 79E383A6C24 for ; Wed, 5 Jan 2011 06:10: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 p05ED0ak012716; Wed, 5 Jan 2011 14:13:00 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101051413.p05ED0ak012716@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Tue, 04 Jan 2011 16:40:48 PST. <049c01cbac71$3231fd90$9695f8b0$@com> Date: Wed, 05 Jan 2011 15:13:00 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] base #32 (new): Interference between 2 clients on same host 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, 05 Jan 2011 14:10:57 -0000 In your previous mail you wrote: With PCP, something -- somewhere -- is refreshing the port forwarding entries. They don't last forever. That same thing that refreshes the PCP entries could maintain the text hint for a user. => this implies the PCP client stores its state in stable storage so I have a real concern about how to implement this on a B4 IWF for instance. (Or, in the case of the CPE you're using at the moment, it probably wouldn't do that). => my CPE has no stable storage: this is why config changes are applied on after a reboot which includes a download on the new config. Another proof that the point about stable storage is really critical. Thanks Francis.Dupont@fdupont.fr From dwing@cisco.com Wed Jan 5 11:00: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 C56DD3A6CEC for ; Wed, 5 Jan 2011 11:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.526 X-Spam-Level: X-Spam-Status: No, score=-110.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 A7v3wvh5e7kU for ; Wed, 5 Jan 2011 11:00:36 -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 7DF4C3A6CDB for ; Wed, 5 Jan 2011 11:00:36 -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: AqAFAAFPJE2rR7H+/2dsb2JhbACWDIEljG9zpm+YKIVMBIRo X-IronPort-AV: E=Sophos;i="4.60,278,1291593600"; d="scan'208";a="396452334" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 05 Jan 2011 19:02:43 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p05J2h1A021740; Wed, 5 Jan 2011 19:02:43 GMT From: "Dan Wing" To: References: Your message of Tue, 04 Jan 2011 16:40:48 PST. <049c01cbac71$3231fd90$9695f8b0$@com> <201101051413.p05ED0ak012716@givry.fdupont.fr> In-Reply-To: <201101051413.p05ED0ak012716@givry.fdupont.fr> Date: Wed, 5 Jan 2011 11:02:44 -0800 Message-ID: <07d001cbad0b$2276af00$67640d00$@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: Acus4s4RUZ7G2wK0Q5O8RYhaxehGpwAJteGw Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] base #32 (new): Interference between 2 clients on same host 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, 05 Jan 2011 19:00:37 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Wednesday, January 05, 2011 6:13 AM > To: Dan Wing > Cc: mohamed.boucadair@orange-ftgroup.com; pcp@ietf.org > Subject: Re: [pcp] base #32 (new): Interference between 2 clients on > same host > > > In your previous mail you wrote: > > With PCP, something -- somewhere -- is refreshing the port > forwarding entries. They don't last forever. That same thing > that refreshes the PCP entries could maintain the text hint for > a user. > > => this implies the PCP client stores its state in stable storage > so I have a real concern about how to implement this on a B4 IWF > for instance. If I understand correctly, your concern is a UPnP IGD -> PCP interworking device. Today, when a UPnP IGD device is told to map a port, it is allowed to forget a port mapping upon reboot: http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf says: Note that static port mappings do not necessarily mean persistence of these mappings across device resets or reboots. It is up to a gateway vendor to implement persistence as appropriate for their IGD device. http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf says: NOTE: Port mappings are NOT REQUIRED to be persistent across device resets or reboots. It is up to the control points to recreate their port mappings when needed. I don't believe a UPnP IGD -> PCP interworking device has to meet a stricter requirement. > (Or, in the case of the CPE you're using at the moment, it probably > wouldn't do that). > > => my CPE has no stable storage: this is why config changes are applied > on after a reboot which includes a download on the new config. > Another proof that the point about stable storage is really critical. Yes. I know that a lot of low-end CPE are like that because of the limited write cycles of the non-volatile memory they use. I don't see a problem with PCP, though. -d From Francis.Dupont@fdupont.fr Wed Jan 5 14:12: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 E3A9A3A6D02 for ; Wed, 5 Jan 2011 14:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.205 X-Spam-Level: X-Spam-Status: No, score=-3.205 tagged_above=-999 required=5 tests=[AWL=0.044, 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 xC8FsUdJ66XI for ; Wed, 5 Jan 2011 14:12:57 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 7918E3A67D6 for ; Wed, 5 Jan 2011 14:12: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 p05MF3Zf042348; Wed, 5 Jan 2011 22:15:03 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101052215.p05MF3Zf042348@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Wed, 05 Jan 2011 11:02:44 PST. <07d001cbad0b$2276af00$67640d00$@com> Date: Wed, 05 Jan 2011 23:15:03 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] base #32 (new): Interference between 2 clients on same host 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, 05 Jan 2011 22:12:59 -0000 ****************************************************************** Can we wait for the publication of draft-boucadair-pcp-failure-00? ****************************************************************** In your previous mail you wrote: If I understand correctly, your concern is a UPnP IGD -> PCP interworking device. => yes, I have a UPnP IGD 1.0+ / NAT-PMP / PCP -> PCP IWF on a B4 and I miss some stuff to get something operationally sound and reasonably secure. http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf says: Note that static port mappings do not necessarily mean persistence of these mappings across device resets or reboots. It is up to a gateway vendor to implement persistence as appropriate for their IGD device. => I know this text but IMHO it is the worst thing you can write. And it doesn't help for an IWF because the state is not likely lost on the PCP server of the CGN: this switches from an unsolvable persistence problem on the CPE to a PCP client/server synchronization issue (solvable but not with the current PCP). http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf says: NOTE: Port mappings are NOT REQUIRED to be persistent across device resets or reboots. It is up to the control points to recreate their port mappings when needed. => this text is better for a pure UPnP deployment. For an IWF it just squeezes it between UPnP clients (aka control points) and the PCP server of the CGN. Regards Francis.Dupont@fdupont.fr PS: the failure document has some arguments about the application ID too. From xiaohong.deng@orange-ftgroup.com Thu Jan 6 02:17: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 A03D23A6BA7 for ; Thu, 6 Jan 2011 02:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.46 X-Spam-Level: X-Spam-Status: No, score=-0.46 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, HELO_EQ_FR=0.35, MIME_CHARSET_FARAWAY=2.45, 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 REAVL+3mCAKd for ; Thu, 6 Jan 2011 02:17:30 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 8BEA83A6DD0 for ; Thu, 6 Jan 2011 02:17:30 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9BED68B8013; Thu, 6 Jan 2011 11:20:35 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 944A38B8003; Thu, 6 Jan 2011 11:20:35 +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); Thu, 6 Jan 2011 11:19:36 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Jan 2011 18:19:32 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0143B3DC@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <201101051400.p05E05vJ011814@givry.fdupont.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [pcp] PCP Issue #1, Epoch Thread-Index: AcutizP9NnQfQgS8SmKL2e6rfFJ++w== References: Your message of Tue, 04 Jan 2011 09:10:34 PST.<01fe01cbac32$4cf3cee0$e6db6ca0$@com> <201101051400.p05E05vJ011814@givry.fdupont.fr> From: To: , X-OriginalArrivalTime: 06 Jan 2011 10:19:36.0207 (UTC) FILETIME=[380481F0:01CBAD8B] Cc: pcp@ietf.org Subject: Re: [pcp] PCP Issue #1, Epoch 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, 06 Jan 2011 10:17:31 -0000 +1, I agree with Francis that 'some future OpCodes might not care about = the Epoch' is against the design of the Epoch.=20 BR, Xiaohong |-----=D3=CA=BC=FE=D4=AD=BC=FE----- |=B7=A2=BC=FE=C8=CB: Francis Dupont [mailto:Francis.Dupont@fdupont.fr]=20 |=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA1=D4=C25=C8=D5 22:00 |=CA=D5=BC=FE=C8=CB: Dan Wing |=B3=AD=CB=CD: pcp@ietf.org |=D6=F7=CC=E2: Re: [pcp] PCP Issue #1, Epoch | | In your previous mail you wrote: | | > -Maybe as a server-side IE? | =20 | On the last point, "maybe as server-side IE?", there are=20 |two ways I see to | encode the Epoch: | =20 |=3D> as none of the two ways is about an option (aka IE) I can't=20 |see how this is related to the question (:-). | | 1. as currently described in draft-ietf-pcp-base-02, which=20 |is that every PCP | response contains the Epoch. This means *every* OpCode,=20 |including new | Opcodes we might define in the future, would include the Epoch. | |=3D> if we keep the Epoch with its current meaning it should be=20 |in the common header (i.e., 1). I can't see an advantage to=20 |put it in each opcode. |(nor I can see an advantage in any gratuitous change) | | The advantage of moving the Epoch into the PIN* OpCodes is=20 |we free up 4 | bytes of space for future OpCodes that might not care about=20 |the Epoch. | |=3D> 'might not care about the Epoch' is against the design of the = Epoch. | =20 | If I don't hear objections, I will be doing (2) in -03. | =20 |=3D> I object. | |Regards | |Francis.Dupont@fdupont.fr | |PS: I have a concern about the term Epoch: it means both the=20 |Epoch itself and the seconds since start of the Epoch (SSSOE),=20 |i.e., the same word is used for absolute and relative views,=20 |leading to confusion and/or ambiguity. | | From mohamed.boucadair@orange-ftgroup.com Thu Jan 6 06:17: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 1B9663A6E1E for ; Thu, 6 Jan 2011 06:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 fTu4WV0JgYTU for ; Thu, 6 Jan 2011 06:17:20 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id 033163A6DF3 for ; Thu, 6 Jan 2011 06:17:19 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id D8CC11B821A; Thu, 6 Jan 2011 15:19:25 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id B9F2638403C; Thu, 6 Jan 2011 15:19:25 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 6 Jan 2011 15:19:25 +0100 From: To: "pcp@ietf.org" Date: Thu, 6 Jan 2011 15:19:24 +0100 Thread-Topic: PCP failure scenarios & PCP state synchronization procedure Thread-Index: AcutrLfTEDZS4IWxQE+t0B7oqmebLg== Message-ID: <14273_1294323565_4D25CF6D_14273_1391_1_94C682931C08B048B7A8645303FDC9F33C3E9FDE6B@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.12.28.90317 Subject: [pcp] 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: Thu, 06 Jan 2011 14:17:21 -0000 Dear all, =20 We have submitted a new I-D available at http://tools.ietf.org/html/draft-b= oucadair-pcp-failure-00. Abstract This document identifies and analyses several PCP failure scenarios. A procedure to retrieve the mapping(s) from the PCP Server is proposed. This procedure relies upon the use of two new PCP OpCodes: GET and GETNEXT. =20 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. PCP Failure Scenarios . . . . . . . . . . . . . . . . . . . . 3 2.1. Change of the IP Address of The PCP Server . . . . . . . . 3 2.2. Application Crash . . . . . . . . . . . . . . . . . . . . 3 2.3. PCP Client Crash . . . . . . . . . . . . . . . . . . . . . 4 2.4. Change of the Internal IP Address . . . . . . . . . . . . 4 2.5. Change of the CPE WAN IP Address . . . . . . . . . . . . . 5 2.6. Restart or Failure of the PCP Server . . . . . . . . . . . 5 2.6.1. Basic Rule . . . . . . . . . . . . . . . . . . . . . . 5 2.6.2. Clear PCP Mappings . . . . . . . . . . . . . . . . . . 6 2.6.3. State Redundancy is Enabled . . . . . . . . . . . . . 6 2.6.4. Cold-Standby without State Redundancy . . . . . . . . 6 2.6.5. Anycast Redundancy Mode . . . . . . . . . . . . . . . 6 3. PCP State Synchronization Overview . . . . . . . . . . . . . . 6 4. GET and GETNEXT OpCodes . . . . . . . . . . . . . . . . . . . 7 4.1. Message Format . . . . . . . . . . . . . . . . . . . . . . 7 4.2. New Result Codes . . . . . . . . . . . . . . . . . . . . . 8 4.3. GET: Retrieving One Single Mapping . . . . . . . . . . . . 9 4.4. GETNEXT: Retrieve the Mapping Table . . . . . . . . . . . 9 4.4.1. Filter . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4.2. Mapping Table Order . . . . . . . . . . . . . . . . . 10 4.4.3. Behavior . . . . . . . . . . . . . . . . . . . . . . . 10 4.4.4. Misc . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5. Flow Examples . . . . . . . . . . . . . . . . . . . . . . 11 Comments and inputs are welcome. =20 Cheers, Med ********************************* 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 Jan 6 10: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 D1E033A6C9B for ; Thu, 6 Jan 2011 10:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.508 X-Spam-Level: X-Spam-Status: No, score=-110.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 zaym7LDhQ2ln for ; Thu, 6 Jan 2011 10:02:53 -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 C39AB3A68D5 for ; Thu, 6 Jan 2011 10:02:53 -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: AgYGAKSSJU2rRN+K/2dsb2JhbACWD4EljGpzpWmYFYVMBIRn Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 06 Jan 2011 18:05:00 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p06I5094008949 for ; Thu, 6 Jan 2011 18:05:00 GMT From: "Dan Wing" To: Date: Thu, 6 Jan 2011 10:04:59 -0800 Message-ID: <0bd501cbadcc$3be3ce70$b3ab6b50$@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: AcutzDurI+yQ3ycaQQ+TRizSYoVAqg== Content-Language: en-us Subject: [pcp] XOR IP address in payloads 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, 06 Jan 2011 18:02:55 -0000 Both Teredo (*) and STUN (**) XOR IP addresses returned in payloads, in order to avoid interference by overzealous UDP ALG code in some NATs. Do we need the same in PCP? (I think we should, even though it slightly increases implementation complexity.) (*) http://tools.ietf.org/html/rfc4380#section-4 (**) http://tools.ietf.org/html/rfc5389#section-15.2 -d From simon.perreault@viagenie.ca Thu Jan 6 10:15: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 547703A6CED for ; Thu, 6 Jan 2011 10:15:31 -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 BMKta7EaRL6J for ; Thu, 6 Jan 2011 10:15:30 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 77CF03A6CD7 for ; Thu, 6 Jan 2011 10:15:30 -0800 (PST) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:2d18:900e:360a:5392]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AB2B220CBE for ; Thu, 6 Jan 2011 13:17:36 -0500 (EST) Message-ID: <4D260740.5090506@viagenie.ca> Date: Thu, 06 Jan 2011 13:17:36 -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: <0bd501cbadcc$3be3ce70$b3ab6b50$@com> In-Reply-To: <0bd501cbadcc$3be3ce70$b3ab6b50$@com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pcp] XOR IP address in payloads 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, 06 Jan 2011 18:15:31 -0000 On 2011-01-06 13:04, Dan Wing wrote: > Both Teredo (*) and STUN (**) XOR IP addresses returned in payloads, in > order to avoid interference by overzealous UDP ALG code in some NATs. Do we > need the same in PCP? (I think we should, even though it slightly increases > implementation complexity.) I'd say "sure why not" if I had ever seen such an ALG... 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 dthaler@microsoft.com Thu Jan 6 11:56: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 6207C3A6F6D for ; Thu, 6 Jan 2011 11:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.557 X-Spam-Level: X-Spam-Status: No, score=-110.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 Co3WUO+EoZJG for ; Thu, 6 Jan 2011 11:56:43 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 8885B3A6F66 for ; Thu, 6 Jan 2011 11:56:43 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 6 Jan 2011 11:58:50 -0800 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.255.3; Thu, 6 Jan 2011 11:58:50 -0800 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.151]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Thu, 6 Jan 2011 11:58:48 -0800 From: Dave Thaler To: Dan Wing , "pcp@ietf.org" Thread-Topic: [pcp] XOR IP address in payloads Thread-Index: AcutzDurI+yQ3ycaQQ+TRizSYoVAqgAD6inQ Date: Thu, 6 Jan 2011 19:58:49 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653448BBF9@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <0bd501cbadcc$3be3ce70$b3ab6b50$@com> In-Reply-To: <0bd501cbadcc$3be3ce70$b3ab6b50$@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] XOR IP address in payloads 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, 06 Jan 2011 19:56:44 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dan > Wing > Sent: Thursday, January 06, 2011 10:05 AM > To: pcp@ietf.org > Subject: [pcp] XOR IP address in payloads >=20 > Both Teredo (*) and STUN (**) XOR IP addresses returned in payloads, in o= rder > to avoid interference by overzealous UDP ALG code in some NATs. Do we ne= ed > the same in PCP? (I think we should, even though it slightly increases > implementation complexity.) I think this is tightly related to the "nested NAT" discussion. If we only ever use protocols hop-by-hop, then a PCP message would never flow though a NAT and the answer would be No. If we allow PCP to be used to talk to a remote PCP server through a NAT, then the answer would be Yes. -Dave >=20 > (*) http://tools.ietf.org/html/rfc4380#section-4 > (**) http://tools.ietf.org/html/rfc5389#section-15.2 >=20 > -d >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From Francis.Dupont@fdupont.fr Thu Jan 6 12:00: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 3E56D3A6F9A for ; Thu, 6 Jan 2011 12:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.205 X-Spam-Level: X-Spam-Status: No, score=-3.205 tagged_above=-999 required=5 tests=[AWL=0.044, 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 WMgjbQx6SGan for ; Thu, 6 Jan 2011 12:00:21 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 67A273A6F9C for ; Thu, 6 Jan 2011 12:00: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 p06K2Pfr022399; Thu, 6 Jan 2011 20:02:25 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101062002.p06K2Pfr022399@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Thu, 06 Jan 2011 10:04:59 PST. <0bd501cbadcc$3be3ce70$b3ab6b50$@com> Date: Thu, 06 Jan 2011 21:02:25 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] XOR IP address in payloads 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, 06 Jan 2011 20:00:22 -0000 In your previous mail you wrote: Both Teredo (*) and STUN (**) XOR IP addresses returned in payloads, in order to avoid interference by overzealous UDP ALG code in some NATs. Do we need the same in PCP? (I think we should, even though it slightly increases implementation complexity.) => NAT traversal should be a rare event. Teredo and STUN are designed to work through a NAT so it makes sense but this should remain an exception (and broken NATs too :-). So I think we should *not*. Regards Francis.Dupont@fdupont.fr From simon.perreault@viagenie.ca Thu Jan 6 12:17: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 9D22D3A6F31 for ; Thu, 6 Jan 2011 12:17:54 -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=[AWL=0.000, 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 aqPKhX0QY6rD for ; Thu, 6 Jan 2011 12:17:53 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 845793A6F35 for ; Thu, 6 Jan 2011 12:17:53 -0800 (PST) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:2d18:900e:360a:5392]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8133920D17 for ; Thu, 6 Jan 2011 15:19:59 -0500 (EST) Message-ID: <4D2623EE.7020108@viagenie.ca> Date: Thu, 06 Jan 2011 15:19:58 -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: <201101062002.p06K2Pfr022399@givry.fdupont.fr> In-Reply-To: <201101062002.p06K2Pfr022399@givry.fdupont.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pcp] XOR IP address in payloads 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, 06 Jan 2011 20:17:54 -0000 On 2011-01-06 15:02, Francis Dupont wrote: > => NAT traversal should be a rare event. I'm not too sure about that. Use case: Imagine a home gateway that supports UPnP or NAT-PMP and does not know anything about PCP (i.e. the kind we have now everywhere). Imagine an application that has been updated to include a PCP client. It uses UPnP or NAT-PMP for opening a pinhole in the home gateway, and PCP for opening a pinhole in the CGN. Unless I'm wrong, PCP is supposed to handle this use case. In this use case the PCP request will be NATed by the home gateway. 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 Francis.Dupont@fdupont.fr Thu Jan 6 12:46: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 6B0043A6CFF for ; Thu, 6 Jan 2011 12:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 xn831rF471z9 for ; Thu, 6 Jan 2011 12:46:57 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id BCCE63A6A94 for ; Thu, 6 Jan 2011 12:46:56 -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 p06Kn3o8025272; Thu, 6 Jan 2011 20:49:03 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101062049.p06Kn3o8025272@givry.fdupont.fr> From: Francis Dupont To: Dave Thaler In-reply-to: Your message of Thu, 06 Jan 2011 19:58:49 GMT. <9B57C850BB53634CACEC56EF4853FF653448BBF9@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 06 Jan 2011 21:49:03 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "pcp@ietf.org" Subject: Re: [pcp] XOR IP address in payloads 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, 06 Jan 2011 20:46:58 -0000 In your previous mail you wrote: If we allow PCP to be used to talk to a remote PCP server through a NAT, then the answer would be Yes. => it is a rare case and not only the intermediate NAT is required to support port forwarding, if possible controled by PCP, and to make the NAT detection to work PCP itself should use port forwarding. So IMHO this constraint should be far too high for a NAT which is so broken it messes randomly byte patterns which look like an IP address. So IMHO XOR IP address in PCP is more than overkilling. Regards Francis.Dupont@fdupont.fr PS: BTW I never saw a proposal to XOR IP addresses in the DNS (this doesn't say a NAT can't mess the DNS :-). From royersoftwareandservices@gmail.com Thu Jan 6 13:02: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 613443A6DF5 for ; Thu, 6 Jan 2011 13:02:11 -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 KAoiH+TXSFpt for ; Thu, 6 Jan 2011 13:02:10 -0800 (PST) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 04BBF3A6CFF for ; Thu, 6 Jan 2011 13:02:09 -0800 (PST) Received: by pvc21 with SMTP id 21so3816523pvc.31 for ; Thu, 06 Jan 2011 13:04:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=Qx7y4i9edGmS98CbWj5onybK5j7sHGwBVNhBTQFmy9Q=; b=UZdiIVe9vcBJQ4Pkx+IKjL73s4jxHE+VK8mKGFTskxeRwyBLvWNyBvaULQuFgt5dU3 9w0ZrlBQYrol5STsFInTzLanLZCytYks+2YZsea25DY78EQS2OaW2PPRXO20bUmSYqmT TVHWVlVe4mXr90O6EfX6fgqMhjDKc9y5m6Iac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type; b=SpVTVEAhBggD0XVXtxJJ1903fxs6saVXUouVI6DI6ANugQ+BTbmLyf+G6sR3b4Y2uU ohUJD+bEeP8lILKvw9mdYgl4gBOZzB4SGvJsQtfiTJFcagxQisH/WVDwVlc9P6bBs9pQ 1za3uAKjKFfhvzVm3X76nZ7fhjrnoCFrFE3ro= Received: by 10.142.246.8 with SMTP id t8mr1110931wfh.119.1294347856936; Thu, 06 Jan 2011 13:04:16 -0800 (PST) Received: from [192.168.15.4] (96-25-89-248.war.clearwire-wmx.net [96.25.89.248]) by mx.google.com with ESMTPS id x35sm1606409wfd.13.2011.01.06.13.04.04 (version=SSLv3 cipher=RC4-MD5); Thu, 06 Jan 2011 13:04:06 -0800 (PST) Message-ID: <4D262E3E.6030002@gmail.com> Date: Thu, 06 Jan 2011 14:03:58 -0700 From: Royer Software and Services Organization: http://Project-Contracting.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: pcp@ietf.org References: <201101062002.p06K2Pfr022399@givry.fdupont.fr> <4D2623EE.7020108@viagenie.ca> In-Reply-To: <4D2623EE.7020108@viagenie.ca> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000006010201040703070400" Subject: Re: [pcp] XOR IP address in payloads 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, 06 Jan 2011 21:02:11 -0000 This is a cryptographically signed message in MIME format. --------------ms000006010201040703070400 Content-Type: multipart/mixed; boundary="------------090205080709030301070609" This is a multi-part message in MIME format. --------------090205080709030301070609 Content-Type: multipart/alternative; boundary="------------000307080801000009020904" --------------000307080801000009020904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 1/6/2011 13:19, Simon Perreault wrote: > On 2011-01-06 15:02, Francis Dupont wrote: >> =3D> NAT traversal should be a rare event. > I'm not too sure about that. I double NAT. Not because I want to, because my home ISP provides me=20 with this very dumb vendor router/firewall/NAT that I can't do anything with (They do not=20 give out the password). Inside of that have my NAT that directs inbound traffic. Their firewall is one of the=20 dumbest products on the Internet. Their idiotic NAT only allows all inbound traffic to one internal IP.=20 Outbound works fine. To punch a hole in, I have to configure my PnP vendor NAT/firewall to=20 let the port in. And I have to configure my NAT to route the port. Doug *Royer Software and Services* Project-Contracting.com +1-714-989-6135 --------------000307080801000009020904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 1/6/2011 13:19, Simon Perreault wrote: 
On 2011-01-06 15:02, Francis Dupont wrote:

=3D> NAT traversal should be a rare event.

I'm not too sure about that.

I double NAT. Not because I want to, because my home ISP provides me with this very dumb
vendor router/firewall/NAT that I can't  do anything with (They = do not give out the password). Inside of that
have my NAT that directs inbound traffic. Their firewall is one of the dumbest products on the Internet.
Their idiotic NAT only allows all inbound traffic to one internal IP. Outbound works fine.

To punch a hole in, I have to configure my PnP vendor NAT/firewall to let the port in. And I have to configure
my NAT to route the port.

Doug
Royer Software and Services
Project-Contracting.com<= /a>
+1-714-989-6135

--------------000307080801000009020904-- --------------090205080709030301070609 Content-Type: text/x-vcard; charset=utf-8; name="RoyerSoftwareAndServices.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="RoyerSoftwareAndServices.vcf" begin:vcard fn:Royer Software and Services n:;Royer Software and Services org:Project-Contracting.com adr:;;;Boise;Idaho;83705;U.S.A. email;internet:RoyerSoftwareAndServices@gmail.com title:Owner tel;work:+1-714-989-6135 url:http://Project-Contracting.com version:2.1 end:vcard --------------090205080709030301070609-- --------------ms000006010201040703070400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKsDCC BVQwggM8oAMCAQICAwmUxDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEy MTExNzU2MzdaFw0xMTA2MDkxNzU2MzdaME0xGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEx MC8GCSqGSIb3DQEJARYiUm95ZXJTb2Z0d2FyZUFuZFNlcnZpY2VzQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMPmUFi2nw8/SvurDrNbe7Y/Qql/ch+LT3uw BPn12yrfMenvQP0x0zG1v3tCXdCAgzN0FeZITbKZsoI0KVClIJKz4lPf6w5R0hWOvNbcVrqa z5nPEi1cZSxJKKjl1vz0KDjb6v4wEkvvqHdMiVvTdeqV7MfayzSyQw8U0Q4aj9mKAkuhWAVU 0+xHwKMYkLJF2aHIs5dniVeAZFd+aaKqd5zQrrIEdWWMkqOMV1O+c+M//thtKRxyo2mgOIrF 5udA7qxmvJoyo9xoELaY/s9+az4Gu3VbeJ4D4jBeP6x0Hu9In8ZrMT4zgIbBHMyimR5m1c8E eykJl2odPN+UH22lIB8CAwEAAaOCAQ8wggELMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgEN BEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8g aHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYK KwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggr BgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzAtBgNVHREEJjAkgSJSb3llclNvZnR3 YXJlQW5kU2VydmljZXNAZ21haWwuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQAsQQNQLP56fnJ8 UqgCu/RfEwrzbNwkc+ODBpYuBH+pxiWW8WaU/4GdS3xVe+tKhZOxCcaqJfzsKV+8N6gi0qOy sZDwUaddJr89ah9fyIiZCHXkBDJU2XwWTBREAlST4RRpDAD5b1FAFjTNLgmM5oS8HJvA4WFv J3AmdgCdyslYXdoDN/vlNNL9tBuC2N4w7pd7Q0wx0TzybmznaV8Px8fvdTI4pUohhLaDvo8p fEMLvPkiaKgtfIsp1bmy98e/UtM8nQCKOR9Dd/+uHL7T2Qj3Q0FHa5DqsRE5J+bo4D+3L3f1 MUnzHfk3VrMKx2VDrqynuTW2yTyRRRpy10pbXXHpRr0oDTTX6YpBFC7RTq4bEfreCkm1Y00g L/iSZ3q7kbHGSiGcFB1LFd1p9ylCNYJ3gm45J5UOrbWTUmv4ZFpx4V3oVOps9nBIOnMQCmfW 0IrkcN/SoP4enrk1Sd/etu5AzdCyxFQpTogSE279tjhAbaer94s2UdlFHJIT0Qvx3V8Fwoj3 UjcZUFBEBe6YuCxKMiEPzxrWLG6Ui1j0yEM4Watcms/PIVGr6uzsv8H/y356q1oJf3RBaRS9 HyEwds5b/koZy26gPYkFKNtKT+JUP1EySk4ezPdqZVblGq3AtPVAQRuhE864RHpn3OGqmyeP /R77Fqnc/GKC2RAPLvQloDCCBVQwggM8oAMCAQICAwmUxDANBgkqhkiG9w0BAQUFADB5MRAw DgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNV BAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZzAeFw0xMDEyMTExNzU2MzdaFw0xMTA2MDkxNzU2MzdaME0xGDAWBgNVBAMT D0NBY2VydCBXb1QgVXNlcjExMC8GCSqGSIb3DQEJARYiUm95ZXJTb2Z0d2FyZUFuZFNlcnZp Y2VzQGdtYWlsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMPmUFi2nw8/ SvurDrNbe7Y/Qql/ch+LT3uwBPn12yrfMenvQP0x0zG1v3tCXdCAgzN0FeZITbKZsoI0KVCl IJKz4lPf6w5R0hWOvNbcVrqaz5nPEi1cZSxJKKjl1vz0KDjb6v4wEkvvqHdMiVvTdeqV7Mfa yzSyQw8U0Q4aj9mKAkuhWAVU0+xHwKMYkLJF2aHIs5dniVeAZFd+aaKqd5zQrrIEdWWMkqOM V1O+c+M//thtKRxyo2mgOIrF5udA7qxmvJoyo9xoELaY/s9+az4Gu3VbeJ4D4jBeP6x0Hu9I n8ZrMT4zgIbBHMyimR5m1c8EeykJl2odPN+UH22lIB8CAwEAAaOCAQ8wggELMAwGA1UdEwEB /wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3Ig RlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5MDcGCCsG AQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMDIG CCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzAtBgNV HREEJjAkgSJSb3llclNvZnR3YXJlQW5kU2VydmljZXNAZ21haWwuY29tMA0GCSqGSIb3DQEB BQUAA4ICAQAsQQNQLP56fnJ8UqgCu/RfEwrzbNwkc+ODBpYuBH+pxiWW8WaU/4GdS3xVe+tK hZOxCcaqJfzsKV+8N6gi0qOysZDwUaddJr89ah9fyIiZCHXkBDJU2XwWTBREAlST4RRpDAD5 b1FAFjTNLgmM5oS8HJvA4WFvJ3AmdgCdyslYXdoDN/vlNNL9tBuC2N4w7pd7Q0wx0Tzybmzn aV8Px8fvdTI4pUohhLaDvo8pfEMLvPkiaKgtfIsp1bmy98e/UtM8nQCKOR9Dd/+uHL7T2Qj3 Q0FHa5DqsRE5J+bo4D+3L3f1MUnzHfk3VrMKx2VDrqynuTW2yTyRRRpy10pbXXHpRr0oDTTX 6YpBFC7RTq4bEfreCkm1Y00gL/iSZ3q7kbHGSiGcFB1LFd1p9ylCNYJ3gm45J5UOrbWTUmv4 ZFpx4V3oVOps9nBIOnMQCmfW0IrkcN/SoP4enrk1Sd/etu5AzdCyxFQpTogSE279tjhAbaer 94s2UdlFHJIT0Qvx3V8Fwoj3UjcZUFBEBe6YuCxKMiEPzxrWLG6Ui1j0yEM4Watcms/PIVGr 6uzsv8H/y356q1oJf3RBaRS9HyEwds5b/koZy26gPYkFKNtKT+JUP1EySk4ezPdqZVblGq3A tPVAQRuhE864RHpn3OGqmyeP/R77Fqnc/GKC2RAPLvQloDGCA5QwggOQAgEBMIGAMHkxEDAO BgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UE AxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBj YWNlcnQub3JnAgMJlMQwCQYFKw4DAhoFAKCCAegwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTEwMTA2MjEwMzU4WjAjBgkqhkiG9w0BCQQxFgQUKXx1qERE Cs4GXAk1EhzqowgWuwcwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGRBgkrBgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMV aHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9y aXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmUxDCBkwYLKoZIhvcN AQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZI hvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmUxDANBgkqhkiG9w0BAQEFAASCAQCdYtyv vHRquuiPYFU7TlLPzCKq1FUaj6LO97Lainu0kAkIQgd7pKKZXNm48MumdLh+acwbFoY5qpT3 6c0g/k92rUYV1KfQMxfLB0HARh9XKLf6pZ5i7KMJ+O7VHClHq3SDlp3UPfDmqBYkSMVLFdE3 SIQxC7G92AzIYHGRv7LQdQpfkV33/l8HBTEYAnCDUlEodfg7wMgUKMreUbQqh3LENwwkkLQL 30tOKH+3q0SDXq7JctIGrL5qZrN7n2q/9PY9jywI1zUMLNepnJoBdWc9HkmidElC2/oglKpL f1M4PRRxNtnaklr/VEOcrztmoEtw254MK9TOoC2I86THpeddAAAAAAAA --------------ms000006010201040703070400-- From simon.perreault@viagenie.ca Thu Jan 6 13:05: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 86D5D3A6CFF for ; Thu, 6 Jan 2011 13:05:37 -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 S3NRQ4edukQd for ; Thu, 6 Jan 2011 13:05:36 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 86CAC3A6CEC for ; Thu, 6 Jan 2011 13:05:36 -0800 (PST) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:2d18:900e:360a:5392]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0BD8C20D3E for ; Thu, 6 Jan 2011 16:07:43 -0500 (EST) Message-ID: <4D262F1E.9020708@viagenie.ca> Date: Thu, 06 Jan 2011 16:07:42 -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: <201101062049.p06Kn3o8025272@givry.fdupont.fr> In-Reply-To: <201101062049.p06Kn3o8025272@givry.fdupont.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [pcp] PCP across a NAT 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, 06 Jan 2011 21:05:37 -0000 On 2011-01-06 15:49, Francis Dupont wrote: > => it is a rare case and not only the intermediate NAT is required > to support port forwarding Any recent home gateway supports static port forwarding, UPnP, and/or NAT-PMP. > and > to make the NAT detection to work PCP itself should use port forwarding. What NAT detection? Please explain. 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 Francis.Dupont@fdupont.fr Thu Jan 6 15:13: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 F14733A6DF6 for ; Thu, 6 Jan 2011 15:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 Ul4ysqEL5QiL for ; Thu, 6 Jan 2011 15:13:51 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id C7B113A6D06 for ; Thu, 6 Jan 2011 15:13: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 p06NFuVT034243; Thu, 6 Jan 2011 23:15:57 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101062315.p06NFuVT034243@givry.fdupont.fr> From: Francis Dupont To: Simon Perreault In-reply-to: Your message of Thu, 06 Jan 2011 16:07:42 EST. <4D262F1E.9020708@viagenie.ca> Date: Fri, 07 Jan 2011 00:15:56 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] PCP across a NAT 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, 06 Jan 2011 23:13:52 -0000 In your previous mail you wrote: On 2011-01-06 15:49, Francis Dupont wrote: > => it is a rare case and not only the intermediate NAT is required > to support port forwarding Any recent home gateway supports static port forwarding, UPnP, and/or NAT-PMP. => and doesn't provide a wild ALG on unknown traffic too. > and > to make the NAT detection to work PCP itself should use port forwarding. What NAT detection? Please explain. => to detect a NAT (in fact at least a NAT, this doesn't give the number of NATs or its/their positions) in a path you have to compare addresses and ports at each side. It works too if there are known NATs in the path (works == it detects unknown NATs) if you can control the address and port translation. A common way to do that is to use port forwarding. An example: Host (PCP client in our case) source address A0 and port P0 | V known NAT translating A0 P0 to A1 P1 (i.e., a port forwarding for external=(A1,P1) internal=(A0,P0) was created | perhaps a NAT here | V NAT detection peer (PCP server in our case) getting the packet from A2 P2 If A2 = A1 and P2 = P1 then there is no NAT, If A2 != A1 and/or P2 != P1 then there is at least one NAT. BTW there are two ways to handle this: either the peer gets A1 and P1 is the message payload so it can conclude the path was broken by a NAT (this is the way NAt detection works in IKEv2 for instance), or the peer reflects to the Host the address and port it got and the Host checks if it is what it expects (NAT detection in an old draft uses this way). IMHO the first way is better because its delay is half shorter. Regards Francis.Dupont@fdupont.fr PS: jamais deux sans trois... PPS: I have in my VM platform two levels of NAT and three in my hardware platform so I know how to get port forwarding to work through many NATs. From simon.perreault@viagenie.ca Thu Jan 6 15:34: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 D33593A6F75 for ; Thu, 6 Jan 2011 15:34:32 -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 roRhApvn3ofx for ; Thu, 6 Jan 2011 15:34:32 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id F38883A6D23 for ; Thu, 6 Jan 2011 15:34:31 -0800 (PST) Received: from imac-de-nadesh-morissette.local (unknown [IPv6:2001:470:1f11:783:225:4bff:fe99:520]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 274C120D10; Thu, 6 Jan 2011 18:36:38 -0500 (EST) Message-ID: <4D265205.1020604@viagenie.ca> Date: Thu, 06 Jan 2011 18:36:37 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Francis Dupont References: <201101062315.p06NFuVT034243@givry.fdupont.fr> In-Reply-To: <201101062315.p06NFuVT034243@givry.fdupont.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pcp@ietf.org Subject: Re: [pcp] PCP across a NAT 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, 06 Jan 2011 23:34:33 -0000 Le 11-01-06 18:15, Francis Dupont a écrit : > > and > > to make the NAT detection to work PCP itself should use port forwarding. > > What NAT detection? Please explain. > > => to detect a NAT (in fact at least a NAT, this doesn't give the number > of NATs or its/their positions) in a path you have to compare addresses > and ports at each side. Yes of course, but why do you think NAT detection is needed? The host sends a UPnP/NAT-PMP request. If it gets a response, it knows there is a NAT, and it knows the external address of the pinhole in that NAT. Then it sends a PCP request with that external address as the PCP request's internal address. This creates the pinhole in the second layer of NAT. No NAT detection needed. Simon From dwing@cisco.com Thu Jan 6 18:47: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 2DC163A6E4D for ; Thu, 6 Jan 2011 18:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.229 X-Spam-Level: X-Spam-Status: No, score=-110.229 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, J_CHICKENPOX_33=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 yJVUqJwna0Xu for ; Thu, 6 Jan 2011 18:47:48 -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 43BE43A6E4F for ; Thu, 6 Jan 2011 18:47:48 -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: Av0EAOsNJk2rR7Ht/2dsb2JhbACXNYxqc6RcmC6FTASEZw Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 07 Jan 2011 02:49:54 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p072nsnx002067; Fri, 7 Jan 2011 02:49:54 GMT From: "Dan Wing" To: "'Dave Thaler'" , References: <0bd501cbadcc$3be3ce70$b3ab6b50$@com> <9B57C850BB53634CACEC56EF4853FF653448BBF9@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653448BBF9@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 6 Jan 2011 18:49:53 -0800 Message-ID: <0f3e01cbae15$8f990eb0$aecb2c10$@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: AcutzDurI+yQ3ycaQQ+TRizSYoVAqgAD6inQAA5aeQA= Content-Language: en-us Subject: Re: [pcp] XOR IP address in payloads 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, 07 Jan 2011 02:47:49 -0000 > -----Original Message----- > From: Dave Thaler [mailto:dthaler@microsoft.com] > Sent: Thursday, January 06, 2011 11:59 AM > To: Dan Wing; pcp@ietf.org > Subject: RE: [pcp] XOR IP address in payloads > > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Dan > > Wing > > Sent: Thursday, January 06, 2011 10:05 AM > > To: pcp@ietf.org > > Subject: [pcp] XOR IP address in payloads > > > > Both Teredo (*) and STUN (**) XOR IP addresses returned in payloads, > in order > > to avoid interference by overzealous UDP ALG code in some NATs. Do > we need > > the same in PCP? (I think we should, even though it slightly > increases > > implementation complexity.) > > I think this is tightly related to the "nested NAT" discussion. > > If we only ever use protocols hop-by-hop, then a PCP message would > never flow though a NAT and the answer would be No. > > If we allow PCP to be used to talk to a remote PCP server through a > NAT, then the answer would be Yes. I don't know how to prevent a packet from traversing a NAT. The original STUN (RFC3489) didn't do XOR'ing but after someone noticed the problem in the wild, its revision RFC5389 added XOR'ing. I was looking to see if PCP might suffer a similar experience. And if so, to avoid it. -d > -Dave > > > > > (*) http://tools.ietf.org/html/rfc4380#section-4 > > (**) http://tools.ietf.org/html/rfc5389#section-15.2 > > > > -d > > > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp From dwing@cisco.com Thu Jan 6 18:49: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 2AA293A6E4E for ; Thu, 6 Jan 2011 18:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.526 X-Spam-Level: X-Spam-Status: No, score=-110.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 UKpaVEvfK-rQ for ; Thu, 6 Jan 2011 18:49:18 -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 602B93A6E28 for ; Thu, 6 Jan 2011 18:49:18 -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: Av0EAGIOJk2rR7Hu/2dsb2JhbACXNYxqc6RcmC6FTASEZw Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 07 Jan 2011 02:51:25 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p072pP5F022076; Fri, 7 Jan 2011 02:51:25 GMT From: "Dan Wing" To: , "'Dave Thaler'" References: Your message of Thu, 06 Jan 2011 19:58:49 GMT. <9B57C850BB53634CACEC56EF4853FF653448BBF9@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <201101062049.p06Kn3o8025272@givry.fdupont.fr> In-Reply-To: <201101062049.p06Kn3o8025272@givry.fdupont.fr> Date: Thu, 6 Jan 2011 18:51:24 -0800 Message-ID: <0f4301cbae15$c5cc5500$5164ff00$@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: Acut4ywlrBrvfc+gSCS4Xi2QnDl84QAMb+ew Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] XOR IP address in payloads 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, 07 Jan 2011 02:49:19 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Thursday, January 06, 2011 12:49 PM > To: Dave Thaler > Cc: Dan Wing; pcp@ietf.org > Subject: Re: [pcp] XOR IP address in payloads > > > In your previous mail you wrote: > > If we allow PCP to be used to talk to a remote PCP server through a > NAT, > then the answer would be Yes. > > => it is a rare case and not only the intermediate NAT is required > to support port forwarding, if possible controled by PCP, and > to make the NAT detection to work PCP itself should use port > forwarding. > So IMHO this constraint should be far too high for a NAT which is > so broken it messes randomly byte patterns which look like an IP > address. > > So IMHO XOR IP address in PCP is more than overkilling. > > Regards > > Francis.Dupont@fdupont.fr > > PS: BTW I never saw a proposal to XOR IP addresses in the DNS > (this doesn't say a NAT can't mess the DNS :-). The problem encountered, in the wild, was NATs were rewriting UDP payloads when the NAT's WAN address was in the UDP payload on a 32-bit boundary. That is less likely to happen with DNS payloads because the NAT's WAN address is very unlikely to appear in a DNS payload and if it appears it has a low probability of being 32 bit aligned. -d From xiaohong.deng@orange-ftgroup.com Thu Jan 6 22:21: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 774213A67A5 for ; Thu, 6 Jan 2011 22:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=1.395, 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 eRColaT9zr1D for ; Thu, 6 Jan 2011 22:21:38 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 7BFDF3A679C for ; Thu, 6 Jan 2011 22:21:38 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6A5FB8B8013; Fri, 7 Jan 2011 07:24:43 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 61FE18B8003; Fri, 7 Jan 2011 07:24:43 +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); Fri, 7 Jan 2011 07:23:44 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 7 Jan 2011 14:23:39 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0143B516@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <4D2623EE.7020108@viagenie.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [pcp] XOR IP address in payloads Thread-Index: AcuuM2wklwFAqTGARWmmXA+3Gu7p8Q== References: <201101062002.p06K2Pfr022399@givry.fdupont.fr> <4D2623EE.7020108@viagenie.ca> From: To: , X-OriginalArrivalTime: 07 Jan 2011 06:23:44.0062 (UTC) FILETIME=[6F184DE0:01CBAE33] Subject: Re: [pcp] XOR IP address in payloads 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, 07 Jan 2011 06:21:40 -0000 |On 2011-01-06 15:02, Francis Dupont wrote: |> =3D> NAT traversal should be a rare event. | |I'm not too sure about that. | |Use case: Imagine a home gateway that supports UPnP or NAT-PMP=20 |and does not know anything about PCP (i.e. the kind we have=20 |now everywhere). |Imagine an application that has been updated to include a PCP=20 |client. It uses UPnP or NAT-PMP for opening a pinhole in the=20 |home gateway, and PCP for opening a pinhole in the CGN. Unless=20 |I'm wrong, PCP is supposed to handle this use case. | |In this use case the PCP request will be NATed by the home gateway. This is an interesting case. It depends on deployment scenarios, in Dual Stack-Lite context, PCP request will not be NATed by the home gateway. But in NAT444 context we may face this problem, so I suppose it is necessary to XOR IP address in payloads in this case. Yet, speaking of apps, consider two types of apps, a) UPnP/NAT-PMP enabled(without PCP), e.g. today's apps; b) PCP enabled, e.g. future apps; For type a) apps, we need to deploy UPnP IWF on home gateway to deal with it. For type b) apps, It may traverse NAT depends on deployment scenarios. In case it encounters NAT that does not support PCP on its path, PCP port forwarding on the home gateway can be opened statically via web interface or via UPnP/NAT-PMP control, but it is not necessary to implement both PCP and UPnP/NAT-PMP on apps.=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 | BR, Xiaohong From mohamed.boucadair@orange-ftgroup.com Thu Jan 6 22:37: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 757E83A67C1 for ; Thu, 6 Jan 2011 22:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=0.078, 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 a7aY8kQBKOmS for ; Thu, 6 Jan 2011 22:37:02 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 6689D3A67B2 for ; Thu, 6 Jan 2011 22:37:02 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 5301222C8E6; Fri, 7 Jan 2011 07:39:08 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 3B1FA4C024; Fri, 7 Jan 2011 07:39:08 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 7 Jan 2011 07:39:08 +0100 From: To: Dan Wing , "pcp@ietf.org" Date: Fri, 7 Jan 2011 07:39:05 +0100 Thread-Topic: [pcp] XOR IP address in payloads Thread-Index: AcutzDurI+yQ3ycaQQ+TRizSYoVAqgAaA4lw Message-ID: <9922_1294382348_4D26B50C_9922_236680_1_94C682931C08B048B7A8645303FDC9F33C3E9FDFED@PUEXCB1B.nanterre.francetelecom.fr> References: <0bd501cbadcc$3be3ce70$b3ab6b50$@com> In-Reply-To: <0bd501cbadcc$3be3ce70$b3ab6b50$@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.1.7.33314 Subject: Re: [pcp] XOR IP address in payloads 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, 07 Jan 2011 06:37:04 -0000 Hi Dan, all, What would these ALGs change in the packets: (1) the internal IP address of= outgoing PCP packets, (2) any occurrence of IP addresses in PCP responses? If (1), then this is even good because the internal IP address that should = be maintained by the PCP server is the one used in the external interface o= f the NAT and not the original IP address set by the PCP Client. But still = the problem is the port number. In this case, with or without that ALG, a f= ailure will be experienced. I don't see the added value of xoring the IP ad= dress for this case.=20 If (2), I don't really understand why these ALGs do this. Unless I missed something, I'm not sure there is a justification for xoring= the IP address in PCP. 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 6 janvier 2011 19:05 =C0 : pcp@ietf.org Objet : [pcp] XOR IP address in payloads Both Teredo (*) and STUN (**) XOR IP addresses returned in payloads, in order to avoid interference by overzealous UDP ALG code in some NATs. Do we need the same in PCP? (I think we should, even though it slightly increases implementation complexity.) (*) http://tools.ietf.org/html/rfc4380#section-4 (**) http://tools.ietf.org/html/rfc5389#section-15.2 -d _______________________________________________ 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 mohamed.boucadair@orange-ftgroup.com Thu Jan 6 23:23: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 9E9CB3A67D7 for ; Thu, 6 Jan 2011 23:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.173 X-Spam-Level: X-Spam-Status: No, score=-3.173 tagged_above=-999 required=5 tests=[AWL=0.074, 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 iQulGBZREOTV for ; Thu, 6 Jan 2011 23:23:24 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 9092F3A67A8 for ; Thu, 6 Jan 2011 23:23:24 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 7AB9C324708 for ; Fri, 7 Jan 2011 08:25:30 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 622864C015 for ; Fri, 7 Jan 2011 08:25:30 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 7 Jan 2011 08:25:30 +0100 From: To: "pcp@ietf.org" Date: Fri, 7 Jan 2011 08:25:28 +0100 Thread-Topic: PCP DHCP/DHCPv6 options Thread-Index: AcuuPA8KHu7j1puoTIWKnx6CefvjuA== Message-ID: <9922_1294385130_4D26BFEA_9922_238708_1_94C682931C08B048B7A8645303FDC9F33C3E9FE004@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_94C682931C08B048B7A8645303FDC9F33C3E9FE004PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.1.7.64515 Subject: [pcp] PCP DHCP/DHCPv6 options 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, 07 Jan 2011 07:23:25 -0000 --_000_94C682931C08B048B7A8645303FDC9F33C3E9FE004PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, A new updated version of the PCP DHCP/DHCPv6 options draft has be submitted= . The I-D is available at: http://www.ietf.org/id/draft-bpw-pcp-dhcp-01.txt Comments and inputs are welcome. Cheers, Med ********************************* 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. ******************************** --_000_94C682931C08B048B7A8645303FDC9F33C3E9FE004PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D= ear=20 all,
 
A= new=20 updated version of the PCP DHCP/DHCPv6 options draft has be submitted.= The=20 I-D is available at: http://www.ietf.o= rg/id/draft-bpw-pcp-dhcp-01.txt
 
C= omments and=20 inputs are welcome.
 
Cheers,
Med
********************=
*************
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.
********************************
--_000_94C682931C08B048B7A8645303FDC9F33C3E9FE004PUEXCB1Bnante_-- From Francis.Dupont@fdupont.fr Thu Jan 6 23:58: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 BCA0A3A67DB for ; Thu, 6 Jan 2011 23:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 7N5z9nDYBTfS for ; Thu, 6 Jan 2011 23:58:52 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 82ED43A67D8 for ; Thu, 6 Jan 2011 23:58:52 -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 p0780wAV066008; Fri, 7 Jan 2011 08:00:58 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101070800.p0780wAV066008@givry.fdupont.fr> From: Francis Dupont To: Simon Perreault In-reply-to: Your message of Thu, 06 Jan 2011 18:36:37 EST. <4D265205.1020604@viagenie.ca> Date: Fri, 07 Jan 2011 09:00:58 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] PCP across a NAT 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, 07 Jan 2011 07:58:53 -0000 In your previous mail you wrote: Le 11-01-06 18:15, Francis Dupont a écrit : > > and > > to make the NAT detection to work PCP itself should use port forwarding. > > What NAT detection? Please explain. > > => to detect a NAT (in fact at least a NAT, this doesn't give the number > of NATs or its/their positions) in a path you have to compare addresses > and ports at each side. Yes of course, but why do you think NAT detection is needed? => because there could be a NAT where you expect there is none (some use the term 'NAT protection'). The host sends a UPnP/NAT-PMP request. => you believe in the universal deployment of UPnP? Why do we work on PCP BTW? For NAT-PMP it works only for the first router (aka default gateway). If it gets a response, it knows there is a NAT => the problem is if it doesn't get a response it can't conclude there is no NAT... Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Fri Jan 7 00:05: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 5BF373A67EA for ; Fri, 7 Jan 2011 00:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.907 X-Spam-Level: X-Spam-Status: No, score=-2.907 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6, 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 H8-Yte4I4IxT for ; Fri, 7 Jan 2011 00:05:38 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 5B5453A67E9 for ; Fri, 7 Jan 2011 00:05: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 p0787i76066553; Fri, 7 Jan 2011 08:07:44 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101070807.p0787i76066553@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Thu, 06 Jan 2011 18:49:53 PST. <0f3e01cbae15$8f990eb0$aecb2c10$@com> Date: Fri, 07 Jan 2011 09:07:44 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] XOR IP address in payloads 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, 07 Jan 2011 08:05:39 -0000 In your previous mail you wrote: I don't know how to prevent a packet from traversing a NAT. => but we can detect unexpected NAT traversal. The original STUN (RFC3489) didn't do XOR'ing but after someone noticed the problem in the wild, its revision RFC5389 added XOR'ing. => 'wild' is the right word: my argument is if a NAT in the path is too wild (in fact it is enough it is out of control) then PCP will fail to open pinholes through. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Fri Jan 7 00:14: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 4D66A3A67E2 for ; Fri, 7 Jan 2011 00:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.205 X-Spam-Level: X-Spam-Status: No, score=-3.205 tagged_above=-999 required=5 tests=[AWL=0.044, 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 RCUzryYdJ1+y for ; Fri, 7 Jan 2011 00:14:00 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 282273A67AC for ; Fri, 7 Jan 2011 00:14: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 p078G6j8067098; Fri, 7 Jan 2011 08:16:06 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101070816.p078G6j8067098@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Thu, 06 Jan 2011 18:51:24 PST. <0f4301cbae15$c5cc5500$5164ff00$@com> Date: Fri, 07 Jan 2011 09:16:06 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] XOR IP address in payloads 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, 07 Jan 2011 08:14:01 -0000 In your previous mail you wrote: The problem encountered, in the wild, was NATs were rewriting UDP payloads when the NAT's WAN address was in the UDP payload on a 32-bit boundary. That is less likely to happen with DNS payloads because the NAT's WAN address is very unlikely to appear in a DNS payload and if it appears it has a low probability of being 32 bit aligned. => it seems it should be better to pad the fixed header to never be on a 32 bit boundary, isn't it? BTW we have an unused octet in the fixed header, so we can remove it or double it (in case we believe we'll get an use for it): this shift the whole thing by one. Or do a similar thing with the 3 octets of padding after the protocol field. IMHO it is better to unalign packets than to obfuscate them. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Fri Jan 7 00:26: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 0FFF83A67E9 for ; Fri, 7 Jan 2011 00:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.205 X-Spam-Level: X-Spam-Status: No, score=-3.205 tagged_above=-999 required=5 tests=[AWL=0.044, 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 TjNGC1tEDoQ6 for ; Fri, 7 Jan 2011 00:26:36 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 163513A67DF for ; Fri, 7 Jan 2011 00:26: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 p078Sg2e067840; Fri, 7 Jan 2011 08:28:42 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101070828.p078Sg2e067840@givry.fdupont.fr> From: Francis Dupont To: xiaohong.deng@orange-ftgroup.com In-reply-to: Your message of Fri, 07 Jan 2011 14:23:39 +0800. <0962B0BEF842A24191AD9BE41A8DD2FC0143B516@ch-mailsrv.rd.francetelecom.fr> Date: Fri, 07 Jan 2011 09:28:42 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] XOR IP address in payloads 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, 07 Jan 2011 08:26:37 -0000 In your previous mail you wrote: But in NAT444 context we may face this problem, so I suppose it is necessary to XOR IP address in payloads in this case. => I don't like the word 'necessary' at all: NATs requiring this are broken: they need to be nuked. If we really believe it could be an issue, we should design a way to detect them. Regards Francis.Dupont@fdupont.fr From xiaohong.deng@orange-ftgroup.com Fri Jan 7 03: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 BAA3D3A67EC for ; Fri, 7 Jan 2011 03:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[AWL=1.453, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 J6kZhWswVhIA for ; Fri, 7 Jan 2011 03:02:52 -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 6FC4E3A6816 for ; Fri, 7 Jan 2011 03:02:52 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 84C26FC4012; Fri, 7 Jan 2011 12:05:01 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 78E73FC400E; Fri, 7 Jan 2011 12:05:01 +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); Fri, 7 Jan 2011 12:04:57 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 7 Jan 2011 19:04:52 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0143B671@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <201101070828.p078Sg2e067840@givry.fdupont.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [pcp] XOR IP address in payloads Thread-Index: AcuuRPpteKUCElDAQzOIykKRApLmGwADtK0Q References: Your message of Fri, 07 Jan 2011 14:23:39 +0800. <0962B0BEF842A24191AD9BE41A8DD2FC0143B516@ch-mailsrv.rd.francetelecom.fr> <201101070828.p078Sg2e067840@givry.fdupont.fr> From: To: , X-OriginalArrivalTime: 07 Jan 2011 11:04:57.0793 (UTC) FILETIME=[B89F5310:01CBAE5A] Cc: pcp@ietf.org, lan.wang@orange-ftgroup.com Subject: Re: [pcp] XOR IP address in payloads 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, 07 Jan 2011 11:02:53 -0000 After re-thinking, I changed my mind. Like others, I don't see a use case of XOR IP address in payloads. Consider a typical NAT444 scenario, where the PCP encounters NAT in its path. Assume all the 5-tuple IP headers in this example are in this order: (source IP, source port, destination IP, destination port, protocol). NAT 2 with PCP server listening on A2:P2 (e.g. CGN) | V NAT 1 (e.g. home gate way): translating A0 P0 to A1 P1 | V Host with PCP client: issue a PCP request with 5-tuple IP header: (A0, P0, A2, P2, UDP) PCP request issued by host: 5-tuple IP header: (A0, P0, A2, P2, UDP) payload: (internal ip: A0, internal port: Px)=20 PCP request translated by NAT 1 5-tuple IP header: (A1, P1, A2, P2, UDP) payload: (internal ip: A0, internal port Px)=20 PCP response from the PCP server: 5-tuple IP header: (A2, P2, A1, P1, UDP) payload: (external ip: A2 (or any other IP addresses in NAT 2's address pool), internal port Py) First, I don't think this PCP response has problems with traverse NAT 1 as the pinhole has been dynamically created by the previous PCP request. But, when the NAT 1 handles the PCP response, even if NAT 1 attempts at providing a generic ALG function and rewrites the 32-bit binary payloads containing its public IP address, I don't see any reasons for NAT 1 to change PCP response A because in PCP payload external ip=3D=3D A2 (or = any other IP addresses in NAT 2's address pool), which is not likely to match the WAN interface IP of NAT 1.=20 Dan, Please tell me if I miss something. | In your previous mail you wrote: | | But in NAT444 context we may face this problem, so I suppose it is | necessary to XOR IP address in payloads in this case. | =20 |=3D> I don't like the word 'necessary' at all: NATs requiring=20 I withdraw this word. :-) BR, Xiahong From phdgang@gmail.com Fri Jan 7 08:01: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 ED9C33A6922 for ; Fri, 7 Jan 2011 08:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 4VZHeIrajsgf for ; Fri, 7 Jan 2011 08:01:06 -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 13D763A691A for ; Fri, 7 Jan 2011 08:01:05 -0800 (PST) Received: by gwj17 with SMTP id 17so9375467gwj.31 for ; Fri, 07 Jan 2011 08:03:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=c0RUwp/A8SwELZVlXd+Vjf08HUD3UgqebAiPvDttfSI=; b=gwISuNRUi/HPn+fgceJH+AAgvK0U4g6OAerPHiEXwV+Q1PK+QiBdi3mgQedfGI3VzF zTdQUaXWOTplOCU0WW8ZD9REhdx4kvrhEV59mfJXByIQ8NtqNl5guhQ63dW8MeNV6ZaW DTQPYPkHeI6mtdrtgyjfWpUmZOUKFD8HS6nfE= 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=jXXGt/0tCdkDwYvzsbMz5UleDiFrGO5zm1IHB4ROaeUFSkiswmlGjCdFPdoLQcFb+l hHRY35DtxF4sZvjW28hVOiEcBqWQAv9THKRauz3gWMN32cWaS8JbzoU1NDhjjCIs/yIm tY5azz8O4zBzvXLDzCBlHmZhQmkqebMyR2gbA= MIME-Version: 1.0 Received: by 10.90.61.2 with SMTP id j2mr3472400aga.205.1294416192561; Fri, 07 Jan 2011 08:03:12 -0800 (PST) Received: by 10.91.131.13 with HTTP; Fri, 7 Jan 2011 08:03:11 -0800 (PST) In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC0143B671@ch-mailsrv.rd.francetelecom.fr> References: <0962B0BEF842A24191AD9BE41A8DD2FC0143B516@ch-mailsrv.rd.francetelecom.fr> <201101070828.p078Sg2e067840@givry.fdupont.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0143B671@ch-mailsrv.rd.francetelecom.fr> Date: Sat, 8 Jan 2011 00:03:11 +0800 Message-ID: From: GangChen To: xiaohong.deng@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Cc: lan.wang@orange-ftgroup.com, pcp@ietf.org Subject: Re: [pcp] XOR IP address in payloads 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, 07 Jan 2011 16:01:07 -0000 2011/1/7, xiaohong.deng@orange-ftgroup.com : > PCP request issued by host: > 5-tuple IP header: (A0, P0, A2, P2, UDP) payload: (internal ip: A0, > internal port: Px) > > PCP request translated by NAT 1 > 5-tuple IP header: (A1, P1, A2, P2, UDP) payload: (internal ip: A0, > internal port Px) > I guess the concern people have is PCP request translated by NAT 1 5-tuple IP header: (A1, P1, A2, P2, UDP) payload: (internal ip: A1, external port: Py) From dwing@cisco.com Fri Jan 7 08:29: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 504623A6908 for ; Fri, 7 Jan 2011 08:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.527 X-Spam-Level: X-Spam-Status: No, score=-110.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 JJr8ONtqNobX for ; Fri, 7 Jan 2011 08:29: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 3575F3A68C0 for ; Fri, 7 Jan 2011 08:29:00 -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: Av0EAFfOJk2rR7H+/2dsb2JhbACXPoxqc6NZmAuFTASEZw Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 07 Jan 2011 16:31:07 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p07GV6nn026559; Fri, 7 Jan 2011 16:31:06 GMT From: "Dan Wing" To: , References: <0bd501cbadcc$3be3ce70$b3ab6b50$@com> <9922_1294382348_4D26B50C_9922_236680_1_94C682931C08B048B7A8645303FDC9F33C3E9FDFED@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <9922_1294382348_4D26B50C_9922_236680_1_94C682931C08B048B7A8645303FDC9F33C3E9FDFED@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 7 Jan 2011 08:31:06 -0800 Message-ID: <10d501cbae88$48d6c0d0$da844270$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcutzDurI+yQ3ycaQQ+TRizSYoVAqgAaA4lwABTqmuA= Content-Language: en-us Subject: Re: [pcp] XOR IP address in payloads 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, 07 Jan 2011 16:29:04 -0000 > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Thursday, January 06, 2011 10:39 PM > To: Dan Wing; pcp@ietf.org > Subject: RE: [pcp] XOR IP address in payloads >=20 > Hi Dan, all, >=20 > What would these ALGs change in the packets: (1) the internal IP > address of outgoing PCP packets, (2) any occurrence of IP addresses in > PCP responses? These overzealous ALGs modify UDP packets where the NAT's WAN address=20 is in the UDP payload on a 32 bit boundary. Very hard to guess how many of these exist in the wild. =20 > If (1), then this is even good because the internal IP address that > should be maintained by the PCP server is the one used in the external > interface of the NAT and not the original IP address set by the PCP > Client. But still the problem is the port number. In this case, with = or > without that ALG, a failure will be experienced. I don't see the added > value of xoring the IP address for this case. >=20 > If (2), I don't really understand why these ALGs do this. Like all ALGs, it was done in an attempt to get an application to work. -d > Unless I missed something, I'm not sure there is a justification for > xoring the IP address in PCP. >=20 > Cheers > Med >=20 > -----Message d'origine----- > De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de > Dan Wing > Envoy=E9 : jeudi 6 janvier 2011 19:05 > =C0 : pcp@ietf.org > Objet : [pcp] XOR IP address in payloads >=20 > Both Teredo (*) and STUN (**) XOR IP addresses returned in payloads, = in > order to avoid interference by overzealous UDP ALG code in some NATs. > Do we > need the same in PCP? (I think we should, even though it slightly > increases > implementation complexity.) >=20 > (*) http://tools.ietf.org/html/rfc4380#section-4 > (**) http://tools.ietf.org/html/rfc5389#section-15.2 >=20 > -d >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp >=20 > ********************************* > This message and any attachments (the "message") are confidential and > intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, > changed or falsified. > If you are not the intended addressee of this message, please cancel = it > immediately and inform the sender. > ******************************** From dwing@cisco.com Fri Jan 7 08:33: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 B24213A68C0 for ; Fri, 7 Jan 2011 08:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.511 X-Spam-Level: X-Spam-Status: No, score=-110.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 IroruUjAm2qz for ; Fri, 7 Jan 2011 08:33:32 -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 8DCE63A68CC for ; Fri, 7 Jan 2011 08:33:32 -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: AgIGAL7PJk2rRN+J/2dsb2JhbACWGYEljGpzo0uYCoVMBIRn Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 07 Jan 2011 16:35:38 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p07GZcMQ016339; Fri, 7 Jan 2011 16:35:38 GMT From: "Dan Wing" To: References: Your message of Thu, 06 Jan 2011 18:51:24 PST. <0f4301cbae15$c5cc5500$5164ff00$@com> <201101070816.p078G6j8067098@givry.fdupont.fr> In-Reply-To: <201101070816.p078G6j8067098@givry.fdupont.fr> Date: Fri, 7 Jan 2011 08:35:38 -0800 Message-ID: <10fb01cbae88$ea988340$bfc989c0$@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: AcuuQyeQ34L2YMcTQCSH7gDhOvt6SwARbNZA Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] XOR IP address in payloads 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, 07 Jan 2011 16:33:33 -0000 > In your previous mail you wrote: > > The problem encountered, in the wild, was NATs were rewriting > UDP payloads when the NAT's WAN address was in the UDP payload > on a 32-bit boundary. > > That is less likely to happen with DNS payloads because the NAT's > WAN address is very unlikely to appear in a DNS payload and > if it appears it has a low probability of being 32 bit aligned. > > => it seems it should be better to pad the fixed header > to never be on a 32 bit boundary, isn't it? > BTW we have an unused octet in the fixed header, so we can remove > it or double it (in case we believe we'll get an use for it): > this shift the whole thing by one. Or do a similar thing with > the 3 octets of padding after the protocol field. > > IMHO it is better to unalign packets than to obfuscate them. Not on a lot of our platforms. -d From dwing@cisco.com Fri Jan 7 09:40: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 8BFE23A692E for ; Fri, 7 Jan 2011 09:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.528 X-Spam-Level: X-Spam-Status: No, score=-110.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 t1Zxaqiw-kST for ; Fri, 7 Jan 2011 09:40: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 5935E3A68C5 for ; Fri, 7 Jan 2011 09:40: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: Av0EAPreJk2rR7Hu/2dsb2JhbACXP4xqc6NImA2FTASEZw Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 07 Jan 2011 17:42:20 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p07HgKCx013397; Fri, 7 Jan 2011 17:42:20 GMT From: "Dan Wing" To: , References: Your message of Fri, 07 Jan 2011 14:23:39 +0800. <0962B0BEF842A24191AD9BE41A8DD2FC0143B516@ch-mailsrv.rd.francetelecom.fr> <201101070828.p078Sg2e067840@givry.fdupont.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0143B671@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC0143B671@ch-mailsrv.rd.francetelecom.fr> Date: Fri, 7 Jan 2011 09:42:19 -0800 Message-ID: <11b601cbae92$3bbc8560$b3359020$@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: AcuuRPpteKUCElDAQzOIykKRApLmGwADtK0QAA1XxlA= Content-Language: en-us Cc: pcp@ietf.org, lan.wang@orange-ftgroup.com Subject: Re: [pcp] XOR IP address in payloads 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, 07 Jan 2011 17:40:14 -0000 > -----Original Message----- > From: xiaohong.deng@orange-ftgroup.com [mailto:xiaohong.deng@orange- > ftgroup.com] > Sent: Friday, January 07, 2011 3:05 AM > To: Francis.Dupont@fdupont.fr; dwing@cisco.com > Cc: simon.perreault@viagenie.ca; pcp@ietf.org; lan.wang@orange- > ftgroup.com > Subject: RE: [pcp] XOR IP address in payloads > > After re-thinking, I changed my mind. Like others, I don't see a use > case of XOR IP address in payloads. > > Consider a typical NAT444 scenario, where the PCP encounters NAT in its > path. Assume all the 5-tuple IP headers in this example are in this > order: (source IP, source port, destination IP, destination port, > protocol). > > NAT 2 with PCP server listening on A2:P2 (e.g. CGN) > | > V > NAT 1 (e.g. home gate way): translating A0 P0 to A1 P1 > | > V > Host with PCP client: issue a PCP request with 5-tuple IP header: (A0, > P0, A2, P2, UDP) > > PCP request issued by host: > 5-tuple IP header: (A0, P0, A2, P2, UDP) payload: (internal ip: A0, > internal port: Px) > > PCP request translated by NAT 1 > 5-tuple IP header: (A1, P1, A2, P2, UDP) payload: (internal ip: A0, > internal port Px) > > PCP response from the PCP server: > 5-tuple IP header: (A2, P2, A1, P1, UDP) payload: (external ip: A2 (or > any other IP addresses in NAT 2's address pool), internal port Py) > > First, I don't think this PCP response has problems with traverse NAT 1 > as the pinhole has been dynamically created by the previous PCP > request. > > But, when the NAT 1 handles the PCP response, even if NAT 1 attempts at > providing a generic ALG function and rewrites the 32-bit binary > payloads > containing its public IP address, I don't see any reasons for NAT 1 to > change PCP response A because in PCP payload external ip== A2 (or any > other IP addresses in NAT 2's address pool), which is not likely to > match the WAN interface IP of NAT 1. That PCP response contains the NAT-1's public IP address, in the existing internal-ip-address field of the PIN* response packet format. Teredo and STUN experience says that some NATs will modify the PCP UDP payload. -d > Dan, Please tell me if I miss something. > > > | In your previous mail you wrote: > | > | But in NAT444 context we may face this problem, so I suppose it is > | necessary to XOR IP address in payloads in this case. > | > |=> I don't like the word 'necessary' at all: NATs requiring > > I withdraw this word. :-) > > BR, > Xiahong From dwing@cisco.com Fri Jan 7 09:41: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 4D8EE3A6920 for ; Fri, 7 Jan 2011 09:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.529 X-Spam-Level: X-Spam-Status: No, score=-110.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 4G57FZwXm2XT for ; Fri, 7 Jan 2011 09:41: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 4EDBD3A68C5 for ; Fri, 7 Jan 2011 09:41: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: AgIGAK7fJk2rR7H+/2dsb2JhbACWGoEljGpzo0qYDYVMBIRn Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 07 Jan 2011 17:42:52 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p07HgpGm027862 for ; Fri, 7 Jan 2011 17:42:51 GMT From: "Dan Wing" To: Date: Fri, 7 Jan 2011 09:42:51 -0800 Message-ID: <11b701cbae92$4e5395b0$eafac110$@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: Acuukk4SnXDcNYaESqilP8X2bbFnlg== Content-Language: en-us Subject: [pcp] PCP and nested NAPT 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, 07 Jan 2011 17:41:03 -0000 I have prepared a slide deck which suggests two goals for PCP: 1. Work over one existing NAPT in people's homes 2. Detect multiple existing NAPTs and a mechanism to achieve the goal: * PCP client speaks UPnP IGDto existing in-home NAPT * PCP client speaks PCP to PCP server (which is similar to what Simon recently discussed in http://www.ietf.org/mail-archive/web/pcp/current/msg00634.html). To achieve this, I believe we need three things: 1. IANA-registered PCP server address 2. UPnP IGD running on existing NAPT - Rumor says ~25% of NAPTsrun UPnP IGD 3. New PCP Option to indicate source address - To detect the 3 NAPT situation Slides are at: ftp://ftp-eng.cisco.com/dwing/pcp/pcp-nested-nat.pdf Comments welcome. -d From Francis.Dupont@fdupont.fr Fri Jan 7 13:57: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 5F15428C0D7 for ; Fri, 7 Jan 2011 13:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.205 X-Spam-Level: X-Spam-Status: No, score=-3.205 tagged_above=-999 required=5 tests=[AWL=0.044, 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 GNkd5usKj6CE for ; Fri, 7 Jan 2011 13:57:23 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 7703928C0D6 for ; Fri, 7 Jan 2011 13:57:21 -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 p07LxR50017332; Fri, 7 Jan 2011 21:59:27 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101072159.p07LxR50017332@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Fri, 07 Jan 2011 09:42:19 PST. <11b601cbae92$3bbc8560$b3359020$@com> Date: Fri, 07 Jan 2011 22:59:27 +0100 Sender: Francis.Dupont@fdupont.fr Cc: xiaohong.deng@orange-ftgroup.com, pcp@ietf.org, lan.wang@orange-ftgroup.com Subject: Re: [pcp] XOR IP address in payloads 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, 07 Jan 2011 21:57:24 -0000 In your previous mail you wrote: Teredo and STUN experience says that some NATs will modify the PCP UDP payload. => as you seem to know what is exactly this crazy behavior, can you design a way to detect such NATs? IMHO it should be more useful for users than to mess the PCP message layout. (the idea is such NATs will break randomly any protocol (at the exception of Teredo and STUN) so if one can detect them (s)he can jump on his/her favorite weapon to solve the issue). Regards Francis.Dupont@fdupont.fr From dwing@cisco.com Fri Jan 7 14:25: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 D501428C12E for ; Fri, 7 Jan 2011 14:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.515 X-Spam-Level: X-Spam-Status: No, score=-110.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 mrgFY9++JzFw for ; Fri, 7 Jan 2011 14:25:27 -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 099A928C136 for ; Fri, 7 Jan 2011 14:25:16 -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: AnEFAAIiJ02rRN+J/2dsb2JhbACWHoEljGpzoxKYA4VMBIRn Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 07 Jan 2011 22:27:23 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p07MRM23004310; Fri, 7 Jan 2011 22:27:22 GMT From: "Dan Wing" To: References: Your message of Fri, 07 Jan 2011 09:42:19 PST. <11b601cbae92$3bbc8560$b3359020$@com> <201101072159.p07LxR50017332@givry.fdupont.fr> In-Reply-To: <201101072159.p07LxR50017332@givry.fdupont.fr> Date: Fri, 7 Jan 2011 14:27:21 -0800 Message-ID: <12ef01cbaeba$0d600de0$282029a0$@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: AcuutisQKwgMmiDdS7KBx/jgTIHkVgAA50jg Content-Language: en-us Cc: xiaohong.deng@orange-ftgroup.com, pcp@ietf.org, lan.wang@orange-ftgroup.com Subject: Re: [pcp] XOR IP address in payloads 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, 07 Jan 2011 22:25:27 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Friday, January 07, 2011 1:59 PM > To: Dan Wing > Cc: xiaohong.deng@orange-ftgroup.com; simon.perreault@viagenie.ca; > pcp@ietf.org; lan.wang@orange-ftgroup.com > Subject: Re: [pcp] XOR IP address in payloads > > > In your previous mail you wrote: > > Teredo and STUN experience says that some NATs will modify the > PCP UDP payload. > > => as you seem to know what is exactly this crazy behavior, > can you design a way to detect such NATs? IMHO it should be > more useful for users than to mess the PCP message layout. http://tools.ietf.org/html/rfc5780#section-3.6 but it isn't always reliable, per http://tools.ietf.org/html/rfc5780#section-1 -d > (the idea is such NATs will break randomly any protocol > (at the exception of Teredo and STUN) so if one can detect them > (s)he can jump on his/her favorite weapon to solve the issue). > > Regards > > Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Fri Jan 7 17:08: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 F2F193A69B7 for ; Fri, 7 Jan 2011 17:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 1mWAzIH9fNSk for ; Fri, 7 Jan 2011 17:08:55 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 91E933A69AE for ; Fri, 7 Jan 2011 17:08: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 p081B0uF028999; Sat, 8 Jan 2011 01:11:00 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101080111.p081B0uF028999@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Fri, 07 Jan 2011 09:42:51 PST. <11b701cbae92$4e5395b0$eafac110$@com> Date: Sat, 08 Jan 2011 02:11:00 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] PCP and nested NAPT 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, 08 Jan 2011 01:08:57 -0000 In your previous mail you wrote: To achieve this, I believe we need three things: 1. IANA-registered PCP server address => I can't see why. 2. UPnP IGD running on existing NAPT - Rumor says ~25% of NAPTsrun UPnP IGD => in general you need a pcp (lower case) for each NAT on the path, both to run PCP through them and to build port forwarding entries from the Internet to hosts. 3. New PCP Option to indicate source address - To detect the 3 NAPT situation => this is NAT detection and IMHO it should be done by the PCP server with source address and port. Wild ALG detection too should be fine. Regards Francis.Dupont@fdupont.fr From mohamed.boucadair@orange-ftgroup.com Sun Jan 9 23:57: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 6A93B3A6AAA for ; Sun, 9 Jan 2011 23:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.176 X-Spam-Level: X-Spam-Status: No, score=-3.176 tagged_above=-999 required=5 tests=[AWL=0.072, 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 F+MwTqb09fVV for ; Sun, 9 Jan 2011 23:57:28 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 572F53A6AB3 for ; Sun, 9 Jan 2011 23:57:27 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 3714122C410; Mon, 10 Jan 2011 08:59:38 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1DE9923804B; Mon, 10 Jan 2011 08:59:38 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 10 Jan 2011 08:59:37 +0100 From: To: Dan Wing , "pcp@ietf.org" Date: Mon, 10 Jan 2011 08:59:37 +0100 Thread-Topic: [pcp] PCP and nested NAPT Thread-Index: Acuukk4SnXDcNYaESqilP8X2bbFnlgCCY9Ow Message-ID: <12343_1294646378_4D2ABC6A_12343_191100_1_94C682931C08B048B7A8645303FDC9F33C3FD7AE24@PUEXCB1B.nanterre.francetelecom.fr> References: <11b701cbae92$4e5395b0$eafac110$@com> In-Reply-To: <11b701cbae92$4e5395b0$eafac110$@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.1.10.70314 Subject: Re: [pcp] PCP and nested NAPT 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, 10 Jan 2011 07:57:29 -0000 Hi Dan, We have discussed this point in the past several times; see for instance: h= ttp://www.ietf.org/mail-archive/web/pcp/current/msg00168.html.=20 I don't want to repeat my self but it would be efficient if you include the= points raised in that thread. Cheers, Med=20 -----Message d'origine----- De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Dan W= ing Envoy=E9 : vendredi 7 janvier 2011 18:43 =C0 : pcp@ietf.org Objet : [pcp] PCP and nested NAPT I have prepared a slide deck which suggests two goals for PCP: 1. Work over one existing NAPT in people's homes 2. Detect multiple existing NAPTs and a mechanism to achieve the goal: * PCP client speaks UPnP IGDto existing in-home NAPT * PCP client speaks PCP to PCP server (which is similar to what Simon recently discussed in http://www.ietf.org/mail-archive/web/pcp/current/msg00634.html). To achieve this, I believe we need three things: 1. IANA-registered PCP server address 2. UPnP IGD running on existing NAPT - Rumor says ~25% of NAPTsrun UPnP IGD 3. New PCP Option to indicate source address - To detect the 3 NAPT situation Slides are at: ftp://ftp-eng.cisco.com/dwing/pcp/pcp-nested-nat.pdf Comments welcome. -d _______________________________________________ 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 mohamed.boucadair@orange-ftgroup.com Mon Jan 10 00:04: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 2A9AE28C0F0 for ; Mon, 10 Jan 2011 00:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.179 X-Spam-Level: X-Spam-Status: No, score=-3.179 tagged_above=-999 required=5 tests=[AWL=0.069, 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 BsxocbThcyGH for ; Mon, 10 Jan 2011 00:04:49 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id E3FF428C0D8 for ; Mon, 10 Jan 2011 00:04:48 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 14D3C324473; Mon, 10 Jan 2011 09:07:01 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id EEFD027C06E; Mon, 10 Jan 2011 09:07:00 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Mon, 10 Jan 2011 09:07:00 +0100 From: To: Dan Wing , "pcp@ietf.org" Date: Mon, 10 Jan 2011 09:06:59 +0100 Thread-Topic: [pcp] XOR IP address in payloads Thread-Index: AcutzDurI+yQ3ycaQQ+TRizSYoVAqgAaA4lwABTqmuAAhRitAA== Message-ID: <32730_1294646821_4D2ABE24_32730_128046_1_94C682931C08B048B7A8645303FDC9F33C3FD7AE2B@PUEXCB1B.nanterre.francetelecom.fr> References: <0bd501cbadcc$3be3ce70$b3ab6b50$@com> <9922_1294382348_4D26B50C_9922_236680_1_94C682931C08B048B7A8645303FDC9F33C3E9FDFED@PUEXCB1B.nanterre.francetelecom.fr> <10d501cbae88$48d6c0d0$da844270$@com> In-Reply-To: <10d501cbae88$48d6c0d0$da844270$@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.1.10.70314 Subject: Re: [pcp] XOR IP address in payloads 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, 10 Jan 2011 08:04:50 -0000 Re-, I still don't get the point about what you mentioned: "where the NAT's WAN = address=20 is in the UDP payload on a 32 bit boundary" if this applies for incoming or= outgoing packets. Are you referring to what is defined for example in RFC5780, which I unders= tand: " 3.6. Detecting a Generic Application Level Gateway (ALG) A number of NAT boxes are now being deployed into the market that try to provide "generic" ALG functionality. These generic ALGs hunt for IP addresses, either in text or binary form within a packet, and rewrite them if they match a binding. This behavior can be detected because the STUN server returns both the MAPPED-ADDRESS and XOR- MAPPED-ADDRESS in the same response. If the result in the two does not match, there is a NAT with a generic ALG in the path. This test apples to UDP and TCP, but not TLS over TCP connections." ? -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : vendredi 7 janvier 2011 17:31 =C0 : BOUCADAIR Mohamed NCPI/NAD/TIP; pcp@ietf.org Objet : RE: [pcp] XOR IP address in payloads > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Thursday, January 06, 2011 10:39 PM > To: Dan Wing; pcp@ietf.org > Subject: RE: [pcp] XOR IP address in payloads >=20 > Hi Dan, all, >=20 > What would these ALGs change in the packets: (1) the internal IP > address of outgoing PCP packets, (2) any occurrence of IP addresses in > PCP responses? These overzealous ALGs modify UDP packets where the NAT's WAN address=20 is in the UDP payload on a 32 bit boundary. Very hard to guess how many of these exist in the wild.=20=20 > If (1), then this is even good because the internal IP address that > should be maintained by the PCP server is the one used in the external > interface of the NAT and not the original IP address set by the PCP > Client. But still the problem is the port number. In this case, with or > without that ALG, a failure will be experienced. I don't see the added > value of xoring the IP address for this case. >=20 > If (2), I don't really understand why these ALGs do this. Like all ALGs, it was done in an attempt to get an application to work. -d > Unless I missed something, I'm not sure there is a justification for > xoring the IP address in PCP. >=20 > Cheers > Med >=20 > -----Message d'origine----- > De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de > Dan Wing > Envoy=E9 : jeudi 6 janvier 2011 19:05 > =C0 : pcp@ietf.org > Objet : [pcp] XOR IP address in payloads >=20 > Both Teredo (*) and STUN (**) XOR IP addresses returned in payloads, in > order to avoid interference by overzealous UDP ALG code in some NATs. > Do we > need the same in PCP? (I think we should, even though it slightly > increases > implementation complexity.) >=20 > (*) http://tools.ietf.org/html/rfc4380#section-4 > (**) http://tools.ietf.org/html/rfc5389#section-15.2 >=20 > -d >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp >=20 > ********************************* > This message and any attachments (the "message") are confidential and > intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, > changed or falsified. > If you are not the intended addressee of this message, please cancel it > immediately and inform the sender. > ******************************** ********************************* 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 xiaohong.deng@orange-ftgroup.com Mon Jan 10 00:51: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 566CC28C0F5 for ; Mon, 10 Jan 2011 00:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.930, 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 Qc2uBSMLiV2M for ; Mon, 10 Jan 2011 00:51:08 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 7853428C0F2 for ; Mon, 10 Jan 2011 00:51:08 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 349178B8002; Mon, 10 Jan 2011 09:54:21 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 286748B8001; Mon, 10 Jan 2011 09:54:21 +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); Mon, 10 Jan 2011 09:53:21 +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: Mon, 10 Jan 2011 16:53:17 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0143B8CC@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [pcp] XOR IP address in payloads Thread-Index: AcuuhGWJHjFtlCuCRqmJD3fvkewBzQCGn4ew References: <0962B0BEF842A24191AD9BE41A8DD2FC0143B516@ch-mailsrv.rd.francetelecom.fr><201101070828.p078Sg2e067840@givry.fdupont.fr><0962B0BEF842A24191AD9BE41A8DD2FC0143B671@ch-mailsrv.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 10 Jan 2011 08:53:21.0323 (UTC) FILETIME=[D532DFB0:01CBB0A3] Cc: lan.wang@orange-ftgroup.com, pcp@ietf.org Subject: Re: [pcp] XOR IP address in payloads 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, 10 Jan 2011 08:51:09 -0000 =20 |2011/1/7, xiaohong.deng@orange-ftgroup.com=20 |: |> PCP request issued by host: |> 5-tuple IP header: (A0, P0, A2, P2, UDP) payload: (internal ip: A0,=20 |> internal port: Px) |> |> PCP request translated by NAT 1 |> 5-tuple IP header: (A1, P1, A2, P2, UDP) payload: (internal ip: A0,=20 |> internal port Px) |> |I guess the concern people have is PCP request translated by=20 |NAT 1 5-tuple IP header: (A1, P1, A2, P2, UDP) payload:=20 |(internal ip: A1, external port: Py) Would you explain why? I don't see why NAT-1 translates UDP payload/PCP request from (internal ip: A0, external port: Px) to (internal ip: A1, external port: Py), =20 because NAT-1s' WAN address A1 does *not* present in the PCP request sent by host, even if "These overzealous ALGs modify UDP packets *where* the NAT's WAN address is in the UDP payload on a 32 bit boundary. "-- Quoted from Dan's reply BR, xiaohong From xiaohong.deng@orange-ftgroup.com Mon Jan 10 00:52: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 E85B428C107 for ; Mon, 10 Jan 2011 00:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.697, 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 VAFUVTOp4Azn for ; Mon, 10 Jan 2011 00:52:07 -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 1908328C104 for ; Mon, 10 Jan 2011 00:52:07 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 07066760003; Mon, 10 Jan 2011 09:58:54 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id F211E760001; Mon, 10 Jan 2011 09:58:53 +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); Mon, 10 Jan 2011 09:54:20 +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: Mon, 10 Jan 2011 16:54:16 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0143B8CF@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <11b601cbae92$3bbc8560$b3359020$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE [pcp] XOR IP address in payloads Thread-Index: AcuuRPpteKUCElDAQzOIykKRApLmGwADtK0QAA1XxlAAhdQEEA== References: Your message of Fri, 07 Jan 2011 14:23:39 +0800. <0962B0BEF842A24191AD9BE41A8DD2FC0143B516@ch-mailsrv.rd.francetelecom.fr> <201101070828.p078Sg2e067840@givry.fdupont.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0143B671@ch-mailsrv.rd.francetelecom.fr> <11b601cbae92$3bbc8560$b3359020$@com> From: To: , X-OriginalArrivalTime: 10 Jan 2011 08:54:20.0188 (UTC) FILETIME=[F848F5C0:01CBB0A3] Cc: pcp@ietf.org, lan.wang@orange-ftgroup.com Subject: [pcp] RE XOR IP address in payloads 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, 10 Jan 2011 08:52:08 -0000 |That PCP response contains the NAT-1's public IP address, in=20 |the existing internal-ip-address field of the PIN* response=20 |packet format. =20 I wonder how PCP response could contain the NAT-1's public IP address in the existing internal-ip-address. Do you mean NAT-1's ALG has already modified the PCP request when it passed through NAT-1? But even if these=20 overzealous ALGs modify UDP packets where the NAT's WAN address is in the UDP payload on a 32 bit boundary,=20 I can't see a reason for NAT-1's ALG to modify PCP request's internal-ip-address, as NAT-1's WAN addresses does *not* present in the original payload of PCP request, which was sent by host. I missed something? |Teredo and STUN experience says that some NATs will modify the=20 |PCP UDP payload. | BR, Xiaohong From mohamed.boucadair@orange-ftgroup.com Mon Jan 10 01:00: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 D7A8E28C117 for ; Mon, 10 Jan 2011 01:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=0.066, 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 g1sgy6weB+2B for ; Mon, 10 Jan 2011 01:00:27 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 8E55A28C113 for ; Mon, 10 Jan 2011 01:00:26 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 5C32118C506; Mon, 10 Jan 2011 10:02:39 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 4100E35C05A; Mon, 10 Jan 2011 10:02:39 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Mon, 10 Jan 2011 10:02:39 +0100 From: To: Dan Wing , "pcp@ietf.org" Date: Mon, 10 Jan 2011 10:02:37 +0100 Thread-Topic: PCP-base 02: Section 7.7 Thread-Index: AcuwpSDJg0IJqOgoTraew+QfCbl6Ug== Message-ID: <7726_1294650159_4D2ACB2F_7726_21502_1_94C682931C08B048B7A8645303FDC9F33C3FD7AEA7@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_94C682931C08B048B7A8645303FDC9F33C3FD7AEA7PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.1.10.70314 Subject: [pcp] PCP-base 02: Section 7.7 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, 10 Jan 2011 09:00:27 -0000 --_000_94C682931C08B048B7A8645303FDC9F33C3FD7AEA7PUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan, I re-read section 7.7 of pcp-02 and especially: " On many common platforms (i.e., those making use of the BSD sockets API), using PCP for purposes of application keepalives by issuing a PCP request followed by a dynamic connection to the server is difficult to implement properly. This is therefore NOT RECOMMENDED. Instead, client applications SHOULD first establish a dynamic connection to a server, and then issue a PCP request related to that connection, including the REMOTE_PEER option." I'm not sure this reflects the opinions that have been expressed in this ma= iling list about this issue. I personally expressed some concerns about the connect-then-lifetime availa= ble at: http://www.ietf.org/mail-archive/web/pcp/current/msg00483.html I still disagree with the conclusion of this section in its current state; = in particular keepalive+avoid ALGs is to be considered IMHO. Cheers, Med ********************************* 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. ******************************** --_000_94C682931C08B048B7A8645303FDC9F33C3FD7AEA7PUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
H= i=20 Dan,
 
I= re-read=20 section 7.7 of pcp-02 and especially:
 
"   On many common platforms (i.e., tho= se=20 making use of the BSD sockets
   API), using PCP for purposes = of=20 application keepalives by issuing a
   PCP request followed by= a=20 dynamic connection to the server is
   difficult to implement= =20 properly.  This is therefore NOT RECOMMENDED.
   Instead,= =20 client applications SHOULD first establish a dynamic
   connec= tion=20 to a server, and then issue a PCP request related to that
  = =20 connection, including the REMOTE_PEER option."
I= 'm not sure=20 this reflects the opinions that have been expressed in this mailing list ab= out=20 this issue.
 
I=20 personally expressed some concerns about the connect-then-lifetime availabl= e at:=20 http://www.ietf.org/mail-archive/web/pcp/current/msg00483.html 
 
I= still=20 disagree with the conclusion of this section in its current state; in= =20 particular keepalive+avoid ALGs is to be considered=20 IMHO. 
 
Cheers,
Med
=
*********************************
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.
********************************
--_000_94C682931C08B048B7A8645303FDC9F33C3FD7AEA7PUEXCB1Bnante_-- From simon.perreault@viagenie.ca Mon Jan 10 05:42: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 DE69228C163 for ; Mon, 10 Jan 2011 05:42:51 -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 FF2ABThPG4wi for ; Mon, 10 Jan 2011 05:42:49 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 75E5B28C16A for ; Mon, 10 Jan 2011 05:42:49 -0800 (PST) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:1129:7bed:94d0:8762]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A3CC020D05 for ; Mon, 10 Jan 2011 08:45:02 -0500 (EST) Message-ID: <4D2B0D5E.5030302@viagenie.ca> Date: Mon, 10 Jan 2011 08:45:02 -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: <7726_1294650159_4D2ACB2F_7726_21502_1_94C682931C08B048B7A8645303FDC9F33C3FD7AEA7@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <7726_1294650159_4D2ACB2F_7726_21502_1_94C682931C08B048B7A8645303FDC9F33C3FD7AEA7@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pcp] PCP-base 02: Section 7.7 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, 10 Jan 2011 13:42:52 -0000 On 2011-01-10 04:02, mohamed.boucadair@orange-ftgroup.com wrote: > I re-read section 7.7 of pcp-02 and especially: > > " On many common platforms (i.e., those making use of the BSD sockets > API), using PCP for purposes of application keepalives by issuing a > PCP request followed by a dynamic connection to the server is > difficult to implement properly. This is therefore NOT RECOMMENDED. > Instead, client applications SHOULD first establish a dynamic > connection to a server, and then issue a PCP request related to that > connection, including the REMOTE_PEER option." > I'm not sure this reflects the opinions that have been expressed in this > mailing list about this issue. Note that this was discussed in the virtual interim meeting. I seem to recall the consensus being that the advantage of easy deployment outweighed the disadvantages. (Were the minutes of the meeting posted?) 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 mohamed.boucadair@orange-ftgroup.com Mon Jan 10 06:45: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 5A4F43A6AFE for ; Mon, 10 Jan 2011 06:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 8TP-0wTvwvoO for ; Mon, 10 Jan 2011 06:45:08 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 0E9C03A69C4 for ; Mon, 10 Jan 2011 06:45:07 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id A5037190214; Mon, 10 Jan 2011 15:47:20 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 8DE3338403A; Mon, 10 Jan 2011 15:47:20 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 10 Jan 2011 15:47:20 +0100 From: To: Simon Perreault , "pcp@ietf.org" Date: Mon, 10 Jan 2011 15:47:19 +0100 Thread-Topic: [pcp] PCP-base 02: Section 7.7 Thread-Index: AcuwzJiicO7zEBJiQDGmhse14FaryQACGUZg Message-ID: <9591_1294670840_4D2B1BF8_9591_4714_1_94C682931C08B048B7A8645303FDC9F33C3FD7B1DD@PUEXCB1B.nanterre.francetelecom.fr> References: <7726_1294650159_4D2ACB2F_7726_21502_1_94C682931C08B048B7A8645303FDC9F33C3FD7AEA7@PUEXCB1B.nanterre.francetelecom.fr> <4D2B0D5E.5030302@viagenie.ca> In-Reply-To: <4D2B0D5E.5030302@viagenie.ca> 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.1.10.133321 Subject: Re: [pcp] PCP-base 02: Section 7.7 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, 10 Jan 2011 14:45:09 -0000 Dear Simon, I attended the interim meeting but I left before the end of the conf call. I didn't seen any minutes posted of the interim meeting.=20 Cheers, Med=20 -----Message d'origine----- De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Simon= Perreault Envoy=E9 : lundi 10 janvier 2011 14:45 =C0 : pcp@ietf.org Objet : Re: [pcp] PCP-base 02: Section 7.7 On 2011-01-10 04:02, mohamed.boucadair@orange-ftgroup.com wrote: > I re-read section 7.7 of pcp-02 and especially: >=20=20 > " On many common platforms (i.e., those making use of the BSD sockets > API), using PCP for purposes of application keepalives by issuing a > PCP request followed by a dynamic connection to the server is > difficult to implement properly. This is therefore NOT RECOMMENDED. > Instead, client applications SHOULD first establish a dynamic > connection to a server, and then issue a PCP request related to that > connection, including the REMOTE_PEER option." > I'm not sure this reflects the opinions that have been expressed in this > mailing list about this issue. Note that this was discussed in the virtual interim meeting. I seem to recall the consensus being that the advantage of easy deployment outweighed the disadvantages. (Were the minutes of the meeting posted?) 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 ********************************* 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 Mon Jan 10 08:23:10 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 01F393A67ED for ; Mon, 10 Jan 2011 08:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.53 X-Spam-Level: X-Spam-Status: No, score=-110.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 mrS4wuFGiMVn for ; Mon, 10 Jan 2011 08:23:06 -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 B0EAB3A67DF for ; Mon, 10 Jan 2011 08:23:06 -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: Av0EACPCKk2rR7Ht/2dsb2JhbACXW4xqc6Mtl2+FTASEZw Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 10 Jan 2011 16:25:20 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0AGPKwd012063; Mon, 10 Jan 2011 16:25:20 GMT From: "Dan Wing" To: , References: <0bd501cbadcc$3be3ce70$b3ab6b50$@com> <9922_1294382348_4D26B50C_9922_236680_1_94C682931C08B048B7A8645303FDC9F33C3E9FDFED@PUEXCB1B.nanterre.francetelecom.fr> <10d501cbae88$48d6c0d0$da844270$@com> <32730_1294646821_4D2ABE24_32730_128046_1_94C682931C08B048B7A8645303FDC9F33C3FD7AE2B@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <32730_1294646821_4D2ABE24_32730_128046_1_94C682931C08B048B7A8645303FDC9F33C3FD7AE2B@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 10 Jan 2011 08:25:17 -0800 Message-ID: <162501cbb0e2$f9b29940$ed17cbc0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcutzDurI+yQ3ycaQQ+TRizSYoVAqgAaA4lwABTqmuAAhRitAAARoR4A Content-Language: en-us Subject: Re: [pcp] XOR IP address in payloads 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, 10 Jan 2011 16:23:10 -0000 > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Monday, January 10, 2011 12:07 AM > To: Dan Wing; pcp@ietf.org > Subject: RE: [pcp] XOR IP address in payloads >=20 > Re-, >=20 > I still don't get the point about what you mentioned: "where the NAT's > WAN address > is in the UDP payload on a 32 bit boundary" if this applies for > incoming or outgoing packets. >=20 > Are you referring to what is defined for example in RFC5780, which I > understand: >=20 > " > 3.6. Detecting a Generic Application Level Gateway (ALG) >=20 >=20 > A number of NAT boxes are now being deployed into the market that > try > to provide "generic" ALG functionality. These generic ALGs hunt = for > IP addresses, either in text or binary form within a packet, and > rewrite them if they match a binding. This behavior can be = detected > because the STUN server returns both the MAPPED-ADDRESS and XOR- > MAPPED-ADDRESS in the same response. If the result in the two does > not match, there is a NAT with a generic ALG in the path. This = test > apples to UDP and TCP, but not TLS over TCP connections." >=20 > ? Yes, that is probably the best written description of the behavior of such ALGs. -d > -----Message d'origine----- > De : Dan Wing [mailto:dwing@cisco.com] > Envoy=E9 : vendredi 7 janvier 2011 17:31 > =C0 : BOUCADAIR Mohamed NCPI/NAD/TIP; pcp@ietf.org > Objet : RE: [pcp] XOR IP address in payloads >=20 > > -----Original Message----- > > From: mohamed.boucadair@orange-ftgroup.com > > [mailto:mohamed.boucadair@orange-ftgroup.com] > > Sent: Thursday, January 06, 2011 10:39 PM > > To: Dan Wing; pcp@ietf.org > > Subject: RE: [pcp] XOR IP address in payloads > > > > Hi Dan, all, > > > > What would these ALGs change in the packets: (1) the internal IP > > address of outgoing PCP packets, (2) any occurrence of IP addresses > in > > PCP responses? >=20 > These overzealous ALGs modify UDP packets where the NAT's WAN address > is in the UDP payload on a 32 bit boundary. Very hard to guess how > many of these exist in the wild. >=20 > > If (1), then this is even good because the internal IP address that > > should be maintained by the PCP server is the one used in the > external > > interface of the NAT and not the original IP address set by the PCP > > Client. But still the problem is the port number. In this case, with > or > > without that ALG, a failure will be experienced. I don't see the > added > > value of xoring the IP address for this case. > > > > If (2), I don't really understand why these ALGs do this. >=20 > Like all ALGs, it was done in an attempt to get an application to > work. >=20 > -d >=20 >=20 > > Unless I missed something, I'm not sure there is a justification for > > xoring the IP address in PCP. > > > > Cheers > > Med > > > > -----Message d'origine----- > > De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part = de > > Dan Wing > > Envoy=E9 : jeudi 6 janvier 2011 19:05 > > =C0 : pcp@ietf.org > > Objet : [pcp] XOR IP address in payloads > > > > Both Teredo (*) and STUN (**) XOR IP addresses returned in payloads, > in > > order to avoid interference by overzealous UDP ALG code in some = NATs. > > Do we > > need the same in PCP? (I think we should, even though it slightly > > increases > > implementation complexity.) > > > > (*) http://tools.ietf.org/html/rfc4380#section-4 > > (**) http://tools.ietf.org/html/rfc5389#section-15.2 > > > > -d > > > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp > > > > ********************************* > > This message and any attachments (the "message") are confidential = and > > intended solely for the addressees. > > Any unauthorised use or dissemination is prohibited. > > Messages are susceptible to alteration. > > France Telecom Group shall not be liable for the message if altered, > > changed or falsified. > > If you are not the intended addressee of this message, please cancel > it > > immediately and inform the sender. > > ******************************** >=20 >=20 > ********************************* > This message and any attachments (the "message") are confidential and > intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, > changed or falsified. > If you are not the intended addressee of this message, please cancel = it > immediately and inform the sender. > ******************************** From Francis.Dupont@fdupont.fr Mon Jan 10 14:46: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 328F83A6767 for ; Mon, 10 Jan 2011 14:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 vffSuvFfv9qM for ; Mon, 10 Jan 2011 14:46:27 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 330553A672F for ; Mon, 10 Jan 2011 14:46:27 -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 p0AMmfMb083631; Mon, 10 Jan 2011 22:48:41 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101102248.p0AMmfMb083631@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange-ftgroup.com In-reply-to: Your message of Mon, 10 Jan 2011 10:02:37 +0100. <7726_1294650159_4D2ACB2F_7726_21502_1_94C682931C08B048B7A8645303FDC9F33C3FD7AEA7@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 10 Jan 2011 23:48:41 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "pcp@ietf.org" Subject: Re: [pcp] PCP-base 02: Section 7.7 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, 10 Jan 2011 22:46:28 -0000 In your previous mail you wrote: I re-read section 7.7 of pcp-02 and especially: ... I'm not sure this reflects the opinions that have been expressed in this mailing list about this issue. => I agree: this text was imported directly from base-01 when it was known to be wrong. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Mon Jan 10 14:59: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 ED2B33A6778 for ; Mon, 10 Jan 2011 14:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 5XMJY2aGdzQo for ; Mon, 10 Jan 2011 14:59:40 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id C11073A6403 for ; Mon, 10 Jan 2011 14:59:39 -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 p0AN1rcs084678; Mon, 10 Jan 2011 23:01:53 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101102301.p0AN1rcs084678@givry.fdupont.fr> From: Francis Dupont To: Simon Perreault In-reply-to: Your message of Mon, 10 Jan 2011 08:45:02 EST. <4D2B0D5E.5030302@viagenie.ca> Date: Tue, 11 Jan 2011 00:01:53 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] PCP-base 02: Section 7.7 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, 10 Jan 2011 22:59:42 -0000 In your previous mail you wrote: Note that this was discussed in the virtual interim meeting. I seem to recall the consensus being that the advantage of easy deployment outweighed the disadvantages. => I am afraid this argument would not close the subject... and there was no consensus, just a 'go to next point'. (Were the minutes of the meeting posted?) => +1! Francis.Dupont@fdupont.fr PS: BTW the 'ease of deployment' is not a good argument as it applied only on hosts, not on NATs, when IMHO at least 50% of the deployed base won't support it. From simon.perreault@viagenie.ca Mon Jan 10 15:35: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 AD02C3A67D1 for ; Mon, 10 Jan 2011 15:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 wyArt0G9C+SM for ; Mon, 10 Jan 2011 15:35:40 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id D48763A67AE for ; Mon, 10 Jan 2011 15:35:39 -0800 (PST) Received: from [192.168.1.34] (modemcable037.31-130-66.mc.videotron.ca [66.130.31.37]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2007520D12; Mon, 10 Jan 2011 18:37:54 -0500 (EST) Message-ID: <4D2B984C.5020407@viagenie.ca> Date: Mon, 10 Jan 2011 18:37:48 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Francis Dupont References: <201101102301.p0AN1rcs084678@givry.fdupont.fr> In-Reply-To: <201101102301.p0AN1rcs084678@givry.fdupont.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pcp@ietf.org Subject: Re: [pcp] PCP-base 02: Section 7.7 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, 10 Jan 2011 23:35:40 -0000 Le 10/01/2011 6:01 PM, Francis Dupont a écrit : > PS: BTW the 'ease of deployment' is not a good argument as it applied > only on hosts, not on NATs, when IMHO at least 50% of the deployed > base won't support it. This is the first time I hear this argument. Can you explain why 50% of existing NATs would not support connect-then-keepalive? It would be very unfortunate if we had option A be unimplementable on hosts and option B be unimplementable on NATs... Simon From simon.perreault@viagenie.ca Mon Jan 10 15:36: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 4CB133A67B2 for ; Mon, 10 Jan 2011 15:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 b+DmLemyvJ2n for ; Mon, 10 Jan 2011 15:36:50 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 8BBCB3A67AE for ; Mon, 10 Jan 2011 15:36:50 -0800 (PST) Received: from [192.168.1.34] (modemcable037.31-130-66.mc.videotron.ca [66.130.31.37]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1D22B20D12; Mon, 10 Jan 2011 18:39:05 -0500 (EST) Message-ID: <4D2B9893.2090903@viagenie.ca> Date: Mon, 10 Jan 2011 18:38:59 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Francis Dupont References: <201101102301.p0AN1rcs084678@givry.fdupont.fr> <4D2B984C.5020407@viagenie.ca> In-Reply-To: <4D2B984C.5020407@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pcp@ietf.org Subject: Re: [pcp] PCP-base 02: Section 7.7 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, 10 Jan 2011 23:36:51 -0000 Le 10/01/2011 6:37 PM, Simon Perreault a écrit : > This is the first time I hear this argument. Can you explain why 50% of > existing NATs would not support connect-then-keepalive? I meant connect-then-lifetime... Simon From dwing@cisco.com Mon Jan 10 16:01: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 1602C3A67F4 for ; Mon, 10 Jan 2011 16:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.518 X-Spam-Level: X-Spam-Status: No, score=-110.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 uAcXX+5OdJno for ; Mon, 10 Jan 2011 16:01:00 -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 28C6C3A67E9 for ; Mon, 10 Jan 2011 16:01:00 -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: AgEFAMYsK02rRN+K/2dsb2JhbACXYIxrc6JvmGiFTASEZw Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 11 Jan 2011 00:03:14 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p0B03EnH020656; Tue, 11 Jan 2011 00:03:14 GMT From: "Dan Wing" To: "'Francis Dupont'" , "'Simon Perreault'" , References: Your message of Mon, 10 Jan 2011 08:45:02 EST. <4D2B0D5E.5030302@viagenie.ca> <201101102301.p0AN1rcs084678@givry.fdupont.fr> In-Reply-To: <201101102301.p0AN1rcs084678@givry.fdupont.fr> Date: Mon, 10 Jan 2011 16:03:13 -0800 Message-ID: <19ba01cbb122$f11dfd70$d359f850$@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/oFEq0BUFQIqUfjE7XufIxwABnQoQ Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] PCP-base 02: Section 7.7 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, 11 Jan 2011 00:01:01 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Francis Dupont > Sent: Monday, January 10, 2011 3:02 PM > To: Simon Perreault > Cc: pcp@ietf.org > Subject: Re: [pcp] PCP-base 02: Section 7.7 > > > In your previous mail you wrote: > > Note that this was discussed in the virtual interim meeting. I seem > to > recall the consensus being that the advantage of easy deployment > outweighed the disadvantages. > > => I am afraid this argument would not close the subject... > and there was no consensus, just a 'go to next point'. > > (Were the minutes of the meeting posted?) > > => +1! > > Francis.Dupont@fdupont.fr > > PS: BTW the 'ease of deployment' is not a good argument as it applied > only on hosts, not on NATs, when IMHO at least 50% of the deployed > base won't support it. For reference, this is Issue #17, http://trac.tools.ietf.org/wg/pcp/trac/ticket/17 In the post http://www.ietf.org/mail-archive/web/pcp/current/msg00474.html, Simon described the host implementation difficulty. This got agreement from Dave Thaler, http://www.ietf.org/mail-archive/web/pcp/current/msg00475.html and Lars Eggert, http://www.ietf.org/mail-archive/web/pcp/current/msg00480.html. I do not find a post that describes the NAT implementation difficulty. I found posts that suggest NATs want to have different port ranges for PCP-controlled ports than for dynamically-created connections. That's makes some sense when the user is operating a server. But I don't understand how separate NAT port ranges are helpful/necessary for the application keepalives case. If this does help the NAT, it seems we will need to force (MUST) the hosts to allocate a source port in the non-ephemeral port range and follow the other steps described in http://www.ietf.org/mail-archive/web/pcp/current/msg00474.html. -d From mohamed.boucadair@orange-ftgroup.com Mon Jan 10 22:53: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 7203A3A69B6 for ; Mon, 10 Jan 2011 22:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.184 X-Spam-Level: X-Spam-Status: No, score=-3.184 tagged_above=-999 required=5 tests=[AWL=0.064, 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 LUWyaslRTrcI for ; Mon, 10 Jan 2011 22:53:14 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id B7EFB3A69B2 for ; Mon, 10 Jan 2011 22:53:13 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 7C61C22C2B7; Tue, 11 Jan 2011 07:55:28 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 624C44C013; Tue, 11 Jan 2011 07:55:28 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 11 Jan 2011 07:55:27 +0100 From: To: Dan Wing , 'Francis Dupont' , 'Simon Perreault' Date: Tue, 11 Jan 2011 07:55:26 +0100 Thread-Topic: [pcp] PCP-base 02: Section 7.7 Thread-Index: AcuxGnH/oFEq0BUFQIqUfjE7XufIxwABnQoQAA6BC4A= Message-ID: <837_1294728928_4D2BFEE0_837_116100_1_94C682931C08B048B7A8645303FDC9F33C3FD7B3C4@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Mon, 10 Jan 2011 08:45:02 EST. <4D2B0D5E.5030302@viagenie.ca> <201101102301.p0AN1rcs084678@givry.fdupont.fr> <19ba01cbb122$f11dfd70$d359f850$@com> In-Reply-To: <19ba01cbb122$f11dfd70$d359f850$@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.1.11.55414 Cc: "pcp@ietf.org" Subject: Re: [pcp] PCP-base 02: Section 7.7 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, 11 Jan 2011 06:53:15 -0000 Hi Dan, As a reminder, I have enumerated a set of advantages of implementing what w= as called option 2 (http://www.ietf.org/mail-archive/web/pcp/current/msg004= 83.html). In http://www.ietf.org/mail-archive/web/pcp/current/msg00487.html, I tried = to explain that implementing option 1 may not reduce keepalives in some con= texts since the refresh interval is forced by the server and not by the cli= ent (see SIP example for instance). Cheers, Med=20 -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : mardi 11 janvier 2011 01:03 =C0 : 'Francis Dupont'; 'Simon Perreault'; BOUCADAIR Mohamed OLNC/NAD/TIP Cc : pcp@ietf.org Objet : RE: [pcp] PCP-base 02: Section 7.7 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Francis Dupont > Sent: Monday, January 10, 2011 3:02 PM > To: Simon Perreault > Cc: pcp@ietf.org > Subject: Re: [pcp] PCP-base 02: Section 7.7 >=20 >=20 > In your previous mail you wrote: >=20 > Note that this was discussed in the virtual interim meeting. I seem > to > recall the consensus being that the advantage of easy deployment > outweighed the disadvantages. >=20 > =3D> I am afraid this argument would not close the subject... > and there was no consensus, just a 'go to next point'. >=20 > (Were the minutes of the meeting posted?) > > =3D> +1! >=20 > Francis.Dupont@fdupont.fr >=20 > PS: BTW the 'ease of deployment' is not a good argument as it applied > only on hosts, not on NATs, when IMHO at least 50% of the deployed > base won't support it. For reference, this is Issue #17, http://trac.tools.ietf.org/wg/pcp/trac/ticket/17 In the post http://www.ietf.org/mail-archive/web/pcp/current/msg00474.html, Simon described the host implementation difficulty. This got agreement from Dave Thaler, http://www.ietf.org/mail-archive/web/pcp/current/msg00475.html and Lars Eggert, http://www.ietf.org/mail-archive/web/pcp/current/msg00480.html. I do not find a post that describes the NAT implementation difficulty.=20= =20 I found posts that suggest NATs want to have different port ranges for PCP-controlled ports than for dynamically-created connections. That's makes some sense when the user is operating a server. But I don't understand how separate NAT port ranges are helpful/necessary for the application keepalives case.=20=20 If this does help the NAT, it seems we will need to force (MUST) the hosts to allocate a source port in the non-ephemeral port range and follow the other steps described in http://www.ietf.org/mail-archive/web/pcp/current/msg00474.html.=20=20 -d ********************************* 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 xiaohong.deng@orange-ftgroup.com Tue Jan 11 02:14: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 154F33A6A2F for ; Tue, 11 Jan 2011 02:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[AWL=0.558, 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 wN2pVpGiL9c9 for ; Tue, 11 Jan 2011 02:14:17 -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 038DB3A6A21 for ; Tue, 11 Jan 2011 02:14:17 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 38817760004; Tue, 11 Jan 2011 11:21:08 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 30525760002; Tue, 11 Jan 2011 11:21:08 +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, 11 Jan 2011 11:16:33 +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, 11 Jan 2011 18:16:29 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0148085A@ch-mailsrv.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Does nested NAT apply NAT/ALG on PCP packet? Thread-Index: AcuuRPpteKUCElDAQzOIykKRApLmGwADtK0QAA1XxlAAhdQEEAAz3FJw References: Your message of Fri, 07 Jan 2011 14:23:39 +0800. <0962B0BEF842A24191AD9BE41A8DD2FC0143B516@ch-mailsrv.rd.francetelecom.fr> <201101070828.p078Sg2e067840@givry.fdupont.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0143B671@ch-mailsrv.rd.francetelecom.fr> <11b601cbae92$3bbc8560$b3359020$@com> From: To: , X-OriginalArrivalTime: 11 Jan 2011 10:16:33.0063 (UTC) FILETIME=[9EEBB370:01CBB178] Cc: pcp@ietf.org, lan.wang@orange-ftgroup.com Subject: [pcp] Does nested NAT apply NAT/ALG on PCP packet? 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, 11 Jan 2011 10:14:18 -0000 Sorry I was talking about an interim NAT which does not support PCP.=20 You're referring to the nested NAT case, where the intermediate NAT acts like both PCP Client and PCP server. However, IMHO, it's unlike STUN case; because the destination of the STUN response is the internal host's transport address therefore the intermediate NAT should forward it and applies NAT/ALG on it. But in case of PCP response, the PCP response from the upstream PCP server is sent to the PCP port of the intermediate NAT so that the intermediate NAT will *not* perform NAT/ALG on it. Instead, to my understanding, the intermediate NAT works like a PCP proxy and there will be no NAT/ALG issues. Please anybody tell me if I understood wrong. BR, Xiaohong | ||That PCP response contains the NAT-1's public IP address, in the=20 ||existing internal-ip-address field of the PIN* response packet format. | |I wonder how PCP response could contain the NAT-1's public IP=20 |address in the existing internal-ip-address. | |Do you mean NAT-1's ALG has already modified the PCP request=20 |when it passed through NAT-1? But even if these overzealous=20 |ALGs modify UDP packets where the NAT's WAN address is in the=20 |UDP payload on a 32 bit boundary, I can't see a reason for=20 |NAT-1's ALG to modify PCP request's internal-ip-address, as=20 |NAT-1's WAN addresses does *not* present in the original=20 |payload of PCP request, which was sent by host. | |I missed something? | ||Teredo and STUN experience says that some NATs will modify=20 |the PCP UDP=20 ||payload. || | |BR, |Xiaohong From roberta.maglione@telecomitalia.it Tue Jan 11 03:06: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 DCB6428C26E for ; Tue, 11 Jan 2011 03:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.117 X-Spam-Level: X-Spam-Status: No, score=0.117 tagged_above=-999 required=5 tests=[AWL=0.835, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=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 NhBkY9OvXWxK for ; Tue, 11 Jan 2011 03:06:40 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id 23D4C28C11B for ; Tue, 11 Jan 2011 03:06:40 -0800 (PST) Content-Type: multipart/mixed; boundary="_e2c956ea-25bf-49be-8c3f-61825848e7b1_" Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 11 Jan 2011 12:08:55 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Tue, 11 Jan 2011 12:08:55 +0100 From: Maglione Roberta To: "'mohamed.boucadair@orange-ftgroup.com'" Date: Tue, 11 Jan 2011 12:08:51 +0100 Thread-Topic: PCP DHCP/DHCPv6 options Thread-Index: AcuuPA8KHu7j1puoTIWKnx6CefvjuADQoXdw Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB1061623@GRFMBX704BA020.griffon.local> References: <9922_1294385130_4D26BFEA_9922_238708_1_94C682931C08B048B7A8645303FDC9F33C3E9FE004@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <9922_1294385130_4D26BFEA_9922_238708_1_94C682931C08B048B7A8645303FDC9F33C3E9FE004@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT MIME-Version: 1.0 Cc: "'pcp@ietf.org'" Subject: Re: [pcp] PCP DHCP/DHCPv6 options 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, 11 Jan 2011 11:06:42 -0000 --_e2c956ea-25bf-49be-8c3f-61825848e7b1_ Content-Type: multipart/alternative; boundary="_000_282BBE8A501E1F4DA9C775F964BB21FE3EB1061623GRFMBX704BA02_" --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB1061623GRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, I read the new version of draft, it looks good with me. I support the choice of keeping just the FQDN DHCP option, based on the con= clusion reached on a similar topic for DSLite. I have a question on the FDQN encoding: - for DHCPv6 in section 5.1 you refer to RFC 3315 section 8 that in turn th= en refers to RFC1035 for the Domain Name encoding - while for DHCPv4 in section 6 you refer to RFC2131, but actually this RFC= does not explicitly specify any Domain Name encoding, it just refers to RF= C 1035 in section 1.3 Would not be enough referring to RFC1035 for both DHCPv6 and DHCPv4 case? Best regards, Roberta ________________________________ From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of moham= ed.boucadair@orange-ftgroup.com Sent: venerd=EC 7 gennaio 2011 8.25 To: pcp@ietf.org Subject: [pcp] PCP DHCP/DHCPv6 options Dear all, A new updated version of the PCP DHCP/DHCPv6 options draft has be submitted= . The I-D is available at: http://www.ietf.org/id/draft-bpw-pcp-dhcp-01.txt Comments and inputs are welcome. Cheers, Med ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. 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. ******************************** Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000001@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_282BBE8A501E1F4DA9C775F964BB21FE3EB1061623GRFMBX704BA02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

   I read the new version of= draft, it looks good with me.

I support the choice of keeping just t= he FQDN DHCP option, based on the conclusion reached on a similar topic for= DSLite.

 

I have a question on the FDQN encoding= :

- for DHCPv6 in section 5.1 you refer = to RFC 3315 section 8 that in turn then refers to RFC1035 for the Domain Na= me encoding

- while for DHCPv4 in section 6 you re= fer to RFC2131, but actually this RFC does not explicitly specify any Domai= n Name encoding, it just refers to RFC 1035 in section 1.3

Would not be enough referring to RFC10= 35 for both DHCPv6 and DHCPv4 case?

 

Best regards,=

Roberta

 

 

From: pcp-= bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange-ftgroup.com
Sent: venerd=EC 7 gennaio 20= 11 8.25
To: pcp@ietf.org
Subject: [pcp] PCP DHCP/DHCP= v6 options

 

Dear all,

 

A new updated version of the PCP DHCP/= DHCPv6 options draft has be submitted. The I-D is available at: http://www.iet= f.org/id/draft-bpw-pcp-dhcp-01.txt

 

Comments and inputs are welcome.

 

Cheers,

Med

*********************************
This message and any attachments (the "message") are confidentia=
l and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, chang=
ed or falsified.
If you are not the intended addressee of this message, please cancel it im=
mediately and inform the sender.
********************************
= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_282BBE8A501E1F4DA9C775F964BB21FE3EB1061623GRFMBX704BA02_-- --_e2c956ea-25bf-49be-8c3f-61825848e7b1_ Content-Description: logo Ambiente_foglia.jpg Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Disposition: inline; filename="logo Ambiente_foglia.jpg" Content-Transfer-Encoding: base64 Content-ID: 00000000000000000000000000000001@TI.Disclaimer R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_e2c956ea-25bf-49be-8c3f-61825848e7b1_-- From mohamed.boucadair@orange-ftgroup.com Tue Jan 11 04:26: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 A426128C11E for ; Tue, 11 Jan 2011 04:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 ZORUtVHo5B9N for ; Tue, 11 Jan 2011 04:26:50 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id E0DCE28C0EE for ; Tue, 11 Jan 2011 04:26:49 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 3665A374444; Tue, 11 Jan 2011 13:29:05 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 1B2F538403C; Tue, 11 Jan 2011 13:29:05 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Tue, 11 Jan 2011 13:29:04 +0100 From: To: Maglione Roberta Date: Tue, 11 Jan 2011 13:29:03 +0100 Thread-Topic: PCP DHCP/DHCPv6 options Thread-Index: AcuuPA8KHu7j1puoTIWKnx6CefvjuADQoXdwAAKcOQA= Message-ID: <22350_1294748945_4D2C4D11_22350_52927_1_94C682931C08B048B7A8645303FDC9F33C3FD7B64C@PUEXCB1B.nanterre.francetelecom.fr> References: <9922_1294385130_4D26BFEA_9922_238708_1_94C682931C08B048B7A8645303FDC9F33C3E9FE004@PUEXCB1B.nanterre.francetelecom.fr> <282BBE8A501E1F4DA9C775F964BB21FE3EB1061623@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EB1061623@GRFMBX704BA020.griffon.local> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/related; boundary="_004_94C682931C08B048B7A8645303FDC9F33C3FD7B64CPUEXCB1Bnante_"; type="multipart/alternative" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.1.11.114515 Cc: "'pcp@ietf.org'" Subject: Re: [pcp] PCP DHCP/DHCPv6 options 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, 11 Jan 2011 12:26:51 -0000 --_004_94C682931C08B048B7A8645303FDC9F33C3FD7B64CPUEXCB1Bnante_ Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33C3FD7B64CPUEXCB1Bnante_" --_000_94C682931C08B048B7A8645303FDC9F33C3FD7B64CPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Roberta, Thank you for your feedback. In the introduction, the I-D is referring to Section 3.1 of RFC1035; in par= ticular: " This document defines DHCP [RFC2131] and DHCPv6 [RFC3315] options which can be used to provision a PCP Server [I-D.ietf-pcp-base] reachability information; more precisely it defines DHCP options to convey a FQDN (as per Section 3.1 of [RFC1035]) of a PCP Server. In order to make use of these options, this document assumes that a DNS server is configured on the host client by DHCP or other means." But when defining DHCPv6 option, I avoided to refer to RFC1035 but to Secti= on 8 of RFC3315 because compression as per Section 4.1.4 of RFC1035 is not allowed. For the DHCP option, your comment is valid. I will replace the RFC2131 refe= rence with RFC1035. Please let me know if this is ok with you. Cheers, Med ________________________________ De : Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] Envoy=E9 : mardi 11 janvier 2011 12:09 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : 'pcp@ietf.org' Objet : RE: PCP DHCP/DHCPv6 options Hi Med, I read the new version of draft, it looks good with me. I support the choice of keeping just the FQDN DHCP option, based on the con= clusion reached on a similar topic for DSLite. I have a question on the FDQN encoding: - for DHCPv6 in section 5.1 you refer to RFC 3315 section 8 that in turn th= en refers to RFC1035 for the Domain Name encoding - while for DHCPv4 in section 6 you refer to RFC2131, but actually this RFC= does not explicitly specify any Domain Name encoding, it just refers to RF= C 1035 in section 1.3 Would not be enough referring to RFC1035 for both DHCPv6 and DHCPv4 case? Best regards, Roberta ________________________________ From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of moham= ed.boucadair@orange-ftgroup.com Sent: venerd=EC 7 gennaio 2011 8.25 To: pcp@ietf.org Subject: [pcp] PCP DHCP/DHCPv6 options Dear all, A new updated version of the PCP DHCP/DHCPv6 options draft has be submitted= . The I-D is available at: http://www.ietf.org/id/draft-bpw-pcp-dhcp-01.txt Comments and inputs are welcome. Cheers, Med ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. 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. ******************************** Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:635571312@11012011-14ED]Rispetta l'ambiente. Non stampare questa mail = se non =E8 necessario. ********************************* 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. ******************************** --_000_94C682931C08B048B7A8645303FDC9F33C3FD7B64CPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Roberta,
 
Thank you for your feedback.
 
In the introduction, the I-D is referring to Secti= on 3.1 of=20 RFC1035; in particular:
 
"  This document defines DHC=
P [RFC2131] and DHCPv6 [RFC3315] options
   which can be used to provision a PCP Server [I-D.ietf-pcp-base]
   reachability information; more precisely it defines DHCP options to
   convey a FQDN (as per Section 3.1 of [RFC1035]) of a PCP Server.  In
   order to make use of these options, this document assumes that a DNS
   server is configured on the host client by DHCP or other means."
 
But when defining DHCPv6 option, I avoided to refer to =
RFC1035 but to Section 8 of RFC3315 because compression
as per Se=
ction 4.1.4 of RFC1035 is not allowed.
 
For the D=
HCP option, your comment is valid. I will replace the RFC2131 reference wit=
h RFC1035.
 
Please let me know if this is ok with=
 you.
 
Cheers,
Med
<= /DIV>
De : Maglione Roberta=20 [mailto:roberta.maglione@telecomitalia.it]
Envoy=E9 : mardi= 11=20 janvier 2011 12:09
=C0 : BOUCADAIR Mohamed=20 OLNC/NAD/TIP
Cc : 'pcp@ietf.org'
Objet : RE: = PCP=20 DHCP/DHCPv6 options

Hi=20 Med,

   I r= ead the=20 new version of draft, it looks good with me.

I support the ch= oice of=20 keeping just the FQDN DHCP option, based on the conclusion reached on a sim= ilar=20 topic for DSLite.

 

I have a questio= n on=20 the FDQN encoding:

- for DHCPv6 in = section=20 5.1 you refer to RFC 3315 section 8 that in turn then refers to RFC1035 for= the=20 Domain Name encoding

- while for DHCP= v4 in=20 section 6 you refer to RFC2131, but actually this RFC does not explicitly= =20 specify any Domain Name encoding, it just refers to RFC 1035 in section 1.3= =20

Would not be eno= ugh=20 referring to RFC1035 for both DHCPv6 and DHCPv4=20 case?

 

Best=20 regards,

Roberta

 

 

From:=20 pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of=20 mohamed.boucadair@orange-ftgroup.com
Sent: venerd=EC 7 gennaio 2011=20 8.25
To:=20 pcp@ietf.org
Subject: [p= cp] PCP=20 DHCP/DHCPv6 options

 

Dear=20 all,

 

A new updated version= of the=20 PCP DHCP/DHCPv6 options draft has be submitted. The I-D is availa= ble=20 at: http://www.ietf.o= rg/id/draft-bpw-pcp-dhcp-01.txt

 

Comments and inputs a= re=20 welcome.

 

Cheers,=

Med

*********************************
Any unauthori=
sed use or dissemination is prohibited.
=
Message=
s are susceptible to alteration. 
France Teleco=
m Group shall not be liable for the message if altered, changed or falsifie=
d.
<=
SPAN style=3D"FONT-SIZE: 10pt">If you are not the intended addressee of thi=
s message, please cancel it immediately and inform the sender.
********************************
Questo messaggio e i= suoi=20 allegati sono indirizzati esclusivamente alle persone indicate. La=20 diffusione, copia o qualsiasi altra azione derivante dalla conoscenza= di=20 queste informazioni sono rigorosamente vietate. Qualora abbiate ricev= uto=20 questo documento per errore siete cortesemente pregati di darne immed= iata=20 comunicazione al mittente e di provvedere alla sua distruzione, Grazi= e.=20

This=20 e-mail and any attachments is confidential=20 and may contain privileged information intended for the addressee(s) = only.=20 Dissemination, copying, printing or use by anybody else is unauthoris= ed.=20 If you are not the intended recipient, please delete this message and= any=20 attachments and advise the sender by return e-mail,=20 Thanks.=20

3D"rispettaRispetta l'ambiente. Non stampare questa mail se non =E8= =20 necessario.=20 

*******************************=
**
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.
********************************
--_000_94C682931C08B048B7A8645303FDC9F33C3FD7B64CPUEXCB1Bnante_-- --_004_94C682931C08B048B7A8645303FDC9F33C3FD7B64CPUEXCB1Bnante_ Content-Type: image/jpeg; name="logo Ambiente_foglia.jpg" Content-Description: logo Ambiente_foglia.jpg Content-Disposition: inline; filename="logo Ambiente_foglia.jpg"; size=677; creation-date="Tue, 11 Jan 2011 13:29:04 GMT"; modification-date="Tue, 11 Jan 2011 13:29:04 GMT" Content-ID: <635571312@11012011-14ED> Content-Transfer-Encoding: base64 R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_004_94C682931C08B048B7A8645303FDC9F33C3FD7B64CPUEXCB1Bnante_-- From roberta.maglione@telecomitalia.it Tue Jan 11 05:10: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 7199628C299 for ; Tue, 11 Jan 2011 05:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 U5E7mTSUY8Y6 for ; Tue, 11 Jan 2011 05:10:24 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id E64E628C28D for ; Tue, 11 Jan 2011 05:10:23 -0800 (PST) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 11 Jan 2011 14:12:39 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Tue, 11 Jan 2011 14:12:39 +0100 From: Maglione Roberta To: "'mohamed.boucadair@orange-ftgroup.com'" Date: Tue, 11 Jan 2011 14:12:35 +0100 Thread-Topic: PCP DHCP/DHCPv6 options Thread-Index: AcuuPA8KHu7j1puoTIWKnx6CefvjuADQoXdwAAKcOQAAAe15cA== Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB1061701@GRFMBX704BA020.griffon.local> References: <9922_1294385130_4D26BFEA_9922_238708_1_94C682931C08B048B7A8645303FDC9F33C3E9FE004@PUEXCB1B.nanterre.francetelecom.fr> <282BBE8A501E1F4DA9C775F964BB21FE3EB1061623@GRFMBX704BA020.griffon.local> <22350_1294748945_4D2C4D11_22350_52927_1_94C682931C08B048B7A8645303FDC9F33C3FD7B64C@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <22350_1294748945_4D2C4D11_22350_52927_1_94C682931C08B048B7A8645303FDC9F33C3FD7B64C@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'pcp@ietf.org'" Subject: Re: [pcp] PCP DHCP/DHCPv6 options 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, 11 Jan 2011 13:10:25 -0000 Hi Med, That's ok with me. Thanks Best regards, Roberta ________________________________________ From: mohamed.boucadair@orange-ftgroup.com [mailto:mohamed.boucadair@orange= -ftgroup.com] Sent: marted=EC 11 gennaio 2011 13.29 To: Maglione Roberta Cc: 'pcp@ietf.org' Subject: RE: PCP DHCP/DHCPv6 options Dear Roberta, Thank you for your feedback. In the introduction, the I-D is referring to Section 3.1 of RFC1035; in par= ticular: " This document defines DHCP [RFC2131] and DHCPv6 [RFC3315] options which can be used to provision a PCP Server [I-D.ietf-pcp-base] reachability information; more precisely it defines DHCP options to convey a FQDN (as per Section 3.1 of [RFC1035]) of a PCP Server. In order to make use of these options, this document assumes that a DNS server is configured on the host client by DHCP or other means." But when defining DHCPv6 option, I avoided to refer to RFC1035 but to Secti= on 8 of RFC3315 because compression as per Section 4.1.4 of RFC1035 is not allowed. For the DHCP option, your comment is valid. I will replace the RFC2131 refe= rence with RFC1035. Please let me know if this is ok with you. Cheers, Med ________________________________________ De : Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] Envoy=E9 : mardi 11 janvier 2011 12:09 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : 'pcp@ietf.org' Objet : RE: PCP DHCP/DHCPv6 options Hi Med, I read the new version of draft, it looks good with me. I support the choice of keeping just the FQDN DHCP option, based on the con= clusion reached on a similar topic for DSLite. I have a question on the FDQN encoding: - for DHCPv6 in section 5.1 you refer to RFC 3315 section 8 that in turn th= en refers to RFC1035 for the Domain Name encoding - while for DHCPv4 in section 6 you refer to RFC2131, but actually this RFC= does not explicitly specify any Domain Name encoding, it just refers to RF= C 1035 in section 1.3 Would not be enough referring to RFC1035 for both DHCPv6 and DHCPv4 case? Best regards, Roberta ________________________________________ From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of moham= ed.boucadair@orange-ftgroup.com Sent: venerd=EC 7 gennaio 2011 8.25 To: pcp@ietf.org Subject: [pcp] PCP DHCP/DHCPv6 options Dear all, A new updated version of the PCP DHCP/DHCPv6 options draft has be submitted= . The I-D is available at: http://www.ietf.org/id/draft-bpw-pcp-dhcp-01.txt Comments and inputs are welcome. Cheers, Med ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. 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. ******************************** Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. 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. ******************************** Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From dwing@cisco.com Tue Jan 11 09:30:10 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 B8BB33A6A3F for ; Tue, 11 Jan 2011 09:30:10 -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 12QfdHdetgqt for ; Tue, 11 Jan 2011 09:30: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 DB2EB3A69D3 for ; Tue, 11 Jan 2011 09:30:08 -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: Av0EAN8iLE1AaMHG/2dsb2JhbACXTYxsc6NhmHCFTASEaA Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 11 Jan 2011 17:32:24 +0000 Received: from dwingWS ([10.32.240.194]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0BHW6GX006883; Tue, 11 Jan 2011 17:32:16 GMT From: "Dan Wing" To: , References: Your message of Fri, 07 Jan 2011 14:23:39 +0800. <0962B0BEF842A24191AD9BE41A8DD2FC0143B516@ch-mailsrv.rd.francetelecom.fr> <201101070828.p078Sg2e067840@givry.fdupont.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0143B671@ch-mailsrv.rd.francetelecom.fr> <11b601cbae92$3bbc8560$b3359020$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0148085A@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC0148085A@ch-mailsrv.rd.francetelecom.fr> Date: Tue, 11 Jan 2011 09:32:16 -0800 Message-ID: <1d7f01cbb1b5$7e38ce00$7aaa6a00$@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: AcuuRPpteKUCElDAQzOIykKRApLmGwADtK0QAA1XxlAAhdQEEAAz3FJwABESdLA= Content-Language: en-us Cc: pcp@ietf.org, lan.wang@orange-ftgroup.com Subject: Re: [pcp] Does nested NAT apply NAT/ALG on PCP packet? 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, 11 Jan 2011 17:30:11 -0000 > -----Original Message----- > From: xiaohong.deng@orange-ftgroup.com [mailto:xiaohong.deng@orange- > ftgroup.com] > Sent: Tuesday, January 11, 2011 2:16 AM > To: dwing@cisco.com; Francis.Dupont@fdupont.fr > Cc: simon.perreault@viagenie.ca; pcp@ietf.org; lan.wang@orange- > ftgroup.com > Subject: Does nested NAT apply NAT/ALG on PCP packet? > > Sorry I was talking about an interim NAT which does not support PCP. > > You're referring to the nested NAT case, where the intermediate NAT > acts > like both PCP Client and PCP server. However, IMHO, it's unlike STUN > case; because the destination of the STUN response is the internal > host's transport address therefore the intermediate NAT should forward > it and applies NAT/ALG on it. But in case of PCP response, the PCP > response from the upstream PCP server is sent to the PCP port of the > intermediate NAT so that the intermediate NAT will *not* perform > NAT/ALG > on it. Instead, to my understanding, the intermediate NAT works like a > PCP proxy and there will be no NAT/ALG issues. Please anybody tell me > if > I understood wrong. For the nested NAT case, I am _not_ talking about a NAT that supports PCP at all. ftp://ftp-eng.cisco.com/dwing/pcp/pcp-nested-nat.pdf and my earlier email " PCP and nested NAPT" http://www.ietf.org/mail-archive/web/pcp/current/msg00654.html stated two goals: 1. Work over one existing NAPT in people's homes 2. Detect multiple existing NAPTs Regarding (1), existing NAPT devices, as we all know, do not implement PCP. Existing NAPT devices are devices that users have purchased at the local computer store and will continue to purchase at the local computer store for years and years in the future. Maybe, at some point, PCP proxying will become a ubiquitous feature. But I was not attempting to initiate a thread on NATs that do PCP proxying. I believe we all know how PCP proxying would work. If there is a disagreement about the two goals, let's talk about the disagreement with those goals. We cannot talk about bits and bytes on the wire without first agreeing on the goal. -d > BR, > Xiaohong > > | > ||That PCP response contains the NAT-1's public IP address, in the > ||existing internal-ip-address field of the PIN* response packet > format. > | > |I wonder how PCP response could contain the NAT-1's public IP > |address in the existing internal-ip-address. > | > |Do you mean NAT-1's ALG has already modified the PCP request > |when it passed through NAT-1? But even if these overzealous > |ALGs modify UDP packets where the NAT's WAN address is in the > |UDP payload on a 32 bit boundary, I can't see a reason for > |NAT-1's ALG to modify PCP request's internal-ip-address, as > |NAT-1's WAN addresses does *not* present in the original > |payload of PCP request, which was sent by host. > | > |I missed something? > | > ||Teredo and STUN experience says that some NATs will modify > |the PCP UDP > ||payload. > || > | > |BR, > |Xiaohong From dwing@cisco.com Tue Jan 11 09:30: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 6333428C28A for ; Tue, 11 Jan 2011 09:30: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 2WdtB+SLpHR2 for ; Tue, 11 Jan 2011 09:30:13 -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 3C7BC28C290 for ; Tue, 11 Jan 2011 09:30:13 -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: AsIGAKIiLE1AaMHG/2dsb2JhbACWKIEljGxzo16YcIVMBIRo Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 11 Jan 2011 17:32:16 +0000 Received: from dwingWS ([10.32.240.194]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0BHW6GW006883; Tue, 11 Jan 2011 17:32:06 GMT From: "Dan Wing" To: References: Your message of Fri, 07 Jan 2011 09:42:51 PST. <11b701cbae92$4e5395b0$eafac110$@com> <201101080111.p081B0uF028999@givry.fdupont.fr> In-Reply-To: <201101080111.p081B0uF028999@givry.fdupont.fr> Date: Tue, 11 Jan 2011 09:32:05 -0800 Message-ID: <1d7e01cbb1b5$77f12380$67d36a80$@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: Acuu0P62CAnMNV6+Sj6n2PC5HEzxSwC5AqJQ Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] PCP and nested NAPT 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, 11 Jan 2011 17:30:14 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Friday, January 07, 2011 5:11 PM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] PCP and nested NAPT > > > In your previous mail you wrote: > > To achieve this, I believe we need three things: > > 1. IANA-registered PCP server address > > => I can't see why. > > 2. UPnP IGD running on existing NAPT > - Rumor says ~25% of NAPTsrun UPnP IGD > > => in general you need a pcp (lower case) for each NAT on > the path, both to run PCP through them and to build > port forwarding entries from the Internet to hosts. You appear to be disagreeing with the two goals I described in my initial post, which are: 1. Work over one existing NAPT in people's homes 2. Detect multiple existing NAPTs Of course, as we can all agree, existing NAPTs do not implement PCP. My goal is to work with those NAPT devices where we can, and detect them and allow PCP to fail gracefully where we cannot. Because of that disagreement, it is natural there is disagreement with the technical solution that I proposed in ftp://ftp-eng.cisco.com/dwing/pcp/pcp-nested-nat.pdf. -d > 3. New PCP Option to indicate source address > - To detect the 3 NAPT situation > > => this is NAT detection and IMHO it should be done > by the PCP server with source address and port. > Wild ALG detection too should be fine. > > Regards > > Francis.Dupont@fdupont.fr From dwing@cisco.com Tue Jan 11 09:32: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 E35D428C282 for ; Tue, 11 Jan 2011 09:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.531 X-Spam-Level: X-Spam-Status: No, score=-110.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 BAyEmUKnT7TJ for ; Tue, 11 Jan 2011 09:32: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 A5B1828C273 for ; Tue, 11 Jan 2011 09:32: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: Av0EAM8jLE2rR7H+/2dsb2JhbACXTYxsc6NhmHCFTASEaA Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 11 Jan 2011 17:35:02 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0BHZ2s8002248; Tue, 11 Jan 2011 17:35:02 GMT From: "Dan Wing" To: , "'Francis Dupont'" , "'Simon Perreault'" References: Your message of Mon, 10 Jan 2011 08:45:02 EST. <4D2B0D5E.5030302@viagenie.ca> <201101102301.p0AN1rcs084678@givry.fdupont.fr> <19ba01cbb122$f11dfd70$d359f850$@com> <837_1294728928_4D2BFEE0_837_116100_1_94C682931C08B048B7A8645303FDC9F33C3FD7B3C4@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <837_1294728928_4D2BFEE0_837_116100_1_94C682931C08B048B7A8645303FDC9F33C3FD7B3C4@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 11 Jan 2011 09:35:02 -0800 Message-ID: <1d8901cbb1b5$e093ca50$a1bb5ef0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuxGnH/oFEq0BUFQIqUfjE7XufIxwABnQoQAA6BC4AAFMrhsA== Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] PCP-base 02: Section 7.7 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, 11 Jan 2011 17:32:47 -0000 > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Monday, January 10, 2011 10:55 PM > To: Dan Wing; 'Francis Dupont'; 'Simon Perreault' > Cc: pcp@ietf.org > Subject: RE: [pcp] PCP-base 02: Section 7.7 >=20 > Hi Dan, >=20 > As a reminder, I have enumerated a set of advantages of implementing > what was called option 2 (http://www.ietf.org/mail- > archive/web/pcp/current/msg00483.html). >=20 > In http://www.ietf.org/mail-archive/web/pcp/current/msg00487.html, I > tried to explain that implementing option 1 may not reduce keepalives > in some contexts since the refresh interval is forced by the server = and > not by the client (see SIP example for instance). Thanks for the pointers. The first URL says: > I don't know how we can forbid applications to use option 2 > which is the obvious one to avoid overloading service > elements with keepalive messages! > > As a concrete example: In the current VoIP deployments SBC > or P-CSCF forces the SIP User Agent to send frequent > REGISTER messages (setting a small value of expire timer); > these messages are not forwarded to the core service > elements. The main purpose is to maintain the NAT binding > in case a NAT is traversed alive. Both the NAT and SBC are > overloaded with these keepalive messages. For the NAT side > this may not be an issue when the NAT is embedded in the > CPE but this may be become sensitive for the CGN case. > > If PCP is used to instruct a mapping before issuing the > REGISTER message: (1) the CGN is not overloaded, (2) > service contact point is not overloaded, (3) the client can > use the external IP address/port to build its application > messages (e.g., SIP) and thus no need to implement extra > function in the service side (e.g., SBC) or in the CGN > (e.g., SIP ALG), (4) the service elements can detect the > present of non-transparent NAT by comparing the content of > the message with the source IP/port information, (5) the > client is aware of the lifetime of the mapping in the CGN > which important to avoid sending aggressive keeplines > (e.g., 20s for Ipsec clients), etc. and the second URL reinforces that connect-then-lifetime does not have property (3). Here is how I see property (3) implemented when doing = connect-then-lifetime, following the REGISTER procedure described at http://tools.ietf.org/html/draft-ietf-sipping-nat-scenarios-13#page-16 SIP UA PCP server SIP proxy | | | |--SIP REGISTER, rport------------------------->| |<-Ok, port=3D12345-------------------------------| | | | |-PIN44, REMOTE_PEER=3D->| | |<--lifetime=3D3600, ext-port=3D12345-| | | | | What is the disadvantage of reducing SIP keepalives that way? For RTP, message flow would be like this, again doing = connect-then-lifetime. The difference is we don't get anything like an "rport=3DNNN" from the = remote peer. But, we don't need it anyway except to detect a rogue NAT on the = path between the PCP-controlled NAT and the RTP peer. If the SIP UA wanted = to detect such a rogue NAT, it would need to send ICE (STUN) messages to = the RTP peer. SIP UA PCP server RTP peer | | | |--RTP message--------------------------------->| |--RTP message--------------------------------->| |--... more RTP messages ...------------------->| |--RTP message--------------------------------->| | | | |-PIN44, REMOTE_PEER=3D=3D->| | |<--lifetime=3D3600, ext-port=3D12345-| | | | | As with SIP, the SIP UA does not need to be in a hurry to communicate = with the PCP server. -d > Cheers, > Med >=20 > -----Message d'origine----- > De : Dan Wing [mailto:dwing@cisco.com] > Envoy=E9 : mardi 11 janvier 2011 01:03 > =C0 : 'Francis Dupont'; 'Simon Perreault'; BOUCADAIR Mohamed = OLNC/NAD/TIP > Cc : pcp@ietf.org > Objet : RE: [pcp] PCP-base 02: Section 7.7 >=20 >=20 >=20 > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf = Of > > Francis Dupont > > Sent: Monday, January 10, 2011 3:02 PM > > To: Simon Perreault > > Cc: pcp@ietf.org > > Subject: Re: [pcp] PCP-base 02: Section 7.7 > > > > > > In your previous mail you wrote: > > > > Note that this was discussed in the virtual interim meeting. I > seem > > to > > recall the consensus being that the advantage of easy deployment > > outweighed the disadvantages. > > > > =3D> I am afraid this argument would not close the subject... > > and there was no consensus, just a 'go to next point'. > > > > (Were the minutes of the meeting posted?) > > > > =3D> +1! > > > > Francis.Dupont@fdupont.fr > > > > PS: BTW the 'ease of deployment' is not a good argument as it = applied > > only on hosts, not on NATs, when IMHO at least 50% of the deployed > > base won't support it. >=20 > For reference, this is Issue #17, > http://trac.tools.ietf.org/wg/pcp/trac/ticket/17 >=20 > In the post http://www.ietf.org/mail- > archive/web/pcp/current/msg00474.html, > Simon described the host implementation difficulty. This got = agreement > from > Dave Thaler, http://www.ietf.org/mail- > archive/web/pcp/current/msg00475.html > and Lars Eggert, > http://www.ietf.org/mail-archive/web/pcp/current/msg00480.html. >=20 > I do not find a post that describes the NAT implementation difficulty. >=20 > I found posts that suggest NATs want to have different port ranges for > PCP-controlled ports than for dynamically-created connections. That's > makes > some sense when the user is operating a server. But I don't = understand > how > separate NAT port ranges are helpful/necessary for the application > keepalives case. >=20 > If this does help the NAT, it seems we will need to force (MUST) the > hosts > to allocate a source port in the non-ephemeral port range and follow > the > other steps described in > http://www.ietf.org/mail-archive/web/pcp/current/msg00474.html. >=20 > -d >=20 >=20 >=20 >=20 > ********************************* > This message and any attachments (the "message") are confidential and > intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, > changed or falsified. > If you are not the intended addressee of this message, please cancel = it > immediately and inform the sender. > ******************************** From dwing@cisco.com Tue Jan 11 11:43: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 6A92428C152 for ; Tue, 11 Jan 2011 11:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.532 X-Spam-Level: X-Spam-Status: No, score=-110.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 6vn4hvm0MHnp for ; Tue, 11 Jan 2011 11:43: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 22F963A6A8F for ; Tue, 11 Jan 2011 11:43: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: Av0EAEZCLE2rR7Ht/2dsb2JhbACXTYxsc6NimGiCdASCVASEaA Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 11 Jan 2011 19:45:19 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0BJjI3Q001691; Tue, 11 Jan 2011 19:45:18 GMT From: "Dan Wing" To: , References: <14273_1294323565_4D25CF6D_14273_1391_1_94C682931C08B048B7A8645303FDC9F33C3E9FDE6B@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <14273_1294323565_4D25CF6D_14273_1391_1_94C682931C08B048B7A8645303FDC9F33C3E9FDE6B@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 11 Jan 2011 11:45:18 -0800 Message-ID: <1eb201cbb1c8$13810830$3a831890$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcutrLfTEDZS4IWxQE+t0B7oqmebLgEGUuIA Content-Language: en-us Subject: Re: [pcp] 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, 11 Jan 2011 19:43:03 -0000 > We have submitted a new I-D available at > http://tools.ietf.org/html/draft-boucadair-pcp-failure-00. ... This is a review of draft-boucadair-pcp-failure-00.txt. First, thanks for writing this document -- it clarifies a lot of=20 email discussions. Section 2.2, "Application Crash", says in part: To avoid this inconvenience induced by stale mappings, the PCP Client MAY clear the "old" mappings before issuing the refresh requests; but this would require the PCP Client to store the information about the "old" port number. This may not be easy in some scenarios because the PCP Client may handle PCP requests on behalf of several applications and no means to identify the requesting application may be supported. Nothing is said about a PCP client embedded into an application. I = presume that could work okay, by the application writing its PCP-allocated ports = to permanent storage (a file) to try to re-use after it crashes and re-initializes. Yes? I noticed this note at the end of that same section that says: [Ed. This is in fact about the "application ID" idea.] For that to work, there must be a mechanism for the OS-embedded PCP = client=20 to know which application that create a mapping. Perhaps, for example, an opaque string is passed from the application to the OS-embedded PCP client. Once that mechanism exists, can't we foist the problem onto the OS-embedded PCP client? This could be as straight forward as having the client code do this, for example: pcp -> PCP.new("Cisco SIP Client"); pcp.remove_stale_mappings(); Once we have such a mechanism to identify an application in the=20 OS-embedded PCP client's API, I believe the problems identified by Section 2.2 mostly go away, because an application restart can be detected by the OS-embedded PCP client. =20 Section 2.4, "Change of the Internal IP Address" When a new IP address is assigned to a host embedding a PCP Client, the PCP Client MUST install on the PCP Server all the mappings it manages, using the new assigned IP address as the internal IP address. This needs some additional discussion. Let's take an example where I have a computer with both WiFi and wired Ethernet connections and I plug and unplug the Ethernet connection, or go in and out of range of WiFi. When do we want PCP to do something about that change of connectivity? Does the answer depend on IPv4, IPv6, or dual stack running on that interface if we're doing PIN44,=20 PIN64, PIN46, PIN66? =20 Section 2.4 also says: " [Ed. Note: Do we need to support means to clear stale mappings first? This may have an impact if the quota is exceed due to the presence of stale mappings.] A PCP Client may be used to manage pinholes on behalf of a third party (i.e., the PCP Client and the third party are not co-located on the same host). If a new internal IP address is assigned to that third party (e.g., webcam), the PCP Client SHOULD be instructed to delete the old mapping(s) and create new one(s) using the new assigned internal IP address." (As you know,) PCP currently has a mechanism that supports doing=20 that - a PCP client can clear mappings for another host within the=20 subscriber's network. I believe you're asking if we want to=20 encourage doing that. I am worried about supporting such deletes=20 at all. Let's take as an example that my IP address is 192.168.1.1=20 while I'm at home and then I visit a friend's house, were I get a different address. With a na=EFve implementation, I would simply=20 clear mappings for 192.168.1.1, which is my friend's webcam. =20 Oops. A smarter implementation would notice that my SSID is=20 different from my friend's SSID (SSID is something an OS- embedded PCP client could know) but SSIDs can collide (all the Starbucks use the same SSID) and Ethernet doesn't have a=20 handy SSID. The second paragraph I quoted above says that a PCP client that created a pinhole for another device needs to refresh the pinhole if the other device's IP address changes. In a PC, I don't see how that could be implemented. It could be implemented in a CPE, if that CPE is also running DHCP and interfaces DHCP leases with PCP. We may want to consider disallowing PCP from deleting another host's mappings, or pull that feature entirely. I created ticket #33 "3rd party mappings: create/destroy" to track this issue, http://trac.tools.ietf.org/wg/pcp/trac/ticket/33 Section 2.5, " Change of the CPE WAN IP Address" should also discuss the NAT44 case (a.k.a. "NAT444"). That case suffers from a similar problem highlighted by the Ed. Note in Section 2.5, where the PCP client has no reasonable way to detect the CPE's WAN address changed. It should also be noted in Section 2.5 that, on today's Internet without CGN and without PCP, subscriber WAN addresses change. And if the subscriber installed their own NAT, the hosts behind the NAT are likewise completely unaware of the CPE's WAN address change. NAT-PMP includes a mechanism to alert the hosts of this change, which uses multicast. We might consider if PCP could benefit from a mechanism that allows alerting hosts in some fashion [multicast or unicast]. UPnP IGD does not include such a mechanism, to my knowledge. 2.6.2. Clear PCP Mappings When a command line or a configuration change is enforced to clear all or a subset of PCP mappings maintained by the PCP Server, the PCP Server MUST reset its Epoch to zero value. Does the PCP server need to maintain only one Epoch value, or an Epoch=20 value for each subscriber? If one Epoch value, and only one = subscriber's mappings are changed, it will cause all PCP clients to refresh their=20 pinholes -- unnecessarily. So this means the base specification needs to encouarge per-subscriber Epoch values. Then, to the main point of the draft: The two cases where GET/GETNEXT are useful are when an application crashes and forgets its mappings (Section 2.2) and when the PCP=20 client crashes and forgets its mappings (Section 2.3). If we require PCP clients (implemented by applications or embedded in an OS) to store their mappings in permanent storage, do we need GET/GETNEXT? Are there PCP clients which cannot store their mappings in=20 permanent storage? If so, let's discuss them. -d From mohamed.boucadair@orange-ftgroup.com Tue Jan 11 22:53: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 DC91A3A6AF2 for ; Tue, 11 Jan 2011 22:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 DNDQISvcXN8F for ; Tue, 11 Jan 2011 22:53:08 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id 250FC3A699E for ; Tue, 11 Jan 2011 22:53:07 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id A3EE62AC79F; Wed, 12 Jan 2011 07:55:25 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 1DDC6384057; Wed, 12 Jan 2011 07:55:25 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 12 Jan 2011 07:55:24 +0100 From: To: Dan Wing , 'Francis Dupont' , 'Simon Perreault' Date: Wed, 12 Jan 2011 07:55:23 +0100 Thread-Topic: [pcp] PCP-base 02: Section 7.7 Thread-Index: AcuxGnH/oFEq0BUFQIqUfjE7XufIxwABnQoQAA6BC4AAFMrhsAAdWvDw Message-ID: <22350_1294815325_4D2D505D_22350_100240_1_94C682931C08B048B7A8645303FDC9F33C3FD7B99E@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Mon, 10 Jan 2011 08:45:02 EST. <4D2B0D5E.5030302@viagenie.ca> <201101102301.p0AN1rcs084678@givry.fdupont.fr> <19ba01cbb122$f11dfd70$d359f850$@com> <837_1294728928_4D2BFEE0_837_116100_1_94C682931C08B048B7A8645303FDC9F33C3FD7B3C4@PUEXCB1B.nanterre.francetelecom.fr> <1d8901cbb1b5$e093ca50$a1bb5ef0$@com> In-Reply-To: <1d8901cbb1b5$e093ca50$a1bb5ef0$@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.1.12.53314 Cc: "pcp@ietf.org" Subject: Re: [pcp] PCP-base 02: Section 7.7 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, 12 Jan 2011 06:53:10 -0000 Hi Dan, Please see inline. Cheers, Med=20 -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : mardi 11 janvier 2011 18:35 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; 'Francis Dupont'; 'Simon Perreault' Cc : pcp@ietf.org Objet : RE: [pcp] PCP-base 02: Section 7.7 > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Monday, January 10, 2011 10:55 PM > To: Dan Wing; 'Francis Dupont'; 'Simon Perreault' > Cc: pcp@ietf.org > Subject: RE: [pcp] PCP-base 02: Section 7.7 >=20 > Hi Dan, >=20 > As a reminder, I have enumerated a set of advantages of implementing > what was called option 2 (http://www.ietf.org/mail- > archive/web/pcp/current/msg00483.html). >=20 > In http://www.ietf.org/mail-archive/web/pcp/current/msg00487.html, I > tried to explain that implementing option 1 may not reduce keepalives > in some contexts since the refresh interval is forced by the server and > not by the client (see SIP example for instance). Thanks for the pointers. The first URL says: > I don't know how we can forbid applications to use option 2 > which is the obvious one to avoid overloading service > elements with keepalive messages! > > As a concrete example: In the current VoIP deployments SBC > or P-CSCF forces the SIP User Agent to send frequent > REGISTER messages (setting a small value of expire timer); > these messages are not forwarded to the core service > elements. The main purpose is to maintain the NAT binding > in case a NAT is traversed alive. Both the NAT and SBC are > overloaded with these keepalive messages. For the NAT side > this may not be an issue when the NAT is embedded in the > CPE but this may be become sensitive for the CGN case. > > If PCP is used to instruct a mapping before issuing the > REGISTER message: (1) the CGN is not overloaded, (2) > service contact point is not overloaded, (3) the client can > use the external IP address/port to build its application > messages (e.g., SIP) and thus no need to implement extra > function in the service side (e.g., SBC) or in the CGN > (e.g., SIP ALG), (4) the service elements can detect the > present of non-transparent NAT by comparing the content of > the message with the source IP/port information, (5) the > client is aware of the lifetime of the mapping in the CGN > which important to avoid sending aggressive keeplines > (e.g., 20s for Ipsec clients), etc. and the second URL reinforces that connect-then-lifetime does not have property (3). Here is how I see property (3) implemented when doing connect-then-lifetime, following the REGISTER procedure described at http://tools.ietf.org/html/draft-ietf-sipping-nat-scenarios-13#page-16 SIP UA PCP server SIP proxy | | | |--SIP REGISTER, rport------------------------->| |<-Ok, port=3D12345-------------------------------| | | | |-PIN44, REMOTE_PEER=3D->| | |<--lifetime=3D3600, ext-port=3D12345-| | | | | What is the disadvantage of reducing SIP keepalives that way? Med: The use of "rport" allows the SIP Proxy to answer to the source port n= umber and not to the one indicated in the via header but it does not help t= he SIP proxy server to detect the lifetime of the nat binding in the path; = therefore a lower expire timers (e.g., 30 or 60s) will be returned by the S= IP Proxy to the SIP UA to maintain such binding. The SIP UA has to refresh = its registration before the expiry of the returned expiry timer. The PCP re= quest does not help in such case. In some deployments "rport" is not used b= ut SBCs "emulate" a similar functionality but this does not prevent frequen= t re-registration messages (not forwarded to the core service elements btw)= . Keepalive messages have a SEVERE impact on the performance of the SBC (60= % degradation). This is why I prefer to present a SIP message to the SIP pr= oxy without rport but with the external IP/port assigned by the nat in the = path. This would be a hint for the proxy server to return an expire timer w= ith greater value. For RTP, message flow would be like this, again doing connect-then-lifetime. The difference is we don't get anything like an "rport=3DNNN" from the remo= te peer. But, we don't need it anyway except to detect a rogue NAT on the path between the PCP-controlled NAT and the RTP peer. If the SIP UA wanted to detect such a rogue NAT, it would need to send ICE (STUN) messages to the RTP peer. Med: Why not doing it simple, use the even_plus_one option to get the ports= ; use those ports to build the offer/answer and issue the request. We don't= need ICE/STUN/etc.=20 SIP UA PCP server RTP peer | | | |--RTP message--------------------------------->| |--RTP message--------------------------------->| |--... more RTP messages ...------------------->| |--RTP message--------------------------------->| | | | |-PIN44, REMOTE_PEER=3D=3D->| | |<--lifetime=3D3600, ext-port=3D12345-| | | | | As with SIP, the SIP UA does not need to be in a hurry to communicate with the PCP server. -d > Cheers, > Med >=20 > -----Message d'origine----- > De : Dan Wing [mailto:dwing@cisco.com] > Envoy=E9 : mardi 11 janvier 2011 01:03 > =C0 : 'Francis Dupont'; 'Simon Perreault'; BOUCADAIR Mohamed OLNC/NAD/TIP > Cc : pcp@ietf.org > Objet : RE: [pcp] PCP-base 02: Section 7.7 >=20 >=20 >=20 > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > > Francis Dupont > > Sent: Monday, January 10, 2011 3:02 PM > > To: Simon Perreault > > Cc: pcp@ietf.org > > Subject: Re: [pcp] PCP-base 02: Section 7.7 > > > > > > In your previous mail you wrote: > > > > Note that this was discussed in the virtual interim meeting. I > seem > > to > > recall the consensus being that the advantage of easy deployment > > outweighed the disadvantages. > > > > =3D> I am afraid this argument would not close the subject... > > and there was no consensus, just a 'go to next point'. > > > > (Were the minutes of the meeting posted?) > > > > =3D> +1! > > > > Francis.Dupont@fdupont.fr > > > > PS: BTW the 'ease of deployment' is not a good argument as it applied > > only on hosts, not on NATs, when IMHO at least 50% of the deployed > > base won't support it. >=20 > For reference, this is Issue #17, > http://trac.tools.ietf.org/wg/pcp/trac/ticket/17 >=20 > In the post http://www.ietf.org/mail- > archive/web/pcp/current/msg00474.html, > Simon described the host implementation difficulty. This got agreement > from > Dave Thaler, http://www.ietf.org/mail- > archive/web/pcp/current/msg00475.html > and Lars Eggert, > http://www.ietf.org/mail-archive/web/pcp/current/msg00480.html. >=20 > I do not find a post that describes the NAT implementation difficulty. >=20 > I found posts that suggest NATs want to have different port ranges for > PCP-controlled ports than for dynamically-created connections. That's > makes > some sense when the user is operating a server. But I don't understand > how > separate NAT port ranges are helpful/necessary for the application > keepalives case. >=20 > If this does help the NAT, it seems we will need to force (MUST) the > hosts > to allocate a source port in the non-ephemeral port range and follow > the > other steps described in > http://www.ietf.org/mail-archive/web/pcp/current/msg00474.html. >=20 > -d >=20 >=20 >=20 >=20 > ********************************* > This message and any attachments (the "message") are confidential and > intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, > changed or falsified. > If you are not the intended addressee of this message, please cancel it > immediately and inform the sender. > ******************************** ********************************* 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 mohamed.boucadair@orange-ftgroup.com Wed Jan 12 00:04: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 594AC3A69AE for ; Wed, 12 Jan 2011 00:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[AWL=0.062, 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 IxSD7aIcn+4C for ; Wed, 12 Jan 2011 00:04:14 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id 972BA3A6B0E for ; Wed, 12 Jan 2011 00:04:13 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 506E618C66D; Wed, 12 Jan 2011 09:06:31 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 3729A35C055; Wed, 12 Jan 2011 09:06:31 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Wed, 12 Jan 2011 09:06:30 +0100 From: To: Dan Wing , "pcp@ietf.org" Date: Wed, 12 Jan 2011 09:06:29 +0100 Thread-Topic: [pcp] PCP failure scenarios & PCP state synchronization procedure Thread-Index: AcutrLfTEDZS4IWxQE+t0B7oqmebLgEGUuIAABh4RDA= Message-ID: <10778_1294819591_4D2D6107_10778_54899_1_94C682931C08B048B7A8645303FDC9F33C3FD7B9BA@PUEXCB1B.nanterre.francetelecom.fr> References: <14273_1294323565_4D25CF6D_14273_1391_1_94C682931C08B048B7A8645303FDC9F33C3E9FDE6B@PUEXCB1B.nanterre.francetelecom.fr> <1eb201cbb1c8$13810830$3a831890$@com> In-Reply-To: <1eb201cbb1c8$13810830$3a831890$@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.1.12.71523 Subject: Re: [pcp] 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: Wed, 12 Jan 2011 08:04:15 -0000 Re-, Please see inline. Cheers, Med=20 -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : mardi 11 janvier 2011 20:45 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; pcp@ietf.org Objet : RE: [pcp] PCP failure scenarios & PCP state synchronization procedu= re > We have submitted a new I-D available at > http://tools.ietf.org/html/draft-boucadair-pcp-failure-00. ... This is a review of draft-boucadair-pcp-failure-00.txt. First, thanks for writing this document -- it clarifies a lot of=20 email discussions. Section 2.2, "Application Crash", says in part: To avoid this inconvenience induced by stale mappings, the PCP Client MAY clear the "old" mappings before issuing the refresh requests; but this would require the PCP Client to store the information about the "old" port number. This may not be easy in some scenarios because the PCP Client may handle PCP requests on behalf of several applications and no means to identify the requesting application may be supported. Nothing is said about a PCP client embedded into an application. I presume that could work okay, by the application writing its PCP-allocated ports to permanent storage (a file) to try to re-use after it crashes and re-initializes. Yes? Med: Yes. The text mentions only the case which poses problem. I updated th= e text to refer explicitely to this case. I noticed this note at the end of that same section that says: [Ed. This is in fact about the "application ID" idea.] For that to work, there must be a mechanism for the OS-embedded PCP client= =20 to know which application that create a mapping. Perhaps, for example, an opaque string is passed from the application to the OS-embedded PCP client. Once that mechanism exists, can't we foist the problem onto the OS-embedded PCP client? This could be as straight forward as having the client code do this, for example: pcp -> PCP.new("Cisco SIP Client"); pcp.remove_stale_mappings(); Once we have such a mechanism to identify an application in the=20 OS-embedded PCP client's API, I believe the problems identified by Section 2.2 mostly go away, because an application restart can be detected by the OS-embedded PCP client. Med: Yes. Note that the local PCP mapping table should have an "application= _id" attribute for this to work. The following reco should also be followed= :=20 "It is NOT RECOMMENDED for a PCP Client to issue a request to delete all th= e mappings associated with an internal IP address since other applications = and PCP Client(s) may use the same internal IP address to instruct their pi= nholes in the PCP Server." Section 2.4, "Change of the Internal IP Address" When a new IP address is assigned to a host embedding a PCP Client, the PCP Client MUST install on the PCP Server all the mappings it manages, using the new assigned IP address as the internal IP address. This needs some additional discussion. Let's take an example where I have a computer with both WiFi and wired Ethernet connections and I plug and unplug the Ethernet connection, or go in and out of range of WiFi. When do we want PCP to do something about that change of connectivity? Does the answer depend on IPv4, IPv6, or dual stack running on that interface if we're doing PIN44,=20 PIN64, PIN46, PIN66?=20 Med: Good point. IMHO, the address selection should be done according to th= e-be-completed section: http://tools.ietf.org/html/draft-ietf-pcp-base-02#s= ection-6.1.3. Based on the output of that process, the PCP Client can be tr= iggered accordingly.=20 =20 Section 2.4 also says: " [Ed. Note: Do we need to support means to clear stale mappings first? This may have an impact if the quota is exceed due to the presence of stale mappings.] A PCP Client may be used to manage pinholes on behalf of a third party (i.e., the PCP Client and the third party are not co-located on the same host). If a new internal IP address is assigned to that third party (e.g., webcam), the PCP Client SHOULD be instructed to delete the old mapping(s) and create new one(s) using the new assigned internal IP address." (As you know,) PCP currently has a mechanism that supports doing=20 that - a PCP client can clear mappings for another host within the=20 subscriber's network. I believe you're asking if we want to=20 encourage doing that.=20=20 Med: The question is not this one but how to remove the stale mappings asso= ciated with the "old" used internal IP address. I am worried about supporting such deletes=20 at all. Let's take as an example that my IP address is 192.168.1.1=20 while I'm at home and then I visit a friend's house, were I get a different address. With a na=EFve implementation, I would simply=20 clear mappings for 192.168.1.1, which is my friend's webcam.=20=20 Oops.=20 Med: Me too I'm in favour of having means to avoid such behaviour, this is = why I have proposed in the past the PCP Identifier (http://www.ietf.org/mai= l-archive/web/pcp/current/msg00055.html) A smarter implementation would notice that my SSID is=20 different from my friend's SSID (SSID is something an OS- embedded PCP client could know) but SSIDs can collide (all the Starbucks use the same SSID) and Ethernet doesn't have a=20 handy SSID. The second paragraph I quoted above says that a PCP client that created a pinhole for another device needs to refresh the pinhole if the other device's IP address changes. In a PC, I don't see how that could be implemented. It could be implemented in a CPE, if that CPE is also running DHCP and interfaces DHCP leases with PCP. Med: Yes, and especially for an IWF co-located with the local DHCP server. = Otherwise, we can recommend the use of static internal IP addresses if PCP = is used to configure third-party pinholes. We may want to consider disallowing PCP from deleting another host's mappings, or pull that feature entirely. I created ticket #33 "3rd party mappings: create/destroy" to track this issue, http://trac.tools.ietf.org/wg/pcp/trac/ticket/33 Med: Or use the "PCP identifier". Section 2.5, " Change of the CPE WAN IP Address" should also discuss the NAT44 case (a.k.a. "NAT444"). That case suffers from a similar problem highlighted by the Ed. Note in Section 2.5, where the PCP client has no reasonable way to detect the CPE's WAN address changed. Med: I added a note about the NAT444 case. It should also be noted in Section 2.5 that, on today's Internet without CGN and without PCP, subscriber WAN addresses change. And if the subscriber installed their own NAT, the hosts behind the NAT are likewise completely unaware of the CPE's WAN address change. NAT-PMP includes a mechanism to alert the hosts of this change, which uses multicast. We might consider if PCP could benefit from a mechanism that allows alerting hosts in some fashion [multicast or unicast]. UPnP IGD does not include such a mechanism, to my knowledge. Med: I suggest you add an issue into the tracker to record it. 2.6.2. Clear PCP Mappings When a command line or a configuration change is enforced to clear all or a subset of PCP mappings maintained by the PCP Server, the PCP Server MUST reset its Epoch to zero value. Does the PCP server need to maintain only one Epoch value, or an Epoch=20 value for each subscriber? If one Epoch value, and only one subscriber's mappings are changed, it will cause all PCP clients to refresh their=20 pinholes -- unnecessarily. So this means the base specification needs to encouarge per-subscriber Epoch values. Med: FWIW, the logic of setting the Epoch value when enforcing CLI is descr= ibed in: http://www.ietf.org/mail-archive/web/pcp/current/msg00091.html=20 I'm not sure Epoch is the more efficient per-subscriber hint to audit the m= appings; COUNT of the mappings can be considered too. Then, to the main point of the draft: The two cases where GET/GETNEXT are useful are when an application crashes and forgets its mappings (Section 2.2) and when the PCP=20 client crashes and forgets its mappings (Section 2.3). If we require PCP clients (implemented by applications or embedded in an OS) to store their mappings in permanent storage, do we need GET/GETNEXT? Are there PCP clients which cannot store their mappings in=20 permanent storage? If so, let's discuss them. Med: Yes: some CPEs embedding a PCP Client/IWF. ********************************* 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 trac@tools.ietf.org Wed Jan 12 08:50: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 426D328C0EE for ; Wed, 12 Jan 2011 08:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.014, 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 HtTFvaTSW9Dv for ; Wed, 12 Jan 2011 08:50:33 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4431D28C0F3 for ; Wed, 12 Jan 2011 08:50:33 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pd3wK-0007t6-1k; Wed, 12 Jan 2011 08:52: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: mohamed.boucadair@orange-ftgroup.com X-Trac-Project: pcp Date: Wed, 12 Jan 2011 16:52:51 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/34 Message-ID: <074.0ffa67fbfec724848038ffd8690553bf@tools.ietf.org> X-Trac-Ticket-ID: 34 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mohamed.boucadair@orange-ftgroup.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] base #34 (new): notify NAT WAN address changed 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, 12 Jan 2011 16:50:35 -0000 #34: notify NAT WAN address changed It may be useful to add a feature to PCP so that a PCP client can be immediately informed if the CPE WAN address changed, as that will require obtaining new PCP mappings. This is discussed in [http://tools.ietf.org/html/draft-boucadair-pcp-failure-00#section-2.5 Change of the CPE WAN IP Address]. -- --------------------------------------------------+------------------------- Reporter: mohamed.boucadair@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: base | Version: Severity: - | Keywords: --------------------------------------------------+------------------------- Ticket URL: pcp From simon.perreault@viagenie.ca Wed Jan 12 08:53: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 3FFAB28C0EE for ; Wed, 12 Jan 2011 08:53: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 K4FxldfeHdyZ for ; Wed, 12 Jan 2011 08:53:32 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 3108228C0F0 for ; Wed, 12 Jan 2011 08:53:32 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9A83720E36 for ; Wed, 12 Jan 2011 11:55:51 -0500 (EST) Message-ID: <4D2DDD17.7080004@viagenie.ca> Date: Wed, 12 Jan 2011 11:55: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: <074.0ffa67fbfec724848038ffd8690553bf@tools.ietf.org> In-Reply-To: <074.0ffa67fbfec724848038ffd8690553bf@tools.ietf.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [pcp] base #34 (new): notify NAT WAN address changed 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, 12 Jan 2011 16:53:34 -0000 On 2011-01-12 11:52, pcp issue tracker wrote: > It may be useful to add a feature to PCP so that a PCP client can be > immediately informed if the CPE WAN address changed, as that will require > obtaining new PCP mappings. To use PCP terms, would it work if we say "external address" instead of "CPE WAN address"? This way it would apply to any PCP server, whether it is on a CPE or elsewhere. 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 Jan 12 08:59: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 3D64F3A6B3B for ; Wed, 12 Jan 2011 08:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.532 X-Spam-Level: X-Spam-Status: No, score=-110.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=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 aIQN8OB1T2rN for ; Wed, 12 Jan 2011 08:59:53 -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 EC23F3A69A6 for ; Wed, 12 Jan 2011 08:59:52 -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: AmAFANRtLU2rR7Hu/2dsb2JhbACJcY1ijDM5c6NPjg4BimWCeIJUBIRo Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 12 Jan 2011 17:02:12 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0CH2CbH029158; Wed, 12 Jan 2011 17:02:12 GMT From: "Dan Wing" To: , References: <14273_1294323565_4D25CF6D_14273_1391_1_94C682931C08B048B7A8645303FDC9F33C3E9FDE6B@PUEXCB1B.nanterre.francetelecom.fr> <1eb201cbb1c8$13810830$3a831890$@com> <10778_1294819591_4D2D6107_10778_54899_1_94C682931C08B048B7A8645303FDC9F33C3FD7B9BA@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <10778_1294819591_4D2D6107_10778_54899_1_94C682931C08B048B7A8645303FDC9F33C3FD7B9BA@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 12 Jan 2011 09:02:12 -0800 Message-ID: <222c01cbb27a$750a61c0$5f1f2540$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcutrLfTEDZS4IWxQE+t0B7oqmebLgEGUuIAABh4RDAAExtaMA== Content-Language: en-us Subject: Re: [pcp] 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: Wed, 12 Jan 2011 16:59:54 -0000 ... > Section 2.4 also says: >=20 > " [Ed. Note: Do we need to support means to clear stale mappings > first? This may have an impact if the quota is exceed due to = the > presence of stale mappings.] >=20 > A PCP Client may be used to manage pinholes on behalf of a third > party (i.e., the PCP Client and the third party are not co-located > on > the same host). If a new internal IP address is assigned to that > third party (e.g., webcam), the PCP Client SHOULD be instructed to > delete the old mapping(s) and create new one(s) using the new > assigned internal IP address." >=20 > (As you know,) PCP currently has a mechanism that supports doing > that - a PCP client can clear mappings for another host within the > subscriber's network. I believe you're asking if we want to > encourage doing that. >=20 > Med: The question is not this one but how to remove the stale mappings > associated with the "old" used internal IP address. You're referring to the problem of detecting that a host's IP address changed? I agree that is hard. I say don't worry about it. =20 Let's consider the same situation (host's IP address changes=20 arbitrarily) without NAT and without PCP, and where a 3rd party set up some sort of rendezvous for the device -- because the device couldn't do that itself. For example, a simple networked camera or a simple NAS device, where the user edits a web page that says=20 "click here to see my home movies" which points to http://1.2.3.4 (an IP address literal). This works until the NAS's IP address=20 changes. We have no way to solve that without NAT and without=20 PCP. So, I propose we don't try to solve that with PCP. > I am worried about supporting such deletes > at all. Let's take as an example that my IP address is 192.168.1.1 > while I'm at home and then I visit a friend's house, were I get > a different address. With a na=EFve implementation, I would simply > clear mappings for 192.168.1.1, which is my friend's webcam. > Oops. >=20 > Med: Me too I'm in favour of having means to avoid such behaviour, = this > is why I have proposed in the past the PCP Identifier > (http://www.ietf.org/mail-archive/web/pcp/current/msg00055.html) That solves a slew of other problems, though. And creates some new problems. To solve the problem of accidental deletes, here are two other ideas: * a 3rd party mapping could cause an opaque identifier to be=20 included in the PIN response, and require subsequent PIN*=20 requests that reduce the lifetime to include that identifier. =20 A problem with that idea might be loss of the first response,=20 though.=20 * Another idea which doesn't change PCP is that the server, on noticing a 3rd party mapping, only allows that same IP address to reduce the lifetime of the mapping. > A smarter implementation would notice that my SSID is > different from my friend's SSID (SSID is something an OS- > embedded PCP client could know) but SSIDs can collide (all > the Starbucks use the same SSID) and Ethernet doesn't have a > handy SSID. >=20 > The second paragraph I quoted above says that a PCP client > that created a pinhole for another device needs to refresh > the pinhole if the other device's IP address changes. In > a PC, I don't see how that could be implemented. It could > be implemented in a CPE, if that CPE is also running DHCP > and interfaces DHCP leases with PCP. >=20 > Med: Yes, and especially for an IWF co-located with the local DHCP > server. Otherwise, we can recommend the use of static internal IP > addresses if PCP is used to configure third-party pinholes. That's the only safe thing to recommend. Today, changing the IP address on a server is an involved process (reduce DNS TTL, bring it up on the new address and keep the old address active, change DNS, wait until TTL*some_safety_multiplier, decommission old address). None of that is described in an RFC, it's just common practice (documented elsewhere). I don't see a need to get into deep levels of education about changing client IP=20 addresses and making that work nicely with PCP. Besides, client IP addresses don't change that often or, if they are being changed, it's by a malicious ISP that is trying to interfere with their subscribers running a server -- exactly the sort of ISP that won't be much interested in PCP. ... > It should also be noted in Section 2.5 that, on today's Internet > without CGN and without PCP, subscriber WAN addresses change. > And if the subscriber installed their own NAT, the hosts behind > the NAT are likewise completely unaware of the CPE's WAN > address change. NAT-PMP includes a mechanism to alert the > hosts of this change, which uses multicast. We might consider > if PCP could benefit from a mechanism that allows alerting > hosts in some fashion [multicast or unicast]. UPnP IGD does > not include such a mechanism, to my knowledge. >=20 > Med: I suggest you add an issue into the tracker to record it. http://trac.tools.ietf.org/wg/pcp/trac/ticket/34, as an enhancement. > 2.6.2. Clear PCP Mappings >=20 > When a command line or a configuration change is enforced to clear > all or a subset of PCP mappings maintained by the PCP Server, the > PCP > Server MUST reset its Epoch to zero value. >=20 > Does the PCP server need to maintain only one Epoch value, or an Epoch > value for each subscriber? If one Epoch value, and only one > subscriber's > mappings are changed, it will cause all PCP clients to refresh their > pinholes -- unnecessarily. So this means the base specification needs > to encouarge per-subscriber Epoch values. >=20 > Med: FWIW, the logic of setting the Epoch value when enforcing CLI is > described in: http://www.ietf.org/mail- > archive/web/pcp/current/msg00091.html > I'm not sure Epoch is the more efficient per-subscriber hint to audit > the mappings; COUNT of the mappings can be considered too. A count of the number of mappings only works if: 1. there is one PCP client per host, which requires the PCP=20 client be part of the OS rather than part of the application. 2. there is some sort of application-id stored on the PCP server, and counts are returned only for matching application-id. If there is an application-id maintained for every PCP mapping, we might as well have separate Epoch for every subscriber for this case, as separate Epoch is fewer bytes on the server than=20 an application-id for every mapping. > Then, to the main point of the draft: >=20 > The two cases where GET/GETNEXT are useful are when an application > crashes and forgets its mappings (Section 2.2) and when the PCP > client crashes and forgets its mappings (Section 2.3). >=20 > If we require PCP clients (implemented by applications or embedded in > an OS) to store their mappings in permanent storage, do we need > GET/GETNEXT? >=20 > Are there PCP clients which cannot store their mappings in > permanent storage? If so, let's discuss them. >=20 > Med: Yes: some CPEs embedding a PCP Client/IWF. Please say more. -d From mohamed.boucadair@orange-ftgroup.com Wed Jan 12 09:07: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 73D6928C133 for ; Wed, 12 Jan 2011 09:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[AWL=0.060, 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 HIl+25hgEkQ0 for ; Wed, 12 Jan 2011 09:07:19 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 194A828C123 for ; Wed, 12 Jan 2011 09:07:18 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 3170B22C56F; Wed, 12 Jan 2011 18:09:38 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 182B0238076; Wed, 12 Jan 2011 18:09:38 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Wed, 12 Jan 2011 18:09:37 +0100 From: To: Simon Perreault , "pcp@ietf.org" Date: Wed, 12 Jan 2011 18:09:37 +0100 Thread-Topic: [pcp] base #34 (new): notify NAT WAN address changed Thread-Index: AcuyeZabn1BRceD4QGqLOi3LMMeKlwAAWCKA Message-ID: <12343_1294852178_4D2DE052_12343_367309_1_94C682931C08B048B7A8645303FDC9F33C3FD7BD4C@PUEXCB1B.nanterre.francetelecom.fr> References: <074.0ffa67fbfec724848038ffd8690553bf@tools.ietf.org> <4D2DDD17.7080004@viagenie.ca> In-Reply-To: <4D2DDD17.7080004@viagenie.ca> 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.1.12.163314 Subject: Re: [pcp] base #34 (new): notify NAT WAN address changed 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, 12 Jan 2011 17:07:20 -0000 Dear Simon,=20 The use of "external address" term is not appropriate in this case. The issue described here is when there is a PCP Client behind a CPE; the PC= P Server is located upstream (not located in the CPE): how the PCP Client i= s aware about the change of the assigned IP address on the WAN interface of= the CPE so that to trigger the update of the pinholes it instructed on the= PCP Server.=20 Cheers, Med=20 -----Message d'origine----- De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Simon= Perreault Envoy=E9 : mercredi 12 janvier 2011 17:56 =C0 : pcp@ietf.org Objet : Re: [pcp] base #34 (new): notify NAT WAN address changed On 2011-01-12 11:52, pcp issue tracker wrote: > It may be useful to add a feature to PCP so that a PCP client can be > immediately informed if the CPE WAN address changed, as that will require > obtaining new PCP mappings. To use PCP terms, would it work if we say "external address" instead of "CPE WAN address"? This way it would apply to any PCP server, whether it is on a CPE or elsewhere. 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 ********************************* 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 simon.perreault@viagenie.ca Wed Jan 12 09:47: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 526E73A69B9 for ; Wed, 12 Jan 2011 09:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_74=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 eA-FCWyKwYfF for ; Wed, 12 Jan 2011 09:47:30 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 3E2B53A6A5B for ; Wed, 12 Jan 2011 09:47:30 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DD05220D10; Wed, 12 Jan 2011 12:49:49 -0500 (EST) Message-ID: <4D2DE9BD.5070301@viagenie.ca> Date: Wed, 12 Jan 2011 12:49:49 -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: mohamed.boucadair@orange-ftgroup.com References: <074.0ffa67fbfec724848038ffd8690553bf@tools.ietf.org> <4D2DDD17.7080004@viagenie.ca> <12343_1294852178_4D2DE052_12343_367309_1_94C682931C08B048B7A8645303FDC9F33C3FD7BD4C@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <12343_1294852178_4D2DE052_12343_367309_1_94C682931C08B048B7A8645303FDC9F33C3FD7BD4C@PUEXCB1B.nanterre.francetelecom.fr> 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] base #34 (new): notify NAT WAN address changed 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, 12 Jan 2011 17:47:31 -0000 On 2011-01-12 12:09, mohamed.boucadair@orange-ftgroup.com wrote: > The issue described here is when there is a PCP Client behind a CPE; > the PCP Server is located upstream (not located in the CPE): how the > PCP Client is aware about the change of the assigned IP address on > the WAN interface of the CPE so that to trigger the update of the > pinholes it instructed on the PCP Server. I'm purposefully trying to avoid the term "CPE". PCP is applicable to many scenarios, some of which don't involve a CPE at all. This is how I understand it (please correct if wrong): +----------+ +---------------+ +------------+ |PCP client|---|NAT without PCP|---|NAT with PCP|--- Internet +----------+ +---------------+ +------------+ ^ ^ external 1 external 2 You would want the PCP client to be notified with PCP when the external address labelled "external 1" changes. Is that right? If so, two things: - How would the PCP server itself be notified of the change? - Where would the PCP server send the notification? It cannot reuse the address+port of the last incoming PCP request since the UDP binding in the NAT without PCP will very likely have expired. 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 Wed Jan 12 09:49: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 58D083A69B7 for ; Wed, 12 Jan 2011 09:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.014, 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 AAKVpFxdK9DC for ; Wed, 12 Jan 2011 09:49:12 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 77D683A683D for ; Wed, 12 Jan 2011 09:49:12 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pd4r5-0002oX-KV; Wed, 12 Jan 2011 09:51:31 -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: Wed, 12 Jan 2011 17:51:31 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/25#comment:2 Message-ID: <055.b1bec1c8701a38da93f426dfaca88d68@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: 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] 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: Wed, 12 Jan 2011 17:49:13 -0000 #25: Nested NAT support Changes (by dwing@…): * milestone: milestone1 => -- --------------------------------+------------------------------------------- Reporter: multiple | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: base | Version: 1.0 Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: pcp From dwing@cisco.com Wed Jan 12 09:50: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 AC6FF3A69B7 for ; Wed, 12 Jan 2011 09:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.533 X-Spam-Level: X-Spam-Status: No, score=-110.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 Zec85E83d4kg for ; Wed, 12 Jan 2011 09:50:44 -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 EA0AF3A683D for ; Wed, 12 Jan 2011 09:50:44 -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: Am0GAA95LU2rR7Hu/2dsb2JhbACWLoEljGxzo1KYcYVMBIRo Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 12 Jan 2011 17:53:05 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0CHr42Q029246 for ; Wed, 12 Jan 2011 17:53:05 GMT From: "Dan Wing" To: Date: Wed, 12 Jan 2011 09:53:04 -0800 Message-ID: <228101cbb281$90332f70$b0998e50$@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: AcuygY/62HcOUwRGQ22WgxBVVn7EYA== Content-Language: en-us Subject: [pcp] review tracker 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, 12 Jan 2011 17:50:45 -0000 Over the last few weeks I have updated a lot of information in PCP's tracker and closed some items based on text in draft-ietf-pcp-base-01 or -02. I would really like everyone to review the open issues and the closed issues. Regarding the open issues, we need to build consensus around how to solve them or how to defer them. Regarding the closed issues, I believe there is consensus for the text I have included/excluded from -02 (which is why I marked them closed). All of the tickets can be viewed at http://trac.tools.ietf.org/wg/pcp/trac/report/6 the closed tickets are at the bottom of that page, in grey. -d From trac@tools.ietf.org Wed Jan 12 09:52: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 819BA3A6817 for ; Wed, 12 Jan 2011 09:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.014, 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+VaqkYYaL92 for ; Wed, 12 Jan 2011 09:52:15 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0C76E3A683D for ; Wed, 12 Jan 2011 09:52: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 1Pd4u3-0002qg-D1; Wed, 12 Jan 2011 09:54:35 -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, 12 Jan 2011 17:54:35 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/34#comment:1 Message-ID: <083.f0db3ea5d788f563a01faaadede71fa4@tools.ietf.org> References: <074.0ffa67fbfec724848038ffd8690553bf@tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <074.0ffa67fbfec724848038ffd8690553bf@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 #34 (new): notify NAT WAN address changed 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, 12 Jan 2011 17:52:18 -0000 #34: notify NAT WAN address changed Description changed by dwing@…: Old description: > It may be useful to add a feature to PCP so that a PCP client can be > immediately informed if the CPE WAN address changed, as that will require > obtaining new PCP mappings. This is discussed in > [http://tools.ietf.org/html/draft-boucadair-pcp-failure-00#section-2.5 > Change of the CPE WAN IP Address]. New description: It may be useful to add a feature to PCP so that a PCP client can be immediately informed if: a. the CPE's WAN address changed (if the CPE is a NAT) or b. the PCP-controlled NAT's WAN address changed (if a LSN) As either will require obtaining new PCP mappings. The CPE address change is discussed in [http://tools.ietf.org/html/draft-boucadair-pcp- failure-00#section-2.5 Change of the CPE WAN IP Address]. -- -- --------------------------------------------------+------------------------- Reporter: mohamed.boucadair@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: base | Version: Severity: - | Keywords: --------------------------------------------------+------------------------- Ticket URL: pcp From trac@tools.ietf.org Wed Jan 12 09:54: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 62D603A684B for ; Wed, 12 Jan 2011 09:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.014, 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 FICFrjWKLbzz for ; Wed, 12 Jan 2011 09:54:15 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C23CC3A6808 for ; Wed, 12 Jan 2011 09:54: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 1Pd4w0-0002s6-4w; Wed, 12 Jan 2011 09:56: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: dwing@cisco.com X-Trac-Project: pcp Date: Wed, 12 Jan 2011 17:56:36 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/34#comment:2 Message-ID: <083.da80e879af3413bf4b7a968b27e48c2e@tools.ietf.org> References: <074.0ffa67fbfec724848038ffd8690553bf@tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <074.0ffa67fbfec724848038ffd8690553bf@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 #34 (new): notify NAT WAN address changed 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, 12 Jan 2011 17:54:17 -0000 #34: notify NAT WAN address changed Description changed by dwing@…: Old description: > It may be useful to add a feature to PCP so that a PCP client can be > immediately informed if: > > a. the CPE's WAN address changed (if the CPE is a NAT) > or > b. the PCP-controlled NAT's WAN address changed (if a LSN) > > As either will require obtaining new PCP mappings. The CPE address > change is discussed in [http://tools.ietf.org/html/draft-boucadair-pcp- > failure-00#section-2.5 Change of the CPE WAN IP Address]. New description: It may be useful to add a feature to PCP so that a PCP client can be immediately informed if either: a. the CPE's WAN address changed (if the CPE is a NAT), as discussed in [http://tools.ietf.org/html/draft-boucadair-pcp-failure-00#section-2.5 Change of the CPE WAN IP Address], OR b. the PCP-controlled NAT's WAN address changed (if a LSN) As either will require obtaining new PCP mappings. -- -- --------------------------------------------------+------------------------- Reporter: mohamed.boucadair@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: base | Version: Severity: - | Keywords: --------------------------------------------------+------------------------- Ticket URL: pcp From dwing@cisco.com Wed Jan 12 09:54: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 6FD443A684B for ; Wed, 12 Jan 2011 09:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.534 X-Spam-Level: X-Spam-Status: No, score=-110.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 KEqqOLtfmXQ3 for ; Wed, 12 Jan 2011 09:54:47 -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 D5F463A6808 for ; Wed, 12 Jan 2011 09:54:47 -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: ApUNALN6LU2rR7H+/2dsb2JhbACXU4VkglyELHOjWJhxhUwEhGg Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 12 Jan 2011 17:57:08 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0CHv7B2008398; Wed, 12 Jan 2011 17:57:07 GMT From: "Dan Wing" To: , "'Simon Perreault'" , References: <074.0ffa67fbfec724848038ffd8690553bf@tools.ietf.org> <4D2DDD17.7080004@viagenie.ca> <12343_1294852178_4D2DE052_12343_367309_1_94C682931C08B048B7A8645303FDC9F33C3FD7BD4C@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <12343_1294852178_4D2DE052_12343_367309_1_94C682931C08B048B7A8645303FDC9F33C3FD7BD4C@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 12 Jan 2011 09:57:07 -0800 Message-ID: <228e01cbb282$20fe4b20$62fae160$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuyeZabn1BRceD4QGqLOi3LMMeKlwAAWCKAAAG2g/A= Content-Language: en-us Subject: Re: [pcp] base #34 (new): notify NAT WAN address changed 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, 12 Jan 2011 17:54:49 -0000 To cover both cases, which I think are pretty closely related, I changed the text to read: "It may be useful to add a feature to PCP so that a PCP client can be immediately informed if either: a. the CPE's WAN address changed (if the CPE is a NAT), as discussed = in [http://tools.ietf.org/html/draft-boucadair-pcp-failure-00#section-2.5 Change of the CPE WAN IP Address], OR b. the PCP-controlled NAT's WAN address changed (if a LSN) As either will require obtaining new PCP mappings." -d =20 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange-ftgroup.com > Sent: Wednesday, January 12, 2011 9:10 AM > To: Simon Perreault; pcp@ietf.org > Subject: Re: [pcp] base #34 (new): notify NAT WAN address changed >=20 > Dear Simon, >=20 > The use of "external address" term is not appropriate in this case. >=20 > The issue described here is when there is a PCP Client behind a CPE; > the PCP Server is located upstream (not located in the CPE): how the > PCP Client is aware about the change of the assigned IP address on the > WAN interface of the CPE so that to trigger the update of the pinholes > it instructed on the PCP Server. >=20 > Cheers, > Med >=20 > -----Message d'origine----- > De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de > Simon Perreault > Envoy=E9 : mercredi 12 janvier 2011 17:56 > =C0 : pcp@ietf.org > Objet : Re: [pcp] base #34 (new): notify NAT WAN address changed >=20 > On 2011-01-12 11:52, pcp issue tracker wrote: > > It may be useful to add a feature to PCP so that a PCP client can = be > > immediately informed if the CPE WAN address changed, as that will > require > > obtaining new PCP mappings. >=20 > To use PCP terms, would it work if we say "external address" instead = of > "CPE WAN address"? This way it would apply to any PCP server, whether > it > is on a CPE or elsewhere. >=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 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp >=20 > ********************************* > This message and any attachments (the "message") are confidential and > intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, > changed or falsified. > If you are not the intended addressee of this message, please cancel = it > immediately and inform the sender. > ******************************** >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From dwing@cisco.com Wed Jan 12 10:22: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 666133A6B43 for ; Wed, 12 Jan 2011 10:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.235 X-Spam-Level: X-Spam-Status: No, score=-110.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_74=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 NI9n4rBWnRLF for ; Wed, 12 Jan 2011 10:22: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 1DFF63A6A64 for ; Wed, 12 Jan 2011 10:22:07 -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: Av0EAAeBLU2rR7Ht/2dsb2JhbACXU4xsc6NGmHeFTASEaA Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 12 Jan 2011 18:24:27 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0CIOQKK013927; Wed, 12 Jan 2011 18:24:27 GMT From: "Dan Wing" To: "'Simon Perreault'" , References: <074.0ffa67fbfec724848038ffd8690553bf@tools.ietf.org> <4D2DDD17.7080004@viagenie.ca> <12343_1294852178_4D2DE052_12343_367309_1_94C682931C08B048B7A8645303FDC9F33C3FD7BD4C@PUEXCB1B.nanterre.francetelecom.fr> <4D2DE9BD.5070301@viagenie.ca> In-Reply-To: <4D2DE9BD.5070301@viagenie.ca> Date: Wed, 12 Jan 2011 10:24:26 -0800 Message-ID: <22ad01cbb285$f2035410$d609fc30$@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: AcuygR5bKkalbXqiQ1OEYTKGzKPWHAABLDBw Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] base #34 (new): notify NAT WAN address changed 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, 12 Jan 2011 18:22:38 -0000 > On 2011-01-12 12:09, mohamed.boucadair@orange-ftgroup.com wrote: > > The issue described here is when there is a PCP Client behind a CPE; > > the PCP Server is located upstream (not located in the CPE): how the > > PCP Client is aware about the change of the assigned IP address on > > the WAN interface of the CPE so that to trigger the update of the > > pinholes it instructed on the PCP Server. > > I'm purposefully trying to avoid the term "CPE". PCP is applicable to > many scenarios, some of which don't involve a CPE at all. > > This is how I understand it (please correct if wrong): > > +----------+ +---------------+ +------------+ > |PCP client|---|NAT without PCP|---|NAT with PCP|--- Internet > +----------+ +---------------+ +------------+ > ^ ^ > external 1 external 2 > > You would want the PCP client to be notified with PCP when the external > address labelled "external 1" changes. Is that right? > > If so, two things: > > - How would the PCP server itself be notified of the change? > > - Where would the PCP server send the notification? It cannot reuse the > address+port of the last incoming PCP request since the UDP binding in > the NAT without PCP will very likely have expired. The answers will be written by someone that writes up the I-D. This was added to the tracker as 'enhancement'. I interpret 'enhancement' to mean "not in the base protocol". -d From simon.perreault@viagenie.ca Wed Jan 12 10:38: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 516CE3A6A62 for ; Wed, 12 Jan 2011 10:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 BVzSq5bcGfKa for ; Wed, 12 Jan 2011 10:38:31 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 7B65E3A6A3F for ; Wed, 12 Jan 2011 10:38:31 -0800 (PST) Received: from [206.123.31.83] (h83.viagenie.ca [206.123.31.83]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DDE0120D12; Wed, 12 Jan 2011 13:40:50 -0500 (EST) Message-ID: <4D2DF5B2.9000305@viagenie.ca> Date: Wed, 12 Jan 2011 13:40:50 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dan Wing References: <074.0ffa67fbfec724848038ffd8690553bf@tools.ietf.org> <4D2DDD17.7080004@viagenie.ca> <12343_1294852178_4D2DE052_12343_367309_1_94C682931C08B048B7A8645303FDC9F33C3FD7BD4C@PUEXCB1B.nanterre.francetelecom.fr> <4D2DE9BD.5070301@viagenie.ca> <22ad01cbb285$f2035410$d609fc30$@com> In-Reply-To: <22ad01cbb285$f2035410$d609fc30$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pcp@ietf.org Subject: Re: [pcp] base #34 (new): notify NAT WAN address changed 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, 12 Jan 2011 18:38:32 -0000 Le 12/01/2011 1:24 PM, Dan Wing a écrit : > The answers will be written by someone that writes up the I-D. This > was added to the tracker as 'enhancement'. I interpret 'enhancement' > to mean "not in the base protocol". Ah! Fine by me! (I still need to get used to the tracker...) Simon From phdgang@gmail.com Wed Jan 12 22:18: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 655013A6AB6 for ; Wed, 12 Jan 2011 22:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_75=0.6, 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 5XoDFXgRmgrx for ; Wed, 12 Jan 2011 22:18:19 -0800 (PST) Received: from mail-yi0-f42.google.com (mail-yi0-f42.google.com [209.85.218.42]) by core3.amsl.com (Postfix) with ESMTP id 80C7F3A6AB2 for ; Wed, 12 Jan 2011 22:18:19 -0800 (PST) Received: by yia28 with SMTP id 28so803442yia.15 for ; Wed, 12 Jan 2011 22:20:41 -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=nrVkWow+HaqJSLtNOci4Kh2s+Bb+EG0xCgXrmq2TORI=; b=U2xV33CjWMfMxyNrj+xF0/3ldvkF8X+I8x+uPX90Qj6Kd2b1WldZLy3msmrbG9Ydj+ rtkzEx6lKI13OlrJt83L8xUzyj8mo4c2nxfdhGchUl1u0xkuZYNrCsKnFcyzbXc9bfBA f6f6NmiYVMwHEY33Je0PfRjfhMCrD+cfYt8Ok= 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=R58qJ4AVLZvwB0v8V1kQ6ULcNiT/ieV8q+BOO7j/DWi7RHPN6SKZojd12Buk67rB1G Lus0Nqb1O4Gxuf5sGgBx8kaCSX7Pt4A/zlyNQOdiCXLSP+sJQfny0NEC3LZl1VHzupVX GWhCDkw8Dvy5H9UK0+LliBMABDcCOKjGxCGjw= MIME-Version: 1.0 Received: by 10.90.102.15 with SMTP id z15mr2675619agb.190.1294899640891; Wed, 12 Jan 2011 22:20:40 -0800 (PST) Received: by 10.90.27.1 with HTTP; Wed, 12 Jan 2011 22:20:38 -0800 (PST) In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC0143B8CC@ch-mailsrv.rd.francetelecom.fr> References: <0962B0BEF842A24191AD9BE41A8DD2FC0143B516@ch-mailsrv.rd.francetelecom.fr> <201101070828.p078Sg2e067840@givry.fdupont.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0143B671@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0143B8CC@ch-mailsrv.rd.francetelecom.fr> Date: Thu, 13 Jan 2011 14:20:38 +0800 Message-ID: From: GangChen To: xiaohong.deng@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Cc: lan.wang@orange-ftgroup.com, pcp@ietf.org Subject: Re: [pcp] XOR IP address in payloads 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, 13 Jan 2011 06:18:21 -0000 > > Would you explain why? I don't see why NAT-1 translates UDP payload/PCP > request from (internal ip: A0, external port: Px) to (internal ip: A1, > external port: Py), > because NAT-1s' WAN address A1 does *not* present in the PCP request > sent by host, even if "These overzealous ALGs modify UDP packets *where* > the > NAT's WAN address is in the UDP payload on a 32 bit boundary. "-- Quoted > from Dan's reply Let's see. NAT1 has the binding A0:Px<=>A1:Py. When PCP client send PCP request(payload: (internal ip: A0, internal port Px). The ALG hunt for IP address and rewrite,since they match a binding. PCP request payload is translated by NAT 1 to (internal ip: A1,external port: Py). The NAT2 responses PCP request (internal ip: A1,external port: Py),and replies with payload: (external ip: A2 (orany other IP addresses in NAT 2's address pool), internal IP address A1:Py). That is my understanding. Please correct me. BRs Gang From dwing@cisco.com Wed Jan 12 23:16: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 9FBD33A695B for ; Wed, 12 Jan 2011 23:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.22 X-Spam-Level: X-Spam-Status: No, score=-110.22 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, J_CHICKENPOX_75=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 gYC-R23olvIp for ; Wed, 12 Jan 2011 23:16: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 AEF443A68A8 for ; Wed, 12 Jan 2011 23:16: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: Av0EALo1Lk2rRN+K/2dsb2JhbACXWIxuc6MzmGuFTASEaIw/ Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 13 Jan 2011 07:19:02 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p0D7J2En016804; Thu, 13 Jan 2011 07:19:02 GMT From: "Dan Wing" To: "'GangChen'" , References: <0962B0BEF842A24191AD9BE41A8DD2FC0143B516@ch-mailsrv.rd.francetelecom.fr> <201101070828.p078Sg2e067840@givry.fdupont.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0143B671@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0143B8CC@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: Date: Wed, 12 Jan 2011 23:19:02 -0800 Message-ID: <02d201cbb2f2$278e2d50$76aa87f0$@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: Acuy6gNwLizYRumuQiKRxL3V2c9a+wAB0GMA Content-Language: en-us Cc: lan.wang@orange-ftgroup.com, pcp@ietf.org Subject: Re: [pcp] XOR IP address in payloads 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, 13 Jan 2011 07:16:41 -0000 Don't over-think it. The NATs with this behavior are only seeing packets going in and packets going out. Simplified, they do: host----[NAT with (broken) UDP ALG]---------[network] The problem is when the "NAT with the (broken) UDP ALG" device sees a UDP packet arrive from the right network (its "WAN" interface) and that UDP packet contains a payload on a 32 bit boundary that matches the NAT's WAN address, the NAT will change those 32 bits. It changes the 32 bits to become the internal host's IP address. When PCP is added to the mix, the question is: when a PCP message accidentally (1) or purposefully (2) traverses such a NAT, do we want PCP to protect its payload from such a NAT? On (1), accidental may happen if a subscriber installs one of these NATs in their home network. The one that has been sitting in their garage, for example. Or a new one they bought at a computer store. We don't know, and can't control, what sort of crazy ALGs are running in NATs. We _know_ that some NATs have done what is described in the top of this message. On (2), we might want to traverse a NAT, on purpose, to support nested NATs. Again, we don't know and can't tell if a NAT does this sort of UDP payload modification. We can protect against it, though. -d > -----Original Message----- > From: GangChen [mailto:phdgang@gmail.com] > Sent: Wednesday, January 12, 2011 10:21 PM > To: xiaohong.deng@orange-ftgroup.com > Cc: Francis.Dupont@fdupont.fr; dwing@cisco.com; pcp@ietf.org; > lan.wang@orange-ftgroup.com > Subject: Re: [pcp] XOR IP address in payloads > > > > > Would you explain why? I don't see why NAT-1 translates UDP > payload/PCP > > request from (internal ip: A0, external port: Px) to (internal ip: > A1, > > external port: Py), > > because NAT-1s' WAN address A1 does *not* present in the PCP request > > sent by host, even if "These overzealous ALGs modify UDP packets > *where* > > the > > NAT's WAN address is in the UDP payload on a 32 bit boundary. "-- > Quoted > > from Dan's reply > > > Let's see. NAT1 has the binding A0:Px<=>A1:Py. When PCP client send > PCP request(payload: (internal ip: A0, internal port Px). The ALG hunt > for IP address and rewrite,since they match a binding. PCP request > payload is translated by NAT 1 to (internal ip: A1,external port: Py). > The NAT2 responses PCP request (internal ip: A1,external port: Py),and > replies with payload: (external ip: A2 (orany other IP addresses in > NAT 2's address pool), internal IP address A1:Py). > > That is my understanding. Please correct me. > > BRs > > Gang From xiaohong.deng@orange-ftgroup.com Wed Jan 12 23:44: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 957533A6AB3 for ; Wed, 12 Jan 2011 23:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[AWL=0.862, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_75=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 zNx9XGnt4gAx for ; Wed, 12 Jan 2011 23:44:00 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 952043A6AB0 for ; Wed, 12 Jan 2011 23:44:00 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DE6C16C000C; Thu, 13 Jan 2011 08:46:49 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id D27BD6C0001; Thu, 13 Jan 2011 08:46:49 +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); Thu, 13 Jan 2011 08:46:21 +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: Thu, 13 Jan 2011 15:46:17 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC01480D12@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE:[pcp] XOR IP address in payloads Thread-Index: Acuy6gQfUw7aeSsUQqCrUvAs75KFKAACUH6A References: <0962B0BEF842A24191AD9BE41A8DD2FC0143B516@ch-mailsrv.rd.francetelecom.fr><201101070828.p078Sg2e067840@givry.fdupont.fr><0962B0BEF842A24191AD9BE41A8DD2FC0143B671@ch-mailsrv.rd.francetelecom.fr><0962B0BEF842A24191AD9BE41A8DD2FC0143B8CC@ch-mailsrv.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 13 Jan 2011 07:46:21.0439 (UTC) FILETIME=[F86680F0:01CBB2F5] Cc: lan.wang@orange-ftgroup.com, pcp@ietf.org Subject: Re: [pcp] XOR IP address in payloads 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, 13 Jan 2011 07:44:01 -0000 | |Let's see. NAT1 has the binding A0:Px<=3D>A1:Py. When PCP client=20 |send PCP request(payload: (internal ip: A0, internal port Px).=20 =3D=3D>First, NAT1 will not have this binding until it receives any PCP requests from this client; second, the internal port of binding is NOT the same as internal port in the PCP payload; so, assuming the binding A0:P0<=3D>A1:P1, and the PCP request should be (payload: (internal ip: A0, internal port Px).=20 |The ALG hunt for IP address and rewrite,since they match a=20 |binding. PCP request payload is translated by NAT 1 to=20 |(internal ip: A1,external port: Py). =3D=3D> The ALG will NOT rewrite this packet since fisrt its Niether = come from its "WAN" interface Nor its paylaod contains a payload on a 32 bit boundary that matches the NAT-1's WAN address A1. Besides, the payload will NOT match any NAT bindings either. |The NAT2 responses PCP request (internal ip: A1,external port:=20 |Py),and replies with payload: (external ip: A2 (orany other IP=20 |addresses in NAT 2's address pool), internal IP address A1:Py). | |That is my understanding. Please correct me. =3D=3D> Prove me wrong if you have other opinions. | |BRs | |Gang BR Xiaohong From phdgang@gmail.com Wed Jan 12 23:58: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 C5A743A69B5 for ; Wed, 12 Jan 2011 23:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 DFwG7GFEfCRt for ; Wed, 12 Jan 2011 23:58:14 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id DA9223A69B0 for ; Wed, 12 Jan 2011 23:58:13 -0800 (PST) Received: by gyd12 with SMTP id 12so632653gyd.31 for ; Thu, 13 Jan 2011 00:00:35 -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=NMBzxeqwvHZyy8DGZzVZ9GRTd2Eye0RLOd47AU3D0F0=; b=WXHZYyRbfCvO2TMz6bI9k8qCzO8hbf0lntbVCUabZTYgIsTeE6pGjt8VM0hjKv8Nc6 8OC3EVzqO0arzUWZLOxAZavl9TSTm9PWsCaEZGK5FPpknbnbawwTamM9f3hPm6DZUHIv d4cATMtEYrnuhKOsWb1vq6mEMnQmwchbfgfwA= 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=f4Z8b9c18GU+CsjPZ55fLJtJKWDgKn2d6zZ5w40cPMd/CP+6WUUO04tIvqKoxi4p6t DjIN2eZdBh5JVHXEjFig4dbDZCJzxcnCx3FeJTNMGCEVMRp1ktQEGoHQbNgMhWfnQO+c V0OFfDw+BUcpXdWkYZTQ1D0OvSk/tFUGwphwk= MIME-Version: 1.0 Received: by 10.91.42.29 with SMTP id u29mr2919461agj.99.1294905635351; Thu, 13 Jan 2011 00:00:35 -0800 (PST) Received: by 10.90.27.1 with HTTP; Thu, 13 Jan 2011 00:00:31 -0800 (PST) In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC01480D12@ch-mailsrv.rd.francetelecom.fr> References: <0962B0BEF842A24191AD9BE41A8DD2FC0143B516@ch-mailsrv.rd.francetelecom.fr> <201101070828.p078Sg2e067840@givry.fdupont.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0143B671@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0143B8CC@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC01480D12@ch-mailsrv.rd.francetelecom.fr> Date: Thu, 13 Jan 2011 16:00:31 +0800 Message-ID: From: GangChen To: xiaohong.deng@orange-ftgroup.com Content-Type: text/plain; charset=ISO-8859-1 Cc: lan.wang@orange-ftgroup.com, pcp@ietf.org Subject: Re: [pcp] XOR IP address in payloads 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, 13 Jan 2011 07:58:14 -0000 > ==>First, NAT1 will not have this binding until it receives any PCP > requests from this client; second, the internal port of binding is NOT > the same as internal port in the PCP payload; > so, assuming the binding A0:P0<=>A1:P1, and the PCP request should be > (payload: (internal ip: A0, internal port Px). It depends specific use cases. "Using PCP to Eliminate Application Keepalive Messages" could be the case. > > ==> The ALG will NOT rewrite this packet since fisrt its Niether come > from its "WAN" interface Nor its paylaod contains a payload on a 32 bit > boundary that matches the NAT-1's WAN address A1. Besides, the payload > will NOT match any NAT bindings either. I think that is related to first question. BRs Gang From xiaohong.deng@orange-ftgroup.com Thu Jan 13 00:17: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 ED6043A6AB7 for ; Thu, 13 Jan 2011 00:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[AWL=1.019, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 0XLfAiW0cHzO for ; Thu, 13 Jan 2011 00:17:23 -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 030193A6AB3 for ; Thu, 13 Jan 2011 00:17:22 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A631AFC400A; Thu, 13 Jan 2011 09:19:47 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 9A5ABFC4009; Thu, 13 Jan 2011 09:19:47 +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); Thu, 13 Jan 2011 09:19:43 +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: Thu, 13 Jan 2011 16:19:40 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC01480D51@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE:[pcp] XOR IP address in payloads Thread-Index: Acuy9/fr4Foe95enRDWm/i3WLAXJHQAAdPOg References: <0962B0BEF842A24191AD9BE41A8DD2FC0143B516@ch-mailsrv.rd.francetelecom.fr><201101070828.p078Sg2e067840@givry.fdupont.fr><0962B0BEF842A24191AD9BE41A8DD2FC0143B671@ch-mailsrv.rd.francetelecom.fr><0962B0BEF842A24191AD9BE41A8DD2FC0143B8CC@ch-mailsrv.rd.francetelecom.fr><0962B0BEF842A24191AD9BE41A8DD2FC01480D12@ch-mailsrv.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 13 Jan 2011 08:19:43.0958 (UTC) FILETIME=[A1FEA760:01CBB2FA] Cc: lan.wang@orange-ftgroup.com, pcp@ietf.org Subject: Re: [pcp] XOR IP address in payloads 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, 13 Jan 2011 08:17:24 -0000 |> =3D=3D>First, NAT1 will not have this binding until it receives any = PCP=20 |> requests from this client; second, the internal port of binding is=20 |> NOT the same as internal port in the PCP payload; so, assuming the=20 |> binding A0:P0<=3D>A1:P1, and the PCP request should be |> (payload: (internal ip: A0, internal port Px). | |It depends specific use cases. "Using PCP to Eliminate=20 |Application Keepalive Messages" could be the case. =3D=3D> I agree with you, it may happen that the payload port eqauls to binding port.=20 |> |> =3D=3D> The ALG will NOT rewrite this packet since fisrt its=20 |Niether come=20 |> from its "WAN" interface Nor its paylaod contains a payload on a 32=20 |> bit boundary that matches the NAT-1's WAN address A1. Besides, the=20 |> payload will NOT match any NAT bindings either. =3D=3D> Still, this PCP request does not satisfy the criteria to be = applied this kind of ALG. |I think that is related to first question. =3D=3D> what makes you think it's different? | |BRs | |Gang | BR, Xiaohong From xiaohong.deng@orange-ftgroup.com Thu Jan 13 00:17: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 9982E3A6AC8 for ; Thu, 13 Jan 2011 00:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_75=0.6, 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 voR9j29DpgLb for ; Thu, 13 Jan 2011 00:17:29 -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 7002A3A6AC5 for ; Thu, 13 Jan 2011 00:17:29 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1C2607D8005; Thu, 13 Jan 2011 09:24:28 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 1364F760007; Thu, 13 Jan 2011 09:24:28 +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); Thu, 13 Jan 2011 09:19:50 +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: Thu, 13 Jan 2011 16:19:47 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC01480D52@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <02d201cbb2f2$278e2d50$76aa87f0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE:[pcp] XOR IP address in payloads Thread-Index: Acuy6gNwLizYRumuQiKRxL3V2c9a+wAB0GMAAAFuydA= References: <0962B0BEF842A24191AD9BE41A8DD2FC0143B516@ch-mailsrv.rd.francetelecom.fr> <201101070828.p078Sg2e067840@givry.fdupont.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0143B671@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0143B8CC@ch-mailsrv.rd.francetelecom.fr> <02d201cbb2f2$278e2d50$76aa87f0$@com> From: To: , X-OriginalArrivalTime: 13 Jan 2011 08:19:50.0865 (UTC) FILETIME=[A61C9410:01CBB2FA] Cc: lan.wang@orange-ftgroup.com, pcp@ietf.org Subject: Re: [pcp] XOR IP address in payloads 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, 13 Jan 2011 08:17:30 -0000 |Don't over-think it. The NATs with this behavior are only=20 |seeing packets going in and packets going out. Simplified, they do: | | host----[NAT with (broken) UDP ALG]---------[network] | |The problem is when the "NAT with the (broken) UDP ALG" device=20 |sees a UDP packet arrive from the right network (its "WAN"=20 |interface) and that UDP packet contains a payload on a 32 bit=20 |boundary that matches the NAT's WAN address, the NAT will=20 |change those 32 bits. |It changes the 32 bits to become the internal host's IP address. =3D=3D> My point is I don't see that PCP request/response will satisfy = the criteria that been rewirtted by this kind of crazy NAT. Because there is no NAT's WAN address in the PCP response. The internal-ip-address filed of the PCP response should be the internal ip address of the PCP client instead of the NAT's WAN address. That's my understanding. Please correct me. |When PCP is added to the mix, the question is: when a PCP=20 |message accidentally (1) or purposefully (2) traverses such a=20 |NAT, do we want PCP to protect its payload from such a NAT? | |On (1), accidental may happen if a subscriber installs one of=20 |these NATs in their home network. The one that has been=20 |sitting in their garage, for example. Or a new one they=20 |bought at a computer store. We don't know, and can't control,=20 |what sort of crazy ALGs are running in NATs. We _know_ that=20 |some NATs have done what is described in the top of this message. |On (2), we might want to traverse a NAT, on purpose, to=20 |support nested NATs. Again, we don't know and can't tell if a=20 |NAT does this sort of UDP payload modification. |We can protect against it, though. =3D=3D> Anyway, I agree with you that the point is it to make it work. = When it comes to the goals of addressing it, I wonder which one is of higher priority.=20 1. Work over one existing NAPT in people's homes 2. Detect multiple existing NAPTs BR, Xiaohong | |-d | |> -----Original Message----- |> From: GangChen [mailto:phdgang@gmail.com] |> Sent: Wednesday, January 12, 2011 10:21 PM |> To: xiaohong.deng@orange-ftgroup.com |> Cc: Francis.Dupont@fdupont.fr; dwing@cisco.com; pcp@ietf.org;=20 |> lan.wang@orange-ftgroup.com |> Subject: Re: [pcp] XOR IP address in payloads |>=20 |> > |> > Would you explain why? I don't see why NAT-1 translates UDP |> payload/PCP |> > request from (internal ip: A0, external port: Px) to (internal ip: |> A1, |> > external port: Py), |> > because NAT-1s' WAN address A1 does *not* present in the PCP=20 |> > request sent by host, even if "These overzealous ALGs modify UDP=20 |> > packets |> *where* |> > the |> > NAT's WAN address is in the UDP payload on a 32 bit boundary. "-- |> Quoted |> > from Dan's reply |>=20 |>=20 |> Let's see. NAT1 has the binding A0:Px<=3D>A1:Py. When PCP client send = |> PCP request(payload: (internal ip: A0, internal port Px).=20 |The ALG hunt=20 |> for IP address and rewrite,since they match a binding. PCP request=20 |> payload is translated by NAT 1 to (internal ip: A1,external=20 |port: Py). |> The NAT2 responses PCP request (internal ip: A1,external=20 |port: Py),and=20 |> replies with payload: (external ip: A2 (orany other IP addresses in=20 |> NAT 2's address pool), internal IP address A1:Py). |>=20 |> That is my understanding. Please correct me. |>=20 |> BRs |>=20 |> Gang | | From dwing@cisco.com Thu Jan 13 00:27: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 D134A3A6AC3 for ; Thu, 13 Jan 2011 00:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.235 X-Spam-Level: X-Spam-Status: No, score=-110.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_75=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 PtI7TOx3WlZM for ; Thu, 13 Jan 2011 00:27:31 -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 183D33A6AB3 for ; Thu, 13 Jan 2011 00:27:31 -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: Av0EAJtGLk2rR7H+/2dsb2JhbACXWIxuc4gnmyyYbIVMBIRohFaHaQ Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 13 Jan 2011 08:29:53 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0D8Tq4p028866; Thu, 13 Jan 2011 08:29:52 GMT From: "Dan Wing" To: , References: <0962B0BEF842A24191AD9BE41A8DD2FC0143B516@ch-mailsrv.rd.francetelecom.fr> <201101070828.p078Sg2e067840@givry.fdupont.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0143B671@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0143B8CC@ch-mailsrv.rd.francetelecom.fr> <02d201cbb2f2$278e2d50$76aa87f0$@com> <0962B0BEF842A24191AD9BE41A8DD2FC01480D52@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC01480D52@ch-mailsrv.rd.francetelecom.fr> Date: Thu, 13 Jan 2011 00:29:52 -0800 Message-ID: <031501cbb2fc$0d0e6120$272b2360$@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: Acuy6gNwLizYRumuQiKRxL3V2c9a+wAB0GMAAAFuydAAAPJZMA== Content-Language: en-us Cc: lan.wang@orange-ftgroup.com, pcp@ietf.org Subject: Re: [pcp] XOR IP address in payloads 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, 13 Jan 2011 08:27:33 -0000 > -----Original Message----- > From: xiaohong.deng@orange-ftgroup.com [mailto:xiaohong.deng@orange- > ftgroup.com] > Sent: Thursday, January 13, 2011 12:20 AM > To: dwing@cisco.com; phdgang@gmail.com > Cc: Francis.Dupont@fdupont.fr; pcp@ietf.org; lan.wang@orange- > ftgroup.com > Subject: RE:[pcp] XOR IP address in payloads > > > |Don't over-think it. The NATs with this behavior are only > |seeing packets going in and packets going out. Simplified, they do: > | > | host----[NAT with (broken) UDP ALG]---------[network] > | > |The problem is when the "NAT with the (broken) UDP ALG" device > |sees a UDP packet arrive from the right network (its "WAN" > |interface) and that UDP packet contains a payload on a 32 bit > |boundary that matches the NAT's WAN address, the NAT will > |change those 32 bits. > |It changes the 32 bits to become the internal host's IP address. > > ==> My point is I don't see that PCP request/response will satisfy the > criteria that been rewirtted by this kind of crazy NAT. Because there > is > no NAT's WAN address in the PCP response. The internal-ip-address filed > of the PCP response should be the internal ip address of the PCP client > instead of the NAT's WAN address. That's my understanding. Please > correct me. The internal-ip-address could be the NAT's WAN address: * after doing STUN (RFC5389) and then using PCP (and putting the learned IP address into PCP's internal-ip-address field) or * after doing STUNT (http://nutss.gforge.cis.cornell.edu/stunt.php) and then doing PCP (and putting the learned IP address into PCP's internal-ip-address field) or * doing the Nested NAT procedure described on slides 7-9 of ftp://ftp-eng.cisco.com/dwing/pcp/pcp-nested-nat.pdf Do we want PCP to forever fail (in obscure ways) with NATs that rewrite UDP payloads such as I have described, or do we want PCP to work with such NATs. Teredo and STUN decided the additional complexity of an XOR operation was worthwhile and necessary for their protocols. I don't know all of the ways PCP might be deployed, and we (the industry) do not know how often these horrible UDP ALGs occur in the wild. To my eyes, the safest thing is to prevent the problem from occurring, such as XORing the address. > |When PCP is added to the mix, the question is: when a PCP > |message accidentally (1) or purposefully (2) traverses such a > |NAT, do we want PCP to protect its payload from such a NAT? > | > |On (1), accidental may happen if a subscriber installs one of > |these NATs in their home network. The one that has been > |sitting in their garage, for example. Or a new one they > |bought at a computer store. We don't know, and can't control, > |what sort of crazy ALGs are running in NATs. We _know_ that > |some NATs have done what is described in the top of this message. > > |On (2), we might want to traverse a NAT, on purpose, to > |support nested NATs. Again, we don't know and can't tell if a > |NAT does this sort of UDP payload modification. > |We can protect against it, though. > > ==> Anyway, I agree with you that the point is it to make it work. When > it comes to the goals of addressing it, I wonder which one is of higher > priority. > > 1. Work over one existing NAPT in people's homes > 2. Detect multiple existing NAPTs I stated my goals for nested NAT in another email. I'm happy to discuss those goals or re-prioritize them. At this point, I don't see much interest in the problem and I do not expect to include anything about nested NAT in draft-ietf-pcp-base, other than "it won't work without extensions to PCP and without documented procedures". -d > BR, > Xiaohong > > | > |-d > | > |> -----Original Message----- > |> From: GangChen [mailto:phdgang@gmail.com] > |> Sent: Wednesday, January 12, 2011 10:21 PM > |> To: xiaohong.deng@orange-ftgroup.com > |> Cc: Francis.Dupont@fdupont.fr; dwing@cisco.com; pcp@ietf.org; > |> lan.wang@orange-ftgroup.com > |> Subject: Re: [pcp] XOR IP address in payloads > |> > |> > > |> > Would you explain why? I don't see why NAT-1 translates UDP > |> payload/PCP > |> > request from (internal ip: A0, external port: Px) to (internal ip: > |> A1, > |> > external port: Py), > |> > because NAT-1s' WAN address A1 does *not* present in the PCP > |> > request sent by host, even if "These overzealous ALGs modify UDP > |> > packets > |> *where* > |> > the > |> > NAT's WAN address is in the UDP payload on a 32 bit boundary. "-- > |> Quoted > |> > from Dan's reply > |> > |> > |> Let's see. NAT1 has the binding A0:Px<=>A1:Py. When PCP client send > |> PCP request(payload: (internal ip: A0, internal port Px). > |The ALG hunt > |> for IP address and rewrite,since they match a binding. PCP request > |> payload is translated by NAT 1 to (internal ip: A1,external > |port: Py). > |> The NAT2 responses PCP request (internal ip: A1,external > |port: Py),and > |> replies with payload: (external ip: A2 (orany other IP addresses in > |> NAT 2's address pool), internal IP address A1:Py). > |> > |> That is my understanding. Please correct me. > |> > |> BRs > |> > |> Gang > | > | From xiaohong.deng@orange-ftgroup.com Thu Jan 13 01:14: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 659013A69EF for ; Thu, 13 Jan 2011 01:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.076 X-Spam-Level: X-Spam-Status: No, score=-1.076 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_75=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 cM03yT1Nzf1j for ; Thu, 13 Jan 2011 01:14:44 -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 D2D8D3A69EA for ; Thu, 13 Jan 2011 01:14:43 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9BF91FC4006; Thu, 13 Jan 2011 10:17:08 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 8DFBCFC4001; Thu, 13 Jan 2011 10:17:08 +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); Thu, 13 Jan 2011 10:17:04 +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: Thu, 13 Jan 2011 17:17:00 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC01480DAF@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <031501cbb2fc$0d0e6120$272b2360$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE:[pcp] XOR IP address in payloads Thread-Index: Acuy6gNwLizYRumuQiKRxL3V2c9a+wAB0GMAAAFuydAAAPJZMAABSLlQ References: <0962B0BEF842A24191AD9BE41A8DD2FC0143B516@ch-mailsrv.rd.francetelecom.fr> <201101070828.p078Sg2e067840@givry.fdupont.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0143B671@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0143B8CC@ch-mailsrv.rd.francetelecom.fr> <02d201cbb2f2$278e2d50$76aa87f0$@com> <0962B0BEF842A24191AD9BE41A8DD2FC01480D52@ch-mailsrv.rd.francetelecom.fr> <031501cbb2fc$0d0e6120$272b2360$@com> From: To: , X-OriginalArrivalTime: 13 Jan 2011 09:17:04.0978 (UTC) FILETIME=[A500A320:01CBB302] Cc: lan.wang@orange-ftgroup.com, pcp@ietf.org Subject: Re: [pcp] XOR IP address in payloads 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, 13 Jan 2011 09:14:45 -0000 |> |Don't over-think it. The NATs with this behavior are only seeing=20 |> |packets going in and packets going out. Simplified, they do: |> | |> | host----[NAT with (broken) UDP ALG]---------[network] |> | |> |The problem is when the "NAT with the (broken) UDP ALG"=20 |device sees a=20 |> |UDP packet arrive from the right network (its "WAN" |> |interface) and that UDP packet contains a payload on a 32 bit=20 |> |boundary that matches the NAT's WAN address, the NAT will change=20 |> |those 32 bits. |> |It changes the 32 bits to become the internal host's IP address. |>=20 |> =3D=3D> My point is I don't see that PCP request/response will = satisfy=20 |> the criteria that been rewirtted by this kind of crazy NAT. Because=20 |> there is no NAT's WAN address in the PCP response. The=20 |> internal-ip-address filed of the PCP response should be the internal=20 |> ip address of the PCP client instead of the NAT's WAN=20 |address. That's=20 |> my understanding. Please correct me. | |The internal-ip-address could be the NAT's WAN address: | | * after doing STUN (RFC5389) and then using PCP (and putting the | learned IP address into PCP's internal-ip-address field) or | * after doing STUNT (http://nutss.gforge.cis.cornell.edu/stunt.php) | and then doing PCP (and putting the learned IP address into | PCP's internal-ip-address field) |or =3D=3D>Thanks for your clearfication. I don't see as far as you. | * doing the Nested NAT procedure described on slides 7-9 of=20 | ftp://ftp-eng.cisco.com/dwing/pcp/pcp-nested-nat.pdf =3D=3D>When I saw the proposal for working over one existing NAPT in people's homes in the slides, I was thinking that if CPE support UPnP IWG and the present apps that speaks UPnP to CPE will work well in CGN scenarios, what will be the urgent need for app developers to implement PCP client in their apps? | |Do we want PCP to forever fail (in obscure ways) with NATs=20 |that rewrite UDP payloads such as I have described, or do we=20 |want PCP to work with such NATs. | |Teredo and STUN decided the additional complexity of an XOR=20 |operation was worthwhile and necessary for their protocols. | |I don't know all of the ways PCP might be deployed, and we (the |industry) do not know how often these horrible UDP ALGs occur=20 |in the wild. To my eyes, the safest thing is to prevent the=20 |problem from occurring, such as XORing the address. | |> |When PCP is added to the mix, the question is: when a PCP message=20 |> |accidentally (1) or purposefully (2) traverses such a NAT,=20 |do we want=20 |> |PCP to protect its payload from such a NAT? |> | |> |On (1), accidental may happen if a subscriber installs one of these=20 |> |NATs in their home network. The one that has been sitting in their=20 |> |garage, for example. Or a new one they bought at a=20 |computer store. =20 |> |We don't know, and can't control, what sort of crazy ALGs=20 |are running=20 |> |in NATs. We _know_ that some NATs have done what is=20 |described in the=20 |> |top of this message. |>=20 |> |On (2), we might want to traverse a NAT, on purpose, to support=20 |> |nested NATs. Again, we don't know and can't tell if a NAT=20 |does this=20 |> |sort of UDP payload modification. |> |We can protect against it, though. |>=20 |> =3D=3D> Anyway, I agree with you that the point is it to make it = work.=20 |> When it comes to the goals of addressing it, I wonder which=20 |one is of=20 |> higher priority. |>=20 |> 1. Work over one existing NAPT in people's homes |> 2. Detect multiple existing NAPTs | |I stated my goals for nested NAT in another email. I'm happy=20 |to discuss those goals or re-prioritize them. At this point,=20 |I don't see much interest in the problem and I do not expect=20 |to include anything about nested NAT in draft-ietf-pcp-base,=20 |other than "it won't work without extensions to PCP and=20 |without documented procedures". | |-d | |> BR, |> Xiaohong |>=20 |> | |> |-d |> | |> |> -----Original Message----- |> |> From: GangChen [mailto:phdgang@gmail.com] |> |> Sent: Wednesday, January 12, 2011 10:21 PM |> |> To: xiaohong.deng@orange-ftgroup.com |> |> Cc: Francis.Dupont@fdupont.fr; dwing@cisco.com; pcp@ietf.org;=20 |> |> lan.wang@orange-ftgroup.com |> |> Subject: Re: [pcp] XOR IP address in payloads |> |> |> |> > |> |> > Would you explain why? I don't see why NAT-1 translates UDP |> |> payload/PCP |> |> > request from (internal ip: A0, external port: Px) to=20 |(internal ip: |> |> A1, |> |> > external port: Py), |> |> > because NAT-1s' WAN address A1 does *not* present in the PCP=20 |> |> > request sent by host, even if "These overzealous ALGs=20 |modify UDP=20 |> |> > packets |> |> *where* |> |> > the |> |> > NAT's WAN address is in the UDP payload on a 32 bit=20 |boundary. "-- |> |> Quoted |> |> > from Dan's reply |> |> |> |> |> |> Let's see. NAT1 has the binding A0:Px<=3D>A1:Py. When PCP=20 |client send=20 |> |> PCP request(payload: (internal ip: A0, internal port Px). |> |The ALG hunt |> |> for IP address and rewrite,since they match a binding.=20 |PCP request=20 |> |> payload is translated by NAT 1 to (internal ip: A1,external |> |port: Py). |> |> The NAT2 responses PCP request (internal ip: A1,external |> |port: Py),and |> |> replies with payload: (external ip: A2 (orany other IP=20 |addresses in=20 |> |> NAT 2's address pool), internal IP address A1:Py). |> |> |> |> That is my understanding. Please correct me. |> |> |> |> BRs |> |> |> |> Gang |> | |> | | | From dwing@cisco.com Thu Jan 13 01:53: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 8C05B3A6825 for ; Thu, 13 Jan 2011 01:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.532 X-Spam-Level: X-Spam-Status: No, score=-110.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 9PE+5vHZ29WU for ; Thu, 13 Jan 2011 01:53:43 -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 6799F3A6B5D for ; Thu, 13 Jan 2011 01:53:43 -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: Av0EAP9aLk2rR7H+/2dsb2JhbACXWIxuc6NfmGeFTASEaA Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 13 Jan 2011 09:56:05 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0D9u5cJ001864; Thu, 13 Jan 2011 09:56:05 GMT From: "Dan Wing" To: , References: <0962B0BEF842A24191AD9BE41A8DD2FC0143B516@ch-mailsrv.rd.francetelecom.fr> <201101070828.p078Sg2e067840@givry.fdupont.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0143B671@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC0143B8CC@ch-mailsrv.rd.francetelecom.fr> <02d201cbb2f2$278e2d50$76aa87f0$@com> <0962B0BEF842A24191AD9BE41A8DD2FC01480D52@ch-mailsrv.rd.francetelecom.fr> <031501cbb2fc$0d0e6120$272b2360$@com> <0962B0BEF842A24191AD9BE41A8DD2FC01480DAF@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC01480DAF@ch-mailsrv.rd.francetelecom.fr> Date: Thu, 13 Jan 2011 01:56:05 -0800 Message-ID: <035e01cbb308$17fe4080$47fac180$@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: Acuy6gNwLizYRumuQiKRxL3V2c9a+wAB0GMAAAFuydAAAPJZMAABSLlQAAG+B+A= Content-Language: en-us Cc: lan.wang@orange-ftgroup.com, pcp@ietf.org Subject: Re: [pcp] XOR IP address in payloads 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, 13 Jan 2011 09:53:44 -0000 ... > | * doing the Nested NAT procedure described on slides 7-9 of > | ftp://ftp-eng.cisco.com/dwing/pcp/pcp-nested-nat.pdf > > ==>When I saw the proposal for working over one existing NAPT in > people's homes in the slides, I was thinking that if CPE support UPnP > IWG and the present apps that speaks UPnP to CPE will work well in CGN > scenarios, what will be the urgent need for app developers to implement > PCP client in their apps? There are two ways an application can get a pinholes created so the application can operate a server: * Add PCP to their applications (or calling OS-provided frameworks), to speak directly to the ISP's large-scale NAT. And, if there is also another NAT in the home, speak to it using UPnP IGD. This may require telling the user to enable UPnP IGD on their existing NAT (as many are shipped with it disabled at the factory or by the ISP's preference [for CPE partially managed or shipped by the ISP]). OR * Tell the user (trying to use the application) to buy a new NAT, specifically a new NAT that includes a UPnP IGD->PCP interworking function. This is an additional $40-80 cost to the user, and this new NAT may not include the features of their old NAT (some NATs include Z-Wave or ZigBee radios (for home automation), others include NAS disks, 802.11n with fancy-sounding acceleration technology, and so on). OR * Tell the user to throw away the existing NAT in their home. This causes a loss of functionality to the user, such as losing WiFi in a part of their house, reconfiguring their network, etc. The user must have purchased and installed the NAT for some legitimate reason, afterall. Maybe there are more options. I expect the first option will be most successful. -d From trac@tools.ietf.org Thu Jan 13 09:03: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 5AEB73A6B21 for ; Thu, 13 Jan 2011 09:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.014, 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 XAWx2jUytQrR for ; Thu, 13 Jan 2011 09:03:52 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B47973A6B15 for ; Thu, 13 Jan 2011 09:03:52 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PdQcp-0007Ww-Ix; Thu, 13 Jan 2011 09:06: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: dwing@cisco.com X-Trac-Project: pcp Date: Thu, 13 Jan 2011 17:06:15 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/35 Message-ID: <053.b2b17c91c0f5b0d4ee1c339d09ccde0f@tools.ietf.org> X-Trac-Ticket-ID: 35 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] base #35 (new): 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: Thu, 13 Jan 2011 17:03:53 -0000 #35: clients don't know address family of server A host operating a pure client seldom knows or cares about the address family of the server; a host host operating a symmetric client/server sometimes also does not know or care. Thus, the PCP client could mistakenly use the PIN44 OpCode when it should have used PIN46. This is unfortunately not fully handled by REMOTE_PEER's inclusion of address family from the PCP client's perspective. Do we want to resolve this? If so, how -- perhaps adjust all of the PIN opcodes to effectively incorporate the REMOTE_PEER semantic? -- -----------------------------+---------------------------------------------- Reporter: dwing@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: -----------------------------+---------------------------------------------- Ticket URL: pcp From dwing@cisco.com Thu Jan 13 09: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 649E928C125 for ; Thu, 13 Jan 2011 09:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.533 X-Spam-Level: X-Spam-Status: No, score=-110.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 V4FQIapLtxnS for ; Thu, 13 Jan 2011 09:17:27 -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 11D3F28C112 for ; Thu, 13 Jan 2011 09:17:27 -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: Av0EAEvDLk2rR7H+/2dsb2JhbACXWYxvc6RImE2CdoJWBIRo Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 13 Jan 2011 17:19:50 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0DHJngS003494; Thu, 13 Jan 2011 17:19:49 GMT From: "Dan Wing" To: , "'Francis Dupont'" , "'Simon Perreault'" References: Your message of Mon, 10 Jan 2011 08:45:02 EST. <4D2B0D5E.5030302@viagenie.ca> <201101102301.p0AN1rcs084678@givry.fdupont.fr> <19ba01cbb122$f11dfd70$d359f850$@com> <837_1294728928_4D2BFEE0_837_116100_1_94C682931C08B048B7A8645303FDC9F33C3FD7B3C4@PUEXCB1B.nanterre.francetelecom.fr> <1d8901cbb1b5$e093ca50$a1bb5ef0$@com> <22350_1294815325_4D2D505D_22350_100240_1_94C682931C08B048B7A8645303FDC9F33C3FD7B99E@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <22350_1294815325_4D2D505D_22350_100240_1_94C682931C08B048B7A8645303FDC9F33C3FD7B99E@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 13 Jan 2011 09:19:49 -0800 Message-ID: <048f01cbb346$1583c170$408b4450$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuxGnH/oFEq0BUFQIqUfjE7XufIxwABnQoQAA6BC4AAFMrhsAAdWvDwAERBjVA= Content-Language: en-us Cc: pcp@ietf.org Subject: [pcp] client/server/symmetric [was RE: PCP-base 02: Section 7.7] 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, 13 Jan 2011 17:17:28 -0000 ... > SIP UA PCP server SIP proxy > | | | > |--SIP REGISTER, rport------------------------->| > |<-Ok, port=3D12345-------------------------------| > | | | > |-PIN44, REMOTE_PEER=3D->| | > |<--lifetime=3D3600, ext-port=3D12345-| | > | | | >=20 > What is the disadvantage of reducing SIP keepalives that way? >=20 > Med: The use of "rport" allows the SIP Proxy to answer to the source > port number and not to the one indicated in the via header but it does > not help the SIP proxy server to detect the lifetime of the nat = binding > in the path; Agreed. But it is not the SIP proxy's job to keep the NAT binding alive. It is the SIP UA's job to do that, and the SIP UA sends those keepalives. > therefore a lower expire timers (e.g., 30 or 60s) will be > returned by the SIP Proxy to the SIP UA to maintain such binding. The > SIP UA has to refresh its registration before the expiry of the > returned expiry timer. The PCP request does not help in such case. In > some deployments "rport" is not used but SBCs "emulate" a similar > functionality but this does not prevent frequent re-registration > messages (not forwarded to the core service elements btw). Keepalive > messages have a SEVERE impact on the performance of the SBC (60% > degradation). In both the cases you describe above, it is the SIP UA that is generating the keepalive messages. It is the SIP UA that can reduce the frequency of those messages when it (a) determines it has only PCP-controlled NATs on the path and (b) knows the lifetime of the mappings in those NATs. This new knowledge in the SIP UA may require changes to SIP's signaling. > This is why I prefer to present a SIP message to the SIP > proxy without rport but with the external IP/port assigned by the nat > in the path. This would be a hint for the proxy server to return an > expire timer with greater value. "rport" could be removed, but only if we have the SIP UA open its=20 port differently from how it does it today. See below. > For RTP, message flow would be like this, again doing connect-then- > lifetime. > The difference is we don't get anything like an "rport=3DNNN" from the > remote > peer. But, we don't need it anyway except to detect a rogue NAT on = the > path > between the PCP-controlled NAT and the RTP peer. If the SIP UA wanted > to > detect such a rogue NAT, it would need to send ICE (STUN) messages to > the > RTP peer. >=20 > Med: Why not doing it simple, use the even_plus_one option to get the > ports; use those ports to build the offer/answer and issue the = request. > We don't need ICE/STUN/etc. I did not suggest or propose using ICE/STUN to open pinholes. Rather, I = suggested using ICE (STUN) to detect a rogue NAT. By 'rogue', I mean a=20 NAT that is not running PCP but is on the media path. But please see below. > SIP UA PCP server RTP peer > | | | > |--RTP message--------------------------------->| > |--RTP message--------------------------------->| > |--... more RTP messages ...------------------->| > |--RTP message--------------------------------->| > | | | > |-PIN44, REMOTE_PEER=3D=3D->| | > |<--lifetime=3D3600, ext-port=3D12345-| | > | | | >=20 > As with SIP, the SIP UA does not need to be in a hurry to communicate > with > the PCP server. I stepped back from the problem and came to a different way to view this, which I have added to my work-in-progress copy of -03. This new text reads: "7.1. Use Cases for PIN OpCodes There are three uses for these PIN OpCodes: 1. a host operating a server (e.g., a web server). For this, the application needs to (a) create a pinhole from a public IP address and port to itself and (b) publish that public IP address and port to some sort of rendezvous server (e.g., DNS, a SIP message, a proprietary protocol). To accomplish this, the application follows the procedures described in Section 7.1.1. [7.1.1 is a new section titled "Using PCP to Operate a Server", which says you need to bind to an non-ephemeral port for your application's exclusive use.] 2. a host operating a client (e.g., XMPP client, SIP client). For this, the application wants to ensure its connection is not terminated prematurely (due to inactivity) by an on-path NAT or firewall. To accomplish this, the application uses the procedures described in Section 7.1.2. [7.1.2 is -02's Section 7.7 "Using PCP to Eliminate=20 Application Keepalive Messages"] 3. a host operating a client and server on the same port (e.g., Symmetric RTP [RFC4961] or SIP Symmetric Response Routing (rport) = [RFC3581]). For this, the application desires properties of=20 both (1) and (2), and uses the procedures described in Section=20 7.1.3. [7.1.3 is a new section titled "Using PCP to Operate a=20 Symmetric Client/Server", which combines aspects of (1) and (2).]" I believe this is much more clear about how the PCP-enabled application=20 should utilize PCP to meet its needs. Related, I created a new ticket, Issue #35, which is something Simon=20 and I had discussed offline, but I don't think we achieved clarity on=20 the problem. I now think the problem is clearer. Included in -03 will be the following (which is the same as in Issue #35), [Ed. Note: A host operating a pure client (2) seldom knows or cares about the address family of the server; a host=20 operating a symmetric client/server (3) sometimes also does not know or care. Thus, the PCP client could mistakenly use the PIN44 OpCode when it should have used PIN46. This is unfortunately not fully handled by REMOTE_PEER's inclusion of address family from the PCP client's perspective. Do we want to resolve this? If so, how -- perhaps adjust all of the PIN opcodes to effectively incorporate the REMOTE_PEER semantic? This is tracked as PCP Issue #35] http://trac.tools.ietf.org/wg/pcp/trac/ticket/35 Thoughts / comments on Issue #35? -d > -d >=20 >=20 > > Cheers, > > Med > > > > -----Message d'origine----- > > De : Dan Wing [mailto:dwing@cisco.com] > > Envoy=E9 : mardi 11 janvier 2011 01:03 > > =C0 : 'Francis Dupont'; 'Simon Perreault'; BOUCADAIR Mohamed > OLNC/NAD/TIP > > Cc : pcp@ietf.org > > Objet : RE: [pcp] PCP-base 02: Section 7.7 > > > > > > > > > -----Original Message----- > > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf > Of > > > Francis Dupont > > > Sent: Monday, January 10, 2011 3:02 PM > > > To: Simon Perreault > > > Cc: pcp@ietf.org > > > Subject: Re: [pcp] PCP-base 02: Section 7.7 > > > > > > > > > In your previous mail you wrote: > > > > > > Note that this was discussed in the virtual interim meeting. I > > seem > > > to > > > recall the consensus being that the advantage of easy = deployment > > > outweighed the disadvantages. > > > > > > =3D> I am afraid this argument would not close the subject... > > > and there was no consensus, just a 'go to next point'. > > > > > > (Were the minutes of the meeting posted?) > > > > > > =3D> +1! > > > > > > Francis.Dupont@fdupont.fr > > > > > > PS: BTW the 'ease of deployment' is not a good argument as it > applied > > > only on hosts, not on NATs, when IMHO at least 50% of the deployed > > > base won't support it. > > > > For reference, this is Issue #17, > > http://trac.tools.ietf.org/wg/pcp/trac/ticket/17 > > > > In the post http://www.ietf.org/mail- > > archive/web/pcp/current/msg00474.html, > > Simon described the host implementation difficulty. This got > agreement > > from > > Dave Thaler, http://www.ietf.org/mail- > > archive/web/pcp/current/msg00475.html > > and Lars Eggert, > > http://www.ietf.org/mail-archive/web/pcp/current/msg00480.html. > > > > I do not find a post that describes the NAT implementation > difficulty. > > > > I found posts that suggest NATs want to have different port ranges > for > > PCP-controlled ports than for dynamically-created connections. > That's > > makes > > some sense when the user is operating a server. But I don't > understand > > how > > separate NAT port ranges are helpful/necessary for the application > > keepalives case. > > > > If this does help the NAT, it seems we will need to force (MUST) the > > hosts > > to allocate a source port in the non-ephemeral port range and follow > > the > > other steps described in > > http://www.ietf.org/mail-archive/web/pcp/current/msg00474.html. > > > > -d > > > > > > > > > > ********************************* > > This message and any attachments (the "message") are confidential = and > > intended solely for the addressees. > > Any unauthorised use or dissemination is prohibited. > > Messages are susceptible to alteration. > > France Telecom Group shall not be liable for the message if altered, > > changed or falsified. > > If you are not the intended addressee of this message, please cancel > it > > immediately and inform the sender. > > ******************************** >=20 >=20 > ********************************* > This message and any attachments (the "message") are confidential and > intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, > changed or falsified. > If you are not the intended addressee of this message, please cancel = it > immediately and inform the sender. > ******************************** From Francis.Dupont@fdupont.fr Thu Jan 13 13:48: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 1D9613A6BE0 for ; Thu, 13 Jan 2011 13:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[AWL=0.042, 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 m+RmSnIEtGGC for ; Thu, 13 Jan 2011 13:48:36 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 1464B3A6BDE for ; Thu, 13 Jan 2011 13:48: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 p0DLowX9039947; Thu, 13 Jan 2011 22:50:58 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101132150.p0DLowX9039947@givry.fdupont.fr> From: Francis Dupont To: Simon Perreault In-reply-to: Your message of Mon, 10 Jan 2011 18:37:48 EST. <4D2B984C.5020407@viagenie.ca> Date: Thu, 13 Jan 2011 22:50:58 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] PCP-base 02: Section 7.7 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, 13 Jan 2011 21:48:37 -0000 In your previous mail you wrote: Le 10/01/2011 6:01 PM, Francis Dupont a écrit : > PS: BTW the 'ease of deployment' is not a good argument as it applied > only on hosts, not on NATs, when IMHO at least 50% of the deployed > base won't support it. This is the first time I hear this argument. Can you explain why 50% of existing NATs would not support connect-then-keepalive? => on a Linux: man iptables To summary connect-then-keepalive assumes dynamic and PCP mappings are the same and it is at least fully false on the most common NAT code, in particular on small boxes. It would be very unfortunate if we had option A be unimplementable on hosts and option B be unimplementable on NATs... => this is why to design something without taking care of the existing is IMHO not the best (:-). Regards Francis.Dupont@fdupont.fr PS: in fact Linux NAT is not EIM/EIF: it is either (== on choice) EIM/APDF or APDM. From Francis.Dupont@fdupont.fr Thu Jan 13 13:56: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 5112C3A6BE2 for ; Thu, 13 Jan 2011 13:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[AWL=0.042, 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 DzrMQqENP4oz for ; Thu, 13 Jan 2011 13:56:12 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 0DDC93A687E for ; Thu, 13 Jan 2011 13:56:11 -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 p0DLwZvQ040602; Thu, 13 Jan 2011 22:58:35 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101132158.p0DLwZvQ040602@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Mon, 10 Jan 2011 16:03:13 PST. <19ba01cbb122$f11dfd70$d359f850$@com> Date: Thu, 13 Jan 2011 22:58:35 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] PCP-base 02: Section 7.7 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, 13 Jan 2011 21:56:13 -0000 In your previous mail you wrote: I do not find a post that describes the NAT implementation difficulty. => you can find many posts saying than the hypothesis "dynamic mapping == PCP mapping" is not always true. (cf ticket #9) I found posts that suggest NATs want to have different port ranges for PCP-controlled ports than for dynamically-created connections. That's makes some sense when the user is operating a server. But I don't understand how separate NAT port ranges are helpful/necessary for the application keepalives case. => with separate NAT port ranges either the PCP request will fail or it returns another external port. In both cases it won't do what is expected, i.e., the request won't change the lifetime of the dynamic mapping. If this does help the NAT, it seems we will need to force (MUST) the hosts to allocate a source port in the non-ephemeral port range and follow the other steps described in http://www.ietf.org/mail-archive/web/pcp/current/msg00474.html. => the issue is with the external port so the choice of the internal port by the host won't help. Regards Francis.Dupont@fdupont.fr PS: note it is possible to fall back on the lifetime-than-connect strategy but it introduces delay and complexity. From dwing@cisco.com Thu Jan 13 17:39: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 5A4CE3A672F for ; Thu, 13 Jan 2011 17:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.534 X-Spam-Level: X-Spam-Status: No, score=-110.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 SkboFlBRa5Vh for ; Thu, 13 Jan 2011 17:39: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 637A03A65A6 for ; Thu, 13 Jan 2011 17:39:14 -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: AssFAAI4L02rR7H+/2dsb2JhbACWOYEljG9zpCWYSYVMBIRo Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 14 Jan 2011 01:41:38 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0E1fc9h017866; Fri, 14 Jan 2011 01:41:38 GMT From: "Dan Wing" To: References: Your message of Mon, 10 Jan 2011 16:03:13 PST. <19ba01cbb122$f11dfd70$d359f850$@com> <201101132158.p0DLwZvQ040602@givry.fdupont.fr> In-Reply-To: <201101132158.p0DLwZvQ040602@givry.fdupont.fr> Date: Thu, 13 Jan 2011 17:41:38 -0800 Message-ID: <07cd01cbb38c$2f87e6a0$8e97b3e0$@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: AcuzbQzvWDECAAf4RjqZCVioZkrusAAHpiAQ Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] PCP-base 02: Section 7.7 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, 14 Jan 2011 01:39:15 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Thursday, January 13, 2011 1:59 PM > To: Dan Wing > Cc: 'Simon Perreault'; mohamed.boucadair@orange-ftgroup.com; > pcp@ietf.org > Subject: Re: [pcp] PCP-base 02: Section 7.7 > > > In your previous mail you wrote: > > I do not find a post that describes the NAT implementation > difficulty. > > => you can find many posts saying than the hypothesis "dynamic mapping > == > PCP mapping" is not always true. > (cf ticket #9) > > I found posts that suggest NATs want to have different port ranges > for > PCP-controlled ports than for dynamically-created connections. > That's makes > some sense when the user is operating a server. But I don't > understand how > separate NAT port ranges are helpful/necessary for the application > keepalives case. > > => with separate NAT port ranges either the PCP request will fail or it > returns > another external port. In both cases it won't do what is expected, > i.e., > the request won't change the lifetime of the dynamic mapping. I have an idea, which I am writing into -03, which takes a different approach to solve the problem. I believe it works. However, I do not understand the purpose of the PCP server using different pools for PCP-controlled mappings and for dynamic mappings. That is, I do not see the advantage to to _preventing_ an application from learning the lifetime of its dynamic mapping. You and Med have said there is some advantage to forcing the application to first send a PCP message. I have not understood what advantage that brings to the NAT's implementation or to the NAT's operation. Can you please elaborate the advantage. -d > If this does help the NAT, it seems we will need to force (MUST) the > hosts > to allocate a source port in the non-ephemeral port range and follow > the > other steps described in > http://www.ietf.org/mail-archive/web/pcp/current/msg00474.html. > > => the issue is with the external port so the choice of the internal > port > by the host won't help. > > Regards > > Francis.Dupont@fdupont.fr > > PS: note it is possible to fall back on the lifetime-than-connect > strategy > but it introduces delay and complexity. From dwing@cisco.com Thu Jan 13 17:57: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 2CB973A67AE for ; Thu, 13 Jan 2011 17:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.535 X-Spam-Level: X-Spam-Status: No, score=-110.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 ee0Awqk8mnHT for ; Thu, 13 Jan 2011 17:57:53 -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 757E13A6778 for ; Thu, 13 Jan 2011 17:57:53 -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: Av0EACo9L02rR7Hu/2dsb2JhbACXXoxvc6QlmE2FTASEaA Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 14 Jan 2011 02:00:17 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0E20HIB027055; Fri, 14 Jan 2011 02:00:17 GMT From: "Dan Wing" To: "'Francis Dupont'" , "'Simon Perreault'" References: Your message of Mon, 10 Jan 2011 18:37:48 EST. <4D2B984C.5020407@viagenie.ca> <201101132150.p0DLowX9039947@givry.fdupont.fr> In-Reply-To: <201101132150.p0DLowX9039947@givry.fdupont.fr> Date: Thu, 13 Jan 2011 18:00:17 -0800 Message-ID: <07d101cbb38e$ca9ac660$5fd05320$@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: Acuza/rA8WN7ULM7QKGJNEgHy/sPjgAIoh7w Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] PCP-base 02: Section 7.7 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, 14 Jan 2011 01:57:54 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Francis Dupont > Sent: Thursday, January 13, 2011 1:51 PM > To: Simon Perreault > Cc: pcp@ietf.org > Subject: Re: [pcp] PCP-base 02: Section 7.7 > > In your previous mail you wrote: > > Le 10/01/2011 6:01 PM, Francis Dupont a icrit : > > PS: BTW the 'ease of deployment' is not a good argument as it > applied > > only on hosts, not on NATs, when IMHO at least 50% of the deployed > > base won't support it. > > This is the first time I hear this argument. Can you explain why 50% > of > existing NATs would not support connect-then-keepalive? > > => on a Linux: man iptables > To summary connect-then-keepalive assumes dynamic and PCP mappings are > the same > and it is at least fully false on the most common NAT code, in > particular on small boxes. You're saying PCP cannot dip into the NAT state table for an existing connection, examine (or increase) the lifetime of the mapping, and return that value? -d > It would be very unfortunate if we had option A be unimplementable > on > hosts and option B be unimplementable on NATs... > > => this is why to design something without taking care of the existing > is IMHO not the best (:-). > > Regards > > Francis.Dupont@fdupont.fr > > PS: in fact Linux NAT is not EIM/EIF: it is either (== on choice) > EIM/APDF or APDM. From Francis.Dupont@fdupont.fr Fri Jan 14 01:50: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 A4F1E3A69EF for ; Fri, 14 Jan 2011 01:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[AWL=0.042, 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 DoUfhLbqRNcT for ; Fri, 14 Jan 2011 01:50:43 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id A9D2D3A69EA for ; Fri, 14 Jan 2011 01:50:42 -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 p0E9r69S085718; Fri, 14 Jan 2011 10:53:06 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101140953.p0E9r69S085718@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Thu, 13 Jan 2011 18:00:17 PST. <07d101cbb38e$ca9ac660$5fd05320$@com> Date: Fri, 14 Jan 2011 10:53:06 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] PCP-base 02: Section 7.7 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, 14 Jan 2011 09:50:44 -0000 In your previous mail you wrote: You're saying PCP cannot dip into the NAT state table for an existing connection, examine (or increase) the lifetime of the mapping, and return that value? => I say we can't require all NAT implementations to perform operations you cite for dynamic mappings. And BTW this is out of the charter which is for NATs only about port forwarding. Regards Francis.Dupont@fdupont.fr From dwing@cisco.com Fri Jan 14 03:36: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 B03113A6C5D for ; Fri, 14 Jan 2011 03:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 jZvdVVVu0+1i for ; Fri, 14 Jan 2011 03:36: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 E898D3A6C5E for ; Fri, 14 Jan 2011 03:36:16 -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: AvsFAO/DL02rRN+J/2dsb2JhbACWQIEmjHBzpBeYQYVPBIRr Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 14 Jan 2011 11:38:42 +0000 Received: from dwingWS ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p0EBcfDO026281; Fri, 14 Jan 2011 11:38:42 GMT From: "Dan Wing" To: References: Your message of Thu, 13 Jan 2011 18:00:17 PST. <07d101cbb38e$ca9ac660$5fd05320$@com> <201101140953.p0E9r69S085718@givry.fdupont.fr> In-Reply-To: <201101140953.p0E9r69S085718@givry.fdupont.fr> Date: Fri, 14 Jan 2011 03:38:41 -0800 Message-ID: <00c601cbb3df$9809a940$c81cfbc0$@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: Acuz0N4KxXQ7QfbLSsug3rdCkBgUPQADih3A Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] PCP-base 02: Section 7.7 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, 14 Jan 2011 11:36:17 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Friday, January 14, 2011 1:53 AM > To: Dan Wing > Cc: 'Simon Perreault'; pcp@ietf.org > Subject: Re: [pcp] PCP-base 02: Section 7.7 > > > In your previous mail you wrote: > > You're saying PCP cannot dip into the NAT state table for an > existing connection, examine (or increase) the lifetime of the > mapping, > and return that value? > > => I say we can't require all NAT implementations to perform > operations you cite for dynamic mappings. And several people have said we can't require all applications developers to do complicated socket allocations in order to bring up a simple TCP client and optimize its keepalives. > And BTW this is out of > the charter which is for NATs only about port forwarding. I see. -d From simon.perreault@viagenie.ca Fri Jan 14 05:49: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 854C63A6B7F for ; Fri, 14 Jan 2011 05:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 99wMudxzcS85 for ; Fri, 14 Jan 2011 05:49:54 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 5AC5A3A6B7A for ; Fri, 14 Jan 2011 05:49:54 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 368F120D10; Fri, 14 Jan 2011 08:52:19 -0500 (EST) Message-ID: <4D305512.90104@viagenie.ca> Date: Fri, 14 Jan 2011 08:52:18 -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: Francis Dupont References: <201101132150.p0DLowX9039947@givry.fdupont.fr> In-Reply-To: <201101132150.p0DLowX9039947@givry.fdupont.fr> 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] PCP-base 02: Section 7.7 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, 14 Jan 2011 13:49:55 -0000 On 2011-01-13 16:50, Francis Dupont wrote: > This is the first time I hear this argument. Can you explain why 50% of > existing NATs would not support connect-then-keepalive? > > => on a Linux: man iptables Please. I think I know iptables well enough... > To summary connect-then-keepalive assumes dynamic and PCP mappings are the same > and it is at least fully false on the most common NAT code, in particular > on small boxes. Why wouldn't dynamic and PCP mappings be the same? Why couldn't a Linux PCP server just edit Netfilter's conntrack table directly? Why would it need to go through iptables? 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 simon.perreault@viagenie.ca Fri Jan 14 05:58: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 534E93A6B7F for ; Fri, 14 Jan 2011 05:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 DR9NKHhxoMhi for ; Fri, 14 Jan 2011 05:58:08 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 13D443A6B26 for ; Fri, 14 Jan 2011 05:58:08 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0C0D920D10; Fri, 14 Jan 2011 09:00:33 -0500 (EST) Message-ID: <4D305700.4030809@viagenie.ca> Date: Fri, 14 Jan 2011 09:00: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: Dan Wing References: Your message of Mon, 10 Jan 2011 18:37:48 EST. <4D2B984C.5020407@viagenie.ca> <201101132150.p0DLowX9039947@givry.fdupont.fr> <07d101cbb38e$ca9ac660$5fd05320$@com> In-Reply-To: <07d101cbb38e$ca9ac660$5fd05320$@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] PCP-base 02: Section 7.7 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, 14 Jan 2011 13:58:09 -0000 On 2011-01-13 21:00, Dan Wing wrote: > You're saying PCP cannot dip into the NAT state table for an > existing connection, examine (or increase) the lifetime of the mapping, > and return that value? As least on Linux it is possible using e.g. libnetfilter_conntrack. 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 Francis.Dupont@fdupont.fr Fri Jan 14 08:31: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 6367D28C0F8 for ; Fri, 14 Jan 2011 08:31:35 -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 uNVJnwO6Ucok for ; Fri, 14 Jan 2011 08:31:34 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 3E2B828C0F6 for ; Fri, 14 Jan 2011 08:31:34 -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 p0EGXxfl010425; Fri, 14 Jan 2011 17:33:59 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101141633.p0EGXxfl010425@givry.fdupont.fr> From: Francis Dupont To: Simon Perreault In-reply-to: Your message of Fri, 14 Jan 2011 08:52:18 EST. <4D305512.90104@viagenie.ca> Date: Fri, 14 Jan 2011 17:33:59 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] PCP-base 02: Section 7.7 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, 14 Jan 2011 16:31:35 -0000 In your previous mail you wrote: On 2011-01-13 16:50, Francis Dupont wrote: > This is the first time I hear this argument. Can you explain why 50% of > existing NATs would not support connect-then-keepalive? > > => on a Linux: man iptables Please. I think I know iptables well enough... => so you know iptables don't provide a way to patch dynamic mappings. > To summary connect-then-keepalive assumes dynamic and PCP mappings are the same > and it is at least fully false on the most common NAT code, in particular > on small boxes. Why wouldn't dynamic and PCP mappings be the same? => they can (!= 'they must' and != 'they must not'). Why couldn't a Linux PCP server just edit Netfilter's conntrack table directly? Why would it need to go through iptables? => because conntrack is at least one order bigger to manage than iptables, and we are taking about small boxes (big boxes don't run Linux, BTW this doesn't mean they don't share the issue). And again this is not in the charter so if the NAT supports this why not, and no more. Regards Francis.Dupont@fdupont.fr From simon.perreault@viagenie.ca Fri Jan 14 08:36: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 CAF993A6B9A for ; Fri, 14 Jan 2011 08:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 JDW906qACUaO for ; Fri, 14 Jan 2011 08:36:53 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id B04103A6BAB for ; Fri, 14 Jan 2011 08:36:53 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D6B5620D24; Fri, 14 Jan 2011 11:39:18 -0500 (EST) Message-ID: <4D307C36.8060004@viagenie.ca> Date: Fri, 14 Jan 2011 11:39:18 -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: Francis Dupont References: <201101141633.p0EGXxfl010425@givry.fdupont.fr> In-Reply-To: <201101141633.p0EGXxfl010425@givry.fdupont.fr> 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] PCP-base 02: Section 7.7 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, 14 Jan 2011 16:36:54 -0000 On 2011-01-14 11:33, Francis Dupont wrote: > => so you know iptables don't provide a way to patch dynamic mappings. Of course. > => because conntrack is at least one order bigger to manage than > iptables, and we are taking about small boxes (big boxes don't run Linux, > BTW this doesn't mean they don't share the issue). iptables uses conntrack in the kernel to implement its NAT. You cannot run a NAT on Linux with iptables without using conntrack implicitly. Big or small, every Linux NAT runs conntrack. Using libnetfilter_conntrack to inspect and modify the NAT state table from user-space is very simple. One might even argue that it is simpler than iptables because it provides a real API. 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 Francis.Dupont@fdupont.fr Fri Jan 14 08:41: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 6FE5F3A6C64 for ; Fri, 14 Jan 2011 08:41:48 -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 4uG2C994zPaV for ; Fri, 14 Jan 2011 08:41:47 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 67B813A6C63 for ; Fri, 14 Jan 2011 08:41:47 -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 p0EGiCmT011148; Fri, 14 Jan 2011 17:44:12 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101141644.p0EGiCmT011148@givry.fdupont.fr> From: Francis Dupont To: xiaohong.deng@orange-ftgroup.com In-reply-to: Your message of Tue, 11 Jan 2011 18:16:29 +0800. <0962B0BEF842A24191AD9BE41A8DD2FC0148085A@ch-mailsrv.rd.francetelecom.fr> Date: Fri, 14 Jan 2011 17:44:12 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org, lan.wang@orange-ftgroup.com Subject: Re: [pcp] Does nested NAT apply NAT/ALG on PCP packet? 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, 14 Jan 2011 16:41:48 -0000 In your previous mail you wrote: Sorry I was talking about an interim NAT which does not support PCP. => note if it doesn't support a pcp (lower case, i.e., no NAT-PMP, UPnP IGD, PCP, Web interface, etc) then it is not possible to create any port forwarding through it. You're referring to the nested NAT case, where the intermediate NAT acts like both PCP Client and PCP server. => this is not so clear: even it is technically possible IMHO one should not send a request to the first NAT believing this NAT will handle the whole chain. At the opposite the NAT chain should be handled by the host, i.e., the host creates a port forwarding by sending requests to each NAT. To make things more complex an intermediate NAT can run a proxy in order to enforce security, change transport (cf. DS-Lite), etc. But IMHO in this case it should not change the content of requests. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Fri Jan 14 08:48: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 597EB28C0E8 for ; Fri, 14 Jan 2011 08:48:16 -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 F7YY9SS5riVJ for ; Fri, 14 Jan 2011 08:48:15 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 59ACE3A6BA4 for ; Fri, 14 Jan 2011 08:48: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 p0EGoeI9011522; Fri, 14 Jan 2011 17:50:40 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101141650.p0EGoeI9011522@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Thu, 13 Jan 2011 17:41:38 PST. <07cd01cbb38c$2f87e6a0$8e97b3e0$@com> Date: Fri, 14 Jan 2011 17:50:40 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] PCP-base 02: Section 7.7 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, 14 Jan 2011 16:48:16 -0000 In your previous mail you wrote: I have an idea, which I am writing into -03, which takes a different approach to solve the problem. I believe it works. However, I do not understand the purpose of the PCP server using different pools for PCP-controlled mappings and for dynamic mappings. => first it is a fact so to discuss about advantages is useless, second it is just an example of a classical way to manage share resources: as dynamic and PCP mappings are at least different for lifetime it can be simpler to use different pools. And don't forget the pretty different security constraints can become a strong argument too. That is, I do not see the advantage to to _preventing_ an application from learning the lifetime of its dynamic mapping. You and Med have said there is some advantage to forcing the application to first send a PCP message. I have not understood what advantage that brings to the NAT's implementation or to the NAT's operation. Can you please elaborate the advantage. => I shan't because it is about NAT behavior and it is not the right mailing-list. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Fri Jan 14 10:11: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 35E173A6C76 for ; Fri, 14 Jan 2011 10:11:24 -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 m6rosZBHxCrQ for ; Fri, 14 Jan 2011 10:11:23 -0800 (PST) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id DAD0B3A6C1D for ; Fri, 14 Jan 2011 10:11:22 -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 p0EIDm8O016656; Fri, 14 Jan 2011 19:13:48 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201101141813.p0EIDm8O016656@givry.fdupont.fr> From: Francis Dupont To: Simon Perreault In-reply-to: Your message of Fri, 14 Jan 2011 11:39:18 EST. <4D307C36.8060004@viagenie.ca> Date: Fri, 14 Jan 2011 19:13:48 +0100 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] PCP-base 02: Section 7.7 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, 14 Jan 2011 18:11:24 -0000 In your previous mail you wrote: > => because conntrack is at least one order bigger to manage than > iptables, and we are taking about small boxes (big boxes don't run Linux, > BTW this doesn't mean they don't share the issue). => I believe it was obvious but I refered to the user mode conntrack tools. iptables uses conntrack in the kernel to implement its NAT. You cannot run a NAT on Linux with iptables without using conntrack implicitly. Big or small, every Linux NAT runs conntrack. => I know: it is pretty hard to disable conntrack when you don't need it (of course, to remove all iptables' chains has not this effect :-). Using libnetfilter_conntrack to inspect and modify the NAT state table from user-space is very simple. One might even argue that it is simpler than iptables because it provides a real API. => we can argue about the libipt API but the conntrack table is for some orders larger than an iptables chain. This is why I don't expect to get it on a typical small box. Regards Francis.Dupont@fdupont.fr PS: about other "Unix" NAT implementations (or future Linux): you have the equivalent of conntrack tools as soon as you have NAT state duplication (obviously to duplicate the state you have to read, transfer and re-install it). For instance OpenBSD PF (used on some other BSDs) provides pfsync. BTW it makes clear again the PF state and the PF rulesets (aka dynamic and static mapping tables) pretty different. PPS: when PCP gives access to both dynamic and not dynamic mappings, one can ask for a way to recognize not dynamic mappings. IMHO the lifetime is a good criterion and a not dynamic mapping which will expire soon looks the same than a dynamic mapping with all other properties the same. But this is an operational point of view: for security they could be considered as critically different... From jacniq@gmail.com Sun Jan 16 17:11: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 BC00A28C0DB for ; Sun, 16 Jan 2011 17:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.333, 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 gGDa9DUnGBTX for ; Sun, 16 Jan 2011 17:11:40 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 9481A28C0D0 for ; Sun, 16 Jan 2011 17:11:39 -0800 (PST) Received: by fxm9 with SMTP id 9so5895257fxm.31 for ; Sun, 16 Jan 2011 17:14:11 -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=I0nc0AG5GmkgP7WzjHQIIT8JOjqVwKITTq0Eylm8NxU=; b=HfSeij9awxB4baV3t/z7ic3slDsnhSoUWNSCqooLPFd0ixlaFok7etiUeikt7Z4mWd PKeSejoF5mqHdrnSsgMtFMe78Hv35qpfapHly1n7AFBfitdM3y5FJ6Ix9cdvMFc8r30S 2qv5qmQ7CqPduOsFp5LkmtRS9BGJiPMckrN+8= 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=ktPU67kXcg/kiDMsoBXh6usG5c2fDgxxPstBpnSDP4wqB3PNJKom6bEUphMiMoM/+2 xN6JrctYTOWOIlo7er2gVQQmXTnnbeC+8P0SYTp+bBYeXxRTydT7L2aohT0uhXD9VTz7 tjZunGJjjjjDSOQYJJKPfWlQ7g7zwbUkNmvtU= MIME-Version: 1.0 Received: by 10.204.85.26 with SMTP id m26mr1736204bkl.137.1295226849204; Sun, 16 Jan 2011 17:14:09 -0800 (PST) Received: by 10.204.152.11 with HTTP; Sun, 16 Jan 2011 17:14:09 -0800 (PST) In-Reply-To: <048f01cbb346$1583c170$408b4450$@com> References: <4D2B0D5E.5030302@viagenie.ca> <201101102301.p0AN1rcs084678@givry.fdupont.fr> <19ba01cbb122$f11dfd70$d359f850$@com> <837_1294728928_4D2BFEE0_837_116100_1_94C682931C08B048B7A8645303FDC9F33C3FD7B3C4@PUEXCB1B.nanterre.francetelecom.fr> <1d8901cbb1b5$e093ca50$a1bb5ef0$@com> <22350_1294815325_4D2D505D_22350_100240_1_94C682931C08B048B7A8645303FDC9F33C3FD7B99E@PUEXCB1B.nanterre.francetelecom.fr> <048f01cbb346$1583c170$408b4450$@com> Date: Mon, 17 Jan 2011 09:14:09 +0800 Message-ID: From: Jacni Qin To: Dan Wing Content-Type: multipart/alternative; boundary=0016e6db61a4401bbc049a0080b3 Cc: pcp@ietf.org Subject: Re: [pcp] client/server/symmetric [was RE: PCP-base 02: Section 7.7] 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, 17 Jan 2011 01:11:42 -0000 --0016e6db61a4401bbc049a0080b3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Re-, On Fri, Jan 14, 2011 at 1:19 AM, Dan Wing wrote: > ... > > > Related, I created a new ticket, Issue #35, which is something Simon > and I had discussed offline, but I don't think we achieved clarity on > the problem. I now think the problem is clearer. Included in -03 > will be the following (which is the same as in Issue #35), > > [Ed. Note: A host operating a pure client (2) seldom knows or > cares about the address family of the server; a host > operating a symmetric client/server (3) sometimes also does > not know or care. Thus, the PCP client could mistakenly use > the PIN44 OpCode when it should have used PIN46. This is > unfortunately not fully handled by REMOTE_PEER's inclusion of > address family from the PCP client's perspective. Do we want > to resolve this? If so, how -- perhaps adjust all of the PIN > opcodes to effectively incorporate the REMOTE_PEER semantic? > This is tracked as PCP Issue #35] > > http://trac.tools.ietf.org/wg/pcp/trac/ticket/35 > > Thoughts / comments on Issue #35? > Or simply return an error to identify this status, which then trigger the client to try another server in its list? Cheers, Jacni > > -d > > > -d > > > > > > > Cheers, > > > Med > > > > > > -----Message d'origine----- > > > De : Dan Wing [mailto:dwing@cisco.com] > > > Envoy=E9 : mardi 11 janvier 2011 01:03 > > > =C0 : 'Francis Dupont'; 'Simon Perreault'; BOUCADAIR Mohamed > > OLNC/NAD/TIP > > > Cc : pcp@ietf.org > > > Objet : RE: [pcp] PCP-base 02: Section 7.7 > > > > > > > > > > > > > -----Original Message----- > > > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf > > Of > > > > Francis Dupont > > > > Sent: Monday, January 10, 2011 3:02 PM > > > > To: Simon Perreault > > > > Cc: pcp@ietf.org > > > > Subject: Re: [pcp] PCP-base 02: Section 7.7 > > > > > > > > > > > > In your previous mail you wrote: > > > > > > > > Note that this was discussed in the virtual interim meeting. I > > > seem > > > > to > > > > recall the consensus being that the advantage of easy deployment > > > > outweighed the disadvantages. > > > > > > > > =3D> I am afraid this argument would not close the subject... > > > > and there was no consensus, just a 'go to next point'. > > > > > > > > (Were the minutes of the meeting posted?) > > > > > > > > =3D> +1! > > > > > > > > Francis.Dupont@fdupont.fr > > > > > > > > PS: BTW the 'ease of deployment' is not a good argument as it > > applied > > > > only on hosts, not on NATs, when IMHO at least 50% of the deployed > > > > base won't support it. > > > > > > For reference, this is Issue #17, > > > http://trac.tools.ietf.org/wg/pcp/trac/ticket/17 > > > > > > In the post http://www.ietf.org/mail- > > > archive/web/pcp/current/msg00474.html, > > > Simon described the host implementation difficulty. This got > > agreement > > > from > > > Dave Thaler, http://www.ietf.org/mail- > > > archive/web/pcp/current/msg00475.html > > > and Lars Eggert, > > > http://www.ietf.org/mail-archive/web/pcp/current/msg00480.html. > > > > > > I do not find a post that describes the NAT implementation > > difficulty. > > > > > > I found posts that suggest NATs want to have different port ranges > > for > > > PCP-controlled ports than for dynamically-created connections. > > That's > > > makes > > > some sense when the user is operating a server. But I don't > > understand > > > how > > > separate NAT port ranges are helpful/necessary for the application > > > keepalives case. > > > > > > If this does help the NAT, it seems we will need to force (MUST) the > > > hosts > > > to allocate a source port in the non-ephemeral port range and follow > > > the > > > other steps described in > > > http://www.ietf.org/mail-archive/web/pcp/current/msg00474.html. > > > > > > -d > > > > > > > > > > > > > > > ********************************* > > > This message and any attachments (the "message") are confidential and > > > intended solely for the addressees. > > > Any unauthorised use or dissemination is prohibited. > > > Messages are susceptible to alteration. > > > France Telecom Group shall not be liable for the message if altered, > > > changed or falsified. > > > If you are not the intended addressee of this message, please cancel > > it > > > immediately and inform the sender. > > > ******************************** > > > > > > ********************************* > > This message and any attachments (the "message") are confidential and > > intended solely for the addressees. > > Any unauthorised use or dissemination is prohibited. > > Messages are susceptible to alteration. > > France Telecom Group shall not be liable for the message if altered, > > changed or falsified. > > If you are not the intended addressee of this message, please cancel it > > immediately and inform the sender. > > ******************************** > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > --0016e6db61a4401bbc049a0080b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Re-,

On Fri, Jan 14, 2011 at 1:19 AM, Dan Wing <dwing@cisco.com> wrote:
...


Related, I created a new ticket, Issue #35, which is something Simon
and I had discussed offline, but I don't think we achieved clarity on the problem. =A0I now think the problem is clearer. =A0Included in -03
will be the following (which is the same as in Issue #35),

=A0 =A0 =A0 =A0 =A0[Ed. =A0Note: A host operating a pure client (2) seldom= knows or
=A0 =A0 =A0 =A0 =A0cares about the address family of the server; a host =A0 =A0 =A0 =A0 =A0operating a symmetric client/server (3) sometimes also = does
=A0 =A0 =A0 =A0 =A0not know or care. =A0Thus, the PCP client could mistake= nly use
=A0 =A0 =A0 =A0 =A0the PIN44 OpCode when it should have used PIN46. =A0Thi= s is
=A0 =A0 =A0 =A0 =A0unfortunately not fully handled by REMOTE_PEER's in= clusion of
=A0 =A0 =A0 =A0 =A0address family from the PCP client's perspective. = =A0Do we want
=A0 =A0 =A0 =A0 =A0to resolve this? =A0If so, how -- perhaps adjust all of= the PIN
=A0 =A0 =A0 =A0 =A0opcodes to effectively incorporate the REMOTE_PEER sema= ntic?
=A0 =A0 =A0 =A0 =A0This is tracked as PCP Issue #35]

http://trac.tools.ietf.org/wg/pcp/trac/ticket/35

Thoughts / comments on Issue #35?

Or simply return= an error to identify this status, which then trigger the client to try ano= ther server in its list?

Cheers,
Jacni

=A0

-d

> -d
>
>
> > Cheers,
> > Med
> >
> > -----Message d'origine-----
> > De : Dan Wing [mailto:dwing@ci= sco.com]
> > Envoy=E9 : mardi 11 janvier 2011 01:03
> > =C0 : 'Francis Dupont'; 'Simon Perreault'; BOUCAD= AIR Mohamed
> OLNC/NAD/TIP
> > Cc : pcp@ietf.org
> > Objet : RE: [pcp] PCP-base 02: Section 7.7
> >
> >
> >
> > > -----Original Message-----
> > > From: pcp-bounces@ie= tf.org [mailto:pcp-bounces@ietf= .org] On Behalf
> Of
> > > Francis Dupont
> > > Sent: Monday, January 10, 2011 3:02 PM
> > > To: Simon Perreault
> > > Cc: pcp@ietf.org
> > > Subject: Re: [pcp] PCP-base 02: Section 7.7
> > >
> > >
> > > =A0In your previous mail you wrote:
> > >
> > > =A0 =A0Note that this was discussed in the virtual interim m= eeting. I
> > seem
> > > to
> > > =A0 =A0recall the consensus being that the advantage of easy= deployment
> > > =A0 =A0outweighed the disadvantages.
> > >
> > > =3D> I am afraid this argument would not close the subjec= t...
> > > and there was no consensus, just a 'go to next point'= ;.
> > >
> > > =A0 (Were the minutes of the meeting posted?)
> > >
> > > =3D> +1!
> > >
> > > Francis.Dupont@= fdupont.fr
> > >
> > > PS: BTW the 'ease of deployment' is not a good argum= ent as it
> applied
> > > only on hosts, not on NATs, when IMHO at least 50% of the de= ployed
> > > base won't support it.
> >
> > For reference, this is Issue #17,
> > http://trac.tools.ietf.org/wg/pcp/trac/ticket/17
> >
> > In the post http://www.ietf.org/mail-
> > archive/web/pcp/current/msg00474.html,
> > Simon described the host implementation difficulty. =A0This got > agreement
> > from
> > Dave Thaler, http://www.ietf.org/mail-
> > archive/web/pcp/current/msg00475.html
> > and Lars Eggert,
> > http://www.ietf.org/mail-archive/web/pcp/curren= t/msg00480.html.
> >
> > I do not find a post that describes the NAT implementation
> difficulty.
> >
> > I found posts that suggest NATs want to have different port range= s
> for
> > PCP-controlled ports than for dynamically-created connections. > That's
> > makes
> > some sense when the user is operating a server. =A0But I don'= t
> understand
> > how
> > separate NAT port ranges are helpful/necessary for the applicatio= n
> > keepalives case.
> >
> > If this does help the NAT, it seems we will need to force (MUST) = the
> > hosts
> > to allocate a source port in the non-ephemeral port range and fol= low
> > the
> > other steps described in
> > http://www.ietf.org/mail-archive/web/pcp/curren= t/msg00474.html.
> >
> > -d
> >
> >
> >
> >
> > *********************************
> > This message and any attachments (the "message") are co= nfidential and
> > intended solely for the addressees.
> > Any unauthorised use or dissemination is prohibited.
> > Messages are susceptible to alteration.
> > France Telecom Group shall not be liable for the message if alter= ed,
> > changed or falsified.
> > If you are not the intended addressee of this message, please can= cel
> it
> > immediately and inform the sender.
> > ********************************
>
>
> *********************************
> This message and any attachments (the "message") are confide= ntial and
> intended solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration.
> France Telecom Group shall not be liable for the message if altered, > changed or falsified.
> If you are not the intended addressee of this message, please cancel i= t
> immediately and inform the sender.
> ********************************

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

--0016e6db61a4401bbc049a0080b3-- From phdgang@gmail.com Mon Jan 17 07:10: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 BE7EE28C10A for ; Mon, 17 Jan 2011 07:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 z68PiONk2K39 for ; Mon, 17 Jan 2011 07:10:01 -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 3A4B428C0D7 for ; Mon, 17 Jan 2011 07:10:01 -0800 (PST) Received: by gwj17 with SMTP id 17so2193051gwj.31 for ; Mon, 17 Jan 2011 07:12:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=WunsQ7SQpv9Y2Phg40e5xmMJi9xRVTjgW7IjTVv9DAk=; b=ibVp7Cxs62MGbeM+FMHivzeWuqQpJzzrpzeZbVL81xPKKqLukm+FsBz4fieOjFFGWo 4rI3CAt7JLKL8VVUUj1Lz7n2ixHY1PQ3elYp1iJUZ8gZMblSh0cIdOVo57UwBnVExJgN gc0XQYFhHDiNSoNhunAeppWbFGRSsUrjE6iCM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Ll9mkxGzTvcGveFU0G9RKje9JvTs+2Um2n70QZVXknTVjiP1hdTjqt+QIqT4CbzA3i aQOUaDokEWfsk6lSPCCkNyqAd+G8OKdvwVpOxX0YBuIjol0S7WvoKQyxzqOq6KKwZSpY mFr6oRNABVYhgmC2XD5Kue9pL6i0CC4+9kkJE= MIME-Version: 1.0 Received: by 10.90.89.11 with SMTP id m11mr4314284agb.18.1295277153502; Mon, 17 Jan 2011 07:12:33 -0800 (PST) Received: by 10.90.27.1 with HTTP; Mon, 17 Jan 2011 07:12:33 -0800 (PST) Date: Mon, 17 Jan 2011 23:12:33 +0800 Message-ID: From: GangChen To: dwing@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Cc: pcp@ietf.org Subject: [pcp] [PCP] Using PCP to reduce keepalive traffic of IM application 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, 17 Jan 2011 15:10:03 -0000 Hello Dan, For draft-ietf-pcp-base-02 section 7.7, I find a drawback when PCP is applied to IM applications. The IM original keepalives (sent from IM client to IM server) have two purposes. One is to keep NAT state alive. The other is to make IM server aware of IM client state (alive or dead). When it changes to PCP, PCP messages are sent between PCP client and PCP server. IM server will regard TCP connection interrupted, since it can't receive keepalive message for specific lifetime duration. Should we consider this problem? BRs Gang From dwing@cisco.com Tue Jan 18 13:34: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 1D7A43A6E28 for ; Tue, 18 Jan 2011 13:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.535 X-Spam-Level: X-Spam-Status: No, score=-110.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 YQVD0fNfQ+5S for ; Tue, 18 Jan 2011 13:34:16 -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 444AB3A6DCE for ; Tue, 18 Jan 2011 13:34:16 -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: Av0EAEOXNU2rR7Ht/2dsb2JhbACXaYx0c6gemjSFUASEbw Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 18 Jan 2011 21:36:54 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0ILasjp025659; Tue, 18 Jan 2011 21:36:54 GMT From: "Dan Wing" To: "'GangChen'" References: In-Reply-To: Date: Tue, 18 Jan 2011 13:36:54 -0800 Message-ID: <094b01cbb757$d356a5e0$7a03f1a0$@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: Acu2WRDGK6NVxJoOR4Gnmv0v+HhJSwA/l35Q Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] [PCP] Using PCP to reduce keepalive traffic of IM application 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, 18 Jan 2011 21:34:17 -0000 > For draft-ietf-pcp-base-02 section 7.7, I find a drawback when PCP is > applied to IM applications. The IM original keepalives (sent from IM > client to IM server) have two purposes. One is to keep NAT state > alive. The other is to make IM server aware of IM client state (alive > or dead). When it changes to PCP, PCP messages are sent between PCP > client and PCP server. IM server will regard TCP connection > interrupted, since it can't receive keepalive message for specific > lifetime duration. > > Should we consider this problem? I added the following to my work-in-progress copy of -03, which I believe goes to your question: Note: For reasons beyond NAT, an application may find it useful to perform application-level keepalives, such as to detect a broken path between the client and server, detect a crashed server, or detect a powered-down client. These keepalives are not related to maintaining middlebox state, and PCP cannot do anything useful to reduce those keepalives. -d From dwing@cisco.com Tue Jan 18 14:03: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 7A6F03A6F58 for ; Tue, 18 Jan 2011 14:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.516 X-Spam-Level: X-Spam-Status: No, score=-110.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 wGadhx5TqfjJ for ; Tue, 18 Jan 2011 14:03:36 -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 AC0563A6DCE for ; Tue, 18 Jan 2011 14:03:36 -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: Av0EAB+dNU2rRN+K/2dsb2JhbACXaYx0c6gomjeCeIJYBIRv Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 18 Jan 2011 22:06:14 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p0IM6EwG019490; Tue, 18 Jan 2011 22:06:14 GMT From: "Dan Wing" To: "'Jacni Qin'" References: <4D2B0D5E.5030302@viagenie.ca> <201101102301.p0AN1rcs084678@givry.fdupont.fr> <19ba01cbb122$f11dfd70$d359f850$@com> <837_1294728928_4D2BFEE0_837_116100_1_94C682931C08B048B7A8645303FDC9F33C3FD7B3C4@PUEXCB1B.nanterre.francetelecom.fr> <1d8901cbb1b5$e093ca50$a1bb5ef0$@com> <22350_1294815325_4D2D505D_22350_100240_1_94C682931C08B048B7A8645303FDC9F33C3FD7B99E@PUEXCB1B.nanterre.francetelecom.fr> <048f01cbb346$1583c170$408b4450$@com> In-Reply-To: Date: Tue, 18 Jan 2011 14:06:14 -0800 Message-ID: <097e01cbb75b$ecadef40$c609cdc0$@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: Acu149xkX2H7uuVVQIW5EMNBBU+xIQBdwrhw Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] client/server/symmetric [was RE: PCP-base 02: Section 7.7] 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, 18 Jan 2011 22:03:37 -0000 > On Fri, Jan 14, 2011 at 1:19 AM, Dan Wing wrote: > > > ... > > > Related, I created a new ticket, Issue #35, which is something > Simon > and I had discussed offline, but I don't think we achieved > clarity on > the problem. I now think the problem is clearer. Included in - > 03 > will be the following (which is the same as in Issue #35), > > [Ed. Note: A host operating a pure client (2) seldom > knows or > cares about the address family of the server; a host > operating a symmetric client/server (3) sometimes also > does > not know or care. Thus, the PCP client could mistakenly > use > the PIN44 OpCode when it should have used PIN46. This > is > unfortunately not fully handled by REMOTE_PEER's > inclusion of > address family from the PCP client's perspective. Do we > want > to resolve this? If so, how -- perhaps adjust all of > the PIN > opcodes to effectively incorporate the REMOTE_PEER > semantic? > This is tracked as PCP Issue #35] > > http://trac.tools.ietf.org/wg/pcp/trac/ticket/35 > > Thoughts / comments on Issue #35? > > > > Or simply return an error to identify this status, which then trigger > the client to try another server in its list? But the client doesn't have another server on its list. Looking at an XMPP we all know and love as a concrete example: # host jabber.ietf.org jabber.ietf.org has address 64.170.98.32 jabber.ietf.org has IPv6 address 2001:1890:1112:1::20 jabber.ietf.org mail is handled by 0 mail.ietf.org. -d From jacniq@gmail.com Tue Jan 18 17:16: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 846883A700F for ; Tue, 18 Jan 2011 17:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.200, 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 ds2C0rcNmMmC for ; Tue, 18 Jan 2011 17:16:54 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 19F203A6F76 for ; Tue, 18 Jan 2011 17:16:53 -0800 (PST) Received: by bwz12 with SMTP id 12so328234bwz.31 for ; Tue, 18 Jan 2011 17:19:32 -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=IXV9POHgVPhI/nvy+S9x1cGc4HYcXPVY9mdgYl6pGXA=; b=BQJNoY0Ryv501O9be1AZVLh+q2+NatYFN9b/sFnxPsVpkVTwNmPnw1fYKoZfCI+gqa PQieymG5HgyIPp/amRKoceHjqHHrxMgEYmc46UsAAARw4zNLSmdvdUXMzYdYUCJABXsE 3xpnS27rNmmVuNKjtliSYEKM6BOx27mwgVS/o= 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=YNkBooXp0QhodZgamZuPblaQdEVfhNGbY6UP6wPW88JUuRfLMgIl0qR11B4DySGPeJ DTHi2B8GAHeifBJu84c8LgFfJKiyk0rUy9McST/MIRZ5LWiJSR1j2kgzXM80AjPp4QZu RVPSHBOxSKBWckxX6P7bUWpdU4xNNfzBKNYAY= MIME-Version: 1.0 Received: by 10.204.59.140 with SMTP id l12mr52991bkh.2.1295399970139; Tue, 18 Jan 2011 17:19:30 -0800 (PST) Received: by 10.204.152.11 with HTTP; Tue, 18 Jan 2011 17:19:30 -0800 (PST) In-Reply-To: <097e01cbb75b$ecadef40$c609cdc0$@com> References: <4D2B0D5E.5030302@viagenie.ca> <201101102301.p0AN1rcs084678@givry.fdupont.fr> <19ba01cbb122$f11dfd70$d359f850$@com> <837_1294728928_4D2BFEE0_837_116100_1_94C682931C08B048B7A8645303FDC9F33C3FD7B3C4@PUEXCB1B.nanterre.francetelecom.fr> <1d8901cbb1b5$e093ca50$a1bb5ef0$@com> <22350_1294815325_4D2D505D_22350_100240_1_94C682931C08B048B7A8645303FDC9F33C3FD7B99E@PUEXCB1B.nanterre.francetelecom.fr> <048f01cbb346$1583c170$408b4450$@com> <097e01cbb75b$ecadef40$c609cdc0$@com> Date: Wed, 19 Jan 2011 09:19:30 +0800 Message-ID: From: Jacni Qin To: Dan Wing Content-Type: multipart/alternative; boundary=001636ed6d010ff0d9049a28cf8a Cc: pcp@ietf.org Subject: Re: [pcp] client/server/symmetric [was RE: PCP-base 02: Section 7.7] 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, 19 Jan 2011 01:16:55 -0000 --001636ed6d010ff0d9049a28cf8a Content-Type: text/plain; charset=ISO-8859-1 Re-, On Wed, Jan 19, 2011 at 6:06 AM, Dan Wing wrote: > > On Fri, Jan 14, 2011 at 1:19 AM, Dan Wing wrote: > > > > > > ... > > > > > > Related, I created a new ticket, Issue #35, which is something > > Simon > > and I had discussed offline, but I don't think we achieved > > clarity on > > the problem. I now think the problem is clearer. Included in - > > 03 > > will be the following (which is the same as in Issue #35), > > > > [Ed. Note: A host operating a pure client (2) seldom > > knows or > > cares about the address family of the server; a host > > operating a symmetric client/server (3) sometimes also > > does > > not know or care. Thus, the PCP client could mistakenly > > use > > the PIN44 OpCode when it should have used PIN46. This > > is > > unfortunately not fully handled by REMOTE_PEER's > > inclusion of > > address family from the PCP client's perspective. Do we > > want > > to resolve this? If so, how -- perhaps adjust all of > > the PIN > > opcodes to effectively incorporate the REMOTE_PEER > > semantic? > > This is tracked as PCP Issue #35] > > > > http://trac.tools.ietf.org/wg/pcp/trac/ticket/35 > > > > Thoughts / comments on Issue #35? > > > > > > > > Or simply return an error to identify this status, which then trigger > > the client to try another server in its list? > > But the client doesn't have another server on its list. Jacni>: Sorry, I'm confused. What I mean is to try another PCP Server. The PCP Client, also the client of an application should know the stack of its remote peer of that application. The problem is which PIN opcode it should use. Assume that the Client is of IPvX and its remote peer is of IPvY, then it should use PINXY. If the PCP server is not a right one (e.g., doesn't support Y), maybe try another one. While I got another question, in one of the use case NAT64, if the PCP Client is IPv6-only (i.e., a host with only IPv6 stack), how could it know IPv4 and use PIN64? Maybe the other type of IPv6-only host, with both IPv4 and IPv6 stack but only with IPv6 connectivity is ok. Did I miss something? Cheers, Jacni > Looking at > an XMPP we all know and love as a concrete example: > > # host jabber.ietf.org > jabber.ietf.org has address 64.170.98.32 > jabber.ietf.org has IPv6 address 2001:1890:1112:1::20 > jabber.ietf.org mail is handled by 0 mail.ietf.org. > > -d > > > > --001636ed6d010ff0d9049a28cf8a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Re-,

On Wed, Jan 19, 2011 at 6:06 AM, Dan Wing <dwing@cisco.com> wrote:
> On Fri, Jan 14, 2011 at 1:19 AM, Dan= Wing <dwing@cisco.com> wrote:=
>
>
> =A0 =A0 =A0 ...
>
>
> =A0 =A0 =A0 Related, I created a new ticket, Issue #35, which is somet= hing
> Simon
> =A0 =A0 =A0 and I had discussed offline, but I don't think we achi= eved
> clarity on
> =A0 =A0 =A0 the problem. =A0I now think the problem is clearer. =A0Inc= luded in -
> 03
> =A0 =A0 =A0 will be the following (which is the same as in Issue #35),=
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Ed. =A0Note: A host operating a pure c= lient (2) seldom
> knows or
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cares about the address family of the s= erver; a host
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0operating a symmetric client/server (3)= sometimes also
> does
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0not know or care. =A0Thus, the PCP clie= nt could mistakenly
> use
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the PIN44 OpCode when it should have us= ed PIN46. =A0This
> is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unfortunately not fully handled by REMO= TE_PEER's
> inclusion of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0address family from the PCP client'= s perspective. =A0Do we
> want
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to resolve this? =A0If so, how -- perha= ps adjust all of
> the PIN
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0opcodes to effectively incorporate the = REMOTE_PEER
> semantic?
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This is tracked as PCP Issue #35]
>
> =A0 =A0 =A0 http://trac.tools.ietf.org/wg/pcp/trac/ticket/35 >
> =A0 =A0 =A0 Thoughts / comments on Issue #35?
>
>
>
> Or simply return an error to identify this status, which then trigger<= br> > the client to try another server in its list?

But the client doesn't have another server on its list.

Jacni>: Sorry, I= 9;m confused. What I mean is to try another PCP Server.
The PCP Client, = also the client of an application should know the stack of its remote peer = of that application. The problem is which PIN opcode it should use. Assume = that the Client is of IPvX and its remote peer is of IPvY, then it should u= se PINXY. If the PCP server is not a right one (e.g., doesn't support Y= ), maybe try another one.

While I got another question, in one of the use case NAT64, if the PCP = Client is IPv6-only (i.e., a host with only IPv6 stack), how could it know = IPv4 and use PIN64?
Maybe the other type of IPv6-only host, with both IP= v4 and IPv6 stack but only with IPv6 connectivity is ok. Did I miss somethi= ng?


Cheers,
Jacni
=A0
=A0Looking at
an XMPP we all know and love as a concrete example:

=A0# host jabber.ietf= .org
=A0jabber.ietf.org has address 64.170.98.32
=A0jabber.ietf.org has IPv6 address 2001:1890:1112:1::20
=A0jabber.ietf.org mail is handled by 0 m= ail.ietf.org.

-d




--001636ed6d010ff0d9049a28cf8a-- From dwing@cisco.com Tue Jan 18 17:51: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 D470B3A6F34 for ; Tue, 18 Jan 2011 17:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.518 X-Spam-Level: X-Spam-Status: No, score=-110.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 nFHgYwl3cp04 for ; Tue, 18 Jan 2011 17:51: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 DBC2C3A6FE1 for ; Tue, 18 Jan 2011 17:51:16 -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: Av0EAJvSNU2rRN+J/2dsb2JhbACXTox0c6dfmjOCeIJYBIRvjEs Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 19 Jan 2011 01:53:55 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p0J1rtiL021513; Wed, 19 Jan 2011 01:53:55 GMT From: "Dan Wing" To: "'Jacni Qin'" References: <4D2B0D5E.5030302@viagenie.ca> <201101102301.p0AN1rcs084678@givry.fdupont.fr> <19ba01cbb122$f11dfd70$d359f850$@com> <837_1294728928_4D2BFEE0_837_116100_1_94C682931C08B048B7A8645303FDC9F33C3FD7B3C4@PUEXCB1B.nanterre.francetelecom.fr> <1d8901cbb1b5$e093ca50$a1bb5ef0$@com> <22350_1294815325_4D2D505D_22350_100240_1_94C682931C08B048B7A8645303FDC9F33C3FD7B99E@PUEXCB1B.nanterre.francetelecom.fr> <048f01cbb346$1583c170$408b4450$@com> <097e01cbb75b$ecadef40$c609cdc0$@com> In-Reply-To: Date: Tue, 18 Jan 2011 17:53:55 -0800 Message-ID: <006401cbb77b$baf91ea0$30eb5be0$@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: Acu3du7Dtq0TyK/IS+Ww65OUIiD8pgAA3Vkg Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] client/server/symmetric [was RE: PCP-base 02: Section 7.7] 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, 19 Jan 2011 01:51:17 -0000 > -----Original Message----- > From: Jacni Qin [mailto:jacniq@gmail.com] > Sent: Tuesday, January 18, 2011 5:20 PM > To: Dan Wing > Cc: mohamed.boucadair@orange-ftgroup.com; Francis Dupont; Simon > Perreault; pcp@ietf.org > Subject: Re: [pcp] client/server/symmetric [was RE: PCP-base 02: > Section 7.7] > > Re-, > > > On Wed, Jan 19, 2011 at 6:06 AM, Dan Wing wrote: > > > > On Fri, Jan 14, 2011 at 1:19 AM, Dan Wing > wrote: > > > > > > ... > > > > > > Related, I created a new ticket, Issue #35, which is > something > > Simon > > and I had discussed offline, but I don't think we > achieved > > clarity on > > the problem. I now think the problem is clearer. > Included in - > > 03 > > will be the following (which is the same as in Issue > #35), > > > > [Ed. Note: A host operating a pure client (2) > seldom > > knows or > > cares about the address family of the server; a > host > > operating a symmetric client/server (3) > sometimes also > > does > > not know or care. Thus, the PCP client could > mistakenly > > use > > the PIN44 OpCode when it should have used PIN46. > This > > is > > unfortunately not fully handled by REMOTE_PEER's > > inclusion of > > address family from the PCP client's > perspective. Do we > > want > > to resolve this? If so, how -- perhaps adjust > all of > > the PIN > > opcodes to effectively incorporate the > REMOTE_PEER > > semantic? > > This is tracked as PCP Issue #35] > > > > http://trac.tools.ietf.org/wg/pcp/trac/ticket/35 > > > > Thoughts / comments on Issue #35? > > > > > > > > Or simply return an error to identify this status, which then > trigger > > the client to try another server in its list? > > > But the client doesn't have another server on its list. > > > Jacni>: Sorry, I'm confused. What I mean is to try another PCP Server. > The PCP Client, also the client of an application should know the stack > of its remote peer of that application. The problem is which PIN opcode > it should use. Assume that the Client is of IPvX and its remote peer is > of IPvY, then it should use PINXY. If the PCP server is not a right one > (e.g., doesn't support Y), maybe try another one. The problem isn't what the PCP server supports. I mean, let's assume (for the moment) that the PCP server supports all of the PIN* codes -- in that case, the PCP client doesn't know which PIN* code to send. I have resolved this with a new OpCode in -03. I expect to publish -03 shortly (this evening or tomorrow). > While I got another question, in one of the use case NAT64, if the PCP > Client is IPv6-only (i.e., a host with only IPv6 stack), how could it > know IPv4 and use PIN64? In -03, new text explains there are three cases: 1. operating a server. If a host wants to operate a server, it knows if it wants an IPv6 listener, IPv4 listener, or both -- just like today it knows if it wants to listen on an IPv6 socket or an IPv4 socket or both. 2. client connecting to a server, such as an IMAP server, XMPP server, SIP server, etc. In such a case, it wants to reduce application-level keepalives that it would otherwise send to keep the NAT mapping alive 3. symmetric client and server on the same port, such as done by SIP signaling and by RTP media, where the same port is used to send packets and to receive incoming packets. With this new clarity in -03, you are referring to case (1) and case (3). In those cases, the client knows it wants an IPv4 listener (PINx4), IPv6 listener (PINx6), or both (PINx4 and PINx6). It knows if it has an IPv4 interface on itself (PIN4y) or an IPv6 interface on itself (PIN4y). Taking the union of its own knowledge of what it wants publicly and its own interfaces, it sends a request for PIN44, PIN64, PIN46, or PIN66. > Maybe the other type of IPv6-only host, with both IPv4 and IPv6 stack > but only with IPv6 connectivity is ok. Did I miss something? -d > > Cheers, > Jacni > > > Looking at > an XMPP we all know and love as a concrete example: > > # host jabber.ietf.org > jabber.ietf.org has address 64.170.98.32 > jabber.ietf.org has IPv6 address 2001:1890:1112:1::20 > jabber.ietf.org mail is handled by 0 mail.ietf.org. > > -d > > > > > From mohamed.boucadair@orange-ftgroup.com Wed Jan 19 04:36: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 8E9693A710C for ; Wed, 19 Jan 2011 04:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_FR=0.35, NORMAL_HTTP_TO_IP=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 yk3jto2eETFi for ; Wed, 19 Jan 2011 04:36:15 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id E686F3A7102 for ; Wed, 19 Jan 2011 04:36:14 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id C88E02643A0; Wed, 19 Jan 2011 13:38:53 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id AEB3235C048; Wed, 19 Jan 2011 13:38:53 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 19 Jan 2011 13:38:53 +0100 From: To: 'Dan Wing' , "pcp@ietf.org" Date: Wed, 19 Jan 2011 13:38:52 +0100 Thread-Topic: [pcp] PCP failure scenarios & PCP state synchronization procedure Thread-Index: AcutrLfTEDZS4IWxQE+t0B7oqmebLgEGUuIAABh4RDAAExtaMAAB60Qg Message-ID: <31464_1295440733_4D36DB5D_31464_31408_1_94C682931C08B048B7A8645303FDC9F33C401F04C7@PUEXCB1B.nanterre.francetelecom.fr> References: <14273_1294323565_4D25CF6D_14273_1391_1_94C682931C08B048B7A8645303FDC9F33C3E9FDE6B@PUEXCB1B.nanterre.francetelecom.fr> <1eb201cbb1c8$13810830$3a831890$@com> <10778_1294819591_4D2D6107_10778_54899_1_94C682931C08B048B7A8645303FDC9F33C3FD7B9BA@PUEXCB1B.nanterre.francetelecom.fr> <222c01cbb27a$750a61c0$5f1f2540$@com> In-Reply-To: <222c01cbb27a$750a61c0$5f1f2540$@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.1.19.113614 Subject: Re: [pcp] 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: Wed, 19 Jan 2011 12:36:17 -0000 Hi Dan, Please see inline. Cheers, Med=20 -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : mercredi 12 janvier 2011 18:02 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; pcp@ietf.org Objet : RE: [pcp] PCP failure scenarios & PCP state synchronization procedu= re ... > Section 2.4 also says: >=20 > " [Ed. Note: Do we need to support means to clear stale mappings > first? This may have an impact if the quota is exceed due to the > presence of stale mappings.] >=20 > A PCP Client may be used to manage pinholes on behalf of a third > party (i.e., the PCP Client and the third party are not co-located > on > the same host). If a new internal IP address is assigned to that > third party (e.g., webcam), the PCP Client SHOULD be instructed to > delete the old mapping(s) and create new one(s) using the new > assigned internal IP address." >=20 > (As you know,) PCP currently has a mechanism that supports doing > that - a PCP client can clear mappings for another host within the > subscriber's network. I believe you're asking if we want to > encourage doing that. >=20 > Med: The question is not this one but how to remove the stale mappings > associated with the "old" used internal IP address. You're referring to the problem of detecting that a host's IP address changed? I agree that is hard. I say don't worry about it.=20=20 Med: This is a sensitive point for the CGN: port quota need to be carefully= taken into account; otherwise the service will be impacted because of stal= e mappings.=20 Let's consider the same situation (host's IP address changes=20 arbitrarily) without NAT and without PCP, and where a 3rd party set up some sort of rendezvous for the device -- because the device couldn't do that itself. For example, a simple networked camera or a simple NAS device, where the user edits a web page that says=20 "click here to see my home movies" which points to http://1.2.3.4 (an IP address literal). This works until the NAS's IP address=20 changes. We have no way to solve that without NAT and without=20 PCP. So, I propose we don't try to solve that with PCP. Med: See my comment about the port quota considerations. > I am worried about supporting such deletes > at all. Let's take as an example that my IP address is 192.168.1.1 > while I'm at home and then I visit a friend's house, were I get > a different address. With a na=EFve implementation, I would simply > clear mappings for 192.168.1.1, which is my friend's webcam. > Oops. >=20 > Med: Me too I'm in favour of having means to avoid such behaviour, this > is why I have proposed in the past the PCP Identifier > (http://www.ietf.org/mail-archive/web/pcp/current/msg00055.html) That solves a slew of other problems, though. And creates some new problems. Med: imho, we need to analyse further the options we have on the table incl= uding the ideas you list below. To solve the problem of accidental deletes, here are two other ideas: * a 3rd party mapping could cause an opaque identifier to be=20 included in the PIN response, and require subsequent PIN*=20 requests that reduce the lifetime to include that identifier.=20=20 A problem with that idea might be loss of the first response,=20 though.=20 * Another idea which doesn't change PCP is that the server, on noticing a 3rd party mapping, only allows that same IP address to reduce the lifetime of the mapping. Med: Which information the PCP Server will use assess 3rd party mapping? Co= mpare the internal IP address vs. source IP address?=20 > A smarter implementation would notice that my SSID is > different from my friend's SSID (SSID is something an OS- > embedded PCP client could know) but SSIDs can collide (all > the Starbucks use the same SSID) and Ethernet doesn't have a > handy SSID. >=20 > The second paragraph I quoted above says that a PCP client > that created a pinhole for another device needs to refresh > the pinhole if the other device's IP address changes. In > a PC, I don't see how that could be implemented. It could > be implemented in a CPE, if that CPE is also running DHCP > and interfaces DHCP leases with PCP. >=20 > Med: Yes, and especially for an IWF co-located with the local DHCP > server. Otherwise, we can recommend the use of static internal IP > addresses if PCP is used to configure third-party pinholes. That's the only safe thing to recommend. Med: This can be added to the I-D. Today, changing the IP address on a server is an involved process (reduce DNS TTL, bring it up on the new address and keep the old address active, change DNS, wait until TTL*some_safety_multiplier, decommission old address). None of that is described in an RFC, it's just common practice (documented elsewhere). I don't see a need to get into deep levels of education about changing client IP=20 addresses and making that work nicely with PCP.=20=20 Med: Ok. Besides, client IP addresses don't change that often or, if they are being changed, it's by a malicious ISP that is trying to interfere with their subscribers running a server -- exactly the sort of ISP that won't be much interested in PCP. Med: See your point but this section is more about the change of the intern= al IP address. ... > It should also be noted in Section 2.5 that, on today's Internet > without CGN and without PCP, subscriber WAN addresses change. > And if the subscriber installed their own NAT, the hosts behind > the NAT are likewise completely unaware of the CPE's WAN > address change. NAT-PMP includes a mechanism to alert the > hosts of this change, which uses multicast. We might consider > if PCP could benefit from a mechanism that allows alerting > hosts in some fashion [multicast or unicast]. UPnP IGD does > not include such a mechanism, to my knowledge. >=20 > Med: I suggest you add an issue into the tracker to record it. http://trac.tools.ietf.org/wg/pcp/trac/ticket/34, as an enhancement. Med: Thanks. > 2.6.2. Clear PCP Mappings >=20 > When a command line or a configuration change is enforced to clear > all or a subset of PCP mappings maintained by the PCP Server, the > PCP > Server MUST reset its Epoch to zero value. >=20 > Does the PCP server need to maintain only one Epoch value, or an Epoch > value for each subscriber? If one Epoch value, and only one > subscriber's > mappings are changed, it will cause all PCP clients to refresh their > pinholes -- unnecessarily. So this means the base specification needs > to encouarge per-subscriber Epoch values. >=20 > Med: FWIW, the logic of setting the Epoch value when enforcing CLI is > described in: http://www.ietf.org/mail- > archive/web/pcp/current/msg00091.html > I'm not sure Epoch is the more efficient per-subscriber hint to audit > the mappings; COUNT of the mappings can be considered too. A count of the number of mappings only works if: 1. there is one PCP client per host, which requires the PCP=20 client be part of the OS rather than part of the application. 2. there is some sort of application-id stored on the PCP server, and counts are returned only for matching application-id. Med: I agree. If there is an application-id maintained for every PCP mapping, we might as well have separate Epoch for every subscriber for this case, as separate Epoch is fewer bytes on the server than=20 an application-id for every mapping. > Then, to the main point of the draft: >=20 > The two cases where GET/GETNEXT are useful are when an application > crashes and forgets its mappings (Section 2.2) and when the PCP > client crashes and forgets its mappings (Section 2.3). >=20 > If we require PCP clients (implemented by applications or embedded in > an OS) to store their mappings in permanent storage, do we need > GET/GETNEXT? >=20 > Are there PCP clients which cannot store their mappings in > permanent storage? If so, let's discuss them. >=20 > Med: Yes: some CPEs embedding a PCP Client/IWF. Please say more. Med: See http://www.ietf.org/mail-archive/web/pcp/current/msg00626.html ;-)= =20 ********************************* 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 mohamed.boucadair@orange-ftgroup.com Wed Jan 19 04:52: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 830573A711C for ; Wed, 19 Jan 2011 04:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.192 X-Spam-Level: X-Spam-Status: No, score=-3.192 tagged_above=-999 required=5 tests=[AWL=0.056, 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 3aeHXjKkXB5A for ; Wed, 19 Jan 2011 04:52:33 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id B5FDD3A7102 for ; Wed, 19 Jan 2011 04:52:32 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id ED9803246B9; Wed, 19 Jan 2011 13:55:11 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id CB2AE23806E; Wed, 19 Jan 2011 13:55:11 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Wed, 19 Jan 2011 13:55:11 +0100 From: To: Dan Wing , 'Francis Dupont' , 'Simon Perreault' Date: Wed, 19 Jan 2011 13:55:10 +0100 Thread-Topic: client/server/symmetric [was RE: [pcp] PCP-base 02: Section 7.7] Thread-Index: AcuxGnH/oFEq0BUFQIqUfjE7XufIxwABnQoQAA6BC4AAFMrhsAAdWvDwAERBjVABKGP/kA== Message-ID: <12343_1295441711_4D36DF2F_12343_748393_1_94C682931C08B048B7A8645303FDC9F33C401F04D7@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Mon, 10 Jan 2011 08:45:02 EST. <4D2B0D5E.5030302@viagenie.ca> <201101102301.p0AN1rcs084678@givry.fdupont.fr> <19ba01cbb122$f11dfd70$d359f850$@com> <837_1294728928_4D2BFEE0_837_116100_1_94C682931C08B048B7A8645303FDC9F33C3FD7B3C4@PUEXCB1B.nanterre.francetelecom.fr> <1d8901cbb1b5$e093ca50$a1bb5ef0$@com> <22350_1294815325_4D2D505D_22350_100240_1_94C682931C08B048B7A8645303FDC9F33C3FD7B99E@PUEXCB1B.nanterre.francetelecom.fr> <048f01cbb346$1583c170$408b4450$@com> In-Reply-To: <048f01cbb346$1583c170$408b4450$@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.1.19.113614 Cc: "pcp@ietf.org" Subject: Re: [pcp] client/server/symmetric [was RE: PCP-base 02: Section 7.7] 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, 19 Jan 2011 12:52:34 -0000 Re-, Please see inline. Cheers, Med=20 -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : jeudi 13 janvier 2011 18:20 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; 'Francis Dupont'; 'Simon Perreault' Cc : pcp@ietf.org Objet : client/server/symmetric [was RE: [pcp] PCP-base 02: Section 7.7] ... > SIP UA PCP server SIP proxy > | | | > |--SIP REGISTER, rport------------------------->| > |<-Ok, port=3D12345-------------------------------| > | | | > |-PIN44, REMOTE_PEER=3D->| | > |<--lifetime=3D3600, ext-port=3D12345-| | > | | | >=20 > What is the disadvantage of reducing SIP keepalives that way? >=20 > Med: The use of "rport" allows the SIP Proxy to answer to the source > port number and not to the one indicated in the via header but it does > not help the SIP proxy server to detect the lifetime of the nat binding > in the path; Agreed. But it is not the SIP proxy's job to keep the NAT binding alive. It is the SIP UA's job to do that, and the SIP UA sends those keepalives. Med: In theory yes; but in practice (let's say some of the deployment I kno= w) the binding is updated by re-issuing frequent REGISTER messages. The re-= registration rhythm is forced by the server side and not the SIP UA side. I= 'm sure you know that. > therefore a lower expire timers (e.g., 30 or 60s) will be > returned by the SIP Proxy to the SIP UA to maintain such binding. The > SIP UA has to refresh its registration before the expiry of the > returned expiry timer. The PCP request does not help in such case. In > some deployments "rport" is not used but SBCs "emulate" a similar > functionality but this does not prevent frequent re-registration > messages (not forwarded to the core service elements btw). Keepalive > messages have a SEVERE impact on the performance of the SBC (60% > degradation). In both the cases you describe above, it is the SIP UA that is generating the keepalive messages. It is the SIP UA that can reduce the frequency of those messages when it (a) determines it has only PCP-controlled NATs on the path and (b) knows the lifetime of the mappings in those NATs. Med: Agree if the keepalive message is not the REGISTER message; otherwise = see my answer above. This new knowledge in the SIP UA may require changes to SIP's signaling. > This is why I prefer to present a SIP message to the SIP > proxy without rport but with the external IP/port assigned by the nat > in the path. This would be a hint for the proxy server to return an > expire timer with greater value. "rport" could be removed, but only if we have the SIP UA open its=20 port differently from how it does it today. See below. > For RTP, message flow would be like this, again doing connect-then- > lifetime. > The difference is we don't get anything like an "rport=3DNNN" from the > remote > peer. But, we don't need it anyway except to detect a rogue NAT on the > path > between the PCP-controlled NAT and the RTP peer. If the SIP UA wanted > to > detect such a rogue NAT, it would need to send ICE (STUN) messages to > the > RTP peer. >=20 > Med: Why not doing it simple, use the even_plus_one option to get the > ports; use those ports to build the offer/answer and issue the request. > We don't need ICE/STUN/etc. I did not suggest or propose using ICE/STUN to open pinholes. Rather, I=20 suggested using ICE (STUN) to detect a rogue NAT. By 'rogue', I mean a=20 NAT that is not running PCP but is on the media path. But please see below. > SIP UA PCP server RTP peer > | | | > |--RTP message--------------------------------->| > |--RTP message--------------------------------->| > |--... more RTP messages ...------------------->| > |--RTP message--------------------------------->| > | | | > |-PIN44, REMOTE_PEER=3D=3D->| | > |<--lifetime=3D3600, ext-port=3D12345-| | > | | | >=20 > As with SIP, the SIP UA does not need to be in a hurry to communicate > with > the PCP server. I stepped back from the problem and came to a different way to view this, which I have added to my work-in-progress copy of -03. This new text reads: "7.1. Use Cases for PIN OpCodes There are three uses for these PIN OpCodes: 1. a host operating a server (e.g., a web server). For this, the application needs to (a) create a pinhole from a public IP address and port to itself and (b) publish that public IP address and port to some sort of rendezvous server (e.g., DNS, a SIP message, a proprietary protocol). To accomplish this, the application follows the procedures described in Section 7.1.1. [7.1.1 is a new section titled "Using PCP to Operate a Server", which says you need to bind to an non-ephemeral port for your application's exclusive use.] 2. a host operating a client (e.g., XMPP client, SIP client). For this, the application wants to ensure its connection is not terminated prematurely (due to inactivity) by an on-path NAT or firewall. To accomplish this, the application uses the procedures described in Section 7.1.2. [7.1.2 is -02's Section 7.7 "Using PCP to Eliminate=20 Application Keepalive Messages"] 3. a host operating a client and server on the same port (e.g., Symmetric RTP [RFC4961] or SIP Symmetric Response Routing (rport)=20 [RFC3581]). For this, the application desires properties of=20 both (1) and (2), and uses the procedures described in Section=20 7.1.3. [7.1.3 is a new section titled "Using PCP to Operate a=20 Symmetric Client/Server", which combines aspects of (1) and (2).]" I believe this is much more clear about how the PCP-enabled application=20 should utilize PCP to meet its needs. Med: I need to read the content of Sections 7.1.x ...=20 Related, I created a new ticket, Issue #35, which is something Simon=20 and I had discussed offline, but I don't think we achieved clarity on=20 the problem. I now think the problem is clearer. Included in -03 will be the following (which is the same as in Issue #35), [Ed. Note: A host operating a pure client (2) seldom knows or cares about the address family of the server; a host=20 operating a symmetric client/server (3) sometimes also does not know or care. Thus, the PCP client could mistakenly use the PIN44 OpCode when it should have used PIN46. This is unfortunately not fully handled by REMOTE_PEER's inclusion of address family from the PCP client's perspective. Do we want to resolve this? If so, how -- perhaps adjust all of the PIN opcodes to effectively incorporate the REMOTE_PEER semantic? This is tracked as PCP Issue #35] http://trac.tools.ietf.org/wg/pcp/trac/ticket/35 Thoughts / comments on Issue #35? ********************************* 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 Wed Jan 19 09:29: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 AA6533A7013 for ; Wed, 19 Jan 2011 09:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.536 X-Spam-Level: X-Spam-Status: No, score=-110.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 gFSUclbZfXVc for ; Wed, 19 Jan 2011 09:29:55 -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 4B5343A7040 for ; Wed, 19 Jan 2011 09:29:55 -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: Av0EAJKvNk2rR7Ht/2dsb2JhbACXU4x0c6RymhOCfA+CRQSEbw Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 19 Jan 2011 17:32:28 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0JHWSB7003245; Wed, 19 Jan 2011 17:32:28 GMT From: "Dan Wing" To: , References: <14273_1294323565_4D25CF6D_14273_1391_1_94C682931C08B048B7A8645303FDC9F33C3E9FDE6B@PUEXCB1B.nanterre.francetelecom.fr> <1eb201cbb1c8$13810830$3a831890$@com> <10778_1294819591_4D2D6107_10778_54899_1_94C682931C08B048B7A8645303FDC9F33C3FD7B9BA@PUEXCB1B.nanterre.francetelecom.fr> <222c01cbb27a$750a61c0$5f1f2540$@com> <31464_1295440733_4D36DB5D_31464_31408_1_94C682931C08B048B7A8645303FDC9F33C401F04C7@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <31464_1295440733_4D36DB5D_31464_31408_1_94C682931C08B048B7A8645303FDC9F33C401F04C7@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 19 Jan 2011 09:32:27 -0800 Message-ID: <001b01cbb7fe$d7d72b10$87858130$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcutrLfTEDZS4IWxQE+t0B7oqmebLgEGUuIAABh4RDAAExtaMAAB60QgAWCD7KA= Content-Language: en-us Subject: Re: [pcp] 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: Wed, 19 Jan 2011 17:29:57 -0000 > > " [Ed. Note: Do we need to support means to clear stale = mappings > > first? This may have an impact if the quota is exceed due to > the > > presence of stale mappings.] > > > > A PCP Client may be used to manage pinholes on behalf of a third > > party (i.e., the PCP Client and the third party are not = co-located > > on > > the same host). If a new internal IP address is assigned to that > > third party (e.g., webcam), the PCP Client SHOULD be instructed = to > > delete the old mapping(s) and create new one(s) using the new > > assigned internal IP address." > > > > (As you know,) PCP currently has a mechanism that supports doing > > that - a PCP client can clear mappings for another host within the > > subscriber's network. I believe you're asking if we want to > > encourage doing that. > > > > Med: The question is not this one but how to remove the stale > mappings > > associated with the "old" used internal IP address. >=20 > You're referring to the problem of detecting that a host's IP address > changed? I agree that is hard. I say don't worry about it. >=20 > Med: This is a sensitive point for the CGN: port quota need to be > carefully taken into account; otherwise the service will be impacted > because of stale mappings. Ok, I added the following to -03's security considerations: Because of the state created in a NAPT or firewall, it is anticipated that port forwarding (PIN OpCodes) will have a quota applied to each subscriber. If the quota is small and the maximum lifetime is large, a faulty or disconnected PCP client could cause a denial of service for other PCP clients belonging to that same subscriber. To prevent this problem, if a PCP server is configured for a small = per-subscriber=20 quota (e.g., less than 15 ports) then it is RECOMMENDED it also be be configured for a short maximum lifetime (e.g., 5 minutes). ... > > I am worried about supporting such deletes > > at all. Let's take as an example that my IP address is 192.168.1.1 > > while I'm at home and then I visit a friend's house, were I get > > a different address. With a na=EFve implementation, I would simply > > clear mappings for 192.168.1.1, which is my friend's webcam. > > Oops. > > > > Med: Me too I'm in favour of having means to avoid such behaviour, > this > > is why I have proposed in the past the PCP Identifier > > (http://www.ietf.org/mail-archive/web/pcp/current/msg00055.html) >=20 > That solves a slew of other problems, though. And creates some new > problems. >=20 > Med: imho, we need to analyse further the options we have on the table > including the ideas you list below. >=20 > To solve the problem of accidental deletes, here are two other > ideas: >=20 > * a 3rd party mapping could cause an opaque identifier to be > included in the PIN response, and require subsequent PIN* > requests that reduce the lifetime to include that identifier. > A problem with that idea might be loss of the first response, > though. > * Another idea which doesn't change PCP is that the server, > on noticing a 3rd party mapping, only allows that same IP > address to reduce the lifetime of the mapping. >=20 > Med: Which information the PCP Server will use assess 3rd party > mapping? Compare the internal IP address vs. source IP address? Correct. > > A smarter implementation would notice that my SSID is > > different from my friend's SSID (SSID is something an OS- > > embedded PCP client could know) but SSIDs can collide (all > > the Starbucks use the same SSID) and Ethernet doesn't have a > > handy SSID. > > > > The second paragraph I quoted above says that a PCP client > > that created a pinhole for another device needs to refresh > > the pinhole if the other device's IP address changes. In > > a PC, I don't see how that could be implemented. It could > > be implemented in a CPE, if that CPE is also running DHCP > > and interfaces DHCP leases with PCP. > > > > Med: Yes, and especially for an IWF co-located with the local DHCP > > server. Otherwise, we can recommend the use of static internal IP > > addresses if PCP is used to configure third-party pinholes. >=20 > That's the only safe thing to recommend. >=20 > Med: This can be added to the I-D. >=20 > Today, changing the > IP address on a server is an involved process (reduce DNS TTL, > bring it up on the new address and keep the old address active, > change DNS, wait until TTL*some_safety_multiplier, decommission > old address). None of that is described in an RFC, it's just > common practice (documented elsewhere). I don't see a need to > get into deep levels of education about changing client IP > addresses and making that work nicely with PCP. >=20 > Med: Ok. >=20 > Besides, client > IP addresses don't change that often or, if they are being changed, > it's by a malicious ISP that is trying to interfere with their > subscribers running a server -- exactly the sort of ISP that > won't be much interested in PCP. >=20 > Med: See your point but this section is more about the change of the > internal IP address. >=20 > ... > > It should also be noted in Section 2.5 that, on today's Internet > > without CGN and without PCP, subscriber WAN addresses change. > > And if the subscriber installed their own NAT, the hosts behind > > the NAT are likewise completely unaware of the CPE's WAN > > address change. NAT-PMP includes a mechanism to alert the > > hosts of this change, which uses multicast. We might consider > > if PCP could benefit from a mechanism that allows alerting > > hosts in some fashion [multicast or unicast]. UPnP IGD does > > not include such a mechanism, to my knowledge. > > > > Med: I suggest you add an issue into the tracker to record it. >=20 > http://trac.tools.ietf.org/wg/pcp/trac/ticket/34, as an enhancement. >=20 > Med: Thanks. >=20 > > 2.6.2. Clear PCP Mappings > > > > When a command line or a configuration change is enforced to = clear > > all or a subset of PCP mappings maintained by the PCP Server, the > > PCP > > Server MUST reset its Epoch to zero value. > > > > Does the PCP server need to maintain only one Epoch value, or an > Epoch > > value for each subscriber? If one Epoch value, and only one > > subscriber's > > mappings are changed, it will cause all PCP clients to refresh their > > pinholes -- unnecessarily. So this means the base specification > needs > > to encouarge per-subscriber Epoch values. > > > > Med: FWIW, the logic of setting the Epoch value when enforcing CLI = is > > described in: http://www.ietf.org/mail- > > archive/web/pcp/current/msg00091.html > > I'm not sure Epoch is the more efficient per-subscriber hint to = audit > > the mappings; COUNT of the mappings can be considered too. >=20 > A count of the number of mappings only works if: >=20 > 1. there is one PCP client per host, which requires the PCP > client be part of the OS rather than part of the application. > 2. there is some sort of application-id stored on the PCP server, > and counts are returned only for matching application-id. >=20 > Med: I agree. >=20 > If there is an application-id maintained for every PCP mapping, > we might as well have separate Epoch for every subscriber for > this case, as separate Epoch is fewer bytes on the server than > an application-id for every mapping. >=20 >=20 > > Then, to the main point of the draft: > > > > The two cases where GET/GETNEXT are useful are when an application > > crashes and forgets its mappings (Section 2.2) and when the PCP > > client crashes and forgets its mappings (Section 2.3). > > > > If we require PCP clients (implemented by applications or embedded = in > > an OS) to store their mappings in permanent storage, do we need > > GET/GETNEXT? > > > > Are there PCP clients which cannot store their mappings in > > permanent storage? If so, let's discuss them. > > > > Med: Yes: some CPEs embedding a PCP Client/IWF. >=20 > Please say more. >=20 > Med: See = http://www.ietf.org/mail-archive/web/pcp/current/msg00626.html > ;-)=09 If the interworking function has no stable storage, I don't see how it can function as a UPnP IGD device at all. -d >=20 > ********************************* > This message and any attachments (the "message") are confidential and > intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, > changed or falsified. > If you are not the intended addressee of this message, please cancel = it > immediately and inform the sender. > ******************************** From dwing@cisco.com Wed Jan 19 09:36: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 1428D28C0D9 for ; Wed, 19 Jan 2011 09:36:08 -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.238, BAYES_00=-2.599, J_CHICKENPOX_44=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 jdEWYHIGawAO for ; Wed, 19 Jan 2011 09:36:07 -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 2FA483A7183 for ; Wed, 19 Jan 2011 09:36:07 -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: Av0EAIKwNk2rR7Hu/2dsb2JhbACXU4x0c6RvmhODC4JFBIRv Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 19 Jan 2011 17:38:47 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0JHclmd005101; Wed, 19 Jan 2011 17:38:47 GMT From: "Dan Wing" To: , "'Francis Dupont'" , "'Simon Perreault'" References: Your message of Mon, 10 Jan 2011 08:45:02 EST. <4D2B0D5E.5030302@viagenie.ca> <201101102301.p0AN1rcs084678@givry.fdupont.fr> <19ba01cbb122$f11dfd70$d359f850$@com> <837_1294728928_4D2BFEE0_837_116100_1_94C682931C08B048B7A8645303FDC9F33C3FD7B3C4@PUEXCB1B.nanterre.francetelecom.fr> <1d8901cbb1b5$e093ca50$a1bb5ef0$@com> <22350_1294815325_4D2D505D_22350_100240_1_94C682931C08B048B7A8645303FDC9F33C3FD7B99E@PUEXCB1B.nanterre.francetelecom.fr> <048f01cbb346$1583c170$408b4450$@com> <12343_1295441711_4D36DF2F_12343_748393_1_94C682931C08B048B7A8645303FDC9F33C401F04D7@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <12343_1295441711_4D36DF2F_12343_748393_1_94C682931C08B048B7A8645303FDC9F33C401F04D7@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 19 Jan 2011 09:38:47 -0800 Message-ID: <001c01cbb7ff$ba16a1e0$2e43e5a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuxGnH/oFEq0BUFQIqUfjE7XufIxwABnQoQAA6BC4AAFMrhsAAdWvDwAERBjVABKGP/kAAKMmBQ Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] client/server/symmetric [was RE: PCP-base 02: Section 7.7] 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, 19 Jan 2011 17:36:08 -0000 > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Wednesday, January 19, 2011 4:55 AM > To: Dan Wing; 'Francis Dupont'; 'Simon Perreault' > Cc: pcp@ietf.org > Subject: RE: client/server/symmetric [was RE: [pcp] PCP-base 02: > Section 7.7] >=20 >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > -----Message d'origine----- > De : Dan Wing [mailto:dwing@cisco.com] > Envoy=E9 : jeudi 13 janvier 2011 18:20 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; 'Francis Dupont'; 'Simon = Perreault' > Cc : pcp@ietf.org > Objet : client/server/symmetric [was RE: [pcp] PCP-base 02: Section > 7.7] >=20 > ... > > SIP UA PCP server SIP proxy > > | | | > > |--SIP REGISTER, rport------------------------->| > > |<-Ok, port=3D12345-------------------------------| > > | | | > > |-PIN44, REMOTE_PEER=3D->| | > > |<--lifetime=3D3600, ext-port=3D12345-| | > > | | | > > > > What is the disadvantage of reducing SIP keepalives that way? > > > > Med: The use of "rport" allows the SIP Proxy to answer to the source > > port number and not to the one indicated in the via header but it > does > > not help the SIP proxy server to detect the lifetime of the nat > binding > > in the path; >=20 > Agreed. But it is not the SIP proxy's job to keep the NAT > binding alive. It is the SIP UA's job to do that, and the SIP UA > sends those keepalives. >=20 > Med: In theory yes; but in practice (let's say some of the deployment = I > know) the binding is updated by re-issuing frequent REGISTER messages. > The re-registration rhythm is forced by the server side and not the = SIP > UA side. I'm sure you know that. What happened to the SIP ideas of sending CRLF.CRLF, or to sending a STUN message? Those are both lighter weight than REGISTER. In any event, the SIP specification needs a small change to add a phrase = something like: =20 "Unless the SIP UA has reason to believe a less frequent=20 keepalive frequency is necessary to keep its NAT mapping alive=20 (e.g., [I-D.ietf-pcp-base])," immediately prior to its text that says the SIP proxy decides the frequency of the NAT keepalive messages. I see absolutely nothing PCP (the protocol itself) can here; this is a problem entirely with one application (SIP) which will need to take into account that PCP exists. -d From dwing@cisco.com Wed Jan 19 09:55: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 10B6F28C0E2 for ; Wed, 19 Jan 2011 09:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.234 X-Spam-Level: X-Spam-Status: No, score=-110.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_66=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 Zdnk5jU3fIuV for ; Wed, 19 Jan 2011 09:55:54 -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 0B46B3A7182 for ; Wed, 19 Jan 2011 09:55:54 -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: Ap0GAPu0Nk2rR7Ht/2dsb2JhbACWLYEmjHRzpGmaFoJ5glcEhG8 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 19 Jan 2011 17:58:34 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0JHwYjk025693 for ; Wed, 19 Jan 2011 17:58:34 GMT From: "Dan Wing" To: Date: Wed, 19 Jan 2011 09:58:34 -0800 Message-ID: <004501cbb802$7da371e0$78ea55a0$@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: Acu4An1hFeuJHYdPTf6gZ5XLc43PIQ== Content-Language: en-us Subject: [pcp] submitted draft-ietf-pcp-base-03 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, 19 Jan 2011 17:55:55 -0000 I just submitted draft-ietf-pcp-base-03.txt, available now at: http://tools.ietf.org/html/draft-ietf-pcp-base-03 Diffs are available by clicking "Diff1" or "Diff2" at the top of that page. The interesting change to this version is two new OpCodes, PEER4 and PEER6. These are used to query and control the lifetime of a dynamic connection. When operating a server (e.g., webcam) or a symmetric client/server (e.g., SIP user agent, RTP endpoint), the existing PIN OpCodes are used (PIN44, PIN64, etc.). This is discussed more clearly in Section 7, http://tools.ietf.org/html/draft-ietf-pcp-base-03#section-7 Changes from draft-ietf-pcp-base-02 to -03, http://tools.ietf.org/html/draft-ietf-pcp-base-03#appendix-A.1, o Adjusted abstract and introduction to make it clear PCP is intended to forward ports and intended to reduce application keepalives. o First bit in PCP common header is set. This allows DTLS and non- DTLS to be multiplexed on same port, should we want to add DTLS support. o Moved subscriber identity from common PCP section to PIN* section. o made clearer that PCP client can reduce mapping lifetime if it wishes. o Added discussion of host running a server, client, or symmetric client+server. o Introduced PEER4 and PEER6 OpCodes. o Removed REMOTE_PEER Option, as its function has been replaced by the new PEER OpCodes. o IANA assigned port 44323 to PCP. o Removed AMBIGUOUS error code, which is no longer needed. -d From Internet-Drafts@ietf.org Wed Jan 19 10:00: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 EC26728C116; Wed, 19 Jan 2011 10:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Som5fd+AsxCX; Wed, 19 Jan 2011 10:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B9C3A6FCF; Wed, 19 Jan 2011 10:00: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.10 Message-ID: <20110119180001.20059.6668.idtracker@localhost> Date: Wed, 19 Jan 2011 10:00:01 -0800 Cc: pcp@ietf.org Subject: [pcp] I-D Action:draft-ietf-pcp-base-03.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: Wed, 19 Jan 2011 18:00:03 -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 Filename : draft-ietf-pcp-base-03.txt Pages : 49 Date : 2011-01-19 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-03.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-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-19094543.I-D@ietf.org> --NextPart-- From mohamed.boucadair@orange-ftgroup.com Wed Jan 19 22:59: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 74AD43A71ED for ; Wed, 19 Jan 2011 22:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[AWL=0.054, 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 kAcD6c47-oPA for ; Wed, 19 Jan 2011 22:59:06 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id F0E623A7035 for ; Wed, 19 Jan 2011 22:59:04 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 2DCE23B458B; Thu, 20 Jan 2011 08:01:46 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1283A238061; Thu, 20 Jan 2011 08:01:46 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 20 Jan 2011 08:01:45 +0100 From: To: Dan Wing , "pcp@ietf.org" Date: Thu, 20 Jan 2011 08:01:44 +0100 Thread-Topic: [pcp] PCP failure scenarios & PCP state synchronization procedure Thread-Index: AcutrLfTEDZS4IWxQE+t0B7oqmebLgEGUuIAABh4RDAAExtaMAAB60QgAWCD7KAAG+gOoA== Message-ID: <12343_1295506906_4D37DDDA_12343_790116_1_94C682931C08B048B7A8645303FDC9F33C413CDB0E@PUEXCB1B.nanterre.francetelecom.fr> References: <14273_1294323565_4D25CF6D_14273_1391_1_94C682931C08B048B7A8645303FDC9F33C3E9FDE6B@PUEXCB1B.nanterre.francetelecom.fr> <1eb201cbb1c8$13810830$3a831890$@com> <10778_1294819591_4D2D6107_10778_54899_1_94C682931C08B048B7A8645303FDC9F33C3FD7B9BA@PUEXCB1B.nanterre.francetelecom.fr> <222c01cbb27a$750a61c0$5f1f2540$@com> <31464_1295440733_4D36DB5D_31464_31408_1_94C682931C08B048B7A8645303FDC9F33C401F04C7@PUEXCB1B.nanterre.francetelecom.fr> <001b01cbb7fe$d7d72b10$87858130$@com> In-Reply-To: <001b01cbb7fe$d7d72b10$87858130$@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.1.20.40316 Subject: Re: [pcp] 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: Thu, 20 Jan 2011 06:59:08 -0000 Re-, Please see inline. Cheers, Med=20 -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : mercredi 19 janvier 2011 18:32 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; pcp@ietf.org Objet : RE: [pcp] PCP failure scenarios & PCP state synchronization procedu= re > > " [Ed. Note: Do we need to support means to clear stale mappings > > first? This may have an impact if the quota is exceed due to > the > > presence of stale mappings.] > > > > A PCP Client may be used to manage pinholes on behalf of a third > > party (i.e., the PCP Client and the third party are not co-located > > on > > the same host). If a new internal IP address is assigned to that > > third party (e.g., webcam), the PCP Client SHOULD be instructed to > > delete the old mapping(s) and create new one(s) using the new > > assigned internal IP address." > > > > (As you know,) PCP currently has a mechanism that supports doing > > that - a PCP client can clear mappings for another host within the > > subscriber's network. I believe you're asking if we want to > > encourage doing that. > > > > Med: The question is not this one but how to remove the stale > mappings > > associated with the "old" used internal IP address. >=20 > You're referring to the problem of detecting that a host's IP address > changed? I agree that is hard. I say don't worry about it. >=20 > Med: This is a sensitive point for the CGN: port quota need to be > carefully taken into account; otherwise the service will be impacted > because of stale mappings. Ok, I added the following to -03's security considerations: Because of the state created in a NAPT or firewall, it is anticipated that port forwarding (PIN OpCodes) will have a quota applied to each subscriber. If the quota is small and the maximum lifetime is large, a faulty or disconnected PCP client could cause a denial of service for other PCP clients belonging to that same subscriber. To prevent this problem, if a PCP server is configured for a small per-subscriber= =20 quota (e.g., less than 15 ports) then it is RECOMMENDED it also be be configured for a short maximum lifetime (e.g., 5 minutes). Med: This is one of the mitigation actions we can recommend; a more concret= e one is to allow the PCP Client to audit the mappings it instantiated in t= he PCP Server. ... > > I am worried about supporting such deletes > > at all. Let's take as an example that my IP address is 192.168.1.1 > > while I'm at home and then I visit a friend's house, were I get > > a different address. With a na=EFve implementation, I would simply > > clear mappings for 192.168.1.1, which is my friend's webcam. > > Oops. > > > > Med: Me too I'm in favour of having means to avoid such behaviour, > this > > is why I have proposed in the past the PCP Identifier > > (http://www.ietf.org/mail-archive/web/pcp/current/msg00055.html) >=20 > That solves a slew of other problems, though. And creates some new > problems. >=20 > Med: imho, we need to analyse further the options we have on the table > including the ideas you list below. >=20 > To solve the problem of accidental deletes, here are two other > ideas: >=20 > * a 3rd party mapping could cause an opaque identifier to be > included in the PIN response, and require subsequent PIN* > requests that reduce the lifetime to include that identifier. > A problem with that idea might be loss of the first response, > though. > * Another idea which doesn't change PCP is that the server, > on noticing a 3rd party mapping, only allows that same IP > address to reduce the lifetime of the mapping. >=20 > Med: Which information the PCP Server will use assess 3rd party > mapping? Compare the internal IP address vs. source IP address? Correct. > > A smarter implementation would notice that my SSID is > > different from my friend's SSID (SSID is something an OS- > > embedded PCP client could know) but SSIDs can collide (all > > the Starbucks use the same SSID) and Ethernet doesn't have a > > handy SSID. > > > > The second paragraph I quoted above says that a PCP client > > that created a pinhole for another device needs to refresh > > the pinhole if the other device's IP address changes. In > > a PC, I don't see how that could be implemented. It could > > be implemented in a CPE, if that CPE is also running DHCP > > and interfaces DHCP leases with PCP. > > > > Med: Yes, and especially for an IWF co-located with the local DHCP > > server. Otherwise, we can recommend the use of static internal IP > > addresses if PCP is used to configure third-party pinholes. >=20 > That's the only safe thing to recommend. >=20 > Med: This can be added to the I-D. >=20 > Today, changing the > IP address on a server is an involved process (reduce DNS TTL, > bring it up on the new address and keep the old address active, > change DNS, wait until TTL*some_safety_multiplier, decommission > old address). None of that is described in an RFC, it's just > common practice (documented elsewhere). I don't see a need to > get into deep levels of education about changing client IP > addresses and making that work nicely with PCP. >=20 > Med: Ok. >=20 > Besides, client > IP addresses don't change that often or, if they are being changed, > it's by a malicious ISP that is trying to interfere with their > subscribers running a server -- exactly the sort of ISP that > won't be much interested in PCP. >=20 > Med: See your point but this section is more about the change of the > internal IP address. >=20 > ... > > It should also be noted in Section 2.5 that, on today's Internet > > without CGN and without PCP, subscriber WAN addresses change. > > And if the subscriber installed their own NAT, the hosts behind > > the NAT are likewise completely unaware of the CPE's WAN > > address change. NAT-PMP includes a mechanism to alert the > > hosts of this change, which uses multicast. We might consider > > if PCP could benefit from a mechanism that allows alerting > > hosts in some fashion [multicast or unicast]. UPnP IGD does > > not include such a mechanism, to my knowledge. > > > > Med: I suggest you add an issue into the tracker to record it. >=20 > http://trac.tools.ietf.org/wg/pcp/trac/ticket/34, as an enhancement. >=20 > Med: Thanks. >=20 > > 2.6.2. Clear PCP Mappings > > > > When a command line or a configuration change is enforced to clear > > all or a subset of PCP mappings maintained by the PCP Server, the > > PCP > > Server MUST reset its Epoch to zero value. > > > > Does the PCP server need to maintain only one Epoch value, or an > Epoch > > value for each subscriber? If one Epoch value, and only one > > subscriber's > > mappings are changed, it will cause all PCP clients to refresh their > > pinholes -- unnecessarily. So this means the base specification > needs > > to encouarge per-subscriber Epoch values. > > > > Med: FWIW, the logic of setting the Epoch value when enforcing CLI is > > described in: http://www.ietf.org/mail- > > archive/web/pcp/current/msg00091.html > > I'm not sure Epoch is the more efficient per-subscriber hint to audit > > the mappings; COUNT of the mappings can be considered too. >=20 > A count of the number of mappings only works if: >=20 > 1. there is one PCP client per host, which requires the PCP > client be part of the OS rather than part of the application. > 2. there is some sort of application-id stored on the PCP server, > and counts are returned only for matching application-id. >=20 > Med: I agree. >=20 > If there is an application-id maintained for every PCP mapping, > we might as well have separate Epoch for every subscriber for > this case, as separate Epoch is fewer bytes on the server than > an application-id for every mapping. >=20 >=20 > > Then, to the main point of the draft: > > > > The two cases where GET/GETNEXT are useful are when an application > > crashes and forgets its mappings (Section 2.2) and when the PCP > > client crashes and forgets its mappings (Section 2.3). > > > > If we require PCP clients (implemented by applications or embedded in > > an OS) to store their mappings in permanent storage, do we need > > GET/GETNEXT? > > > > Are there PCP clients which cannot store their mappings in > > permanent storage? If so, let's discuss them. > > > > Med: Yes: some CPEs embedding a PCP Client/IWF. >=20 > Please say more. >=20 > Med: See http://www.ietf.org/mail-archive/web/pcp/current/msg00626.html > ;-)=09 If the interworking function has no stable storage, I don't see how it can function as a UPnP IGD device at all. Med: Dan, as a reminder we have wrote this in http://tools.ietf.org/html/dr= aft-bpw-pcp-upnp-igd-interworking-01;=20 "5.4. Port Mapping Tables IGD-PCP Interworking Function MUST store locally all the mappings instantiated by internal UPnP Control Points in the PCP Server. Port Forwarding mappings SHOULD be stored in a permanent storage. If not, upon reset or reboot, the IGD-PCP Interworking Function MUST synchronise its states as specified in Section 5.10." We converged to this text instead of mandating permanent storage which is n= ot met by low-end CPEs. Reinaldo raised at that time "This is an extremely difficult requirement. T= oday most (if not all) CPEs only store in permanent storage manual configur= ed mappings." ********************************* 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 mohamed.boucadair@orange-ftgroup.com Wed Jan 19 23:18: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 F2C633A71B1 for ; Wed, 19 Jan 2011 23:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_44=0.6, 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 uQI4R98+yCyF for ; Wed, 19 Jan 2011 23:18:01 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by core3.amsl.com (Postfix) with ESMTP id B451B3A70BB for ; Wed, 19 Jan 2011 23:18:00 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id DD969C0326; Thu, 20 Jan 2011 08:20:41 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id C43A638407D; Thu, 20 Jan 2011 08:20:41 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 20 Jan 2011 08:20:41 +0100 From: To: Dan Wing , 'Francis Dupont' , 'Simon Perreault' Date: Thu, 20 Jan 2011 08:20:40 +0100 Thread-Topic: client/server/symmetric [was RE: [pcp] PCP-base 02: Section 7.7] Thread-Index: AcuxGnH/oFEq0BUFQIqUfjE7XufIxwABnQoQAA6BC4AAFMrhsAAdWvDwAERBjVABKGP/kAAKMmBQAByAhTA= Message-ID: <7503_1295508041_4D37E249_7503_29597_1_94C682931C08B048B7A8645303FDC9F33C413CDB26@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Mon, 10 Jan 2011 08:45:02 EST. <4D2B0D5E.5030302@viagenie.ca> <201101102301.p0AN1rcs084678@givry.fdupont.fr> <19ba01cbb122$f11dfd70$d359f850$@com> <837_1294728928_4D2BFEE0_837_116100_1_94C682931C08B048B7A8645303FDC9F33C3FD7B3C4@PUEXCB1B.nanterre.francetelecom.fr> <1d8901cbb1b5$e093ca50$a1bb5ef0$@com> <22350_1294815325_4D2D505D_22350_100240_1_94C682931C08B048B7A8645303FDC9F33C3FD7B99E@PUEXCB1B.nanterre.francetelecom.fr> <048f01cbb346$1583c170$408b4450$@com> <12343_1295441711_4D36DF2F_12343_748393_1_94C682931C08B048B7A8645303FDC9F33C401F04D7@PUEXCB1B.nanterre.francetelecom.fr> <001c01cbb7ff$ba16a1e0$2e43e5a0$@com> In-Reply-To: <001c01cbb7ff$ba16a1e0$2e43e5a0$@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.1.20.30615 Cc: "pcp@ietf.org" Subject: Re: [pcp] client/server/symmetric [was RE: PCP-base 02: Section 7.7] 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, 20 Jan 2011 07:18:02 -0000 Re-, -----Message d'origine----- De : Dan Wing [mailto:dwing@cisco.com]=20 Envoy=E9 : mercredi 19 janvier 2011 18:39 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; 'Francis Dupont'; 'Simon Perreault' Cc : pcp@ietf.org Objet : RE: client/server/symmetric [was RE: [pcp] PCP-base 02: Section 7.7] > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Wednesday, January 19, 2011 4:55 AM > To: Dan Wing; 'Francis Dupont'; 'Simon Perreault' > Cc: pcp@ietf.org > Subject: RE: client/server/symmetric [was RE: [pcp] PCP-base 02: > Section 7.7] >=20 >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > -----Message d'origine----- > De : Dan Wing [mailto:dwing@cisco.com] > Envoy=E9 : jeudi 13 janvier 2011 18:20 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; 'Francis Dupont'; 'Simon Perreault' > Cc : pcp@ietf.org > Objet : client/server/symmetric [was RE: [pcp] PCP-base 02: Section > 7.7] >=20 > ... > > SIP UA PCP server SIP proxy > > | | | > > |--SIP REGISTER, rport------------------------->| > > |<-Ok, port=3D12345-------------------------------| > > | | | > > |-PIN44, REMOTE_PEER=3D->| | > > |<--lifetime=3D3600, ext-port=3D12345-| | > > | | | > > > > What is the disadvantage of reducing SIP keepalives that way? > > > > Med: The use of "rport" allows the SIP Proxy to answer to the source > > port number and not to the one indicated in the via header but it > does > > not help the SIP proxy server to detect the lifetime of the nat > binding > > in the path; >=20 > Agreed. But it is not the SIP proxy's job to keep the NAT > binding alive. It is the SIP UA's job to do that, and the SIP UA > sends those keepalives. >=20 > Med: In theory yes; but in practice (let's say some of the deployment I > know) the binding is updated by re-issuing frequent REGISTER messages. > The re-registration rhythm is forced by the server side and not the SIP > UA side. I'm sure you know that. What happened to the SIP ideas of sending CRLF.CRLF, or to sending a STUN message? Those are both lighter weight than REGISTER. Med: I'm aware of non-SIP keepalive mechanisms. My point was when a SIP-bas= ed keepalive mechanism is used as what is described http://tools.ietf.org/h= tml/rfc5853#section-3.4. In any event, the SIP specification needs a small change to add a phrase=20 something like:=20=20 "Unless the SIP UA has reason to believe a less frequent=20 keepalive frequency is necessary to keep its NAT mapping alive=20 (e.g., [I-D.ietf-pcp-base])," immediately prior to its text that says the SIP proxy decides the frequency of the NAT keepalive messages. Med: But how the proxy is aware about this??? I see absolutely nothing PCP (the protocol itself) can here; this is a problem entirely with one application (SIP) which will need to take into account that PCP exists. Med: I summarise again my position because I'm not sure I follow you here: * PCP is another mechanism that can be used to ease the NAT traversal for S= IP-based application, to avoid SIP-ALG or any procedure in the proxy side t= o assist establishing session when there is an NAT in the path, etc. * the proxy server is not aware of the mechanism used to control the bindin= g in the NAT; therefore some keepalive messages are required: these KA can = be SIP-based or non-SIP-based.=20 * if SIP-based KA are used, creating the mapping and then use the external = IP/port in the SIP message is a hint for the proxy server to not force freq= uent registration.=20 ********************************* 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 Jan 20 08:25: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 7AABE3A7125 for ; Thu, 20 Jan 2011 08:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.234 X-Spam-Level: X-Spam-Status: No, score=-110.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_44=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 DBQpm9sEpgiI for ; Thu, 20 Jan 2011 08:25: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 7F6E63A713A for ; Thu, 20 Jan 2011 08:25: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: Av0EAJvxN02rR7Hu/2dsb2JhbACXXIx1c6Mvmx6DC4JFBIRv Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 20 Jan 2011 16:28:13 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0KGSCi5027276; Thu, 20 Jan 2011 16:28:12 GMT From: "Dan Wing" To: , "'Francis Dupont'" , "'Simon Perreault'" References: Your message of Mon, 10 Jan 2011 08:45:02 EST. <4D2B0D5E.5030302@viagenie.ca> <201101102301.p0AN1rcs084678@givry.fdupont.fr> <19ba01cbb122$f11dfd70$d359f850$@com> <837_1294728928_4D2BFEE0_837_116100_1_94C682931C08B048B7A8645303FDC9F33C3FD7B3C4@PUEXCB1B.nanterre.francetelecom.fr> <1d8901cbb1b5$e093ca50$a1bb5ef0$@com> <22350_1294815325_4D2D505D_22350_100240_1_94C682931C08B048B7A8645303FDC9F33C3FD7B99E@PUEXCB1B.nanterre.francetelecom.fr> <048f01cbb346$1583c170$408b4450$@com> <12343_1295441711_4D36DF2F_12343_748393_1_94C682931C08B048B7A8645303FDC9F33C401F04D7@PUEXCB1B.nanterre.francetelecom.fr> <001c01cbb7ff$ba16a1e0$2e43e5a0$@com> <7503_1295508041_4D37E249_7503_29597_1_94C682931C08B048B7A8645303FDC9F33C413CDB26@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <7503_1295508041_4D37E249_7503_29597_1_94C682931C08B048B7A8645303FDC9F33C413CDB26@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 20 Jan 2011 08:28:12 -0800 Message-ID: <09bb01cbb8bf$084e3ac0$18eab040$@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/kAAKMmBQAByAhTAAE22JAA== Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] client/server/symmetric [was RE: PCP-base 02: Section 7.7] 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, 20 Jan 2011 16:25:30 -0000 ... > > Med: In theory yes; but in practice (let's say some of the deployment > I > > know) the binding is updated by re-issuing frequent REGISTER > messages. > > The re-registration rhythm is forced by the server side and not the > SIP > > UA side. I'm sure you know that. > > What happened to the SIP ideas of sending CRLF.CRLF, or to sending a > STUN message? Those are both lighter weight than REGISTER. > > Med: I'm aware of non-SIP keepalive mechanisms. My point was when a > SIP-based keepalive mechanism is used as what is described > http://tools.ietf.org/html/rfc5853#section-3.4. *Shrug*. If there is a desire by the SIP UA and/or the SIP proxy to reduce those keepalives to something that causes less pain (less bandwidth, less processing power, whatever) -- those implementations can do that already. "CRLF.CRLF" is lighter weight, as is sending a STUN message on the same UDP ports. > In any event, the SIP specification needs a small change to add a > phrase > something like: > > "Unless the SIP UA has reason to believe a less frequent > keepalive frequency is necessary to keep its NAT mapping alive > (e.g., [I-D.ietf-pcp-base])," > > immediately prior to its text that says the SIP proxy decides the > frequency of the NAT keepalive messages. > > Med: But how the proxy is aware about this??? I don't know. Ask on a SIP mailing list. > I see absolutely nothing PCP (the protocol itself) can here; this is > a problem entirely with one application (SIP) which will need to > take into account that PCP exists. > > Med: I summarise again my position because I'm not sure I follow you > here: > > * PCP is another mechanism that can be used to ease the NAT traversal > for SIP-based application, to avoid SIP-ALG or any procedure in the > proxy side to assist establishing session when there is an NAT in the > path, etc. > > * the proxy server is not aware of the mechanism used to control the > binding in the NAT; Agreed. > therefore some keepalive messages are required: > these KA can be SIP-based or non-SIP-based. I do not agree with the "therefore some keepalive message are required". That need is of the SIP proxy itself, and is not related WHATSOEVER to PCP. > * if SIP-based KA are used, creating the mapping and then use the > external IP/port in the SIP message is a hint for the proxy server to > not force frequent registration. The SIP folks will have to take that up. -d > > > > > ********************************* > This message and any attachments (the "message") are confidential and > intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, > changed or falsified. > If you are not the intended addressee of this message, please cancel it > immediately and inform the sender. > ******************************** From dwing@cisco.com Thu Jan 20 08:31: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 127F73A7125 for ; Thu, 20 Jan 2011 08:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.124 X-Spam-Level: X-Spam-Status: No, score=-110.124 tagged_above=-999 required=5 tests=[AWL=-0.324, 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 8vCrVIUBrHzw for ; Thu, 20 Jan 2011 08:31:38 -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 8E0FE3A701E for ; Thu, 20 Jan 2011 08:31:35 -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: Av0EAE7yN02rRN+K/2dsb2JhbACXXIx1c6Mvmx6FUASEbw Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 20 Jan 2011 16:34:09 +0000 Received: from dwingWS ([10.32.240.195]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p0KGY8xi004516; Thu, 20 Jan 2011 16:34:08 GMT From: "Dan Wing" To: , References: <14273_1294323565_4D25CF6D_14273_1391_1_94C682931C08B048B7A8645303FDC9F33C3E9FDE6B@PUEXCB1B.nanterre.francetelecom.fr> <1eb201cbb1c8$13810830$3a831890$@com> <10778_1294819591_4D2D6107_10778_54899_1_94C682931C08B048B7A8645303FDC9F33C3FD7B9BA@PUEXCB1B.nanterre.francetelecom.fr> <222c01cbb27a$750a61c0$5f1f2540$@com> <31464_1295440733_4D36DB5D_31464_31408_1_94C682931C08B048B7A8645303FDC9F33C401F04C7@PUEXCB1B.nanterre.francetelecom.fr> <001b01cbb7fe$d7d72b10$87858130$@com> <12343_1295506906_4D37DDDA_12343_790116_1_94C682931C08B048B7A8645303FDC9F33C413CDB0E@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <12343_1295506906_4D37DDDA_12343_790116_1_94C682931C08B048B7A8645303FDC9F33C413CDB0E@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 20 Jan 2011 08:34:08 -0800 Message-ID: <09bc01cbb8bf$dc42f0f0$94c8d2d0$@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: AcutrLfTEDZS4IWxQE+t0B7oqmebLgEGUuIAABh4RDAAExtaMAAB60QgAWCD7KAAG+gOoAAUWmPQ Content-Language: en-us Subject: [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: Thu, 20 Jan 2011 16:31:39 -0000 > -----Original Message----- > From: mohamed.boucadair@orange-ftgroup.com > [mailto:mohamed.boucadair@orange-ftgroup.com] > Sent: Wednesday, January 19, 2011 11:02 PM > To: Dan Wing; pcp@ietf.org > Cc: 'Reinaldo Penno' > Subject: RE: [pcp] PCP failure scenarios & PCP state synchronization > procedure ... > If the interworking function has no stable storage, I don't see how > it can function as a UPnP IGD device at all. > > Med: Dan, as a reminder we have wrote this in > http://tools.ietf.org/html/draft-bpw-pcp-upnp-igd-interworking-01; > > "5.4. Port Mapping Tables > > IGD-PCP Interworking Function MUST store locally all the mappings > instantiated by internal UPnP Control Points in the PCP Server. > Port > Forwarding mappings SHOULD be stored in a permanent storage. If > not, > upon reset or reboot, the IGD-PCP Interworking Function MUST > synchronise its states as specified in Section 5.10." > > We converged to this text instead of mandating permanent storage which > is not met by low-end CPEs. > > Reinaldo raised at that time "This is an extremely difficult > requirement. Today most (if not all) CPEs only store in permanent > storage manual configured mappings." Let's consider today's UPnP IGD devices -- which (of course) do nothing with PCP. Those devices, today, also do not store their UPnP IGD-created mappings in non-volatile RAM. Thus, when they reboot, they forget about their UPnP IGD-created mappings. I don't see that PCP needs to take the burden to improve UPnP IGD. -d From simon.perreault@viagenie.ca Thu Jan 20 09:09: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 820753A7132 for ; Thu, 20 Jan 2011 09:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=-0.350, 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 BkNOT1WVR6Gx for ; Thu, 20 Jan 2011 09:09:52 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 3A0AC3A7037 for ; Thu, 20 Jan 2011 09:09:51 -0800 (PST) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0AE4420D24 for ; Thu, 20 Jan 2011 12:12:34 -0500 (EST) Message-ID: <4D386D01.8060107@viagenie.ca> Date: Thu, 20 Jan 2011 12:12:33 -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: <14273_1294323565_4D25CF6D_14273_1391_1_94C682931C08B048B7A8645303FDC9F33C3E9FDE6B@PUEXCB1B.nanterre.francetelecom.fr> <1eb201cbb1c8$13810830$3a831890$@com> <10778_1294819591_4D2D6107_10778_54899_1_94C682931C08B048B7A8645303FDC9F33C3FD7B9BA@PUEXCB1B.nanterre.francetelecom.fr> <222c01cbb27a$750a61c0$5f1f2540$@com> <31464_1295440733_4D36DB5D_31464_31408_1_94C682931C08B048B7A8645303FDC9F33C401F04C7@PUEXCB1B.nanterre.francetelecom.fr> <001b01cbb7fe$d7d72b10$87858130$@com> <12343_1295506906_4D37DDDA_12343_790116_1_94C682931C08B048B7A8645303FDC9F33C413CDB0E@PUEXCB1B.nanterre.francetelecom.fr> <09bc01cbb8bf$dc42f0f0$94c8d2d0$@com> In-Reply-To: <09bc01cbb8bf$dc42f0f0$94c8d2d0$@com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Thu, 20 Jan 2011 17:09:53 -0000 On 2011-01-20 11:34, Dan Wing wrote: >> IGD-PCP Interworking Function MUST store locally all the mappings >> instantiated by internal UPnP Control Points in the PCP Server. >> Port >> Forwarding mappings SHOULD be stored in a permanent storage. If >> not, >> upon reset or reboot, the IGD-PCP Interworking Function MUST >> synchronise its states as specified in Section 5.10." > > Let's consider today's UPnP IGD devices -- which (of course) do > nothing with PCP. Those devices, today, also do not store their > UPnP IGD-created mappings in non-volatile RAM. Thus, when they > reboot, they forget about their UPnP IGD-created mappings. > > I don't see that PCP needs to take the burden to improve > UPnP IGD. Agreed. I think implementations of PCP should be free to choose whether they want to store mappings in permanent storage or not. 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 Wed Jan 26 13:49: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 9B42F3A69E1 for ; Wed, 26 Jan 2011 13:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, 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 oi8FyILiTEoi for ; Wed, 26 Jan 2011 13:49:51 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CEDC03A6893 for ; Wed, 26 Jan 2011 13:49: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 1PiDIL-0004hU-Hb; Wed, 26 Jan 2011 13:52: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: Wed, 26 Jan 2011 21:52:53 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/35#comment:1 Message-ID: <062.211497f4aeccd3004a73e7b42a89372c@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: Wed, 26 Jan 2011 21:49:52 -0000 #35: clients don't know address family of server Changes (by dwing@…): * status: new => closed * resolution: => fixed Comment: resolved with new PEER4 and PEER6 OpCodes introduced in -03. -- -----------------------------+---------------------------------------------- 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 Wed Jan 26 13:58: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 9ACBF3A68D6 for ; Wed, 26 Jan 2011 13:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, 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 kme5eRr4BtjO for ; Wed, 26 Jan 2011 13:58:54 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E3E863A68B7 for ; Wed, 26 Jan 2011 13:58:54 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PiDR6-0002DS-21; Wed, 26 Jan 2011 14:01:56 -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: Wed, 26 Jan 2011 22:01:55 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/19#comment:3 Message-ID: <062.4522de55c6b6b6615561dd2ffab1b5b9@tools.ietf.org> References: <053.1b0bed3e163012413ba56d4d79b4f928@tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <053.1b0bed3e163012413ba56d4d79b4f928@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] base #19 (reopened): Handling of unrecognized IEs in request 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, 26 Jan 2011 21:58:56 -0000 #19: Handling of unrecognized IEs in request Changes (by dwing@…): * status: closed => reopened * resolution: fixed => Comment: in -04, I plan to add a new Option to appear in responses, containing a list of Options that weren't understood or weren't parsed successfully by the server. -- --------------------------------+------------------------------------------- Reporter: dwing@… | Owner: Type: enhancement | Status: reopened Priority: minor | Milestone: Component: base | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Wed Jan 26 13:59: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 377CB3A6893 for ; Wed, 26 Jan 2011 13:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, 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 AgXiSORz1lmI for ; Wed, 26 Jan 2011 13:59:55 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 918133A68B7 for ; Wed, 26 Jan 2011 13:59:55 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PiDS5-0002IM-E6; Wed, 26 Jan 2011 14:02: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: dwing@cisco.com X-Trac-Project: pcp Date: Wed, 26 Jan 2011 22:02:57 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/21#comment:1 Message-ID: <068.7bf99cc16d2081924cb4a81b5273398b@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 (new): 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: Wed, 26 Jan 2011 21:59:56 -0000 #21: Epoch=0 amplification attack Changes (by dwing@…): * owner: => dwing@… Comment: Need text to: More clearly explain that if PCP server reduces its Epoch value, it will cause PCP clients to send requests to the PCP server, and PCP server needs to be scaled appropriately. -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: dwing@… Type: defect | Status: new Priority: minor | Milestone: Component: base | Version: Severity: Active WG Document | Keywords: -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Thu Jan 27 07:24: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 225163A68C5 for ; Thu, 27 Jan 2011 07:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, 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 vKHWjx7raRjV for ; Thu, 27 Jan 2011 07:24:45 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 73C583A689D for ; Thu, 27 Jan 2011 07:24:45 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PiTl9-0007Q4-PX; Thu, 27 Jan 2011 07:27: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: Thu, 27 Jan 2011 15:27:43 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/1#comment:4 Message-ID: <055.189fca0322a969362b5062d460ebc968@tools.ietf.org> References: <046.890cfb374e7b66e9c67505c56d5ab15c@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <046.890cfb374e7b66e9c67505c56d5ab15c@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 #1 (closed): Epoch 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, 27 Jan 2011 15:24:46 -0000 #1: Epoch Changes (by dwing@…): * status: new => closed * resolution: => fixed Comment: consensus is to keep the Epoch in the general packet section. -- --------------------------------+------------------------------------------- Reporter: multiple | Owner: dwing@… Type: enhancement | Status: closed Priority: critical | Milestone: Component: base | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Thu Jan 27 07:42:10 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 8EA193A67ED for ; Thu, 27 Jan 2011 07:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, 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 GBgRcsSOc7ay for ; Thu, 27 Jan 2011 07:42:09 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E2E733A67E2 for ; Thu, 27 Jan 2011 07:42:09 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PiU25-0004GH-TG; Thu, 27 Jan 2011 07:45:13 -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: Thu, 27 Jan 2011 15:45:13 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/8#comment:2 Message-ID: <062.556230aa17d678e1daec9bc68ae290af@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 (assigned): 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: Thu, 27 Jan 2011 15:42:10 -0000 #8: PCP server discovery methods Comment(by dwing@…): Need to flip 3/4 order, so IANA address is the end. -- --------------------------------+------------------------------------------- Reporter: dwing@… | Owner: dwing@… Type: defect | Status: assigned Priority: critical | Milestone: Component: base | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Thu Jan 27 07:53: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 9742C3A682A for ; Thu, 27 Jan 2011 07:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, 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 IcXKjv8Jq4uz for ; Thu, 27 Jan 2011 07:53:05 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B75E43A67C3 for ; Thu, 27 Jan 2011 07:53: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 1PiUCf-00059f-PE; Thu, 27 Jan 2011 07:56:09 -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: Thu, 27 Jan 2011 15:56:09 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/8#comment:3 Message-ID: <062.a4aea081116870373f3c583f115e8c04@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 (assigned): 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: Thu, 27 Jan 2011 15:53:06 -0000 #8: PCP server discovery methods Comment(by dwing@…): Server has to respond using the same IP address as the request. Client expects server to respond that way, too. Thus, we don't have a need for a separate "server id" -- the server's IP address serves that function. -- --------------------------------+------------------------------------------- Reporter: dwing@… | Owner: dwing@… Type: defect | Status: assigned Priority: critical | Milestone: Component: base | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Thu Jan 27 07:58: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 7C53B3A68FA for ; Thu, 27 Jan 2011 07:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, 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 ir9QF7i8CGrf for ; Thu, 27 Jan 2011 07:58:06 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9566E3A68F9 for ; Thu, 27 Jan 2011 07:58:06 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PiUHV-0002zi-IU; Thu, 27 Jan 2011 08:01:09 -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: Thu, 27 Jan 2011 16:01:09 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/35#comment:2 Message-ID: <062.37c33f8464365026aa78f2f0f91d7665@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 (reopened): 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: Thu, 27 Jan 2011 15:58:07 -0000 #35: clients don't know address family of server Changes (by dwing@…): * status: closed => reopened * resolution: fixed => Comment: Need to enhance section "Introduction to PIN and PEER OpCodes" to more fully discuss that for operating a server operating a symmetric client / server the PCP client needs to be smart: it needs to know how to advertise an IPv6 address or IPv4 address to a rendezvous server. Thus, it needs to know more about NAT64 or NAT46 and how to deal with it. That differs from doing the 'connect to server, then PCP' (item #2?), where it does not need to know how to do IPv6. -- -----------------------------+---------------------------------------------- Reporter: dwing@… | Owner: Type: defect | Status: reopened Priority: major | Milestone: Component: base | Version: Severity: - | Resolution: Keywords: | -----------------------------+---------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Thu Jan 27 08:02: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 878B33A682A for ; Thu, 27 Jan 2011 08:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EW06ETJkkDz for ; Thu, 27 Jan 2011 08:02:39 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DB1A43A67F4 for ; Thu, 27 Jan 2011 08:02:39 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PiULv-00039c-UY; Thu, 27 Jan 2011 08:05: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 X-Trac-Project: pcp Date: Thu, 27 Jan 2011 16:05:43 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/24#comment:2 Message-ID: <062.749165fd7df76c77b3fe5602f5e8b8ac@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 (reopened): 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: Thu, 27 Jan 2011 16:02:40 -0000 #24: PCP mappings same public IP address as dynamic mappings Changes (by dwing@…): * status: closed => reopened * resolution: fixed => Comment: Adjust: Once an internal host has no active mapping in the PCP-controlled device, a subsequent PCP request for that host MAY be assigned to a different external IP address. to include a mention that the client has to no longer have either a *dynamic* or PCP mapping. -- --------------------------------+------------------------------------------- Reporter: dwing@… | Owner: Type: enhancement | Status: reopened Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Thu Jan 27 08:41: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 1E1003A691E for ; Thu, 27 Jan 2011 08:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.189 X-Spam-Level: X-Spam-Status: No, score=-102.189 tagged_above=-999 required=5 tests=[AWL=-0.388, 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 UozlrZhkPu+F for ; Thu, 27 Jan 2011 08:41:10 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 946CE28C136 for ; Thu, 27 Jan 2011 08:41: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 1PiUxA-0005bb-Mo; Thu, 27 Jan 2011 08:44: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: Thu, 27 Jan 2011 16:44:12 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/10#comment:2 Message-ID: <062.9eaeb326a001cd9b1535a8e92735b66c@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 (new): 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: Thu, 27 Jan 2011 16:41:14 -0000 #10: Firewall (address-dependent filter) support Changes (by dwing@…): * component: base => UPnP interop Comment: rename this Option -- REMOTE_PEER_FILTER is a confusing name. Dave Thaler suggests to just do delta-based stuff: so a subsequent request adds on to the existing filter. The PCP server can refuse the filter if it can't handle it (e.g., if it has a limit of 8 filters, it just accepts 8 and refuses the 9th). Simon suggested: allow a prefix (subnet) to be indicated. Consensus: move into a separate specification. -- --------------------------------+------------------------------------------- Reporter: dwing@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: UPnP interop | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Thu Jan 27 08:43: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 A36D728C13F for ; Thu, 27 Jan 2011 08:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, 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 EledR+U7L7gO for ; Thu, 27 Jan 2011 08:43:47 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F28403A68DC for ; Thu, 27 Jan 2011 08:43:46 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PiUzj-0006uD-01; Thu, 27 Jan 2011 08:46:51 -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: Thu, 27 Jan 2011 16:46:50 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/11#comment:2 Message-ID: <068.1f744ac5647faf4b6ff591cb523241ae@tools.ietf.org> References: <059.4c42aa6a93e7e1e6278aa73a0b1aca7e@tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <059.4c42aa6a93e7e1e6278aa73a0b1aca7e@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 #11 (closed): Flow control 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: Thu, 27 Jan 2011 16:43:47 -0000 #11: Flow control mechanism Changes (by dwing@…): * status: new => closed * resolution: => duplicate Comment: duplicate of #21. -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Resolution: duplicate Keywords: | -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Thu Jan 27 08:52: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 545E028C136 for ; Thu, 27 Jan 2011 08:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, 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 smeW-tL2k0b7 for ; Thu, 27 Jan 2011 08:52:38 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 8651C3A659B for ; Thu, 27 Jan 2011 08:52:38 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PiV8I-0001nk-MZ; Thu, 27 Jan 2011 08:55: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: Thu, 27 Jan 2011 16:55:42 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/13#comment:1 Message-ID: <062.706cdd5a6b6d1978a4bf6a487bdcc98f@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: 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 #13 (new): 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: Thu, 27 Jan 2011 16:52:40 -0000 #13: DS-lite interaction Comment(by dwing@…): Consensus: encapsulation mode. -- --------------------------------+------------------------------------------- Reporter: dwing@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Thu Jan 27 08:56: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 206693A680B for ; Thu, 27 Jan 2011 08:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, 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 LrNvSVm5wIuE for ; Thu, 27 Jan 2011 08:56:40 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 807B13A6807 for ; Thu, 27 Jan 2011 08:56: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 1PiVCC-0001py-Ls; Thu, 27 Jan 2011 08:59:44 -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: Thu, 27 Jan 2011 16:59:44 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/13#comment:2 Message-ID: <062.38068890390a98b51ef70ca44c4f8578@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: 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 #13 (new): 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: Thu, 27 Jan 2011 16:56:41 -0000 #13: DS-lite interaction Comment(by dwing@…): Reverse THEN..IF that is currently in http://tools.ietf.org/html/draft-ietf-pcp-base-03#section-10.1.1 1. UPnP IGD and NAT-PMP are used in the LAN: an interworking function is required to be embedded in the B4 element to ensure interworking between the protocol used in the LAN and PCP. UPnP IGD-PCP Interworking Function is described in Section 11. so it says IF..THEN. -- --------------------------------+------------------------------------------- Reporter: dwing@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Ticket URL: pcp From mohamed.boucadair@orange-ftgroup.com Mon Jan 31 23: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 ADB463A6B0E for ; Mon, 31 Jan 2011 23:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799, 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 0dlXTMvP5gZH for ; Mon, 31 Jan 2011 23:31:00 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by core3.amsl.com (Postfix) with ESMTP id 63A453A68F1 for ; Mon, 31 Jan 2011 23:31:00 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id C48D318C1C3; Tue, 1 Feb 2011 08:34:15 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id AC7874C013; Tue, 1 Feb 2011 08:34:15 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Tue, 1 Feb 2011 08:34:15 +0100 From: To: Simon Perreault , "pcp@ietf.org" Date: Tue, 1 Feb 2011 08:34:14 +0100 Thread-Topic: [pcp] UPnP IGD interworking [was RE: PCP failure scenarios & PCP state synchronization procedure] Thread-Index: Acu4xT6EGo6uquWoROyTFd+Yeay2IwJHHvyA Message-ID: <26213_1296545655_4D47B777_26213_6192_1_94C682931C08B048B7A8645303FDC9F33C4376DA52@PUEXCB1B.nanterre.francetelecom.fr> References: <14273_1294323565_4D25CF6D_14273_1391_1_94C682931C08B048B7A8645303FDC9F33C3E9FDE6B@PUEXCB1B.nanterre.francetelecom.fr> <1eb201cbb1c8$13810830$3a831890$@com> <10778_1294819591_4D2D6107_10778_54899_1_94C682931C08B048B7A8645303FDC9F33C3FD7B9BA@PUEXCB1B.nanterre.francetelecom.fr> <222c01cbb27a$750a61c0$5f1f2540$@com> <31464_1295440733_4D36DB5D_31464_31408_1_94C682931C08B048B7A8645303FDC9F33C401F04C7@PUEXCB1B.nanterre.francetelecom.fr> <001b01cbb7fe$d7d72b10$87858130$@com> <12343_1295506906_4D37DDDA_12343_790116_1_94C682931C08B048B7A8645303FDC9F33C413CDB0E@PUEXCB1B.nanterre.francetelecom.fr> <09bc01cbb8bf$dc42f0f0$94c8d2d0$@com> <4D386D01.8060107@viagenie.ca> In-Reply-To: <4D386D01.8060107@viagenie.ca> 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.1.61516 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 07:31:04 -0000 Dear Simon, 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 C= lient and PCP Server because we think not all CPEs will be able to store th= e mappings in a permanent storage. State reliability is important imho to consider. This is not considered as = it should be in the current base pcp spec. Cheers, Med=20 -----Message d'origine----- De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Simon= Perreault Envoy=E9 : jeudi 20 janvier 2011 18:13 =C0 : pcp@ietf.org Objet : Re: [pcp] UPnP IGD interworking [was RE: PCP failure scenarios & PC= P state synchronization procedure] On 2011-01-20 11:34, Dan Wing wrote: >> IGD-PCP Interworking Function MUST store locally all the mappings >> instantiated by internal UPnP Control Points in the PCP Server. >> Port >> Forwarding mappings SHOULD be stored in a permanent storage. If >> not, >> upon reset or reboot, the IGD-PCP Interworking Function MUST >> synchronise its states as specified in Section 5.10." >=20 > Let's consider today's UPnP IGD devices -- which (of course) do > nothing with PCP. Those devices, today, also do not store their > UPnP IGD-created mappings in non-volatile RAM. Thus, when they > reboot, they forget about their UPnP IGD-created mappings. >=20 > I don't see that PCP needs to take the burden to improve=20 > UPnP IGD. Agreed. I think implementations of PCP should be free to choose whether they want to store mappings in permanent storage or not. 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 ********************************* 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. ********************************