From mrw@lilacglade.org Sun Apr 1 04:57: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 16DDA21F8645 for ; Sun, 1 Apr 2012 04:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[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 J-dexgNXRARs for ; Sun, 1 Apr 2012 04:57:17 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 34D4221F861B for ; Sun, 1 Apr 2012 04:57:17 -0700 (PDT) Received: from [10.36.0.36] (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id D45C62032E; Sun, 1 Apr 2012 07:56:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B4EB9B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Sun, 1 Apr 2012 07:57:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3030A725-EC01-4C51-874D-B19800C27859@lilacglade.org> References: <9B57C850BB53634CACEC56EF4853FF653B4EB9B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> To: Dave Thaler X-Mailer: Apple Mail (2.1084) Cc: "pcp@ietf.org" , Stephen Farrell Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised 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, 01 Apr 2012 11:57:18 -0000 Personally, I don't see the value in splitting THIRD_PARTY into two = separate option codes that do exactly the same thing. What is the = difference between having two different option codes, and having one = option code that is restricted to be used either in safe situations OR = with cryptographic security? How can a PCP Server know when it is running in a trusted environment, = anyway? 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 = document. - Add text to the place in the PCP spec where THIRD_PARTY is defined to = state 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. The ACL SHOULD contain a list of PCP Clients (by internal = IP Address) that are allowed to send the THIRD_PARTY option, and a list = of addresses or address ranges for which each authorized PCP Client can = issue THIRD_PARTY requests. - Add text to the Security Considerations section that the use of = THIRD_PARTY without a cryptographic security mechanism opens various = attack vectors, and that THIRD_PARTY should only be enabled without = cryptographic security in environments where the authorized PCP = Client(s) and the PCP Server are under the same administrative control = AND where there is some form of protection against address spoofing, = such as layer 2 security or another type of restricted network access. Stephen would that work for you? 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. >=20 > The proposal is to split how we think about THIRD_PARTY into two > separate options with different Option Codes (though the rest of=20 > the option format may be identical), one in the base spec and one > moved out of it. Specifically: >=20 > * 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 = typical > 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=20 > unblock the deployments of the people who objected to the=20 > "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. >=20 > * 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. >=20 > With appropriate wordsmithing, is this approach something we > can quickly get consensus on? >=20 > -Dave >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Mon Apr 2 01:33:28 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 E9E2A21F8940 for ; Mon, 2 Apr 2012 01:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ozmquko8JLwO for ; Mon, 2 Apr 2012 01:33:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8717921F893D for ; Mon, 2 Apr 2012 01:33:27 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 1CBCE22C584; Mon, 2 Apr 2012 10:33:26 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id EE739238072; Mon, 2 Apr 2012 10:33:25 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 2 Apr 2012 10:33:26 +0200 From: To: Margaret Wasserman , Dave Thaler Date: Mon, 2 Apr 2012 10:33:24 +0200 Thread-Topic: [pcp] WG last call on draft-ietf-pcp-dhcp-02 Thread-Index: Ac0OmCdU9WNvj1aCQ7uDQC/og90RvgAAjKAI Message-ID: <94C682931C08B048B7A8645303FDC9F36E28805EDE@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B4EBA16@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>, <197DC2D6-8322-4592-B0CE-D73EAE6D0B01@lilacglade.org> In-Reply-To: <197DC2D6-8322-4592-B0CE-D73EAE6D0B01@lilacglade.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.3.21.123317 Cc: "pcp@ietf.org" Subject: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02 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, 02 Apr 2012 08:33:29 -0000 Dear Margaret Thank you for the review. Please see inline. Cheers, Med ________________________________________ De : pcp-bounces@ietf.org [pcp-bounces@ietf.org] de la part de Margaret Was= serman [mrw@lilacglade.org] Date d'envoi : vendredi 30 mars 2012 19:11 =C0 : Dave Thaler Cc : pcp@ietf.org Objet : Re: [pcp] WG last call on draft-ietf-pcp-dhcp-02 I have read draft-ietf-pcp-dhcp-02. I support specification of a DHCP opti= on to configure hosts with the name(s) of their PCP Server(s), but I think = there are any issues with this document that need to be addressed before pu= blication. My detailed comments are included below, but I'll start with a = couple of general comments. This document _way_ oversteps what should be defined in a DHCP option, pros= cribing quite a bit of operational behaviour of the PCP server including: = how to handle multiple PCP servers, how to handle retransmissions, etc. M= ore than half of the information in this document does not belong here. Med: This section has been added as requested by D. Thaler. A text has been= proposed for integration in -02. Please see the mailing list archives. Also, there is a lengthy discussion in this document of whether to use IP A= ddresses or Names, and I don't understand any of that.=20 Med: We had that discussion last year in PCP and Softwire. If I remember we= ll R. Droms suggested documenting this would be useful.=20 There are a number of DHCP options that contain server lists, and those se= rvers can be represented by either IP addresses or names. For an example o= f a good DHCP option definition along those lines, please see the NTP DHCP = Option (RFC 5908). IMO, it would be much better to produce a PCP Server DH= CP Option based on the NTP DHCP Option than to do it as described in this d= ocument. Med: We added that discussion section to explain the rationale behind the c= hoice of defining a name option instead of the IP Address. We had a lengthy discussion about this issue; please refer to http://www.ie= tf.org/mail-archive/web/dhcwg/current/msg11297.html for example or Softwire= ML archives (search for draft-ietf-softwire-ds-lite-tunnel-option-05). DHC= WG and IESG were against defining two options to convey the same informati= on. First version of draft-*-pcp-dhcp defines both IP Address and Name but = as a conclusion to those discussion we maintained the Name Option. 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 the document (ad= dresses vs. names). To resolve this issue I would suggest: OLD: This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) Server addresses. NEW: This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) Server names. Med: Done. Thanks. (2) Introduction: This option does not provide anything about "reachabilit= y information", it provisions a list of PCP Servers on a host. The DHCP se= rver won't know anything about whether those Servers are reachable at any g= iven time, or from any given place on the network, so it can't convey that = information. To resolve this issue I would suggest: OLD: This document defines DHCPv4 [RFC2131] and DHCPv6 [RFC3315] options which can be used to provision PCP Server [I-D.ietf-pcp-base] reachability information; more precisely it defines DHCP options to convey 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. Thanks.=20 (3) Section 3: Configuration of a list of servers is quite common, and it d= oes not require a lengthy rationale, nor is it valuable to invent a new way= to do it. This section describes an operational model that is not pertine= nt to many uses of PCP, and I am concerned that by describing this model, w= e could give the impression that the IETF is condoning, or even encouraging= , the type of "organization" described. I am not sure why we would want to= do that. Also, since we are moving the DS-Lite stuff out of the Base Spec= , discussing "the DS-Lite Use Case" for PCP as we do here would require a r= eference to the new spec, and I don't think 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 Addres= ses, like the NTP Server option (RFC 5908). Med: See above. DHC WG is against defining two options for provisioning the= same information. Please refer to the discussion we had about this point i= n the PCP and Softwires mailing list Archives. (4) Section 4: There are a number of problems with this section. (4a) It is possible to return more than one PCP Server name in the list, an= d it is possible that there will be more than one PCP controlled device on = a hosts outbound path. So, the first statement in this section is simplist= ic... Is the applicability of this option 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. If not, I think you need to = say something else. Med: this section says: discovered PCP server must control devices which wi= ll be in the data path of packets destined/sourced from the requesting host= . Could you be more explicit and precise the concern you have with that tex= t? (4b) What is "any terminal belonging to the same realm"? "Terminal" and "r= ealm" aren't words that apply in a typical IP networking case, and it is un= clear what is meant here. Med: What about "any terminal connected to a Customer Premise Equipment (CP= E)"?=20 (4c) What is a CP Router? Do you mean a customer-premise router? If so, y= ou 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 thi= s option is used to configure a router, is it assumed that the router will = pass this information on to its internal hosts? Or that it will serve as a= PCP proxy for them? Med: Changed "CP Router" to "Customer Premise Equipment (CPE)".=20 (4d) "Customers" will experience "service troubles" and their "service(s) w= on't be delivered appropriately" is a bit obscure.... I also wonder why this section exists in this document at all, since it see= ms more like general advice on how to deal with a situation where a PCP Ser= ver isn't co-resident with the device it controls than anything having to d= o 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: This section is non-normative. I can remove this section if there is n= o objection. (5) Section 5: This section doesn't make sense to me, as written. You hav= e described two operational models, but IMO they muddle 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 t= he name). IMO, you need to make a decision here... =20 Med: There is no decision to make here: both parallel and sequential modes = are valid models. A PCP Client may contact all receives PCP Servers or only= one single server in the same time. This is deployment-specific.=20 Do you want to treat each IP Address returned from name resolution as a sep= arate PCP 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 nam= e, on server) in section 5.1 and the former (one address, one server) in se= ction 5.2. This doesn't make any sense to me. Med: The current text assumes each name option is treated as separate PCP S= erver. I *think* what you want to do is to allow multiple DHCP Server names to ind= icate multiple servers that should be used in parallel (to cover the case w= here a site is multi-homed), and that you want clients to use each set of I= P addresses as alternate ways to reach each of those servers, but that is n= ot what this section says. Also, why do you describe a PCP retransmission algorithm here in the DHCP s= pec? Med: The base spec does not only cover the case where only ONE PCP Server i= s configured. This text specifies the behaviour to follow when a list of IP= addresses are configured.=20 All you want to do in the DHCP spec is describe how a node gets its configu= ration information through DHCP. You don't want to describe how PCP works.= =20 Med: PCP Server Address Selection is out of scope of base spec. The PCP base spec needs to describe how PCP works included what its expecte= d configuration looks like, while remaining neutral on whether that configu= ration is obtained via manual configuration, DHC or other means. Med: FYI, we added this section -02 to handle a comment received from D. Th= aler. I don't have an objection to remove the discussion about PCP Server S= election from this document. I'm fine with both.=20 To address this issue: Construct a DHCP Option that can be used to indicate whether the PCP Server= s in the PCP Server list should be tried in sequence if the prior servers a= re unavailable, or whether they should all be used in parallel. If a more = complicated construct is needed, describe what it is, and I will help you u= nderstand how to represent that in a DHCP option. DO NOT descrive how the PCP Client will work in this option. How does a PC= P Client use multiple servers if they are configured statically? Or if the= re are multiple default routers in the default router list. All of this op= erational mode stuff belongs in the PCP base document, not in an DHCP optio= n. (6) Section 6: (6a) The DS-Lite example isn't helpful here. Med: I can remove it. (6b) Also, this option only allows you to configure one DNS name, which doe= sn't match all of section 5. Med: Yes but several OPTION_PCP_SERVER may be returned; see the discussion = in Section 6.2.=20 (6c) This document should not tell you how to configure your DNS server. Med: This is only a "MAY".=20 (6d) When you want to configure a server list, it is typical to include the= server list in one option (as in NTP) not to send multiple options as seem= s to be described in this draft. (6e) I don't even know what to say about the "local cache" of resolved add= resses... Include what TTL? What cache? Med: The issue with names is that a cache of resolved address(es) will be m= aintained by a resolver. If the operator changes the IP address of the PCP = server, the name resolution will always return the OLD IP address. A timer = to flush the resolved IP address(es) must be used. 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 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. (8) There is no link between using DHCPv4 or DHCPv6 and DNS in terms of wha= t IP version will be returned in a name lookup, and I don't see why you wou= ld want to imply that there is. Med: FWIW, this section has been added to address a comment from T. Mrugals= ki. What hurts in that section? _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp From hartmans@painless-security.com Mon Apr 2 03:24:15 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 508EE21F87AF for ; Mon, 2 Apr 2012 03:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=0.866, 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 51VpEblDMZtc for ; Mon, 2 Apr 2012 03:24:15 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id DE05D21F87AD for ; Mon, 2 Apr 2012 03:24:14 -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 A5F0820820; Mon, 2 Apr 2012 06:23:24 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 054564766; Mon, 2 Apr 2012 06:24:10 -0400 (EDT) From: Sam Hartman To: References: <9B57C850BB53634CACEC56EF4853FF653B4EBA16@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <197DC2D6-8322-4592-B0CE-D73EAE6D0B01@lilacglade.org> <94C682931C08B048B7A8645303FDC9F36E28805EDE@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 02 Apr 2012 06:24:09 -0400 In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E28805EDE@PUEXCB1B.nanterre.francetelecom.fr> (mohamed boucadair's message of "Mon, 2 Apr 2012 10:33:24 +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: Margaret Wasserman , "pcp@ietf.org" Subject: Re: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02 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, 02 Apr 2012 10:24:15 -0000 So, I'll note that recently a working group I chaired tried to represent a server as a name not an IP address. The DHCP working group objected strongly enough that we had to revert to IP address based specification. I'd expect the same issue to happen here. From mrw@lilacglade.org Mon Apr 2 03:34:48 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 C957C21F893E for ; Mon, 2 Apr 2012 03:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[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 Iuhouk4o0o9j for ; Mon, 2 Apr 2012 03:34:48 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 57F9F21F88E2 for ; Mon, 2 Apr 2012 03:34:48 -0700 (PDT) Received: from [10.36.0.36] (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 8ED7F202D8; Mon, 2 Apr 2012 06:33:57 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: Date: Mon, 2 Apr 2012 06:34:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B57C850BB53634CACEC56EF4853FF653B4EBA16@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <197DC2D6-8322-4592-B0CE-D73EAE6D0B01@lilacglade.org> <94C682931C08B048B7A8645303FDC9F36E28805EDE@PUEXCB1B.nanterre.francetelecom.fr> To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: "pcp@ietf.org" Subject: Re: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02 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, 02 Apr 2012 10:34:48 -0000 On Apr 2, 2012, at 6:24 AM, Sam Hartman wrote: > So, I'll note that recently a working group I chaired tried to = represent > a server as a name not an IP address. > The DHCP working group objected strongly enough that we had to revert = to > IP address based specification. > I'd expect the same issue to happen here. Recent, widely-used DHCP Server options I'm aware of, like the NTP = Server Option, allow you to send either a FQDN or an IP address in the = same option format. I think that's still the best choice, as it allows = maximum flexibility for the administrator at little cost in terms of = option complexity/length. Margaret From mrw@lilacglade.org Mon Apr 2 03:56: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 D812D21F8812 for ; Mon, 2 Apr 2012 03:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[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 E7pgfRhGPeJf for ; Mon, 2 Apr 2012 03:56:51 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 28C6B21F8816 for ; Mon, 2 Apr 2012 03:56:50 -0700 (PDT) Received: from [10.36.0.36] (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 7F6BD2032E; Mon, 2 Apr 2012 06:55:59 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <4F784863.1030003@cs.tcd.ie> Date: Mon, 2 Apr 2012 06:56:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B57C850BB53634CACEC56EF4853FF653B4EB9B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <3030A725-EC01-4C51-874D-B19800C27859@lilacglade.org> <4F784863.1030003@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) Cc: "pcp@ietf.org" Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised 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, 02 Apr 2012 10:56:52 -0000 On Apr 1, 2012, at 8:21 AM, Stephen Farrell wrote: > 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. I understand. >=20 > In terms of ordering my preferences, most preferred 1st, > that'd be: >=20 > 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 >=20 > I'm not at all fond of #3 but can live with it. I'm not entirely comfortable with this option either, but if it works = for the rest of the WG, I'll document it in the Security Considerations. = Can you help me, though, to understand what the Security Considerations = should say about what constitutes a "safe" environment? And, how a PCP = Server wll know if it is running in a safe environment, or not? What = advices would you give, specifically, to implementors to help them = decide whether to implement the new UNSECURE_THIRD_PARTY option, and = when it would be safe to turn it on? > 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). Oh, I understand what you are hoping for now... Maybe, once we have a = secure THIRD_PARTY option available, everyone will realize that they = don't want to support the UNSECURE_THIRD_PARTY option? I guess I think = that the same thing could happen without having two options, where = implementation start checking that it has been received in a secure = message/ It isn't particularly _expensive_ to define another option, = though, so I guess I can deal with that. I do have some concern that once an UNSECURE_THIRD_PARTY option is = available, the WG might have little motivation to define a more secure = one... I guess I can increase the chances of that happening, though, by = working with folks to write it. And maybe I can convince folks that we = should officially deprecate the UNSECURE_THIRD_PARTY option when we do = that... >=20 > - 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. We did accept PCP-Authentication as a WG document in Paris, So, if = there are no new issues raised on the list, we will have a WG -00 in a = couple of weeks. > - 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 Actually, the current THIRD_PARTY option is optional, so there is no = requirement that it MUST be implemented. =20 > - 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. I understand. Thanks for trying to help us move forward here. =20 If you could help me understand how to define a "safe" environment in = the Security Considerations, that would be very helpful. Thanks, Margaret From hartmans@painless-security.com Mon Apr 2 04:26:28 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 7ACB621F8794 for ; Mon, 2 Apr 2012 04:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=0.650, 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 u3a7U6W-E+hz for ; Mon, 2 Apr 2012 04:26:27 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9E72921F8792 for ; Mon, 2 Apr 2012 04:26:27 -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 362F72032E; Mon, 2 Apr 2012 07:25:35 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7F8384766; Mon, 2 Apr 2012 07:26:20 -0400 (EDT) From: Sam Hartman To: Margaret Wasserman References: <9B57C850BB53634CACEC56EF4853FF653B4EBA16@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <197DC2D6-8322-4592-B0CE-D73EAE6D0B01@lilacglade.org> <94C682931C08B048B7A8645303FDC9F36E28805EDE@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 02 Apr 2012 07:26:20 -0400 In-Reply-To: (Margaret Wasserman's message of "Mon, 2 Apr 2012 06:34:50 -0400") 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" Subject: Re: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02 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, 02 Apr 2012 11:26:28 -0000 >>>>> "Margaret" == Margaret Wasserman writes: Margaret> On Apr 2, 2012, at 6:24 AM, Sam Hartman wrote: >> So, I'll note that recently a working group I chaired tried to >> represent a server as a name not an IP address. The DHCP working >> group objected strongly enough that we had to revert to IP >> address based specification. I'd expect the same issue to happen >> here. Margaret> Recent, widely-used DHCP Server options I'm aware of, like Margaret> the NTP Server Option, allow you to send either a FQDN or Margaret> an IP address in the same option format. I think that's Margaret> still the best choice, as it allows maximum flexibility Margaret> for the administrator at little cost in terms of option Margaret> complexity/length. I agree it's the best choice. I wish Kerberos had not gotten pushback to trying to do this and definitely think we should move forward with FQDN/IP address if we are permitted to do so. From mohamed.boucadair@orange.com Mon Apr 2 04:27:28 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 37AA521F88EC for ; Mon, 2 Apr 2012 04:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, 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 eDm1iEAoVX4C for ; Mon, 2 Apr 2012 04:27:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 77EC121F88F5 for ; Mon, 2 Apr 2012 04:27:27 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 93A9D22C72D; Mon, 2 Apr 2012 13:27:25 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 748184C017; Mon, 2 Apr 2012 13:27:25 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 2 Apr 2012 13:27:26 +0200 From: To: Margaret Wasserman , Sam Hartman Date: Mon, 2 Apr 2012 13:27:23 +0200 Thread-Topic: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02 Thread-Index: Ac0QvDtGKrj7201URXC4ZBZTvlUDeQABvhVg Message-ID: <94C682931C08B048B7A8645303FDC9F36E28805FCF@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B4EBA16@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <197DC2D6-8322-4592-B0CE-D73EAE6D0B01@lilacglade.org> <94C682931C08B048B7A8645303FDC9F36E28805EDE@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.2.103315 Cc: "pcp@ietf.org" Subject: Re: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02 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, 02 Apr 2012 11:27:28 -0000 Re-, I was one of the those advocating for defining both an IP Address and Name = (see http://tools.ietf.org/html/draft-bpw-pcp-dhcp-00). We had a similar is= sue in RFC6334, DHC WG objected defining both an IP Address and a Name Opti= on (there was also a DISCUSS from the IESG)(please refer to softwire archiv= es ~October 2010). The same reasons to select the Name option in RFC6334 apply here; I'm not e= xpecting DHC WG and IESG change their position in less than 6 months. Cheers, Med =20 >-----Message d'origine----- >De : Margaret Wasserman [mailto:mrw@lilacglade.org]=20 >Envoy=E9 : lundi 2 avril 2012 12:35 >=C0 : Sam Hartman >Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; pcp@ietf.org >Objet : Re: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02 > > >On Apr 2, 2012, at 6:24 AM, Sam Hartman wrote: >> So, I'll note that recently a working group I chaired tried=20 >to represent >> a server as a name not an IP address. >> The DHCP working group objected strongly enough that we had=20 >to revert to >> IP address based specification. >> I'd expect the same issue to happen here. > >Recent, widely-used DHCP Server options I'm aware of, like the=20 >NTP Server Option, allow you to send either a FQDN or an IP=20 >address in the same option format. I think that's still the=20 >best choice, as it allows maximum flexibility for the=20 >administrator at little cost in terms of option complexity/length. > >Margaret > > >= From mohamed.boucadair@orange.com Mon Apr 2 04:31: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 59C6121F87F1 for ; Mon, 2 Apr 2012 04:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.372, 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 qByzdhwx2ES8 for ; Mon, 2 Apr 2012 04:31:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4529321F87ED for ; Mon, 2 Apr 2012 04:31:45 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id A577218C53A; Mon, 2 Apr 2012 13:31:44 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 6E5C923806C; Mon, 2 Apr 2012 13:31:44 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Mon, 2 Apr 2012 13:31:44 +0200 From: To: Sam Hartman , Margaret Wasserman Date: Mon, 2 Apr 2012 13:31:43 +0200 Thread-Topic: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02 Thread-Index: Ac0Qw3GNKjx5GwW5QWe2e8ygG0faUgAACneA Message-ID: <94C682931C08B048B7A8645303FDC9F36E28805FD2@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B4EBA16@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <197DC2D6-8322-4592-B0CE-D73EAE6D0B01@lilacglade.org> <94C682931C08B048B7A8645303FDC9F36E28805EDE@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.21.123317 Cc: "pcp@ietf.org" Subject: Re: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02 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, 02 Apr 2012 11:31:46 -0000 Dear Sam, We defined both IP Address and FQDN Option in http://tools.ietf.org/html/dr= aft-bpw-pcp-dhcp-00 but we removed the IP Address and based on the experien= ce we had with RFC6334.=20 Saying that, the Name option as defined in draft-ietf-pcp-dhcp allows to co= nvey address literals. Below an excerpt from the draft: o Name is a domain name (as per Section 3.1 of [RFC1035]) that contains one or more labels. In particular, a PCP name may be structured as DNS qualified name or be composed of strings such as can be passed to getaddrinfo (Section 6.1 of [RFC3493]), including address literals, etc. Cheers, Med=20 >-----Message d'origine----- >De : Sam Hartman [mailto:hartmans@painless-security.com]=20 >Envoy=E9 : lundi 2 avril 2012 13:26 >=C0 : Margaret Wasserman >Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; pcp@ietf.org >Objet : Re: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02 > >>>>>> "Margaret" =3D=3D Margaret Wasserman writes: > > Margaret> On Apr 2, 2012, at 6:24 AM, Sam Hartman wrote: > >> So, I'll note that recently a working group I chaired tried to > >> represent a server as a name not an IP address. The=20 >DHCP working > >> group objected strongly enough that we had to revert to IP > >> address based specification. I'd expect the same issue=20 >to happen > >> here. > > Margaret> Recent, widely-used DHCP Server options I'm=20 >aware of, like > Margaret> the NTP Server Option, allow you to send either a FQDN or > Margaret> an IP address in the same option format. I think that's > Margaret> still the best choice, as it allows maximum flexibility > Margaret> for the administrator at little cost in terms of option > Margaret> complexity/length. > >I agree it's the best choice. >I wish Kerberos had not gotten pushback to trying to do this and >definitely think we should move forward with FQDN/IP address if we are >permitted to do so. >= From mohamed.boucadair@orange.com Mon Apr 2 04:47:10 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 D809121F8559 for ; Mon, 2 Apr 2012 04:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=0.248, 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 e6LZ144wNCWH for ; Mon, 2 Apr 2012 04:47:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id DF06721F8927 for ; Mon, 2 Apr 2012 04:47:09 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 9CE0F3B44D4; Mon, 2 Apr 2012 13:47:06 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 75E0E4C024; Mon, 2 Apr 2012 13:47:06 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 2 Apr 2012 13:47:06 +0200 From: To: Dave Thaler , "pcp@ietf.org" Date: Mon, 2 Apr 2012 13:47:04 +0200 Thread-Topic: Confirming consensus from WG meetings: THIRD_PARTY revised Thread-Index: Ac0Og19CMBLvWGdiQCCH4fAtFC8UDgCQZKRA Message-ID: <94C682931C08B048B7A8645303FDC9F36E28805FEB@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B4EB9B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B4EB9B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.2.103315 Cc: Stephen Farrell Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised 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, 02 Apr 2012 11:47:11 -0000 Dear Dave, I don't see the value to define two Options. I'm still convinced we can kee= p the THIRD_PARTY Option in the base spec and clarify the remaining securit= y concerns against it. FWIW, the scenario I'm interested in is: * Provide a user-interface hosted in the CPE.=20 * The user will log into that interface using a login/password * The user is invited to instruct mappings for hosts connected to the CPE. = PCP messages are then generated by the UI. THIRD_PARTY Option is mandatory = to be included otherwise packets can not be forwarded to the internal hosts= . The base spec may emphasis the followings: * The CPE SHOULD disable by default THIRD_PARTY Option * The PCP Server MUST enforce address validation Cheers, Med=20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Dave Thaler >Envoy=E9 : vendredi 30 mars 2012 16:43 >=C0 : pcp@ietf.org >Cc : Stephen Farrell >Objet : [pcp] Confirming consensus from WG meetings:=20 >THIRD_PARTY revised > >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=20 >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=20 >nor a typical > 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=20 > unblock the deployments of the people who objected to the=20 > "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 >= From mohamed.boucadair@orange.com Mon Apr 2 04:51: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 0E61F21F887D for ; Mon, 2 Apr 2012 04:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=0.186, 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 luPz8-Cm+VGT for ; Mon, 2 Apr 2012 04:51:50 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2B05321F8871 for ; Mon, 2 Apr 2012 04:51:50 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 90F4B22C836; Mon, 2 Apr 2012 13:51:49 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 74D6523804B; Mon, 2 Apr 2012 13:51:49 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Mon, 2 Apr 2012 13:51:49 +0200 From: To: Margaret Wasserman , Dave Thaler Date: Mon, 2 Apr 2012 13:51:48 +0200 Thread-Topic: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised Thread-Index: Ac0P/pkmr+t22p5wStK4pKidMUCpZAAyD5AA Message-ID: <94C682931C08B048B7A8645303FDC9F36E28805FF0@PUEXCB1B.nanterre.francetelecom.fr> 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> 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.3.21.123317 Cc: "pcp@ietf.org" , Stephen Farrell Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised 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, 02 Apr 2012 11:51:51 -0000 Re-, The proposal made my Margaret works for me. Cheers, Med=20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Margaret Wasserman >Envoy=E9 : dimanche 1 avril 2012 13:57 >=C0 : Dave Thaler >Cc : pcp@ietf.org; Stephen Farrell >Objet : Re: [pcp] Confirming consensus from WG meetings:=20 >THIRD_PARTY revised > > >Personally, I don't see the value in splitting THIRD_PARTY=20 >into two separate option codes that do exactly the same thing.=20 > What is the difference between having two different option=20 >codes, and having one option code that is restricted to be=20 >used either in safe situations OR with cryptographic security? > >How can a PCP Server know when it is running in a trusted=20 >environment, anyway? I realize that this is mean to be some=20 >shorthand for the DS-Lite case, but it is simply not the case=20 >that all DS-Lite deployments will meet these criteria, since=20 >I've heard discussion of a B4 running on customer-owned=20 >equipment and/or hosts. How can a PCP Server, even if it is=20 >running on a DS-Lite AFTR _know_ that every B4 that tries to=20 >send a THIRD_PARTY option to the server is owned by the same=20 >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=20 >THIRD_PARTY document. > >- Add text to the place in the PCP spec where THIRD_PARTY is=20 >defined to state that it MUST be disabled by default in PCP=20 >Servers, and that it SHOULD NOT be enabled unless an access=20 >control list (ACL) has been configured. The ACL SHOULD=20 >contain a list of PCP Clients (by internal IP Address) that=20 >are allowed to send the THIRD_PARTY option, and a list of=20 >addresses or address ranges for which each authorized PCP=20 >Client can issue THIRD_PARTY requests. > >- Add text to the Security Considerations section that the use=20 >of THIRD_PARTY without a cryptographic security mechanism=20 >opens various attack vectors, and that THIRD_PARTY should only=20 >be enabled without cryptographic security in environments=20 >where the authorized PCP Client(s) and the PCP Server are=20 >under the same administrative control AND where there is some=20 >form of protection against address spoofing, such as layer 2=20 >security or another type of restricted network access. > >Stephen would that work for you? > >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=20 >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. >>=20 >> The proposal is to split how we think about THIRD_PARTY into two >> separate options with different Option Codes (though the rest of=20 >> the option format may be identical), one in the base spec and one >> moved out of it. Specifically: >>=20 >> * 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=20 >nor a typical >> 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=20 >> unblock the deployments of the people who objected to the=20 >> "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. >>=20 >> * 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. >>=20 >> With appropriate wordsmithing, is this approach something we >> can quickly get consensus on? >>=20 >> -Dave >>=20 >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp >= From hartmans@painless-security.com Mon Apr 2 04:57:43 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 E418721F89AD for ; Mon, 2 Apr 2012 04:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.745 X-Spam-Level: X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[AWL=0.520, 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 E7AFmTBEC0KE for ; Mon, 2 Apr 2012 04:57:43 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 775AF21F889F for ; Mon, 2 Apr 2012 04:57:43 -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 26FF520807; Mon, 2 Apr 2012 07:56:53 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7798C4766; Mon, 2 Apr 2012 07:57:38 -0400 (EDT) From: Sam Hartman To: References: <9B57C850BB53634CACEC56EF4853FF653B4EB9B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E28805FEB@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 02 Apr 2012 07:57:38 -0400 In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E28805FEB@PUEXCB1B.nanterre.francetelecom.fr> (mohamed boucadair's message of "Mon, 2 Apr 2012 13:47:04 +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" , Stephen Farrell Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised 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, 02 Apr 2012 11:57:44 -0000 >>>>> writes: > FWIW, the scenario I'm interested in is: > * Provide a user-interface hosted in the CPE. * The user will log > into that interface using a login/password * The user is invited > to instruct mappings for hosts connected to the CPE. PCP messages > are then generated by the UI. THIRD_PARTY Option is mandatory to > be included otherwise packets can not be forwarded to the internal > hosts. Is the CPE also the PCP server in this environment? From christian.jacquenet@orange.com Mon Apr 2 05:00: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 11BF721F8959 for ; Mon, 2 Apr 2012 05:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcYfycjhu5VM for ; Mon, 2 Apr 2012 05:00:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id ECC6A21F89A3 for ; Mon, 2 Apr 2012 05:00:03 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 355563243CC; Mon, 2 Apr 2012 14:00:03 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 1739427C064; Mon, 2 Apr 2012 14:00:03 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 2 Apr 2012 14:00:02 +0200 From: To: Margaret Wasserman , Dave Thaler Date: Mon, 2 Apr 2012 13:58:15 +0200 Thread-Topic: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised Thread-Index: Ac0P/pjpu2u+E1yDTnKydhynuEZ7YwAyTAAg Message-ID: <22883_1333368003_4F7994C3_22883_2910_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15793C856F7@PUEXCB1C.nanterre.francetelecom.fr> 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> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.2.111519 Cc: "pcp@ietf.org" , Stephen Farrell Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised 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, 02 Apr 2012 12:00:05 -0000 Hi, Thanks to Margaret for this proposal, which is fine by me. Cheers, Christian.=20 [snip] I'd rather see us go with a solution like this: - Keep one THIRD_PARTY option, and don't write a separate THIRD_PARTY docum= ent. - Add text to the place in the PCP spec where THIRD_PARTY is defined to sta= te that it MUST be disabled by default in PCP Servers, and that it SHOULD N= OT be enabled unless an access control list (ACL) has been configured. The= ACL SHOULD contain a list of PCP Clients (by internal IP Address) that are= allowed to send the THIRD_PARTY option, and a list of addresses or address= ranges for which each authorized PCP Client can issue THIRD_PARTY requests. - Add text to the Security Considerations section that the use of THIRD_PAR= TY without a cryptographic security mechanism opens various attack vectors,= and that THIRD_PARTY should only be enabled without cryptographic security= in environments where the authorized PCP Client(s) and the PCP Server are = under the same administrative control AND where there is some form of prote= ction against address spoofing, such as layer 2 security or another type of= restricted network access. Stephen would that work for you? Margaret On Mar 30, 2012, at 10:43 AM, Dave Thaler wrote: > Based on the feedback received during the meeting and on this thread=20 > from various people reporting they were blocked on THIRD_PARTY for=20 > deploying PCP for the web portal case, I met with Stephen Farrell=20 > today to report on the WG feedback and have a new proposal for the=20 > WG's review, which Stephen would be okay with if worded properly. >=20 > The proposal is to split how we think about THIRD_PARTY into two=20 > separate options with different Option Codes (though the rest of the=20 > option format may be identical), one in the base spec and one moved=20 > out of it. Specifically: >=20 > * 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 typical > 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=20 > unblock the deployments of the people who objected to the=20 > "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. >=20 > * 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. >=20 > With appropriate wordsmithing, is this approach something we can=20 > quickly get consensus on? >=20 > -Dave >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From wim.henderickx@alcatel-lucent.com Mon Apr 2 05:02:19 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 238FA21F88B0 for ; Mon, 2 Apr 2012 05:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[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 Tgd7ctH6a0PV for ; Mon, 2 Apr 2012 05:02:18 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2239921F889A for ; Mon, 2 Apr 2012 05:02:17 -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 q32C14aC021429 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Apr 2012 14:02:08 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 2 Apr 2012 14:02:03 +0200 From: "Henderickx, Wim (Wim)" To: "mohamed.boucadair@orange.com" , Margaret Wasserman , Dave Thaler Date: Mon, 2 Apr 2012 14:02:02 +0200 Thread-Topic: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised Thread-Index: Ac0P/pkmr+t22p5wStK4pKidMUCpZAAyD5AAAABdyyA= Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D67E52C8AB6@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <9B57C850BB53634CACEC56EF4853FF653B4EB9B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <3030A725-EC01-4C51-874D-B19800C27859@lilacglade.org> <94C682931C08B048B7A8645303FDC9F36E28805FF0@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E28805FF0@PUEXCB1B.nanterre.francetelecom.fr> 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.80 Cc: "pcp@ietf.org" , Stephen Farrell Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised 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, 02 Apr 2012 12:02:19 -0000 +1 -----Original Message----- From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of moham= ed.boucadair@orange.com Sent: maandag 2 april 2012 13:52 To: Margaret Wasserman; Dave Thaler Cc: pcp@ietf.org; Stephen Farrell Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revis= ed Re-, The proposal made my Margaret works for me. Cheers, Med=20 >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Margaret Wasserman >Envoy=E9 : dimanche 1 avril 2012 13:57 >=C0 : Dave Thaler >Cc : pcp@ietf.org; Stephen Farrell >Objet : Re: [pcp] Confirming consensus from WG meetings:=20 >THIRD_PARTY revised > > >Personally, I don't see the value in splitting THIRD_PARTY=20 >into two separate option codes that do exactly the same thing.=20 > What is the difference between having two different option=20 >codes, and having one option code that is restricted to be=20 >used either in safe situations OR with cryptographic security? > >How can a PCP Server know when it is running in a trusted=20 >environment, anyway? I realize that this is mean to be some=20 >shorthand for the DS-Lite case, but it is simply not the case=20 >that all DS-Lite deployments will meet these criteria, since=20 >I've heard discussion of a B4 running on customer-owned=20 >equipment and/or hosts. How can a PCP Server, even if it is=20 >running on a DS-Lite AFTR _know_ that every B4 that tries to=20 >send a THIRD_PARTY option to the server is owned by the same=20 >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=20 >THIRD_PARTY document. > >- Add text to the place in the PCP spec where THIRD_PARTY is=20 >defined to state that it MUST be disabled by default in PCP=20 >Servers, and that it SHOULD NOT be enabled unless an access=20 >control list (ACL) has been configured. The ACL SHOULD=20 >contain a list of PCP Clients (by internal IP Address) that=20 >are allowed to send the THIRD_PARTY option, and a list of=20 >addresses or address ranges for which each authorized PCP=20 >Client can issue THIRD_PARTY requests. > >- Add text to the Security Considerations section that the use=20 >of THIRD_PARTY without a cryptographic security mechanism=20 >opens various attack vectors, and that THIRD_PARTY should only=20 >be enabled without cryptographic security in environments=20 >where the authorized PCP Client(s) and the PCP Server are=20 >under the same administrative control AND where there is some=20 >form of protection against address spoofing, such as layer 2=20 >security or another type of restricted network access. > >Stephen would that work for you? > >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=20 >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. >>=20 >> The proposal is to split how we think about THIRD_PARTY into two >> separate options with different Option Codes (though the rest of=20 >> the option format may be identical), one in the base spec and one >> moved out of it. Specifically: >>=20 >> * 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=20 >nor a typical >> 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=20 >> unblock the deployments of the people who objected to the=20 >> "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. >>=20 >> * 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. >>=20 >> With appropriate wordsmithing, is this approach something we >> can quickly get consensus on? >>=20 >> -Dave >>=20 >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp > _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Mon Apr 2 05:04:00 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 0B96F21F88B0 for ; Mon, 2 Apr 2012 05:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.149, 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 0ER+3LAbBNEB for ; Mon, 2 Apr 2012 05:03:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB7521F8893 for ; Mon, 2 Apr 2012 05:03:59 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id F0A463B437D; Mon, 2 Apr 2012 14:03:58 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id AAC4435C065; Mon, 2 Apr 2012 14:03:58 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 2 Apr 2012 14:03:58 +0200 From: To: Sam Hartman Date: Mon, 2 Apr 2012 14:03:57 +0200 Thread-Topic: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised Thread-Index: Ac0Qx9BH0eNikQ6fROKrU1Fz3N6xEwAAMbPw Message-ID: <94C682931C08B048B7A8645303FDC9F36E2880600E@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B4EB9B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E28805FEB@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.2.111519 Cc: "pcp@ietf.org" , Stephen Farrell Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised 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, 02 Apr 2012 12:04:00 -0000 Re-, No. It behaves only as PCP Client.=20 Cheers, Med=20 >-----Message d'origine----- >De : Sam Hartman [mailto:hartmans@painless-security.com]=20 >Envoy=E9 : lundi 2 avril 2012 13:58 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Dave Thaler; pcp@ietf.org; Stephen Farrell >Objet : Re: [pcp] Confirming consensus from WG meetings:=20 >THIRD_PARTY revised > >>>>>> writes: > > > FWIW, the scenario I'm interested in is: > > > * Provide a user-interface hosted in the CPE. * The=20 >user will log > > into that interface using a login/password * The user is invited > > to instruct mappings for hosts connected to the CPE. PCP messages > > are then generated by the UI. THIRD_PARTY Option is mandatory to > > be included otherwise packets can not be forwarded to=20 >the internal > > hosts. > >Is the CPE also the PCP server in this environment? >= From hartmans@painless-security.com Mon Apr 2 05:18: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 8FEE621F86E5 for ; Mon, 2 Apr 2012 05:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.433, 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 fiRVUiTJCl-I for ; Mon, 2 Apr 2012 05:18:02 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2973821F86A2 for ; Mon, 2 Apr 2012 05:18:02 -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 849542032E; Mon, 2 Apr 2012 08:17:11 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A5EA24766; Mon, 2 Apr 2012 08:17:56 -0400 (EDT) From: Sam Hartman To: References: <9B57C850BB53634CACEC56EF4853FF653B4EB9B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E28805FEB@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E2880600E@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 02 Apr 2012 08:17:56 -0400 In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E2880600E@PUEXCB1B.nanterre.francetelecom.fr> (mohamed boucadair's message of "Mon, 2 Apr 2012 14:03:57 +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=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: "pcp@ietf.org" , Stephen Farrell Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised 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, 02 Apr 2012 12:18:02 -0000 >>>>> writes: Hi. As I recall the ds-lite case has been ruled out of scope for a future document. I'd like to understand two things. 1) What is the use case where the CPE is a PCP client but we are not using ds-lite? 2) Can you please walk through the analysis of the simple security model for your use case and explain how we know that the third party option will not introduce new vulnerabilities beyond those permitted by implicit mappings? Thanks, --Sam > Re-, No. It behaves only as PCP Client. > Cheers, Med >> -----Message d'origine----- De : Sam Hartman >> [mailto:hartmans@painless-security.com] Envoyé : lundi 2 avril >> 2012 13:58 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Dave >> Thaler; pcp@ietf.org; Stephen Farrell Objet : Re: [pcp] >> Confirming consensus from WG meetings: THIRD_PARTY revised >> >>>>>>> writes: >> >> > FWIW, the scenario I'm interested in is: >> >> > * Provide a user-interface hosted in the CPE. * The user will >> log > into that interface using a login/password * The user is >> invited > to instruct mappings for hosts connected to the >> CPE. PCP messages > are then generated by the UI. THIRD_PARTY >> Option is mandatory to > be included otherwise packets can not be >> forwarded to the internal > hosts. >> >> Is the CPE also the PCP server in this environment? >> From mohamed.boucadair@orange.com Mon Apr 2 05:55: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 8C64C21F86BA for ; Mon, 2 Apr 2012 05:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.124, 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 c2vrMMGR9sxa for ; Mon, 2 Apr 2012 05:55:07 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id C868421F86B6 for ; Mon, 2 Apr 2012 05:55:06 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id B594A18C3B9; Mon, 2 Apr 2012 14:55:05 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 7F4BA4C066; Mon, 2 Apr 2012 14:55:05 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 2 Apr 2012 14:55:05 +0200 From: To: Sam Hartman Date: Mon, 2 Apr 2012 14:55:03 +0200 Thread-Topic: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised Thread-Index: Ac0Qyqburd+68evaTyqTTsk0Veck6wAAuu5w Message-ID: <94C682931C08B048B7A8645303FDC9F36E28806080@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B4EB9B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E28805FEB@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E2880600E@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.21.123317 Cc: "pcp@ietf.org" , Stephen Farrell Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised 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, 02 Apr 2012 12:55:07 -0000 Re-, The current situation is there are no (yet) PCP-enabled applications so we = would have a bootstrapping issue: provide means to subscribers to control t= heir mappings in PCP-controlled devices without requiring all applications/= hosts be PCP-enabled. A PCP-controlled device can be a CGN (NAT44), a DS-Li= te AFTR or a NAT64. This issue can be met by combining one or all of the following pieces: * Provide a user-interface to control the mapping (we already have such por= t forwarding interface). This interface will be modified to trigger PCP mes= sages. For this case, the internal IP address is not the same as the addres= s of the PCP client; THIRD_PARTY Option is needed. * Enable a IGD/PCP Interworking function * Enable a PCP Proxy If we consider the three deployments I mentioned above: CGN (NAT44), DS-Lit= e AFTR and NAT64. The PCP Server can enforce policies to validate the conte= nt of the THIRD_PARTY Option: * DS-Lite AFTR case: the THIRD_PARTY Option MUST embed a private IP address= . This is the same validation for implicit mappings. * NAT64 case: The THIRD_PARTY Option and the source IP address of the PCP C= lient MUST belong to the same IPv6 prefix (e.g. /56). This is the same cons= traint as for implicit mapping Please let me know if I answered your question. Cheers, Med=20 >-----Message d'origine----- >De : Sam Hartman [mailto:hartmans@painless-security.com]=20 >Envoy=E9 : lundi 2 avril 2012 14:18 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Dave Thaler; pcp@ietf.org; Stephen Farrell >Objet : Re: [pcp] Confirming consensus from WG meetings:=20 >THIRD_PARTY revised > >>>>>> writes: > >Hi. >As I recall the ds-lite case has been ruled out of scope for a future >document. > >I'd like to understand two things. >1) What is the use case where the CPE is a PCP client but we are not >using ds-lite? > >2) Can you please walk through the analysis of the simple=20 >security model >for your use case and explain how we know that the third party option >will not introduce new vulnerabilities beyond those permitted by >implicit mappings? > >Thanks, >--Sam > > > > Re-, No. It behaves only as PCP Client. > > > Cheers, Med > > >> -----Message d'origine----- De : Sam Hartman > >> [mailto:hartmans@painless-security.com] Envoy=E9 : lundi 2 avril > >> 2012 13:58 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Dave > >> Thaler; pcp@ietf.org; Stephen Farrell Objet : Re: [pcp] > >> Confirming consensus from WG meetings: THIRD_PARTY revised > >>=20 > >>>>>>> writes: > >>=20 > >> > FWIW, the scenario I'm interested in is: > >>=20 > >> > * Provide a user-interface hosted in the CPE. * The user will > >> log > into that interface using a login/password * The user is > >> invited > to instruct mappings for hosts connected to the > >> CPE. PCP messages > are then generated by the UI. THIRD_PARTY > >> Option is mandatory to > be included otherwise packets=20 >can not be > >> forwarded to the internal > hosts. > >>=20 > >> Is the CPE also the PCP server in this environment? > >>=20 >= From iljitsch@muada.com Mon Apr 2 08:38:11 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 3E10B21F8645 for ; Mon, 2 Apr 2012 08:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.186 X-Spam-Level: X-Spam-Status: No, score=-100.186 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fhs-clQPdmsc for ; Mon, 2 Apr 2012 08:38:10 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id C2CE921F8653 for ; Mon, 2 Apr 2012 08:38:09 -0700 (PDT) Received: from [IPv6:2001:470:1f0b:1289:1936:3ea0:ccbb:2280] ([IPv6:2001:470:1f0b:1289:1936:3ea0:ccbb:2280]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id q32FbhDf043389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 2 Apr 2012 17:37:46 +0200 (CEST) (envelope-from iljitsch@muada.com) From: Iljitsch van Beijnum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Apr 2012 17:38:01 +0200 Message-Id: To: pcp@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [pcp] review of pcp-base-24 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, 02 Apr 2012 15:38:11 -0000 Here a short^H^H^H^H^H review of the draft. I didn't exhaustively look = at all details, though. (Especially the different calculations.) I = strongly suspect that additional answers can be found in other PCP wg = work and in the previous version discussions, but I didn't look at that = because the document needs to stand on its own and have explicit = pointers to other work when relevant. Let me first say that I like this work a lot and I think it uses the = right approach and philosophy. Section 7.3 on options: Unless I misunderstand this, if an optional option (ha) is present and = the server doesn't understand that option, that's ok. But if the server = does understand the option, and judges it to be malformed, the server = should reject the entire request. So what can happen now is that client A sends a packet with options X = and Y that is handled by server B running version 1 (of the server = software, I'm not talking about the protocol version here). Bv1 doesn't = understand Y so it handles X and A is mostly happy because it gets a = mapping even though some additional feature can't be used. Now B is = upgraded to version 2, and Bv2 finds option Y faulty. So now when A does = what it always did, but the results are different, and not in a good = way. A might be able to work around this by resubmitting a request with only = option X and not option Y, but such behavior is relatively complex and = hard to test, so I don't think it's a good solution. My suggestion: the server silently ignores optional options where the = content of the option is malformed and only sends back an error if the = option header itself (that needs to be parsable to get to the next = option) is malformed, or in the case of mandatory options. In this case, = from the client's perspective, the server behavior is the same whether = the server doesn't implement an option or the server can't parse the = option (because of an issue on either the client or the server). 7.4 on error codes: I think the NO_RESOURCES error should be agnostic about the = well-formedness and validness of the request, an implementation may = decide it has no resources to check for these at this time. Many errors = are still possible for well-formed and valid requests to servers with = ample resources anyway. 8: Perhaps point out that it's also possible that packets are duplicated in = the network relatively easily (on wifi the data packet makes it through = but the layer 2 ACK is lost so the packet is retransmitted) so two = responses to one request will happen with some regularity. 8.1: If the client has to explicitly address requests at a server's unicast = address, how are clients expected to contact servers in the case of CGN = or NAT64? These are multiple hops away and generally not explicitly = known to the hosts they serve. Requiring DHCP(v6) options for this = discovery is highly problematic in my opinion, because in CGN and NAT64 = deployments there will typically be a CPE in the path that would then = have to request the new DHCP option on its WAN side and advertise it on = its LAN side. (Assuming this device supports DHCPv6 on both sides in the = first place!) This is especially problematic because the PCP doesn't = otherwise require the cooperation of such a CPE in at least the NAT64 = case. Also, a PCP client could presumably be implemented as part of an = application on operating systems that don't support a new DHCP option, = and applications may not be in the position to add this support. I know we had a hard time gaining consensus on NAT64 prefix discovery = mechanisms, which is basically the same problem. But getting this right = would make PCP more useful with the CGN/NAT64 use cases by a huge = margin. I would even go so far as to suggest that clients should have the option = to learn one or more PCP server addresses through manual configuration = as a last resort. 8.4: "IPv6 addresses without global reachability (e.g., ULA [ RFC4193 ]), SHOULD NOT be used as the source interface when generating a PCP request." This of course makes it impossible to have PCP work with IPv6 NAT, for = better or for worse. 10.2: An application that is using the same port for outgoing connections as well as incoming connections MUST first signal its operation of a server using the PCP MAP Opcode, as described in=20 Section 11 , and receive a positive PCP response before it sends any packets from that port. As per the discussion follow that paragraph, this optimizes for the case = where the application runs on a host residing behind a PCP-capable = NAT/firewall at the expense of the cases where a NAT/firewall isn't = present or is present but doesn't support either PCP nor endpoint = independent mappings. I don't think that's necessarily the right = tradeoff. But, more importantly, I don't understand the MUST here. Can = someone explain this? It's certainly conceivable that an application could get a strong hint = that PCP is either supported or not supported, and optimize its behavior = accordingly. Also, certain applications may suffer from an initial delay = much more than from the situation where initially incoming sessions = can't be established, and thus prefer to initiate outgoing sessions = without waiting for PCP mappings. Further, in the case of firewalls = there should be no issues creating a mapping after setting up a session, = because port numbers will not be changed. For IPv4 the difference between the NAT and firewall cases can be = determined with a high degree of confidence by the use of RFC 1918 = addresses, while in the case of NAT64 endpoint independent mappings are = specified in the NAT64 spec and as per the above, IPv6 NAT isn't = supported by PCP anyway. So: RFC 1918 -> SHOULD PCP MAP first, ! RFC = 1918 -> SHOULD NOT PCP MAP first. 11.1: Suggested External IP Address: Suggested external IPv4 or IPv6 address. This is useful for refreshing a mapping, especially after the PCP server loses state. If the PCP client does not know the external address, or does not have a preference, it MUST use the address-family-specific all-zeroes address (see=20 Section 5). I wonder if it could be useful to have the ability to specify address = family agnostic mappings? (I'm starting to imagine NAT46 = functionality...) Lifetime (in common header): On an error response, this indicates how long clients should assume they'll get the same error response from the PCP server if they repeat the same request. On a success response, this indicates the lifetime for this mapping, in seconds. Ii think this needs a default that is used when implementers have no = information one way or the other about what value to use here. 5 = minutes? 10? 30? 11.5: o If both the internal port and protocol are zero, it indicates a request to delete all mappings for this Internal Address for all transport protocols. This is useful when a host reboots or joins a new network, to clear out prior stale state from the NAT gateway before beginning to install new mappings. What if multiple PCP client implementations/instances live on the same = host? Unless they compete for the same mappings, that should work = without trouble, but if one of them were to issue a request as per the = above, that would be very destructive. There is also potential for DoS = by other hosts on the same subnet. I would feel more comfortable with this if rather than removing = mappings, the server reduces the remaining lifetime of the existing = mappings and then sends notifications to the clients that requested = these mappings, so that they can refresh them if they're still desired. I don't think this operation is ever appropriate on client = implementations that aren't part of the operating system. 11.6: I think it would make sense to recommend that clients request mappings = with lifetimes that match the lifetimes of the addresses they obtained = through DHCP and/or stateless autoconfig. This way, when an address = expires, the mappings expire at about the same time, avoiding issues if = another host subsequently obtains that address. Note that one source of regular address changes is the use of RFC 4941 = temporary / privacy addresses. Of course in the IPv6 case there are = generally no issues with ports not being available so a deprecated and a = new temporary address could exist side by side and use a mapping to the = same port without issue. 13.2: PCP servers MAY choose to rate-limit their handling of PREFER_FAILURE requests, to protect themselves from a rapid flurry of 65535 consecutive PREFER_FAILURE requests from clients probing to discover which external ports are available. Hm, this reads as an implementation suggestion to clients... Maybe point = out a better way to obtain a port. 13.3. FILTER Option for MAP Opcode This is a DoS attack waiting to happen. I don't think it's a good idea = to allow a feature like this with at least some kind of return = routability check. And even then, one application with little or no = privileges could make the entire internet unreachable for the entire = host. 15.2, 15.3, 15.3.1, 15.3.2: This section provides... Please don't repeat this sentence or a very similar one over and over. = Once for the entire section 15 is enough. 15.3.2: If the client wishes to check the PCP server's Epoch Time, it sends a PCP request for any one of the client's mappings. This will return the current Epoch Time value. Wouldn't it be better if there was a separate message for doing this? = That would save the server from consulting its mapping state, allowing = it to answer such requests very quickly. Does it make sense to reset the epoch when a NAT device loses its = external address? 17.1.1: o If you allow multiple administrative domains to send PCP requests Addressing the reader is uncommon in RFCs. 18.1: PCP will use ports 5350 and 5351 (currently assigned by IANA to NAT- PMP [ I-D.cheshire-nat-pmp]). So what happens when a NAT-PMP client and a PCP server or a PCP client = and NAT-PMP server end up talking to each other? Answer: mention = appendix A here. What about the NAT64 case where mappings are only relevant to/from IPv4 = space mapped by the NAT64, and presumably not to/from other IPv6 space? = Is it useful for the server to indicate that the mappings only apply to = a certain subset of destinations, or should clients simply always = request mappings and then proceed to communicate whether they get the = mappings or not? In support of the former: it may be useful to know that = STUN-like mechanisms are necessary for some, but unnecessary for other = destinations , for instance. Also, if a NAT64 user wants to use a = STUN-like mechanism to learn its externally visible IP address, it would = be good to know which prefix represents the IPv4 address space so it = knows destinations in that prefix see something other than destinations = outside that prefix. From margaretw42@gmail.com Mon Apr 2 09:17: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 EF62C21F8510 for ; Mon, 2 Apr 2012 09:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 HfS2hpqCbEii for ; Mon, 2 Apr 2012 09:17:36 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 110A921F851B for ; Mon, 2 Apr 2012 09:17:36 -0700 (PDT) Received: from [10.36.0.36] (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 73971204BE for ; Mon, 2 Apr 2012 12:16:45 -0400 (EDT) From: Margaret Wasserman Content-Type: multipart/alternative; boundary=Apple-Mail-21-741453624 Date: Mon, 2 Apr 2012 12:17:35 -0400 References: To: pcp@ietf.org Message-Id: <1BE9AC16-7FC6-4F67-A77F-211CBBDB2C27@gmail.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [pcp] Fwd: Comments on draft-wasserman-pcp-authentication-02 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, 02 Apr 2012 16:17:37 -0000 --Apple-Mail-21-741453624 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just FYI -- We received these comments on draft-wasserman-pcp-authentication-02, and = we will attempt to address these issues (where still pertinent) in the = next version of the draft. Margaret Begin forwarded message: > From: Josh Howlett > Date: March 27, 2012 8:58:13 AM EDT > To: Margaret Wasserman , Sam Hartman = , "zhangdacheng@huawei.com" = > Subject: Comments on draft-wasserman-pcp-authentication-02 >=20 > Hi all, >=20 > I just reviewed draft-wasserman-pcp-authentication-02 very quickly; a = few > comments: >=20 > 0. A general point: I think it might be useful to cast the document = more > explicitly in term of a 'secure association protocol' (in the sense of > RFC5247). It would probably make it easier to understand for the EAP > community. >=20 > 1. The Message Type and Session ID fields seem to duplicate the = functions > of EAP's Type and Identifier fields. >=20 > 2. I think you need to specify MTI PRF(s) and MAC(s) for = interoperability. > The text does currently mandate the use of EAP methods that export = MSK, > but it is well hidden! >=20 > 3. EAP methods 'export' MSKs, not 'generate' them. Also RFC3748 does = not > define 'EAP key generating method[s]'; specific EAP methods do. >=20 > 4. I do not know much about PCP, but would it be interesting to return > PCP-related policy using AAA attributes? Would it also be useful to > discuss EAP pass-through? Presumably you would want to avoid = configuring > EAP credentials into routers? >=20 > 5. Could the EAP Reauthentication Protocol be useful here? Or is this = not > expected to be particularly dynamic? >=20 > 6. EAP methods are required to support fragmentation if their payloads = are > likely to exceed the EAP MTU. So I don't think the protocol needs > fragmentation semantics. >=20 > 7. Specifically which offline attacks is the nonce protecting against? >=20 > 8. Why is the EAP Payload Option the only one that MUST be padded? >=20 > 9. I'm a bit confused hot where the options fit into the packet = format. > This is probably best discussed offline! >=20 > Josh. >=20 >=20 >=20 > Janet is a trading name of The JNT Association, a company limited > by guarantee which is registered in England under No. 2881024=20 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG >=20 --Apple-Mail-21-741453624 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: Josh Howlett <Josh.Howlett@ja.net>
=
Date: March 27, 2012 = 8:58:13 AM EDT
Subject: Comments on = draft-wasserman-pcp-authentication-02

Hi = all,

I just reviewed draft-wasserman-pcp-authentication-02 very = quickly; a few
comments:

0. A general point: I think it might = be useful to cast the document more
explicitly in term of a 'secure = association protocol' (in the sense of
RFC5247). It would probably = make it easier to understand for the EAP
community.

1. The = Message Type and Session ID fields seem to duplicate the functions
of = EAP's Type and Identifier fields.

2. I think you need to specify = MTI PRF(s) and MAC(s) for interoperability.
The text does currently = mandate the use of EAP methods that export MSK,
but it is well = hidden!

3. EAP methods 'export' MSKs, not 'generate' them. Also = RFC3748 does not
define 'EAP key generating method[s]'; specific EAP = methods do.

4. I do not know much about PCP, but would it be = interesting to return
PCP-related policy using AAA attributes? Would = it also be useful to
discuss EAP pass-through? Presumably you would = want to avoid configuring
EAP credentials into routers?

5. = Could the EAP Reauthentication Protocol be useful here? Or is this = not
expected to be particularly dynamic?

6. EAP methods are = required to support fragmentation if their payloads are
likely to = exceed the EAP MTU. So I don't think the protocol needs
fragmentation = semantics.

7. Specifically which offline attacks is the nonce = protecting against?

8. Why is the EAP Payload Option the only one = that MUST be padded?

9. I'm a bit confused hot where the options = fit into the packet format.
This is probably best discussed = offline!

Josh.



Janet is a trading name of The JNT = Association, a company limited
by guarantee which is registered in = England under No. 2881024
and whose Registered Office is at Lumen = House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 = 0SG


= --Apple-Mail-21-741453624-- From trac@tools.ietf.org Mon Apr 2 12:55:34 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 DFF3121F872D for ; Mon, 2 Apr 2012 12:55:33 -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 T2441CtV1rws for ; Mon, 2 Apr 2012 12:55:32 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9390721F872B for ; Mon, 2 Apr 2012 12:55:31 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SEnLM-0002HA-ET; Mon, 02 Apr 2012 15:55:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-pcp-dhcp@tools.ietf.org, mrw@lilacglade.org X-Trac-Project: pcp Date: Mon, 02 Apr 2012 19:55:11 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/58 Message-ID: <077.85b119a156bc4cf8903e1fb82de118fa@tools.ietf.org> X-Trac-Ticket-ID: 58 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-dhcp@tools.ietf.org, mrw@lilacglade.org, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120402195532.9390721F872B@ietfa.amsl.com> Resent-Date: Mon, 2 Apr 2012 12:55:31 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: [pcp] #58: DHCP option issues from Margaret Wasserman X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 19:55:34 -0000 #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 this document does not belong here. Also, there is a lengthy discussion in this document of 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 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 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 ================================ Detailed Comments: (1) The Abstract: The text in the abstract does not match the document (addresses vs. names). To resolve this issue I would suggest: OLD: This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) Server addresses. NEW: This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) Server names. (2) Introduction: This option does not provide anything about "reachability information", it provisions a list of PCP 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 network, so it can't convey that information. To resolve this issue I would suggest: OLD: This document defines DHCPv4 [RFC2131] and DHCPv6 [RFC3315] options which can be used to provision PCP Server [I-D.ietf-pcp-base] reachability information; more precisely it defines DHCP options to convey 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. (3) Section 3: Configuration of a list of servrtd is quite common, and it does not require a lengthy rationale, nor is it valuable to invent a new way to to do it. This section describes an operational model that is not pertinent to many uses of PCP, and I am concerned that by describing this model, we could give the impression that the IETF is condoning, or even encouraging, the type of "organization" described. I am not sure why we would want to do that. Also, since we are moving the DS-Lite 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 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). (4) Section 4: There are a number of problems with this section. (4a) It is possible to return more than one PCP Server name in the list, and it is possible that there will be more than one PCP controlled device on a hosts outbound path. So, the first statement in this section is simplistic... Is the applicability of this option 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. If not, I think you need to say something else. (4b) What is "any terminal belonging to the same realm"? "Terminal" and "realm" aren't words that apply in a typical IP networking case, and it is unclear what is meant here. (4c) What is a CP Router? Do you mean a customer-premise 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 assumed that the router will pass this information on to its internal hosts? Or that it will serve as a PCP proxy for them? (4d) "Customers" will experience "service troubles" and their "service(s) won't be delivered appropriately" is a bit obscure.... I also wonder why this section exists in this document at all, since it seems more like general advice on how to deal with a situation where a PCP Server isn't co-resident with the device it controls than 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. (5) Section 5: This section doesn't make sense to me, as written. You have described two operational models, but IMO they muddle 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 treat each IP Address returned from name resolution as a separate PCP 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 section 5.2. This doesn't make any sense to me. I *think* what you want to do is to allow multiple DHCP Server names to indicate multiple servers that should be used in parallel (to cover the case where a site is multi-homed), and that you want clients to use each set of IP addresses as alternate ways to reach each of those servers, but that is not what this section says. Also, why do you describe a PCP retransmission algorithm here 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 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 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 the prior servers are unavailable, or whether they should all be used in parallel. If a more complicated construct is needed, describe what it 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. How does a PCP Client use multiple servers if they are configured 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, not in an DHCP option. (6) Section 6: (6a) The DS-Lite example isn't helpful here. (6b) Also, this option only allows you to configure one DNS name, which doesn't match all of section 5. (6c) This document should not tell you how to configure your DNS server. (6d) When you want to configure a server list, it is typical to include the server list in one option (as in NTP) not to send multiple options as seems to be described in this draft. (6e) I don't even know what to say about the "local cache" of resolved addresses... Include what TTL? What 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 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. (8) There is no link between using DHCPv4 or DHCPv6 and DNS in terms of what IP version will be returned in a name lookup, and I don't see why you would want to imply that there is. -- ----------------------------------------+---------------------------------- Reporter: Margaret Wasserman | Owner: draft-ietf-pcp- Type: defect | dhcp@… Priority: major | Status: new Component: dhcp | Milestone: Severity: - | Version: | Keywords: ----------------------------------------+---------------------------------- Ticket URL: pcp From trac@tools.ietf.org Mon Apr 2 12:59:11 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 3067421F8717 for ; Mon, 2 Apr 2012 12:59:11 -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 JhjrodHogYRc for ; Mon, 2 Apr 2012 12:59:10 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id DD3CC21F8559 for ; Mon, 2 Apr 2012 12:59:09 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SEnP9-0002u4-NK; Mon, 02 Apr 2012 15:59:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-pcp-dhcp@tools.ietf.org X-Trac-Project: pcp Date: Mon, 02 Apr 2012 19:59:07 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/59 Message-ID: <045.31f834615dd5d2df046febdab737d0b1@tools.ietf.org> X-Trac-Ticket-ID: 59 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-dhcp@tools.ietf.org, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: dwing@cisco.com, mohamed.boucadair@orange.com, rpenno@juniper.net Resent-Message-Id: <20120402195909.DD3CC21F8559@ietfa.amsl.com> Resent-Date: Mon, 2 Apr 2012 12:59:09 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: [pcp] #59: DHCP option: name and/or IP address X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 19:59:11 -0000 #59: DHCP option: name and/or IP address Should the option contain a name or IP address? Consensus was that it can contain a string that can be passed to APIs like getaddrinfo. Which means a name or IP address literal string. Recent email exchanges are consistent with that, so entering this one as a closed issue. > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Sam > Hartman > Sent: Monday, April 02, 2012 4:26 AM > To: Margaret Wasserman > Cc: pcp@ietf.org > Subject: Re: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02 >>>>> "Margaret" == Margaret Wasserman writes: Margaret> On Apr 2, 2012, at 6:24 AM, Sam Hartman wrote: >> So, I'll note that recently a working group I chaired tried to >> represent a server as a name not an IP address. The DHCP working >> group objected strongly enough that we had to revert to IP >> address based specification. I'd expect the same issue to happen >> here. Margaret> Recent, widely-used DHCP Server options I'm aware of, like Margaret> the NTP Server Option, allow you to send either a FQDN or Margaret> an IP address in the same option format. I think that's Margaret> still the best choice, as it allows maximum flexibility Margaret> for the administrator at little cost in terms of option Margaret> complexity/length. I agree it's the best choice. I wish Kerberos had not gotten pushback to trying to do this and definitely think we should move forward with FQDN/IP address if we are permitted to do so. _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp -- ---------------------+----------------------------------- Reporter: various | Owner: draft-ietf-pcp-dhcp@… Type: defect | Status: new Priority: major | Milestone: Component: dhcp | Version: Severity: - | Keywords: ---------------------+----------------------------------- Ticket URL: pcp From trac@tools.ietf.org Mon Apr 2 12:59: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 E01B721F8747 for ; Mon, 2 Apr 2012 12:59:46 -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 vYdoZL2zZGIS for ; Mon, 2 Apr 2012 12:59:46 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6345121F8744 for ; Mon, 2 Apr 2012 12:59:46 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SEnPg-0002v1-E8; Mon, 02 Apr 2012 15:59:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-pcp-dhcp@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Mon, 02 Apr 2012 19:59:40 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/59#comment:1 Message-ID: <060.764fed63de1c848468307190f516b71b@tools.ietf.org> References: <045.31f834615dd5d2df046febdab737d0b1@tools.ietf.org> X-Trac-Ticket-ID: 59 In-Reply-To: <045.31f834615dd5d2df046febdab737d0b1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-dhcp@tools.ietf.org, dthaler@microsoft.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120402195946.6345121F8744@ietfa.amsl.com> Resent-Date: Mon, 2 Apr 2012 12:59:46 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #59: DHCP option: name and/or IP address X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 19:59:47 -0000 #59: DHCP option: name and/or IP address Changes (by dthaler@…): * status: new => closed * resolution: => fixed -- ---------------------+------------------------------------ Reporter: various | Owner: draft-ietf-pcp-dhcp@… Type: defect | Status: closed Priority: major | Milestone: Component: dhcp | Version: Severity: - | Resolution: fixed Keywords: | ---------------------+------------------------------------ Ticket URL: pcp From mrw@lilacglade.org Mon Apr 2 14:49:13 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 BD40B21F875A for ; Mon, 2 Apr 2012 14:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[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 I3qAnNZHAZ55 for ; Mon, 2 Apr 2012 14:49:13 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 47DFB21F86AA for ; Mon, 2 Apr 2012 14:49:12 -0700 (PDT) Received: from [10.36.0.36] (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id C96CE20127; Mon, 2 Apr 2012 17:48:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Margaret Wasserman In-Reply-To: <045.31f834615dd5d2df046febdab737d0b1@tools.ietf.org> Date: Mon, 2 Apr 2012 17:49:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5CE08D05-9242-4148-B20B-4887653B15C2@lilacglade.org> References: <045.31f834615dd5d2df046febdab737d0b1@tools.ietf.org> To: "pcp issue tracker" X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-pcp-dhcp@tools.ietf.org, pcp@ietf.org Subject: Re: [pcp] #59: DHCP option: name and/or IP address 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, 02 Apr 2012 21:49:13 -0000 I don't understand how this can be a closed issue for two reasons: (1) The document goes to some length to claim that the option contains a = FQDN and not an IP Address. It then talks about resolving the string = using a resolver, not interpreting it as it would be by getaddrinfo(). (2) A string that could be passed to getaddrinfo() is not the way a = server that could be identified by an FQDN or an IP Address is usually = represented in a DHCP option. Has this option been reviewed by the DHC WG? Or has it been sent to = the DHC WG for parallel review with WGLC? Thanks, Margaret On Apr 2, 2012, at 3:59 PM, pcp issue tracker wrote: > #59: DHCP option: name and/or IP address >=20 > Should the option contain a name or IP address? >=20 > Consensus was that it can contain a string that can be passed to APIs = like > getaddrinfo. Which means a name or IP address literal string. >=20 > Recent email exchanges are consistent with that, so entering this one = as a > closed issue. >=20 >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Sam >> Hartman >> Sent: Monday, April 02, 2012 4:26 AM >> To: Margaret Wasserman >> Cc: pcp@ietf.org >> Subject: Re: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02 >=20 >=20 >>>>>> "Margaret" =3D=3D Margaret Wasserman writes: >=20 > Margaret> On Apr 2, 2012, at 6:24 AM, Sam Hartman wrote: >>> So, I'll note that recently a working group I chaired tried to >>> represent a server as a name not an IP address. The DHCP working >>> group objected strongly enough that we had to revert to IP >>> address based specification. I'd expect the same issue to happen >>> here. >=20 > Margaret> Recent, widely-used DHCP Server options I'm aware of, = like > Margaret> the NTP Server Option, allow you to send either a FQDN = or > Margaret> an IP address in the same option format. I think that's > Margaret> still the best choice, as it allows maximum flexibility > Margaret> for the administrator at little cost in terms of option > Margaret> complexity/length. >=20 > I agree it's the best choice. > I wish Kerberos had not gotten pushback to trying to do this and > definitely think we should move forward with FQDN/IP address if we are > permitted to do so. > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp >=20 > --=20 > ---------------------+----------------------------------- > Reporter: various | Owner: draft-ietf-pcp-dhcp@=85 > Type: defect | Status: new > Priority: major | Milestone: > Component: dhcp | Version: > Severity: - | Keywords: > ---------------------+----------------------------------- >=20 > Ticket URL: > pcp >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From mrw@lilacglade.org Mon Apr 2 14:56:19 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 9F1D521F859F for ; Mon, 2 Apr 2012 14:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[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 hiVrxdw9g85I for ; Mon, 2 Apr 2012 14:56:19 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 59C1B21F864A for ; Mon, 2 Apr 2012 14:56:15 -0700 (PDT) Received: from [10.36.0.36] (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 80F99204BE; Mon, 2 Apr 2012 17:55:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E28805FD2@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 2 Apr 2012 17:56:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B57C850BB53634CACEC56EF4853FF653B4EBA16@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <197DC2D6-8322-4592-B0CE-D73EAE6D0B01@lilacglade.org> <94C682931C08B048B7A8645303FDC9F36E28805EDE@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E28805FD2@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: "pcp@ietf.org" Subject: Re: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02 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, 02 Apr 2012 21:56:19 -0000 Hi Med, On Apr 2, 2012, at 7:31 AM, = wrote: > Dear Sam, >=20 > We defined both IP Address and FQDN Option in = http://tools.ietf.org/html/draft-bpw-pcp-dhcp-00 but we removed the IP = Address and based on the experience we had with RFC6334.=20 >=20 > Saying that, the Name option as defined in draft-ietf-pcp-dhcp allows = to convey address literals. Below an excerpt from the draft: >=20 > o Name is a domain name (as per Section 3.1 of [RFC1035]) that > contains one or more labels. In particular, a PCP name may be > structured as DNS qualified name or be composed of strings such = as > can be passed to getaddrinfo (Section 6.1 of [RFC3493]), = including > address literals, etc. >=20 > Cheers, > Med=20 I can live with this answer -- that the name is a string that may = contain address literals. =20 If this is the way we want to go, though there are still some places in = the document that need to be cleaned up to be consistent with this. Margaret From dthaler@microsoft.com Mon Apr 2 15:23: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 9EDFB21F86B6 for ; Mon, 2 Apr 2012 15:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XyTB9B9Ziyv for ; Mon, 2 Apr 2012 15:23:35 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD6821F86A8 for ; Mon, 2 Apr 2012 15:23:35 -0700 (PDT) Received: from mail133-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.23; Mon, 2 Apr 2012 22:23:34 +0000 Received: from mail133-tx2 (localhost [127.0.0.1]) by mail133-tx2-R.bigfish.com (Postfix) with ESMTP id 882533602AD; Mon, 2 Apr 2012 22:23:34 +0000 (UTC) X-SpamScore: -35 X-BigFish: VS-35(zz9371I542M1432N98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail133-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail133-tx2 (localhost.localdomain [127.0.0.1]) by mail133-tx2 (MessageSwitch) id 1333405412413960_19306; Mon, 2 Apr 2012 22:23:32 +0000 (UTC) Received: from TX2EHSMHS020.bigfish.com (unknown [10.9.14.251]) by mail133-tx2.bigfish.com (Postfix) with ESMTP id 5867E380089; Mon, 2 Apr 2012 22:23:32 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS020.bigfish.com (10.9.99.120) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 2 Apr 2012 22:23:32 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.2.283.4; Mon, 2 Apr 2012 22:23:18 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.253]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0283.004; Mon, 2 Apr 2012 15:23:18 -0700 From: Dave Thaler To: Margaret Wasserman , "mohamed.boucadair@orange.com" Thread-Topic: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02 Thread-Index: AQHNEMNtxJEvWEyMUU+JLCYu4Oeg+JaH3C2AgACufQD//5GzsA== Date: Mon, 2 Apr 2012 22:23:17 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B4F0A09@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B4EBA16@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <197DC2D6-8322-4592-B0CE-D73EAE6D0B01@lilacglade.org> <94C682931C08B048B7A8645303FDC9F36E28805EDE@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E28805FD2@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "pcp@ietf.org" Subject: Re: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02 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, 02 Apr 2012 22:23:36 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Margaret Wasserman > Sent: Monday, April 02, 2012 2:56 PM > To: mohamed.boucadair@orange.com > Cc: pcp@ietf.org > Subject: Re: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02 >=20 > Hi Med, >=20 > On Apr 2, 2012, at 7:31 AM, > wrote: >=20 > > Dear Sam, > > > > We defined both IP Address and FQDN Option in > http://tools.ietf.org/html/draft-bpw-pcp-dhcp-00 but we removed the IP > Address and based on the experience we had with RFC6334. > > > > Saying that, the Name option as defined in draft-ietf-pcp-dhcp allows t= o > convey address literals. Below an excerpt from the draft: > > > > o Name is a domain name (as per Section 3.1 of [RFC1035]) that > > contains one or more labels. In particular, a PCP name may be > > structured as DNS qualified name or be composed of strings such as > > can be passed to getaddrinfo (Section 6.1 of [RFC3493]), including > > address literals, etc. > > > > Cheers, > > Med >=20 > I can live with this answer -- that the name is a string that may contain > address literals. Yes, WG consensus was already that the name is a string that can be passed to APIs such as getaddrinfo, etc. That means it can be an IP litera= l, or an FQDN, or even a non-fully-qualified domain name (though I'm not sure why you'd want to do that, only that no code is expected to be able to filter out such things, and it would just work). I filed an issue in the closed state to track the previous WG consensus on = this. -Dave >=20 > If this is the way we want to go, though there are still some places in t= he > document that need to be cleaned up to be consistent with this. >=20 > Margaret >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Mon Apr 2 23:15: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 36DAC21F86E4 for ; Mon, 2 Apr 2012 23:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.106, 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 SfnNocsh2Fm0 for ; Mon, 2 Apr 2012 23:15:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5750921F86E3 for ; Mon, 2 Apr 2012 23:15:53 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 9E7CE22C3E7; Tue, 3 Apr 2012 08:15:52 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 822C44C024; Tue, 3 Apr 2012 08:15:52 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 3 Apr 2012 08:15:52 +0200 From: To: Margaret Wasserman Date: Tue, 3 Apr 2012 08:15:50 +0200 Thread-Topic: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02 Thread-Index: Ac0RG235+G26Q1iZQCy/upguefQKAQARWfRA Message-ID: <94C682931C08B048B7A8645303FDC9F36E28806266@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B4EBA16@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <197DC2D6-8322-4592-B0CE-D73EAE6D0B01@lilacglade.org> <94C682931C08B048B7A8645303FDC9F36E28805EDE@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E28805FD2@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.21.123317 Cc: "pcp@ietf.org" Subject: Re: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02 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, 03 Apr 2012 06:15:55 -0000 Dear Margaret, There are only two occurrences of FQDN in Section 3 which is non-normative.= I can change them to Name. Thanks. Cheers, Med >-----Message d'origine----- >De : Margaret Wasserman [mailto:mrw@lilacglade.org]=20 >Envoy=E9 : lundi 2 avril 2012 23:56 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Sam Hartman; pcp@ietf.org >Objet : Re: [pcp] RE : WG last call on draft-ietf-pcp-dhcp-02 > > >Hi Med, > >On Apr 2, 2012, at 7:31 AM, =20 > wrote: > >> Dear Sam, >>=20 >> We defined both IP Address and FQDN Option in=20 >http://tools.ietf.org/html/draft-bpw-pcp-dhcp-00 but we=20 >removed the IP Address and based on the experience we had with=20 >RFC6334.=20 >>=20 >> Saying that, the Name option as defined in=20 >draft-ietf-pcp-dhcp allows to convey address literals. Below=20 >an excerpt from the draft: >>=20 >> o Name is a domain name (as per Section 3.1 of [RFC1035]) that >> contains one or more labels. In particular, a PCP name may be >> structured as DNS qualified name or be composed of=20 >strings such as >> can be passed to getaddrinfo (Section 6.1 of=20 >[RFC3493]), including >> address literals, etc. >>=20 >> Cheers, >> Med=20 > >I can live with this answer -- that the name is a string that=20 >may contain address literals. =20 > >If this is the way we want to go, though there are still some=20 >places in the document that need to be cleaned up to be=20 >consistent with this. > >Margaret > > >= From hartmans@painless-security.com Tue Apr 3 04:09:13 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 C2A0321F86D9 for ; Tue, 3 Apr 2012 04:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.371, 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 p9R3AJP5mvc6 for ; Tue, 3 Apr 2012 04:09:13 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAD921F8665 for ; Tue, 3 Apr 2012 04:09:13 -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 82FEE20820; Tue, 3 Apr 2012 07:08:21 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1E1614766; Tue, 3 Apr 2012 07:09:06 -0400 (EDT) From: Sam Hartman To: References: <9B57C850BB53634CACEC56EF4853FF653B4EB9B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E28805FEB@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E2880600E@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E28806080@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 03 Apr 2012 07:09:06 -0400 In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E28806080@PUEXCB1B.nanterre.francetelecom.fr> (mohamed boucadair's message of "Mon, 2 Apr 2012 14:55:03 +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" , Stephen Farrell Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised 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, 03 Apr 2012 11:09:13 -0000 >>>>> writes: > Re-, The current situation is there are no (yet) PCP-enabled > applications so we would have a bootstrapping issue: provide means > to subscribers to control their mappings in PCP-controlled devices > without requiring all applications/hosts be PCP-enabled. A > PCP-controlled device can be a CGN (NAT44), a DS-Lite AFTR or a > NAT64. > This issue can be met by combining one or all of the following > pieces: > * Provide a user-interface to control the mapping (we already have > such port forwarding interface). This interface will be modified > to trigger PCP messages. For this case, the internal IP address is > not the same as the address of the PCP client; THIRD_PARTY Option > is needed. * Enable a IGD/PCP Interworking function * Enable a > PCP Proxy Hi. He believes that even for a solution like Margaret proposes, we'd need to explicitly restrict against implementing the base spec third party option for CPE or enterprise equipment. It would look a lot more like the third-party option for trusted networks Dave proposed on Friday than what Margaret described. So, it would not help the use case you have. I think the third-party option would need a mandatory-to-implement security mechanism for Stephen to be comfortable with your use case above. So, I believe the solutions you've been supporting in the last few days are solutions that the IESG would not approve. What I'd like to understand is who in the WG believes it is worth delaying the base spec for the portal use case. The portal use case is one where the PCP server is running on ISP equipment (CGN for example). The ISP runs a website on their servers (not CPE) that allows users to log in with some ISP-issued credentials and manipulate mappings. That style of use case is the only one where Stephen is indicating flexibility with a mandatory-to-implement security mechanism. So, I'd like to better understand who in the WG believes it's worth delaying the base spec to address this use case but not the broader third-party use case. We'd do the broader third-party use case in a separate document as dave suggested Friday. The delay introduced would be greater than if we simply move all third-party use cases to a separate document but not nearly as long as adding a mandatory-to-implement security mechanism to the base spec. From repenno@cisco.com Tue Apr 3 08:57:12 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 5D43811E80FF for ; Tue, 3 Apr 2012 08:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.943 X-Spam-Level: X-Spam-Status: No, score=-8.943 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, J_BACKHAIR_43=1, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] 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 BQ5vNYfbvoqv for ; Tue, 3 Apr 2012 08:57:11 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id C1DE811E80EF for ; Tue, 3 Apr 2012 08:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=3272; q=dns/txt; s=iport; t=1333468619; x=1334678219; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=4q8wOn7zsW35J8o2M3gJHeEiLuD9WOdAx7zEIE3aQfA=; b=fZDjlw4xhbRDUeQNgwe+RzBCbMlUW8Twrzu2KHqlNXdTNbFj5kNQp5lS y73ts2w/eEtRxtlKb2VTkEmLIbHbn9gqk/DS6MO8XmyS9OZnPjZt1KRWb sKorL2KyO8C33yi1GWa73AtdRgU8QaxpO4dxJpzpkPFJPj7WTn2K/bvlg 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4HAPYce0+rRDoI/2dsb2JhbABFgxG0cIEHggkBAQEDAQEBAQ8BFBMCATELBQ4IbTAGAQ0FGweHYgQMm2yefASQZgSIWI0LhXCDYYR2gWmDBw X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="38776169" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 03 Apr 2012 15:56:59 +0000 Received: from [10.21.74.92] ([10.21.74.92]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q33Fuw0T032183; Tue, 3 Apr 2012 15:56:59 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Tue, 03 Apr 2012 08:56:58 -0700 From: Reinaldo Penno To: Sam Hartman , Message-ID: Thread-Topic: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "pcp@ietf.org" , Stephen Farrell Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised 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, 03 Apr 2012 15:57:12 -0000 On 4/3/12 4:09 AM, "Sam Hartman" wrote: >>>>>> writes: > > > Re-, The current situation is there are no (yet) PCP-enabled > > applications so we would have a bootstrapping issue: provide means > > to subscribers to control their mappings in PCP-controlled devices > > without requiring all applications/hosts be PCP-enabled. A > > PCP-controlled device can be a CGN (NAT44), a DS-Lite AFTR or a > > NAT64. > > > This issue can be met by combining one or all of the following > > pieces: > > > * Provide a user-interface to control the mapping (we already have > > such port forwarding interface). This interface will be modified > > to trigger PCP messages. For this case, the internal IP address is > > not the same as the address of the PCP client; THIRD_PARTY Option > > is needed. * Enable a IGD/PCP Interworking function * Enable a > > PCP Proxy > >Hi. > >He believes that even for a solution like Margaret proposes, we'd need >to explicitly restrict against implementing the base spec third party >option for CPE or enterprise equipment. It would look a lot more like >the third-party option for trusted networks Dave proposed on Friday than >what Margaret described. > >So, it would not help the use case you have. > >I think the third-party option would need a mandatory-to-implement >security mechanism for Stephen to be comfortable with your use case >above. >So, I believe the solutions you've been supporting in the last few days >are solutions that the IESG would not approve. > >What I'd like to understand is who in the WG believes it is worth >delaying the base spec for the portal use case. The portal use case is >one where the PCP server is running on ISP equipment (CGN for >example). The ISP runs a website on their servers (not CPE) that allows >users to log in with some ISP-issued credentials and manipulate >mappings. That style of use case is the only one where Stephen is >indicating flexibility with a mandatory-to-implement security mechanism. > >So, I'd like to better understand who in the WG believes it's worth >delaying the base spec to address this use case but not the broader >third-party use case. The portal case I've been pushing forward for a long time is the one most broadband ISPs are trying to deploy due to the fact out of the ~500M CPEs none of them support PCP, but support some form of port forwarding. And btw, when they do support PCP might be UPnP<->PCP in order to leverage the millions of ready applications. Mobile (3G/4G) is different, port forwarding is not status quo. Third party applicability is for a different scenario. I believe having third-party in the base spec is very important. > We'd do the broader third-party use case in a >separate document as dave suggested Friday. The delay introduced would >be greater than if we simply move all third-party use cases to a >separate document but not nearly as long as adding a >mandatory-to-implement security mechanism to the base spec. >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Tue Apr 3 09:43: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 DD36A21F8527 for ; Tue, 3 Apr 2012 09:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.093, 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 Fdo2N9DgB9a1 for ; Tue, 3 Apr 2012 09:43:50 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAEF21F8522 for ; Tue, 3 Apr 2012 09:43:50 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id D6E4618C3CB; Tue, 3 Apr 2012 18:43:48 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id BD75B27C046; Tue, 3 Apr 2012 18:43:48 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Tue, 3 Apr 2012 18:43:48 +0200 From: To: Sam Hartman Date: Tue, 3 Apr 2012 18:43:47 +0200 Thread-Topic: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised Thread-Index: Ac0RijSitWQwRWg2Th6Vv6wHoG+QkgALgirA Message-ID: <94C682931C08B048B7A8645303FDC9F36E28806616@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B4EB9B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E28805FEB@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E2880600E@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E28806080@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.3.143318 Cc: "pcp@ietf.org" , Stephen Farrell Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised 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, 03 Apr 2012 16:43:52 -0000 Dear Sam,=20 Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : Sam Hartman [mailto:hartmans@painless-security.com]=20 >Envoy=E9 : mardi 3 avril 2012 13:09 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Dave Thaler; pcp@ietf.org; Stephen Farrell >Objet : Re: [pcp] Confirming consensus from WG meetings:=20 >THIRD_PARTY revised > >>>>>> writes: > > > Re-, The current situation is there are no (yet) PCP-enabled > > applications so we would have a bootstrapping issue:=20 >provide means > > to subscribers to control their mappings in=20 >PCP-controlled devices > > without requiring all applications/hosts be PCP-enabled. A > > PCP-controlled device can be a CGN (NAT44), a DS-Lite AFTR or a > > NAT64. > > > This issue can be met by combining one or all of the following > > pieces: > > > * Provide a user-interface to control the mapping (we=20 >already have > > such port forwarding interface). This interface will be modified > > to trigger PCP messages. For this case, the internal IP=20 >address is > > not the same as the address of the PCP client; THIRD_PARTY Option > > is needed. * Enable a IGD/PCP Interworking function * Enable a > > PCP Proxy > >Hi. > >He believes that even for a solution like Margaret proposes, we'd need >to explicitly restrict against implementing the base spec third party >option for CPE or enterprise equipment. It would look a lot more like >the third-party option for trusted networks Dave proposed on=20 >Friday than >what Margaret described. > >So, it would not help the use case you have. Med: Why? > >I think the third-party option would need a mandatory-to-implement >security mechanism for Stephen to be comfortable with your use case >above. >So, I believe the solutions you've been supporting in the=20 >last few days >are solutions that the IESG would not approve. Med: The solution proposed by Margaret works for me. For my own use case, t= here is no need to enforce authentication for PCP while the same validation= rules for implicit mappings apply. > >What I'd like to understand is who in the WG believes it is worth >delaying the base spec for the portal use case. Med: We are not delaying the progress of the base spec. We are asking to ma= intain the THIRD_PARTY option in the base spec, with the appropriate securi= ty checks (like the ones suggested by Margaret), because we have deployment= plans requiring that option.=20 What is wrong with the proposal made by Margaret?=20 = From hartmans@painless-security.com Tue Apr 3 10:23: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 0244121F8644 for ; Tue, 3 Apr 2012 10:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.325, 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 26NRyA3eZC7y for ; Tue, 3 Apr 2012 10:23:54 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8F61E21F8630 for ; Tue, 3 Apr 2012 10:23:54 -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 5833120820; Tue, 3 Apr 2012 13:23:00 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 623544766; Tue, 3 Apr 2012 13:23:44 -0400 (EDT) From: Sam Hartman To: References: <9B57C850BB53634CACEC56EF4853FF653B4EB9B4@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <94C682931C08B048B7A8645303FDC9F36E28805FEB@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E2880600E@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E28806080@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E28806616@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 03 Apr 2012 13:23:44 -0400 In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E28806616@PUEXCB1B.nanterre.francetelecom.fr> (mohamed boucadair's message of "Tue, 3 Apr 2012 18:43:47 +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" , Stephen Farrell Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised 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, 03 Apr 2012 17:23:55 -0000 >>>>> writes: >> He believes that even for a solution like Margaret proposes, we'd >> need to explicitly restrict against implementing the base spec >> third party option for CPE or enterprise equipment. It would >> look a lot more like the third-party option for trusted networks >> Dave proposed on Friday than what Margaret described. >> >> So, it would not help the use case you have. > Med: Why? Are you asking why a solution that forbids implementation for equipment targeted at CPEs would be problematic for the use case you've defined or are you asking why Stephen requires additional restrictions beyond what Margaret originally proposed? > What is wrong with the proposal made by Margaret? Stephen believes that additional restrictions similar to those proposed by Dave are required in order to address his concerns. So, margaret's proposal would be insufficient for Stephen to remove his blocking objection to the approval of the base spec. If you're asking why Stephen believes that, I'd refer you to him or to his comments in the IETF datatracker (the formal text of his objection). Hope that helps. --Sam From mohamed.boucadair@orange.com Wed Apr 4 01:16: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 19BAA21F8663 for ; Wed, 4 Apr 2012 01:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.075, 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 MrhO1bVAE0zT for ; Wed, 4 Apr 2012 01:16:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4782121F84DF for ; Wed, 4 Apr 2012 01:16:44 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id DB09E3B42D4; Wed, 4 Apr 2012 10:16:39 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id B21494C06C; Wed, 4 Apr 2012 10:16:39 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 4 Apr 2012 10:16:39 +0200 From: To: Dan Wing , 'Qiong' , "pcp@ietf.org" Date: Wed, 4 Apr 2012 10:16:38 +0200 Thread-Topic: [pcp] Ask for your comments on PCP port-set extension Thread-Index: Ac0OSxfnQh7/jAmKQZWoo+SdVYujLQAAYIMwAPty1+A= Message-ID: <94C682931C08B048B7A8645303FDC9F36E28806724@PUEXCB1B.nanterre.francetelecom.fr> References: <066601cd0e4f$5d02c400$17084c00$@com> In-Reply-To: <066601cd0e4f$5d02c400$17084c00$@com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.21.123317 Subject: Re: [pcp] Ask for your comments on PCP port-set extension 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, 04 Apr 2012 08:16:46 -0000 Hi Dan, Your comment is valid when the same address is shared among a large number = of users. A remote server may force the client to issue N connections and t= hen discover the full port set but if the address sharing ratio is low (e.g= ., 2 or 4), the random port range preserves the spirit of RFC6056.=20 Because address sharing ratio is deployment-specific, we need to cover the = full range from 2 to 2^16. Cheers, Med >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Dan Wing >Envoy=E9 : vendredi 30 mars 2012 10:30 >=C0 : 'Qiong'; pcp@ietf.org >Objet : Re: [pcp] Ask for your comments on PCP port-set extension > > >The Cryptographically Random Port Range Option will lead to=20 >interoperability problems, and is not worth pursuing. There is only=20 >a slight gain to such pseudo-random port assignment (reference=20 >RFC6056),=20 >because an attacker can cause the victim to open 100's of ports to >a server owned by the attacker, thus the attacker learns allocated >port numbers and the port assignment algorithm (which could be=20 >leveraged against other subscribers using that same algorithm at >the same ISP). Thus, the pseudo-random assignment of port numbers=20 >does not achieve the goals outlined in RFC6056. From zhangdacheng@huawei.com Mon Apr 9 00:47:58 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 9AD2921F858D for ; Mon, 9 Apr 2012 00:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uzn4cEcgCM+J for ; Mon, 9 Apr 2012 00:47:57 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBE821F84C8 for ; Mon, 9 Apr 2012 00:47:57 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFB39882; Mon, 09 Apr 2012 03:47:57 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 00:46:09 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 00:46:09 -0700 Received: from SZXEML528-MBS.china.huawei.com ([169.254.5.80]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Mon, 9 Apr 2012 15:46:06 +0800 From: "Zhangdacheng (Dacheng)" To: "pcp@ietf.org" Thread-Topic: [pcp] Fwd: Comments on draft-wasserman-pcp-authentication-02 Thread-Index: Ac0WJNB7jIp6UQPWRISWd2Pa/viREg== Date: Mon, 9 Apr 2012 07:46:05 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [pcp] Fwd: Comments on draft-wasserman-pcp-authentication-02 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, 09 Apr 2012 07:47:58 -0000 Hi, we are updating the draft according to Josh's comments.=20 >>1. The Message Type and Session ID fields seem to duplicate the functions >>of EAP's Type and Identifier fields. The message type filed is redundant while we expected to use the Session ID= to detect antique messages in cooperate with sequence numbers. However, we= later realize that the nonce exchanged between PCC and PCS can be used to = achieve the same function. For example, assume both PCC and PCS select a ra= ndom number as nonce at the beginning of the session to check each other's = aliveness. The random numbers can be used to distinguish the messages withi= n this session from the message in other sessions. Therefore, in the next v= ersion of the draft, we plan to remove the session ID and the Message Type = fields, and plan to use nonce and sequence numbers to detect replay attacks= . Comments?=20 Cheers Dacheng From ext-felipe.m.costa@nokia.com Wed Apr 11 14:10: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 1178411E80BB for ; Wed, 11 Apr 2012 14:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 8ivaPptRpuFG for ; Wed, 11 Apr 2012 14:10:46 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 171BB11E80B8 for ; Wed, 11 Apr 2012 14:10:42 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3BLAd4U011478 for ; Thu, 12 Apr 2012 00:10:40 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Apr 2012 00:10:39 +0300 Received: from 008-AM1MPN1-013.mgdnok.nokia.com ([169.254.3.177]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.02.0283.004; Wed, 11 Apr 2012 23:10:39 +0200 From: To: Thread-Topic: Wrong sentence in I-D v24 Thread-Index: Ac0YJrqwwQAC2nQFQxy+ctb0OeZg9w== Date: Wed, 11 Apr 2012 21:10:38 +0000 Message-ID: <0412136DF48FC94A9795E62ECFC0146510545403@008-AM1MPN1-013.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-headerinfofordlp: None x-titus-version: 3.3.8.1 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-tituslabs-classificationhash-30: FdMHbeiN7EWUUWBGmH2X8EOQugQHpz99pEbMXp381hUhdUEWHIxxOfjfJjNAf3pqMDQk3qJ2BQrY2Q/R/In0vT/DR4m8x4tUtwvS/qoGCzxAup4ct07b+3yPKNFhJu6sMO1/mmtFRu+x8qoolbWTmINIGEJi6X61UopL/eIfhIyWjJK3DSLLFKxtxu2OThOWC9ZTkCrKukf09E20JZNQzEsCyEnElkRplUx262EysLI= x-originating-ip: [189.2.128.130] Content-Type: multipart/alternative; boundary="_000_0412136DF48FC94A9795E62ECFC0146510545403008AM1MPN1013mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 11 Apr 2012 21:10:39.0713 (UTC) FILETIME=[8C1D3D10:01CD1827] X-Nokia-AV: Clean Subject: [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: Wed, 11 Apr 2012 21:10:47 -0000 --_000_0412136DF48FC94A9795E62ECFC0146510545403008AM1MPN1013mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear editors, If/when a new version of the PCP I-D is written, please eliminate the follo= wing sentence, present on I-D v24: Page 51, when explaining the fields present in the PEER Opcode Response pac= ket (Figure 12): Assigned External IP Address: (...) IPv4 or IPv6 address is indicated by th= e Opcode (...) Regards, Felipe Miranda Costa --_000_0412136DF48FC94A9795E62ECFC0146510545403008AM1MPN1013mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear editors,

 

If/when a new version of the PCP I-D is written, ple= ase eliminate the following sentence, present on I-D v24:

 

Page 51, when explaining the fields present in the P= EER Opcode Response packet (Figure 12):

 

Assigned External IP Address: (…) IPv4 or IPv6 address is indicated by the Opcode (…)

 

Regards,

 

Felipe Miranda Costa=

 

--_000_0412136DF48FC94A9795E62ECFC0146510545403008AM1MPN1013mg_-- From mohamed.boucadair@orange.com Thu Apr 19 00:41:34 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 A728D21F84EB for ; Thu, 19 Apr 2012 00:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.088, 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 rVDmSx5XCVCN for ; Thu, 19 Apr 2012 00:41:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 79C2421F84DE for ; Thu, 19 Apr 2012 00:41:30 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 3241D32412F; Thu, 19 Apr 2012 09:41:29 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 15D864C071; Thu, 19 Apr 2012 09:41:29 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 19 Apr 2012 09:41:28 +0200 From: To: "pcp@ietf.org" Date: Thu, 19 Apr 2012 09:41:27 +0200 Thread-Topic: Requesting adoption of draft-boucadair-pcp-rtp-rtcp Thread-Index: Ac0d/9QPTX1D+H+ES76amdglRSwSpA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E28990D09@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.19.63316 Subject: [pcp] Requesting adoption of draft-boucadair-pcp-rtp-rtcp 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, 19 Apr 2012 07:41:34 -0000 Dear all, =20 Senthil and myself are requesting the WG to consider adopting this document= as a WG item. The document specifies a simple solution for a well-defined problem. More d= etails are in the draft. Title : Reserving N and N+1 Ports with PCP Filename : draft-boucadair-pcp-rtp-rtcp-04.txt Pages : 14 Date : 2012-04-19 This document defines a new PCP Option to reserve a pair of ports (N and N+1) by a PCP-controlled device while preserving the parity and contiguity. This PCP Option eases the NAT traversal for applications having requirements on the port parity and contiguity (e.g., RTP/ RTCP).=20 http://tools.ietf.org/html/draft-boucadair-pcp-rtp-rtcp-04 Cheers, Med= From ales.vizdal@t-mobile.cz Thu Apr 19 01:12:41 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 B585C21F8493 for ; Thu, 19 Apr 2012 01:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] 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 VDOS+26kDVDr for ; Thu, 19 Apr 2012 01:12:39 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 21EE621F8496 for ; Thu, 19 Apr 2012 01:12:38 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.246.143.96]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 07AD3285815; Thu, 19 Apr 2012 10:12:37 +0200 (CEST) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::506:b9a6:d353:9494%12]) with mapi; Thu, 19 Apr 2012 10:12:36 +0200 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "mohamed.boucadair@orange.com" , GangChen , "pcp@ietf.org" Date: Thu, 19 Apr 2012 10:12:31 +0200 Thread-Topic: [pcp] Is it the right place to document something for PCP in mobile network Thread-Index: Ac0MM0TLBcelj5DmREiejveaWPFymgAfm6YgBFR03MA= Message-ID: <1808340F7EC362469DDFFB112B37E2FCC67F1B171D@SRVHKE02.rdm.cz> References: <94C682931C08B048B7A8645303FDC9F36E287331FE@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E287331FE@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Is it the right place to document something for PCP in mobile network 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, 19 Apr 2012 08:12:41 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: Wednesday, March 28, 2012 9:28 AM > To: GangChen; pcp@ietf.org > Subject: Re: [pcp] Is it the right place to document something for PCP in= mobile > network >=20 > Hi Gang, all, >=20 > I do personally think it is valuable to have this document as Information= al. >=20 > As mentioned by Gang, we have tried in the past to initiate a study item = within 3GPP > but this was not successful because there is (surprisingly) no function t= o be controlled > by PCP (!!!) >=20 > Since we are aware there are plenty functions (e.g., NAT) which may benef= it from the > help of PCP to achieve goals such as better application experience, bette= r battery > utilization, etc, a document dealing with some of mobile considerations i= s needed. >=20 > Having a document covering PCP-related considerations in mobile networks = would > provide a pointer for operators to be included in their UE profile requir= ements. Of > course, the document need restrict the scope to major issues (e.g., PCP S= erver > Discovery). +1 From simon.perreault@viagenie.ca Thu Apr 19 06:06:23 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 2F67421F846F for ; Thu, 19 Apr 2012 06:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYONNf1FEQiw for ; Thu, 19 Apr 2012 06:06:18 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id A040921F85F9 for ; Thu, 19 Apr 2012 06:06:17 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:40c6:97b5:33:1ee6]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 066834007C for ; Thu, 19 Apr 2012 09:06:16 -0400 (EDT) Message-ID: <4F900DC8.7020606@viagenie.ca> Date: Thu, 19 Apr 2012 09:06:16 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: pcp@ietf.org References: <94C682931C08B048B7A8645303FDC9F36E28990D09@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E28990D09@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pcp] Requesting adoption of draft-boucadair-pcp-rtp-rtcp 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, 19 Apr 2012 13:06:23 -0000 On 2012-04-19 03:41, mohamed.boucadair@orange.com wrote: > Senthil and myself are requesting the WG to consider adopting this document as a WG item. I think this should be adopted. This PCP extension is very simple and constrained to a particular use case, which I like. It is also easy to implement because the semantics of other operations (keep-alive, delete) are not changed: the two mappings created by this option are treated exactly like independent mappings from the moment they are created. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dxhbupt@gmail.com Fri Apr 20 01:13: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 ED13221F87B6 for ; Fri, 20 Apr 2012 01:12:59 -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 Y0VN7pL6NNK7 for ; Fri, 20 Apr 2012 01:12:57 -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 20E4421F87B1 for ; Fri, 20 Apr 2012 01:12:55 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so6366778wgb.13 for ; Fri, 20 Apr 2012 01:12:54 -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=AD4U0xNgnu70HlqhwYJXQI2YT50709wqpHloDaeL8VE=; b=og3swv7VtCuIjV8T5seT7lllcBZusvnFlUXgI/eIF2rgrqhz5E9sDtlEejqu+/0hy8 ycXiTDKVaTGswE7xC2zmNM4SxDwCxdpHTFStIE4LPCXo2+h1nK+4t4h05DxvKUhzdDPK khlgeHe3KtPL1+F5OlLWfXJVtBDk0+Wp5n3ILgUyTDPm/OzXi9Dd51io3p6LMfyo/ew/ R/3IAqXfxzaIygZFFb8Bzz4LjNF0EmUzlSlid0EVPYMqMwex1O05H3FXx3J6+SBWchxA Wsl1HYsEXLf3FiqxEhk6lepME3epjEuVtIT2D44Y4RETrBaStLSc9mR43EGr04OFPKBD L04Q== MIME-Version: 1.0 Received: by 10.216.136.131 with SMTP id w3mr3318598wei.15.1334909574758; Fri, 20 Apr 2012 01:12:54 -0700 (PDT) Received: by 10.180.99.134 with HTTP; Fri, 20 Apr 2012 01:12:54 -0700 (PDT) In-Reply-To: <4F900DC8.7020606@viagenie.ca> References: <94C682931C08B048B7A8645303FDC9F36E28990D09@PUEXCB1B.nanterre.francetelecom.fr> <4F900DC8.7020606@viagenie.ca> Date: Fri, 20 Apr 2012 16:12:54 +0800 Message-ID: From: Xiaohong Deng To: Simon Perreault Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pcp@ietf.org Subject: Re: [pcp] Requesting adoption of draft-boucadair-pcp-rtp-rtcp 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, 20 Apr 2012 08:13:02 -0000 On Thu, Apr 19, 2012 at 9:06 PM, Simon Perreault wrote: > On 2012-04-19 03:41, mohamed.boucadair@orange.com wrote: >> >> Senthil and myself are requesting the WG to consider adopting this >> document as a WG item. > > > I think this should be adopted. This PCP extension is very simple and > constrained to a particular use case, which I like. It is also easy to > implement because the semantics of other operations (keep-alive, delete) = are > not changed: the two mappings created by this option are treated exactly > like independent mappings from the moment they are created. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca > STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp +1 for support of the adaption. The driven of this I-D came from addressing back compatibility of current practices, e.g., RTP/RTCP, and it's easy implementable. Also importantly as Simon has pointed out that it's compliant with basic design as PCP base document. --=20 -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/ From internet-drafts@ietf.org Sat Apr 21 15:03: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 1310F21F8666; Sat, 21 Apr 2012 15:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 Ec7WiIvDFawr; Sat, 21 Apr 2012 15:03:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A701721F856C; Sat, 21 Apr 2012 15:03:50 -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.00 Message-ID: <20120421220350.23006.86649.idtracker@ietfa.amsl.com> Date: Sat, 21 Apr 2012 15:03:50 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-proxy-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2012 22:03:55 -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) Proxy Function Author(s) : Mohamed Boucadair Internet Systems Consortium Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-proxy-00.txt Pages : 12 Date : 2012-03-28 This document specifies the behavior of a PCP Proxy element, for instance embedded in Customer Premise routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcp-proxy-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-ietf-pcp-proxy-00.txt From roberta.maglione@telecomitalia.it Mon Apr 23 01:47:14 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 75D8E21F8663 for ; Mon, 23 Apr 2012 01:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 UvwzoBbWn54e for ; Mon, 23 Apr 2012 01:47:13 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id E4FCF21F8661 for ; Mon, 23 Apr 2012 01:47:12 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.245.1; Mon, 23 Apr 2012 10:47:10 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Mon, 23 Apr 2012 10:47:10 +0200 From: Maglione Roberta To: "'mohamed.boucadair@orange.com'" , "pcp@ietf.org" , Tina TSOU Date: Mon, 23 Apr 2012 10:47:09 +0200 Thread-Topic: Requesting adoption of draft-boucadair-pcp-rtp-rtcp Thread-Index: Ac0d/9QPTX1D+H+ES76amdglRSwSpADLRTyA Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE51370AD03D@GRFMBX704BA020.griffon.local> References: <94C682931C08B048B7A8645303FDC9F36E28990D09@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E28990D09@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Requesting adoption of draft-boucadair-pcp-rtp-rtcp 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, 23 Apr 2012 08:47:14 -0000 Hello, I have a clarification question: What's the difference between this draft and draft-tsou-pcp-natcoord? My understanding is that draft-boucadair-pcp-rtp-rtcp defines a new PCP Opt= ion to reserve a pair of ports (N and N+1) while Tina's draft proposes a ne= w option to reserve a more generic "set of ports". Isn't N and N+1 range just a special case of a generic "set of port"? Thanks, Roberta -----Original Message----- From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of moham= ed.boucadair@orange.com Sent: gioved=EC 19 aprile 2012 9.41 To: pcp@ietf.org Subject: [pcp] Requesting adoption of draft-boucadair-pcp-rtp-rtcp Dear all, Senthil and myself are requesting the WG to consider adopting this document= as a WG item. The document specifies a simple solution for a well-defined problem. More d= etails are in the draft. Title : Reserving N and N+1 Ports with PCP Filename : draft-boucadair-pcp-rtp-rtcp-04.txt Pages : 14 Date : 2012-04-19 This document defines a new PCP Option to reserve a pair of ports (N and N+1) by a PCP-controlled device while preserving the parity and contiguity. This PCP Option eases the NAT traversal for applications having requirements on the port parity and contiguity (e.g., RTP/ RTCP). http://tools.ietf.org/html/draft-boucadair-pcp-rtp-rtcp-04 Cheers, Med _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From mohamed.boucadair@orange.com Mon Apr 23 02:04:58 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 E389521F8675 for ; Mon, 23 Apr 2012 02:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.093, 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 ETsHFfXh5Nvr for ; Mon, 23 Apr 2012 02:04:55 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 56CE421F8674 for ; Mon, 23 Apr 2012 02:04:55 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id BBEFC3B4279; Mon, 23 Apr 2012 11:04:54 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id A1A3E35C055; Mon, 23 Apr 2012 11:04:54 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 23 Apr 2012 11:04:54 +0200 From: To: Maglione Roberta , "pcp@ietf.org" , Tina TSOU Date: Mon, 23 Apr 2012 11:04:53 +0200 Thread-Topic: Requesting adoption of draft-boucadair-pcp-rtp-rtcp Thread-Index: Ac0d/9QPTX1D+H+ES76amdglRSwSpADLRTyAAAA7tJA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E28991391@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E28990D09@PUEXCB1B.nanterre.francetelecom.fr> <282BBE8A501E1F4DA9C775F964BB21FE51370AD03D@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE51370AD03D@GRFMBX704BA020.griffon.local> 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.4.23.72418 Subject: Re: [pcp] Requesting adoption of draft-boucadair-pcp-rtp-rtcp 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, 23 Apr 2012 09:04:59 -0000 Dear Roberta, The N/N+1 Option is designed with a focus on the RTP/RTCP case. As such, in= addition to port contiguity there is also a requirement to preserve port p= arity (http://tools.ietf.org/html/draft-boucadair-pcp-rtp-rtcp-04#section-3= .1). FWIW, below an excerpt from RFC4784: 4.2.2. Port Parity Some NATs preserve the parity of the UDP port, i.e., an even port will be mapped to an even port, and an odd port will be mapped to an odd port. This behavior respects the [RFC3550] rule that RTP use even ports, and RTCP use odd ports. RFC 3550 allows any port numbers to be used for RTP and RTCP if the two numbers are specified separately; for example, using [RFC3605]. However, some implementations do not include RFC 3605, and do not recognize when the peer has specified the RTCP port separately using RFC 3605. If such an implementation receives an odd RTP port number from the peer (perhaps after having been translated by a NAT), and then follows the RFC 3550 rule to change the RTP port to the next lower even number, this would obviously result in the loss of RTP. NAT-friendly application aspects are outside the scope of this document. It is expected that this issue will fade away with time, as implementations improve. Preserving the port parity allows for supporting communication with peers that do not support explicit specification of both RTP and RTCP port numbers. REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation" behavior of "Yes". Justification: This is to avoid breaking peer-to-peer applications that do not explicitly and separately specify RTP and RTCP port numbers and that follow the RFC 3550 rule to decrement an odd RTP port to make it even. The same considerations apply, as per the IP address pooling requirement. N/N+1 Option makes use of an existing PCP OpCode with minor change at the P= CP Server during the creation of the two mappings. Once the 2 mappings are = created, they are handled as any individual mapping created using MAP. draft-tsou-* targets another use case which is to delegate a set of port to= a requesting device: draft-tsou-* does offload the NAT to the requesting P= CP Client while in the N/N+1 case the NAT is enforced in the PCP-controlled= device itself. I hope this clarifies your concern. Cheers, Med=20 >-----Message d'origine----- >De : Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 >Envoy=E9 : lundi 23 avril 2012 10:47 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; pcp@ietf.org; Tina TSOU >Objet : RE: Requesting adoption of draft-boucadair-pcp-rtp-rtcp > >Hello, > I have a clarification question: >What's the difference between this draft and draft-tsou-pcp-natcoord? >My understanding is that draft-boucadair-pcp-rtp-rtcp defines=20 >a new PCP Option to reserve a pair of ports (N and N+1) while=20 >Tina's draft proposes a new option to reserve a more generic=20 >"set of ports". > >Isn't N and N+1 range just a special case of a generic "set of port"? > >Thanks, >Roberta > >-----Original Message----- >From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On=20 >Behalf Of mohamed.boucadair@orange.com >Sent: gioved=EC 19 aprile 2012 9.41 >To: pcp@ietf.org >Subject: [pcp] Requesting adoption of draft-boucadair-pcp-rtp-rtcp > >Dear all, > >Senthil and myself are requesting the WG to consider adopting=20 >this document as a WG item. > >The document specifies a simple solution for a well-defined=20 >problem. More details are in the draft. > > Title : Reserving N and N+1 Ports with PCP > Filename : draft-boucadair-pcp-rtp-rtcp-04.txt > Pages : 14 > Date : 2012-04-19 > > This document defines a new PCP Option to reserve a pair of ports (N > and N+1) by a PCP-controlled device while preserving the parity and > contiguity. This PCP Option eases the NAT traversal for=20 >applications > having requirements on the port parity and contiguity (e.g., RTP/ > RTCP). > > http://tools.ietf.org/html/draft-boucadair-pcp-rtp-rtcp-04 > > >Cheers, >Med >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp > >Questo messaggio e i suoi allegati sono indirizzati=20 >esclusivamente alle persone indicate. La diffusione, copia o=20 >qualsiasi altra azione derivante dalla conoscenza di queste=20 >informazioni sono rigorosamente vietate. Qualora abbiate=20 >ricevuto questo documento per errore siete cortesemente=20 >pregati di darne immediata comunicazione al mittente e di=20 >provvedere alla sua distruzione, Grazie. > >This e-mail and any attachments is confidential and may=20 >contain privileged information intended for the addressee(s)=20 >only. Dissemination, copying, printing or use by anybody else=20 >is unauthorised. If you are not the intended recipient, please=20 >delete this message and any attachments and advise the sender=20 >by return e-mail, Thanks. > >=