From internet-drafts@ietf.org Thu May 3 04:28:45 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949AD21F85D3; Thu, 3 May 2012 04:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YksJnt1W56ep; Thu, 3 May 2012 04:28:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34ACD21F84EC; Thu, 3 May 2012 04:28:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120503112845.2024.96538.idtracker@ietfa.amsl.com> Date: Thu, 03 May 2012 04:28:45 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-dhcp-03.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 11:28:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Port Control Protocol Working Group o= f the IETF. Title : DHCP Options for the Port Control Protocol (PCP) Author(s) : Mohamed Boucadair Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-dhcp-03.txt Pages : 12 Date : 2012-05-03 This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) Server names. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenario. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcp-dhcp-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcp-dhcp-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-dhcp/ From mohamed.boucadair@orange.com Thu May 3 04:51:07 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF2C21F84F0 for ; Thu, 3 May 2012 04:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abBmYe093sUy for ; Thu, 3 May 2012 04:51:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id A1D9021F84EF for ; Thu, 3 May 2012 04:51:05 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id B266018CD36; Thu, 3 May 2012 13:51:04 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 2F1DC238056; Thu, 3 May 2012 13:51:04 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 3 May 2012 13:51:04 +0200 From: To: pcp issue tracker , "draft-ietf-pcp-dhcp@tools.ietf.org" , "mrw@lilacglade.org" Date: Thu, 3 May 2012 13:51:02 +0200 Thread-Topic: [pcp] #58: DHCP option issues from Margaret Wasserman Thread-Index: Ac0RCpIrALkxtaGtQhmt8K9CoMZvagYFsgog Message-ID: <94C682931C08B048B7A8645303FDC9F36E299464A1@PUEXCB1B.nanterre.francetelecom.fr> References: <077.85b119a156bc4cf8903e1fb82de118fa@tools.ietf.org> In-Reply-To: <077.85b119a156bc4cf8903e1fb82de118fa@tools.ietf.org> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.5.3.75415 Cc: "pcp@ietf.org" Subject: Re: [pcp] #58: DHCP option issues from Margaret Wasserman X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 11:51:08 -0000 Dear all, A new version integrating almost all the comments from Margaret is now onli= ne: http://tools.ietf.org/html/draft-ietf-pcp-dhcp-03 A diff can be seen here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pc= p-dhcp-03.txt. Below more detailed answers. Cheers, Med >-----Message d'origine----- >De : pcp issue tracker [mailto:trac@tools.ietf.org]=20 >Envoy=E9 : lundi 2 avril 2012 21:55 >=C0 : draft-ietf-pcp-dhcp@tools.ietf.org; mrw@lilacglade.org >Cc : pcp@ietf.org >Objet : [pcp] #58: DHCP option issues from Margaret Wasserman > >#58: DHCP option issues from Margaret Wasserman > > This document _way_ oversteps what should be defined in a DHCP option, > proscribing quite a bit of operational behaviour of the PCP server > including: how to handle multiple PCP servers, how to handle > retransmissions, etc. More than half of the information in=20 >this document > does not belong here. > > Also, there is a lengthy discussion in this document of=20 >whether to use IP > Addresses or Names, and I don't understand any of that. There are a > number of DHCP options that contain server lists, and those=20 >servers can be > represented by either IP addresses or names. For an example of a good > DHCP option definition along those lines, please see the NTP=20 >DHCP Option > (RFC 5908). IMO, it would be much better to produce a PCP Server DHCP > Option based on the NTP DHCP Option than to do it as described in this > document. > > Margaret > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > Detailed Comments: > > (1) The Abstract: The text in the abstract does not match=20 >the document > (addresses vs. names). > > To resolve this issue I would suggest: > > OLD: > > This document specifies DHCP (IPv4 and IPv6) options to=20 >configure hosts > with Port Control Protocol (PCP) Server addresses. > > NEW: > > This document specifies DHCP (IPv4 and IPv6) options to=20 >configure hosts > with Port Control Protocol (PCP) Server names. Med: Done. > > (2) Introduction: This option does not provide anything about > "reachability information", it provisions a list of PCP=20 >Servers on a host. > The DHCP server won't know anything about whether those Servers are > reachable at any given time, or from any given place on the=20 >network, so it > can't convey that information. > > To resolve this issue I would suggest: > > OLD: > > This document defines DHCPv4 [RFC2131] and DHCPv6 [RFC3315]=20 >options which > can be used to provision PCP Server [I-D.ietf-pcp-base] reachability > information; more precisely it defines DHCP options to convey=20 >a name (as > per Section 3.1 of [RFC1035]) of PCP Server(s). > > NEW: > > This document defines DHCPv4 [RFC2131] and DHCPv6 [RFC3315] options to > provision a list of PCP Server [I-D.ietf-pcp-base] names. > Med: Done. > (3) Section 3: Configuration of a list of servrtd is quite=20 >common, and it > does not require a lengthy rationale, nor is it valuable to=20 >invent a new > way to to do it. This section describes an operational model=20 >that is not > pertinent to many uses of PCP, and I am concerned that by=20 >describing this > model, we could give the impression that the IETF is=20 >condoning, or even > encouraging, the type of "organization" described. I am not=20 >sure why we > would want to do that. Also, since we are moving the DS-Lite=20 >stuff out of > the Base Spec, discussing "the DS-Lite Use Case" for PCP as we do here > would require a reference to the new spec, and I don't think=20 >one should be > needed in a DHCP option that is useful for all use cases. > > To resolve this issue, I would suggest: > > Remove section 3. Rework the option to accept a list of names or IP > Addresses, like the NTP Server option (RFC 5908). Med: see http://trac.tools.ietf.org/wg/pcp/trac/ticket/59. > > (4) Section 4: There are a number of problems with this section. > > (4a) It is possible to return more than one PCP Server name=20 >in the list, > and it is possible that there will be more than one PCP=20 >controlled device > on a hosts outbound path. So, the first statement in this section is > simplistic... Is the applicability of this option=20 >constrained to cases > were there is only one PCP-controlled device serving as a gateway to a > leaf network? If so, you should say that somewhere in here. =20 >If not, I > think you need to say something else. > > (4b) What is "any terminal belonging to the same realm"? =20 >"Terminal" and > "realm" aren't words that apply in a typical IP networking=20 >case, and it is > unclear what is meant here. > > (4c) What is a CP Router? Do you mean a customer-premise=20 >router? If so, > you need to expand the acronym the first time you use it... Also, > Customer Premise Equipment (CPE) is more commonly used in the IETF, I > think. If this option is used to configure a router, is it=20 >assumed that > the router will pass this information on to its internal=20 >hosts? Or that > it will serve as a PCP proxy for them? > > (4d) "Customers" will experience "service troubles" and their=20 >"service(s) > won't be delivered appropriately" is a bit obscure.... > > I also wonder why this section exists in this document at=20 >all, since it > seems more like general advice on how to deal with a=20 >situation where a PCP > Server isn't co-resident with the device it controls than=20 >anything having > to do with the DHCP option... Also, it isn't really necessary to tell > someone that if they misconfigure their hosts, they won't work. > > To address these four problems, I suggest that you remove section 4. Med: The section has been removed. > > (5) Section 5: This section doesn't make sense to me, as=20 >written. You > have described two operational models, but IMO they muddle=20 >together the > notion of receiving a list of PCP Servers (i.e. multiple names), and a > list of IP addresses in a DNS response (i.e. multiple IP Addresses > corresponding to the name). > > IMO, you need to make a decision here... Do you want to=20 >treat each IP > Address returned from name resolution as a separate PCP=20 >Server? Or do you > want to treat each PCP Server name provisioned by DHCP as a separate > server. It appears that you use the latter (one name, on server) in > section 5.1 and the former (one address, one server) in=20 >section 5.2. This > doesn't make any sense to me. > > I *think* what you want to do is to allow multiple DHCP=20 >Server names to > indicate multiple servers that should be used in parallel (to=20 >cover the > case where a site is multi-homed), and that you want clients=20 >to use each > set of IP addresses as alternate ways to reach each of those=20 >servers, but > that is not what this section says. > > Also, why do you describe a PCP retransmission algorithm here=20 >in the DHCP > spec? > > All you want to do in the DHCP spec is describe how a node gets its > configuration information through DHCP. You don't want to=20 >describe how > PCP works. The PCP base spec needs to describe how PCP works included > what its expected configuration looks like, while remaining neutral on > whether that configuration is obtained via manual=20 >configuration, DHC or > other means. > > To address this issue: > > Construct a DHCP Option that can be used to indicate whether the PCP > Servers in the PCP Server list should be tried in sequence if=20 >the prior > servers are unavailable, or whether they should all be used=20 >in parallel. > If a more complicated construct is needed, describe what it=20 >is, and I will > help you understand how to represent that in a DHCP option. > > DO NOT descrive how the PCP Client will work in this option. =20 >How does a > PCP Client use multiple servers if they are configured=20 >statically? Or if > there are multiple default routers in the default router list. All of > this operational mode stuff belongs in the PCP base document,=20 >not in an > DHCP option. Med: The text has been updated to specify an option may include several nam= es; each name is treated as separte PCP Server. Examples are provided to il= lustrate the procedure.=20 > > (6) Section 6: > > (6a) The DS-Lite example isn't helpful here. Med: Removed. > > (6b) Also, this option only allows you to configure one DNS=20 >name, which > doesn't match all of section 5. Med: The text has been updated to indicate several names can be included. > > (6c) This document should not tell you how to configure your=20 >DNS server. Med: Removed. > > (6d) When you want to configure a server list, it is typical=20 >to include > the server list in one option (as in NTP) not to send=20 >multiple options as > seems to be described in this draft. Med: Done. > > (6e) I don't even know what to say about the "local cache"=20 >of resolved > addresses... Include what TTL? What cache? Med: TTL was replaced with "validity lifetime" and cache with "local name r= esolution cache". > > To address this issue I would suggest: > > Remove the DS-Lite example. > > Move to an option like the NTP DHCP Option in RFC 5908, perhaps with a > flag to indicate whether the servers should be used as a=20 >redundancy list, > or as a list of servers to be used in parallel (see my suggestion for > section 5. > > Remove the mention of how to configure a DNS server. > > Substantially rework the client behaviour section. > > (7) Section 7 has many of the same issues described in section 6. Med: Updated to be sync with Section 6. > > (8) There is no link between using DHCPv4 or DHCPv6 and DNS=20 >in terms of > what IP version will be returned in a name lookup, and I=20 >don't see why you > would want to imply that there is. Med: The issue is more about potential conflict when receiving PCP option i= n both DHCPv4 and DHCPv6. This section has been introduced to handle a comm= ent received during early review of the document. I maintained this section= . > >--=20 >----------------------------------------+---------------------- >------------ > Reporter: Margaret Wasserman | Owner: draft-ietf-pcp- > Type: defect | dhcp@. > Priority: major | Status: new >Component: dhcp | Milestone: > Severity: - | Version: > | Keywords: >----------------------------------------+---------------------- >------------ > >Ticket URL: >pcp > >= From dwing@cisco.com Thu May 3 16:37:32 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F66611E807F for ; Thu, 3 May 2012 16:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ah-hI8Io-6d2 for ; Thu, 3 May 2012 16:37:31 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE4211E8073 for ; Thu, 3 May 2012 16:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1850; q=dns/txt; s=iport; t=1336088251; x=1337297851; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=Do7JWT56nMzl9nkc6cB/FqOi+K0VgpfpFefreX7k5lI=; b=Sr6rZHvqT1MQUNkcK0SoH/KK2FwN+CP3DHYLoy/dIYXF6KdmbX4jCz8U FqqN7X4LMYy8UcGDJm3v1hQsgnvS6qks1yOgNZrPhEpFsI/wwn2wWIC9z rGgvjH2q72/ztQ9KRemZV1TGvi6mWqlKa68ANjMFHYTDHT+fIBYaf5N2W o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAD8Wo0+Q/khM/2dsb2JhbABFojqQQoEHghAICgEXED8NBRhQIxwBBB4TBIdrC5pDoBUEjWODJQSIZIUWll2BaYMI X-IronPort-AV: E=Sophos;i="4.75,528,1330905600"; d="scan'208";a="72402861" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 03 May 2012 23:37:29 +0000 Received: from dwingWS ([10.32.240.195]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q43NbRTi013074; Thu, 3 May 2012 23:37:28 GMT From: "Dan Wing" To: Date: Thu, 3 May 2012 16:37:31 -0700 Message-ID: <087501cd2985$b667d660$23378320$@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: Ac0phbVu7EFT0sMXQ0qfmjzLyke80g== Content-Language: en-us Cc: draft-ietf-pcp-base@tools.ietf.org Subject: [pcp] pcp-base: Mapping Nonce X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 23:37:32 -0000 Working group, During IESG evaluation of draft-ietf-pcp-base (*) we received several DISCUSSes that PCP needs a "transaction id" for two reasons: security and to simplify the protocol design. After several face to face meetings at IETF83 in Paris, we believe we resolved most of the concerns around needing transaction-id to ease protocol design and that adding a transaction id would make some aspects of the protocol more difficult. That left us with a "transaction id" for reasons of security. The specific concern is around Mapping Update. Mapping Update is where a PCP server sends updated information to the PCP client about a mapping. For example, if a PCP server is running on a home NAT and the ISP renumbers the subscriber, a Mapping Update can be sent to immediately inform the PCP client that the mapping has changed. An attacker, able to spoof the PCP server's IP address, could cause PCP clients to think a mapping had changed and cause traffic to flow through a host operated by the attacker. To prevent this attack, at the IETF83 PCP meeting, Margaret Wasserman proposed adding a "mapping nonce". The client would chose this value and include it in MAP and PEER requests, and the PCP server would include this same mapping none value in all responses it sends -- both the first response it sends and all Mapping Update responses it sends (if any). A mapping nonce does not appear to complicate PCP as much as a (typical) transaction-id, so this seems a win from both a security perspective and protocol design perspective. If there are questions or concerns about this change, please say so. I hope to finish editing in the next several days to add the Mapping Nonce and resolve some other IESG DISCUSS and COMMENTS. (*) https://datatracker.ietf.org/doc/draft-ietf-pcp-base/ballot/ -d From dwing@cisco.com Thu May 3 18:38:46 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1150E11E8085 for ; Thu, 3 May 2012 18:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdRWj2Pe641x for ; Thu, 3 May 2012 18:38:45 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAE411E8073 for ; Thu, 3 May 2012 18:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=734; q=dns/txt; s=iport; t=1336095525; x=1337305125; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=1H5kNJIipQ26CcffA+q+0xLSlCabC2s2uYrt/cQbNZs=; b=N0HBeCc0Z+we/7WTXhiOgEXCMlv5fk4JqzfjgGByxx95c8JEHWzuPu60 ae1U31uBhpLsKW1hbcu/WnXUcp/QjkE7QB8+Gnpyewd+COhD1pHxusASY QUdsJygM5ilM6eSdbAfwPUJXYrDF4OXUfw7F8itGlbUEiZoql/JmcE4pl c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJUyo0+Q/khL/2dsb2JhbABFojuQQoEHggkBAQEDAQgKARcQSwEDAgkPAgQBASgHGSMKCQgBAQQBEgsXh2YFmkugHZEIBIhkhRaWXYFpgwg X-IronPort-AV: E=Sophos;i="4.75,528,1330905600"; d="scan'208";a="72406312" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 04 May 2012 01:38:44 +0000 Received: from dwingWS ([10.32.240.195]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q441cgdf003001; Fri, 4 May 2012 01:38:43 GMT From: "Dan Wing" To: , References: <0412136DF48FC94A9795E62ECFC0146510545403@008-AM1MPN1-013.mgdnok.nokia.com> In-Reply-To: <0412136DF48FC94A9795E62ECFC0146510545403@008-AM1MPN1-013.mgdnok.nokia.com> Date: Thu, 3 May 2012 18:38:46 -0700 Message-ID: <08ee01cd2996$a6aa8a40$f3ff9ec0$@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: Ac0YJrqwwQAC2nQFQxy+ctb0OeZg9wRasVCw Content-Language: en-us Subject: Re: [pcp] Wrong sentence in I-D v24 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 01:38:46 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > ext-felipe.m.costa@nokia.com > Sent: Wednesday, April 11, 2012 2:11 PM > To: pcp@ietf.org > Subject: [pcp] Wrong sentence in I-D v24 > > Dear editors, > > > > If/when a new version of the PCP I-D is written, please eliminate the > following sentence, present on I-D v24: > > > > Page 51, when explaining the fields present in the PEER Opcode Response > packet (Figure 12): > > > > Assigned External IP Address: (.) IPv4 or IPv6 address is indicated by > the Opcode (.) Thanks for catching that. It will be fixed in -25. -d > > > Regards, > > > > Felipe Miranda Costa > > From mohamed.boucadair@orange.com Fri May 4 06:06:02 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E149121F85A1 for ; Fri, 4 May 2012 06:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ci7cT3WafQzr for ; Fri, 4 May 2012 06:06:01 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3A77821F8599 for ; Fri, 4 May 2012 06:06:01 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 9CC1922C4D8 for ; Fri, 4 May 2012 15:06:00 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 7DF4727C057 for ; Fri, 4 May 2012 15:06:00 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 4 May 2012 15:06:00 +0200 From: To: "pcp@ietf.org" Date: Fri, 4 May 2012 15:05:59 +0200 Thread-Topic: draft-boucadair-pcp-bittorrent Thread-Index: Ac0p7Bj/Hk2fE/iXRzu4A54bkRpt0AACmYPw Message-ID: <94C682931C08B048B7A8645303FDC9F36E299468ED@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.5.4.121515 Subject: [pcp] draft-boucadair-pcp-bittorrent X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 13:06:02 -0000 Dear all, For information and comments. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : vendredi 4 mai 2012 13:50 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-boucadair-pcp-bittorrent-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Behavior of BitTorrent service in PCP-enabled networks w= ith Address Sharing Author(s) : Mohamed Boucadair Tao Zheng Xiaohing Deng Jaqueline Queiroz Filename : draft-boucadair-pcp-bittorrent-00.txt Pages : 22 Date : 2012-05-04 This document describes the behavior of BitTorrent service in the context of PCP-enabled address sharing functions. It provides an overview of the used testbed and main results of the tests that have been conducted in order to assess the limitations of an architecture based on shared IP addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-pcp-bittorrent-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-boucadair-pcp-bittorrent-00.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-boucadair-pcp-bittorrent/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From dthaler@microsoft.com Sat May 5 14:21:18 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E9A21F848E for ; Sat, 5 May 2012 14:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.857 X-Spam-Level: X-Spam-Status: No, score=-103.857 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbGTbn2vkJ5Y for ; Sat, 5 May 2012 14:21:17 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 129DC21F847F for ; Sat, 5 May 2012 14:21:17 -0700 (PDT) Received: from mail49-ch1-R.bigfish.com (10.43.68.243) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.23; Sat, 5 May 2012 21:21:06 +0000 Received: from mail49-ch1 (localhost [127.0.0.1]) by mail49-ch1-R.bigfish.com (Postfix) with ESMTP id 84FB860309; Sat, 5 May 2012 21:21:05 +0000 (UTC) X-SpamScore: -40 X-BigFish: VS-40(zzbb2dI9371I15bfKc85fhc85dh1432N1418I98dKzz1202hzz1033IL8275bh8275dh186Mz2fh2a8h668h839hd25h34h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail49-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail49-ch1 (localhost.localdomain [127.0.0.1]) by mail49-ch1 (MessageSwitch) id 1336252863509670_8220; Sat, 5 May 2012 21:21:03 +0000 (UTC) Received: from CH1EHSMHS021.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail49-ch1.bigfish.com (Postfix) with ESMTP id 7807D40252; Sat, 5 May 2012 21:21:03 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS021.bigfish.com (10.43.70.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 5 May 2012 21:21:03 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.298.5; Sat, 5 May 2012 21:21:13 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.298.5; Sat, 5 May 2012 14:21:12 -0700 Received: from TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com ([169.254.5.160]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0298.005; Sat, 5 May 2012 14:21:12 -0700 From: Dave Thaler To: "pcp@ietf.org" , Stephen Farrell Thread-Topic: Summarizing THIRD_PARTY discussion Thread-Index: Ac0q/uaHPnY86KsDT7Klt/UF2ihqHw== Date: Sat, 5 May 2012 21:21:11 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B5B429F@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.42] Content-Type: multipart/mixed; boundary="_002_9B57C850BB53634CACEC56EF4853FF653B5B429FTK5EX14MBXW605w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [pcp] Summarizing THIRD_PARTY discussion X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 21:21:18 -0000 --_002_9B57C850BB53634CACEC56EF4853FF653B5B429FTK5EX14MBXW605w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There have been a number of proposals made, including: 1) Delay the base spec until some future time when we have finished advance= d security. Although a few were in favor of this, WG consensus was against = this. 2) Margaret's proposal summarized 4/1: http://www.ietf.org/mail-archive/web= /pcp/current/msg02015.html where there's only one THIRD_PARTY option, it's disabled by default, but implementable on all devices. Stephen Farrel was asked if that would pass the IESG and he responded 4/1 saying "'Fraid not." (His email 4/1 is attached. It isn't showing up in the archives, so I'm se= parately trying to track that down and get that fixed, since that seems to be the ca= use of some confusion.) Sam then re-summarized Stephen's position in email 4/3: http://www.ietf.org/mail-archive/web/pcp/current/msg02040.html So even though a bunch of WG people expressed support for this, it turns out to be the same as option 1 (delay the base spec for a long tim= e). Hence this is not an option, since I do not see that people arguing for Margaret's were in support of delaying the base spec. However,=20 this option did influence the updated points of the next approach below. 3) Have an UNSECURE_THIRD_PARTY (or UNSAFE_THIRD_PARTY) option in the base spec, that MUST NOT be implemented in home gateways or enterprise systems, only by web portals in secure networks. This was the compromise proposal I summarized in email 3/30: http://www.ietf.org/mail-archive/web/pcp/current/msg02006.html Stephen further sent points to be made in text in off-list email 4/2 to Margaret, Sam, and me which I quote from below, with his permission: > It might take some iterations to get the language right but essentially i= t seems that: > > a) only a person can know when they're running in a "safe" > environment, so the UNSAFE_THIRD_PARTY option (or whatever it gets=20 > called) MUST be off by default > > b) there doesn't seem to be any known-safe case for this in the home > > c) there doesn't seem to be any known-safe case for this in a typical off= ice environment > > d) a typical VM environment would not have any known-safe case for this=20 > (just calling this out because sometimes you might consider networking=20 > between VM's on the same h/w safe, but in general its not) > > e) where both hosts involved are equally trusted and operated by the=20 > same entity and all traffic between them is fully trusted already then it= =20 > seems safe for one of them to be a PCP client that uses the=20 > UNSAFE_THIRD_PARTY option to control a PCP server on the other one > if the PCP server has an ACL for addresses allowed to use the option > > f) I think that a developer whose code will only run in environments=20 > like (b)-(d) SHOULD NOT implement UNSAFE_THIRD_PARTY, but a developer > whose code will run only in an place like (e) MAY implement it, and if yo= u're > not sure then don't write that code. > > I think that (e) captures the known-safe use-case that Dave described to= =20 > me where an operator hosts the PCP clients and servers inside its network= . In my view we have ROUGH consensus on the approach in the base spec with restrictions noted in Stephen's (a-f), in order to get it published in a ti= mely fashion. I saw a number of folks on the list saying they can live with it= =20 (assuming it's worded correctly of course), and only 2 people saying they=20 preferred an option that we then found won't pass IESG, but I think that th= en=20 influenced (f). So at present, I'd like the document editors to try to craft text based on Stephen's (a-f) above and post the proposed text to the list. -Dave (as WG chair) --_002_9B57C850BB53634CACEC56EF4853FF653B5B429FTK5EX14MBXW605w_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Sat, 05 May 2012 21:21:11 GMT"; modification-date="Sat, 05 May 2012 21:21:11 GMT" Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.283.4; Sun, 1 Apr 2012 05:22:02 -0700 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.283.4; Sun, 1 Apr 2012 12:22:02 +0000 Received: from mail16-ch1-R.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.283.4; Sun, 1 Apr 2012 12:22:02 +0000 Received: from mail16-ch1 (localhost [127.0.0.1]) by mail16-ch1-R.bigfish.com (Postfix) with ESMTP id 8BCC4200062 for ; Sun, 1 Apr 2012 12:22:01 +0000 (UTC) Received: from mail16-ch1 (localhost.localdomain [127.0.0.1]) by mail16-ch1 (MessageSwitch) id 1333282917778578_13454; Sun, 1 Apr 2012 12:21:57 +0000 (UTC) Received: from CH1EHSMHS028.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.225]) by mail16-ch1.bigfish.com (Postfix) with ESMTP id B9B286004B for ; Sun, 1 Apr 2012 12:21:57 +0000 (UTC) Received: from scss.tcd.ie (134.226.32.56) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server id 14.1.225.23; Sun, 1 Apr 2012 12:21:57 +0000 Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D001B171C05; Sun, 1 Apr 2012 13:21:56 +0100 (IST) Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Fe8cf+IAou12; Sun, 1 Apr 2012 13:21:56 +0100 (IST) Received: from [10.87.48.8] (unknown [86.42.31.132]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A6B29171BFD; Sun, 1 Apr 2012 13:21:55 +0100 (IST) From: Stephen Farrell To: Margaret Wasserman CC: Dave Thaler , "pcp@ietf.org" Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised Thread-Topic: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised Thread-Index: Ac0Og19CMBLvWGdiQCCH4fAtFC8UDgBteGKAAADcioA= Date: Sun, 1 Apr 2012 12:21:55 +0000 Message-ID: <4F784863.1030003@cs.tcd.ie> References: <9B57C850BB53634CACEC56EF4853FF653B4EB9B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <3030A725-EC01-4C51-874D-B19800C27859@lilacglade.org> In-Reply-To: <3030A725-EC01-4C51-874D-B19800C27859@lilacglade.org> Content-Language: en-US X-MS-Exchange-Organization-AuthSource: TK5EX14HUBC103.redmond.corp.microsoft.com X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 x-virus-scanned: Debian amavisd-new at scss.tcd.ie x-bigfish: vps-34(zzbb2dI9371I15bfK1432N98dKzz1202hzz1033IL8275dhz2dh5fh668h839hd25h) dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1333282916; bh=U9ygMXrsonUZJJ uwvRkFm97+GVEkKM/qsEX8aXy3Z4U=; b=ZFde9yESHp4OBgZoxDgmuExKk2QR3E jRGGkF1gIF0oIDr2d+ywC/r4fzwdY00xeB/r6o6BIZB64bIOFBQt9Abjm5yYadr1 eFKY2NRuAojZmVnC8//MuVvM0xwlfZddknax058MkxIdx1o+YHZNgVQ+ffDUyDNn Z36nJjo0mgWxKGdnpcNiMOwRR5gNObInm5FktY7fAvMVw0GY+gICfS1zwjshOgh5 McsigCUR3TtLHiujXD/pMpiL6PXF0LlHCu7fiDw78sE91RW49MI7CTBWtCz2yzTo 1XsPEO52Mm9XyQnK62RWLvOS3jcnxeBI60tv6NL+mVjI2vqKmN0eYPAg== x-spamscore: -34 x-forefront-antispam-report: CIP:134.226.32.56;KIP:(null);UIP:(null);IPV:NLI;H:scss.tcd.ie;RD:hermes.scss.tcd.ie;EFVD:NLI Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hi Margaret, I'm sympathetic with both your and Sam's approaches. The basic problem here is that the PCP wg want to define something that needs security before that security is defined. Doing stuff backwards like that is just going to make it harder and that's what we face. In terms of ordering my preferences, most preferred 1st, that'd be: 1. wait until the required security is defined 2. split out 3rd party until the required security is defined and progress the base in the meantime with no 3rd party option 3. the compromise that Dave outlined, which is to use a new opcode constrained for use (as best we can) only in environments that are "safe" without the additional security that a general 3rd party option needs I'm not at all fond of #3 but can live with it. On 04/01/2012 12:57 PM, Margaret Wasserman wrote: > > Personally, I don't see the value in splitting THIRD_PARTY into two separ= ate option codes that do exactly the same thing. What is the difference be= tween having two different option codes, and having one option code that is= restricted to be used either in safe situations OR with cryptographic secu= rity? I think a separate opcode is less bad since there'd be no reason to implement it for a bunch of implementations where a general 3rd party option would be unsafe. > How can a PCP Server know when it is running in a trusted environment, an= yway? I absolutely agree this is not a good part of the compromise. Some developers will however know that they're never in that environment and won't write the 3rd party code (I hope). > I realize that this is mean to be some shorthand for the DS-Lite case, but it is simply not the case that all DS-Lite deployments will meet these criteria, since I've heard discussion of a B4 running on customer-owned equipment and/or hosts. How can a PCP Server, even if it is running on a DS-Lite AFTR _know_ that every B4 that tries to send a THIRD_PARTY option to the server is owned by the same entity as the PCP Server? > > I'd rather see us go with a solution like this: > > - Keep one THIRD_PARTY option, and don't write a separate THIRD_PARTY doc= ument. > > - Add text to the place in the PCP spec where THIRD_PARTY is defined to s= tate that it MUST be disabled by default in PCP Servers, and that it SHOULD= NOT be enabled unless an access control list (ACL) has been configured. T= he ACL SHOULD contain a list of PCP Clients (by internal IP Address) that a= re allowed to send the THIRD_PARTY option, and a list of addresses or addre= ss ranges for which each authorized PCP Client can issue THIRD_PARTY reques= ts. > > - Add text to the Security Considerations section that the use of THIRD_P= ARTY without a cryptographic security mechanism opens various attack vector= s, and that THIRD_PARTY should only be enabled without cryptographic securi= ty in environments where the authorized PCP Client(s) and the PCP Server ar= e under the same administrative control AND where there is some form of pro= tection against address spoofing, such as layer 2 security or another type = of restricted network access. > > Stephen would that work for you? 'Fraid not. I like that much less than #3 above. Reasons: - If all PCP code includes 3rd party then it will be unsafely turned on in lots of places and we don't even have a WG -00 document for how to address that. - Defining a feature that MUST be implemented, MUST NOT be turned on by default, that SHOULD almost always be disabled, and that can only be turned if you have some (as yet) undefined security stuff is just not a good place to be - I don't see how we can add a "you SHOULD do x" statement to the PCP base now when we don't know what x is, unless you want to hold the pcp base document in the RFC editor queue to wait for x. Hope that helps, Cheers, S. > > Margaret > > > On Mar 30, 2012, at 10:43 AM, Dave Thaler wrote: > >> Based on the feedback received during the meeting and on this thread >> from various people reporting they were blocked on THIRD_PARTY for >> deploying PCP for the web portal case, I met with Stephen Farrell today >> to report on the WG feedback and have a new proposal for the WG's >> review, which Stephen would be okay with if worded properly. >> >> The proposal is to split how we think about THIRD_PARTY into two >> separate options with different Option Codes (though the rest of >> the option format may be identical), one in the base spec and one >> moved out of it. Specifically: >> >> * One is for use cases where the PCP client and PCP server are owned >> and operated by the same entity and are placed on an entirely >> trusted network. That is explicitly not a home network nor a typica= l >> enterprise network. A PCP server intended for a home network >> MUST NOT support this option. This option can appear in the >> pcp-base spec with the above restrictions and is intended to >> unblock the deployments of the people who objected to the >> "separate it out" proposal. As noted below, we rename this option >> to something else (SAME_PARTY?) and use the term THIRD_PARTY >> for the next one. >> >> * The second option would be separated out of the pcp-base spec, >> would mandate that it be protected via whatever advanced security >> mechanism we decide on, and be usable for more general cases >> where the PCP client and PCP server could even be owned by >> different entities and hence the term "THIRD_PARTY" is more >> appropriate to retain for this option. >> >> With appropriate wordsmithing, is this approach something we >> can quickly get consensus on? >> >> -Dave >> >> >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > --_002_9B57C850BB53634CACEC56EF4853FF653B5B429FTK5EX14MBXW605w_-- From dwing@cisco.com Tue May 8 09:31:51 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E9721F84DD for ; Tue, 8 May 2012 09:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.319 X-Spam-Level: X-Spam-Status: No, score=-110.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lqw-Ypn08jwc for ; Tue, 8 May 2012 09:31:50 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 73A3A21F84DC for ; Tue, 8 May 2012 09:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1452; q=dns/txt; s=iport; t=1336494710; x=1337704310; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=4wJP7EJ1Vb3g8AT0MXigQzTWA5F8DcH7WSBOpACR6s4=; b=OIKjrJiixH/SWFKn3ansR5mH4jDy22dQRlYjzdSQKxGtPFDchd6fGHmy WpzJrvpOUgHFZyT25kfGVQ71sD38V4x4Wybg+d9rYJNEfEWOADupFsCfR mp9ZTd12fpY8TwYCZ2xb9gBsCjQ49JNAXSZhGNcnUhmGfABuBOf0vx+Wk s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8FACxKqU+rRDoG/2dsb2JhbABEomqQQIEHghMICgEXED8NBRhQIxwBBB4Xh2ubNKA0jW+DJgSIZIUWll2BaYMJ X-IronPort-AV: E=Sophos;i="4.75,552,1330905600"; d="scan'208";a="40868335" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 08 May 2012 16:31:50 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q48GVnSY023056; Tue, 8 May 2012 16:31:50 GMT From: "Dan Wing" To: Date: Tue, 8 May 2012 09:31:49 -0700 Message-ID: <02e601cd2d38$11a50ba0$34ef22e0$@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: Ac0tOBFh4GD3eZt7QfaL3evp2Gcbkg== Content-Language: en-us Cc: draft-ietf-pcp-base@tools.ietf.org Subject: [pcp] PCP robustness for Rapid Recovery X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 16:31:51 -0000 Another upcoming change for pcp-base was Pete Resnick's suggestion at IETF83 in the PCP meeting (and in the hallways prior to the PCP meeting), that PCP be 'more robust' when the server noticed a mapping needed to be updated (e.g., when the NAT's public IP address changed or when the PCP server lost state). As background, Rapid Recovery is the ANNOUNCE Opcode (sent when the PCP server loses state) and the Mapping Update (the second response in the "request-response-response" model of PCP, where the PCP server maintains state but realizes that the mapping information has changed -- such as a new IP address for the mapping). The current specification is lenient regarding Rapid Recovery and Mapping Update, describing both as somewhat optional and unnecessary. This is because the PCP philosophy has been that PCP should be "as good as" sending a TCP SYN. Pete suggested that PCP can be better, and that PCP should be better -- that is, the PCP specification should be changed to say a PCP server "SHOULD" implement Mapping Update (see Section 14.2 in draft-ietf-pcp-base-24), and that it transmit those Mapping Update packets several times (to accommodate packet loss). Similarly, when sending the ANNOUNCE Opcode, change from "MAY send up to 10 times" to "SHOULD transmit 10 times" (I believe the other text for ANNOUNCE does not need changing). Please let me know if there are objections to this change. -d From dxhbupt@gmail.com Wed May 9 01:58:22 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90B521F8573 for ; Wed, 9 May 2012 01:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8sqgBosf6as for ; Wed, 9 May 2012 01:58:22 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF01421F855A for ; Wed, 9 May 2012 01:58:18 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so25007wgb.13 for ; Wed, 09 May 2012 01:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ifu606xTBRfqbnDdw2MHJdBlJnQ1Xrmq2KypxZ8ryek=; b=AtpsvrS6BEqvWz+Zmc5sGso/3PVV7NT7Eu3foPyIknOU3slwgOr6wtzfLXvUd7mear +VovJs0mGclcAd599l3pt7jQiUM/ZttcYrSQUBE+41zpXJBDdmJFRw56V+Zln3/IRkUv 1zWA90m9Z5+OtmblNc1Vb+PjK8G9mk5Bh5KDOdqYuJKipXt2rJUAGOTKPR0FfBBT83aj TCEmgh0Efk/SNm7nqMPmwB2tn39FLOSI+OTHpfGHXfihD8Lc+SXG/r8073KlOra/cLuE 8zOLKEkxHI1FZxkoPneYeQt9/21Sfoeg49akrEkzTu0OwKTWf0bm95P4N/UKnxZu0PEs f41g== MIME-Version: 1.0 Received: by 10.216.213.79 with SMTP id z57mr3528246weo.27.1336553897955; Wed, 09 May 2012 01:58:17 -0700 (PDT) Received: by 10.180.85.105 with HTTP; Wed, 9 May 2012 01:58:17 -0700 (PDT) In-Reply-To: <02e601cd2d38$11a50ba0$34ef22e0$@com> References: <02e601cd2d38$11a50ba0$34ef22e0$@com> Date: Wed, 9 May 2012 16:58:17 +0800 Message-ID: From: Xiaohong Deng To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pcp@ietf.org, draft-ietf-pcp-base@tools.ietf.org Subject: Re: [pcp] PCP robustness for Rapid Recovery X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 08:58:22 -0000 On Wed, May 9, 2012 at 12:31 AM, Dan Wing wrote: > Another upcoming change for pcp-base was Pete Resnick's suggestion at IET= F83 > in the PCP meeting (and in the hallways prior to the PCP meeting), that P= CP > be 'more robust' when the server noticed a mapping needed to be updated > (e.g., when the NAT's public IP address changed or when the PCP server lo= st > state). > > As background, Rapid Recovery is the ANNOUNCE Opcode (sent when the PCP > server loses state) and the Mapping Update (the second response in the > "request-response-response" model of PCP, where the PCP server maintains > state but realizes that the mapping information has changed -- such as a = new > IP address for the mapping). =A0The current specification is lenient rega= rding > Rapid Recovery and Mapping Update, describing both as somewhat optional a= nd > unnecessary. =A0This is because the PCP philosophy has been that PCP shou= ld be > "as good as" sending a TCP SYN. > > Pete suggested that PCP can be better, and that PCP should be better -- t= hat > is, the PCP specification should be changed to say =A0a PCP server "SHOUL= D" > implement Mapping Update (see Section 14.2 in draft-ietf-pcp-base-24), an= d > that it transmit those Mapping Update packets several times (to accommoda= te > packet loss). =A0Similarly, when sending the ANNOUNCE Opcode, change from= "MAY > send up to 10 times" to "SHOULD transmit 10 times" (I believe the other t= ext > for ANNOUNCE does not need changing). Doubt about the necessity of this change, because for some cases, for example, in case of a nested NAT where the middle level NAT acts both as a client and a server, there is a need to implement the PCP server in a light weight, and retransmitting 10 times doesn't look like a necessity in such a case. So IMO, the word MAY would leave more rooms for implementers' decision case by case. My five cent. -Xiaohong Open source mB4 for Multicast DS-Lite: http://sourceforge.net/projects/mb4/ Open source PCP: http://sourceforge.net/projects/pcpclient/ Open source A+P: http://opensourceaplusp.weebly.com/ > > Please let me know if there are objections to this change. > > -d > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp -- From dwing@cisco.com Wed May 9 08:19:01 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA7C21F84E4 for ; Wed, 9 May 2012 08:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.378 X-Spam-Level: X-Spam-Status: No, score=-110.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftLeCEart-wX for ; Wed, 9 May 2012 08:19:00 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id D0A1E11E80A4 for ; Wed, 9 May 2012 08:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2890; q=dns/txt; s=iport; t=1336576696; x=1337786296; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=tkl18PQnVD+VK2Y8h5VsMBRk4GtTGCBVT3VF9K5YPRY=; b=An9CgM8zAS6cVbZEp4Rpns7V8cBKOkokiXzEA5QfgFaMZtoXh1Pggur4 W93fL3LAnRd0EI1zf9WA5gsYuuWGSQr6xJ1qQSpa7NbCWpdopUz80m0Cm 86ru+oBgEX28x3Gno+NbloQllNu7Du3n5oc48J1tVHwOIdmTOG1ZdaJbq A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAHqKqk+rRDoH/2dsb2JhbABEow6QLIEHggwBAQEDAQEBAQUKARdECwUHAQMCCQ4BAgQBAQEnBxkIBhUKCQgBAQQTCxeHXgMGBAybW5ZBDYlTiiFrhhIEiDA0hRaJFIotgxqBaYMJ X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="41553232" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 09 May 2012 15:18:16 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q49FIGJq031728; Wed, 9 May 2012 15:18:16 GMT From: "Dan Wing" To: "'Xiaohong Deng'" References: <02e601cd2d38$11a50ba0$34ef22e0$@com> In-Reply-To: Date: Wed, 9 May 2012 08:18:16 -0700 Message-ID: <067501cd2df6$f54a62b0$dfdf2810$@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: Ac0tweeHQA6vlcudTnyaG4T7OjQcUwANOSMg Content-Language: en-us Cc: pcp@ietf.org, draft-ietf-pcp-base@tools.ietf.org Subject: Re: [pcp] PCP robustness for Rapid Recovery X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 15:19:01 -0000 > -----Original Message----- > From: Xiaohong Deng [mailto:dxhbupt@gmail.com] > Sent: Wednesday, May 09, 2012 1:58 AM > To: Dan Wing > Cc: pcp@ietf.org; draft-ietf-pcp-base@tools.ietf.org > Subject: Re: [pcp] PCP robustness for Rapid Recovery >=20 > On Wed, May 9, 2012 at 12:31 AM, Dan Wing wrote: > > Another upcoming change for pcp-base was Pete Resnick's suggestion = at > IETF83 > > in the PCP meeting (and in the hallways prior to the PCP meeting), > that PCP > > be 'more robust' when the server noticed a mapping needed to be > updated > > (e.g., when the NAT's public IP address changed or when the PCP > server lost > > state). > > > > As background, Rapid Recovery is the ANNOUNCE Opcode (sent when the > PCP > > server loses state) and the Mapping Update (the second response in > the > > "request-response-response" model of PCP, where the PCP server > maintains > > state but realizes that the mapping information has changed -- such > as a new > > IP address for the mapping). =A0The current specification is lenient > regarding > > Rapid Recovery and Mapping Update, describing both as somewhat > optional and > > unnecessary. =A0This is because the PCP philosophy has been that PCP > should be > > "as good as" sending a TCP SYN. > > > > Pete suggested that PCP can be better, and that PCP should be better > -- that > > is, the PCP specification should be changed to say =A0a PCP server > "SHOULD" > > implement Mapping Update (see Section 14.2 in draft-ietf-pcp-base- > 24), and > > that it transmit those Mapping Update packets several times (to > accommodate > > packet loss). =A0Similarly, when sending the ANNOUNCE Opcode, change > from "MAY > > send up to 10 times" to "SHOULD transmit 10 times" (I believe the > other text > > for ANNOUNCE does not need changing). >=20 > Doubt about the necessity of this change, because for some cases, for > example, in case of a nested NAT where the middle level NAT acts both > as a client and a server, there is a need to implement the PCP server > in a light weight, and retransmitting 10 times doesn't look like a > necessity in such a case. So IMO, the word MAY would leave more rooms > for implementers' decision case by case. Sorry -- are you saying you agree with the change in general, and=20 would like a lower recommended value than 10? -d > My five cent. > -Xiaohong >=20 > Open source mB4 for Multicast DS-Lite: > http://sourceforge.net/projects/mb4/ > Open source PCP: http://sourceforge.net/projects/pcpclient/ > Open source A+P: http://opensourceaplusp.weebly.com/ > > > > Please let me know if there are objections to this change. > > > > -d > > > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp >=20 >=20 >=20 > -- From cheshire@apple.com Wed May 9 11:52:40 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2315521F8493 for ; Wed, 9 May 2012 11:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ub93a2tr12TU for ; Wed, 9 May 2012 11:52:39 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 96D2A21F8491 for ; Wed, 9 May 2012 11:52:39 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M3R00KD7R2GCYB1@mail-out.apple.com> for pcp@ietf.org; Wed, 09 May 2012 11:52:03 -0700 (PDT) X-AuditID: 11807137-b7f536d000006fcc-ae-4faabcd351dd Received: from [17.193.13.41] (chesh1.apple.com [17.193.13.41]) by relay16.apple.com (Apple SCV relay) with SMTP id 43.40.28620.3DCBAAF4; Wed, 09 May 2012 11:52:03 -0700 (PDT) In-reply-to: <02e601cd2d38$11a50ba0$34ef22e0$@com> References: <02e601cd2d38$11a50ba0$34ef22e0$@com> Message-id: <23F545DB-2531-4E88-9C1D-53BA53E4D207@apple.com> From: Stuart Cheshire Date: Wed, 09 May 2012 11:51:39 -0700 To: Dan Wing X-Mailer: Apple Mail (2.753.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUieJBXU/fynlX+Bl+f6Vhs+VBrcfHaQyaL ycd+szowe0z5vZHVY8mSn0weXy5/ZgtgjuKySUnNySxLLdK3S+DK+PfhL1vBQ7GKrx3nGRsY zwt2MXJySAiYSGxd2cwGYYtJXLi3Hsjm4hAS2MgosfrGRiaQBKeAkUTLhTb2LkYOoIShxJWj 6iBhXqDw1clTwcLMAi4SC6fkQYRtJCYc+coIYjMLmEm8n7qVBcKWl9j+dg4ziM0moCXx4vMV NpBWYQE9iUkTwcpZBFQkXmzZCmaLCMhJ3J0/gRniMjmJw6dfMU5g5J+FZPEshMWzkCxYwMi8 ilGwKDUnsdLQTC+xoCAnVS85P3cTIygAGwrNdzBu/yt3iFGAg1GJh1eyZZW/EGtiWXFl7iFG CQ5mJRFeN2D4CvGmJFZWpRblxxeV5qQWH2KU5mBREuc9LLvAX0ggPbEkNTs1tSC1CCbLxMEp 1cB44ERXjsGh+Cp93W1Hy7Z2qjQqlXBxrlHkZ2tKfpYQuMPw49UvpbsnVuhF8P9n+HW6qqu4 wr30kfoMQZ0GZvdrG0wcf1bsklvwTVvs0SOPDZH3vU7Z2uTwrPjxLEM8t8Boyuqr3tL/7jy8 3dZRtYvZpXDHvQCNmQ4nuFV0SmOj99a3fYpbs1GJpTgj0VCLuag4EQCu7RLaPAIAAA== Cc: pcp@ietf.org, draft-ietf-pcp-base@tools.ietf.org Subject: Re: [pcp] PCP robustness for Rapid Recovery X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 18:52:40 -0000 On 8 May, 2012, at 09:31, Dan Wing wrote: > Another upcoming change for pcp-base was Pete Resnick's suggestion > at IETF83 > in the PCP meeting (and in the hallways prior to the PCP meeting), > that PCP > be 'more robust' when the server noticed a mapping needed to be > updated > (e.g., when the NAT's public IP address changed or when the PCP > server lost > state). Pete made good points. Today he runs servers at home, with static IP addresses. Other people run servers at home by manually configuring their NAT gateway with static port mappings. PCP offers a way to automate this, which is great, but *not* if it results in hours of server downtime. Pete wants a NAT gateway with PCP to work at least as well as a NAT gateway with manual static port mappings. In other words, after a NAT gateway reboot Pete wants his servers reachable again within a few seconds, not a few hours. If it takes PCP an hour or two to restore mappings lost after a NAT gateway reboot, then all the "expert" advice is going to be, "Forget PCP: make manual static port mappings just like you used to." If we want PCP to be taken seriously, it has to compete credibly with today's status quo. (Note that NAT-PMP had Rapid Recovery from the start, so it never suffered this criticism.) > Pete suggested that PCP can be better, and that PCP should be > better -- that > is, the PCP specification should be changed to say a PCP server > "SHOULD" > implement Mapping Update (see Section 14.2 in draft-ietf-pcp- > base-24), and > that it transmit those Mapping Update packets several times (to > accommodate > packet loss). Similarly, when sending the ANNOUNCE Opcode, change > from "MAY > send up to 10 times" to "SHOULD transmit 10 times" (I believe the > other text > for ANNOUNCE does not need changing). > > Please let me know if there are objections to this change. > > -d I think Pete is right. These changes should be made. Changing MAY to SHOULD does not in any way change what anyone's code has to do. Both are optional. It does however set the a particular editorial tone for the document. When a customer tells a vendor they'd like the NAT gateway not take an hour or two to recover after a reboot, the MAY/SHOULD language signifies whether or not we, as a group, believe that's a reasonable thing to want. Using "MAY" suggests that we think taking an hour or two to recover is acceptable, and wanting it to recover faster is specialized and unusual. Using "SHOULD" suggests that we think it's reasonable and normal to want the NAT gateway to recover quickly. I vote for "SHOULD". I want PCP to work really well. I don't want it to be the protocol where all the "experts" know that you're better off ignoring it and using manual static port mappings instead. Stuart Cheshire From repenno@cisco.com Wed May 9 14:31:50 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC4811E80C8 for ; Wed, 9 May 2012 14:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.04 X-Spam-Level: X-Spam-Status: No, score=-10.04 tagged_above=-999 required=5 tests=[AWL=0.559, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0h76zAJAfc-A for ; Wed, 9 May 2012 14:31:49 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6743C11E80BF for ; Wed, 9 May 2012 14:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=3422; q=dns/txt; s=iport; t=1336599109; x=1337808709; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=vecGlczfuqIOrXVutcOBklF1ou5L5st1+X4eyj5kRkM=; b=TkghKWU6Z6pvv6+MbJRHXSoUedbYo4NzAtBYgBxTEbK1EzcdG+zJ7b5J PdNmgKFVMnv6m7Lx6hun5ZiOkhSkv4dcjqV2ORe167Ee1nPHomQcMYh92 4xfO0OD8MPYS10xIyVwb9ho5m8DwPMiAS83d/TxOBamjLxVGe6itXibzJ s=; X-IronPort-AV: E=Sophos;i="4.75,559,1330905600"; d="scan'208";a="41066394" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 09 May 2012 21:31:49 +0000 Received: from [10.21.124.42] (sjc-vpn6-1066.cisco.com [10.21.124.42]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q49LViSb031101; Wed, 9 May 2012 21:31:47 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Wed, 09 May 2012 14:30:53 -0700 From: Reinaldo Penno To: Stuart Cheshire , Dan Wing Message-ID: Thread-Topic: [pcp] PCP robustness for Rapid Recovery In-Reply-To: <23F545DB-2531-4E88-9C1D-53BA53E4D207@apple.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pcp@ietf.org, draft-ietf-pcp-base@tools.ietf.org Subject: Re: [pcp] PCP robustness for Rapid Recovery X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 21:31:50 -0000 PCP needs to be a suitable replacement for static port forwarding otherwise it will severely weaken PCP applicability. That's why I pushed for web portals, rapid recovery and third_party. I'm glad that Pete's statement finally resonated. PCP also needs to work through non-PCP capable NATs. On 5/9/12 11:51 AM, "Stuart Cheshire" wrote: >On 8 May, 2012, at 09:31, Dan Wing wrote: > >> Another upcoming change for pcp-base was Pete Resnick's suggestion >> at IETF83 >> in the PCP meeting (and in the hallways prior to the PCP meeting), >> that PCP >> be 'more robust' when the server noticed a mapping needed to be >> updated >> (e.g., when the NAT's public IP address changed or when the PCP >> server lost >> state). > >Pete made good points. Today he runs servers at home, with static IP >addresses. > >Other people run servers at home by manually configuring their NAT >gateway with static port mappings. > >PCP offers a way to automate this, which is great, but *not* if it >results in hours of server downtime. > >Pete wants a NAT gateway with PCP to work at least as well as a NAT >gateway with manual static port mappings. In other words, after a NAT >gateway reboot Pete wants his servers reachable again within a few >seconds, not a few hours. > >If it takes PCP an hour or two to restore mappings lost after a NAT >gateway reboot, then all the "expert" advice is going to be, "Forget >PCP: make manual static port mappings just like you used to." > >If we want PCP to be taken seriously, it has to compete credibly with >today's status quo. > >(Note that NAT-PMP had Rapid Recovery from the start, so it never >suffered this criticism.) > >> Pete suggested that PCP can be better, and that PCP should be >> better -- that >> is, the PCP specification should be changed to say a PCP server >> "SHOULD" >> implement Mapping Update (see Section 14.2 in draft-ietf-pcp- >> base-24), and >> that it transmit those Mapping Update packets several times (to >> accommodate >> packet loss). Similarly, when sending the ANNOUNCE Opcode, change >> from "MAY >> send up to 10 times" to "SHOULD transmit 10 times" (I believe the >> other text >> for ANNOUNCE does not need changing). >> >> Please let me know if there are objections to this change. >> >> -d > >I think Pete is right. These changes should be made. > >Changing MAY to SHOULD does not in any way change what anyone's code >has to do. Both are optional. It does however set the a particular >editorial tone for the document. When a customer tells a vendor >they'd like the NAT gateway not take an hour or two to recover after >a reboot, the MAY/SHOULD language signifies whether or not we, as a >group, believe that's a reasonable thing to want. Using "MAY" >suggests that we think taking an hour or two to recover is >acceptable, and wanting it to recover faster is specialized and >unusual. Using "SHOULD" suggests that we think it's reasonable and >normal to want the NAT gateway to recover quickly. > >I vote for "SHOULD". I want PCP to work really well. I don't want it >to be the protocol where all the "experts" know that you're better >off ignoring it and using manual static port mappings instead. > >Stuart Cheshire > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From dxhbupt@gmail.com Wed May 9 20:56:17 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C907711E80AF for ; Wed, 9 May 2012 20:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKOo3DX7MnAk for ; Wed, 9 May 2012 20:56:17 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B10FD11E8087 for ; Wed, 9 May 2012 20:56:16 -0700 (PDT) Received: by werf13 with SMTP id f13so779429wer.31 for ; Wed, 09 May 2012 20:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3UtcWrE0vvot5nfPj4QDnxO9E+ouvvZKx4OiFX2v/D8=; b=J1j1brM1Mih4Il1q8MLUadqyyXj3b8S/OkyWQss/h0N1pHKDipLsdDiMw75xMu6Uge ymTvL7Ndz0osBM7BerATNy8g1bt3rYwLAWQv2Q75xAxOhbQs8qORg3i7TRUQy6Za2EoS Xe1pvKEvbVHIFue48xlo0une07aAg5FfrKam7mYPUQchOi5w7URSvjFIAeEtkZGSa4qx 8c4lSna+HnOf/iOHqV7amF6KO35s4JpcmVWTjVTvLQJ/IRvsXnFugZL7LTmRlbHSgnuy vvDlb257Md7/fN+RdMA92Q5wixbvzrirX67KIC/b9+NSx51WctGPoIUC3iwKRobwyaCW p9kw== MIME-Version: 1.0 Received: by 10.180.109.197 with SMTP id hu5mr5754911wib.8.1336622175526; Wed, 09 May 2012 20:56:15 -0700 (PDT) Received: by 10.180.85.105 with HTTP; Wed, 9 May 2012 20:56:15 -0700 (PDT) In-Reply-To: <067501cd2df6$f54a62b0$dfdf2810$@com> References: <02e601cd2d38$11a50ba0$34ef22e0$@com> <067501cd2df6$f54a62b0$dfdf2810$@com> Date: Thu, 10 May 2012 11:56:15 +0800 Message-ID: From: Xiaohong Deng To: Dan Wing Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: pcp@ietf.org, draft-ietf-pcp-base@tools.ietf.org Subject: Re: [pcp] PCP robustness for Rapid Recovery X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 03:56:17 -0000 On Wed, May 9, 2012 at 11:18 PM, Dan Wing wrote: >> -----Original Message----- >> From: Xiaohong Deng [mailto:dxhbupt@gmail.com] >> Sent: Wednesday, May 09, 2012 1:58 AM >> To: Dan Wing >> Cc: pcp@ietf.org; draft-ietf-pcp-base@tools.ietf.org >> Subject: Re: [pcp] PCP robustness for Rapid Recovery >> >> On Wed, May 9, 2012 at 12:31 AM, Dan Wing wrote: >> > Another upcoming change for pcp-base was Pete Resnick's suggestion at >> IETF83 >> > in the PCP meeting (and in the hallways prior to the PCP meeting), >> that PCP >> > be 'more robust' when the server noticed a mapping needed to be >> updated >> > (e.g., when the NAT's public IP address changed or when the PCP >> server lost >> > state). >> > >> > As background, Rapid Recovery is the ANNOUNCE Opcode (sent when the >> PCP >> > server loses state) and the Mapping Update (the second response in >> the >> > "request-response-response" model of PCP, where the PCP server >> maintains >> > state but realizes that the mapping information has changed -- such >> as a new >> > IP address for the mapping). =A0The current specification is lenient >> regarding >> > Rapid Recovery and Mapping Update, describing both as somewhat >> optional and >> > unnecessary. =A0This is because the PCP philosophy has been that PCP >> should be >> > "as good as" sending a TCP SYN. >> > >> > Pete suggested that PCP can be better, and that PCP should be better >> -- that >> > is, the PCP specification should be changed to say =A0a PCP server >> "SHOULD" >> > implement Mapping Update (see Section 14.2 in draft-ietf-pcp-base- >> 24), and >> > that it transmit those Mapping Update packets several times (to >> accommodate >> > packet loss). =A0Similarly, when sending the ANNOUNCE Opcode, change >> from "MAY >> > send up to 10 times" to "SHOULD transmit 10 times" (I believe the >> other text >> > for ANNOUNCE does not need changing). >> >> Doubt about the necessity of this change, because for some cases, for >> example, in case of a nested NAT where the middle level NAT acts both >> as a client and a server, there is a need to implement the PCP server >> in a light weight, and retransmitting 10 times doesn't look like a >> necessity in such a case. So IMO, the word MAY would leave more rooms >> for implementers' decision case by case. > > Sorry -- are you saying you agree with the change in general, and > would like a lower recommended value than 10? Yes, I agree the changes in general proposed by Pete are pretty good. And yes, after comments coming up from Stuart in this thread to vote using the wording =91SHOULD=92, for conveying idea of the importance of PCP=92s reliability, which I agree, I vote for lowering recommended time below 10. Reasons are below. 10 would be a good recommended value for recovering from network failure, given the typical retransmission times for the sake of assuring network reliability. For example, minimal 3 and maximal 15 are set as TCP retransmission default values, according to previous RFC and work pretty well in most current and wide deployed practice, e.g., linux since 2.2. However, PCP server=92s performance limits on handling concurrent sessions would be another major cause of retransmission. In this case, thousands of clients concurrently retransmitting up to 10 after a PCP server has already reached its limits would, on the opposite, slow down PCP server=92s rapid recovery. Therefore, a compromised recommended value, let=92s say 5, taking into account these two causes IMO, would do better. My 5 cent. -Xiaohong Open source mB4 for Multicast DS-Lite: http://sourceforge.net/projects/mb4/ Open source PCP: http://sourceforge.net/projects/pcpclient/ Open source A+P: http://opensourceaplusp.weebly.com/ > > -d > > >> My five cent. >> -Xiaohong >> >> Open source mB4 for Multicast DS-Lite: >> http://sourceforge.net/projects/mb4/ >> Open source PCP: http://sourceforge.net/projects/pcpclient/ >> Open source A+P: http://opensourceaplusp.weebly.com/ >> > >> > Please let me know if there are objections to this change. >> > >> > -d >> > >> > >> > _______________________________________________ >> > pcp mailing list >> > pcp@ietf.org >> > https://www.ietf.org/mailman/listinfo/pcp >> >> >> >> -- > -- From dwing@cisco.com Thu May 10 07:59:56 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD3D21F86C6 for ; Thu, 10 May 2012 07:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.389 X-Spam-Level: X-Spam-Status: No, score=-110.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkaYA6qBAsIz for ; Thu, 10 May 2012 07:59:56 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id ED02121F869A for ; Thu, 10 May 2012 07:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=7183; q=dns/txt; s=iport; t=1336661996; x=1337871596; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=UJzKM3stZleS5g+C9YN3k5hNmLTkD5PIXtjzC7B6Koo=; b=Y3wLyxSm8z01FdyXHb7ZEs+bCSmpkdW1BdWBkcyCvAVHL2AHJ1yFpfLB bMpquGdf/LEIZrMa2HVSKXwHjyo0BkNbzNIGNkKGwoIRjmXMlKNRkBSAQ ZQuaE6fk/vOyvevRbwASIO4BfAoq5vGuzSeffGemknREOiySMNAY0YKke o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQFAN/Wq0+rRDoG/2dsb2JhbABEoxiQc4EHghUBAQEDAQEBAQUKARQDRAsFBwEDAgkOAQIEAQEBFRIHGQgGFQoJCAEBBBMLF4deAwYEDJselj4NiVOKJW0cgluDMgSIMDSFFokUiiyDGoFpgwmBNgc X-IronPort-AV: E=Sophos;i="4.75,565,1330905600"; d="scan'208";a="44271654" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 10 May 2012 14:59:55 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q4AExtHQ028710; Thu, 10 May 2012 14:59:55 GMT From: "Dan Wing" To: "'Xiaohong Deng'" References: <02e601cd2d38$11a50ba0$34ef22e0$@com> <067501cd2df6$f54a62b0$dfdf2810$@com> In-Reply-To: Date: Thu, 10 May 2012 07:59:55 -0700 Message-ID: <09a701cd2ebd$8f9166e0$aeb434a0$@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: Ac0uYOBj+p+XfketS+SmCSpQD4iFLwAWwkJQ Content-Language: en-us Cc: pcp@ietf.org, draft-ietf-pcp-base@tools.ietf.org Subject: Re: [pcp] PCP robustness for Rapid Recovery X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 14:59:57 -0000 > -----Original Message----- > From: Xiaohong Deng [mailto:dxhbupt@gmail.com] > Sent: Wednesday, May 09, 2012 8:56 PM > To: Dan Wing > Cc: pcp@ietf.org; draft-ietf-pcp-base@tools.ietf.org > Subject: Re: [pcp] PCP robustness for Rapid Recovery >=20 > On Wed, May 9, 2012 at 11:18 PM, Dan Wing wrote: > >> -----Original Message----- > >> From: Xiaohong Deng [mailto:dxhbupt@gmail.com] > >> Sent: Wednesday, May 09, 2012 1:58 AM > >> To: Dan Wing > >> Cc: pcp@ietf.org; draft-ietf-pcp-base@tools.ietf.org > >> Subject: Re: [pcp] PCP robustness for Rapid Recovery > >> > >> On Wed, May 9, 2012 at 12:31 AM, Dan Wing wrote: > >> > Another upcoming change for pcp-base was Pete Resnick's = suggestion > at > >> IETF83 > >> > in the PCP meeting (and in the hallways prior to the PCP = meeting), > >> that PCP > >> > be 'more robust' when the server noticed a mapping needed to be > >> updated > >> > (e.g., when the NAT's public IP address changed or when the PCP > >> server lost > >> > state). > >> > > >> > As background, Rapid Recovery is the ANNOUNCE Opcode (sent when > the > >> PCP > >> > server loses state) and the Mapping Update (the second response = in > >> the > >> > "request-response-response" model of PCP, where the PCP server > >> maintains > >> > state but realizes that the mapping information has changed -- > such > >> as a new > >> > IP address for the mapping). =A0The current specification is = lenient > >> regarding > >> > Rapid Recovery and Mapping Update, describing both as somewhat > >> optional and > >> > unnecessary. =A0This is because the PCP philosophy has been that = PCP > >> should be > >> > "as good as" sending a TCP SYN. > >> > > >> > Pete suggested that PCP can be better, and that PCP should be > better > >> -- that > >> > is, the PCP specification should be changed to say =A0a PCP = server > >> "SHOULD" > >> > implement Mapping Update (see Section 14.2 in = draft-ietf-pcp-base- > >> 24), and > >> > that it transmit those Mapping Update packets several times (to > >> accommodate > >> > packet loss). =A0Similarly, when sending the ANNOUNCE Opcode, = change > >> from "MAY > >> > send up to 10 times" to "SHOULD transmit 10 times" (I believe the > >> other text > >> > for ANNOUNCE does not need changing). > >> > >> Doubt about the necessity of this change, because for some cases, > for > >> example, in case of a nested NAT where the middle level NAT acts > both > >> as a client and a server, there is a need to implement the PCP > server > >> in a light weight, and retransmitting 10 times doesn't look like a > >> necessity in such a case. So IMO, the word MAY would leave more > rooms > >> for implementers' decision case by case. > > > > Sorry -- are you saying you agree with the change in general, and > > would like a lower recommended value than 10? >=20 > Yes, I agree the changes in general proposed by Pete are pretty good. >=20 > And yes, after comments coming up from Stuart in this thread to vote > using the wording =91SHOULD=92, for conveying idea of the importance = of > PCP=92s reliability, which I agree, I vote for lowering recommended = time > below 10. Reasons are below. >=20 > 10 would be a good recommended value for recovering from network > failure, given the typical retransmission times for the sake of > assuring network reliability. For example, minimal 3 and maximal 15 > are set as TCP retransmission default values, according to previous > RFC and work pretty well in most current and wide deployed practice, > e.g., linux since 2.2. However, PCP server=92s performance limits on > handling concurrent sessions would be another major cause of > retransmission. In this case, thousands of clients concurrently > retransmitting up to 10 after a PCP server has already reached its > limits would, on the opposite, slow down PCP server=92s rapid = recovery. The clients will only react once, no matter how often the server re-transmits is ANNOUNCE message. This is because once a client=20 receives the first ANNOUNCE, the Epoch Time is "wrong" (too high or too low) which will cause the client to re-establish its PCP mappings. However, subsequent retransmissions of ANNOUNCE will have the expected Epoch Time value, and will not cause a reaction by the PCP client (that is, the PCP client will not send new PCP requests because of that ANNOUNCE). =20 PCP client PCP server | | |-----MAP---------------->| |<-Ok, Epoch=3D123456-------| | | ... ... ... (hours later) ... ... ... | |=20 | (power lost) | (power restored) | | |<--ANNOUNCE, Epoch=3D0-----| | (multicasted) | | | (Uh-oh. that PCP | server's Epoch is | wrong. It must | have lost state.) | | | |-----MAP---------------->| |<-Ok, Epoch=3D123456-------| | | |<--ANNOUNCE, Epoch=3D1-----| | (multicasted) | =20 | | (that PCP server's | Epoch is correct) | | | |<--ANNOUNCE, Epoch=3D2-----| | (multicasted) | =20 | | (that PCP server's | Epoch is correct) | | | |<--ANNOUNCE, Epoch=3D4-----| | (multicasted) | =20 | | (that PCP server's | Epoch is correct) | | | ... > Therefore, a compromised recommended value, let=92s say 5, taking into > account these two causes IMO, would do better. With the explanation above, do you still want the PCP server to only send it 5 times? A problem with sending the unsolicited ANNOUNCE is the PCP server has no way to determine if all the clients have seen the message. -d > My 5 cent. > -Xiaohong >=20 > Open source mB4 for Multicast DS-Lite: > http://sourceforge.net/projects/mb4/ > Open source PCP: http://sourceforge.net/projects/pcpclient/ > Open source A+P: http://opensourceaplusp.weebly.com/ >=20 > > > > -d > > > > > >> My five cent. > >> -Xiaohong > >> > >> Open source mB4 for Multicast DS-Lite: > >> http://sourceforge.net/projects/mb4/ > >> Open source PCP: http://sourceforge.net/projects/pcpclient/ > >> Open source A+P: http://opensourceaplusp.weebly.com/ > >> > > >> > Please let me know if there are objections to this change. > >> > > >> > -d > >> > > >> > > >> > _______________________________________________ > >> > pcp mailing list > >> > pcp@ietf.org > >> > https://www.ietf.org/mailman/listinfo/pcp > >> > >> > >> > >> -- > > >=20 >=20 >=20 > -- From dxhbupt@gmail.com Thu May 10 23:51:36 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB46521F8620 for ; Thu, 10 May 2012 23:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXiM2fGqaYyj for ; Thu, 10 May 2012 23:51:36 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C75421F861F for ; Thu, 10 May 2012 23:51:35 -0700 (PDT) Received: by werf13 with SMTP id f13so1091299wer.31 for ; Thu, 10 May 2012 23:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MG3K8h+4XpPqhMbiALvbwgOhFhO7W6P9/UV52RbQ9z4=; b=w7PxMiPlq5fG6akBYUs5Pld9dEgYZYRew/XbzUlPDdkV5/KOcMPGG8itOahaNqNKLK sWI+w2vx7cJHQMsBona5Y3JNPVP764CJyfccmQv3o7wgnWdmoHl8GrC2IKM/PUWvRFsQ kC+xNRiAhif7uvg+88eHtIwT/IpV7jUYCKB7ZtWcUxOvNgpjmjofyKg/TiBAE75h3N+H RnuGn+GgWN6KcAuesIzSgR4jhBjMpAgCPtNMjxXlFsUxDW72TB3jMsnYnYQTKj2M4KMx 3aRVTXMq0fq6pdO3ETa403AUnHP7lly+bAaE9sPU6WRdPvqwRyChERNDd34h/sHQiLTR 9iUQ== MIME-Version: 1.0 Received: by 10.216.140.218 with SMTP id e68mr724076wej.11.1336719094536; Thu, 10 May 2012 23:51:34 -0700 (PDT) Received: by 10.180.85.105 with HTTP; Thu, 10 May 2012 23:51:34 -0700 (PDT) In-Reply-To: <09a701cd2ebd$8f9166e0$aeb434a0$@com> References: <02e601cd2d38$11a50ba0$34ef22e0$@com> <067501cd2df6$f54a62b0$dfdf2810$@com> <09a701cd2ebd$8f9166e0$aeb434a0$@com> Date: Fri, 11 May 2012 14:51:34 +0800 Message-ID: From: Xiaohong Deng To: Dan Wing Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: pcp@ietf.org, draft-ietf-pcp-base@tools.ietf.org Subject: Re: [pcp] PCP robustness for Rapid Recovery X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 06:51:37 -0000 On Thu, May 10, 2012 at 10:59 PM, Dan Wing wrote: >> -----Original Message----- >> From: Xiaohong Deng [mailto:dxhbupt@gmail.com] >> Sent: Wednesday, May 09, 2012 8:56 PM >> To: Dan Wing >> Cc: pcp@ietf.org; draft-ietf-pcp-base@tools.ietf.org >> Subject: Re: [pcp] PCP robustness for Rapid Recovery >> >> On Wed, May 9, 2012 at 11:18 PM, Dan Wing wrote: >> >> -----Original Message----- >> >> From: Xiaohong Deng [mailto:dxhbupt@gmail.com] >> >> Sent: Wednesday, May 09, 2012 1:58 AM >> >> To: Dan Wing >> >> Cc: pcp@ietf.org; draft-ietf-pcp-base@tools.ietf.org >> >> Subject: Re: [pcp] PCP robustness for Rapid Recovery >> >> >> >> On Wed, May 9, 2012 at 12:31 AM, Dan Wing wrote: >> >> > Another upcoming change for pcp-base was Pete Resnick's suggestion >> at >> >> IETF83 >> >> > in the PCP meeting (and in the hallways prior to the PCP meeting), >> >> that PCP >> >> > be 'more robust' when the server noticed a mapping needed to be >> >> updated >> >> > (e.g., when the NAT's public IP address changed or when the PCP >> >> server lost >> >> > state). >> >> > >> >> > As background, Rapid Recovery is the ANNOUNCE Opcode (sent when >> the >> >> PCP >> >> > server loses state) and the Mapping Update (the second response in >> >> the >> >> > "request-response-response" model of PCP, where the PCP server >> >> maintains >> >> > state but realizes that the mapping information has changed -- >> such >> >> as a new >> >> > IP address for the mapping). =A0The current specification is lenien= t >> >> regarding >> >> > Rapid Recovery and Mapping Update, describing both as somewhat >> >> optional and >> >> > unnecessary. =A0This is because the PCP philosophy has been that PC= P >> >> should be >> >> > "as good as" sending a TCP SYN. >> >> > >> >> > Pete suggested that PCP can be better, and that PCP should be >> better >> >> -- that >> >> > is, the PCP specification should be changed to say =A0a PCP server >> >> "SHOULD" >> >> > implement Mapping Update (see Section 14.2 in draft-ietf-pcp-base- >> >> 24), and >> >> > that it transmit those Mapping Update packets several times (to >> >> accommodate >> >> > packet loss). =A0Similarly, when sending the ANNOUNCE Opcode, chang= e >> >> from "MAY >> >> > send up to 10 times" to "SHOULD transmit 10 times" (I believe the >> >> other text >> >> > for ANNOUNCE does not need changing). >> >> >> >> Doubt about the necessity of this change, because for some cases, >> for >> >> example, in case of a nested NAT where the middle level NAT acts >> both >> >> as a client and a server, there is a need to implement the PCP >> server >> >> in a light weight, and retransmitting 10 times doesn't look like a >> >> necessity in such a case. So IMO, the word MAY would leave more >> rooms >> >> for implementers' decision case by case. >> > >> > Sorry -- are you saying you agree with the change in general, and >> > would like a lower recommended value than 10? >> >> Yes, I agree the changes in general proposed by Pete are pretty good. >> >> And yes, after comments coming up from Stuart in this thread to vote >> using the wording =A0=91SHOULD=92, for conveying idea of the importance = of >> PCP=92s reliability, which I agree, I vote for lowering recommended time >> below 10. =A0Reasons are below. >> >> 10 would be a good recommended value for recovering from network >> failure, given the typical retransmission times for the sake of >> assuring network reliability. For example, =A0minimal 3 and maximal 15 >> are set as TCP retransmission default values, according to previous >> RFC and work pretty well in most current and wide deployed practice, >> e.g., linux since 2.2. =A0However, PCP server=92s performance limits on >> handling concurrent sessions would be another major cause of >> retransmission. In this case, thousands of clients concurrently >> retransmitting up to 10 after a PCP server has already reached its >> limits would, on the opposite, slow down PCP server=92s rapid recovery. > > The clients will only react once, no matter how often the server > re-transmits is ANNOUNCE message. =A0This is because once a client > receives the first ANNOUNCE, the Epoch Time is "wrong" (too high > or too low) which will cause the client to re-establish its > PCP mappings. =A0However, subsequent retransmissions of ANNOUNCE > will have the expected Epoch Time value, and will not cause a > reaction by the PCP client (that is, the PCP client will not > send new PCP requests because of that ANNOUNCE). > > =A0PCP client =A0 =A0 =A0 =A0 =A0 =A0 =A0 PCP server > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0|-----MAP---------------->| > =A0 =A0 =A0|<-Ok, Epoch=3D123456-------| > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0... > =A0 =A0... (hours later) =A0 =A0 =A0 =A0 =A0... > =A0 =A0... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0... > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (power lost) > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(power restored) > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0|<--ANNOUNCE, Epoch=3D0-----| > =A0 =A0 =A0| =A0 (multicasted) =A0 =A0 =A0 =A0 | > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 (Uh-oh. =A0that PCP =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0server's Epoch is =A0 =A0 =A0 =A0 =A0 | > =A0 =A0wrong. =A0It must =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0have lost state.) =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0|-----MAP---------------->| > =A0 =A0 =A0|<-Ok, Epoch=3D123456-------| > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0|<--ANNOUNCE, Epoch=3D1-----| > =A0 =A0 =A0| =A0 (multicasted) =A0 =A0 =A0 =A0 | > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 (that PCP server's =A0 =A0 =A0 =A0 =A0 | > =A0 =A0Epoch is correct) =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0|<--ANNOUNCE, Epoch=3D2-----| > =A0 =A0 =A0| =A0 (multicasted) =A0 =A0 =A0 =A0 | > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 (that PCP server's =A0 =A0 =A0 =A0 =A0 | > =A0 =A0Epoch is correct) =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0|<--ANNOUNCE, Epoch=3D4-----| > =A0 =A0 =A0| =A0 (multicasted) =A0 =A0 =A0 =A0 | > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 (that PCP server's =A0 =A0 =A0 =A0 =A0 | > =A0 =A0Epoch is correct) =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0... I see.. > >> Therefore, a compromised recommended value, let=92s say 5, taking into >> account these two causes IMO, would do better. > > With the explanation above, do you still want the PCP server to > only send it 5 times? Thanks for the explanation. It certainly eliminates my previous concern of PCP server's handling too many concurrent replies. Then 10 is pretty good recommend value as per reason pointed out previously. > > A problem with sending the unsolicited ANNOUNCE is the PCP server > has no way to determine if all the clients have seen the message. Yes, this adds another point to stick to a fairly high recommend value than a lower one. -Xiaohong Open source mB4 for Multicast DS-Lite: http://sourceforge.net/projects/mb4/ Open source PCP: http://sourceforge.net/projects/pcpclient/ Open source A+P: http://opensourceaplusp.weebly.com/ > > -d > > >> My 5 cent. >> -Xiaohong >> >> Open source mB4 for Multicast DS-Lite: >> http://sourceforge.net/projects/mb4/ >> Open source PCP: http://sourceforge.net/projects/pcpclient/ >> Open source A+P: http://opensourceaplusp.weebly.com/ >> >> > >> > -d >> > >> > >> >> My five cent. >> >> -Xiaohong >> >> >> >> Open source mB4 for Multicast DS-Lite: >> >> http://sourceforge.net/projects/mb4/ >> >> Open source PCP: http://sourceforge.net/projects/pcpclient/ >> >> Open source A+P: http://opensourceaplusp.weebly.com/ >> >> > >> >> > Please let me know if there are objections to this change. >> >> > >> >> > -d >> >> > >> >> > >> >> > _______________________________________________ >> >> > pcp mailing list >> >> > pcp@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/pcp >> >> >> >> >> >> >> >> -- >> > >> >> >> >> -- > -- From dwing@cisco.com Fri May 11 09:02:36 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA62021F85A8 for ; Fri, 11 May 2012 09:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.397 X-Spam-Level: X-Spam-Status: No, score=-110.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EDhNgckee6T for ; Fri, 11 May 2012 09:02:35 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 00CF221F8527 for ; Fri, 11 May 2012 09:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5074; q=dns/txt; s=iport; t=1336752155; x=1337961755; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=k9ViejRW9SCTXoCT3tZSJQRUPV8dPMNnlw/8GZrKoRA=; b=C47WcNeX4KEpH3x4teUjwJ8OKi3ModQ/hVlRYGEWGknacFtlHo6Yx2MW +xFaw4E0Cc3/krxjXbsZgnX02mZkenArkWkIEaUhGFYIXc2e6a0eUZfsP KR9EFGe/zdDlRmqWFgU+svf2e/cF9r2fk4aeSnyIciyuxQvzCArAD5wVB E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAB83rU+rRDoG/2dsb2JhbABEoyuQeoEHghUBAQEDAQEBAQUKARQDRAsNAwIJDgEeGRkOFRsBAQQTCxeHZwQMmwifdYszgk+DMgSIMDSFFokUjUaBaYMJgTYH X-IronPort-AV: E=Sophos;i="4.75,572,1330905600"; d="scan'208";a="41853318" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 11 May 2012 16:02:34 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q4BG2YwG002256; Fri, 11 May 2012 16:02:34 GMT From: "Dan Wing" To: "'Xiaohong Deng'" References: <02e601cd2d38$11a50ba0$34ef22e0$@com> <067501cd2df6$f54a62b0$dfdf2810$@com> <09a701cd2ebd$8f9166e0$aeb434a0$@com> In-Reply-To: Date: Fri, 11 May 2012 09:02:34 -0700 Message-ID: <0e4a01cd2f8f$7a8fb6c0$6faf2440$@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: Ac0vQowx5GhTjui0Sb2f4aoV8xscwQAS/ZSw Content-Language: en-us Cc: pcp@ietf.org, draft-ietf-pcp-base@tools.ietf.org Subject: Re: [pcp] PCP robustness for Rapid Recovery X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 16:02:36 -0000 ... > > The clients will only react once, no matter how often the server > > re-transmits is ANNOUNCE message. =A0This is because once a client > > receives the first ANNOUNCE, the Epoch Time is "wrong" (too high > > or too low) which will cause the client to re-establish its > > PCP mappings. =A0However, subsequent retransmissions of ANNOUNCE > > will have the expected Epoch Time value, and will not cause a > > reaction by the PCP client (that is, the PCP client will not > > send new PCP requests because of that ANNOUNCE). > > > > =A0PCP client =A0 =A0 =A0 =A0 =A0 =A0 =A0 PCP server > > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > =A0 =A0 =A0|-----MAP---------------->| > > =A0 =A0 =A0|<-Ok, Epoch=3D123456-------| > > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > =A0 =A0... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0... > > =A0 =A0... (hours later) =A0 =A0 =A0 =A0 =A0... > > =A0 =A0... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0... > > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (power lost) > > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(power restored) > > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > =A0 =A0 =A0|<--ANNOUNCE, Epoch=3D0-----| > > =A0 =A0 =A0| =A0 (multicasted) =A0 =A0 =A0 =A0 | > > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > =A0 (Uh-oh. =A0that PCP =A0 =A0 =A0 =A0 =A0 =A0| > > =A0 =A0server's Epoch is =A0 =A0 =A0 =A0 =A0 | > > =A0 =A0wrong. =A0It must =A0 =A0 =A0 =A0 =A0 =A0 | > > =A0 =A0have lost state.) =A0 =A0 =A0 =A0 =A0 | > > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > =A0 =A0 =A0|-----MAP---------------->| > > =A0 =A0 =A0|<-Ok, Epoch=3D123456-------| > > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > =A0 =A0 =A0|<--ANNOUNCE, Epoch=3D1-----| > > =A0 =A0 =A0| =A0 (multicasted) =A0 =A0 =A0 =A0 | > > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > =A0 (that PCP server's =A0 =A0 =A0 =A0 =A0 | > > =A0 =A0Epoch is correct) =A0 =A0 =A0 =A0 =A0 | > > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > =A0 =A0 =A0|<--ANNOUNCE, Epoch=3D2-----| > > =A0 =A0 =A0| =A0 (multicasted) =A0 =A0 =A0 =A0 | > > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > =A0 (that PCP server's =A0 =A0 =A0 =A0 =A0 | > > =A0 =A0Epoch is correct) =A0 =A0 =A0 =A0 =A0 | > > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > =A0 =A0 =A0|<--ANNOUNCE, Epoch=3D4-----| > > =A0 =A0 =A0| =A0 (multicasted) =A0 =A0 =A0 =A0 | > > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > =A0 (that PCP server's =A0 =A0 =A0 =A0 =A0 | > > =A0 =A0Epoch is correct) =A0 =A0 =A0 =A0 =A0 | > > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > =A0 =A0... >=20 > I see.. To make that clearer, -25 includes the additional sentence If the Epoch time value is within the expect range for that=20 server, the PCP client does not recreate its mappings. > >> Therefore, a compromised recommended value, let=92s say 5, taking = into > >> account these two causes IMO, would do better. > > > > With the explanation above, do you still want the PCP server to > > only send it 5 times? >=20 > Thanks for the explanation. It certainly eliminates my previous > concern of PCP server's handling too many concurrent replies. Then 10 > is pretty good recommend value as per reason pointed out previously. Ok. -d > > A problem with sending the unsolicited ANNOUNCE is the PCP server > > has no way to determine if all the clients have seen the message. >=20 > Yes, this adds another point to stick to a fairly high recommend value > than a lower one. >=20 > -Xiaohong >=20 > Open source mB4 for Multicast DS-Lite: > http://sourceforge.net/projects/mb4/ > Open source PCP: http://sourceforge.net/projects/pcpclient/ > Open source A+P: http://opensourceaplusp.weebly.com/ >=20 >=20 > > > > -d > > > > > >> My 5 cent. > >> -Xiaohong > >> > >> Open source mB4 for Multicast DS-Lite: > >> http://sourceforge.net/projects/mb4/ > >> Open source PCP: http://sourceforge.net/projects/pcpclient/ > >> Open source A+P: http://opensourceaplusp.weebly.com/ > >> > >> > > >> > -d > >> > > >> > > >> >> My five cent. > >> >> -Xiaohong > >> >> > >> >> Open source mB4 for Multicast DS-Lite: > >> >> http://sourceforge.net/projects/mb4/ > >> >> Open source PCP: http://sourceforge.net/projects/pcpclient/ > >> >> Open source A+P: http://opensourceaplusp.weebly.com/ > >> >> > > >> >> > Please let me know if there are objections to this change. > >> >> > > >> >> > -d > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > pcp mailing list > >> >> > pcp@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/pcp > >> >> > >> >> > >> >> > >> >> -- > >> > > >> > >> > >> > >> -- > > >=20 >=20 >=20 > -- From dxhbupt@gmail.com Sat May 12 21:02:53 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B11E21F8513 for ; Sat, 12 May 2012 21:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzUgabQQhPCn for ; Sat, 12 May 2012 21:02:53 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E89F21F850F for ; Sat, 12 May 2012 21:02:52 -0700 (PDT) Received: by werf13 with SMTP id f13so2283967wer.31 for ; Sat, 12 May 2012 21:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=sXsQ67p0sWLR42OT+UBK9me/TIUFTkvRqxBprOSiRpA=; b=L0kzibLbvBw1rgGgKJySdX534UJOtIiGhZzgq4l0AMepqatYHaEoKTHwevV84T0bin qHWrF3JVQ5MXqdO0YsediJhGGs4fxC0ezI9B+vx7p7N4/JeZ6lnBqO1ptso14OxHN4RH nrp9HzUAufoI3eu5nqIA0ihEpCcOt0t2al6ybAcNJlALhT4iDJ92R8tZUQYeZA0561Gj PIKMfEIB38o+cogoo5hF/n1nTEILkul7Cgj7dm3BFI+OUvQBRWa2cVGD9FlIHLcSK7Av lkGWlSqmptASmkRXrbnAlTU1NrEQcErrIAiEJ5FNGowVmE+kLGh1DReFTtgYoExaj3lO N8yg== MIME-Version: 1.0 Received: by 10.216.140.218 with SMTP id e68mr2251238wej.11.1336881771530; Sat, 12 May 2012 21:02:51 -0700 (PDT) Received: by 10.180.85.105 with HTTP; Sat, 12 May 2012 21:02:51 -0700 (PDT) In-Reply-To: <0e4a01cd2f8f$7a8fb6c0$6faf2440$@com> References: <02e601cd2d38$11a50ba0$34ef22e0$@com> <067501cd2df6$f54a62b0$dfdf2810$@com> <09a701cd2ebd$8f9166e0$aeb434a0$@com> <0e4a01cd2f8f$7a8fb6c0$6faf2440$@com> Date: Sun, 13 May 2012 12:02:51 +0800 Message-ID: From: Xiaohong Deng To: Dan Wing Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: pcp@ietf.org, draft-ietf-pcp-base@tools.ietf.org Subject: Re: [pcp] PCP robustness for Rapid Recovery X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 04:02:53 -0000 On Sat, May 12, 2012 at 12:02 AM, Dan Wing wrote: > ... >> > The clients will only react once, no matter how often the server >> > re-transmits is ANNOUNCE message. =A0This is because once a client >> > receives the first ANNOUNCE, the Epoch Time is "wrong" (too high >> > or too low) which will cause the client to re-establish its >> > PCP mappings. =A0However, subsequent retransmissions of ANNOUNCE >> > will have the expected Epoch Time value, and will not cause a >> > reaction by the PCP client (that is, the PCP client will not >> > send new PCP requests because of that ANNOUNCE). >> > >> > =A0PCP client =A0 =A0 =A0 =A0 =A0 =A0 =A0 PCP server >> > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0 =A0|-----MAP---------------->| >> > =A0 =A0 =A0|<-Ok, Epoch=3D123456-------| >> > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0... >> > =A0 =A0... (hours later) =A0 =A0 =A0 =A0 =A0... >> > =A0 =A0... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0... >> > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (power lost) >> > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(power restored) >> > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0 =A0|<--ANNOUNCE, Epoch=3D0-----| >> > =A0 =A0 =A0| =A0 (multicasted) =A0 =A0 =A0 =A0 | >> > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> > =A0 (Uh-oh. =A0that PCP =A0 =A0 =A0 =A0 =A0 =A0| >> > =A0 =A0server's Epoch is =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0wrong. =A0It must =A0 =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0have lost state.) =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0 =A0|-----MAP---------------->| >> > =A0 =A0 =A0|<-Ok, Epoch=3D123456-------| >> > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0 =A0|<--ANNOUNCE, Epoch=3D1-----| >> > =A0 =A0 =A0| =A0 (multicasted) =A0 =A0 =A0 =A0 | >> > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> > =A0 (that PCP server's =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0Epoch is correct) =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0 =A0|<--ANNOUNCE, Epoch=3D2-----| >> > =A0 =A0 =A0| =A0 (multicasted) =A0 =A0 =A0 =A0 | >> > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> > =A0 (that PCP server's =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0Epoch is correct) =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0 =A0|<--ANNOUNCE, Epoch=3D4-----| >> > =A0 =A0 =A0| =A0 (multicasted) =A0 =A0 =A0 =A0 | >> > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> > =A0 (that PCP server's =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0Epoch is correct) =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> > =A0 =A0... >> >> I see.. > > To make that clearer, -25 includes the additional sentence > > =A0 If the Epoch time value is within the expect range for that > =A0 server, the PCP client does not recreate its mappings. Perfect. Thanks. -Xiaohong Open source mB4 for Multicast DS-Lite: http://sourceforge.net/projects/mb4/ Open source PCP: http://sourceforge.net/projects/pcpclient/ Open source A+P: http://opensourceaplusp.weebly.com/ > >> >> Therefore, a compromised recommended value, let=92s say 5, taking int= o >> >> account these two causes IMO, would do better. >> > >> > With the explanation above, do you still want the PCP server to >> > only send it 5 times? >> >> Thanks for the explanation. It certainly eliminates my previous >> concern of PCP server's handling too many concurrent replies. Then 10 >> is pretty good recommend value as per reason pointed out previously. > > Ok. > > -d > >> > A problem with sending the unsolicited ANNOUNCE is the PCP server >> > has no way to determine if all the clients have seen the message. >> >> Yes, this adds another point to stick to a fairly high recommend value >> than a lower one. >> >> -Xiaohong >> >> Open source mB4 for Multicast DS-Lite: >> http://sourceforge.net/projects/mb4/ >> Open source PCP: http://sourceforge.net/projects/pcpclient/ >> Open source A+P: http://opensourceaplusp.weebly.com/ >> >> >> > >> > -d >> > >> > >> >> My 5 cent. >> >> -Xiaohong >> >> >> >> Open source mB4 for Multicast DS-Lite: >> >> http://sourceforge.net/projects/mb4/ >> >> Open source PCP: http://sourceforge.net/projects/pcpclient/ >> >> Open source A+P: http://opensourceaplusp.weebly.com/ >> >> >> >> > >> >> > -d >> >> > >> >> > >> >> >> My five cent. >> >> >> -Xiaohong >> >> >> >> >> >> Open source mB4 for Multicast DS-Lite: >> >> >> http://sourceforge.net/projects/mb4/ >> >> >> Open source PCP: http://sourceforge.net/projects/pcpclient/ >> >> >> Open source A+P: http://opensourceaplusp.weebly.com/ >> >> >> > >> >> >> > Please let me know if there are objections to this change. >> >> >> > >> >> >> > -d >> >> >> > >> >> >> > >> >> >> > _______________________________________________ >> >> >> > pcp mailing list >> >> >> > pcp@ietf.org >> >> >> > https://www.ietf.org/mailman/listinfo/pcp >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> > >> >> >> >> >> >> >> >> -- >> > >> >> >> >> -- > From internet-drafts@ietf.org Mon May 21 10:58:52 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F143E21F85F2; Mon, 21 May 2012 10:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Woam528b-ZhR; Mon, 21 May 2012 10:58:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB1E21F859E; Mon, 21 May 2012 10:58:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120521175851.26096.98288.idtracker@ietfa.amsl.com> Date: Mon, 21 May 2012 10:58:51 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-base-25.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 17:58:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Port Control Protocol Working Group o= f the IETF. Title : Port Control Protocol (PCP) Author(s) : Dan Wing Stuart Cheshire Mohamed Boucadair Reinaldo Penno Paul Selkirk Filename : draft-ietf-pcp-base-25.txt Pages : 100 Date : 2012-05-21 The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-25.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcp-base-25.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-base/ From dwing@cisco.com Mon May 21 11:04:42 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5271321F8611 for ; Mon, 21 May 2012 11:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEgO+yYfTpjA for ; Mon, 21 May 2012 11:04:41 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id AD1AB21F85FF for ; Mon, 21 May 2012 11:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2303; q=dns/txt; s=iport; t=1337623481; x=1338833081; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=KbysAWyklc/qVMj+HTlER+TdZ/qzGDO+DbyAs52mruo=; b=LBef+KrSco0CDQ+BSbvAOONaz9BQIkGInySP0QZYSooOdIFCySjNqdbR BWmfv0AzU3ckUeuhs93S35NxR8zgNS71jFK+/eKEQWjpqYbdXacAJw+m/ cRi+NxpNY53nF8THSRwBLXO543n3rTJ+4r8Oa1iGmrRB3zXBu3pcC1rT/ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FANyCuk+rRDoH/2dsb2JhbABEo2aQNIEHghwICgEXED8NBRhQIxwBBB4Xh2sMnyKfdo0jgx4DiEKEfIhsjH2BZIMJgTYH X-IronPort-AV: E=Sophos;i="4.75,632,1330905600"; d="scan'208";a="45744583" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 21 May 2012 18:04:41 +0000 Received: from dwingWS (sjc-vpn7-267.cisco.com [10.21.145.11]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4LI4f0Z029913; Mon, 21 May 2012 18:04:41 GMT From: "Dan Wing" To: Date: Mon, 21 May 2012 11:04:40 -0700 Message-ID: <02b301cd377c$31925b40$94b711c0$@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: Ac03e3YF3IFRrRIGRtiS6WBVqCoxMQ== Content-Language: en-us Cc: draft-ietf-pcp-base@tools.ietf.org Subject: [pcp] pcp-base-25 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 18:04:42 -0000 draft-ietf-pcp-base-25 was just submitted. The major changes to the document are introduction of Mapping Nonce to MAP and PEER opcodes, which protects against spoofing of the PCP server, and the restriction of the THIRD_PARTY option to networks with ACLs that prevent spoofing of the PCP client. Other changes are summarized in the changes section, which is copied below for convenience. Version -25 is available at http://tools.ietf.org/html/draft-ietf-pcp-base-25 And side-by-side diffs between -24 and -25 are at http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-25.txt If you have feedback, please change the Subject line to something meaningful. -d ----- o Clarified the port used by the PCP server when sending unsolicited unicast ANNOUNCE. o Removed parenthetical comment implying ANNOUNCE was not a normal Opcode; it is a normal Opcode. o Explain that non-PCP-speaking host-based and network-based firewalls need to allow incoming connections for MAP to work. o For race condition with PREFER_FAILURE, clarified that it is the PCP client's responsibility to delete the mapping if the PCP client doesn't need the mapping. o For table, the NAT64 remote peer is IPv4 (was IPv6). o Added a Mapping Nonce field to both MAP and PEER requests and responses, to protect from off-path attackers spoofing the PCP server's IP address. o Security considerations: added 'PCP is secure against off-path attackers who can spoof the PCP server's IP address', because of the addition of the Mapping Nonce. o Removed reference to DS-Lite from Security Considerations, as part of the changes to THIRD_PARTY from IESG review. o Rapid Recovery is now a SHOULD implement. o Clarify behavior of PREFER_FAILURE with zeros in Suggested External Port or Address fields. o PCP server is now more robust and insistent about informing PCP client of state changes. o When PCP server sends Mapping Update to a specific PCP client, and gets an update for a particular mapping, it doesn't need to send reminders about that mapping any more. o THIRD_PARTY is now prohibited on subscriber PCP clients. From wim.henderickx@alcatel-lucent.com Fri May 25 05:32:47 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8404D21F85BD for ; Fri, 25 May 2012 05:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.582 X-Spam-Level: X-Spam-Status: No, score=-9.582 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W2OL2sZHNeg for ; Fri, 25 May 2012 05:32:46 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEB721F85A3 for ; Fri, 25 May 2012 05:32:46 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q4PCTAc8010234 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 25 May 2012 14:32:42 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 25 May 2012 14:32:08 +0200 From: "Henderickx, Wim (Wim)" To: Dan Wing , "pcp@ietf.org" Date: Fri, 25 May 2012 14:32:42 +0200 Thread-Topic: [pcp] pcp-base-25 Thread-Index: Ac03e3YF3IFRrRIGRtiS6WBVqCoxMQC9m5vw Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702DF450809@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <02b301cd377c$31925b40$94b711c0$@com> In-Reply-To: <02b301cd377c$31925b40$94b711c0$@com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "draft-ietf-pcp-base@tools.ietf.org" Subject: Re: [pcp] pcp-base-25 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 12:32:47 -0000 Dan, Can we not add the Nonce in an option iso in the MAP/PEER messages? This wi= ll provide easier backward compatibility with existing implementations. Cheers, Wim -----Original Message----- From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dan W= ing Sent: maandag 21 mei 2012 20:05 To: pcp@ietf.org Cc: draft-ietf-pcp-base@tools.ietf.org Subject: [pcp] pcp-base-25 draft-ietf-pcp-base-25 was just submitted. The major changes to the document are introduction of Mapping Nonce to MAP and PEER opcodes, which protects=20 against spoofing of the PCP server, and the restriction of the THIRD_PARTY= =20 option to networks with ACLs that prevent spoofing of the PCP client. Other changes are summarized in the changes section, which is copied below for convenience. Version -25 is available at http://tools.ietf.org/html/draft-ietf-pcp-base-25 And side-by-side diffs between -24 and -25 are at http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-base-25.txt If you have feedback, please change the Subject line to something meaningful. -d ----- o Clarified the port used by the PCP server when sending unsolicited unicast ANNOUNCE. o Removed parenthetical comment implying ANNOUNCE was not a normal Opcode; it is a normal Opcode. o Explain that non-PCP-speaking host-based and network-based firewalls need to allow incoming connections for MAP to work. o For race condition with PREFER_FAILURE, clarified that it is the PCP client's responsibility to delete the mapping if the PCP client doesn't need the mapping. o For table, the NAT64 remote peer is IPv4 (was IPv6). o Added a Mapping Nonce field to both MAP and PEER requests and responses, to protect from off-path attackers spoofing the PCP server's IP address. o Security considerations: added 'PCP is secure against off-path attackers who can spoof the PCP server's IP address', because of the addition of the Mapping Nonce. o Removed reference to DS-Lite from Security Considerations, as part of the changes to THIRD_PARTY from IESG review. o Rapid Recovery is now a SHOULD implement. o Clarify behavior of PREFER_FAILURE with zeros in Suggested External Port or Address fields. o PCP server is now more robust and insistent about informing PCP client of state changes. o When PCP server sends Mapping Update to a specific PCP client, and gets an update for a particular mapping, it doesn't need to send reminders about that mapping any more. o THIRD_PARTY is now prohibited on subscriber PCP clients. _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp From dwing@cisco.com Fri May 25 08:25:05 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3525421F85DD for ; Fri, 25 May 2012 08:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TAfszeZEMcL for ; Fri, 25 May 2012 08:25:04 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6906021F85D9 for ; Fri, 25 May 2012 08:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4732; q=dns/txt; s=iport; t=1337959504; x=1339169104; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=92h3/YHAdsICce4TeRH4O6Zd/rdoZilmxbxobNqSFMI=; b=ABJQMwicYXLnMZwNX7imeqwVUdnwzWOZalCRmsb9WDjbHiucA2EzBBCS vAvVMS3QHPrWPAcmCeh/+xpiTRe73jdJB5kLrZgM/jKQpr7j9aPdPG3uQ RPBvNewEHILKIOppQTBg80oVie/JEinZdWDZyeUKh1EeHOKNGv4EwUDRk M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAOijv0+rRDoH/2dsb2JhbABEpFyQNYEHghUBAQEDAQEBAQUKARcQNAsFBwEDAgkPAgQBASgHGQ4VCgkIAQEEARILF4dmBAybSJ9ZiwGFRgOIP4R8iGyMfYFkgwCBNgc X-IronPort-AV: E=Sophos;i="4.75,656,1330905600"; d="scan'208";a="43816369" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 25 May 2012 15:25:04 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4PFP3GP029445; Fri, 25 May 2012 15:25:03 GMT From: "Dan Wing" To: "'Henderickx, Wim \(Wim\)'" , References: <02b301cd377c$31925b40$94b711c0$@com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF450809@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702DF450809@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Date: Fri, 25 May 2012 08:25:04 -0700 Message-ID: <03ec01cd3a8a$8f06fc70$ad14f550$@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: Ac03e3YF3IFRrRIGRtiS6WBVqCoxMQC9m5vwAAWByeA= Content-Language: en-us Cc: draft-ietf-pcp-base@tools.ietf.org Subject: Re: [pcp] pcp-base-25 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 15:25:05 -0000 > -----Original Message----- > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] > Sent: Friday, May 25, 2012 5:33 AM > To: Dan Wing; pcp@ietf.org > Cc: draft-ietf-pcp-base@tools.ietf.org > Subject: RE: [pcp] pcp-base-25 > > Dan, > > Can we not add the Nonce in an option iso in the MAP/PEER messages? > This will provide easier backward compatibility with existing > implementations. It's mandatory in order to make it difficult for an off-path attacker to spoof the PCP server. If it's optional in the specification, it will be optional in implementations -- weakening the protocol (bad) and adding permanent, long-term interop complexity (bad). I do understand there are pre-RFC implementations in the field, and I believe they can be accommodated by a PCP server that understands both -24 and -25. A PCP server, which supports -24 and -25, can differentiate a PCP request as being from a -24 or -25 PCP client by using a heuristic. The heuristic examines bits 192-224 of the MAP opcode request. In -24, those bits are the protocol number and 24 reserved bits which must be 0. In -25, those bits are the first 32 bits of the Mapping Nonce. A -24 client, supporting only TCP and UDP (which I am sure is all that are supported today), will always set those bits to three different values, 0000011000000000000000000000 = protocol=6=TCP 0010001000000000000000000000 = protocol=17=UDP 0000000000000000000000000000 = protocol=wildcard any other values in that 32 bit field means it's from a -25 PCP client, because bits 192-224 are the first 32 bits of the Mapping Nonce, which is a random value. This heuristic will fail if the PCP client happens to choose a random value where the first 32 bits are those three values above. A similar heuristic can be used for the PEER opcode. -d > Cheers, > Wim > > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Dan Wing > Sent: maandag 21 mei 2012 20:05 > To: pcp@ietf.org > Cc: draft-ietf-pcp-base@tools.ietf.org > Subject: [pcp] pcp-base-25 > > draft-ietf-pcp-base-25 was just submitted. The major changes to the > document > are introduction of Mapping Nonce to MAP and PEER opcodes, which > protects > against spoofing of the PCP server, and the restriction of the > THIRD_PARTY > option to networks with ACLs that prevent spoofing of the PCP client. > > Other changes are summarized in the changes section, which is copied > below > for convenience. > > Version -25 is available at > http://tools.ietf.org/html/draft-ietf-pcp-base-25 > > And side-by-side diffs between -24 and -25 are at > http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-25.txt > > > If you have feedback, please change the Subject line to something > meaningful. > > -d > > ----- > > > o Clarified the port used by the PCP server when sending > unsolicited > unicast ANNOUNCE. > > o Removed parenthetical comment implying ANNOUNCE was not a normal > Opcode; it is a normal Opcode. > > o Explain that non-PCP-speaking host-based and network-based > firewalls need to allow incoming connections for MAP to work. > > o For race condition with PREFER_FAILURE, clarified that it is the > PCP client's responsibility to delete the mapping if the PCP > client doesn't need the mapping. > > o For table, the NAT64 remote peer is IPv4 (was IPv6). > > o Added a Mapping Nonce field to both MAP and PEER requests and > responses, to protect from off-path attackers spoofing the PCP > server's IP address. > > o Security considerations: added 'PCP is secure against off-path > attackers who can spoof the PCP server's IP address', because of > the addition of the Mapping Nonce. > > o Removed reference to DS-Lite from Security Considerations, as > part > of the changes to THIRD_PARTY from IESG review. > > o Rapid Recovery is now a SHOULD implement. > > o Clarify behavior of PREFER_FAILURE with zeros in Suggested > External Port or Address fields. > > o PCP server is now more robust and insistent about informing PCP > client of state changes. > > o When PCP server sends Mapping Update to a specific PCP client, > and > gets an update for a particular mapping, it doesn't need to send > reminders about that mapping any more. > > o THIRD_PARTY is now prohibited on subscriber PCP clients. > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From wim.henderickx@alcatel-lucent.com Fri May 25 12:16:38 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4461E21F8782 for ; Fri, 25 May 2012 12:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXE41e9N-74T for ; Fri, 25 May 2012 12:16:37 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 45AC221F877D for ; Fri, 25 May 2012 12:16:37 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q4PJGUdU005025 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 25 May 2012 21:16:33 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 25 May 2012 21:16:31 +0200 From: "Henderickx, Wim (Wim)" To: Dan Wing , "pcp@ietf.org" Date: Fri, 25 May 2012 21:15:38 +0200 Thread-Topic: [pcp] pcp-base-25 Thread-Index: Ac03e3YF3IFRrRIGRtiS6WBVqCoxMQC9m5vwAAWByeAACJGDAA== Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702DF450943@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <02b301cd377c$31925b40$94b711c0$@com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF450809@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <03ec01cd3a8a$8f06fc70$ad14f550$@com> In-Reply-To: <03ec01cd3a8a$8f06fc70$ad14f550$@com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "draft-ietf-pcp-base@tools.ietf.org" Subject: Re: [pcp] pcp-base-25 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 19:16:38 -0000 Dan, if a PCP-25 client is using a nonce which has these 192-224 bits set a= s one of those heuristic values the PCP-24 server would interpret the packe= t wrongly. The option is much better for backward compatibility and lets make it manda= tory to ensure it is included in the MAP/PEER opcodes -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: vrijdag 25 mei 2012 17:25 To: Henderickx, Wim (Wim); pcp@ietf.org Cc: draft-ietf-pcp-base@tools.ietf.org Subject: RE: [pcp] pcp-base-25 > -----Original Message----- > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] > Sent: Friday, May 25, 2012 5:33 AM > To: Dan Wing; pcp@ietf.org > Cc: draft-ietf-pcp-base@tools.ietf.org > Subject: RE: [pcp] pcp-base-25 >=20 > Dan, >=20 > Can we not add the Nonce in an option iso in the MAP/PEER messages? > This will provide easier backward compatibility with existing > implementations. It's mandatory in order to make it difficult for an off-path attacker to spoof the PCP server. If it's optional in the specification, it will be optional in implementations -- weakening the protocol (bad) and adding permanent, long-term interop complexity (bad). I do understand there are pre-RFC implementations in the field, and I believe they can be accommodated by a PCP server that understands both -24 and -25. A PCP server, which supports -24 and -25, can differentiate a PCP request as being from a -24 or -25 PCP client by using a heuristic. The heuristic examines bits 192-224 of the MAP opcode request. In=20 -24, those bits are the protocol number and 24 reserved bits which=20 must be 0. In -25, those bits are the first 32 bits of the Mapping=20 Nonce. A -24 client, supporting only TCP and UDP (which I am sure is all that are supported today), will always set those bits to three different values, 0000011000000000000000000000 =3D protocol=3D6=3DTCP 0010001000000000000000000000 =3D protocol=3D17=3DUDP 0000000000000000000000000000 =3D protocol=3Dwildcard any other values in that 32 bit field means it's from a -25 PCP client, because bits 192-224 are the first 32 bits of the Mapping Nonce, which is a random value. This heuristic will fail if the PCP client happens to choose a random value where the first 32 bits are those three values above. A similar heuristic can be used for the PEER opcode. -d > Cheers, > Wim >=20 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Dan Wing > Sent: maandag 21 mei 2012 20:05 > To: pcp@ietf.org > Cc: draft-ietf-pcp-base@tools.ietf.org > Subject: [pcp] pcp-base-25 >=20 > draft-ietf-pcp-base-25 was just submitted. The major changes to the > document > are introduction of Mapping Nonce to MAP and PEER opcodes, which > protects > against spoofing of the PCP server, and the restriction of the > THIRD_PARTY > option to networks with ACLs that prevent spoofing of the PCP client. >=20 > Other changes are summarized in the changes section, which is copied > below > for convenience. >=20 > Version -25 is available at > http://tools.ietf.org/html/draft-ietf-pcp-base-25 >=20 > And side-by-side diffs between -24 and -25 are at > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-base-25.txt >=20 >=20 > If you have feedback, please change the Subject line to something > meaningful. >=20 > -d >=20 > ----- >=20 >=20 > o Clarified the port used by the PCP server when sending > unsolicited > unicast ANNOUNCE. >=20 > o Removed parenthetical comment implying ANNOUNCE was not a normal > Opcode; it is a normal Opcode. >=20 > o Explain that non-PCP-speaking host-based and network-based > firewalls need to allow incoming connections for MAP to work. >=20 > o For race condition with PREFER_FAILURE, clarified that it is the > PCP client's responsibility to delete the mapping if the PCP > client doesn't need the mapping. >=20 > o For table, the NAT64 remote peer is IPv4 (was IPv6). >=20 > o Added a Mapping Nonce field to both MAP and PEER requests and > responses, to protect from off-path attackers spoofing the PCP > server's IP address. >=20 > o Security considerations: added 'PCP is secure against off-path > attackers who can spoof the PCP server's IP address', because of > the addition of the Mapping Nonce. >=20 > o Removed reference to DS-Lite from Security Considerations, as > part > of the changes to THIRD_PARTY from IESG review. >=20 > o Rapid Recovery is now a SHOULD implement. >=20 > o Clarify behavior of PREFER_FAILURE with zeros in Suggested > External Port or Address fields. >=20 > o PCP server is now more robust and insistent about informing PCP > client of state changes. >=20 > o When PCP server sends Mapping Update to a specific PCP client, > and > gets an update for a particular mapping, it doesn't need to send > reminders about that mapping any more. >=20 > o THIRD_PARTY is now prohibited on subscriber PCP clients. >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From dwing@cisco.com Fri May 25 13:02:44 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7083C21F87BC for ; Fri, 25 May 2012 13:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEEK5ttg-OQR for ; Fri, 25 May 2012 13:02:43 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 332C521F8721 for ; Fri, 25 May 2012 13:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=6545; q=dns/txt; s=iport; t=1337976163; x=1339185763; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=1eufEgsllveJmSd3QbiJT2HaxMz2wXIrlAVTqlauzQU=; b=EAxYIIwHOJL68NBiv5K+5lWCDJAm0lzNxGw2ptiazYWrsBhfbCbkJRCr c4sE1bHOCtnEKAnlrYRvMnzfINNEMf2kJiO/CWcMoudH5j4TR2slw2IXz 0DmeMBIkVbcP48NA9WHc1/Oi55q1xjqTeZhrNGV4hG6WI6poWtrUnDYia 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAAXlv0+rRDoG/2dsb2JhbABEpGGQNYEHghUBAQEDAQEBAQUKARcQNAsFBwEDAgkPAgQBASgHGQ4VCgkIAQEEARILF4dmBAyYdp9RiwGFRgOIP4R8iGyMfYFkgwCBNgcZ X-IronPort-AV: E=Sophos;i="4.75,658,1330905600"; d="scan'208";a="46437029" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 25 May 2012 20:02:43 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4PK2gQr032384; Fri, 25 May 2012 20:02:42 GMT From: "Dan Wing" To: "'Henderickx, Wim \(Wim\)'" , References: <02b301cd377c$31925b40$94b711c0$@com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF450809@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <03ec01cd3a8a$8f06fc70$ad14f550$@com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF450943@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702DF450943@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Date: Fri, 25 May 2012 13:02:42 -0700 Message-ID: <056901cd3ab1$58393920$08abab60$@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: Ac03e3YF3IFRrRIGRtiS6WBVqCoxMQC9m5vwAAWByeAACJGDAAABflBw Content-Language: en-us Cc: draft-ietf-pcp-base@tools.ietf.org Subject: Re: [pcp] pcp-base-25 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 20:02:44 -0000 > -----Original Message----- > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] > Sent: Friday, May 25, 2012 12:16 PM > To: Dan Wing; pcp@ietf.org > Cc: draft-ietf-pcp-base@tools.ietf.org > Subject: RE: [pcp] pcp-base-25 > > Dan, if a PCP-25 client is using a nonce which has these 192-224 bits > set as one of those heuristic values the PCP-24 server would interpret > the packet wrongly. Yes, that is what I meant when I wrote "This heuristic will fail if the PCP client happens to choose a random value where the first 32 bits are those three values above." I am sure there are additional heuristics that can improve the detection, such as packet length, looking for a legal Option code value where it's expected for -24, or -- if these pcp-base-24 clients are IPv4 clients -- looking for their 96 bit ::FFFF pattern in the Suggested External IP Address field. > The option is much better for backward compatibility and lets make it > mandatory to ensure it is included in the MAP/PEER opcodes I am hard pressed to provide backward compatibility with pre-RFC implementations, especially by making a security mechanism optional to accommodate those pre-RFC implementations. This would create permanent harm to PCP, whereas pre-25 versions are temporary. -d > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: vrijdag 25 mei 2012 17:25 > To: Henderickx, Wim (Wim); pcp@ietf.org > Cc: draft-ietf-pcp-base@tools.ietf.org > Subject: RE: [pcp] pcp-base-25 > > > -----Original Message----- > > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > lucent.com] > > Sent: Friday, May 25, 2012 5:33 AM > > To: Dan Wing; pcp@ietf.org > > Cc: draft-ietf-pcp-base@tools.ietf.org > > Subject: RE: [pcp] pcp-base-25 > > > > Dan, > > > > Can we not add the Nonce in an option iso in the MAP/PEER messages? > > This will provide easier backward compatibility with existing > > implementations. > > It's mandatory in order to make it difficult for an off-path attacker > to spoof the PCP server. If it's optional in the specification, it > will be optional in implementations -- weakening the protocol (bad) > and adding permanent, long-term interop complexity (bad). > > > I do understand there are pre-RFC implementations in the field, and > I believe they can be accommodated by a PCP server that understands > both -24 and -25. > > A PCP server, which supports -24 and -25, can differentiate a PCP > request as being from a -24 or -25 PCP client by using a heuristic. > The heuristic examines bits 192-224 of the MAP opcode request. In > -24, those bits are the protocol number and 24 reserved bits which > must be 0. In -25, those bits are the first 32 bits of the Mapping > Nonce. > > A -24 client, supporting only TCP and UDP (which I am sure is all > that are supported today), will always set those bits to three > different values, > > 0000011000000000000000000000 = protocol=6=TCP > 0010001000000000000000000000 = protocol=17=UDP > 0000000000000000000000000000 = protocol=wildcard > > any other values in that 32 bit field means it's from a -25 PCP > client, because bits 192-224 are the first 32 bits of the Mapping > Nonce, which is a random value. This heuristic will fail if the PCP > client happens to choose a random value where the first 32 bits are > those three values above. > > A similar heuristic can be used for the PEER opcode. > > -d > > > > Cheers, > > Wim > > > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > > Dan Wing > > Sent: maandag 21 mei 2012 20:05 > > To: pcp@ietf.org > > Cc: draft-ietf-pcp-base@tools.ietf.org > > Subject: [pcp] pcp-base-25 > > > > draft-ietf-pcp-base-25 was just submitted. The major changes to the > > document > > are introduction of Mapping Nonce to MAP and PEER opcodes, which > > protects > > against spoofing of the PCP server, and the restriction of the > > THIRD_PARTY > > option to networks with ACLs that prevent spoofing of the PCP client. > > > > Other changes are summarized in the changes section, which is copied > > below > > for convenience. > > > > Version -25 is available at > > http://tools.ietf.org/html/draft-ietf-pcp-base-25 > > > > And side-by-side diffs between -24 and -25 are at > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-25.txt > > > > > > If you have feedback, please change the Subject line to something > > meaningful. > > > > -d > > > > ----- > > > > > > o Clarified the port used by the PCP server when sending > > unsolicited > > unicast ANNOUNCE. > > > > o Removed parenthetical comment implying ANNOUNCE was not a > normal > > Opcode; it is a normal Opcode. > > > > o Explain that non-PCP-speaking host-based and network-based > > firewalls need to allow incoming connections for MAP to work. > > > > o For race condition with PREFER_FAILURE, clarified that it is > the > > PCP client's responsibility to delete the mapping if the PCP > > client doesn't need the mapping. > > > > o For table, the NAT64 remote peer is IPv4 (was IPv6). > > > > o Added a Mapping Nonce field to both MAP and PEER requests and > > responses, to protect from off-path attackers spoofing the PCP > > server's IP address. > > > > o Security considerations: added 'PCP is secure against off-path > > attackers who can spoof the PCP server's IP address', because > of > > the addition of the Mapping Nonce. > > > > o Removed reference to DS-Lite from Security Considerations, as > > part > > of the changes to THIRD_PARTY from IESG review. > > > > o Rapid Recovery is now a SHOULD implement. > > > > o Clarify behavior of PREFER_FAILURE with zeros in Suggested > > External Port or Address fields. > > > > o PCP server is now more robust and insistent about informing PCP > > client of state changes. > > > > o When PCP server sends Mapping Update to a specific PCP client, > > and > > gets an update for a particular mapping, it doesn't need to > send > > reminders about that mapping any more. > > > > o THIRD_PARTY is now prohibited on subscriber PCP clients. > > > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp From mrw@lilacglade.org Fri May 25 13:33:03 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878AE21F8747 for ; Fri, 25 May 2012 13:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yez9VP6nMByE for ; Fri, 25 May 2012 13:33:03 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id CC8A821F8724 for ; Fri, 25 May 2012 13:33:02 -0700 (PDT) Received: from [10.36.0.36] (pool-108-49-158-143.bstnma.fios.verizon.net [108.49.158.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 34B3320383; Fri, 25 May 2012 16:32:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702DF450943@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Date: Fri, 25 May 2012 16:33:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <52527A56-1A45-4285-B808-0C2A691CEDD3@lilacglade.org> References: <02b301cd377c$31925b40$94b711c0$@com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF450809@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <03ec01cd3a8a$8f06fc70$ad14f550$@com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF450943@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> To: "Henderickx, Wim (Wim)" X-Mailer: Apple Mail (2.1084) Cc: "pcp@ietf.org" , "draft-ietf-pcp-base@tools.ietf.org" Subject: Re: [pcp] pcp-base-25 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 20:33:03 -0000 Is there actually deployed base of PCP at this point that we need to be = backwards compatible with? I am concerned about the idea that we would need to be backwards = compatible with PCP-24, which doesn't even exist in an easily accessible = form now that PCP-25 has been published. =20 Margaret On May 25, 2012, at 3:15 PM, Henderickx, Wim (Wim) wrote: > Dan, if a PCP-25 client is using a nonce which has these 192-224 bits = set as one of those heuristic values the PCP-24 server would interpret = the packet wrongly. >=20 > The option is much better for backward compatibility and lets make it = mandatory to ensure it is included in the MAP/PEER opcodes >=20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: vrijdag 25 mei 2012 17:25 > To: Henderickx, Wim (Wim); pcp@ietf.org > Cc: draft-ietf-pcp-base@tools.ietf.org > Subject: RE: [pcp] pcp-base-25 >=20 >> -----Original Message----- >> From: Henderickx, Wim (Wim) = [mailto:wim.henderickx@alcatel-lucent.com] >> Sent: Friday, May 25, 2012 5:33 AM >> To: Dan Wing; pcp@ietf.org >> Cc: draft-ietf-pcp-base@tools.ietf.org >> Subject: RE: [pcp] pcp-base-25 >>=20 >> Dan, >>=20 >> Can we not add the Nonce in an option iso in the MAP/PEER messages? >> This will provide easier backward compatibility with existing >> implementations. >=20 > It's mandatory in order to make it difficult for an off-path attacker > to spoof the PCP server. If it's optional in the specification, it > will be optional in implementations -- weakening the protocol (bad) > and adding permanent, long-term interop complexity (bad). >=20 >=20 > I do understand there are pre-RFC implementations in the field, and > I believe they can be accommodated by a PCP server that understands > both -24 and -25. >=20 > A PCP server, which supports -24 and -25, can differentiate a PCP > request as being from a -24 or -25 PCP client by using a heuristic. > The heuristic examines bits 192-224 of the MAP opcode request. In=20 > -24, those bits are the protocol number and 24 reserved bits which=20 > must be 0. In -25, those bits are the first 32 bits of the Mapping=20 > Nonce. >=20 > A -24 client, supporting only TCP and UDP (which I am sure is all > that are supported today), will always set those bits to three > different values, >=20 > 0000011000000000000000000000 =3D protocol=3D6=3DTCP > 0010001000000000000000000000 =3D protocol=3D17=3DUDP > 0000000000000000000000000000 =3D protocol=3Dwildcard >=20 > any other values in that 32 bit field means it's from a -25 PCP > client, because bits 192-224 are the first 32 bits of the Mapping > Nonce, which is a random value. This heuristic will fail if the PCP > client happens to choose a random value where the first 32 bits are > those three values above. >=20 > A similar heuristic can be used for the PEER opcode. >=20 > -d >=20 >=20 >> Cheers, >> Wim >>=20 >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of >> Dan Wing >> Sent: maandag 21 mei 2012 20:05 >> To: pcp@ietf.org >> Cc: draft-ietf-pcp-base@tools.ietf.org >> Subject: [pcp] pcp-base-25 >>=20 >> draft-ietf-pcp-base-25 was just submitted. The major changes to the >> document >> are introduction of Mapping Nonce to MAP and PEER opcodes, which >> protects >> against spoofing of the PCP server, and the restriction of the >> THIRD_PARTY >> option to networks with ACLs that prevent spoofing of the PCP client. >>=20 >> Other changes are summarized in the changes section, which is copied >> below >> for convenience. >>=20 >> Version -25 is available at >> http://tools.ietf.org/html/draft-ietf-pcp-base-25 >>=20 >> And side-by-side diffs between -24 and -25 are at >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-base-25.txt >>=20 >>=20 >> If you have feedback, please change the Subject line to something >> meaningful. >>=20 >> -d >>=20 >> ----- >>=20 >>=20 >> o Clarified the port used by the PCP server when sending >> unsolicited >> unicast ANNOUNCE. >>=20 >> o Removed parenthetical comment implying ANNOUNCE was not a normal >> Opcode; it is a normal Opcode. >>=20 >> o Explain that non-PCP-speaking host-based and network-based >> firewalls need to allow incoming connections for MAP to work. >>=20 >> o For race condition with PREFER_FAILURE, clarified that it is the >> PCP client's responsibility to delete the mapping if the PCP >> client doesn't need the mapping. >>=20 >> o For table, the NAT64 remote peer is IPv4 (was IPv6). >>=20 >> o Added a Mapping Nonce field to both MAP and PEER requests and >> responses, to protect from off-path attackers spoofing the PCP >> server's IP address. >>=20 >> o Security considerations: added 'PCP is secure against off-path >> attackers who can spoof the PCP server's IP address', because of >> the addition of the Mapping Nonce. >>=20 >> o Removed reference to DS-Lite from Security Considerations, as >> part >> of the changes to THIRD_PARTY from IESG review. >>=20 >> o Rapid Recovery is now a SHOULD implement. >>=20 >> o Clarify behavior of PREFER_FAILURE with zeros in Suggested >> External Port or Address fields. >>=20 >> o PCP server is now more robust and insistent about informing PCP >> client of state changes. >>=20 >> o When PCP server sends Mapping Update to a specific PCP client, >> and >> gets an update for a particular mapping, it doesn't need to send >> reminders about that mapping any more. >>=20 >> o THIRD_PARTY is now prohibited on subscriber PCP clients. >>=20 >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From wim.henderickx@alcatel-lucent.com Sat May 26 03:52:55 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7FA21F85B8 for ; Sat, 26 May 2012 03:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.915 X-Spam-Level: X-Spam-Status: No, score=-9.915 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49acHhqA2Axv for ; Sat, 26 May 2012 03:52:54 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE9E21F85BE for ; Sat, 26 May 2012 03:52:53 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q4QAoxT6021438 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 26 May 2012 12:52:47 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sat, 26 May 2012 12:52:00 +0200 From: "Henderickx, Wim (Wim)" To: Margaret Wasserman Date: Sat, 26 May 2012 12:51:56 +0200 Thread-Topic: [pcp] pcp-base-25 Thread-Index: Ac06tZpdjEYEwaiLSGWydPlzolQuwwAd+clA Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702DF450969@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <02b301cd377c$31925b40$94b711c0$@com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF450809@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <03ec01cd3a8a$8f06fc70$ad14f550$@com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF450943@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <52527A56-1A45-4285-B808-0C2A691CEDD3@lilacglade.org> In-Reply-To: <52527A56-1A45-4285-B808-0C2A691CEDD3@lilacglade.org> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "pcp@ietf.org" , "draft-ietf-pcp-base@tools.ietf.org" Subject: Re: [pcp] pcp-base-25 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 10:52:55 -0000 -----Original Message----- From: Margaret Wasserman [mailto:mrw@lilacglade.org]=20 Sent: vrijdag 25 mei 2012 22:33 To: Henderickx, Wim (Wim) Cc: Dan Wing; pcp@ietf.org; draft-ietf-pcp-base@tools.ietf.org Subject: Re: [pcp] pcp-base-25 Is there actually deployed base of PCP at this point that we need to be bac= kwards compatible with? WH> yes I am concerned about the idea that we would need to be backwards compatible= with PCP-24, which doesn't even exist in an easily accessible form now tha= t PCP-25 has been published. =20 Margaret On May 25, 2012, at 3:15 PM, Henderickx, Wim (Wim) wrote: > Dan, if a PCP-25 client is using a nonce which has these 192-224 bits set= as one of those heuristic values the PCP-24 server would interpret the pac= ket wrongly. >=20 > The option is much better for backward compatibility and lets make it man= datory to ensure it is included in the MAP/PEER opcodes >=20 > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com]=20 > Sent: vrijdag 25 mei 2012 17:25 > To: Henderickx, Wim (Wim); pcp@ietf.org > Cc: draft-ietf-pcp-base@tools.ietf.org > Subject: RE: [pcp] pcp-base-25 >=20 >> -----Original Message----- >> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] >> Sent: Friday, May 25, 2012 5:33 AM >> To: Dan Wing; pcp@ietf.org >> Cc: draft-ietf-pcp-base@tools.ietf.org >> Subject: RE: [pcp] pcp-base-25 >>=20 >> Dan, >>=20 >> Can we not add the Nonce in an option iso in the MAP/PEER messages? >> This will provide easier backward compatibility with existing >> implementations. >=20 > It's mandatory in order to make it difficult for an off-path attacker > to spoof the PCP server. If it's optional in the specification, it > will be optional in implementations -- weakening the protocol (bad) > and adding permanent, long-term interop complexity (bad). >=20 >=20 > I do understand there are pre-RFC implementations in the field, and > I believe they can be accommodated by a PCP server that understands > both -24 and -25. >=20 > A PCP server, which supports -24 and -25, can differentiate a PCP > request as being from a -24 or -25 PCP client by using a heuristic. > The heuristic examines bits 192-224 of the MAP opcode request. In=20 > -24, those bits are the protocol number and 24 reserved bits which=20 > must be 0. In -25, those bits are the first 32 bits of the Mapping=20 > Nonce. >=20 > A -24 client, supporting only TCP and UDP (which I am sure is all > that are supported today), will always set those bits to three > different values, >=20 > 0000011000000000000000000000 =3D protocol=3D6=3DTCP > 0010001000000000000000000000 =3D protocol=3D17=3DUDP > 0000000000000000000000000000 =3D protocol=3Dwildcard >=20 > any other values in that 32 bit field means it's from a -25 PCP > client, because bits 192-224 are the first 32 bits of the Mapping > Nonce, which is a random value. This heuristic will fail if the PCP > client happens to choose a random value where the first 32 bits are > those three values above. >=20 > A similar heuristic can be used for the PEER opcode. >=20 > -d >=20 >=20 >> Cheers, >> Wim >>=20 >> -----Original Message----- >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of >> Dan Wing >> Sent: maandag 21 mei 2012 20:05 >> To: pcp@ietf.org >> Cc: draft-ietf-pcp-base@tools.ietf.org >> Subject: [pcp] pcp-base-25 >>=20 >> draft-ietf-pcp-base-25 was just submitted. The major changes to the >> document >> are introduction of Mapping Nonce to MAP and PEER opcodes, which >> protects >> against spoofing of the PCP server, and the restriction of the >> THIRD_PARTY >> option to networks with ACLs that prevent spoofing of the PCP client. >>=20 >> Other changes are summarized in the changes section, which is copied >> below >> for convenience. >>=20 >> Version -25 is available at >> http://tools.ietf.org/html/draft-ietf-pcp-base-25 >>=20 >> And side-by-side diffs between -24 and -25 are at >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-base-25.txt >>=20 >>=20 >> If you have feedback, please change the Subject line to something >> meaningful. >>=20 >> -d >>=20 >> ----- >>=20 >>=20 >> o Clarified the port used by the PCP server when sending >> unsolicited >> unicast ANNOUNCE. >>=20 >> o Removed parenthetical comment implying ANNOUNCE was not a normal >> Opcode; it is a normal Opcode. >>=20 >> o Explain that non-PCP-speaking host-based and network-based >> firewalls need to allow incoming connections for MAP to work. >>=20 >> o For race condition with PREFER_FAILURE, clarified that it is the >> PCP client's responsibility to delete the mapping if the PCP >> client doesn't need the mapping. >>=20 >> o For table, the NAT64 remote peer is IPv4 (was IPv6). >>=20 >> o Added a Mapping Nonce field to both MAP and PEER requests and >> responses, to protect from off-path attackers spoofing the PCP >> server's IP address. >>=20 >> o Security considerations: added 'PCP is secure against off-path >> attackers who can spoof the PCP server's IP address', because of >> the addition of the Mapping Nonce. >>=20 >> o Removed reference to DS-Lite from Security Considerations, as >> part >> of the changes to THIRD_PARTY from IESG review. >>=20 >> o Rapid Recovery is now a SHOULD implement. >>=20 >> o Clarify behavior of PREFER_FAILURE with zeros in Suggested >> External Port or Address fields. >>=20 >> o PCP server is now more robust and insistent about informing PCP >> client of state changes. >>=20 >> o When PCP server sends Mapping Update to a specific PCP client, >> and >> gets an update for a particular mapping, it doesn't need to send >> reminders about that mapping any more. >>=20 >> o THIRD_PARTY is now prohibited on subscriber PCP clients. >>=20 >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From wim.henderickx@alcatel-lucent.com Sat May 26 03:54:31 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DC921F85BE for ; Sat, 26 May 2012 03:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.963 X-Spam-Level: X-Spam-Status: No, score=-9.963 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uI6pKYvJj6q7 for ; Sat, 26 May 2012 03:54:30 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id E942C21F85B9 for ; Sat, 26 May 2012 03:54:29 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q4QAsQUA029039 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 26 May 2012 12:54:26 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sat, 26 May 2012 12:54:26 +0200 From: "Henderickx, Wim (Wim)" To: Dan Wing , "pcp@ietf.org" Date: Sat, 26 May 2012 12:54:21 +0200 Thread-Topic: [pcp] pcp-base-25 Thread-Index: Ac03e3YF3IFRrRIGRtiS6WBVqCoxMQC9m5vwAAWByeAACJGDAAABflBwAB9eIPA= Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702DF45096A@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <02b301cd377c$31925b40$94b711c0$@com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF450809@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <03ec01cd3a8a$8f06fc70$ad14f550$@com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF450943@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <056901cd3ab1$58393920$08abab60$@com> In-Reply-To: <056901cd3ab1$58393920$08abab60$@com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "draft-ietf-pcp-base@tools.ietf.org" Subject: Re: [pcp] pcp-base-25 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 10:54:31 -0000 There is other options to make this in the MAP/PEER header. Take one of the reserved bits and indicate that a nonce is embedded, put th= is bit to 1 and append the nonce at the end of the MAP/PEER opcode -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: vrijdag 25 mei 2012 22:03 To: Henderickx, Wim (Wim); pcp@ietf.org Cc: draft-ietf-pcp-base@tools.ietf.org Subject: RE: [pcp] pcp-base-25 > -----Original Message----- > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] > Sent: Friday, May 25, 2012 12:16 PM > To: Dan Wing; pcp@ietf.org > Cc: draft-ietf-pcp-base@tools.ietf.org > Subject: RE: [pcp] pcp-base-25 >=20 > Dan, if a PCP-25 client is using a nonce which has these 192-224 bits > set as one of those heuristic values the PCP-24 server would interpret > the packet wrongly. Yes, that is what I meant when I wrote "This heuristic will fail if the PCP client happens to choose a random value where the first 32 bits are those three values above." I am sure there are additional heuristics that can improve the detection, such as packet length, looking for a legal Option code value where it's expected for -24, or -- if these pcp-base-24 clients are IPv4 clients --=20 looking for their 96 bit ::FFFF pattern in the Suggested External IP=20 Address field. > The option is much better for backward compatibility and lets make it > mandatory to ensure it is included in the MAP/PEER opcodes I am hard pressed to provide backward compatibility with pre-RFC=20 implementations, especially by making a security mechanism optional to accommodate those pre-RFC implementations. This would create=20 permanent harm to PCP, whereas pre-25 versions are temporary. -d > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: vrijdag 25 mei 2012 17:25 > To: Henderickx, Wim (Wim); pcp@ietf.org > Cc: draft-ietf-pcp-base@tools.ietf.org > Subject: RE: [pcp] pcp-base-25 >=20 > > -----Original Message----- > > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > lucent.com] > > Sent: Friday, May 25, 2012 5:33 AM > > To: Dan Wing; pcp@ietf.org > > Cc: draft-ietf-pcp-base@tools.ietf.org > > Subject: RE: [pcp] pcp-base-25 > > > > Dan, > > > > Can we not add the Nonce in an option iso in the MAP/PEER messages? > > This will provide easier backward compatibility with existing > > implementations. >=20 > It's mandatory in order to make it difficult for an off-path attacker > to spoof the PCP server. If it's optional in the specification, it > will be optional in implementations -- weakening the protocol (bad) > and adding permanent, long-term interop complexity (bad). >=20 >=20 > I do understand there are pre-RFC implementations in the field, and > I believe they can be accommodated by a PCP server that understands > both -24 and -25. >=20 > A PCP server, which supports -24 and -25, can differentiate a PCP > request as being from a -24 or -25 PCP client by using a heuristic. > The heuristic examines bits 192-224 of the MAP opcode request. In > -24, those bits are the protocol number and 24 reserved bits which > must be 0. In -25, those bits are the first 32 bits of the Mapping > Nonce. >=20 > A -24 client, supporting only TCP and UDP (which I am sure is all > that are supported today), will always set those bits to three > different values, >=20 > 0000011000000000000000000000 =3D protocol=3D6=3DTCP > 0010001000000000000000000000 =3D protocol=3D17=3DUDP > 0000000000000000000000000000 =3D protocol=3Dwildcard >=20 > any other values in that 32 bit field means it's from a -25 PCP > client, because bits 192-224 are the first 32 bits of the Mapping > Nonce, which is a random value. This heuristic will fail if the PCP > client happens to choose a random value where the first 32 bits are > those three values above. >=20 > A similar heuristic can be used for the PEER opcode. >=20 > -d >=20 >=20 > > Cheers, > > Wim > > > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > > Dan Wing > > Sent: maandag 21 mei 2012 20:05 > > To: pcp@ietf.org > > Cc: draft-ietf-pcp-base@tools.ietf.org > > Subject: [pcp] pcp-base-25 > > > > draft-ietf-pcp-base-25 was just submitted. The major changes to the > > document > > are introduction of Mapping Nonce to MAP and PEER opcodes, which > > protects > > against spoofing of the PCP server, and the restriction of the > > THIRD_PARTY > > option to networks with ACLs that prevent spoofing of the PCP client. > > > > Other changes are summarized in the changes section, which is copied > > below > > for convenience. > > > > Version -25 is available at > > http://tools.ietf.org/html/draft-ietf-pcp-base-25 > > > > And side-by-side diffs between -24 and -25 are at > > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-base-25.txt > > > > > > If you have feedback, please change the Subject line to something > > meaningful. > > > > -d > > > > ----- > > > > > > o Clarified the port used by the PCP server when sending > > unsolicited > > unicast ANNOUNCE. > > > > o Removed parenthetical comment implying ANNOUNCE was not a > normal > > Opcode; it is a normal Opcode. > > > > o Explain that non-PCP-speaking host-based and network-based > > firewalls need to allow incoming connections for MAP to work. > > > > o For race condition with PREFER_FAILURE, clarified that it is > the > > PCP client's responsibility to delete the mapping if the PCP > > client doesn't need the mapping. > > > > o For table, the NAT64 remote peer is IPv4 (was IPv6). > > > > o Added a Mapping Nonce field to both MAP and PEER requests and > > responses, to protect from off-path attackers spoofing the PCP > > server's IP address. > > > > o Security considerations: added 'PCP is secure against off-path > > attackers who can spoof the PCP server's IP address', because > of > > the addition of the Mapping Nonce. > > > > o Removed reference to DS-Lite from Security Considerations, as > > part > > of the changes to THIRD_PARTY from IESG review. > > > > o Rapid Recovery is now a SHOULD implement. > > > > o Clarify behavior of PREFER_FAILURE with zeros in Suggested > > External Port or Address fields. > > > > o PCP server is now more robust and insistent about informing PCP > > client of state changes. > > > > o When PCP server sends Mapping Update to a specific PCP client, > > and > > gets an update for a particular mapping, it doesn't need to > send > > reminders about that mapping any more. > > > > o THIRD_PARTY is now prohibited on subscriber PCP clients. > > > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp From moore@network-heretics.com Sat May 26 04:52:04 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E6B21F85CD for ; Sat, 26 May 2012 04:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyZ8UyxNmaQG for ; Sat, 26 May 2012 04:51:56 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 7021221F85C4 for ; Sat, 26 May 2012 04:51:56 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8AF8820B34; Sat, 26 May 2012 07:51:55 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 26 May 2012 07:51:55 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=LS9SqbMSX71zMpyVoHAORmqTaEU=; b=sV B4rU2hHvaiPcFUD+4ZabDUZ+pgINxZL2zSmNS1S/HXJbZRWCYlpB/ia9u5h2+PD3 dRf8dCPi9FvIKqUfG4bt7NE9/y3yT2IZg1wHgeodByvasIzfCmNt+MLBFsSH4yry Jif9KOYIPj0b1kz8PRh+fWb7IYyxiseNrl6tczp28= X-Sasl-enc: PR57F5CuIVKmm8Jd6iRh0qpDoQ9+BXJAbqHLTAgIVzrS 1338033114 Received: from [192.168.1.16] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 06FAE483601; Sat, 26 May 2012 07:51:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702DF450969@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Date: Sat, 26 May 2012 07:51:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <02b301cd377c$31925b40$94b711c0$@com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF450809@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <03ec01cd3a8a$8f06fc70$ad14f550$@com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF450943@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <52527A56-1A45-4285-B808-0C2A691CEDD3@lilacglade.org> <14C7F4F06DB5814AB0DE29716C4F6D6702DF450969@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> To: "Henderickx, Wim (Wim)" X-Mailer: Apple Mail (2.1084) Cc: Margaret Wasserman , "pcp@ietf.org" , "draft-ietf-pcp-base@tools.ietf.org" Subject: Re: [pcp] pcp-base-25 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 11:52:04 -0000 That's not a valid reason to standardize a specification with serious = identified security flaws. Companies that deploy a protocol before the first standard RFC is = approved should realize that they're taking a gamble that they're very = likely to lose. Keith On May 26, 2012, at 6:51 AM, Henderickx, Wim (Wim) wrote: >=20 >=20 > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@lilacglade.org]=20 > Sent: vrijdag 25 mei 2012 22:33 > To: Henderickx, Wim (Wim) > Cc: Dan Wing; pcp@ietf.org; draft-ietf-pcp-base@tools.ietf.org > Subject: Re: [pcp] pcp-base-25 >=20 >=20 > Is there actually deployed base of PCP at this point that we need to = be backwards compatible with? >=20 > WH> yes >=20 > I am concerned about the idea that we would need to be backwards = compatible with PCP-24, which doesn't even exist in an easily accessible = form now that PCP-25 has been published. =20 >=20 > Margaret >=20 >=20 > On May 25, 2012, at 3:15 PM, Henderickx, Wim (Wim) wrote: >=20 >> Dan, if a PCP-25 client is using a nonce which has these 192-224 bits = set as one of those heuristic values the PCP-24 server would interpret = the packet wrongly. >>=20 >> The option is much better for backward compatibility and lets make it = mandatory to ensure it is included in the MAP/PEER opcodes >>=20 >> -----Original Message----- >> From: Dan Wing [mailto:dwing@cisco.com]=20 >> Sent: vrijdag 25 mei 2012 17:25 >> To: Henderickx, Wim (Wim); pcp@ietf.org >> Cc: draft-ietf-pcp-base@tools.ietf.org >> Subject: RE: [pcp] pcp-base-25 >>=20 >>> -----Original Message----- >>> From: Henderickx, Wim (Wim) = [mailto:wim.henderickx@alcatel-lucent.com] >>> Sent: Friday, May 25, 2012 5:33 AM >>> To: Dan Wing; pcp@ietf.org >>> Cc: draft-ietf-pcp-base@tools.ietf.org >>> Subject: RE: [pcp] pcp-base-25 >>>=20 >>> Dan, >>>=20 >>> Can we not add the Nonce in an option iso in the MAP/PEER messages? >>> This will provide easier backward compatibility with existing >>> implementations. >>=20 >> It's mandatory in order to make it difficult for an off-path attacker >> to spoof the PCP server. If it's optional in the specification, it >> will be optional in implementations -- weakening the protocol (bad) >> and adding permanent, long-term interop complexity (bad). >>=20 >>=20 >> I do understand there are pre-RFC implementations in the field, and >> I believe they can be accommodated by a PCP server that understands >> both -24 and -25. >>=20 >> A PCP server, which supports -24 and -25, can differentiate a PCP >> request as being from a -24 or -25 PCP client by using a heuristic. >> The heuristic examines bits 192-224 of the MAP opcode request. In=20 >> -24, those bits are the protocol number and 24 reserved bits which=20 >> must be 0. In -25, those bits are the first 32 bits of the Mapping=20= >> Nonce. >>=20 >> A -24 client, supporting only TCP and UDP (which I am sure is all >> that are supported today), will always set those bits to three >> different values, >>=20 >> 0000011000000000000000000000 =3D protocol=3D6=3DTCP >> 0010001000000000000000000000 =3D protocol=3D17=3DUDP >> 0000000000000000000000000000 =3D protocol=3Dwildcard >>=20 >> any other values in that 32 bit field means it's from a -25 PCP >> client, because bits 192-224 are the first 32 bits of the Mapping >> Nonce, which is a random value. This heuristic will fail if the PCP >> client happens to choose a random value where the first 32 bits are >> those three values above. >>=20 >> A similar heuristic can be used for the PEER opcode. >>=20 >> -d >>=20 >>=20 >>> Cheers, >>> Wim >>>=20 >>> -----Original Message----- >>> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf = Of >>> Dan Wing >>> Sent: maandag 21 mei 2012 20:05 >>> To: pcp@ietf.org >>> Cc: draft-ietf-pcp-base@tools.ietf.org >>> Subject: [pcp] pcp-base-25 >>>=20 >>> draft-ietf-pcp-base-25 was just submitted. The major changes to the >>> document >>> are introduction of Mapping Nonce to MAP and PEER opcodes, which >>> protects >>> against spoofing of the PCP server, and the restriction of the >>> THIRD_PARTY >>> option to networks with ACLs that prevent spoofing of the PCP = client. >>>=20 >>> Other changes are summarized in the changes section, which is copied >>> below >>> for convenience. >>>=20 >>> Version -25 is available at >>> http://tools.ietf.org/html/draft-ietf-pcp-base-25 >>>=20 >>> And side-by-side diffs between -24 and -25 are at >>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-base-25.txt >>>=20 >>>=20 >>> If you have feedback, please change the Subject line to something >>> meaningful. >>>=20 >>> -d >>>=20 >>> ----- >>>=20 >>>=20 >>> o Clarified the port used by the PCP server when sending >>> unsolicited >>> unicast ANNOUNCE. >>>=20 >>> o Removed parenthetical comment implying ANNOUNCE was not a normal >>> Opcode; it is a normal Opcode. >>>=20 >>> o Explain that non-PCP-speaking host-based and network-based >>> firewalls need to allow incoming connections for MAP to work. >>>=20 >>> o For race condition with PREFER_FAILURE, clarified that it is the >>> PCP client's responsibility to delete the mapping if the PCP >>> client doesn't need the mapping. >>>=20 >>> o For table, the NAT64 remote peer is IPv4 (was IPv6). >>>=20 >>> o Added a Mapping Nonce field to both MAP and PEER requests and >>> responses, to protect from off-path attackers spoofing the PCP >>> server's IP address. >>>=20 >>> o Security considerations: added 'PCP is secure against off-path >>> attackers who can spoof the PCP server's IP address', because of >>> the addition of the Mapping Nonce. >>>=20 >>> o Removed reference to DS-Lite from Security Considerations, as >>> part >>> of the changes to THIRD_PARTY from IESG review. >>>=20 >>> o Rapid Recovery is now a SHOULD implement. >>>=20 >>> o Clarify behavior of PREFER_FAILURE with zeros in Suggested >>> External Port or Address fields. >>>=20 >>> o PCP server is now more robust and insistent about informing PCP >>> client of state changes. >>>=20 >>> o When PCP server sends Mapping Update to a specific PCP client, >>> and >>> gets an update for a particular mapping, it doesn't need to send >>> reminders about that mapping any more. >>>=20 >>> o THIRD_PARTY is now prohibited on subscriber PCP clients. >>>=20 >>>=20 >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From wim.henderickx@alcatel-lucent.com Sat May 26 04:56:37 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AA021F8577 for ; Sat, 26 May 2012 04:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A31qQ+lJJj61 for ; Sat, 26 May 2012 04:56:36 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by ietfa.amsl.com (Postfix) with ESMTP id E1C5321F856F for ; Sat, 26 May 2012 04:56:35 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q4QBse8x006570 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 26 May 2012 13:56:28 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sat, 26 May 2012 13:55:18 +0200 From: "Henderickx, Wim (Wim)" To: "'moore@network-heretics.com'" Date: Sat, 26 May 2012 13:55:17 +0200 Thread-Topic: [pcp] pcp-base-25 Thread-Index: Ac07NfSd7iWqFwnCRnC2fiF5yfQGFAAAHYbC Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702DF21706F@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "'mrw@lilacglade.org'" , "'pcp@ietf.org'" , "'draft-ietf-pcp-base@tools.ietf.org'" Subject: Re: [pcp] pcp-base-25 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 11:56:37 -0000 Sure and we do it for good reasons. Originally this spec should have been d= one as per original goal and this was not accomplished. So why would we not= try to make it backward compatible if it is easy and possible as I suggest= ed. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Keith Moore [mailto:moore@network-heretics.com] Sent: Saturday, May 26, 2012 01:51 PM=0A= To: Henderickx, Wim (Wim) Cc: Margaret Wasserman ; pcp@ietf.org ; d= raft-ietf-pcp-base@tools.ietf.org Subject: Re: [pcp] pcp-base-25 That's not a valid reason to standardize a specification with serious ident= ified security flaws. Companies that deploy a protocol before the first standard RFC is approved = should realize that they're taking a gamble that they're very likely to los= e. Keith On May 26, 2012, at 6:51 AM, Henderickx, Wim (Wim) wrote: >=20 >=20 > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@lilacglade.org]=20 > Sent: vrijdag 25 mei 2012 22:33 > To: Henderickx, Wim (Wim) > Cc: Dan Wing; pcp@ietf.org; draft-ietf-pcp-base@tools.ietf.org > Subject: Re: [pcp] pcp-base-25 >=20 >=20 > Is there actually deployed base of PCP at this point that we need to be b= ackwards compatible with? >=20 > WH> yes >=20 > I am concerned about the idea that we would need to be backwards compatib= le with PCP-24, which doesn't even exist in an easily accessible form now t= hat PCP-25 has been published. =20 >=20 > Margaret >=20 >=20 > On May 25, 2012, at 3:15 PM, Henderickx, Wim (Wim) wrote: >=20 >> Dan, if a PCP-25 client is using a nonce which has these 192-224 bits se= t as one of those heuristic values the PCP-24 server would interpret the pa= cket wrongly. >>=20 >> The option is much better for backward compatibility and lets make it ma= ndatory to ensure it is included in the MAP/PEER opcodes >>=20 >> -----Original Message----- >> From: Dan Wing [mailto:dwing@cisco.com]=20 >> Sent: vrijdag 25 mei 2012 17:25 >> To: Henderickx, Wim (Wim); pcp@ietf.org >> Cc: draft-ietf-pcp-base@tools.ietf.org >> Subject: RE: [pcp] pcp-base-25 >>=20 >>> -----Original Message----- >>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] >>> Sent: Friday, May 25, 2012 5:33 AM >>> To: Dan Wing; pcp@ietf.org >>> Cc: draft-ietf-pcp-base@tools.ietf.org >>> Subject: RE: [pcp] pcp-base-25 >>>=20 >>> Dan, >>>=20 >>> Can we not add the Nonce in an option iso in the MAP/PEER messages? >>> This will provide easier backward compatibility with existing >>> implementations. >>=20 >> It's mandatory in order to make it difficult for an off-path attacker >> to spoof the PCP server. If it's optional in the specification, it >> will be optional in implementations -- weakening the protocol (bad) >> and adding permanent, long-term interop complexity (bad). >>=20 >>=20 >> I do understand there are pre-RFC implementations in the field, and >> I believe they can be accommodated by a PCP server that understands >> both -24 and -25. >>=20 >> A PCP server, which supports -24 and -25, can differentiate a PCP >> request as being from a -24 or -25 PCP client by using a heuristic. >> The heuristic examines bits 192-224 of the MAP opcode request. In=20 >> -24, those bits are the protocol number and 24 reserved bits which=20 >> must be 0. In -25, those bits are the first 32 bits of the Mapping=20 >> Nonce. >>=20 >> A -24 client, supporting only TCP and UDP (which I am sure is all >> that are supported today), will always set those bits to three >> different values, >>=20 >> 0000011000000000000000000000 =3D protocol=3D6=3DTCP >> 0010001000000000000000000000 =3D protocol=3D17=3DUDP >> 0000000000000000000000000000 =3D protocol=3Dwildcard >>=20 >> any other values in that 32 bit field means it's from a -25 PCP >> client, because bits 192-224 are the first 32 bits of the Mapping >> Nonce, which is a random value. This heuristic will fail if the PCP >> client happens to choose a random value where the first 32 bits are >> those three values above. >>=20 >> A similar heuristic can be used for the PEER opcode. >>=20 >> -d >>=20 >>=20 >>> Cheers, >>> Wim >>>=20 >>> -----Original Message----- >>> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of >>> Dan Wing >>> Sent: maandag 21 mei 2012 20:05 >>> To: pcp@ietf.org >>> Cc: draft-ietf-pcp-base@tools.ietf.org >>> Subject: [pcp] pcp-base-25 >>>=20 >>> draft-ietf-pcp-base-25 was just submitted. The major changes to the >>> document >>> are introduction of Mapping Nonce to MAP and PEER opcodes, which >>> protects >>> against spoofing of the PCP server, and the restriction of the >>> THIRD_PARTY >>> option to networks with ACLs that prevent spoofing of the PCP client. >>>=20 >>> Other changes are summarized in the changes section, which is copied >>> below >>> for convenience. >>>=20 >>> Version -25 is available at >>> http://tools.ietf.org/html/draft-ietf-pcp-base-25 >>>=20 >>> And side-by-side diffs between -24 and -25 are at >>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-base-25.txt >>>=20 >>>=20 >>> If you have feedback, please change the Subject line to something >>> meaningful. >>>=20 >>> -d >>>=20 >>> ----- >>>=20 >>>=20 >>> o Clarified the port used by the PCP server when sending >>> unsolicited >>> unicast ANNOUNCE. >>>=20 >>> o Removed parenthetical comment implying ANNOUNCE was not a normal >>> Opcode; it is a normal Opcode. >>>=20 >>> o Explain that non-PCP-speaking host-based and network-based >>> firewalls need to allow incoming connections for MAP to work. >>>=20 >>> o For race condition with PREFER_FAILURE, clarified that it is the >>> PCP client's responsibility to delete the mapping if the PCP >>> client doesn't need the mapping. >>>=20 >>> o For table, the NAT64 remote peer is IPv4 (was IPv6). >>>=20 >>> o Added a Mapping Nonce field to both MAP and PEER requests and >>> responses, to protect from off-path attackers spoofing the PCP >>> server's IP address. >>>=20 >>> o Security considerations: added 'PCP is secure against off-path >>> attackers who can spoof the PCP server's IP address', because of >>> the addition of the Mapping Nonce. >>>=20 >>> o Removed reference to DS-Lite from Security Considerations, as >>> part >>> of the changes to THIRD_PARTY from IESG review. >>>=20 >>> o Rapid Recovery is now a SHOULD implement. >>>=20 >>> o Clarify behavior of PREFER_FAILURE with zeros in Suggested >>> External Port or Address fields. >>>=20 >>> o PCP server is now more robust and insistent about informing PCP >>> client of state changes. >>>=20 >>> o When PCP server sends Mapping Update to a specific PCP client, >>> and >>> gets an update for a particular mapping, it doesn't need to send >>> reminders about that mapping any more. >>>=20 >>> o THIRD_PARTY is now prohibited on subscriber PCP clients. >>>=20 >>>=20 >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From moore@network-heretics.com Sat May 26 05:01:36 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C5F21F85A5 for ; Sat, 26 May 2012 05:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+vKumRjnN0E for ; Sat, 26 May 2012 05:01:35 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id CC65221F8577 for ; Sat, 26 May 2012 05:01:34 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7FF5620B68; Sat, 26 May 2012 08:01:34 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 26 May 2012 08:01:34 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=MYqTxcq2o2VVy2ycNlVEBWWOroU=; b=Vo MXvM9kpExp6/VBEaQYsrYEq8BNPkkJKRIcGMpE7+cWFLSJZQ82DCiifF82ME72wA A0l1SAT/3dNXvf+H+XpWR43OigHs5JNrMZ9/IRaryaTNss39xzlOXd02WYpW+hjS 1In831ed9QQzYQEKIYIVyCABU58NqDdEPDFFf1ky8= X-Sasl-enc: xA3baHF1xkx5aUmqgHIieLovGbzYoOOalStyHw/5C1DA 1338033693 Received: from [192.168.1.16] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id EDE33483524; Sat, 26 May 2012 08:01:32 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702DF21706F@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Date: Sat, 26 May 2012 08:01:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9282CF6B-D6CF-4DF9-AA41-B5850A15F2AA@network-heretics.com> References: <14C7F4F06DB5814AB0DE29716C4F6D6702DF21706F@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> To: "Henderickx, Wim (Wim)" X-Mailer: Apple Mail (2.1084) Cc: "'mrw@lilacglade.org'" , "'pcp@ietf.org'" , "'draft-ietf-pcp-base@tools.ietf.org'" Subject: Re: [pcp] pcp-base-25 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 12:01:36 -0000 Sorry, no. There is NOTHING about a spec that is merely an = Internet-Draft that says that it's suitable for deployment. If you = deploy prior to standardization, you deserve whatever you get. =20 I've seen this used to delay or even hijack specifications too many = times. It's simply not acceptable. Keith On May 26, 2012, at 7:55 AM, Henderickx, Wim (Wim) wrote: > Sure and we do it for good reasons. Originally this spec should have = been done as per original goal and this was not accomplished. So why = would we not try to make it backward compatible if it is easy and = possible as I suggested. >=20 > Cheers, > Wim > _________________ > sent from blackberry >=20 > ----- Original Message ----- > From: Keith Moore [mailto:moore@network-heretics.com] > Sent: Saturday, May 26, 2012 01:51 PM > To: Henderickx, Wim (Wim) > Cc: Margaret Wasserman ; pcp@ietf.org = ; draft-ietf-pcp-base@tools.ietf.org = > Subject: Re: [pcp] pcp-base-25 >=20 > That's not a valid reason to standardize a specification with serious = identified security flaws. >=20 > Companies that deploy a protocol before the first standard RFC is = approved should realize that they're taking a gamble that they're very = likely to lose. >=20 > Keith >=20 > On May 26, 2012, at 6:51 AM, Henderickx, Wim (Wim) wrote: >=20 >>=20 >>=20 >> -----Original Message----- >> From: Margaret Wasserman [mailto:mrw@lilacglade.org]=20 >> Sent: vrijdag 25 mei 2012 22:33 >> To: Henderickx, Wim (Wim) >> Cc: Dan Wing; pcp@ietf.org; draft-ietf-pcp-base@tools.ietf.org >> Subject: Re: [pcp] pcp-base-25 >>=20 >>=20 >> Is there actually deployed base of PCP at this point that we need to = be backwards compatible with? >>=20 >> WH> yes >>=20 >> I am concerned about the idea that we would need to be backwards = compatible with PCP-24, which doesn't even exist in an easily accessible = form now that PCP-25 has been published. =20 >>=20 >> Margaret >>=20 >>=20 >> On May 25, 2012, at 3:15 PM, Henderickx, Wim (Wim) wrote: >>=20 >>> Dan, if a PCP-25 client is using a nonce which has these 192-224 = bits set as one of those heuristic values the PCP-24 server would = interpret the packet wrongly. >>>=20 >>> The option is much better for backward compatibility and lets make = it mandatory to ensure it is included in the MAP/PEER opcodes >>>=20 >>> -----Original Message----- >>> From: Dan Wing [mailto:dwing@cisco.com]=20 >>> Sent: vrijdag 25 mei 2012 17:25 >>> To: Henderickx, Wim (Wim); pcp@ietf.org >>> Cc: draft-ietf-pcp-base@tools.ietf.org >>> Subject: RE: [pcp] pcp-base-25 >>>=20 >>>> -----Original Message----- >>>> From: Henderickx, Wim (Wim) = [mailto:wim.henderickx@alcatel-lucent.com] >>>> Sent: Friday, May 25, 2012 5:33 AM >>>> To: Dan Wing; pcp@ietf.org >>>> Cc: draft-ietf-pcp-base@tools.ietf.org >>>> Subject: RE: [pcp] pcp-base-25 >>>>=20 >>>> Dan, >>>>=20 >>>> Can we not add the Nonce in an option iso in the MAP/PEER messages? >>>> This will provide easier backward compatibility with existing >>>> implementations. >>>=20 >>> It's mandatory in order to make it difficult for an off-path = attacker >>> to spoof the PCP server. If it's optional in the specification, it >>> will be optional in implementations -- weakening the protocol (bad) >>> and adding permanent, long-term interop complexity (bad). >>>=20 >>>=20 >>> I do understand there are pre-RFC implementations in the field, and >>> I believe they can be accommodated by a PCP server that understands >>> both -24 and -25. >>>=20 >>> A PCP server, which supports -24 and -25, can differentiate a PCP >>> request as being from a -24 or -25 PCP client by using a heuristic. >>> The heuristic examines bits 192-224 of the MAP opcode request. In=20= >>> -24, those bits are the protocol number and 24 reserved bits which=20= >>> must be 0. In -25, those bits are the first 32 bits of the Mapping=20= >>> Nonce. >>>=20 >>> A -24 client, supporting only TCP and UDP (which I am sure is all >>> that are supported today), will always set those bits to three >>> different values, >>>=20 >>> 0000011000000000000000000000 =3D protocol=3D6=3DTCP >>> 0010001000000000000000000000 =3D protocol=3D17=3DUDP >>> 0000000000000000000000000000 =3D protocol=3Dwildcard >>>=20 >>> any other values in that 32 bit field means it's from a -25 PCP >>> client, because bits 192-224 are the first 32 bits of the Mapping >>> Nonce, which is a random value. This heuristic will fail if the PCP >>> client happens to choose a random value where the first 32 bits are >>> those three values above. >>>=20 >>> A similar heuristic can be used for the PEER opcode. >>>=20 >>> -d >>>=20 >>>=20 >>>> Cheers, >>>> Wim >>>>=20 >>>> -----Original Message----- >>>> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf = Of >>>> Dan Wing >>>> Sent: maandag 21 mei 2012 20:05 >>>> To: pcp@ietf.org >>>> Cc: draft-ietf-pcp-base@tools.ietf.org >>>> Subject: [pcp] pcp-base-25 >>>>=20 >>>> draft-ietf-pcp-base-25 was just submitted. The major changes to = the >>>> document >>>> are introduction of Mapping Nonce to MAP and PEER opcodes, which >>>> protects >>>> against spoofing of the PCP server, and the restriction of the >>>> THIRD_PARTY >>>> option to networks with ACLs that prevent spoofing of the PCP = client. >>>>=20 >>>> Other changes are summarized in the changes section, which is = copied >>>> below >>>> for convenience. >>>>=20 >>>> Version -25 is available at >>>> http://tools.ietf.org/html/draft-ietf-pcp-base-25 >>>>=20 >>>> And side-by-side diffs between -24 and -25 are at >>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-base-25.txt >>>>=20 >>>>=20 >>>> If you have feedback, please change the Subject line to something >>>> meaningful. >>>>=20 >>>> -d >>>>=20 >>>> ----- >>>>=20 >>>>=20 >>>> o Clarified the port used by the PCP server when sending >>>> unsolicited >>>> unicast ANNOUNCE. >>>>=20 >>>> o Removed parenthetical comment implying ANNOUNCE was not a normal >>>> Opcode; it is a normal Opcode. >>>>=20 >>>> o Explain that non-PCP-speaking host-based and network-based >>>> firewalls need to allow incoming connections for MAP to work. >>>>=20 >>>> o For race condition with PREFER_FAILURE, clarified that it is the >>>> PCP client's responsibility to delete the mapping if the PCP >>>> client doesn't need the mapping. >>>>=20 >>>> o For table, the NAT64 remote peer is IPv4 (was IPv6). >>>>=20 >>>> o Added a Mapping Nonce field to both MAP and PEER requests and >>>> responses, to protect from off-path attackers spoofing the PCP >>>> server's IP address. >>>>=20 >>>> o Security considerations: added 'PCP is secure against off-path >>>> attackers who can spoof the PCP server's IP address', because of >>>> the addition of the Mapping Nonce. >>>>=20 >>>> o Removed reference to DS-Lite from Security Considerations, as >>>> part >>>> of the changes to THIRD_PARTY from IESG review. >>>>=20 >>>> o Rapid Recovery is now a SHOULD implement. >>>>=20 >>>> o Clarify behavior of PREFER_FAILURE with zeros in Suggested >>>> External Port or Address fields. >>>>=20 >>>> o PCP server is now more robust and insistent about informing PCP >>>> client of state changes. >>>>=20 >>>> o When PCP server sends Mapping Update to a specific PCP client, >>>> and >>>> gets an update for a particular mapping, it doesn't need to send >>>> reminders about that mapping any more. >>>>=20 >>>> o THIRD_PARTY is now prohibited on subscriber PCP clients. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> pcp mailing list >>>> pcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcp >>>=20 >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From wim.henderickx@alcatel-lucent.com Sat May 26 05:02:57 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2299221F85A5 for ; Sat, 26 May 2012 05:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.804 X-Spam-Level: X-Spam-Status: No, score=-9.804 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4palBI1MyqxE for ; Sat, 26 May 2012 05:02:56 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id EABB021F85B1 for ; Sat, 26 May 2012 05:02:55 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q4QC2s02007206 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 26 May 2012 14:02:54 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Sat, 26 May 2012 14:02:54 +0200 From: "Henderickx, Wim (Wim)" To: "'moore@network-heretics.com'" Date: Sat, 26 May 2012 14:02:52 +0200 Thread-Topic: [pcp] pcp-base-25 Thread-Index: Ac07N03YPbr7qTaySkKwMiSuQYNL7QAACxjA Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702DF217070@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: <9282CF6B-D6CF-4DF9-AA41-B5850A15F2AA@network-heretics.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "'mrw@lilacglade.org'" , "'pcp@ietf.org'" , "'draft-ietf-pcp-base@tools.ietf.org'" Subject: Re: [pcp] pcp-base-25 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 12:02:57 -0000 I am not trying to delay anything I am trying to solve a problem. Cheers, Wim _________________ sent from blackberry ----- Original Message ----- From: Keith Moore [mailto:moore@network-heretics.com] Sent: Saturday, May 26, 2012 02:01 PM=0A= To: Henderickx, Wim (Wim) Cc: 'mrw@lilacglade.org' ; 'pcp@ietf.org' ; 'draft-ietf-pcp-base@tools.ietf.org' Subject: Re: [pcp] pcp-base-25 Sorry, no. There is NOTHING about a spec that is merely an Internet-Draf= t that says that it's suitable for deployment. If you deploy prior to sta= ndardization, you deserve whatever you get. =20 I've seen this used to delay or even hijack specifications too many times. = It's simply not acceptable. Keith On May 26, 2012, at 7:55 AM, Henderickx, Wim (Wim) wrote: > Sure and we do it for good reasons. Originally this spec should have been= done as per original goal and this was not accomplished. So why would we n= ot try to make it backward compatible if it is easy and possible as I sugge= sted. >=20 > Cheers, > Wim > _________________ > sent from blackberry >=20 > ----- Original Message ----- > From: Keith Moore [mailto:moore@network-heretics.com] > Sent: Saturday, May 26, 2012 01:51 PM > To: Henderickx, Wim (Wim) > Cc: Margaret Wasserman ; pcp@ietf.org ;= draft-ietf-pcp-base@tools.ietf.org > Subject: Re: [pcp] pcp-base-25 >=20 > That's not a valid reason to standardize a specification with serious ide= ntified security flaws. >=20 > Companies that deploy a protocol before the first standard RFC is approve= d should realize that they're taking a gamble that they're very likely to l= ose. >=20 > Keith >=20 > On May 26, 2012, at 6:51 AM, Henderickx, Wim (Wim) wrote: >=20 >>=20 >>=20 >> -----Original Message----- >> From: Margaret Wasserman [mailto:mrw@lilacglade.org]=20 >> Sent: vrijdag 25 mei 2012 22:33 >> To: Henderickx, Wim (Wim) >> Cc: Dan Wing; pcp@ietf.org; draft-ietf-pcp-base@tools.ietf.org >> Subject: Re: [pcp] pcp-base-25 >>=20 >>=20 >> Is there actually deployed base of PCP at this point that we need to be = backwards compatible with? >>=20 >> WH> yes >>=20 >> I am concerned about the idea that we would need to be backwards compati= ble with PCP-24, which doesn't even exist in an easily accessible form now = that PCP-25 has been published. =20 >>=20 >> Margaret >>=20 >>=20 >> On May 25, 2012, at 3:15 PM, Henderickx, Wim (Wim) wrote: >>=20 >>> Dan, if a PCP-25 client is using a nonce which has these 192-224 bits s= et as one of those heuristic values the PCP-24 server would interpret the p= acket wrongly. >>>=20 >>> The option is much better for backward compatibility and lets make it m= andatory to ensure it is included in the MAP/PEER opcodes >>>=20 >>> -----Original Message----- >>> From: Dan Wing [mailto:dwing@cisco.com]=20 >>> Sent: vrijdag 25 mei 2012 17:25 >>> To: Henderickx, Wim (Wim); pcp@ietf.org >>> Cc: draft-ietf-pcp-base@tools.ietf.org >>> Subject: RE: [pcp] pcp-base-25 >>>=20 >>>> -----Original Message----- >>>> From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] >>>> Sent: Friday, May 25, 2012 5:33 AM >>>> To: Dan Wing; pcp@ietf.org >>>> Cc: draft-ietf-pcp-base@tools.ietf.org >>>> Subject: RE: [pcp] pcp-base-25 >>>>=20 >>>> Dan, >>>>=20 >>>> Can we not add the Nonce in an option iso in the MAP/PEER messages? >>>> This will provide easier backward compatibility with existing >>>> implementations. >>>=20 >>> It's mandatory in order to make it difficult for an off-path attacker >>> to spoof the PCP server. If it's optional in the specification, it >>> will be optional in implementations -- weakening the protocol (bad) >>> and adding permanent, long-term interop complexity (bad). >>>=20 >>>=20 >>> I do understand there are pre-RFC implementations in the field, and >>> I believe they can be accommodated by a PCP server that understands >>> both -24 and -25. >>>=20 >>> A PCP server, which supports -24 and -25, can differentiate a PCP >>> request as being from a -24 or -25 PCP client by using a heuristic. >>> The heuristic examines bits 192-224 of the MAP opcode request. In=20 >>> -24, those bits are the protocol number and 24 reserved bits which=20 >>> must be 0. In -25, those bits are the first 32 bits of the Mapping=20 >>> Nonce. >>>=20 >>> A -24 client, supporting only TCP and UDP (which I am sure is all >>> that are supported today), will always set those bits to three >>> different values, >>>=20 >>> 0000011000000000000000000000 =3D protocol=3D6=3DTCP >>> 0010001000000000000000000000 =3D protocol=3D17=3DUDP >>> 0000000000000000000000000000 =3D protocol=3Dwildcard >>>=20 >>> any other values in that 32 bit field means it's from a -25 PCP >>> client, because bits 192-224 are the first 32 bits of the Mapping >>> Nonce, which is a random value. This heuristic will fail if the PCP >>> client happens to choose a random value where the first 32 bits are >>> those three values above. >>>=20 >>> A similar heuristic can be used for the PEER opcode. >>>=20 >>> -d >>>=20 >>>=20 >>>> Cheers, >>>> Wim >>>>=20 >>>> -----Original Message----- >>>> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of >>>> Dan Wing >>>> Sent: maandag 21 mei 2012 20:05 >>>> To: pcp@ietf.org >>>> Cc: draft-ietf-pcp-base@tools.ietf.org >>>> Subject: [pcp] pcp-base-25 >>>>=20 >>>> draft-ietf-pcp-base-25 was just submitted. The major changes to the >>>> document >>>> are introduction of Mapping Nonce to MAP and PEER opcodes, which >>>> protects >>>> against spoofing of the PCP server, and the restriction of the >>>> THIRD_PARTY >>>> option to networks with ACLs that prevent spoofing of the PCP client. >>>>=20 >>>> Other changes are summarized in the changes section, which is copied >>>> below >>>> for convenience. >>>>=20 >>>> Version -25 is available at >>>> http://tools.ietf.org/html/draft-ietf-pcp-base-25 >>>>=20 >>>> And side-by-side diffs between -24 and -25 are at >>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-base-25.txt >>>>=20 >>>>=20 >>>> If you have feedback, please change the Subject line to something >>>> meaningful. >>>>=20 >>>> -d >>>>=20 >>>> ----- >>>>=20 >>>>=20 >>>> o Clarified the port used by the PCP server when sending >>>> unsolicited >>>> unicast ANNOUNCE. >>>>=20 >>>> o Removed parenthetical comment implying ANNOUNCE was not a normal >>>> Opcode; it is a normal Opcode. >>>>=20 >>>> o Explain that non-PCP-speaking host-based and network-based >>>> firewalls need to allow incoming connections for MAP to work. >>>>=20 >>>> o For race condition with PREFER_FAILURE, clarified that it is the >>>> PCP client's responsibility to delete the mapping if the PCP >>>> client doesn't need the mapping. >>>>=20 >>>> o For table, the NAT64 remote peer is IPv4 (was IPv6). >>>>=20 >>>> o Added a Mapping Nonce field to both MAP and PEER requests and >>>> responses, to protect from off-path attackers spoofing the PCP >>>> server's IP address. >>>>=20 >>>> o Security considerations: added 'PCP is secure against off-path >>>> attackers who can spoof the PCP server's IP address', because of >>>> the addition of the Mapping Nonce. >>>>=20 >>>> o Removed reference to DS-Lite from Security Considerations, as >>>> part >>>> of the changes to THIRD_PARTY from IESG review. >>>>=20 >>>> o Rapid Recovery is now a SHOULD implement. >>>>=20 >>>> o Clarify behavior of PREFER_FAILURE with zeros in Suggested >>>> External Port or Address fields. >>>>=20 >>>> o PCP server is now more robust and insistent about informing PCP >>>> client of state changes. >>>>=20 >>>> o When PCP server sends Mapping Update to a specific PCP client, >>>> and >>>> gets an update for a particular mapping, it doesn't need to send >>>> reminders about that mapping any more. >>>>=20 >>>> o THIRD_PARTY is now prohibited on subscriber PCP clients. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> pcp mailing list >>>> pcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcp >>>=20 >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From hartmans@painless-security.com Wed May 30 10:45:31 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C124021F8621 for ; Wed, 30 May 2012 10:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAwsOculFa4p for ; Wed, 30 May 2012 10:45:31 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4D58621F861A for ; Wed, 30 May 2012 10:45:30 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id F099620341; Wed, 30 May 2012 13:45:27 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1ECB04151; Wed, 30 May 2012 13:45:29 -0400 (EDT) From: Sam Hartman To: "Henderickx\, Wim \(Wim\)" References: <02b301cd377c$31925b40$94b711c0$@com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF450809@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Date: Wed, 30 May 2012 13:45:29 -0400 In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702DF450809@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> (Wim Henderickx's message of "Fri, 25 May 2012 14:32:42 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "pcp@ietf.org" , "draft-ietf-pcp-base@tools.ietf.org" Subject: Re: [pcp] pcp-base-25 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 17:45:31 -0000 >>>>> "Henderickx," == Henderickx, Wim (Wim) writes: Henderickx,> Dan, Can we not add the Nonce in an option iso in the Henderickx,> MAP/PEER messages? This will provide easier backward Henderickx,> compatibility with existing implementations. Hi. I support Margaret's concern. In addition, we want the nonce for all message types defined in the future not just peer/map. It's possible that some future message we'll define will not have a need for a nonce because there is no value at all to being able to generate it off-path. However, performing that security analysis is tricky, tends to miss possible attack vectors. Architecturally I don't think an option is the right approach for a field that we want in all messages. From wim.henderickx@alcatel-lucent.com Wed May 30 10:48:32 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D70521F8627 for ; Wed, 30 May 2012 10:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.885 X-Spam-Level: X-Spam-Status: No, score=-9.885 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlkHakbzrJd8 for ; Wed, 30 May 2012 10:48:31 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id B89B521F8622 for ; Wed, 30 May 2012 10:48:30 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q4UHmQA3001883 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 May 2012 19:48:27 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 30 May 2012 19:48:26 +0200 From: "Henderickx, Wim (Wim)" To: Sam Hartman Date: Wed, 30 May 2012 19:48:25 +0200 Thread-Topic: [pcp] pcp-base-25 Thread-Index: Ac0+jAO95WM30FIWQW+D9xRwWEF0agAAB1iw Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702DF51B268@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <02b301cd377c$31925b40$94b711c0$@com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF450809@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "pcp@ietf.org" , "draft-ietf-pcp-base@tools.ietf.org" Subject: Re: [pcp] pcp-base-25 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 17:48:32 -0000 Sam, look at some later emails. I agree that doing an option is probably th= e wrong solution. What I proposed is using a bit of the reserved field (non= ce bit) and keep the nonce where it is. -----Original Message----- From: Sam Hartman [mailto:hartmans@painless-security.com]=20 Sent: woensdag 30 mei 2012 19:45 To: Henderickx, Wim (Wim) Cc: Dan Wing; pcp@ietf.org; draft-ietf-pcp-base@tools.ietf.org Subject: Re: [pcp] pcp-base-25 >>>>> "Henderickx," =3D=3D Henderickx, Wim (Wim) writes: Henderickx,> Dan, Can we not add the Nonce in an option iso in the Henderickx,> MAP/PEER messages? This will provide easier backward Henderickx,> compatibility with existing implementations. Hi. I support Margaret's concern. In addition, we want the nonce for all message types defined in the future not just peer/map. It's possible that some future message we'll define will not have a need for a nonce because there is no value at all to being able to generate it off-path. However, performing that security analysis is tricky, tends to miss possible attack vectors. Architecturally I don't think an option is the right approach for a field that we want in all messages. From hartmans@painless-security.com Wed May 30 11:13:37 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB3611E80F5 for ; Wed, 30 May 2012 11:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCfZfIi7xO3K for ; Wed, 30 May 2012 11:13:37 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5AA11E80F3 for ; Wed, 30 May 2012 11:13:37 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D9FFC20341; Wed, 30 May 2012 14:13:34 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EC5D34151; Wed, 30 May 2012 14:13:35 -0400 (EDT) From: Sam Hartman To: "Henderickx\, Wim \(Wim\)" References: <02b301cd377c$31925b40$94b711c0$@com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF450809@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF51B268@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Date: Wed, 30 May 2012 14:13:35 -0400 In-Reply-To: <14C7F4F06DB5814AB0DE29716C4F6D6702DF51B268@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> (Wim Henderickx's message of "Wed, 30 May 2012 19:48:25 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "pcp@ietf.org" , "draft-ietf-pcp-base@tools.ietf.org" Subject: Re: [pcp] pcp-base-25 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 18:13:38 -0000 >>>>> "Henderickx," == Henderickx, Wim (Wim) writes: Henderickx,> Sam, look at some later emails. I agree that doing an Henderickx,> option is probably the wrong solution. What I proposed Henderickx,> is using a bit of the reserved field (nonce bit) and Henderickx,> keep the nonce where it is. -----Original Message----- I saw that mail but didn't understand it until this explanation. I neither object to nor support that solution. I think I understand it well enough that it won't cause any problems. However other than in a security capacity I haven't been involved in PCP enough that I'd feel comfortable explicitly supporting it. --Sam From wim.henderickx@alcatel-lucent.com Wed May 30 12:17:35 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4A921F8630 for ; Wed, 30 May 2012 12:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.916 X-Spam-Level: X-Spam-Status: No, score=-9.916 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxXaxpesa+w5 for ; Wed, 30 May 2012 12:17:34 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 67CEC21F8627 for ; Wed, 30 May 2012 12:17:34 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q4UJHTHO021738 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 May 2012 21:17:30 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 30 May 2012 21:17:29 +0200 From: "Henderickx, Wim (Wim)" To: Sam Hartman Date: Wed, 30 May 2012 21:17:28 +0200 Thread-Topic: [pcp] pcp-base-25 Thread-Index: Ac0+kAbcLQmS8r2HS8KMoOdyC+3uHgACMKtg Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702DF51B27A@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <02b301cd377c$31925b40$94b711c0$@com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF450809@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <14C7F4F06DB5814AB0DE29716C4F6D6702DF51B268@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "pcp@ietf.org" , "draft-ietf-pcp-base@tools.ietf.org" Subject: Re: [pcp] pcp-base-25 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 19:17:35 -0000 Sam, understand. Lets have the PCP experts comment on the proposal. Sorry f= or not being clear in the beginning. -----Original Message----- From: Sam Hartman [mailto:hartmans@painless-security.com]=20 Sent: woensdag 30 mei 2012 20:14 To: Henderickx, Wim (Wim) Cc: Dan Wing; pcp@ietf.org; draft-ietf-pcp-base@tools.ietf.org Subject: Re: [pcp] pcp-base-25 >>>>> "Henderickx," =3D=3D Henderickx, Wim (Wim) writes: Henderickx,> Sam, look at some later emails. I agree that doing an Henderickx,> option is probably the wrong solution. What I proposed Henderickx,> is using a bit of the reserved field (nonce bit) and Henderickx,> keep the nonce where it is. -----Original Message----- I saw that mail but didn't understand it until this explanation. I neither object to nor support that solution. I think I understand it well enough that it won't cause any problems. However other than in a security capacity I haven't been involved in PCP enough that I'd feel comfortable explicitly supporting it. --Sam