From dean.cheng@huawei.com Wed May 1 17:15:17 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEC521F9A9F for ; Wed, 1 May 2013 17:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waaOe8q42nzE for ; Wed, 1 May 2013 17:15:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CF1E521F9A98 for ; Wed, 1 May 2013 17:15:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQZ10639; Thu, 02 May 2013 00:15:07 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 2 May 2013 01:14:13 +0100 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 2 May 2013 01:15:05 +0100 Received: from SZXEML523-MBX.china.huawei.com ([169.254.3.66]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Thu, 2 May 2013 08:15:00 +0800 From: Dean cheng To: Tassos Chatzithomaoglou , "Reinaldo Penno (repenno)" , "pcp@ietf.org" Thread-Topic: [pcp] WG Call for Adoption: draft-maglione-pcp-radius-ext-07 Thread-Index: AQHORY2/F+aRXyiCXUe2ciJhpJe+V5jxBo+g Date: Thu, 2 May 2013 00:14:59 +0000 Message-ID: References: <45A697A8FFD7CF48BCF2BE7E106F06040905138F@xmb-rcd-x04.cisco.com> <517F9D2A.5050601@forthnetgroup.gr> In-Reply-To: <517F9D2A.5050601@forthnetgroup.gr> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [pcp] WG Call for Adoption: draft-maglione-pcp-radius-ext-07 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, 02 May 2013 00:15:17 -0000 Thanks Tassos for your comments, please refer to some explanations below. > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Tassos Chatzithomaoglou > Sent: Tuesday, April 30, 2013 3:30 AM > To: Reinaldo Penno (repenno); pcp@ietf.org > Subject: Re: [pcp] WG Call for Adoption: draft-maglione-pcp-radius-ext- > 07 >=20 > just had a quick look and i have a question: >=20 > If i understand correctly the packet format, you can't have a PCP > server for IPv4 and a different PCP server for IPv6, unless the same > DNS name is used; am i right? > Generally, how do you differentiate between v4 and v6 ones when the > Dual-Stack context is used? > Is this left to the NAS to decide (based on what?) which one to pass to > the co-located DHCPv4/v6 servers, or does the NAS pass everything to > both DHCP servers? This draft only proposes a mechanism using RADIUS protocol with an=20 extension as proposed to convey the PCP-server name from an AAA server=20 to an NAS that is co-located with a DHCP or DHCPv6 server, (and as you=20 suggested, could be both), as such the operating scope is limited between=20 the AAA server and the NAS. The configuration required is on the AAA=20 server for the PCP-server name. This draft does not define how the configuration and overal operation=20 is in a broadband network in this regard, although however, it does=20 elaborate in IPv4 and IPv6 based access network, respectively, how the proposed RADIUS message flow interacts with the DHCP/DHCPv6 message=20 flow using their respective PCP-related (sub-)option. It is out of scope for this draft as how a PCP-server name mapping to the PCP-server IP address. However, in IPv4-only or IPv6-only=20 access network, the IP address to be mapped is obvious; and in a=20 dual-stack environment, it is so as well, since where the IPv4 and=20 IPv6 operate in a SIN mode - if an access request is in IPv4, then=20 the RADIUS message exchange between the NAS and AAA server is in=20 IPv4, hence the PCP-server name received by the NAS is passed to=20 DHCP server; same logic if an access request is in IPv6. With this,=20 it would be possible that the same PCP-server for both IPv4 and IPv6. >=20 > ...and some minor ones... > > In such environment, PCP server's name can be configured on a > RADIUS > > server, which then passes the information to a NAS that co-locates > > with the DHCPv4/DHCPv6 server, which in turn populates the > location > > of the PCP server. >=20 > Shouldn't this be the opposite? DHCP server that co-locates with the > NAS. The "co-location" means the DHCPv4/DHCPv6 function (entity) is on the same= =20 platform where the NAS function (entity) is, such that through=20 internal-to-the-platform communication between the two, the PCP-server=20 name can be passed from the latter one to the former one. >=20 >=20 > > When the co-located DHCPv6 server receives a DHCPv6 message > > containing the PCP Server Option, it SHALL use the name returned > in > > the RADIUS attribute as defined in this memo to populate the > DHCPv6 > > PCP Server option defined in [I-D.ietf-pcp-dhcp > D.ietf-pcp-dhcp>]. >=20 > When the co-located DHCPv6 server receives a DHCPv6 message from a > client containing the PCP Server Option... Will fix this, thanks. >=20 > > The scenario with PPP Session and IPv4 only connectivity does not > > require DHCPv4: the whole configuration of the client is performed > by > > PPP. This case is out of scope of this document because in order > to > > complete the configuration of the PCP client a new PPP IPC option > > would be required. >=20 > ...a new PPP IPCP option.. Will fix this, thanks. >=20 > -- > Tassos >=20 >=20 > Reinaldo Penno (repenno) wrote on 26/04/2013 17:12: > > Hello, > > > > This email starts a 2-week consensus call on adopting "RADIUS > Extensions > > for Port Control Protocol (PCP)" as a WG item. > > > > Title : RADIUS Extensions for Port Control Protocol (PCP) > > Author(s) : R. Maglione et al > > Filename : draft-maglione-pcp-radius-ext-07 > > URL : > > http://tools.ietf.org/html/draft-maglione-pcp-radius-ext-07 > > > > Please read the current revision and state you opinion either for or > > against adoption (and with reasoning why) in the mailing list. > > > > The call for adoption ends 10th May 2013. > > > > Thanks, > > > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp > > >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From dean.cheng@huawei.com Wed May 1 17:20:29 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DC021F9B61 for ; Wed, 1 May 2013 17:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpBCHHTuI1sq for ; Wed, 1 May 2013 17:20:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 31BF921F9B27 for ; Wed, 1 May 2013 17:20:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQZ10817; Thu, 02 May 2013 00:20:20 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 2 May 2013 01:19:27 +0100 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 2 May 2013 01:20:20 +0100 Received: from SZXEML523-MBX.china.huawei.com ([169.254.3.66]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.007; Thu, 2 May 2013 08:20:13 +0800 From: Dean cheng To: Alan DeKok , "pcp@ietf.org" Thread-Topic: [pcp] Review of draft-maglione-pcp-radius-ext-05 Thread-Index: AQHORaU85lN6KE7MDUGN8Z4R53lLE5jxCVZg Date: Thu, 2 May 2013 00:20:12 +0000 Message-ID: References: <513F39CA.4070701@deployingradius.com> <517FC4B3.7040709@deployingradius.com> In-Reply-To: <517FC4B3.7040709@deployingradius.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [pcp] Review of draft-maglione-pcp-radius-ext-05 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, 02 May 2013 00:20:29 -0000 Hi Alan, thanks for your comment, and we'll=20 update the related text and align it with=20 the 6rd draft (now RFC6930) in that regard. Dean > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Alan DeKok > Sent: Tuesday, April 30, 2013 6:19 AM > To: pcp@ietf.org > Subject: Re: [pcp] Review of draft-maglione-pcp-radius-ext-05 >=20 > Finishing the message... >=20 > Alan DeKok wrote: > > This email is a quick review of the draft-maglione-pcp-radius-ext- > 05 > > document. Overall, it looks fairly good. >=20 > Another note. Section 3 says: >=20 > In the scenario depicted in Figure 2 the Access-Request packet > contains a Service-Type attribute with the value Authorize Only (17), > thus according to [RFC5080] the Access-Request packet MUST contain a > State attribute. >=20 >=20 > That text is identical with previous drafts using RADIUS for > authorization-only. It's wrong. >=20 > There was a LOT of discussion in RADEXT about this. There's really > no > perfect solution. But the text should be fixed. >=20 > Alan DeKok. > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From repenno@cisco.com Fri May 3 14:18:53 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FDF21F85EE for ; Fri, 3 May 2013 14:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P01GxmO6-FYx for ; Fri, 3 May 2013 14:18:48 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 771F521F84B2 for ; Fri, 3 May 2013 14:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3910; q=dns/txt; s=iport; t=1367615928; x=1368825528; h=from:to:subject:date:message-id:mime-version; bh=Kgnmjjo+XPF2S1PqkhaBavO5W1ag3opBoezdGebrmAE=; b=ENTcBZCJs8JGVrqQ4rYeaexMEU1xNryRyLXfaEmlg3fSTTIh/HmvQ2+n pkXjDI8SBMu4c0eu21Mj+nLIHDN/cS4SWmcLhIlK7N5bpciCcQ9Osed5G DfdvYnN4GLU4DT/Zb/Mv+M40s0dnfgZUPFp3w7Sr9tOCHZdu0hsnhMKS0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcGAAMphFGtJV2b/2dsb2JhbABQgkNEN78zehZtB4IhAQSBCwEMHlYnBBsBiAMMogCfPo8AgyphA5NdlQGDDYIn X-IronPort-AV: E=Sophos;i="4.87,607,1363132800"; d="scan'208,217";a="206063495" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 03 May 2013 21:18:48 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r43LIlYF006773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 3 May 2013 21:18:47 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.96]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Fri, 3 May 2013 16:18:47 -0500 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: Gentle Reminder of Action items Thread-Index: AQHOSEPMTzd51Qwqak20xNTjKGCk4w== Date: Fri, 3 May 2013 21:18:47 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090681BF@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.66.79] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F0604090681BFxmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [pcp] Gentle Reminder of Action items 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, 03 May 2013 21:18:53 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F0604090681BFxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We are 3 months from IETF Berlin, so a gentle nudge. http://www.ietf.org/proceedings/86/minutes/minutes-86-pcp Summary of action items in no specific order: - WGLC for PCP Server Selection and gathering of reviewers (soon) - Further clarification on the use of IP address in DHCP PCP Option (ADs) - PCP Proxy needs a security section (open) - PCP Proxy: discussion whether PCP needs a bit about mandatory/optional to process bit for opcodes (open) - Create a PCP nested NAT use-case and based on that the required extension= (open) - Radius Extension confirmation of adoption on list (done, probably need re= spin) - PCP failure scenarios need to contain only those scenarios not covered by base spec (open) - PCP authentication option will star off with option 4 "Servers continue to use same SA to protect messages pertaining to that mapping, even if the SA is technically expired." - PCP authentication draft need updated based on discussion (done, discusse= d on interim) - Adopt PCP Nat coord as WG document (done, need review based on comments) Thanks, Reinaldo and Dave --_000_45A697A8FFD7CF48BCF2BE7E106F0604090681BFxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <4B7F9B923FEB7C428777B1800A15B1AB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable 
http://www.ietf.org/proceedings/86/minutes/minutes-86-pcp

Summary of action items in no specific order:

- WGLC for PCP Server Selection and gathering of reviewers (soon)
- Further clarification on the use of IP address in DHCP PCP Option (ADs)
- PCP Proxy needs a security section (open)
- PCP Proxy: discussion whether PCP needs a bit about mandatory/optional
to process bit for opcodes (open)
- Create a PCP nested NAT use-case and based on that the required extension=
 (open)
- Radius Extension confirmation of adoption on list (done, probably need re=
spin)
- PCP failure scenarios need to contain only those scenarios not covered
by base spec (open)
- PCP authentication option will star off with option 4
"Servers continue to use same SA to protect messages pertaining to
   that mapping, even if the SA is technically expired."
- PCP authentication draft need updated based on discussion (done, discusse=
d on interim)
- Adopt PCP Nat coord as WG document (done, need review based on comments)

Thanks,

Reinaldo and Dave
--_000_45A697A8FFD7CF48BCF2BE7E106F0604090681BFxmbrcdx04ciscoc_-- From alper.yegin@yegin.org Sat May 4 02:21:34 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB92B21F8425 for ; Sat, 4 May 2013 02:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 PIzmCpCHZyiD for ; Sat, 4 May 2013 02:21:28 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id D7F2021F8525 for ; Sat, 4 May 2013 02:21:22 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0Lh74Z-1UCALS3hjz-00nhTI; Sat, 04 May 2013 05:21:21 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_54BFB537-12EF-42B3-AC60-3F7CDD10CA3C" From: Alper Yegin In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090681BF@xmb-rcd-x04.cisco.com> Date: Sat, 4 May 2013 12:21:16 +0300 Message-Id: <8A6CB3FA-CCBF-4363-8B9F-4A2CBEE8B5EC@yegin.org> References: <45A697A8FFD7CF48BCF2BE7E106F0604090681BF@xmb-rcd-x04.cisco.com> To: "Reinaldo Penno (repenno)" X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:roIBPGOWtpvvG8XFa2SOqxdG69s8zsbcQYZ12BNVnML mT/9IcDZmUKm4ubELgVsBL0AXW99g5qbxZIoQbJ7lsklV60AOQ WDylslhGsGHG77Trv3XKaZ+hNDLoCjDVZdOQ/ag07PSOe8smg9 19KmwXMitQnkl6o7b4IXwXRt7Qs33cqBDdF671g/8FkB+uup0G wi1YasVzfTorYpcKXOojjNOhnyVz4XFOXRBbp87JcdVXYsL2lE 2hzx/FiliCiQGKbAevHyJy5aufvr2RCNKrI9JXDgA8h9RZcDPk +96gRA9sI3xjbSqdLkxQ5OIV2Q/QkYHtA684VKQLFjLedaGTcN 5ixWCmGKwPmeoDqBir03r+o/VMf8m4u/pyv8GlAKkp031UlJWP eJWHBQBjCm5YQ== Cc: "pcp@ietf.org" Subject: Re: [pcp] Gentle Reminder of Action items 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, 04 May 2013 09:21:34 -0000 --Apple-Mail=_54BFB537-12EF-42B3-AC60-3F7CDD10CA3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Reinaldo, > - PCP authentication option will star off with option 4 > "Servers continue to use same SA to protect messages pertaining to > that mapping, even if the SA is technically expired." This is plain broken.=20 I missed the call to express my input, but you can find it on the = reflector. Comments on my email is welcome. > - PCP authentication draft need updated based on discussion (done, = discussed on interim) The issue of using PANA vs EAP-o-PCP is still open. How do you guys plan = on resolving that?=20 Alper --Apple-Mail=_54BFB537-12EF-42B3-AC60-3F7CDD10CA3C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi Reinaldo,

- PCP authentication option will star off with option 4
"Servers continue to use same SA to protect messages pertaining to
   that mapping, even if the SA is technically expired."

This is plain broken. 
I missed the call to express my input, but you can find it on the reflector. Comments on my email is welcome.

- PCP authentication draft need updated based on discussion (done, discussed on interim)
The issue of using PANA vs EAP-o-PCP is still open. How do you guys plan on resolving that? 

Alper


--Apple-Mail=_54BFB537-12EF-42B3-AC60-3F7CDD10CA3C-- From phdgang@gmail.com Mon May 6 02:07:06 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F10321F8529 for ; Mon, 6 May 2013 02:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_17=0.6, J_CHICKENPOX_74=0.6, 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 qR4nPjklSXpR for ; Mon, 6 May 2013 02:07:01 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C6C8B21F8519 for ; Mon, 6 May 2013 02:07:00 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id k19so411796qcs.31 for ; Mon, 06 May 2013 02:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=OWA5+RtAE6BfO433R3rtm7UDP6KDmy1rmTSgmUk2xuM=; b=Kt4yof/iEzyuTQ2rfV+/YfW6L5QuThKL2tg52MRzAY33LFHIJQcvYGoB/boAls/Mcs 1bE87/kPGAHRpjdyy+Ybd46tY/MGDsKzA/6UgcdcJ42YhEpSqKdEbN1h49zN49qm1J3F HNeMH4D/EneBPvGeql8mwnXuLxur38YfnUNon/b9v6R+VRQ+JY9PQu4noAE7em73aghp WsPP+zjR14cF94r6darjawKpJttcZyKa6nyW48CitSLnieD4ASaYV1j752yMbXPCJoS9 VuBfKXKnHszse7zyimXe2dHE3bOU7pmKWHwSNo/8D174OBvRzjvGCAwmkF3IUzbNiSlP oOrA== MIME-Version: 1.0 X-Received: by 10.224.173.6 with SMTP id n6mr22818330qaz.46.1367831220197; Mon, 06 May 2013 02:07:00 -0700 (PDT) Received: by 10.49.17.103 with HTTP; Mon, 6 May 2013 02:07:00 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A1497A1E9@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A1497A1E9@xmb-rcd-x10.cisco.com> Date: Mon, 6 May 2013 17:07:00 +0800 Message-ID: From: GangChen To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "pcp@ietf.org" Subject: Re: [pcp] comments for draft "Analysis of Port Control P0rotocol 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: Mon, 06 May 2013 09:07:06 -0000 Hi Tiru, Thanks for the deep and detailed review. I apology for my late reply. In order to easy the discussion, I excerpt your comments and add the replies as below. Section 2.1 Would FW as network service be offered to all Mobile subscribers or based on some premium paid to some subscribers only ? [cg] FW would offer to all subscribers as a basic service where will the Firewalls be located in the Mobile Network when SIPTO is taken into consideration? [cg] Each entry has their-own FW. In SIPTO case, there are two FWs located in differnet data paths How is this problem different from let=92s say Firewall offered by SP ? [cg] The discussion is more focused on issues in mobile networks. I guess the issue is orthogonal to the FW in SP or NP. SP could take mobile network as a access path. Therefore, the benefits could also applicable to SP. There are various modes in which Firewalls operate as explained in http://tools.ietf.org/html/draft-ietf-opsawg-firewalls-01; [1] you may want to clarify that you are referring to a firewall configuration which =93Block all outside-initiated traffic, allow all inside-initiated Traffic=94 [cg] I would add clarification texts in the next update. The FW in the networks falls into the Category I [2] will the subscriber be allowed to modify the Firewall configuration ? [cg] Subscriber can't modify configuration. It's only allowed using administrator account. [3] what is the Firewall capability offered by the Mobile Network - Layer 4 and/or Layer 7 ? [cg] Only Layer4. Going upper layer requires DPI which is not widely deplo= yed. PCP messages are required to refresh the mapping. Further application keep-alive would still be required to refresh the server state. For more details refer to http://tools.ietf.org/html/draft-reddy-pcp-optimize-keepalives-01#section-3= .4 [cg] I made following revision. =3D=3DOld=3D=3D thus would not need to be using keep-alive to keep the Firewall session ope= n. =3D=3DNew=3D=3D thus would lighten the traffic flow of keep-alive by reducing the number of sending packets Section 2.2/2.3 The problems of 2.2 and 2.3 seem to be also valid if the MN is using Wifi in a Hot spot, Home Network etc. Why is this specific to 3GPP network ? [cg] Section 2.2 is specific to 3GPP network, since there are different channels using for control messages and actual data trasport in 3GPP network. Those beacon messages are occupy the data channels so as to congest voice calls. This issue would not occur in wifi case. We may need to clarify this in next version. [cg] Section 2.3 may applicable to wifi case. But there is different state-changes in 3GPP networks. We may clarify that? BTW, we don't want to differentiate 3GPPP and wifi. Because wifi is also a part of mobile network. Section 4 How will MN receive any other information that is provided by DHCP server ? [cg] MN usually receive the information through PCO Will these techniques solve the IPv4 problem ? [cg] Those are potential solutions. I guess the document is more targeted to the discovery of specific issues. We may add comments on those solutions in the next. Section 5 Some time back there was discussion in the netext WG that =96 Mobile Networks should move away from the model of building application specific APN's and consolidate them into a single home network. For more details refer to http://tools.ietf.org/html/draft-gundavelli-netext-multiple-apn-pmipv6-01 [cg] This work is triggered by integration of 3GPP networks and Wifi networks. PMIPv6 based S2a can't is restricted with a single APN/home network. Therefore, the consolidation of multiple APN feed this requirement. However,this may not be a trend in a pure 3GPP environment. At least, 3GPP doesn't discuss the APN aggregation and multiple APN still widely used. Section 6 This is a problem with any protocol using UDP. Retransmission is a case of error; With both PCP client and server in the same network =96 will retransmission of PCP request be frequent because of packet loss ? This is a implementation problem on the Mobile Device and not a protocol problem; PCP client could either be implemented in the kernel or each application could be using its own PCP client. [cg] Compared to packet loss, we are more concerning about the roaming cas= e. MN with PCP-client may roam to a network where there is no PCP-server avail= able. Subsribers may easily find their MN running into outage when they are on business trips. That is not a protocol problem. We also not intend to change protocol or impede the retransmission. However, it's desirable to notice this potential consumption and configure optimal value to each parameter in order to optimize radio link usage. That may easy mobile-operator's life to deploy PCP. Section 7 I am not sure how NAT/Firewall would do this when rebooted ? Are you referring they need persistence storage ? [cg] I'm referring to using HA with hot-standby Unsolicited responses could also be sent for other PCP requests like MAP. [cg] Would you point me the description in PCP-base document? I may miss t= hat. Section 8 Please clarify the procedure the PCP client must follow - Delete the Mappings on the old PCP server; before sending PCP requests to the new PCP server ? [cg] that is a good suggestion. I will add the procedure at next udpate. TOF and NAT are co-located, so what is the problem in using RAB ID ? SIPTO rules could be different per subscriber ; so the PCP proxy needs to determine that the PCP request is coming from a specific client to pick the associated SIPTO rules for the subscriber so as to determine if the request is to be processed locally or forwarded to the PCP server in the EPC [cg] The issue could refer to http://www.3gpp.org/ftp/Specs/html-info/23060.htm. In the TS 23.060 V10.0.0, the description of "SIPTO with Traffic Offload Function" states: "TOF inspects the NAS and RANAP messages to build the local UE context and local session context. When a RAB is requested to be set up and should be offloaded, ..." Therefore, the offloaded IP flow is identified with RAB-ID, other than IP 5-tuples. If the intention is to adopt PCP-proxy with advanced functions in the case of multiple PCP servers, PCP proxy must understand RAB-ID. Additional mapping function may be required. Section 9 Both NAT/Firewall and AAA are in the same administrative domain in the Mobile Network and that would be the same problem with NAT/Firewall in the Enterprise Netw= ork. Please clarify how is this problem unique to 3GPP networks only ? [cg] We will make futher revision for this section. More clarification will be added. Best Regards Gang 2013/4/27, Tirumaleswar Reddy (tireddy) : > Hi Gang, > > As per the discussion during the interim; attached my comments for the > draft. > > Regards, > --Tiru. > From tireddy@cisco.com Tue May 7 05:50:17 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC4721F8FDF for ; Tue, 7 May 2013 05:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.91 X-Spam-Level: X-Spam-Status: No, score=-7.91 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_17=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WV2Ja3tdvEY1 for ; Tue, 7 May 2013 05:50:12 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2B65721F86D6 for ; Tue, 7 May 2013 05:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8551; q=dns/txt; s=iport; t=1367931012; x=1369140612; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kUpLRuXxTR6x1WjPFfw43y43k6pDwllwd6e87Cl7ZjQ=; b=YTlNu1yL36Qoy8H28IR+CJiSIx3ofgFNJDYxLyeSVTsiERp9NGahary7 3gk66ZIAOxbdDCs/mxfbLXXDbNLn/B/bZLboJ4IqbCptlO/VtOgeWaqCn 6vaBHUCI7k6C+kOEMX6OVquyGZrNTVww7NmXpzeLBsaFNQgopp9zSbodl A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAN73iFGtJXG9/2dsb2JhbABQgwc3vwmBBxZ0ghgHAQEBAwE6PwwEAgEIEQQBAQsLCQkHIREUCQgBAQQOBQgRAoUuB4IqAwkGDLJChjQNiBSMW4EqezEHBgSCaGEDk1+Ba4MKim2FIYMNgWo9 X-IronPort-AV: E=Sophos;i="4.87,628,1363132800"; d="scan'208";a="207345999" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 07 May 2013 12:50:11 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r47CoBKw010468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 May 2013 12:50:11 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Tue, 7 May 2013 07:50:11 -0500 From: "Tirumaleswar Reddy (tireddy)" To: GangChen Thread-Topic: comments for draft "Analysis of Port Control P0rotocol in Mobile Network" Thread-Index: Ac5C9nlNcG7iPGLXS3S0op/ohrTZFAHbICUAAATjSEA= Date: Tue, 7 May 2013 12:50:10 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B669A9@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A1497A1E9@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] comments for draft "Analysis of Port Control P0rotocol 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: Tue, 07 May 2013 12:50:17 -0000 Hi Gang, Please see inline > -----Original Message----- > From: GangChen [mailto:phdgang@gmail.com] > Sent: Monday, May 06, 2013 2:37 PM > To: Tirumaleswar Reddy (tireddy) > Cc: pcp@ietf.org > Subject: Re: comments for draft "Analysis of Port Control P0rotocol in Mo= bile > Network" >=20 > Hi Tiru, >=20 > Thanks for the deep and detailed review. > I apology for my late reply. > In order to easy the discussion, I excerpt your comments and add the > replies as below. >=20 > Section 2.1 > Would FW as network service be offered to all Mobile subscribers or > based on some premium paid to some subscribers only ? >=20 > [cg] FW would offer to all subscribers as a basic service >=20 > where will the Firewalls be located in the Mobile Network when SIPTO > is taken into consideration? >=20 > [cg] Each entry has their-own FW. In SIPTO case, there are two FWs > located in differnet data paths >=20 > How is this problem different from let's say Firewall offered by SP ? >=20 > [cg] The discussion is more focused on issues in mobile networks. > I guess the issue is orthogonal to the FW in SP or NP. > SP could take mobile network as a access path. Therefore, the benefits > could also applicable to SP. If the use-case is applicable to other networks, I would suggest to explici= tly state that to avoid confusion. >=20 > There are various modes in which Firewalls operate as explained in > http://tools.ietf.org/html/draft-ietf-opsawg-firewalls-01; > [1] you may want to clarify that you are referring to a firewall > configuration which "Block all outside-initiated traffic, allow all > inside-initiated > Traffic" >=20 > [cg] I would add clarification texts in the next update. The FW in > the networks falls into the Category I Ok. >=20 > [2] will the subscriber be allowed to modify the Firewall configuration ? >=20 > [cg] Subscriber can't modify configuration. It's only allowed using > administrator account. >=20 > [3] what is the Firewall capability offered by the Mobile Network - > Layer 4 and/or Layer 7 ? >=20 > [cg] Only Layer4. Going upper layer requires DPI which is not widely > deployed. >=20 > PCP messages are required to refresh the mapping. Further application > keep-alive would still be required to refresh the server state. > For more details refer to > http://tools.ietf.org/html/draft-reddy-pcp-optimize-keepalives-01#section= -3.4 >=20 > [cg] I made following revision. >=20 > =3D=3DOld=3D=3D > thus would not need to be using keep-alive to keep the Firewall session o= pen. >=20 > =3D=3DNew=3D=3D >=20 > thus would lighten the traffic flow of keep-alive by reducing the > number of sending packets >=20 >=20 >=20 > Section 2.2/2.3 >=20 > The problems of 2.2 and 2.3 seem to be also valid if the MN is using > Wifi in a Hot spot, Home Network etc. Why is this specific to 3GPP > network ? >=20 > [cg] Section 2.2 is specific to 3GPP network, since there are > different channels using for control messages and actual data trasport > in 3GPP network. > Those beacon messages are occupy the data channels so as to congest > voice calls. This issue would not occur in wifi case. > We may need to clarify this in next version. Yes, that would help. >=20 > [cg] Section 2.3 may applicable to wifi case. But there is different > state-changes in 3GPP networks. We may clarify that? >=20 > BTW, we don't want to differentiate 3GPPP and wifi. Because wifi is > also a part of mobile network. >=20 > Section 4 >=20 > How will MN receive any other information that is provided by DHCP server= ? >=20 > [cg] MN usually receive the information through PCO >=20 > Will these techniques solve the IPv4 problem ? >=20 > [cg] Those are potential solutions. I guess the document is more > targeted to the discovery of specific issues. > We may add comments on those solutions in the next. >=20 > Section 5 >=20 > Some time back there was discussion in the netext WG that - Mobile > Networks should move away from the model > of building application specific APN's and consolidate them into a > single home network. > For more details refer to > http://tools.ietf.org/html/draft-gundavelli-netext-multiple-apn-pmipv6-01 >=20 > [cg] This work is triggered by integration of 3GPP networks and Wifi > networks. PMIPv6 based S2a can't is restricted > with a single APN/home network. Therefore, the consolidation of > multiple APN feed this requirement. > However,this may not be a trend in a pure 3GPP environment. > At least, 3GPP doesn't discuss the APN aggregation and multiple APN > still widely used. Ok. >=20 > Section 6 >=20 > This is a problem with any protocol using UDP. Retransmission is a > case of error; > With both PCP client and server in the same network - will > retransmission of PCP request be frequent because of packet loss ? >=20 > This is a implementation problem on the Mobile Device and not a > protocol problem; > PCP client could either be implemented in the kernel or each > application could be using its own PCP client. >=20 >=20 > [cg] Compared to packet loss, we are more concerning about the roaming c= ase. > MN with PCP-client may roam to a network where there is no PCP-server > available. > Subsribers may easily find their MN running into outage when they are > on business trips. > That is not a protocol problem. We also not intend to change protocol > or impede the retransmission. > However, it's desirable to notice this potential consumption and > configure optimal value to each parameter in order to optimize radio > link usage. > That may easy mobile-operator's life to deploy PCP. >=20 >=20 > Section 7 >=20 > I am not sure how NAT/Firewall would do this when rebooted ? > Are you referring they need persistence storage ? >=20 > [cg] I'm referring to using HA with hot-standby clarify that. >=20 > Unsolicited responses could also be sent for other PCP requests like MAP. >=20 > [cg] Would you point me the description in PCP-base document? I may miss > that. It's explained in the following section http://tools.ietf.org/html/rfc6887#= section-14.2 >=20 >=20 > Section 8 >=20 > Please clarify the procedure the PCP client must follow - Delete the > Mappings on the old PCP server; > before sending PCP requests to the new PCP server ? >=20 > [cg] that is a good suggestion. I will add the procedure at next udpate. >=20 > TOF and NAT are co-located, so what is the problem in using RAB ID ? > SIPTO rules could be different per subscriber ; > so the PCP proxy needs to determine that the PCP request is coming > from a specific client > to pick the associated SIPTO rules for the subscriber so as to > determine if the request is to be processed locally or forwarded to > the PCP server in the EPC >=20 > [cg] The issue could refer to > http://www.3gpp.org/ftp/Specs/html-info/23060.htm. > In the TS 23.060 V10.0.0, the description of "SIPTO with Traffic > Offload Function" states: > "TOF inspects the NAS and RANAP messages to build the local UE context > and local session context. > When a RAB is requested to be set up and should be offloaded, ..." >=20 > Therefore, the offloaded IP flow is identified with RAB-ID, other than > IP 5-tuples. > If the intention is to adopt PCP-proxy with advanced functions in the > case of multiple PCP servers, PCP proxy must understand RAB-ID. > Additional mapping function may be required. I thought there are multiple techniques, the other one is : The new NAT would be informed about the UE point-of-attachment by the Home = Node B Management System (HNS) (HNS is updated by the Node B (cell tower)).= The new NAT is updated with the traffic offload policy rules for the subsc= riber by the HNS. Does this also require using RAB-ID ? Regards, Tiru. >=20 >=20 > Section 9 >=20 >=20 > Both NAT/Firewall and AAA are in the same administrative domain in the > Mobile Network > and that would be the same problem with NAT/Firewall in the Enterprise > Network. > Please clarify how is this problem unique to 3GPP networks only ? >=20 > [cg] We will make futher revision for this section. More > clarification will be added. >=20 > Best Regards >=20 > Gang >=20 > 2013/4/27, Tirumaleswar Reddy (tireddy) : > > Hi Gang, > > > > As per the discussion during the interim; attached my comments for the > > draft. > > > > Regards, > > --Tiru. > > From repenno@cisco.com Tue May 7 06:02:29 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAC321F902D for ; Tue, 7 May 2013 06:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8Oa5l6iI7sE for ; Tue, 7 May 2013 06:02:24 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id AFB4521F8FDB for ; Tue, 7 May 2013 06:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=594; q=dns/txt; s=iport; t=1367931744; x=1369141344; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=K7TMSTkGkmYA0JiGD1sfGZVSOkp3QsGcvDwcAyk12LM=; b=EcvrM8KOWSmCnrp1yKcgKCG1DtdlORqWstU7GFEt4/D4WEE88GWBIzZ0 u6BaONknBYpuPu+1cDmLIKpz09gjapQdtCSKH0kT6c3mYXDB1KlwET/GI mhwT76+MNIt3yO/5mhLhSimg9xrR/nSmC0MzSmX3VLQpHbkqIzTow/muL E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0GAHT6iFGtJV2a/2dsb2JhbABQgwc3gnW8FIEHFm0HgiEBBB0dUQEaEBRCFxAEG4gEDKEjkSWOVY1vgRGDKmEDmFSQDoFVgTiBcjU X-IronPort-AV: E=Sophos;i="4.87,628,1363132800"; d="scan'208";a="204370362" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 07 May 2013 13:02:24 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r47D2NTQ013292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 7 May 2013 13:02:24 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 7 May 2013 08:02:23 -0500 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) Thread-Index: AQHOSyMd+UONupvK9kCM5yrtYUJ65w== Date: Tue, 7 May 2013 13:02:23 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040907BCD0@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.81.12] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) 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, 07 May 2013 13:02:29 -0000 This email communicates the start of a Working Group Last Call for the following draft: Title : PCP Description Option URL : http://tools.ietf.org/html/draft-ietf-pcp-description-option-00 Authors: M. Boucadair et al. The WGLC ends May 21st. If this draft is important to your implementation or architecture, now is the last chance to provide comments and request changes. Silence means you agree with everything in it. Beyond general comments, we also need official reviewers for the draft. If you are willing to volunteer, please send an email. Regards, Reinaldo From repenno@cisco.com Tue May 7 06:05:40 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A27721F86CE for ; Tue, 7 May 2013 06:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaQE+-Oheq+a for ; Tue, 7 May 2013 06:05:35 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 85A1C21F86CA for ; Tue, 7 May 2013 06:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=592; q=dns/txt; s=iport; t=1367931935; x=1369141535; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=YARYoIFbgWICUwdDtojDGZXaS3Euh/qnwxWaraQgLhI=; b=YIEWKDhQCT2oiV/Ljqqoo5FvFXWRAL7WFzA9rgy3QBHuONEj0U7Nj1Tf IbD73z6gq8aVtzoBkr6Votgfo7ZBWliK8q6GNCEl/4fPCGiYUx5/TKMG4 vyhUi9O6waG8QFtkAqQ6XN75lWhGj2qjCKWoOGJHGE3/qeq/WIUaDjA1T c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0GAI/7iFGtJV2c/2dsb2JhbABQgwc3gnW8FIEHFm0HgiEBBB0dUQEaEBQFPRcOAgQbiAQMoSSRJY5VjW+BETiCcmEDmFSQDoFVgTiBcjU X-IronPort-AV: E=Sophos;i="4.87,628,1363132800"; d="scan'208";a="207354410" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 07 May 2013 13:05:35 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r47D5YWL003632 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 7 May 2013 13:05:34 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 7 May 2013 08:05:34 -0500 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: WGLC on Learn NAT64 PREFIX64s using PCP (http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-00) Thread-Index: AQHOSyOPDPtn2RJVIkOGHb2ezwruEw== Date: Tue, 7 May 2013 13:05:34 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040907BDAA@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.81.12] Content-Type: text/plain; charset="us-ascii" Content-ID: <74C197DA7CEC5C478E1F3D55B40CAC26@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] WGLC on Learn NAT64 PREFIX64s using PCP (http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-00) 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, 07 May 2013 13:05:40 -0000 This email communicates the start of a Working Group Last Call for the following draft: Title : Learn NAT64 PREFIX64s using PCP URL : http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-00 Authors: M. Boucadair The WGLC ends May 21st. If this draft is important to your implementation or architecture, now is the last chance to provide comments and request changes. Silence means you agree with everything in it. Beyond general comments, we also need official reviewers for the draft. If you are willing to volunteer, please send an email. Regards, Reinaldo From sardella@comcast.net Tue May 7 06:13:07 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A50D21F89DE for ; Tue, 7 May 2013 06:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mk-itkDOQRTH for ; Tue, 7 May 2013 06:13:02 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7AF21F8930 for ; Tue, 7 May 2013 06:13:02 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta06.westchester.pa.mail.comcast.net with comcast id YztG1l0020EZKEL561D1Jk; Tue, 07 May 2013 13:13:01 +0000 Received: from sardella.org ([66.31.217.148]) by omta01.westchester.pa.mail.comcast.net with comcast id Z1D01l00n3ChNai3M1D1F2; Tue, 07 May 2013 13:13:01 +0000 Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by sardella.org (8.13.1/8.13.1) with ESMTP id r47DCx4n032581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 May 2013 09:13:00 -0400 Message-ID: <5188FDDB.5050903@comcast.net> Date: Tue, 07 May 2013 09:12:59 -0400 From: Norman Sardella User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "pcp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367932381; bh=lStUUYadRjkwfmH0m5k6/eqqHqax4ZX3sx/0NKqypBw=; h=Received:Received:Received:Message-ID:Date:From:MIME-Version:To: Subject:Content-Type; b=oGzOGj/7ZniwU/kkcXgOavBgeMbrYlPVN8Fa6R05VeOZrw+VADjCz3E3SjDaJurjE T/Vrqp8+smvXiZoaLLcOXVQy88fAR8358za8mv7KphLvVBjUz+whIwJdyzd58B/nIO ZhlFhu0zkjiX/MsarRNbYVislI+f5lxyeiv0Kh49qNB8k77uSlsulKRRwSb1G19u5x XOchPVOmC8sAeQBfIfvsS5dStnxq82OdQaZd8pkpYOoyPjPBZPgrBEu1jDEQTew85w QUmK5gwRoimLUP/cYsN6/XErZk2DL14a+MBKrhXv/5O1M/gYhSQgjmmjQJuQnD+nVj deS35GtN599Bw== Subject: [pcp] PCP MAP expiring connections 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, 07 May 2013 13:13:07 -0000 The following section was updated in RFC 6887. I understand the section as follows The MAP or PEER request with lifetime of 0 will only set the assigned lifetime to 0 (i.e., delete the mapping) if the internal host had not sent a packet using that mapping for the idle-timeout time, otherwise the assigned lifetime will be the remaining idle-timeout time. Can someone clarify the meaning of idle-timeout? How is it defined/configured and what does it mean to be "idle"? Is "idle" a new state in a mapping where the mapping exists but no packets have used it for this defined "idle-timeout" period? Thanks http://tools.ietf.org/html/rfc6887#section-15 > When using NAT, the same external port may be assigned for use by > different internal hosts at different times. For example, if an > internal host using an external port ceases sending traffic using > that port, then its mapping may expire, and then later the same > external port may be assigned to a new internal host. The new > internal host could then receive incoming traffic that was intended > for the previous internal host. This generally happens > inadvertently, and this reassignment of the external port only > happens after the current holder of the external port has ceased > using it for some period of time. It would be unacceptable if an > attacker could use PCP to intentionally speed up this reassignment of > the external port in order to deliberately steal traffic intended for > the current holder, by (i) spoofing PCP requests using the current > holder's source IP address and mapping nonce to fraudulently delete > the mapping or shorten its lifetime, and then (ii) subsequently > claiming the external port for itself. > Therefore, in the simple security model, to protect against this > attack, PCP MUST NOT allow a PCP request (even a PCP request that > appears to come from the current holder of the mapping) to cause a > mapping to expire sooner than it would naturally have expired > otherwise by virtue of outbound traffic keeping the mapping active. > A PCP server MUST set the lifetime of a mapping to no less than the > remaining time before the mapping would expire if no further outbound > traffic is seen for that mapping. This means a MAP or PEER request > with lifetime of 0 will only set the assigned lifetime to 0 (i.e., > delete the mapping) if the internal host had not sent a packet using > that mapping for the idle-timeout time, otherwise the assigned > lifetime will be the remaining idle-timeout time. > > Finally, to reduce unwanted traffic and data corruption for both TCP > and UDP, the assigned external port created by the MAP Opcode or PEER > Opcode SHOULD NOT be reused for an interval equal to the reuse time > limit enforced by the NAT for its implicit dynamic mappings > (typically, the maximum TCP segment lifetime of 2 minutes [RFC0793]). > Furthermore, to reduce port stealing attacks, the assigned external > port also SHOULD NOT be reused for an interval equal to the time the > PCP- controlled device would normally maintain an idle (no traffic) > implicit dynamic mapping (e.g., 2 minutes for UDP [RFC4787] and 124 > minutes for TCP [RFC5382]). However, within these time windows, the > PCP server SHOULD allow an external port to be reclaimed by the same > client, where "same client" means "same internal IP address, internal > port, and mapping nonce". From simon.perreault@viagenie.ca Tue May 7 06:20:56 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680DA21F859B for ; Tue, 7 May 2013 06:20:56 -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 2mlkD33UPfCi for ; Tue, 7 May 2013 06:20:55 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 73BB021F859A for ; Tue, 7 May 2013 06:20:55 -0700 (PDT) Received: from porto.nomis80.org (87-231-137-212.rev.numericable.fr [87.231.137.212]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8886B470C0 for ; Tue, 7 May 2013 09:20:54 -0400 (EDT) Message-ID: <5188FFB5.9000508@viagenie.ca> Date: Tue, 07 May 2013 15:20:53 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: pcp@ietf.org References: <5188FDDB.5050903@comcast.net> In-Reply-To: <5188FDDB.5050903@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] PCP MAP expiring connections 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, 07 May 2013 13:20:56 -0000 Le 2013-05-07 15:12, Norman Sardella a écrit : > > The following section was updated in RFC 6887. Note that it's just a rewording. No behavioural change. > > I understand the section as follows > The MAP or PEER request with lifetime of 0 will only set the > assigned lifetime to 0 (i.e., delete the mapping) if the internal > host had not sent a packet using that mapping for the idle-timeout > time, otherwise the assigned lifetime will be the remaining > idle-timeout time. > > Can someone clarify the meaning of idle-timeout? > How is it defined/configured and what does it mean to be "idle"? Is > "idle" a new state in a mapping where the mapping exists but no packets > have used it for this defined "idle-timeout" period? The "idle-timeout time" is the time it takes for the NAT to delete a mapping on which there is no traffic. For example, a NAT could delete a UDP mapping after 60 seconds if there is no traffic. Example: consider a mapping. That mapping's lifetime was initially set with PCP to 1000 seconds, and there are 900 seconds remaining. The last packet seen on this mapping was 15 seconds ago. The PCP server receives a lifetime=0 request to delete the mapping. It would set the mapping's lifetime to 45 seconds. That is, the idle-timeout time (60) minus the time since the last packet seen on the mapping (15). Note that the idle-timeout time varies across NAT implementations, protocols, connection tracking states, time of day, current load, etc. 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 phdgang@gmail.com Wed May 8 08:13:24 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5CE21F9356 for ; Wed, 8 May 2013 08:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_17=0.6, J_CHICKENPOX_74=0.6, 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 JqlF2KvkUxNj for ; Wed, 8 May 2013 08:13:20 -0700 (PDT) Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by ietfa.amsl.com (Postfix) with ESMTP id A9C8D21F9079 for ; Wed, 8 May 2013 08:13:20 -0700 (PDT) Received: by mail-qe0-f41.google.com with SMTP id b10so1169290qen.14 for ; Wed, 08 May 2013 08:13:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=95b7n7OZ4ob7iYWr3loBocgBnXjS7MR64nc79qB9zNE=; b=AC2YyTitu1M1ePxIi8uJLwxFSKrztHkKRr/qJGXJ3r+ppfFCr1bdqqi0U5MPec/QPN +B4J516AMagnDsJ0cfZCYIXPMOBwmYZme2z1FUQImXMhrAXskxhY0t0qMo9kapY4lM45 dls3TF1R0N4eV5gidNqa3dE7C2Bt1WELy32yTBJw/h6neT+NbUKd5LgkcSVTnGNYjs9c l79EJ/kw16JuYBUIrwnCNUbyJYJMaMIwUVDPhGpaVh5JEyzt2WjxY3iw7qZSWLkn0gIl MQaPjyI4eBvfRGXIBV+13upduOMVX3BDZm64Du63v1vpy0HNW1aAyuebofsLw9pSUTWD 0jGg== MIME-Version: 1.0 X-Received: by 10.229.151.134 with SMTP id c6mr2022373qcw.58.1368025999923; Wed, 08 May 2013 08:13:19 -0700 (PDT) Received: by 10.49.94.39 with HTTP; Wed, 8 May 2013 08:13:19 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A14B669A9@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A1497A1E9@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A14B669A9@xmb-rcd-x10.cisco.com> Date: Wed, 8 May 2013 23:13:19 +0800 Message-ID: From: GangChen To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "pcp@ietf.org" Subject: Re: [pcp] comments for draft "Analysis of Port Control P0rotocol 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: Wed, 08 May 2013 15:13:24 -0000 2013/5/7, Tirumaleswar Reddy (tireddy) : > Hi Gang, > > Please see inline > >> -----Original Message----- >> From: GangChen [mailto:phdgang@gmail.com] >> Sent: Monday, May 06, 2013 2:37 PM >> To: Tirumaleswar Reddy (tireddy) >> Cc: pcp@ietf.org >> Subject: Re: comments for draft "Analysis of Port Control P0rotocol in >> Mobile >> Network" >> >> Hi Tiru, >> >> Thanks for the deep and detailed review. >> I apology for my late reply. >> In order to easy the discussion, I excerpt your comments and add the >> replies as below. >> >> Section 2.1 >> Would FW as network service be offered to all Mobile subscribers or >> based on some premium paid to some subscribers only ? >> >> [cg] FW would offer to all subscribers as a basic service >> >> where will the Firewalls be located in the Mobile Network when SIPTO >> is taken into consideration? >> >> [cg] Each entry has their-own FW. In SIPTO case, there are two FWs >> located in differnet data paths >> >> How is this problem different from let's say Firewall offered by SP ? >> >> [cg] The discussion is more focused on issues in mobile networks. >> I guess the issue is orthogonal to the FW in SP or NP. >> SP could take mobile network as a access path. Therefore, the benefits >> could also applicable to SP. > > If the use-case is applicable to other networks, I would suggest to > explicitly state that to avoid confusion. Ok.We will update to clarify applicable cases >> >> There are various modes in which Firewalls operate as explained in >> http://tools.ietf.org/html/draft-ietf-opsawg-firewalls-01; >> [1] you may want to clarify that you are referring to a firewall >> configuration which "Block all outside-initiated traffic, allow all >> inside-initiated >> Traffic" >> >> [cg] I would add clarification texts in the next update. The FW in >> the networks falls into the Category I > > Ok. > >> >> [2] will the subscriber be allowed to modify the Firewall configuration ? >> >> [cg] Subscriber can't modify configuration. It's only allowed using >> administrator account. >> >> [3] what is the Firewall capability offered by the Mobile Network - >> Layer 4 and/or Layer 7 ? >> >> [cg] Only Layer4. Going upper layer requires DPI which is not widely >> deployed. >> >> PCP messages are required to refresh the mapping. Further application >> keep-alive would still be required to refresh the server state. >> For more details refer to >> http://tools.ietf.org/html/draft-reddy-pcp-optimize-keepalives-01#section-3.4 >> >> [cg] I made following revision. >> >> ==Old== >> thus would not need to be using keep-alive to keep the Firewall session >> open. >> >> ==New== >> >> thus would lighten the traffic flow of keep-alive by reducing the >> number of sending packets >> >> >> >> Section 2.2/2.3 >> >> The problems of 2.2 and 2.3 seem to be also valid if the MN is using >> Wifi in a Hot spot, Home Network etc. Why is this specific to 3GPP >> network ? >> >> [cg] Section 2.2 is specific to 3GPP network, since there are >> different channels using for control messages and actual data trasport >> in 3GPP network. >> Those beacon messages are occupy the data channels so as to congest >> voice calls. This issue would not occur in wifi case. >> We may need to clarify this in next version. > > Yes, that would help. > >> >> [cg] Section 2.3 may applicable to wifi case. But there is different >> state-changes in 3GPP networks. We may clarify that? >> >> BTW, we don't want to differentiate 3GPPP and wifi. Because wifi is >> also a part of mobile network. >> >> Section 4 >> >> How will MN receive any other information that is provided by DHCP server >> ? >> >> [cg] MN usually receive the information through PCO >> >> Will these techniques solve the IPv4 problem ? >> >> [cg] Those are potential solutions. I guess the document is more >> targeted to the discovery of specific issues. >> We may add comments on those solutions in the next. >> >> Section 5 >> >> Some time back there was discussion in the netext WG that - Mobile >> Networks should move away from the model >> of building application specific APN's and consolidate them into a >> single home network. >> For more details refer to >> http://tools.ietf.org/html/draft-gundavelli-netext-multiple-apn-pmipv6-01 >> >> [cg] This work is triggered by integration of 3GPP networks and Wifi >> networks. PMIPv6 based S2a can't is restricted >> with a single APN/home network. Therefore, the consolidation of >> multiple APN feed this requirement. >> However,this may not be a trend in a pure 3GPP environment. >> At least, 3GPP doesn't discuss the APN aggregation and multiple APN >> still widely used. > > Ok. > >> >> Section 6 >> >> This is a problem with any protocol using UDP. Retransmission is a >> case of error; >> With both PCP client and server in the same network - will >> retransmission of PCP request be frequent because of packet loss ? >> >> This is a implementation problem on the Mobile Device and not a >> protocol problem; >> PCP client could either be implemented in the kernel or each >> application could be using its own PCP client. >> >> >> [cg] Compared to packet loss, we are more concerning about the roaming >> case. >> MN with PCP-client may roam to a network where there is no PCP-server >> available. >> Subsribers may easily find their MN running into outage when they are >> on business trips. >> That is not a protocol problem. We also not intend to change protocol >> or impede the retransmission. >> However, it's desirable to notice this potential consumption and >> configure optimal value to each parameter in order to optimize radio >> link usage. >> That may easy mobile-operator's life to deploy PCP. >> >> >> Section 7 >> >> I am not sure how NAT/Firewall would do this when rebooted ? >> Are you referring they need persistence storage ? >> >> [cg] I'm referring to using HA with hot-standby > > clarify that. > >> >> Unsolicited responses could also be sent for other PCP requests like MAP. >> >> [cg] Would you point me the description in PCP-base document? I may miss >> that. > > It's explained in the following section > http://tools.ietf.org/html/rfc6887#section-14.2 thanks > >> >> >> Section 8 >> >> Please clarify the procedure the PCP client must follow - Delete the >> Mappings on the old PCP server; >> before sending PCP requests to the new PCP server ? >> >> [cg] that is a good suggestion. I will add the procedure at next udpate. >> >> TOF and NAT are co-located, so what is the problem in using RAB ID ? >> SIPTO rules could be different per subscriber ; >> so the PCP proxy needs to determine that the PCP request is coming >> from a specific client >> to pick the associated SIPTO rules for the subscriber so as to >> determine if the request is to be processed locally or forwarded to >> the PCP server in the EPC >> >> [cg] The issue could refer to >> http://www.3gpp.org/ftp/Specs/html-info/23060.htm. >> In the TS 23.060 V10.0.0, the description of "SIPTO with Traffic >> Offload Function" states: >> "TOF inspects the NAS and RANAP messages to build the local UE context >> and local session context. >> When a RAB is requested to be set up and should be offloaded, ..." >> >> Therefore, the offloaded IP flow is identified with RAB-ID, other than >> IP 5-tuples. >> If the intention is to adopt PCP-proxy with advanced functions in the >> case of multiple PCP servers, PCP proxy must understand RAB-ID. >> Additional mapping function may be required. > > I thought there are multiple techniques, the other one is : > > The new NAT would be informed about the UE point-of-attachment by the Home > Node B Management System (HNS) (HNS is updated by the Node B (cell tower)). > The new NAT is updated with the traffic offload policy rules for the > subscriber by the HNS. > > Does this also require using RAB-ID ? As far as I know, NAT-based technique was documented in TR 23.829 (http://www.3gpp.org/ftp/Specs/html-info/23829.htm). It doesn't involve RAB-ID. However, this solution can't be accepted as TS (Technical Specification) level. TR 23.829 only stands for "informational" level. BRs Gang > Regards, > Tiru. > >> >> >> Section 9 >> >> >> Both NAT/Firewall and AAA are in the same administrative domain in the >> Mobile Network >> and that would be the same problem with NAT/Firewall in the Enterprise >> Network. >> Please clarify how is this problem unique to 3GPP networks only ? >> >> [cg] We will make futher revision for this section. More >> clarification will be added. >> >> Best Regards >> >> Gang >> >> 2013/4/27, Tirumaleswar Reddy (tireddy) : >> > Hi Gang, >> > >> > As per the discussion during the interim; attached my comments for the >> > draft. >> > >> > Regards, >> > --Tiru. >> > > From dwing@cisco.com Wed May 8 11:12:24 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAA221F90C1 for ; Wed, 8 May 2013 11:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfFgfoFJ-KCB for ; Wed, 8 May 2013 11:12:20 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3894D21F9377 for ; Wed, 8 May 2013 11:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2265; q=dns/txt; s=iport; t=1368036739; x=1369246339; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=YFgNeqHY+xxx5UUhhpDNLM2Y9XulVXWcfyJVtAMjY7U=; b=cJR8tLlZJ9HfyfP2K4FSXHbyMFjGZnB/j551nQXbvAwglT5Ebc4eKU1R fx1QCZavKoDf1wOhnpKcrFBxwlSNVq+wd6QeOKwi0swiQi/u5aJ9I2J3c CPHXAlTfBUaCUVDrjYmbwBYcOlCZMKKMzxJEk4098kD4j44oGFQrQMdEH A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAJeSilGrRDoG/2dsb2JhbABSgwc3Ab8VehZ0gh8BAQEDAQEBASRHCwULC0YnMAYTiAYFDcIEjnUzB4J0YQOJGo4SgSaEcIsfgy8c X-IronPort-AV: E=Sophos;i="4.87,636,1363132800"; d="scan'208";a="80616700" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 08 May 2013 18:12:18 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r48ICHch025803; Wed, 8 May 2013 18:12:17 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: <5188FFB5.9000508@viagenie.ca> Date: Wed, 8 May 2013 11:12:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9B2BA1EB-B982-4104-B946-F452BC9823DA@cisco.com> References: <5188FDDB.5050903@comcast.net> <5188FFB5.9000508@viagenie.ca> To: Norman Sardella X-Mailer: Apple Mail (2.1503) Cc: pcp@ietf.org Subject: Re: [pcp] PCP MAP expiring connections 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, 08 May 2013 18:12:24 -0000 On May 7, 2013, at 6:20 AM, Simon Perreault = wrote: > Le 2013-05-07 15:12, Norman Sardella a =E9crit : >>=20 >> The following section was updated in RFC 6887. >=20 > Note that it's just a rewording. No behavioural change. >=20 >>=20 >> I understand the section as follows >> The MAP or PEER request with lifetime of 0 will only set the >> assigned lifetime to 0 (i.e., delete the mapping) if the internal >> host had not sent a packet using that mapping for the idle-timeout >> time, otherwise the assigned lifetime will be the remaining >> idle-timeout time. >>=20 >> Can someone clarify the meaning of idle-timeout? >> How is it defined/configured and what does it mean to be "idle"? Is >> "idle" a new state in a mapping where the mapping exists but no = packets >> have used it for this defined "idle-timeout" period? >=20 > The "idle-timeout time" is the time it takes for the NAT to delete a = mapping on which there is no traffic. For example, a NAT could delete a = UDP mapping after 60 seconds if there is no traffic. >=20 > Example: consider a mapping. That mapping's lifetime was initially set = with PCP to 1000 seconds, and there are 900 seconds remaining. The last = packet seen on this mapping was 15 seconds ago. The PCP server receives = a lifetime=3D0 request to delete the mapping. It would set the mapping's = lifetime to 45 seconds. That is, the idle-timeout time (60) minus the = time since the last packet seen on the mapping (15). >=20 > Note that the idle-timeout time varies across NAT implementations, = protocols, connection tracking states, time of day, current load, etc. Some references, UDP NAT, http://tools.ietf.org/html/rfc4787#section-4.3 TCP NAT, http://tools.ietf.org/html/rfc5382#page-11 IPv6 simple CPE firewall, see REC-15 of = http://tools.ietf.org/html/rfc6092 -d >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From repenno@cisco.com Thu May 9 20:04:56 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E7821F8FA1 for ; Thu, 9 May 2013 20:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NRg6cwDI8oj for ; Thu, 9 May 2013 20:04:51 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9536321F8F4D for ; Thu, 9 May 2013 20:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2162; q=dns/txt; s=iport; t=1368155091; x=1369364691; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=UCDfSAHf3Req8HiyyDnGMNKUjsUdjOpdmOiwQJfpkH0=; b=HknR0b1XuwIq55lwsMj/F3J+PdQlRdtFu+RuY9lk/Zi48rEcNUXLou4Y O1qOO77N24RJUunFCfNbXi4vpLogl9btZ5jITWI9Sk8Owtx7JnODgRi+u hLko+0Cxkx9qUD2SFTTHmhG7QY++OesOy3GMAOadQ5D6QSZfJa6sUMUVr U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAFtjjFGtJV2b/2dsb2JhbABSgwc3wAh+Fm0HgiEBBAEBARodNB0BCBIQFAUyCxcOAgQTCIgEDJ12oBONZoEROIJ0YQOYUpAPgVeBOIFyNQ X-IronPort-AV: E=Sophos;i="4.87,645,1363132800"; d="scan'208";a="208608485" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 10 May 2013 03:04:50 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4A34oSP021995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 10 May 2013 03:04:50 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Thu, 9 May 2013 22:04:50 -0500 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: [pcp] WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) Thread-Index: AQHOSyMd+UONupvK9kCM5yrtYUJ655j94YMA Date: Fri, 10 May 2013 03:04:49 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040907F6D0@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040907BCD0@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.125.119] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) 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, 10 May 2013 03:04:56 -0000 Hi, I finish implementing the description option and would like to provide some feedback. - I suggest that the description string have a suggested MAX length. Otherwise each client and server might have a different thresholds. And if memory is not a premium it makes for safer programming since you can have a fixed array and easier parsing. Basically follow the fact that URI, URLs, Headers, etc have a maximum length. My suggestion is 128 bytes. - I like that the server can truncate the description to the maximum supported length because it reduces back and forth between client and server (good). But I wonder if an error should be returned as well. Developers would need to compare length of sent/received options to see if everything was okay. Not sure they will do that or having a self-contained bit indicating truncation by server would be better. =20 - The document does not talk about updating the description. A client can decide that the current description is not good enough and decide to change it.=20 - Why a description can not have '0'length? In my code it followed naturally as a way to erase the current description. Instead of creating million mappings to test functionality I was adding description, erasing, adding, modifying of the same mapping. Thanks, Reinaldo On 5/7/13 10:02 AM, "Reinaldo Penno (repenno)" wrote: >This email communicates the start of a Working Group Last Call for the >following draft: > >Title : PCP Description Option >URL : http://tools.ietf.org/html/draft-ietf-pcp-description-option-00 >Authors: M. Boucadair et al. > >The WGLC ends May 21st. > >If this draft is important to your implementation or architecture, now is >the last chance to provide comments and request changes. Silence means you >agree with everything in it. > >Beyond general comments, we also need official reviewers for the draft. If >you are willing to volunteer, please send an email. > >Regards, > >Reinaldo > > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From repenno@cisco.com Fri May 10 04:03:48 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C8621F8F4A for ; Fri, 10 May 2013 04:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQmb85DvdM8e for ; Fri, 10 May 2013 04:03:43 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BCE7E21F8ADF for ; Fri, 10 May 2013 04:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=453; q=dns/txt; s=iport; t=1368183823; x=1369393423; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Y8wnKWfKzhrhKWryl8ZBryuL4yHWjoBsc/8qzxFAvQg=; b=dup8zVuzxZCmH4zVwOmR7CV2jg1TN90T4RSFXOSJDPSakrq/OOcfWR2w w1P5LVeBCQb7abwfEu5dWsYntQjhvRQbfaOgWBqDb5c1qGa14T3X3RkTs ZuuXi6s0uO1/IxM1SmL2f2BHL3hUe0p6keh5PpsaIZbW4XpAR7HOENK9m 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFAMXSjFGtJV2a/2dsb2JhbABSgwc3gnW9F38WbQeCIQEEHR00HQEYEhRCJQIEG4gEDJ1poC+NZoEROIJ0YQOYUpAPgw+BcjU X-IronPort-AV: E=Sophos;i="4.87,647,1363132800"; d="scan'208";a="205798170" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 10 May 2013 11:03:43 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4AB3hGl012825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 10 May 2013 11:03:43 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 10 May 2013 06:03:42 -0500 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: WG Call for Adoption: The Port Control Protocol in Dual-Stack Lite environments Thread-Index: AQHOTW4IzNGJjcrb4keUc9T3WaRLFw== Date: Fri, 10 May 2013 11:03:42 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040907F7AA@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.123.187] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] WG Call for Adoption: The Port Control Protocol in Dual-Stack Lite environments 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, 10 May 2013 11:03:48 -0000 Hello, This email starts a 2-week consensus call on adopting Title : The Port Control Protocol in Dual-Stack Lite environments Author(s) : F. Dupont t al. URL : http://tools.ietf.org/html/draft-dupont-pcp-dslite-05 Please read the current revision and state you opinion either for or against adoption (and with reasoning why) in the mailing list. The call for adoption ends 24th May 2013. Thanks, Reinaldo From mrw@lilacglade.org Fri May 10 04:51:34 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3857521F8CEC for ; Fri, 10 May 2013 04:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 I33pNi22awSl for ; Fri, 10 May 2013 04:51:26 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8A021F8A48 for ; Fri, 10 May 2013 04:51:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 12FD5204AC; Fri, 10 May 2013 07:48:51 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-1W0M4pqRGP; Fri, 10 May 2013 07:48:50 -0400 (EDT) Received: from new-host-3.home (pool-71-184-79-25.bstnma.fios.verizon.net [71.184.79.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: mrw@mail.suchdamage.org) by mail.painless-security.com (Postfix) with ESMTPSA; Fri, 10 May 2013 07:48:50 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_75B836F3-A23A-4B2D-93D2-C18828521D89" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Margaret Wasserman In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090681BF@xmb-rcd-x04.cisco.com> Date: Fri, 10 May 2013 07:51:16 -0400 Message-Id: <2BAB10A4-237B-4423-9703-36B90D2D8D12@lilacglade.org> References: <45A697A8FFD7CF48BCF2BE7E106F0604090681BF@xmb-rcd-x04.cisco.com> To: Reinaldo Penno (repenno) X-Mailer: Apple Mail (2.1499) Cc: "pcp@ietf.org" Subject: Re: [pcp] Gentle Reminder of Action items 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, 10 May 2013 11:51:34 -0000 --Apple-Mail=_75B836F3-A23A-4B2D-93D2-C18828521D89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 3, 2013, at 5:18 PM, Reinaldo Penno (repenno) = wrote: > - PCP Proxy needs a security section (open) I think I offered to help with this one, and I'll contact that document = authors to do that=85 Margaret --Apple-Mail=_75B836F3-A23A-4B2D-93D2-C18828521D89 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 repenno@cisco.com> = wrote:
- PCP Proxy needs a security section = (open)

I think I offered to = help with this one, and I'll contact that document authors to do = that=85

Margaret


= --Apple-Mail=_75B836F3-A23A-4B2D-93D2-C18828521D89-- From repenno@cisco.com Fri May 10 12:20:35 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512F221F9524 for ; Fri, 10 May 2013 12:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+UC5z1VDN2F for ; Fri, 10 May 2013 12:20:29 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B54F721F9512 for ; Fri, 10 May 2013 12:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3640; q=dns/txt; s=iport; t=1368213630; x=1369423230; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=VFyhfCcb2x8BbA+KpuJpXfo9UKWL6zZjw4C0Ip+Oumk=; b=CrWRP5PHa92yuNtGJB4kayIQaI0vpcBRUc8l415ml9PUgIYweylODE2b Ow9vMw1BHCDoVhFe7n8IJjhQr0MBcFXo17pcODYbN7qHD2Ut2TZ86Dzs+ CXoQSt+wayTOj+T37n+ZsnShxwcTTsvZ3B1dlLOCqNGD4ZmMOyDU1Jz8g 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAEVIjVGtJV2a/2dsb2JhbABSgkNEwFJ8FnSCHwEBAQR5EgEIBAoDAwECCx05FAkIAgQOBQiIBL0+jncgEQeCdGEDqGGDD4In X-IronPort-AV: E=Sophos;i="4.87,650,1363132800"; d="scan'208,217";a="208968085" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 10 May 2013 19:20:11 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4AJKAsL007752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 May 2013 19:20:11 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 10 May 2013 14:20:10 -0500 From: "Reinaldo Penno (repenno)" To: Margaret Wasserman Thread-Topic: [pcp] Gentle Reminder of Action items Thread-Index: AQHOSEPMTzd51Qwqak20xNTjKGCk45j+rKQAgABKsQA= Date: Fri, 10 May 2013 19:20:10 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F060409080AC5@xmb-rcd-x04.cisco.com> In-Reply-To: <2BAB10A4-237B-4423-9703-36B90D2D8D12@lilacglade.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.145.93] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F060409080AC5xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Gentle Reminder of Action items 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, 10 May 2013 19:20:35 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F060409080AC5xmbrcdx04ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank You Margaret. Looking forward to the update. From: Margaret Wasserman > Date: Fri, 10 May 2013 07:51:16 -0400 To: Reinaldo Penno > Cc: "pcp@ietf.org" > Subject: Re: [pcp] Gentle Reminder of Action items On May 3, 2013, at 5:18 PM, Reinaldo Penno (repenno) > wrote: - PCP Proxy needs a security section (open) I think I offered to help with this one, and I'll contact that document aut= hors to do that=85 Margaret --_000_45A697A8FFD7CF48BCF2BE7E106F060409080AC5xmbrcdx04ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8E8D6F51219B4B4582D9EEF1B186A9D5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thank You Margaret. Looking forward to the update.

From: Margaret Wasserman <mrw@lilacglade.org>
Date: Fri, 10 May 2013 07:51:16 -04= 00
To: Reinaldo Penno <repenno@cisco.com>
Cc: "pcp@ietf.org" <pcp@ietf.= org>
Subject: Re: [pcp] Gentle Reminder = of Action items



On May 3, 2013, at 5:18 PM, Reinaldo Penno (repenno) <repenno@cisco.com> wrote:
- PCP Proxy needs =
a security section (open)

I think I offered to help with this one, and I'll contact that documen= t authors to do that=85

Margaret


 --_000_45A697A8FFD7CF48BCF2BE7E106F060409080AC5xmbrcdx04ciscoc_-- From tireddy@cisco.com Mon May 13 02:45:04 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5E121F8FE8 for ; Mon, 13 May 2013 02:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0ir3cBBRNKG for ; Mon, 13 May 2013 02:45:00 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E4D3221F92FC for ; Mon, 13 May 2013 02:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4616; q=dns/txt; s=iport; t=1368438300; x=1369647900; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=yWfKs3eZEHCEXQVrWfdEcO3TOyprpl0KPZBWy0D6Sds=; b=klmlfnu4Z6Gs2D8ihp422xcW2vFaSMfbW4ygEEG9SgGrdIwhCWtk+qX6 oYX/fzkw/hHtd3urz+br8L0MwsIlLIDpwB9jsXlcnfPyNQ7zuc6udjLxD FhQya9mwEfFCpFAhsksQ7XWI1fdtp7vb5uhs4SkIKlDPQnUTdm4G4oCpD s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFANe0kFGtJXG//2dsb2JhbABagwc3wCeBAhZ0gh8BAQEEAQEBGh0tBxcEAgEIEQEDAQEBChQFCycLFwYIAgQBEgiIBAy7H41mFgd0OAaCbmEDmFKQD4FXgTiBagEHFx4 X-IronPort-AV: E=Sophos;i="4.87,660,1363132800"; d="scan'208";a="206697743" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 13 May 2013 09:44:59 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4D9ixlO021157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 13 May 2013 09:44:59 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Mon, 13 May 2013 04:44:59 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Reinaldo Penno (repenno)" , "pcp@ietf.org" Thread-Topic: [pcp] WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) Thread-Index: AQHOTbCWqahJNtKsdkuePpEKBo3D+JkC25CA Date: Mon, 13 May 2013 09:44:58 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B6B611@xmb-rcd-x10.cisco.com> References: <45A697A8FFD7CF48BCF2BE7E106F06040907BCD0@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06040907F6D0@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040907F6D0@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.54.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) 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, 13 May 2013 09:45:05 -0000 Hi Reinaldo, Few comments [1] The PCP Client SHOULD avoid including the DESCRIPTION Option in any sub= sequent request to that PCP Server. Comment> what if the server is upgraded later and starts supporting DESCRIP= TION ? [2] If the description text carried in the DESCRIPTION Option is null termi= nated, the exact description text, including Null characters, MUST be returned by the PCP Server. Comment> This conflicts with the previous sentence that client SHOULD not i= nclude Null characters. [3] If the PCP Server receives a DESCRIPTION Option having a length which does not exceed the maximum value configured, the PCP Server MUST record the complete sequence of the description text and MUST send comment> Please clarify recording; Is the PCP server supposed to store the = text in the DESCRIPTION option in its memory and for what purpose ? you may want to clarify that it cannot be used for auditing because the cli= ent could lie, for example say that the mapping is for FTP server but creat= e the mappings for SIP server [4] Security considerations discussed in [I-D.ietf-pcp-base] must be considered. comment> If this information is not going to change the PCP client/server s= tate and is only used as hint for debugging purpose; How are the PCP securi= ty considerations applicable to this option ? [5] In addition, administrators of PCP Servers SHOULD configure a maximum d= escription length which does not lead to exhaust storage resources in the PCP Server. comment> Description length should also not exceed 1100 octets. [6] May appear in: both request and response Comment> you may want to change that to "May appear in: request. May appea= r in response only if it appeared in the associated request." [7] For Security considerations - you may want to add that since PCP messag= es are not encrypted; The Description option should not leak any privacy in= formation like User X using this for a SIP call to User Y. --Tiru. > -----Original Message----- > From: Reinaldo Penno (repenno) > Sent: Friday, May 10, 2013 8:35 AM > To: pcp@ietf.org > Subject: Re: [pcp] WGLC on PCP Description Option > (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) >=20 > Hi, >=20 > I finish implementing the description option and would like to provide > some feedback. >=20 > - I suggest that the description string have a suggested MAX length. > Otherwise each client and server might have a different thresholds. And i= f > memory is not a premium it makes for safer programming since you can have > a fixed array and easier parsing. Basically follow the fact that URI, > URLs, Headers, etc have a maximum length. My suggestion is 128 bytes. >=20 > - I like that the server can truncate the description to the maximum > supported length because it reduces back and forth between client and > server (good). But I wonder if an error should be returned as well. > Developers would need to compare length of sent/received options to see i= f > everything was okay. Not sure they will do that or having a self-containe= d > bit indicating truncation by server would be better. >=20 >=20 > - The document does not talk about updating the description. A client can > decide that the current description is not good enough and decide to > change it. >=20 > - Why a description can not have '0'length? In my code it followed > naturally as a way to erase the current description. Instead of creating > million mappings to test functionality I was adding description, erasing, > adding, modifying of the same mapping. >=20 > Thanks, >=20 > Reinaldo >=20 >=20 >=20 >=20 >=20 > On 5/7/13 10:02 AM, "Reinaldo Penno (repenno)" wrote: >=20 > >This email communicates the start of a Working Group Last Call for the > >following draft: > > > >Title : PCP Description Option > >URL : http://tools.ietf.org/html/draft-ietf-pcp-description-option-00 > >Authors: M. Boucadair et al. > > > >The WGLC ends May 21st. > > > >If this draft is important to your implementation or architecture, now i= s > >the last chance to provide comments and request changes. Silence means y= ou > >agree with everything in it. > > > >Beyond general comments, we also need official reviewers for the draft. = If > >you are willing to volunteer, please send an email. > > > >Regards, > > > >Reinaldo > > > > > >_______________________________________________ > >pcp mailing list > >pcp@ietf.org > >https://www.ietf.org/mailman/listinfo/pcp >=20 From mohamed.boucadair@orange.com Mon May 13 05:17:57 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7214921F9408 for ; Mon, 13 May 2013 05:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0fcYhlZeejE for ; Mon, 13 May 2013 05:17:53 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2700721F953E for ; Mon, 13 May 2013 05:17:50 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 0F42B264CBB; Mon, 13 May 2013 14:17:49 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id E612C4C015; Mon, 13 May 2013 14:17:48 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 13 May 2013 14:17:48 +0200 From: To: "Reinaldo Penno (repenno)" , "pcp@ietf.org" Date: Mon, 13 May 2013 14:17:47 +0200 Thread-Topic: [pcp] WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) Thread-Index: AQHOSyMd+UONupvK9kCM5yrtYUJ655j94YMAgAUmGoA= Message-ID: <94C682931C08B048B7A8645303FDC9F36ECEBCE8C9@PUEXCB1B.nanterre.francetelecom.fr> References: <45A697A8FFD7CF48BCF2BE7E106F06040907BCD0@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06040907F6D0@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040907F6D0@xmb-rcd-x04.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.2.60325 Subject: Re: [pcp] WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) 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, 13 May 2013 12:17:57 -0000 Hi Reinaldo, Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >Reinaldo Penno (repenno) >Envoy=E9=A0: vendredi 10 mai 2013 05:05 >=C0=A0: pcp@ietf.org >Objet=A0: Re: [pcp] WGLC on PCP Description Option >(http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) > >Hi, > >I finish implementing the description option and would like to provide >some feedback. > >- I suggest that the description string have a suggested MAX length. >Otherwise each client and server might have a different thresholds. And if >memory is not a premium it makes for safer programming since you can have >a fixed array and easier parsing. Basically follow the fact that URI, >URLs, Headers, etc have a maximum length. My suggestion is 128 bytes. [Med] Makes sense. I made this change in Section 3: OLD:=20 The maximum length SHOULD be configurable in the PCP Server. NEW: The maximum length SHOULD be configurable in the PCP Server. The suggested = maximum length is 128 bytes. > >- I like that the server can truncate the description to the maximum >supported length because it reduces back and forth between client and >server (good). But I wonder if an error should be returned as well. >Developers would need to compare length of sent/received options to see if >everything was okay. Not sure they will do that or having a self-contained >bit indicating truncation by server would be better. [Med] I don't think there is a value in returning an explicit error when th= e field is truncated. The client can deduce this by comparing the length of= the field as sent in the request vs. the one in a received response. > > >- The document does not talk about updating the description. A client can >decide that the current description is not good enough and decide to >change it. [Med] We can add the following to Section 3: NEW: To update the description text of a mapping maintained by a PCP Server, the PCP Client constructs a MAP request which includes a DESCRIPTION Option carrying the new description text. The PCP Client follows the behavior discussed in Section 11.2.1 of [RFC6887] to set the fields of this MAP request. Upon receipt of the MAP request, the PCP Server proceeds to the same operations to validate a MAP request refreshing an existing mapping. In addition, the PCP Server replaces the old description text with the new one included in the DESCRIPTION Option. > >- Why a description can not have '0'length? In my code it followed >naturally as a way to erase the current description. Instead of creating >million mappings to test functionality I was adding description, erasing, >adding, modifying of the same mapping. [Med] Good point. I removed that sentence and replaced it with the followin= g: The PCP Client uses empty DESCRIPTION Option (i.e., Length set to 0) to erase the description text associated with a mapping. Upon receipt of an empty DESCRIPTION Option, the PCP Server MUST clear the description text associated with a mapping it maintains.=20 > >Thanks, > >Reinaldo > > > > > >On 5/7/13 10:02 AM, "Reinaldo Penno (repenno)" wrote: > >>This email communicates the start of a Working Group Last Call for the >>following draft: >> >>Title : PCP Description Option >>URL : http://tools.ietf.org/html/draft-ietf-pcp-description-option-00 >>Authors: M. Boucadair et al. >> >>The WGLC ends May 21st. >> >>If this draft is important to your implementation or architecture, now is >>the last chance to provide comments and request changes. Silence means yo= u >>agree with everything in it. >> >>Beyond general comments, we also need official reviewers for the draft. I= f >>you are willing to volunteer, please send an email. >> >>Regards, >> >>Reinaldo >> >> >>_______________________________________________ >>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 May 13 05:36:37 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8058E21F957D for ; Mon, 13 May 2013 05:36:37 -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 zXGa1M3mGEA9 for ; Mon, 13 May 2013 05:36:33 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5E121F9552 for ; Mon, 13 May 2013 05:36:33 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 3D4573B4106; Mon, 13 May 2013 14:36:32 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1AAB735C04E; Mon, 13 May 2013 14:36:32 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 13 May 2013 14:36:31 +0200 From: To: "Tirumaleswar Reddy (tireddy)" , "Reinaldo Penno (repenno)" , "pcp@ietf.org" Date: Mon, 13 May 2013 14:36:30 +0200 Thread-Topic: [pcp] WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) Thread-Index: AQHOTbCWqahJNtKsdkuePpEKBo3D+JkC25CAgAAw30A= Message-ID: <94C682931C08B048B7A8645303FDC9F36ECEBCE8E9@PUEXCB1B.nanterre.francetelecom.fr> References: <45A697A8FFD7CF48BCF2BE7E106F06040907BCD0@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06040907F6D0@xmb-rcd-x04.cisco.com> <913383AAA69FF945B8F946018B75898A14B6B611@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A14B6B611@xmb-rcd-x10.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.13.102421 Subject: Re: [pcp] WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) 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, 13 May 2013 12:36:37 -0000 Hi Tiru, Thanks for the review. Please see inline. Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >Tirumaleswar Reddy (tireddy) >Envoy=E9=A0: lundi 13 mai 2013 11:45 >=C0=A0: Reinaldo Penno (repenno); pcp@ietf.org >Objet=A0: Re: [pcp] WGLC on PCP Description Option >(http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) > >Hi Reinaldo, > >Few comments > >[1] The PCP Client SHOULD avoid including the DESCRIPTION Option in any >subsequent request to that PCP Server. > >Comment> what if the server is upgraded later and starts supporting >DESCRIPTION ? [Med] The purpose of that text is to not overload the server with useless o= perations. This behavior can be updated to allow including a the DESCRIPTIO= N Option if the PCP Client reboots. > >[2] If the description text carried in the DESCRIPTION Option is null >terminated, the exact description text, > including Null characters, MUST be returned by the PCP Server. > >Comment> This conflicts with the previous sentence that client SHOULD not >include Null characters. [Med] That text is to accommodate poor implementations and avoid errors. > >[3] If the PCP Server receives a DESCRIPTION Option having a length which > does not exceed the maximum value configured, the PCP Server MUST > record the complete sequence of the description text and MUST send > >comment> Please clarify recording; Is the PCP server supposed to store the >text in the DESCRIPTION option in its memory and for what purpose ? >you may want to clarify that it cannot be used for auditing because the >client could lie, for example say that the mapping is for FTP server but >create the mappings for SIP server [Med] There is already this sentence in the document: " Issues related to the usage of this field for troubleshooting or for any = further usage are out of scope of this document. " > >[4] Security considerations discussed in [I-D.ietf-pcp-base] must be > considered. > >comment> If this information is not going to change the PCP client/server >state and is only used as hint for debugging purpose; How are the PCP >security considerations applicable to this option ? [Med] this spec does not change the base security threat analysis as discus= sed in rfc6887. I updated the text as follows: OLD: Security considerations discussed in [I-D.ietf-pcp-base] must be considered= . NEW: PCP-related security considerations are discussed in [RFC6887]. > >[5] In addition, administrators of PCP Servers SHOULD configure a maximum >description length which does not lead to exhaust > storage resources in the PCP Server. > >comment> Description length should also not exceed 1100 octets. [Med] The maximum length depends on other fields and options to be included= in the same pcp request. The 1100 is a limit already discussed in the base= spec.=20 > >[6] May appear in: both request and response > >Comment> you may want to change that to "May appear in: request. May >appear in response only if it appeared in the associated request." [Med] Done. > >[7] For Security considerations - you may want to add that since PCP >messages are not encrypted; The Description option should not leak any >privacy information like User X using this for a SIP call to User Y. [Med] I added this sentence: If the PCP Client and the PCP Server are not under the same administrative entity, the DESCRIPTION Option SHOULD NOT be used to leak privacy-related information (for example, see Section 3.2 of [RFC6462]). > >--Tiru. > >> -----Original Message----- >> From: Reinaldo Penno (repenno) >> Sent: Friday, May 10, 2013 8:35 AM >> To: pcp@ietf.org >> Subject: Re: [pcp] WGLC on PCP Description Option >> (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) >> >> Hi, >> >> I finish implementing the description option and would like to provide >> some feedback. >> >> - I suggest that the description string have a suggested MAX length. >> Otherwise each client and server might have a different thresholds. And >if >> memory is not a premium it makes for safer programming since you can hav= e >> a fixed array and easier parsing. Basically follow the fact that URI, >> URLs, Headers, etc have a maximum length. My suggestion is 128 bytes. >> >> - I like that the server can truncate the description to the maximum >> supported length because it reduces back and forth between client and >> server (good). But I wonder if an error should be returned as well. >> Developers would need to compare length of sent/received options to see >if >> everything was okay. Not sure they will do that or having a self- >contained >> bit indicating truncation by server would be better. >> >> >> - The document does not talk about updating the description. A client ca= n >> decide that the current description is not good enough and decide to >> change it. >> >> - Why a description can not have '0'length? In my code it followed >> naturally as a way to erase the current description. Instead of creating >> million mappings to test functionality I was adding description, erasing= , >> adding, modifying of the same mapping. >> >> Thanks, >> >> Reinaldo >> >> >> >> >> >> On 5/7/13 10:02 AM, "Reinaldo Penno (repenno)" wrote= : >> >> >This email communicates the start of a Working Group Last Call for the >> >following draft: >> > >> >Title : PCP Description Option >> >URL : http://tools.ietf.org/html/draft-ietf-pcp-description-option-0= 0 >> >Authors: M. Boucadair et al. >> > >> >The WGLC ends May 21st. >> > >> >If this draft is important to your implementation or architecture, now >is >> >the last chance to provide comments and request changes. Silence means >you >> >agree with everything in it. >> > >> >Beyond general comments, we also need official reviewers for the draft. >If >> >you are willing to volunteer, please send an email. >> > >> >Regards, >> > >> >Reinaldo >> > >> > >> >_______________________________________________ >> >pcp mailing list >> >pcp@ietf.org >> >https://www.ietf.org/mailman/listinfo/pcp >> > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From tireddy@cisco.com Mon May 13 08:19:04 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAFC21F8F3E for ; Mon, 13 May 2013 08:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQH3UDv5jhMl for ; Mon, 13 May 2013 08:18:59 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 191DF21F872E for ; Mon, 13 May 2013 08:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7576; q=dns/txt; s=iport; t=1368458339; x=1369667939; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=T5J6ge0VCBOWBm8bQx2r+AutF6PteWxvSZ5/EX382kk=; b=Kna4f2amzexGtv/cP+KDFjdFwf2I9FM0Gkcm4C7SenVsjIs2czBNc5RQ Co4rQKbHqFfh7ENQT4HrPr/lCxXtAAEE+OisFA8SnI/Fy46Bsmnxy6MRB 8muIV5KO2VmQZSv7dkd7mlIWDhWMRErxXcvB3x7X9tTxcPK08DOo4IfPj 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAK0DkVGtJV2Z/2dsb2JhbABagwc3wCqBBRZ0gh8BAQEDAQEBARpKBxAHBAIBCBEBAwEBAQoZBAcnCxQDBggCBAESCId+Bgy7Uo1mCwsHdDgGgm5hA4hij3CQD4FXgTiBagEHFx4 X-IronPort-AV: E=Sophos;i="4.87,662,1363132800"; d="scan'208";a="209815787" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 13 May 2013 15:18:47 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4DFIkhC024045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 May 2013 15:18:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Mon, 13 May 2013 10:18:46 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" , "Reinaldo Penno (repenno)" , "pcp@ietf.org" Thread-Topic: [pcp] WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) Thread-Index: AQHOTbCWqahJNtKsdkuePpEKBo3D+JkC25CAgAAw30CAABER4A== Date: Mon, 13 May 2013 15:18:46 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B6B935@xmb-rcd-x10.cisco.com> References: <45A697A8FFD7CF48BCF2BE7E106F06040907BCD0@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06040907F6D0@xmb-rcd-x04.cisco.com> <913383AAA69FF945B8F946018B75898A14B6B611@xmb-rcd-x10.cisco.com> <94C682931C08B048B7A8645303FDC9F36ECEBCE8E9@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ECEBCE8E9@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.47.94] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) 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, 13 May 2013 15:19:04 -0000 Hi Med, Please see inline > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Monday, May 13, 2013 6:07 PM > To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); pcp@ietf.org > Subject: RE: [pcp] WGLC on PCP Description Option > (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) >=20 > Hi Tiru, >=20 > Thanks for the review. >=20 > Please see inline. > Cheers, > Med >=20 > >-----Message d'origine----- > >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de > >Tirumaleswar Reddy (tireddy) > >Envoy=E9=A0: lundi 13 mai 2013 11:45 > >=C0=A0: Reinaldo Penno (repenno); pcp@ietf.org > >Objet=A0: Re: [pcp] WGLC on PCP Description Option > >(http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) > > > >Hi Reinaldo, > > > >Few comments > > > >[1] The PCP Client SHOULD avoid including the DESCRIPTION Option in any > >subsequent request to that PCP Server. > > > >Comment> what if the server is upgraded later and starts supporting > >DESCRIPTION ? > [Med] The purpose of that text is to not overload the server with useless > operations. This behavior can be updated to allow including a the DESCRIP= TION > Option if the PCP Client reboots. or the PCP client may want to try using DESCRIPTION option after it is noti= fied that PCP server has re-booted using ANNOUNCE. >=20 > > > >[2] If the description text carried in the DESCRIPTION Option is null > >terminated, the exact description text, > > including Null characters, MUST be returned by the PCP Server. > > > >Comment> This conflicts with the previous sentence that client SHOULD no= t > >include Null characters. > [Med] That text is to accommodate poor implementations and avoid errors. >=20 > > > >[3] If the PCP Server receives a DESCRIPTION Option having a length whic= h > > does not exceed the maximum value configured, the PCP Server MUST > > record the complete sequence of the description text and MUST send > > > >comment> Please clarify recording; Is the PCP server supposed to store t= he > >text in the DESCRIPTION option in its memory and for what purpose ? > >you may want to clarify that it cannot be used for auditing because the > >client could lie, for example say that the mapping is for FTP server but > >create the mappings for SIP server > [Med] There is already this sentence in the document: >=20 > " Issues related to the usage of this field for troubleshooting or for an= y > further usage are out of scope of this document. " >=20 > > > >[4] Security considerations discussed in [I-D.ietf-pcp-base] must be > > considered. > > > >comment> If this information is not going to change the PCP client/serve= r > >state and is only used as hint for debugging purpose; How are the PCP > >security considerations applicable to this option ? > [Med] this spec does not change the base security threat analysis as disc= ussed > in rfc6887. I updated the text as follows: >=20 > OLD: > Security considerations discussed in [I-D.ietf-pcp-base] must be consider= ed. >=20 > NEW: > PCP-related security considerations are discussed in [RFC6887]. >=20 > > > >[5] In addition, administrators of PCP Servers SHOULD configure a maximu= m > >description length which does not lead to exhaust > > storage resources in the PCP Server. > > > >comment> Description length should also not exceed 1100 octets. > [Med] The maximum length depends on other fields and options to be includ= ed in > the same pcp request. The 1100 is a limit already discussed in the base s= pec. You may want to point to that section, I guess this is the first option to = be of variable length. >=20 > > > >[6] May appear in: both request and response > > > >Comment> you may want to change that to "May appear in: request. May > >appear in response only if it appeared in the associated request." > [Med] Done. >=20 > > > >[7] For Security considerations - you may want to add that since PCP > >messages are not encrypted; The Description option should not leak any > >privacy information like User X using this for a SIP call to User Y. > [Med] I added this sentence: >=20 > If the PCP Client and the PCP Server are not under the same > administrative entity, the DESCRIPTION Option SHOULD NOT be used to > leak privacy-related information (for example, see Section 3.2 of > [RFC6462]). I am not sure, Is the PCP client aware if the PCP server is in the same adm= inistrative domain ? --Tiru. >=20 > > > >--Tiru. > > > >> -----Original Message----- > >> From: Reinaldo Penno (repenno) > >> Sent: Friday, May 10, 2013 8:35 AM > >> To: pcp@ietf.org > >> Subject: Re: [pcp] WGLC on PCP Description Option > >> (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) > >> > >> Hi, > >> > >> I finish implementing the description option and would like to provide > >> some feedback. > >> > >> - I suggest that the description string have a suggested MAX length. > >> Otherwise each client and server might have a different thresholds. An= d > >if > >> memory is not a premium it makes for safer programming since you can h= ave > >> a fixed array and easier parsing. Basically follow the fact that URI, > >> URLs, Headers, etc have a maximum length. My suggestion is 128 bytes. > >> > >> - I like that the server can truncate the description to the maximum > >> supported length because it reduces back and forth between client and > >> server (good). But I wonder if an error should be returned as well. > >> Developers would need to compare length of sent/received options to se= e > >if > >> everything was okay. Not sure they will do that or having a self- > >contained > >> bit indicating truncation by server would be better. > >> > >> > >> - The document does not talk about updating the description. A client = can > >> decide that the current description is not good enough and decide to > >> change it. > >> > >> - Why a description can not have '0'length? In my code it followed > >> naturally as a way to erase the current description. Instead of creati= ng > >> million mappings to test functionality I was adding description, erasi= ng, > >> adding, modifying of the same mapping. > >> > >> Thanks, > >> > >> Reinaldo > >> > >> > >> > >> > >> > >> On 5/7/13 10:02 AM, "Reinaldo Penno (repenno)" wro= te: > >> > >> >This email communicates the start of a Working Group Last Call for th= e > >> >following draft: > >> > > >> >Title : PCP Description Option > >> >URL : http://tools.ietf.org/html/draft-ietf-pcp-description-option= -00 > >> >Authors: M. Boucadair et al. > >> > > >> >The WGLC ends May 21st. > >> > > >> >If this draft is important to your implementation or architecture, no= w > >is > >> >the last chance to provide comments and request changes. Silence mean= s > >you > >> >agree with everything in it. > >> > > >> >Beyond general comments, we also need official reviewers for the draf= t. > >If > >> >you are willing to volunteer, please send an email. > >> > > >> >Regards, > >> > > >> >Reinaldo > >> > > >> > > >> >_______________________________________________ > >> >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 May 13 08:53:08 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF49221F94FF for ; Mon, 13 May 2013 08:53: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 bQSJgaK1AIsj for ; Mon, 13 May 2013 08:53:01 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6A221F949D for ; Mon, 13 May 2013 08:53:01 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id D287722C1AE; Mon, 13 May 2013 17:52:59 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id B61D5238048; Mon, 13 May 2013 17:52:59 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Mon, 13 May 2013 17:52:59 +0200 From: To: "Tirumaleswar Reddy (tireddy)" , "Reinaldo Penno (repenno)" , "pcp@ietf.org" Date: Mon, 13 May 2013 17:52:56 +0200 Thread-Topic: [pcp] WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) Thread-Index: AQHOTbCWqahJNtKsdkuePpEKBo3D+JkC25CAgAAw30CAABER4IAAJ0jA Message-ID: <94C682931C08B048B7A8645303FDC9F36ECEBCEAD1@PUEXCB1B.nanterre.francetelecom.fr> References: <45A697A8FFD7CF48BCF2BE7E106F06040907BCD0@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06040907F6D0@xmb-rcd-x04.cisco.com> <913383AAA69FF945B8F946018B75898A14B6B611@xmb-rcd-x10.cisco.com> <94C682931C08B048B7A8645303FDC9F36ECEBCE8E9@PUEXCB1B.nanterre.francetelecom.fr> <913383AAA69FF945B8F946018B75898A14B6B935@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A14B6B935@xmb-rcd-x10.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.2.60325 Subject: Re: [pcp] WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) 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, 13 May 2013 15:53:08 -0000 Re-, Please see inline. >-----Message d'origine----- >De=A0: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] >Envoy=E9=A0: lundi 13 mai 2013 17:19 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN; Reinaldo Penno (repenno); pcp@ietf.org >Objet=A0: RE: [pcp] WGLC on PCP Description Option >(http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) > >Hi Med, > >Please see inline > >> -----Original Message----- >> From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] >> Sent: Monday, May 13, 2013 6:07 PM >> To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); pcp@ietf.org >> Subject: RE: [pcp] WGLC on PCP Description Option >> (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) >> >> Hi Tiru, >> >> Thanks for the review. >> >> Please see inline. >> Cheers, >> Med >> >> >-----Message d'origine----- >> >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >> >Tirumaleswar Reddy (tireddy) >> >Envoy=E9=A0: lundi 13 mai 2013 11:45 >> >=C0=A0: Reinaldo Penno (repenno); pcp@ietf.org >> >Objet=A0: Re: [pcp] WGLC on PCP Description Option >> >(http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) >> > >> >Hi Reinaldo, >> > >> >Few comments >> > >> >[1] The PCP Client SHOULD avoid including the DESCRIPTION Option in any >> >subsequent request to that PCP Server. >> > >> >Comment> what if the server is upgraded later and starts supporting >> >DESCRIPTION ? >> [Med] The purpose of that text is to not overload the server with useles= s >> operations. This behavior can be updated to allow including a the >DESCRIPTION >> Option if the PCP Client reboots. > >or the PCP client may want to try using DESCRIPTION option after it is >notified that PCP server has re-booted using ANNOUNCE. [Med] What about this change: OLD: The PCP Client SHOULD avoid including the DESCRIPTION Option in any subsequ= ent request to that PCP Server. NEW: The PCP Client SHOULD avoid including the DESCRIPTION Option in any subsequ= ent request to that PCP Server; this behavior is disabled if the PCP Client= reboots or the PCP Client detects the PCP Server has rebooted. > >> >> > >> >[2] If the description text carried in the DESCRIPTION Option is null >> >terminated, the exact description text, >> > including Null characters, MUST be returned by the PCP Server. >> > >> >Comment> This conflicts with the previous sentence that client SHOULD >not >> >include Null characters. >> [Med] That text is to accommodate poor implementations and avoid errors. >> >> > >> >[3] If the PCP Server receives a DESCRIPTION Option having a length >which >> > does not exceed the maximum value configured, the PCP Server MUST >> > record the complete sequence of the description text and MUST send >> > >> >comment> Please clarify recording; Is the PCP server supposed to store >the >> >text in the DESCRIPTION option in its memory and for what purpose ? >> >you may want to clarify that it cannot be used for auditing because the >> >client could lie, for example say that the mapping is for FTP server bu= t >> >create the mappings for SIP server >> [Med] There is already this sentence in the document: >> >> " Issues related to the usage of this field for troubleshooting or for >any >> further usage are out of scope of this document. " >> >> > >> >[4] Security considerations discussed in [I-D.ietf-pcp-base] must be >> > considered. >> > >> >comment> If this information is not going to change the PCP >client/server >> >state and is only used as hint for debugging purpose; How are the PCP >> >security considerations applicable to this option ? >> [Med] this spec does not change the base security threat analysis as >discussed >> in rfc6887. I updated the text as follows: >> >> OLD: >> Security considerations discussed in [I-D.ietf-pcp-base] must be >considered. >> >> NEW: >> PCP-related security considerations are discussed in [RFC6887]. >> >> > >> >[5] In addition, administrators of PCP Servers SHOULD configure a >maximum >> >description length which does not lead to exhaust >> > storage resources in the PCP Server. >> > >> >comment> Description length should also not exceed 1100 octets. >> [Med] The maximum length depends on other fields and options to be >included in >> the same pcp request. The 1100 is a limit already discussed in the base >spec. > >You may want to point to that section, I guess this is the first option to >be of variable length. [Med] I added, this sentence:=20 "The configured maximum length MUST NOT exceed 1100 octets (see Section 7 o= f [RFC6887]). > >> >> > >> >[6] May appear in: both request and response >> > >> >Comment> you may want to change that to "May appear in: request. May >> >appear in response only if it appeared in the associated request." >> [Med] Done. >> >> > >> >[7] For Security considerations - you may want to add that since PCP >> >messages are not encrypted; The Description option should not leak any >> >privacy information like User X using this for a SIP call to User Y. >> [Med] I added this sentence: >> >> If the PCP Client and the PCP Server are not under the same >> administrative entity, the DESCRIPTION Option SHOULD NOT be used to >> leak privacy-related information (for example, see Section 3.2 of >> [RFC6462]). > >I am not sure, Is the PCP client aware if the PCP server is in the same >administrative domain ? [Med] this can be by configuration or if the client and the server are on t= he same network realm.=20 > >--Tiru. > >> >> > >> >--Tiru. >> > >> >> -----Original Message----- >> >> From: Reinaldo Penno (repenno) >> >> Sent: Friday, May 10, 2013 8:35 AM >> >> To: pcp@ietf.org >> >> Subject: Re: [pcp] WGLC on PCP Description Option >> >> (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) >> >> >> >> Hi, >> >> >> >> I finish implementing the description option and would like to provid= e >> >> some feedback. >> >> >> >> - I suggest that the description string have a suggested MAX length. >> >> Otherwise each client and server might have a different thresholds. >And >> >if >> >> memory is not a premium it makes for safer programming since you can >have >> >> a fixed array and easier parsing. Basically follow the fact that URI= , >> >> URLs, Headers, etc have a maximum length. My suggestion is 128 bytes. >> >> >> >> - I like that the server can truncate the description to the maximum >> >> supported length because it reduces back and forth between client and >> >> server (good). But I wonder if an error should be returned as well. >> >> Developers would need to compare length of sent/received options to >see >> >if >> >> everything was okay. Not sure they will do that or having a self- >> >contained >> >> bit indicating truncation by server would be better. >> >> >> >> >> >> - The document does not talk about updating the description. A client >can >> >> decide that the current description is not good enough and decide to >> >> change it. >> >> >> >> - Why a description can not have '0'length? In my code it followed >> >> naturally as a way to erase the current description. Instead of >creating >> >> million mappings to test functionality I was adding description, >erasing, >> >> adding, modifying of the same mapping. >> >> >> >> Thanks, >> >> >> >> Reinaldo >> >> >> >> >> >> >> >> >> >> >> >> On 5/7/13 10:02 AM, "Reinaldo Penno (repenno)" >wrote: >> >> >> >> >This email communicates the start of a Working Group Last Call for >the >> >> >following draft: >> >> > >> >> >Title : PCP Description Option >> >> >URL : http://tools.ietf.org/html/draft-ietf-pcp-description- >option-00 >> >> >Authors: M. Boucadair et al. >> >> > >> >> >The WGLC ends May 21st. >> >> > >> >> >If this draft is important to your implementation or architecture, >now >> >is >> >> >the last chance to provide comments and request changes. Silence >means >> >you >> >> >agree with everything in it. >> >> > >> >> >Beyond general comments, we also need official reviewers for the >draft. >> >If >> >> >you are willing to volunteer, please send an email. >> >> > >> >> >Regards, >> >> > >> >> >Reinaldo >> >> > >> >> > >> >> >_______________________________________________ >> >> >pcp mailing list >> >> >pcp@ietf.org >> >> >https://www.ietf.org/mailman/listinfo/pcp >> >> >> > >> >_______________________________________________ >> >pcp mailing list >> >pcp@ietf.org >> >https://www.ietf.org/mailman/listinfo/pcp From tireddy@cisco.com Mon May 13 09:07:23 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C24321F92C2 for ; Mon, 13 May 2013 09:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTlt19uP7Zg1 for ; Mon, 13 May 2013 09:07:18 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1323C21F92CB for ; Mon, 13 May 2013 09:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9879; q=dns/txt; s=iport; t=1368461237; x=1369670837; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=tw6Doo9I90A4Ln60DuWEB1aUE4AzCHpePt/pTTmZuGQ=; b=Kzc9XkFD3gQrneNBIVkDrIV48ERuzpdev15LoVucYCciv5aaLHRziupt l6MZR40Kx3yJl3bcSFip3xs0w0aVXfd4Crnod5L9ikVt6CII49K1O0Rt8 ylXZPiQfrI0/7IKSb0Ln0sQzMY3eAuBGwRDdytCwV4WPM0M9lB05ZqQR1 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAM8OkVGtJV2Y/2dsb2JhbABQCoMHN8AqgQcWdIIfAQEBBAEBARpKBxcEAgEIEQEDAQELGQQHJwsUAwYIAgQBEgiIBAy7aY1mBgULB3Q4BoJuYQOIYo9wkA+BV4E4gWoBBxce X-IronPort-AV: E=Sophos;i="4.87,662,1363132800"; d="scan'208";a="209803101" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 13 May 2013 16:07:16 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4DG7GYG006828 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 May 2013 16:07:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 13 May 2013 11:07:16 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" , "Reinaldo Penno (repenno)" , "pcp@ietf.org" Thread-Topic: [pcp] WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) Thread-Index: AQHOTbCWqahJNtKsdkuePpEKBo3D+JkC25CAgAAw30CAABER4IAAJ0jAgAAGmDA= Date: Mon, 13 May 2013 16:07:14 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B6B9AE@xmb-rcd-x10.cisco.com> References: <45A697A8FFD7CF48BCF2BE7E106F06040907BCD0@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06040907F6D0@xmb-rcd-x04.cisco.com> <913383AAA69FF945B8F946018B75898A14B6B611@xmb-rcd-x10.cisco.com> <94C682931C08B048B7A8645303FDC9F36ECEBCE8E9@PUEXCB1B.nanterre.francetelecom.fr> <913383AAA69FF945B8F946018B75898A14B6B935@xmb-rcd-x10.cisco.com> <94C682931C08B048B7A8645303FDC9F36ECEBCEAD1@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ECEBCEAD1@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.47.94] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) 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, 13 May 2013 16:07:23 -0000 Hi Med, Please see inline. > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Monday, May 13, 2013 9:23 PM > To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); pcp@ietf.org > Subject: RE: [pcp] WGLC on PCP Description Option > (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) >=20 > Re-, >=20 > Please see inline. >=20 > >-----Message d'origine----- > >De=A0: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > >Envoy=E9=A0: lundi 13 mai 2013 17:19 > >=C0=A0: BOUCADAIR Mohamed OLNC/OLN; Reinaldo Penno (repenno); pcp@ietf.o= rg > >Objet=A0: RE: [pcp] WGLC on PCP Description Option > >(http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) > > > >Hi Med, > > > >Please see inline > > > >> -----Original Message----- > >> From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.co= m] > >> Sent: Monday, May 13, 2013 6:07 PM > >> To: Tirumaleswar Reddy (tireddy); Reinaldo Penno (repenno); pcp@ietf.o= rg > >> Subject: RE: [pcp] WGLC on PCP Description Option > >> (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) > >> > >> Hi Tiru, > >> > >> Thanks for the review. > >> > >> Please see inline. > >> Cheers, > >> Med > >> > >> >-----Message d'origine----- > >> >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part = de > >> >Tirumaleswar Reddy (tireddy) > >> >Envoy=E9=A0: lundi 13 mai 2013 11:45 > >> >=C0=A0: Reinaldo Penno (repenno); pcp@ietf.org > >> >Objet=A0: Re: [pcp] WGLC on PCP Description Option > >> >(http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) > >> > > >> >Hi Reinaldo, > >> > > >> >Few comments > >> > > >> >[1] The PCP Client SHOULD avoid including the DESCRIPTION Option in a= ny > >> >subsequent request to that PCP Server. > >> > > >> >Comment> what if the server is upgraded later and starts supporting > >> >DESCRIPTION ? > >> [Med] The purpose of that text is to not overload the server with usel= ess > >> operations. This behavior can be updated to allow including a the > >DESCRIPTION > >> Option if the PCP Client reboots. > > > >or the PCP client may want to try using DESCRIPTION option after it is > >notified that PCP server has re-booted using ANNOUNCE. > [Med] What about this change: >=20 > OLD: > The PCP Client SHOULD avoid including the DESCRIPTION Option in any subse= quent > request to that PCP Server. >=20 > NEW: > The PCP Client SHOULD avoid including the DESCRIPTION Option in any subse= quent > request to that PCP Server; this behavior is disabled if the PCP Client > reboots or the PCP Client detects the PCP Server has rebooted. >=20 > > > >> > >> > > >> >[2] If the description text carried in the DESCRIPTION Option is null > >> >terminated, the exact description text, > >> > including Null characters, MUST be returned by the PCP Server. > >> > > >> >Comment> This conflicts with the previous sentence that client SHOULD > >not > >> >include Null characters. > >> [Med] That text is to accommodate poor implementations and avoid error= s. > >> > >> > > >> >[3] If the PCP Server receives a DESCRIPTION Option having a length > >which > >> > does not exceed the maximum value configured, the PCP Server MUST > >> > record the complete sequence of the description text and MUST sen= d > >> > > >> >comment> Please clarify recording; Is the PCP server supposed to stor= e > >the > >> >text in the DESCRIPTION option in its memory and for what purpose ? > >> >you may want to clarify that it cannot be used for auditing because t= he > >> >client could lie, for example say that the mapping is for FTP server = but > >> >create the mappings for SIP server > >> [Med] There is already this sentence in the document: > >> > >> " Issues related to the usage of this field for troubleshooting or for > >any > >> further usage are out of scope of this document. " > >> > >> > > >> >[4] Security considerations discussed in [I-D.ietf-pcp-base] must be > >> > considered. > >> > > >> >comment> If this information is not going to change the PCP > >client/server > >> >state and is only used as hint for debugging purpose; How are the PCP > >> >security considerations applicable to this option ? > >> [Med] this spec does not change the base security threat analysis as > >discussed > >> in rfc6887. I updated the text as follows: > >> > >> OLD: > >> Security considerations discussed in [I-D.ietf-pcp-base] must be > >considered. > >> > >> NEW: > >> PCP-related security considerations are discussed in [RFC6887]. > >> > >> > > >> >[5] In addition, administrators of PCP Servers SHOULD configure a > >maximum > >> >description length which does not lead to exhaust > >> > storage resources in the PCP Server. > >> > > >> >comment> Description length should also not exceed 1100 octets. > >> [Med] The maximum length depends on other fields and options to be > >included in > >> the same pcp request. The 1100 is a limit already discussed in the bas= e > >spec. > > > >You may want to point to that section, I guess this is the first option = to > >be of variable length. > [Med] I added, this sentence: >=20 > "The configured maximum length MUST NOT exceed 1100 octets (see Section 7= of > [RFC6887]). >=20 > > > >> > >> > > >> >[6] May appear in: both request and response > >> > > >> >Comment> you may want to change that to "May appear in: request. May > >> >appear in response only if it appeared in the associated request." > >> [Med] Done. > >> > >> > > >> >[7] For Security considerations - you may want to add that since PCP > >> >messages are not encrypted; The Description option should not leak an= y > >> >privacy information like User X using this for a SIP call to User Y. > >> [Med] I added this sentence: > >> > >> If the PCP Client and the PCP Server are not under the same > >> administrative entity, the DESCRIPTION Option SHOULD NOT be used to > >> leak privacy-related information (for example, see Section 3.2 of > >> [RFC6462]). > > > >I am not sure, Is the PCP client aware if the PCP server is in the same > >administrative domain ? > [Med] this can be by configuration or if the client and the server are on= the > same network realm. Agreed, PCP client based on authentication or configuration can identify if= the PCP server is in the same domain or not. All the changes you have proposed look good.=20 Best Regards, --Tiru. >=20 > > > >--Tiru. > > > >> > >> > > >> >--Tiru. > >> > > >> >> -----Original Message----- > >> >> From: Reinaldo Penno (repenno) > >> >> Sent: Friday, May 10, 2013 8:35 AM > >> >> To: pcp@ietf.org > >> >> Subject: Re: [pcp] WGLC on PCP Description Option > >> >> (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) > >> >> > >> >> Hi, > >> >> > >> >> I finish implementing the description option and would like to prov= ide > >> >> some feedback. > >> >> > >> >> - I suggest that the description string have a suggested MAX length= . > >> >> Otherwise each client and server might have a different thresholds. > >And > >> >if > >> >> memory is not a premium it makes for safer programming since you ca= n > >have > >> >> a fixed array and easier parsing. Basically follow the fact that U= RI, > >> >> URLs, Headers, etc have a maximum length. My suggestion is 128 byte= s. > >> >> > >> >> - I like that the server can truncate the description to the maximu= m > >> >> supported length because it reduces back and forth between client a= nd > >> >> server (good). But I wonder if an error should be returned as well. > >> >> Developers would need to compare length of sent/received options to > >see > >> >if > >> >> everything was okay. Not sure they will do that or having a self- > >> >contained > >> >> bit indicating truncation by server would be better. > >> >> > >> >> > >> >> - The document does not talk about updating the description. A clie= nt > >can > >> >> decide that the current description is not good enough and decide t= o > >> >> change it. > >> >> > >> >> - Why a description can not have '0'length? In my code it followed > >> >> naturally as a way to erase the current description. Instead of > >creating > >> >> million mappings to test functionality I was adding description, > >erasing, > >> >> adding, modifying of the same mapping. > >> >> > >> >> Thanks, > >> >> > >> >> Reinaldo > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> On 5/7/13 10:02 AM, "Reinaldo Penno (repenno)" > >wrote: > >> >> > >> >> >This email communicates the start of a Working Group Last Call for > >the > >> >> >following draft: > >> >> > > >> >> >Title : PCP Description Option > >> >> >URL : http://tools.ietf.org/html/draft-ietf-pcp-description- > >option-00 > >> >> >Authors: M. Boucadair et al. > >> >> > > >> >> >The WGLC ends May 21st. > >> >> > > >> >> >If this draft is important to your implementation or architecture, > >now > >> >is > >> >> >the last chance to provide comments and request changes. Silence > >means > >> >you > >> >> >agree with everything in it. > >> >> > > >> >> >Beyond general comments, we also need official reviewers for the > >draft. > >> >If > >> >> >you are willing to volunteer, please send an email. > >> >> > > >> >> >Regards, > >> >> > > >> >> >Reinaldo > >> >> > > >> >> > > >> >> >_______________________________________________ > >> >> >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 repenno@cisco.com Mon May 13 13:55:56 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84CB21F949D for ; Mon, 13 May 2013 13:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6gLJ-yOUotb for ; Mon, 13 May 2013 13:55:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5495D21F944F for ; Mon, 13 May 2013 13:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=298; q=dns/txt; s=iport; t=1368478542; x=1369688142; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=08nglbXl5UyXnqP2h7ewW+s5/spUn7ds+gQXh1H3Qzc=; b=BJIiddcjz5opd0Bnc9j7v/4tBJUd3PROv7utbJTGaSvc6SHcZzoLqC96 vvhqREwf6VkJ37rQlDaBJ9yJhr9UpvUbyUb4BQW7RXv/uibnWWm68weN8 XPraT9e9zbptN1jSfr9CAz4eUdMdRecek5ewGX4J8IWAYVnxbTKM0ITj9 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAPFRkVGtJV2d/2dsb2JhbABagwfAaIELFm0HgiEBBDpRASoUQicEG4gEnR2fHY1mgRGDLGEDqGGDD4FyNQ X-IronPort-AV: E=Sophos;i="4.87,665,1363132800"; d="scan'208";a="209946654" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 13 May 2013 20:55:41 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4DKtfOR024402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 13 May 2013 20:55:41 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 13 May 2013 15:55:41 -0500 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: Requests for PCP Presentations in IETF Berlin Thread-Index: AQHOUBw6KFWNIsjZ7UyDhD7r83QO5w== Date: Mon, 13 May 2013 20:55:40 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F060409083A1F@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.82.84] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] Requests for PCP Presentations in IETF Berlin 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, 13 May 2013 20:55:57 -0000 Hello, I'm sending this in advance so that presenters can also notify the chairs and prepare in advance. If you want to present in IETF Berlin, please send an email with: title, presenter, pointer to draft (if any) and time needed. Sooner the better for everybody. Thanks, Reinaldo From dthaler@microsoft.com Mon May 13 17:27:13 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CC121F85EE for ; Mon, 13 May 2013 17:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.467 X-Spam-Level: X-Spam-Status: No, score=-97.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2o2k+fWHunp for ; Mon, 13 May 2013 17:27:05 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA9721F9545 for ; Mon, 13 May 2013 17:26:35 -0700 (PDT) Received: from BY2FFO11FD012.protection.gbl (10.1.15.202) by BY2FFO11HUB026.protection.gbl (10.1.14.112) with Microsoft SMTP Server (TLS) id 15.0.687.1; Tue, 14 May 2013 00:23:05 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD012.mail.protection.outlook.com (10.1.14.130) with Microsoft SMTP Server (TLS) id 15.0.687.1 via Frontend Transport; Tue, 14 May 2013 00:23:05 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.3.136.1; Tue, 14 May 2013 00:21:42 +0000 Received: from mail101-ch1-R.bigfish.com (10.43.68.233) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.23; Tue, 14 May 2013 00:20:50 +0000 Received: from mail101-ch1 (localhost [127.0.0.1]) by mail101-ch1-R.bigfish.com (Postfix) with ESMTP id B812040039B for ; Tue, 14 May 2013 00:20:50 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -27 X-BigFish: PS-27(z5621hz9371I542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah186M5eeeK8275bh8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d07h1d0ch1d2eh1d3fh17ej9a9j1155h) Received-SPF: softfail (mail101-ch1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=dthaler@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB272; H:BY2PR03MB269.namprd03.prod.outlook.com; LANG:en; Received: from mail101-ch1 (localhost.localdomain [127.0.0.1]) by mail101-ch1 (MessageSwitch) id 13684908486698_10759; Tue, 14 May 2013 00:20:48 +0000 (UTC) Received: from CH1EHSMHS003.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail101-ch1.bigfish.com (Postfix) with ESMTP id E9E9560042; Tue, 14 May 2013 00:20:47 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS003.bigfish.com (10.43.70.3) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 14 May 2013 00:20:47 +0000 Received: from BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.305.3; Tue, 14 May 2013 00:20:47 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) with Microsoft SMTP Server (TLS) id 15.0.680.19; Tue, 14 May 2013 00:20:45 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.107]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.191]) with mapi id 15.00.0680.012; Tue, 14 May 2013 00:20:44 +0000 From: Dave Thaler To: "draft-ietf-pcp-description-option@tools.ietf.org" Thread-Topic: [pcp] WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) Thread-Index: AQHOSyMd+UONupvK9kCM5yrtYUJ655kD21RQ Date: Tue, 14 May 2013 00:20:44 +0000 Message-ID: <0b792e892e3b483a88dbfe4143f65c46@BY2PR03MB269.namprd03.prod.outlook.com> References: <45A697A8FFD7CF48BCF2BE7E106F06040907BCD0@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040907BCD0@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:1a:3:b07a:acab:df5b:2e40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB272.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC105.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC105.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464003)(243025003)(377454002)(189002)(199002)(51704005)(47446002)(47976001)(47736001)(44976003)(65816001)(220493001)(4396001)(80022001)(81342001)(69226001)(50986001)(15202345002)(49866001)(74876001)(54316002)(51856001)(77982001)(74502001)(46406003)(56816002)(59766001)(20776003)(79102001)(56776001)(63696002)(23726002)(47776003)(74366001)(16676001)(53806001)(81542001)(31966008)(46102001)(76482001)(50466002)(54356001)(6806003)(74316001)(33646001)(74706001)(74662001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB026; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 084674B2CF Cc: "pcp@ietf.org" Subject: Re: [pcp] WGLC on PCP Description Option (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) 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, 14 May 2013 00:27:14 -0000 My comments are now in the marked up copy at http://research.microsoft.com/~dthaler/draft-ietf-pcp-description-option-00= .pdf -Dave > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Reinaldo Penno (repenno) > Sent: Tuesday, May 7, 2013 6:02 AM > To: pcp@ietf.org > Subject: [pcp] WGLC on PCP Description Option > (http://tools.ietf.org/html/draft-ietf-pcp-description-option-00) >=20 > This email communicates the start of a Working Group Last Call for the > following draft: >=20 > Title : PCP Description Option > URL : http://tools.ietf.org/html/draft-ietf-pcp-description-option-00 > Authors: M. Boucadair et al. >=20 > The WGLC ends May 21st. >=20 > If this draft is important to your implementation or architecture, now is= the > last chance to provide comments and request changes. Silence means you > agree with everything in it. >=20 > Beyond general comments, we also need official reviewers for the draft. I= f > you are willing to volunteer, please send an email. >=20 > Regards, >=20 > Reinaldo >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp >=20 From cathy.zhou@huawei.com Tue May 14 17:41:42 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C9521F8F07 for ; Tue, 14 May 2013 17:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yC--PzlUmU68 for ; Tue, 14 May 2013 17:41:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4061D21F85C9 for ; Tue, 14 May 2013 17:41:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARJ66241; Wed, 15 May 2013 00:41:34 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 15 May 2013 01:41:08 +0100 Received: from SZXEML452-HUB.china.huawei.com (10.82.67.195) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 15 May 2013 01:41:31 +0100 Received: from SZXEML513-MBS.china.huawei.com ([169.254.8.36]) by szxeml452-hub.china.huawei.com ([10.82.67.195]) with mapi id 14.01.0323.007; Wed, 15 May 2013 08:41:23 +0800 From: "Zhouqian (Cathy)" To: "Reinaldo Penno (repenno)" , "pcp@ietf.org" Thread-Topic: [pcp] WG Call for Adoption: The Port Control Protocol in Dual-Stack Lite environments Thread-Index: AQHOTW4IzNGJjcrb4keUc9T3WaRLF5kFbogg Date: Wed, 15 May 2013 00:41:23 +0000 Message-ID: References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06040907F7AA@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040907F7AA@xmb-rcd-x04.cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [pcp] WG Call for Adoption: The Port Control Protocol in Dual-Stack Lite environments 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, 15 May 2013 00:41:42 -0000 Support adoption of this document. Best Regards, Cathy > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Reinaldo Penno (repenno) > Sent: Friday, May 10, 2013 7:04 PM > To: pcp@ietf.org > Subject: [pcp] WG Call for Adoption: The Port Control Protocol in Dual-St= ack > Lite environments >=20 > Hello, >=20 > This email starts a 2-week consensus call on adopting >=20 > Title : The Port Control Protocol in Dual-Stack Lite environment= s > Author(s) : F. Dupont t al. > URL : http://tools.ietf.org/html/draft-dupont-pcp-dslite-05 >=20 > Please read the current revision and state you opinion either for or > against adoption (and with reasoning why) in the mailing list. >=20 > The call for adoption ends 24th May 2013. >=20 > Thanks, >=20 > Reinaldo >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From liushucheng@huawei.com Tue May 14 18:45:31 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A4F21F85BF for ; Tue, 14 May 2013 18:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTsD34fjljAX for ; Tue, 14 May 2013 18:45:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2584E21F84D9 for ; Tue, 14 May 2013 18:45:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASU55381; Wed, 15 May 2013 01:45:25 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 15 May 2013 02:45:02 +0100 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 15 May 2013 02:45:25 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.133]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.007; Wed, 15 May 2013 09:45:15 +0800 From: "Will Liu (Shucheng)" To: "Reinaldo Penno (repenno)" , "pcp@ietf.org" Thread-Topic: [pcp] WG Call for Adoption: The Port Control Protocol in Dual-Stack Lite environments Thread-Index: AQHOTW4IzNGJjcrb4keUc9T3WaRLF5kFdNoQ Date: Wed, 15 May 2013 01:45:13 +0000 Message-ID: References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06040907F7AA@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040907F7AA@xmb-rcd-x04.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [pcp] WG Call for Adoption: The Port Control Protocol in Dual-Stack Lite environments 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, 15 May 2013 01:45:31 -0000 Folks, I have read draft-dupont-pcp-dslite-05 and also believe the plain mode is a= good choice for both design and security considerations, though actually e= ach mode has its advantages respectively. I support the adoption of this do= cument as a WG document. Cheers, Will > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Reinaldo Penno (repenno) > Sent: Friday, May 10, 2013 7:04 PM > To: pcp@ietf.org > Subject: [pcp] WG Call for Adoption: The Port Control Protocol in Dual-St= ack > Lite environments >=20 > Hello, >=20 > This email starts a 2-week consensus call on adopting >=20 > Title : The Port Control Protocol in Dual-Stack Lite environment= s > Author(s) : F. Dupont t al. > URL : http://tools.ietf.org/html/draft-dupont-pcp-dslite-05 >=20 > Please read the current revision and state you opinion either for or > against adoption (and with reasoning why) in the mailing list. >=20 > The call for adoption ends 24th May 2013. >=20 > Thanks, >=20 > Reinaldo >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From achatz@forthnetgroup.gr Wed May 15 04:09:43 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B061521F84CD for ; Wed, 15 May 2013 04:09:43 -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 HLfPsnZcDXwN for ; Wed, 15 May 2013 04:09:26 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id A42FE21F84B2 for ; Wed, 15 May 2013 04:09:25 -0700 (PDT) Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id r4FB9MuV032234; Wed, 15 May 2013 14:09:22 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id r4FB9LxU013410; Wed, 15 May 2013 14:09:21 +0300 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id r4FB9KaU019453; Wed, 15 May 2013 14:09:21 +0300 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <51936CDE.6000001@forthnetgroup.gr> Date: Wed, 15 May 2013 14:09:18 +0300 From: Tassos Chatzithomaoglou Organization: Forthnet User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16.2 MIME-Version: 1.0 To: "Reinaldo Penno (repenno)" , "pcp@ietf.org" References: <45A697A8FFD7CF48BCF2BE7E106F06040907F7AA@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040907F7AA@xmb-rcd-x04.cisco.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [pcp] WG Call for Adoption: The Port Control Protocol in Dual-Stack Lite environments 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, 15 May 2013 11:09:44 -0000 Support, although it's not very clear to me why PCP proxy is the only option examined/described. Do we assume that all applications and end systems will support PCP? Can't B4 be just a PCP client, taking instructions for mappings through cli or gui? -- Tassos Reinaldo Penno (repenno) wrote on 10/05/2013 14:03: > Hello, > > This email starts a 2-week consensus call on adopting > > Title : The Port Control Protocol in Dual-Stack Lite environments > Author(s) : F. Dupont t al. > URL : http://tools.ietf.org/html/draft-dupont-pcp-dslite-05 > > Please read the current revision and state you opinion either for or > against adoption (and with reasoning why) in the mailing list. > > The call for adoption ends 24th May 2013. > > Thanks, > > Reinaldo > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From mohamed.boucadair@orange.com Thu May 16 01:09:13 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8927E21F8F43 for ; Thu, 16 May 2013 01:09:13 -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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 JZc6+qJDpFuO for ; Thu, 16 May 2013 01:09:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 045A021F8F15 for ; Thu, 16 May 2013 01:09:09 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 42E972DD36B; Thu, 16 May 2013 10:09:08 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 266A627C053; Thu, 16 May 2013 10:09:08 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 16 May 2013 10:09:08 +0200 From: To: "Reinaldo Penno (repenno)" , "pcp@ietf.org" Date: Thu, 16 May 2013 10:09:06 +0200 Thread-Topic: PCP Failure scenarios (was RE: Gentle Reminder of Action items) Thread-Index: Ac5SDJ5L5/8+jj1lTbuX14gMein+/A== Message-ID: <94C682931C08B048B7A8645303FDC9F36ECEBCF3BB@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36ECEBCF3BBPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.2.64815 Subject: [pcp] PCP Failure scenarios (was RE: Gentle Reminder of Action items) 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, 16 May 2013 08:09:13 -0000 --_000_94C682931C08B048B7A8645303FDC9F36ECEBCF3BBPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, As a follow-up to this action point, a new version of the failure analysis = draft is now available online: "- PCP failure scenarios need to contain only those scenarios not covered by base spec (open)" This new version indicates whether the analyzed failure use case is already= solved by the base PCP spec or not. The links to retrieve the new version = are provided below: Htmlized: http://tools.ietf.org/html/draft-boucadair-pcp-failure-06 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-fai= lure-06 I hope this version addresses the concerns raised in the previous pcp meeti= ng. Cheers, Med De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Reina= ldo Penno (repenno) Envoy=E9 : vendredi 3 mai 2013 23:19 =C0 : pcp@ietf.org Objet : [pcp] Gentle Reminder of Action items We are 3 months from IETF Berlin, so a gentle nudge. http://www.ietf.org/proceedings/86/minutes/minutes-86-pcp Summary of action items in no specific order: - WGLC for PCP Server Selection and gathering of reviewers (soon) - Further clarification on the use of IP address in DHCP PCP Option (ADs) - PCP Proxy needs a security section (open) - PCP Proxy: discussion whether PCP needs a bit about mandatory/optional to process bit for opcodes (open) - Create a PCP nested NAT use-case and based on that the required extension= (open) - Radius Extension confirmation of adoption on list (done, probably need re= spin) - PCP failure scenarios need to contain only those scenarios not covered by base spec (open) - PCP authentication option will star off with option 4 "Servers continue to use same SA to protect messages pertaining to that mapping, even if the SA is technically expired." - PCP authentication draft need updated based on discussion (done, discusse= d on interim) - Adopt PCP Nat coord as WG document (done, need review based on comments) Thanks, Reinaldo and Dave --_000_94C682931C08B048B7A8645303FDC9F36ECEBCF3BBPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,=

 

As a follow-up to this action point, a new version of the fa= ilure analysis draft is now available online:

“- PCP failure scenarios need t=
o contain only those scenarios not covered
by base spec (open)”<=
/span>

 

This new version indicates whether the analyze= d failure use case is already solved by the base PCP spec or not. The links= to retrieve the new version are provided below:

 

Htmlized:=A0=A0=A0 =A0=A0=A0=A0= http://tools.ietf.org/html/draft-boucadair-pcp-failure-06

Diff:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 http:= //www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-failure-06

&= nbsp;

I hope this version a= ddresses the concerns raised in the previous pcp meeting.=

 

Cheers,

Med

 =

 

De : pcp-bounces@ietf.org [m= ailto:pcp-bounces@ietf.org] De la part de Reinaldo Penno (repenno)Envoy=E9 : vendredi 3 mai 2013 23:19
=C0 : pcp= @ietf.org
Objet : [pcp] Gentle Reminder of Action items=

 

We are 3 months from IETF Berlin, so a ge=
ntle nudge.
http://www.ietf.org/proceedings/86/minutes/minutes-86-pcp
 =

Summary of action items in no=
 specific order:
 
- WGLC for PCP=
 Server Selection and gathering of reviewers (soon)
= 
- Further clarification on the use of IP a=
ddress in DHCP PCP Option (ADs)
- PCP Proxy needs a security section (open)<=
/pre>
- PCP Proxy: discussion whether PCP n=
eeds a bit about mandatory/optional
to process bit for opcodes (open)
<=
pre>- Create a PCP nested NAT use-case and base=
d on that the required extension (open)
- Radius Extension confirmation of adoption on list (d=
one, probably need respin)
- PCP failure scenarios need to contain only those scenarios not co=
vered
by base spec =
(open)
- PCP authen=
tication option will star off with option 4
"Servers continue to use same SA to protect m=
essages pertaining to
=A0=A0 that mapping, even if the SA is technically expired."
- PCP authentication draf=
t need updated based on discussion (done, discussed on interim)<=
/span>
- Adopt PCP Nat coord as WG do=
cument (done, need review based on comments)
 
Thanks,
 
Reinaldo =
and Dave
 =
;
= --_000_94C682931C08B048B7A8645303FDC9F36ECEBCF3BBPUEXCB1Bnante_-- From repenno@cisco.com Thu May 16 04:31:18 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C2F21F9057 for ; Thu, 16 May 2013 04:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nVkzVMcnq0p for ; Thu, 16 May 2013 04:31:13 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7F66F21F8F41 for ; Thu, 16 May 2013 04:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1180; q=dns/txt; s=iport; t=1368703873; x=1369913473; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=TSva5FIHb6Qgjyh/k7XAOm4jXdH5sQCIrsy+uLZHhuc=; b=FehW4DClMngwmQvYwo+Y1ScUlw0eXecLgRqfp7gegzLGwfsYSiUsa15D NPxIEOVdIyheST6TpCbhsZTY21rlF1mcKRPA/FYuR+8TD9rX7EIVMHiwU Gaqq6XZ45hVkIO46LvYED1OOju5so0XX3xszXgeyy1bxcsce7ocrsFJ+w M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAGbClFGtJV2Z/2dsb2JhbABbgwc3wUF+FnSCIQEEAQEBGh00HQEIDgISFDcLJQIEARIIiAQMvSyNXIEROIJ0YQOYXJAWgViBOIFxNQ X-IronPort-AV: E=Sophos;i="4.87,683,1363132800"; d="scan'208";a="211226531" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 16 May 2013 11:31:13 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4GBVCPu024252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 16 May 2013 11:31:12 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Thu, 16 May 2013 06:31:12 -0500 From: "Reinaldo Penno (repenno)" To: Tassos Chatzithomaoglou , "pcp@ietf.org" Thread-Topic: [pcp] WG Call for Adoption: The Port Control Protocol in Dual-Stack Lite environments Thread-Index: AQHOTW4IzNGJjcrb4keUc9T3WaRLF5kGcj4AgAFmJYA= Date: Thu, 16 May 2013 11:31:12 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F060409086207@xmb-rcd-x04.cisco.com> In-Reply-To: <51936CDE.6000001@forthnetgroup.gr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.246.143] Content-Type: text/plain; charset="us-ascii" Content-ID: <4AE22DFA3C4CF64D9BD741C472CC21A1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] WG Call for Adoption: The Port Control Protocol in Dual-Stack Lite environments 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, 16 May 2013 11:31:18 -0000 On 5/15/13 8:09 AM, "Tassos Chatzithomaoglou" wrote: >Support, although it's not very clear to me why PCP proxy is the only >option examined/described. >Do we assume that all applications and end systems will support PCP? >Can't B4 be just a PCP client, taking instructions for mappings through >cli or gui? Good point, this is not covered in the document. It might also need tweaks in the security section. > >-- >Tassos > >Reinaldo Penno (repenno) wrote on 10/05/2013 14:03: >> Hello, >> >> This email starts a 2-week consensus call on adopting >> >> Title : The Port Control Protocol in Dual-Stack Lite >>environments >> Author(s) : F. Dupont t al. >> URL : http://tools.ietf.org/html/draft-dupont-pcp-dslite-05 >> >> Please read the current revision and state you opinion either for or >> against adoption (and with reasoning why) in the mailing list. >> >> The call for adoption ends 24th May 2013. >> >> Thanks, >> >> Reinaldo >> >> >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >> > From iesg-secretary@ietf.org Thu May 16 11:46:19 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4410221F8E8E; Thu, 16 May 2013 11:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.157 X-Spam-Level: X-Spam-Status: No, score=-102.157 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799, 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 GMywtcjCZWTW; Thu, 16 May 2013 11:46:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC5B21F8EA6; Thu, 16 May 2013 11:46:17 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130516184617.1967.66521.idtracker@ietfa.amsl.com> Date: Thu, 16 May 2013 11:46:17 -0700 Cc: pcp mailing list , pcp chair , RFC Editor Subject: [pcp] Protocol Action: 'Universal Plug and Play (UPnP) Internet Gateway Device (IGD)-Port Control Protocol (PCP) Interworking Function' to Proposed Standard (draft-ietf-pcp-upnp-igd-interworking-10.txt) X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 18:46:19 -0000 The IESG has approved the following document: - 'Universal Plug and Play (UPnP) Internet Gateway Device (IGD)-Port Control Protocol (PCP) Interworking Function' (draft-ietf-pcp-upnp-igd-interworking-10.txt) as Proposed Standard This document is the product of the Port Control Protocol Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pcp-upnp-igd-interworking/ Technical Summary This document specifies the behavior of the UPnP IGD (Internet Gateway Device)/PCP Interworking Function. A UPnP IGD-PCP Interworking Function (IGD-PCP IWF) is required to be embedded in CP (Customer Premises) routers to allow for transparent NAT control in environments where UPnP IGD is used on the LAN side and PCP on the external side of the CP router. Working Group Summary Nothing unusual. Document Quality A public implementation is available at http://sourceforge.net/projects/pcpclient/?source=directory. The authors are also aware of other implementations from some CPE vendors that are not yet disclosed publically. The PCP WG has a policy to not send a document until the WG has consensus and there are at least 5 people who have reviewed and ok'ed the document. Many others were involved in reviews of earlier versions, but the WGLC oks came from: Xiaohong Deng Dave Thaler Reinaldo Penno Tiru Reddy Paul Selkirk The above reviewers collectively represent multiple implementations or potential future implementations. Personnel Dave Thaler is the document shepherd; Ted Lemon is the responsible AD. From iljitsch@muada.com Fri May 17 05:58:07 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A4C21F93E8 for ; Fri, 17 May 2013 05:58:07 -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 UnFyDQTMv+Lr for ; Fri, 17 May 2013 05:58:06 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 721F021F881F for ; Fri, 17 May 2013 05:58:06 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r4HCqEO0036726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 May 2013 14:52:14 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Iljitsch van Beijnum In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090861C4@xmb-rcd-x04.cisco.com> Date: Fri, 17 May 2013 14:57:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <751A0C06-CDD7-4FCD-84D0-C0E5BFFE12A7@muada.com> References: <45A697A8FFD7CF48BCF2BE7E106F0604090861C4@xmb-rcd-x04.cisco.com> To: Reinaldo Penno (repenno) X-Mailer: Apple Mail (2.1503) Cc: pcp@ietf.org, draft-ietf-pcp-nat64-prefix64@tools.ietf.org Subject: Re: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s using PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 12:58:07 -0000 On 16 mei 2013, at 13:19, Reinaldo Penno (repenno) = wrote: >> Title : Learn NAT64 PREFIX64s using PCP >> URL : http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-00 >> Authors: M. Boucadair Ok, here is a brief review. Brief in the sense that I didn't = re-familiarize myself with the related RFCs. This is clearly useful. I found 3.2, and especially 3.2.2 very sparse, I was looking to learn = more about how this mechanism is useful in practice here. Some more = applications/protocols could be listed. However, a lot of information is = provided in 3.3. Unfortunately, there are two issues with this: 1. SIP is a very complex protocol that not everyone may be familiar with 2. Unless I misunderstood, a lot of what happens here is pure NAT64, and = unrelated to the knowledge of the Pref64: "the PCP Client issues a PCP MAP request with PORT_RESERVATION_OPTION to reserve a pair of ports preserving parity and contiguity [I-D.boucadair-pcp-rtp-rtcp]. A pair of ports and an external IPv4 address are then returned by the PCP server to the requesting PCP Client." It would be more useful to concentrate on the functionality that is only = possible when the Pref64 is known at this point. For instance, in the = case of BitTorrent, IPv4 addresses of prospective peers may be learned = from a tracker. In order for the client to connect to those peers, it = needs to synthesize IPv6 representations for those IPv4 addresses by = combining them with the Pref64. It would be useful to spell out that the ability to reserve ports and = learn the external IPv4 address used by the NAT64 (or any NAT) allows = for receiving incoming sessions. For this, the Pref64 is not needed. The = Pref64, on the other hand, allows for setting up outgoing connections to = systems for which only a literal IPv4 address (and not a fully qualified = domain name) is known. But for this, no other PCP functionality is = required. (Although in practice it gets more complex when ports are used = in both directions simultaneously.) The abstract starts with "This document defines a new PCP extension to = learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device" but the = PREFIX64 option only allows for one Pref64 and the option may only = appear once, so the (es) part shouldn't be there. (Would the ability to = learn multiple Pref64s be useful?? I guess load balancing across NAT64s = with each a Pref64 of their own is possible.) In 4.1 a reference to section 7.3 of RFC 6887 would be useful. Although I was unhappy with the SIP example earlier, I think it's = appropriate in section 5 as it shows the full complexity of a real-world = system now that we've learned all the details of the mechanism. I think = the section title should have "SIP" in it, though. In the security considerations, I would expect a discussion about what = happens when a malicious third party impersonates a PCP server and = provides a fake Pref64. Iljitsch= From simon.perreault@viagenie.ca Fri May 17 07:14:05 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3609521F8746 for ; Fri, 17 May 2013 07:14:05 -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 OslqxwG0eJmU for ; Fri, 17 May 2013 07:14:04 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 548A821F8700 for ; Fri, 17 May 2013 07:14:04 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7DF6140062; Fri, 17 May 2013 10:14:03 -0400 (EDT) Message-ID: <51963B2A.4020607@viagenie.ca> Date: Fri, 17 May 2013 16:14:02 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: "pcp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pcp] PORT_SET for discovering static port set mappings 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, 17 May 2013 14:14:05 -0000 WG, In private email, Cathy Zhou has suggested the following addition to draft-ietf-pcp-port-set: 1.4. Discovering Stateless Port Set Mappings A MAP request can be used to discover a stateless mapping. Similarly, a MAP request with a PORT_SET request can be used to discover a stateless port set mapping. Hence, PORT_SET is applicable for port set mapping discovery in Stateless NAT44 [I-D.tsou-stateless-nat44]. Unless the WG disagrees, it will be part of the next revision. 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 repenno@cisco.com Fri May 17 12:24:32 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B362721F96FC for ; Fri, 17 May 2013 12:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuAYNxGdhnbI for ; Fri, 17 May 2013 12:24:27 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C1C0721F96EB for ; Fri, 17 May 2013 12:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3644; q=dns/txt; s=iport; t=1368818667; x=1370028267; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ltyfL5QwV63umnJNXv3d3QnGX4NJJkeGuT9Mk1IDtnk=; b=C+54Z58V29Wm4T7so+kzM43AW1FWKNQ6zn1bj7hdgjYDXx6w8C7UqD/3 V3wxpeflOxRHW/z384JfD8fXsNsUbu+ZUm9BvXfmIs2AiyGShPzaeAYuM hdOtRroC7/gAvmAn/HfjPc7kkk1bA4AJvw27O43mZGAzp2d/uD6aFB5bK E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFANaCllGtJV2b/2dsb2JhbABbgwgwwU+BABZ0giEBBDo/EgEIIhRCJQIEDgUIiAQMvU6OcDEHgnNhA5NnhHqQF4MPgiY X-IronPort-AV: E=Sophos;i="4.87,694,1363132800"; d="scan'208";a="211886298" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 17 May 2013 19:24:27 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4HJOQFm025647 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 May 2013 19:24:27 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Fri, 17 May 2013 14:24:26 -0500 From: "Reinaldo Penno (repenno)" To: Iljitsch van Beijnum Thread-Topic: Official reviewers Request for Learn NAT64 PREFIX64s using PCP Thread-Index: AQHOUicr1T/AnXRP1ECkvJx9NBOsoJkJq9AAgAA5rwA= Date: Fri, 17 May 2013 19:24:25 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040908782B@xmb-rcd-x04.cisco.com> In-Reply-To: <751A0C06-CDD7-4FCD-84D0-C0E5BFFE12A7@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.254.187] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" , "draft-ietf-pcp-nat64-prefix64@tools.ietf.org" Subject: Re: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s using PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 19:24:32 -0000 Thanks for the review Iljitsch. I think you have a good point on the separation of what can be done with the discovery of Pref64 alone versus coupled with other mechanisms. The bitorrent use-case is certainly a good representation of that. Load-blancing is also something was discussed but never got into the draft. There were other initiatives around that, specially in BEHAVE WG and med was involved in that. This might be something that could be incorporated into the draft. Regards, Reinaldo On 5/17/13 9:57 AM, "Iljitsch van Beijnum" wrote: >On 16 mei 2013, at 13:19, Reinaldo Penno (repenno) >wrote: > >>> Title : Learn NAT64 PREFIX64s using PCP >>> URL : http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-00 >>> Authors: M. Boucadair > >Ok, here is a brief review. Brief in the sense that I didn't >re-familiarize myself with the related RFCs. > >This is clearly useful. > >I found 3.2, and especially 3.2.2 very sparse, I was looking to learn >more about how this mechanism is useful in practice here. Some more >applications/protocols could be listed. However, a lot of information is >provided in 3.3. Unfortunately, there are two issues with this: > >1. SIP is a very complex protocol that not everyone may be familiar with > >2. Unless I misunderstood, a lot of what happens here is pure NAT64, and >unrelated to the knowledge of the Pref64: > >"the PCP Client issues a PCP MAP request with > PORT_RESERVATION_OPTION to reserve a pair of ports preserving parity > and contiguity [I-D.boucadair-pcp-rtp-rtcp]. A pair of ports and an > external IPv4 address are then returned by the PCP server to the > requesting PCP Client." > >It would be more useful to concentrate on the functionality that is only >possible when the Pref64 is known at this point. For instance, in the >case of BitTorrent, IPv4 addresses of prospective peers may be learned >from a tracker. In order for the client to connect to those peers, it >needs to synthesize IPv6 representations for those IPv4 addresses by >combining them with the Pref64. > >It would be useful to spell out that the ability to reserve ports and >learn the external IPv4 address used by the NAT64 (or any NAT) allows for >receiving incoming sessions. For this, the Pref64 is not needed. The >Pref64, on the other hand, allows for setting up outgoing connections to >systems for which only a literal IPv4 address (and not a fully qualified >domain name) is known. But for this, no other PCP functionality is >required. (Although in practice it gets more complex when ports are used >in both directions simultaneously.) > >The abstract starts with "This document defines a new PCP extension to >learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device" but the >PREFIX64 option only allows for one Pref64 and the option may only appear >once, so the (es) part shouldn't be there. (Would the ability to learn >multiple Pref64s be useful?? I guess load balancing across NAT64s with >each a Pref64 of their own is possible.) > >In 4.1 a reference to section 7.3 of RFC 6887 would be useful. > >Although I was unhappy with the SIP example earlier, I think it's >appropriate in section 5 as it shows the full complexity of a real-world >system now that we've learned all the details of the mechanism. I think >the section title should have "SIP" in it, though. > >In the security considerations, I would expect a discussion about what >happens when a malicious third party impersonates a PCP server and >provides a fake Pref64. > >Iljitsch From tireddy@cisco.com Fri May 17 23:40:40 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E17B21F8F61 for ; Fri, 17 May 2013 23:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E1gxS3KHRlH for ; Fri, 17 May 2013 23:40:35 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5676921F8E56 for ; Fri, 17 May 2013 23:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4017; q=dns/txt; s=iport; t=1368859235; x=1370068835; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qzQzSx9qg+9HyprSV9bie6cI8d1eokVNIEhNGmXDAdI=; b=mrv9W1QaMgZbwiEiNeU0lnff+xOZZd+HnGbxu+FkMFfBhk7L7Zi6hTUz xteIMtH0VClOlAYv6JNOm0G5jCJb6CHnLlbwjBMhXMgjzdtrIZ3TwY4I5 Q21jg4n+oooAY7B//lMiE491FMTskBMfUbrhNx+8a0r7Zsb0K6nwXQhzr 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQFAOchl1GtJV2Y/2dsb2JhbABbgwgwwU+BARZ0gh8BAQEDATo/DAQCAQgRBAEBAQoOBgkHMhQJCAIEAQ0FCId+Bgy9MI5wMQcGEoJbYQOTZ4R6kBeDD4Im X-IronPort-AV: E=Sophos;i="4.87,698,1363132800"; d="scan'208";a="212127498" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 18 May 2013 06:40:15 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4I6eDEZ003583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 18 May 2013 06:40:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Sat, 18 May 2013 01:40:13 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Iljitsch van Beijnum , "Reinaldo Penno (repenno)" Thread-Topic: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s using PCP Thread-Index: AQHOUzDEbXMBRF62MEG/jn6xPv84lpkKenjA Date: Sat, 18 May 2013 06:40:12 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B6EEAC@xmb-rcd-x10.cisco.com> References: <45A697A8FFD7CF48BCF2BE7E106F0604090861C4@xmb-rcd-x04.cisco.com> <751A0C06-CDD7-4FCD-84D0-C0E5BFFE12A7@muada.com> In-Reply-To: <751A0C06-CDD7-4FCD-84D0-C0E5BFFE12A7@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.71.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" , "draft-ietf-pcp-nat64-prefix64@tools.ietf.org" Subject: Re: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s using PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 06:40:40 -0000 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Friday, May 17, 2013 6:28 PM > To: Reinaldo Penno (repenno) > Cc: pcp@ietf.org; draft-ietf-pcp-nat64-prefix64@tools.ietf.org > Subject: Re: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s u= sing > PCP >=20 > On 16 mei 2013, at 13:19, Reinaldo Penno (repenno) wr= ote: >=20 > >> Title : Learn NAT64 PREFIX64s using PCP > >> URL : http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-00 > >> Authors: M. Boucadair >=20 > Ok, here is a brief review. Brief in the sense that I didn't re-familiari= ze > myself with the related RFCs. >=20 > This is clearly useful. >=20 > I found 3.2, and especially 3.2.2 very sparse, I was looking to learn mor= e > about how this mechanism is useful in practice here. Some more > applications/protocols could be listed. However, a lot of information is > provided in 3.3. Unfortunately, there are two issues with this: >=20 > 1. SIP is a very complex protocol that not everyone may be familiar with >=20 > 2. Unless I misunderstood, a lot of what happens here is pure NAT64, and > unrelated to the knowledge of the Pref64: >=20 > "the PCP Client issues a PCP MAP request with > PORT_RESERVATION_OPTION to reserve a pair of ports preserving parity > and contiguity [I-D.boucadair-pcp-rtp-rtcp]. A pair of ports and an > external IPv4 address are then returned by the PCP server to the > requesting PCP Client." >=20 > It would be more useful to concentrate on the functionality that is only > possible when the Pref64 is known at this point. For instance, in the cas= e of > BitTorrent, IPv4 addresses of prospective peers may be learned from a tra= cker. > In order for the client to connect to those peers, it needs to synthesize= IPv6 > representations for those IPv4 addresses by combining them with the Pref6= 4. >=20 > It would be useful to spell out that the ability to reserve ports and lea= rn > the external IPv4 address used by the NAT64 (or any NAT) allows for recei= ving > incoming sessions. For this, the Pref64 is not needed. The Pref64, on the > other hand, allows for setting up outgoing connections to systems for whi= ch > only a literal IPv4 address (and not a fully qualified domain name) is kn= own. > But for this, no other PCP functionality is required. (Although in practi= ce it > gets more complex when ports are used in both directions simultaneously.) >=20 > The abstract starts with "This document defines a new PCP extension to le= arn > the IPv6 prefix(es) used by a PCP-controlled NAT64 device" but the PREFIX= 64 > option only allows for one Pref64 and the option may only appear once, so= the > (es) part shouldn't be there. (Would the ability to learn multiple Pref64= s be > useful?? I guess load balancing across NAT64s with each a Pref64 of their= own > is possible.) >=20 > In 4.1 a reference to section 7.3 of RFC 6887 would be useful. >=20 > Although I was unhappy with the SIP example earlier, I think it's appropr= iate > in section 5 as it shows the full complexity of a real-world system now t= hat > we've learned all the details of the mechanism. I think the section title > should have "SIP" in it, though. >=20 > In the security considerations, I would expect a discussion about what ha= ppens > when a malicious third party impersonates a PCP server and provides a fak= e > Pref64. This is not a problem when ICE is used. If during ICE connectivity checks, = STUN request is sent to attacker. The attacker cannot send a valid STUN response because it will not be aware the password using for STUN mess= age integrity. Further RTCWEB (use case mentioned in 3.1) recommends SRTP, = so DTLS will also fail.=20 Anyway PCP client and server can be mutually authenticated using PCP authen= tication. This avoids the problem of attacker posing as PCP server. --Tiru.=20 >=20 > Iljitsch From iljitsch@muada.com Sat May 18 00:29:11 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F4121F922A for ; Sat, 18 May 2013 00:29: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 U4bYZDdKG4su for ; Sat, 18 May 2013 00:29:11 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id E4EBC21F9227 for ; Sat, 18 May 2013 00:29:10 -0700 (PDT) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r4I7NJk8045035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 18 May 2013 09:23:19 +0200 (CEST) (envelope-from iljitsch@muada.com) From: Iljitsch van Beijnum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 18 May 2013 09:29:01 +0200 Message-Id: To: tireddy@cisco.com Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Cc: "pcp@ietf.org" Subject: Re: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s using PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 07:29:11 -0000 > > In the security considerations, I would expect a discussion about = what happens > > when a malicious third party impersonates a PCP server and provides = a fake > > Pref64. > This is not a problem when ICE is used. If during ICE connectivity = checks, STUN request is sent to attacker. The attacker cannot send a = valid > STUN response because it will not be aware the password using for STUN = message integrity. Further RTCWEB (use case mentioned in 3.1) recommends = SRTP, so DTLS will also fail.=20 But what about other protocols? Especially DNSSEC. Iljitsch From tireddy@cisco.com Sat May 18 00:35:31 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBE221F925B for ; Sat, 18 May 2013 00:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y579-67QeRgd for ; Sat, 18 May 2013 00:35:20 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A2FD521F8FA9 for ; Sat, 18 May 2013 00:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1119; q=dns/txt; s=iport; t=1368862520; x=1370072120; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3ih294Fox8XU6yKFRNU11jNhgzh8DfFC9KU8v5oT6P0=; b=Wsu84gP9eW3E1s0DB3l/Kbofo513UqnFj9idYDfuX3bskw0+/DWxsiHs eXlV85l7VYhseLhLXnvAiEUzTuUkacPmAJZzln3e+2eNR+pi9ywwxo1sN tjAMGIv8ImvULPXGY3HQqn/e+Rr1A7jf90EPhQxQt+5FeIG5DgUl/kxir w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAE8ul1GtJV2b/2dsb2JhbABbgwjBf4EBFnSCHwEBAQMBOj8MBAIBCBEEAQELDgYJBzIUCQgCBA4FCId+Br0ijnAxBwYSglthA6h4gw+CJg X-IronPort-AV: E=Sophos;i="4.87,698,1363132800"; d="scan'208";a="212058316" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 18 May 2013 07:35:20 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4I7ZIAq015798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 18 May 2013 07:35:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Sat, 18 May 2013 02:35:17 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Iljitsch van Beijnum Thread-Topic: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s using PCP Thread-Index: AQHOU5ldbXMBRF62MEG/jn6xPv84lpkKjOkg Date: Sat, 18 May 2013 07:35:16 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B6EED1@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.71.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s using PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 07:35:31 -0000 > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Saturday, May 18, 2013 12:59 PM > To: Tirumaleswar Reddy (tireddy) > Cc: pcp@ietf.org > Subject: Re: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s u= sing > PCP >=20 >=20 > > > In the security considerations, I would expect a discussion about wha= t > happens > > > when a malicious third party impersonates a PCP server and provides a= fake > > > Pref64. >=20 > > This is not a problem when ICE is used. If during ICE connectivity chec= ks, > STUN request is sent to attacker. The attacker cannot send a valid > > STUN response because it will not be aware the password using for STUN > message integrity. Further RTCWEB (use case mentioned in 3.1) recommends = SRTP, > so DTLS will also fail. >=20 > But what about other protocols? Especially DNSSEC. PCP client and server can be mutually authenticated using PCP authenticatio= n. This avoids the problem of attacker posing as PCP server. This way PCP client will not learn Pref64 from attacker. --Tiru. >=20 > Iljitsch From tireddy@cisco.com Sat May 18 06:11:07 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6C421F924A for ; Sat, 18 May 2013 06:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4w34Mb8S2QXY for ; Sat, 18 May 2013 06:11:02 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 87D1521F923B for ; Sat, 18 May 2013 06:11:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2152; q=dns/txt; s=iport; t=1368882662; x=1370092262; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=HJUYGvmSAmK7Jzn3Ppy1NxV++8/Omm9QB8z8rNLNYzM=; b=JKdIiSJANBlQCwL6kEZMpDLYyPlJEHgLBBPi6XIq8Wn9OEGJ95kpsKiK kU5cOjmS74lwuC+qyJLlbieeMDVmiwgADkGJFVbCKHoxs8StowcB/RC7y GhV1Ez6J4Xbg0DHcJtw4s8g61UmDoMvsppSoVYtGEX9vLwyzwTl0i6SWY c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQFAF59l1GtJXG+/2dsb2JhbABbgwgwQ4J4vhINdBZtB4IfAQEBBCMRQw4GAQgRBAEBAwIGHQMCBDAUAQYBAQUFBBMIAYgDBwWcZI5mkU6BJo1KPoI7MmEDmGGQF4MPgiY X-IronPort-AV: E=Sophos;i="4.87,699,1363132800"; d="scan'208";a="211915484" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 18 May 2013 13:11:02 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4IDB1Wb019214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 18 May 2013 13:11:01 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Sat, 18 May 2013 08:11:01 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "pcp@ietf.org" Thread-Topic: New Version Notification for draft-reddy-pcp-auth-req-03.txt Thread-Index: AQHOUi1t3jrEgGL1zECbMbH3XBgjepkKsMPQ Date: Sat, 18 May 2013 13:11:00 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B6EFBF@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.42.112] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [pcp] FW: New Version Notification for draft-reddy-pcp-auth-req-03.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 13:11:07 -0000 d2UgaGF2ZSBwdWJsaXNoZWQgYSBuZXcgcmV2aXNpb24gb2YgZHJhZnQtcmVkZHktcGNwLWF1dGgt cmVxLTAzIGFuZCBhZGRyZXNzZWQgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIHNvIGZhci4gd2Ugd291 bGQgbGlrZSB0byB0aGFuayBEYXZlIGZvciB0aGUgZGV0YWlsZWQgcmV2aWV3IG9mIHRoZSBkb2N1 bWVudC4gUkVRLTE0IGlzIHVwZGF0ZWQgYmFzZWQgb24gSW50ZXJpbSBtZWV0aW5nIGRpc2N1c3Np b24uDQogDQpSZWdhcmRzLA0KQXV0aG9ycy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZ10gDQpTZW50OiBUaHVyc2RheSwgTWF5IDE2LCAyMDEzIDU6MzQgUE0NClRvOiBEYW4g V2luZyAoZHdpbmcpOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBSZWluYWxkbyBQZW5u byAocmVwZW5ubyk7IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpDQpTdWJqZWN0OiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJlZGR5LXBjcC1hdXRoLXJlcS0wMy50eHQNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtcmVkZHktcGNwLWF1dGgtcmVxLTAzLnR4dA0K aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaXJ1bWFsZXN3YXIgUmVkZHkgYW5k IHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1yZWRk eS1wY3AtYXV0aC1yZXENClJldmlzaW9uOgkgMDMNClRpdGxlOgkJIFBDUCBBdXRoZW50aWNhdGlv biBSZXF1aXJlbWVudHMNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTA1LTE2DQpHcm91cDoJCSBJbmRp dmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogOQ0KVVJMOiAgICAgICAgICAgICBo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yZWRkeS1wY3AtYXV0aC1y ZXEtMDMudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtcmVkZHktcGNwLWF1dGgtcmVxDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJlZGR5LXBjcC1hdXRoLXJlcS0wMw0KRGlmZjogICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1yZWRkeS1wY3AtYXV0 aC1yZXEtMDMNCg0KQWJzdHJhY3Q6DQogICBJbiBhbiBhdHRlbXB0IHRvIHJlYWNoIGNvbnNlbnN1 cyBvbiBhIFBDUCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20sDQogICB0aGlzIGRvY3VtZW50IGRl c2NyaWJlcyByZXF1aXJlbWVudHMgZm9yIFBDUCBhdXRoZW50aWNhdGlvbi4gIEl0IGlzDQogICBo b3BlZCB0aGlzIGNhbiBzZXJ2ZSBhcyB0aGUgYmFzaXMgZm9yIGEgY29tcGFyaXNvbiBvZiBQQ1AN CiAgIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From tireddy@cisco.com Sat May 18 10:23:42 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5482B21F84E3 for ; Sat, 18 May 2013 10:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1z0viuiwD3E for ; Sat, 18 May 2013 10:23:36 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8B74021F86BB for ; Sat, 18 May 2013 10:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18445; q=dns/txt; s=iport; t=1368897816; x=1370107416; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=s6E0YiBy0tmINpl723TeRUDFFUmIn0lDnrIjIRveY1Q=; b=jA0Hs8wWinau0BgSbhQQCO9xGCE5pqx7WRslO0i4OnngnOfpEUU+a7y8 6de5k+TZqC8hUJnAM/uEVT1Ql7OnYhPgGtyxM6vHZPnf3jjvqE7zvxOsv M07YwMQvCEPRQ/XB45Zid58sleK51Xfi6tgVBBmb1yTNF0IpPI5ErkHrM A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYFAL23l1GtJV2b/2dsb2JhbABbgkREMMFOexZ0gh8BAQEELT8dAgEIEQQBAQsODwcyFAkIAgQBEggTh3K9M45wNwEGEoJbYQOoeIMPgiY X-IronPort-AV: E=Sophos;i="4.87,700,1363132800"; d="scan'208,217";a="212166702" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 18 May 2013 17:23:36 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4IHNZxB015630 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 18 May 2013 17:23:35 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Sat, 18 May 2013 12:23:35 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Alper Yegin , "pcp@ietf.org" Thread-Topic: [pcp] pcp auth requirements Thread-Index: AQHORaVDKQ3d6G8P5kumseyWFL/c3ZkK012A Date: Sat, 18 May 2013 17:23:34 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> In-Reply-To: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.42.112] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A14B6EFF0xmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: Re: [pcp] pcp auth requirements 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, 18 May 2013 17:23:42 -0000 --_000_913383AAA69FF945B8F946018B75898A14B6EFF0xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alper, Please see inline [TR] From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Tuesday, April 30, 2013 12:53 PM To: pcp@ietf.org Subject: [pcp] pcp auth requirements c. If a server wants to send an unsolicited message, but the previous security association has expired 1. The server can continue to use the same SA to protect messages pertaining to that mapping, even if the SA is technically expired. "Expired" means "do not use (even if its still hanging around)". We not only do not need to use expired SAs, but also using something expire= d in any sense is plain wrong -- unless someone wants to redefine what "exp= ired" means. [TR] For example if we consider MSCHAPv2, there is configuration option where se= rver accepts the challenge-response from the client even if the password is= expired and allows it be changed. Please clarify if you have some attack in mind that would cause problems us= ing expired SA. [/TR] - Such server notifications will not change state in the PCP client. - The notification could be a trigger for the client to re-authenticate. Here the document is getting into some solution description. And as for such a solution: Instead of sending a notification that is protected with an expired SA to m= ean "re-authenticate", why not send an explicit message that says "re-authe= nticate"? [TR] The client has trusted the PCP server sometime back using mutual authentica= tion, so it can assume the integrity protected PCP response using expired S= A is coming from the same PCP server and not from some attacker posing as P= CP server. [/TR] What is gained by appearing to use an expired SA (but in fact not really us= ing it! because the payload of the notification is not consumed by the rece= iver). For example, if the server indicates that external IP address/port has changed, the PCP client can then re-authenticate with the server to confirm if the external IP address/port for the mapping has indeed changed. 2. The server can optionally trigger re-authentication with the client. Yes, that's the solution. If the server has something to send to the client= , and there's no live SA, then the server first needs to trigger re-auth, s= etup a fresh SA, then send whatever it wants to send to the client. [TR] We have updated this requirement in the new draft, please have a look. Best Regards, --Tiru. [/TR] Alper --_000_913383AAA69FF945B8F946018B75898A14B6EFF0xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alper,

 

Please see inline [TR]

 

From: Alper Ye= gin [mailto:alper.yegin@yegin.org]
Sent: Tuesday, April 30, 2013 12:53 PM
To: pcp@ietf.org
Subject: [pcp] pcp auth requirements

 



 
  =
    c.  If a server wants to send an unsolicited messag=
e, but the
          previous s=
ecurity association has expired
 
          1.  T=
he server can continue to use the same SA to protect

           =
;   messages pertaining to that mapping, even if the SA is


           =
;   technically expired.





"Expire=
d" means "do not use (even if its still hanging around)".&nb=
sp;


We not only do not need t=
o use expired SAs, but also using something expired in any sense is plain w=
rong -- unless someone wants to redefine what "expired" means.


 


[TR]


For example if we consider MSCHAPv2, there is configuration optio=
n where server accepts the challenge-response from the client even if the p=
assword is expired and allows it be changed. 


 


Please clarify if you have some attack in mind that would cause p=
roblems using expired SA.


 


[/TR]


 


    &=
nbsp;         -  Such server n=
otifications will not change state in the


           =
;      PCP client.


 


           =
;   -  The notification could be a trigger for the client to=



           =
;      re-authenticate.  




Here the doc=
ument is getting into some solution description.





And as for s=
uch a solution:





Instead of s=
ending a notification that is protected with an expired SA to mean "re=
-authenticate", why not send an explicit message that says "re-au=
thenticate"?


 


[TR] 


The client has trusted the PCP server sometime back using mutual =
authentication, so it can assume the integrity protected PCP response using=
 expired SA is coming from the same PCP server and not from some attacker p=
osing as PCP server.


[/TR]


 


What is gained by appeari=
ng to use an expired SA (but in fact not really using it! because the paylo=
ad of the notification is not consumed by the receiver).<=
/pre>






  =
            &nb=
sp;  For example, if the server indicates


           =
;      that external IP address/port has changed, =
the PCP


           =
;      client can then re-authenticate with the se=
rver to


           =
;      confirm if the external IP address/port for=
 the mapping


           =
;      has indeed changed.


 


          2.  T=
he server can optionally trigger re-authentication with

           =
;   the client.




 






 






Yes, that's the solution. If the server has somethin=
g to send to the client, and there's no live SA, then the server first need=
s to trigger re-auth, setup a fresh SA, then send whatever it wants to send=
 to the client.


 


[TR]


 


We have updated this requirement in the new draft, please have a =
look.


 


Best Regards,


--Tiru.


 


[/TR]


 






 






Alper






 






 






 






 
--_000_913383AAA69FF945B8F946018B75898A14B6EFF0xmbrcdx10ciscoc_-- From repenno@cisco.com Sat May 18 14:07:04 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EDF21F8CA0 for ; Sat, 18 May 2013 14:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIJ2T-KE2+aa for ; Sat, 18 May 2013 14:06:59 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B55F021F8BC5 for ; Sat, 18 May 2013 14:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1245; q=dns/txt; s=iport; t=1368911218; x=1370120818; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=qRpycE2ObhBcF+axFD83vy6w02KIBh0ZKJsG9UUlIkI=; b=O5wPcQMJR/mM537CFnHRTty/mbc7CUQX0WLbb5i2jMOcSLUZWcq2p02S dYu9tHjMyQLI/b+aCcCan9Dz+nSpxuDNOsvILPkPVkc1xK//dUheAw5Ka EQqLFAiyZzo1xRHG7nt11arwJm0HM4FfPyt+nPNk/gVF0dwYyO23uxils A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQFABntl1GtJV2a/2dsb2JhbABbgwgwwU58FnSCGAMGAQQBAQEkEzQdAQgiFDcLJQIEARIIhUEHgh8eDL0UjV+BETiCJ0xhA5hhiHKHJYMPgXE1 X-IronPort-AV: E=Sophos;i="4.87,700,1363132800"; d="scan'208";a="209211643" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 18 May 2013 21:06:58 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4IL6wrU021892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 18 May 2013 21:06:58 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Sat, 18 May 2013 16:06:58 -0500 From: "Reinaldo Penno (repenno)" To: Simon Perreault , "pcp@ietf.org" Thread-Topic: [pcp] PORT_SET for discovering static port set mappings Thread-Index: AQHOUwjMWJqbrRT94kiXOQ14KOgabpkLkrWA Date: Sat, 18 May 2013 21:06:57 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F060409087A7A@xmb-rcd-x04.cisco.com> In-Reply-To: <51963B2A.4020607@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.73.175] Content-Type: text/plain; charset="us-ascii" Content-ID: <710758324065F74CAF6683531C616315@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] PORT_SET for discovering static port set mappings 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, 18 May 2013 21:07:04 -0000 Interesting. How about stateless NAT64? And last but not least, how about PEER messages? I will send a separate message about my experiments with transmission Bittorrent to see other people's opinion. The current message does not allow the client to specify the internal port set. On 5/17/13 11:14 AM, "Simon Perreault" wrote: >WG, > >In private email, Cathy Zhou has suggested the following addition to >draft-ietf-pcp-port-set: > >1.4. Discovering Stateless Port Set Mappings > > A MAP request can be used to discover a stateless mapping. > Similarly, a MAP request with a PORT_SET request can be used to > discover a stateless port set mapping. Hence, PORT_SET is applicable > for port set mapping discovery in Stateless NAT44 > [I-D.tsou-stateless-nat44]. > >Unless the WG disagrees, it will be part of the next revision. > >Simon >--=20 >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From sagrawal@juniper.net Sat May 18 17:09:19 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C0121F8C38 for ; Sat, 18 May 2013 17:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.248 X-Spam-Level: X-Spam-Status: No, score=-1.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, TVD_SPACE_RATIO=2.219, UNRESOLVED_TEMPLATE=3.132] 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 4lwrNJzIwfzv for ; Sat, 18 May 2013 17:09:12 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id C826C21F8BC0 for ; Sat, 18 May 2013 17:09:12 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUZgYJyBQVIsHdlLSxucxxNr1C9u6EgVv@postini.com; Sat, 18 May 2013 17:09:12 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 18 May 2013 17:07:39 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Sat, 18 May 2013 17:07:39 -0700 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.206) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 18 May 2013 17:10:27 -0700 Received: from mail88-am1-R.bigfish.com (10.3.201.235) by AM1EHSOBE025.bigfish.com (10.3.207.147) with Microsoft SMTP Server id 14.1.225.23; Sun, 19 May 2013 00:07:37 +0000 Received: from mail88-am1 (localhost [127.0.0.1]) by mail88-am1-R.bigfish.com (Postfix) with ESMTP id 49F4E80622 for ; Sun, 19 May 2013 00:07:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 7 X-BigFish: PS7(z569dh4dc7ozda00hd751hdc73hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzzz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1155h) Received: from mail88-am1 (localhost.localdomain [127.0.0.1]) by mail88-am1 (MessageSwitch) id 1368922056329322_13788; Sun, 19 May 2013 00:07:36 +0000 (UTC) Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.248]) by mail88-am1.bigfish.com (Postfix) with ESMTP id 43FD2480057 for ; Sun, 19 May 2013 00:07:36 +0000 (UTC) Received: from BLUPRD0511HT005.namprd05.prod.outlook.com (157.56.232.213) by AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 19 May 2013 00:07:36 +0000 Received: from BLUPRD0511MB437.namprd05.prod.outlook.com ([169.254.7.118]) by BLUPRD0511HT005.namprd05.prod.outlook.com ([10.255.135.168]) with mapi id 14.16.0311.000; Sun, 19 May 2013 00:07:25 +0000 From: "Sanjay V. Agrawal" To: "pcp@ietf.org" Thread-Topic: Bbhfh Thread-Index: Ac5UJNcnTKBQ51OKTaaObtqLRwPBJQ== Date: Sun, 19 May 2013 00:07:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.18.248.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <6D4859A55A5A9E439AE0DE6F89895E74@junipernetworks.onmicrosoft.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [pcp] Bbhfh 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, 19 May 2013 00:09:19 -0000 -Sanjay From simon.perreault@viagenie.ca Sun May 19 22:54:19 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E4C21F8F12 for ; Sun, 19 May 2013 22:54:16 -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 FPXJufA1e79X for ; Sun, 19 May 2013 22:54:12 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id C91CF21F8EFD for ; Sun, 19 May 2013 22:54:11 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 25833403AA; Mon, 20 May 2013 01:54:10 -0400 (EDT) Message-ID: <5199BA80.7060002@viagenie.ca> Date: Mon, 20 May 2013 07:54:08 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Reinaldo Penno (repenno)" References: <45A697A8FFD7CF48BCF2BE7E106F060409087A7A@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F060409087A7A@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "pcp@ietf.org" Subject: Re: [pcp] PORT_SET for discovering static port set mappings 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, 20 May 2013 05:54:20 -0000 Le 2013-05-18 23:06, Reinaldo Penno (repenno) a écrit : > Interesting. How about stateless NAT64? Sure, it could be used for that too. Any NATxy static port set mapping can be discovered. > And last but not least, how about PEER messages? I will send a separate > message about my experiments with transmission Bittorrent to see other > people's opinion. > > > The current message does not allow the client to specify the internal port > set. Right. So far we have considered PEER out of scope for this draft. 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 alper.yegin@yegin.org Mon May 20 01:38:35 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26C321F937A for ; Mon, 20 May 2013 01:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.448 X-Spam-Level: X-Spam-Status: No, score=-101.448 tagged_above=-999 required=5 tests=[AWL=1.149, BAYES_00=-2.599, HTML_MESSAGE=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 XL1w4yIJPAGk for ; Mon, 20 May 2013 01:38:04 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id B841421F8BBC for ; Mon, 20 May 2013 00:59:26 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M8NJq-1UIf7Z1ify-00vEXz; Mon, 20 May 2013 03:53:36 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_BB3AE18A-6CEC-46B3-916E-09FA299F93E9" From: Alper Yegin In-Reply-To: <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> Date: Mon, 20 May 2013 10:53:29 +0300 Message-Id: <8AF116E2-B8E5-4228-8437-B8B4867CA6E2@yegin.org> References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> To: Tirumaleswar Reddy (tireddy) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:m5GWhnVRAQwPuiRmW2ph37/p2iycRlUZMrTIgdup0nJ yYj0V/FZjYaFPy47oQjz8LgTApdQVmai2mWrtsmlLSAKgiVWJ0 uDcaGsVgqoYUpf718fJldeItPGoBz18HoOpO7vnOUKicPv2BtE qvkQczXvj+84AX+E5//SU8fKY5iPLI7utEf7Ea/Wp5+lI+fu/3 7gNPtrPsH54pDG158uAdUORVKlE5g4KqeDXdUvg48sM6FgspsV wBrz+3QH5zANsl/aCeMUVmZvJlhvOC5ORDhAVOkueaWwZUZlxi MkkmDxWddMiZCgwmTxGGu9O2JshsJZiVeDK9HTFNgAJZbAoV01 Xoz94MkxmBdEDP3+DQ6hLrPDlqgfBrP/HDElSrYacUHBD4dylg 81lSFTKmV5B2Q== Cc: "pcp@ietf.org" Subject: Re: [pcp] pcp auth requirements 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, 20 May 2013 08:38:41 -0000 --Apple-Mail=_BB3AE18A-6CEC-46B3-916E-09FA299F93E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Tiru, Please see below. c. If a server wants to send an unsolicited message, but the previous security association has expired =20 1. The server can continue to use the same SA to protect messages pertaining to that mapping, even if the SA is technically expired. "Expired" means "do not use (even if its still hanging around)".=20 We not only do not need to use expired SAs, but also using something = expired in any sense is plain wrong -- unless someone wants to redefine = what "expired" means. =20 [TR] For example if we consider MSCHAPv2, there is configuration option where = server accepts the challenge-response from the client even if the = password is expired and allows it be changed.=20 Alper> In that case the password is "expired for login purpose" (i.e., = the user cannot login using the password), but it's still "unexpired for = password change purpose" (and in fact the previous password is expired = even for that purpose).=20 =20 Please clarify if you have some attack in mind that would cause problems = using expired SA. Alper> SAs are given finite lifetimes for one of many reasons. It can be = for limiting the use of keys because they cannot stand infinite amount = of use in the face of crypto-attacks, it can be for limiting the access = to the service (because the service provider allows finite access to the = subscriber), it can be for periodically challenging the client to ensure = the client device is not compromised, etc. etc.=20 Alper> These are all deployment considerations. At the protocol design = level, we won't know why the SA lifetime is set to the value it is set = to. Using the SA beyond its lifetime is going to violate one of the = deployment considerations, and we won't even know which. And we won't = know how to remedy it. This is complicated. Alper> It's even more complicated. How long would each party hold on to = the expired SAs? What happens if the receiver has "rightfully" yanked = the SA after it expired? Alper> I don't see the utility of using expired SAs either. If the = server wants to tell the client to re-auth, it should just do that. No = point in using expired SAs to do that. =20 [/TR] =20 - Such server notifications will not change state in the PCP client. =20 - The notification could be a trigger for the client to re-authenticate. =20 Here the document is getting into some solution description. Alper> Just to make sure=85 I'm saying the document shall not get into = the solution space. And as for such a solution: Instead of sending a notification that is protected with an expired SA = to mean "re-authenticate", why not send an explicit message that says = "re-authenticate"? =20 [TR]=20 The client has trusted the PCP server sometime back using mutual = authentication, so it can assume the integrity protected PCP response = using expired SA is coming from the same PCP server and not from some = attacker posing as PCP server. [/TR] =20 Alper> The client knows the IP address of the PCP server, right? So, = the first line of defense is to check if the IP address of the PCP = server is the expected one. Alper> Let's say the attacker is using the legit PCP server IP address, = and it worked its way thru ingress filtering. Alper> The worst that happens is (when not using expired SAs), the = client is triggered to enter the re-auth phase. Alper> If the attacker is not able to receive the responses, then the = first message exchange will hang because the attacker cannot receive = and respond. Client will timeout and that's it. Alper> If the attacker is able to receive responses as well (somehow = it's MitM), then the re-auth works all the way, until the = "authentication" fails.=20 Alper> No serious harm is done.=20 Alper> In either case, this is a minor threat that simply gets the PCP = client into single re-auth when it in fact didn't have to.=20 Alper> Using expired SA prevents that, but the complexity and unknown = side effects are not worth it.=20 What is gained by appearing to use an expired SA (but in fact not really = using it! because the payload of the notification is not consumed by the = receiver). For example, if the server indicates that external IP address/port has changed, the PCP client can then re-authenticate with the server to confirm if the external IP address/port for the mapping has indeed changed. =20 2. The server can optionally trigger re-authentication with the client. =20 =20 Yes, that's the solution. If the server has something to send to the = client, and there's no live SA, then the server first needs to trigger = re-auth, setup a fresh SA, then send whatever it wants to send to the = client. =20 [TR] =20 We have updated this requirement in the new draft, please have a look. Alper> I see "The server MUST be able to optionally trigger = re-authentication with the client." Alper> Then using expired SA could be to about "using the expired SA to = protect the trigger message". Alper =20 Best Regards, --Tiru. =20 [/TR] --Apple-Mail=_BB3AE18A-6CEC-46B3-916E-09FA299F93E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Tiru,

Please see = below.

      c.  = If a server wants to send an unsolicited message, but the
 

"Expired" means "do not use (even if its = still hanging around)". 
We not only do not need to = use expired SAs, but also using something expired in any sense is plain = wrong -- unless someone wants to redefine what "expired" means.

 

[TR]
For example if we consider = MSCHAPv2, there is configuration option where server accepts the = challenge-response from the client even if the password is expired and = allows it be changed. 



Alper> In that = case the password is "expired for login purpose" (i.e., the user cannot = login using the password), but it's still "unexpired for password change = purpose" (and in fact the previous password is expired even for that = purpose). 


Please clarify if you have some attack in = mind that would cause problems using expired SA.


Alper> SAs are given finite lifetimes for one of many reasons. = It can be for limiting the use of keys because they cannot stand = infinite amount of use in the face of crypto-attacks, it can be for = limiting the access to the service (because the service provider allows = finite access to the subscriber), it can be for periodically challenging = the client to ensure the client device is not compromised, etc. = etc. 


Alper> These are all deployment = considerations. At the protocol design level, we won't know why the SA = lifetime is set to the value it is set to. Using the SA beyond its = lifetime is going to violate one of the deployment considerations, and = we won't even know which. And we won't know how to remedy it. This is = complicated.


Alper> It's even more = complicated. How long would each party hold on to the expired SAs? What = happens if the receiver has "rightfully" yanked the SA after it = expired?

Alper> I don't see the utility of = using expired SAs either. If the server wants to tell the client to = re-auth, it should just do that. No point in using expired SAs to do = that.


 

 

 

            =      re-authenticate.  

Here the document is getting = into some solution description.

Alper> Just to make sure=85 I'm saying the = document shall not get into the solution space.

And as for such a solution:

Instead of sending a = notification that is protected with an expired SA to mean = "re-authenticate", why not send an explicit message that says = "re-authenticate"?

 

[TR] 
[/TR]

 


Alper>  The client knows the = IP address of the PCP server, right? So, the first line of defense is to = check if the IP address of the PCP server is the expected = one.
Alper>  Let's say the attacker is using the legit = PCP server IP address, and it worked its way thru ingress = filtering.
Alper> The worst that happens is (when not using = expired SAs), the client is triggered to enter the re-auth = phase.
Alper> If the attacker is not able to receive the = responses, then the first message exchange will hang  because the = attacker cannot receive and respond. Client will timeout and that's = it.
Alper> If the attacker is able to receive responses as = well (somehow it's MitM), then the re-auth works all the way, until the = "authentication" fails. 
Alper> No serious harm is = done. 

Alper> In either case, this is a = minor threat that simply gets the PCP client into single re-auth when it = in fact didn't have to. 

Alper> Using = expired SA prevents that, but the complexity and unknown side effects = are not worth = it. 





            =      confirm if the external IP address/port for the = mapping
 

 

 

 

[TR]

 

We have updated this requirement in the new = draft, please have a look.



Alper> I see = "The server MUST be able to = optionally trigger re-

Alper> Then using expired SA could be to = about "using the expired SA to protect the trigger = message".

Alper


 

Best Regards,
--Tiru.

 

To: Simon Perreault Thread-Topic: [pcp] PORT_SET for discovering static port set mappings Thread-Index: AQHOUwjMWJqbrRT94kiXOQ14KOgabpkLkrWAgAJX7QCAAB49gA== Date: Mon, 20 May 2013 10:42:23 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F060409087E21@xmb-rcd-x04.cisco.com> In-Reply-To: <5199BA80.7060002@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.243.6] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] PORT_SET for discovering static port set mappings 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, 20 May 2013 10:42:30 -0000 On 5/20/13 2:54 AM, "Simon Perreault" wrote: >Le 2013-05-18 23:06, Reinaldo Penno (repenno) a =E9crit : >> Interesting. How about stateless NAT64? > >Sure, it could be used for that too. Any NATxy static port set mapping >can be discovered. > >> And last but not least, how about PEER messages? I will send a separate >> message about my experiments with transmission Bittorrent to see other >> people's opinion. >> >> >> The current message does not allow the client to specify the internal >>port >> set. > >Right. So far we have considered PEER out of scope for this draft. I have the following scenario so we can gauge if PEER is in scope: - I changed transmission BT to send a PEER message for every outgoing TCP connection it makes. After running a few tests the issue that bubbled up is that both Transmission and my FW/NAT is paying a penalty for using PCP PEER this way since they both need manage 100s (or 1000s) of PEER mappings. For P2P software and some video streaming clients that have a high number of connections, the use of PCP should be simplified. I thought about two of ways of doing that: - Wildcards in PEER messages - PEER Port set. I guess one can argue a port set is a middle ground between a fully specified 5-tuple and a wildcard. Both have issues that need ironing out but I believe it would simplify considerably PCP use for those types of clients. > >Simon >--=20 >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Mon May 20 04:04:05 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FA421F910D for ; Mon, 20 May 2013 04:04:05 -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 vD-MLoJXr86M for ; Mon, 20 May 2013 04:04:04 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4E80921F9133 for ; Mon, 20 May 2013 04:04:03 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3C40F40062; Mon, 20 May 2013 07:04:02 -0400 (EDT) Message-ID: <519A0321.4010808@viagenie.ca> Date: Mon, 20 May 2013 13:04:01 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Reinaldo Penno (repenno)" References: <45A697A8FFD7CF48BCF2BE7E106F060409087E21@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F060409087E21@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "pcp@ietf.org" Subject: Re: [pcp] PORT_SET for discovering static port set mappings 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, 20 May 2013 11:04:05 -0000 Le 2013-05-20 12:42, Reinaldo Penno (repenno) a écrit : > I have the following scenario so we can gauge if PEER is in scope: > > - I changed transmission BT to send a PEER message for every outgoing TCP > connection it makes. > > After running a few tests the issue that bubbled up is that both > Transmission and my FW/NAT is paying a penalty for using PCP PEER this way > since they both need manage 100s (or 1000s) of PEER mappings. For P2P > software and some video streaming clients that have a high number of > connections, the use of PCP should be simplified. I thought about two of > ways of doing that: > > - Wildcards in PEER messages > > - PEER Port set. I guess one can argue a port set is a middle ground > between a fully specified 5-tuple and a wildcard. > > Both have issues that need ironing out but I believe it would simplify > considerably PCP use for those types of clients. I understand the need for optimization in this use case. But I don't see how PORT_SET could apply, because your 100s of connections are to 100s of different remote peer IP addresses. With wildcards you could probably cover this, but you would end up with an under-constrained request awfully close to meaning "refresh everything". Why not use a MAP request with a PORT_SET option to get some ports and make the BT client use those ports as source for new outbound connections? You would not need a very large set since destinations would vary so you could overload source ports. Then you can refresh the set with a single request. 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 repenno@cisco.com Mon May 20 04:57:44 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B0321F912C for ; Mon, 20 May 2013 04:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyqk17-I8FDL for ; Mon, 20 May 2013 04:57:39 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A0F5521F90FC for ; Mon, 20 May 2013 04:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2391; q=dns/txt; s=iport; t=1369051059; x=1370260659; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+QDGjlrJtJD0ZYxx+CPDhKhWVY4FFPG29IltN7vs6ps=; b=XvUrnTKQZ9HadHAfHsHS29fUeog4btI9/+MY1F1mtcjT8Kz+apNEU6/J gtKLH3csHqkDtAocZF6ERoCnZK8ZhhJsQbLmP8KA19t328PP1j0nqIySy q5Cz0ig9upviTtihMakpxQyQpGnImD/Dp6mEdhp5ongXtxyfZCbb1Vr5t Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4FALYOmlGtJXG9/2dsb2JhbABagwgwwTt/FnSCIQEEJ1ISAQgiViUCBA4FCIgFul2OcDEHgnNhA4hnj3qIcoclgw+CJg X-IronPort-AV: E=Sophos;i="4.87,707,1363132800"; d="scan'208";a="212588945" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 20 May 2013 11:57:39 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4KBvdKW016853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 May 2013 11:57:39 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Mon, 20 May 2013 06:57:38 -0500 From: "Reinaldo Penno (repenno)" To: Simon Perreault Thread-Topic: [pcp] PORT_SET for discovering static port set mappings Thread-Index: AQHOUwjMWJqbrRT94kiXOQ14KOgabpkLkrWAgAJX7QCAAB49gIAAOFiA///cP4A= Date: Mon, 20 May 2013 11:57:38 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F060409087E96@xmb-rcd-x04.cisco.com> In-Reply-To: <519A0321.4010808@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.255.45] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0C7A8184CF982C4580BCE6AF0A240D77@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] PORT_SET for discovering static port set mappings 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, 20 May 2013 11:57:45 -0000 On 5/20/13 8:04 AM, "Simon Perreault" wrote: >Le 2013-05-20 12:42, Reinaldo Penno (repenno) a =E9crit : >> I have the following scenario so we can gauge if PEER is in scope: >> >> - I changed transmission BT to send a PEER message for every outgoing >>TCP >> connection it makes. >> >> After running a few tests the issue that bubbled up is that both >> Transmission and my FW/NAT is paying a penalty for using PCP PEER this >>way >> since they both need manage 100s (or 1000s) of PEER mappings. For P2P >> software and some video streaming clients that have a high number of >> connections, the use of PCP should be simplified. I thought about two of >> ways of doing that: >> >> - Wildcards in PEER messages >> >> - PEER Port set. I guess one can argue a port set is a middle ground >> between a fully specified 5-tuple and a wildcard. >> >> Both have issues that need ironing out but I believe it would simplify >> considerably PCP use for those types of clients. > >I understand the need for optimization in this use case. But I don't see >how PORT_SET could apply, because your 100s of connections are to 100s >of different remote peer IP addresses. With wildcards you could probably >cover this, but you would end up with an under-constrained request >awfully close to meaning "refresh everything". The source IP and protocol are the same. The source port many times is the same across many different connections. > >Why not use a MAP request with a PORT_SET option to get some ports and >make the BT client use those ports as source for new outbound >connections? You would not need a very large set since destinations >would vary so you could overload source ports. This overloading is already heavily done as can be seen by looking at the connection table. But since destinations are different, usually one mapping per session is maintained. >Then you can refresh the >set with a single request. Asking for a MAP PORSET (incoming IP and port are wildcard) isn't the same as asking for a PEER where the destination IP and port are wildcard? How would this work with FW? > >Simon >--=20 >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca From internet-drafts@ietf.org Mon May 20 05:44:38 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A3421F8201; Mon, 20 May 2013 05:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtBSOF+SB0CS; Mon, 20 May 2013 05:44:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CD221F92B2; Mon, 20 May 2013 05:44:18 -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.45 Message-ID: <20130520124417.23283.20831.idtracker@ietfa.amsl.com> Date: Mon, 20 May 2013 05:44:17 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-port-set-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 12:44:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Port Control Protocol Working Group of th= e IETF. Title : Port Control Protocol (PCP) Extension for Port Set Alloc= ation Author(s) : Qiong Sun Mohamed Boucadair Senthil Sivakumar Cathy Zhou Tina Tsou Simon Perreault Filename : draft-ietf-pcp-port-set-01.txt Pages : 12 Date : 2013-05-20 Abstract: This document defines an extension to PCP allowing clients to manipulate sets of ports as a whole. This is accomplished by a new MAP option: PORT_SET. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-port-set There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-port-set-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-port-set-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From simon.perreault@viagenie.ca Mon May 20 05:49:16 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6549C21F91B8 for ; Mon, 20 May 2013 05:49:16 -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 ZaKVrrj9jJLB for ; Mon, 20 May 2013 05:49:15 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9846C21F9050 for ; Mon, 20 May 2013 05:49:15 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0665E40440 for ; Mon, 20 May 2013 08:49:14 -0400 (EDT) Message-ID: <519A1BCA.2050009@viagenie.ca> Date: Mon, 20 May 2013 14:49:14 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: pcp@ietf.org References: <20130520124417.23283.20831.idtracker@ietfa.amsl.com> In-Reply-To: <20130520124417.23283.20831.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] I-D Action: draft-ietf-pcp-port-set-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 12:49:16 -0000 All, This revision brings many important enhancements: - Added a new example of an application benefiting from PORT_SET. - Added a new use case: discovering static port set mappings. - Moved the P bit to the option payload. - Made the option code optional to process. - Many clarifications. - New section 4.3.1 describes server behaviour in overlap conditions. Simon Le 2013-05-20 14:44, internet-drafts@ietf.org a écrit : > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Port Control Protocol Working Group of the IETF. > > Title : Port Control Protocol (PCP) Extension for Port Set Allocation > Author(s) : Qiong Sun > Mohamed Boucadair > Senthil Sivakumar > Cathy Zhou > Tina Tsou > Simon Perreault > Filename : draft-ietf-pcp-port-set-01.txt > Pages : 12 > Date : 2013-05-20 > > Abstract: > This document defines an extension to PCP allowing clients to > manipulate sets of ports as a whole. This is accomplished by a new > MAP option: PORT_SET. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pcp-port-set > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-pcp-port-set-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-port-set-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Mon May 20 07:52:41 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F19621F9048 for ; Mon, 20 May 2013 07:52:41 -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 TP9p07cQiTH0 for ; Mon, 20 May 2013 07:52:41 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 05D5E21F8EF7 for ; Mon, 20 May 2013 07:52:41 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4C45F403A2 for ; Mon, 20 May 2013 10:52:40 -0400 (EDT) Message-ID: <519A38B7.6080005@viagenie.ca> Date: Mon, 20 May 2013 16:52:39 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: "pcp@ietf.org" References: <45A697A8FFD7CF48BCF2BE7E106F0604090861C4@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090861C4@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s using PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 14:52:41 -0000 Le 2013-05-16 13:19, Reinaldo Penno (repenno) a écrit : >> Title : Learn NAT64 PREFIX64s using PCP >> URL : http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-00 >> Authors: M. Boucadair And here's my review... The draft is almost ready. One remaining issue that should be easy to fix: the reference to draft-boucadair-pcp-rtp-rtcp should be replaced by one to draft-ietf-pcp-port-set, and the example in section 3.3 adjusted. 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 bn.mccann@gmail.com Mon May 20 08:30:14 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BB421F8E3C for ; Mon, 20 May 2013 08:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.205 X-Spam-Level: X-Spam-Status: No, score=-3.205 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 9NhI4TBr4NHy for ; Mon, 20 May 2013 08:30:08 -0700 (PDT) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id 10AE421F881C for ; Mon, 20 May 2013 08:30:08 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kl13so5790289pab.34 for ; Mon, 20 May 2013 08:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=Uqpn/iyOC9rSYnuNU172Giw/RLzWnb+8/un9HqBeJ38=; b=pEM9m0RxYxFNvDSCuoGCqfQdW51GI5GpfXmFmEbkbW2WHPsecAJgsMkGX9eBDO/CaJ qcmnX3zuRE9rbTcqs3fZ6s/a92q7wy87xsDkUiZGvvfoPH0VHVRGoBa5WkWrOAsOd3NI +SfXIvYx3IeSHjyHf8uf2o/38IDnSQhX65B+BGGC0NW6Fy45muLuXZSH3WvK/QT6xNSU fy6W7c+BD8ufhpfs3sAosRE1wEnKD+Z+4Kujk9jn5XYG8ZFyxeK0/80M2IABVQBR9sRh 2FpFsIcwsTCEg9OPia/zg7b3TP5t1mpy5Ji/qsQ2M7jMYLVNiJo1Fl2+jkCtrHkN9Y/p cVXg== X-Received: by 10.68.130.199 with SMTP id og7mr61958759pbb.132.1369063807804; Mon, 20 May 2013 08:30:07 -0700 (PDT) Received: from [10.10.20.184] (70-88-209-30-ubr905-ne-ma.hfc.comcastbusiness.net. [70.88.209.30]) by mx.google.com with ESMTPSA id v7sm24530783pbq.32.2013.05.20.08.30.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 May 2013 08:30:06 -0700 (PDT) Message-ID: <519A4189.407@gmail.com> Date: Mon, 20 May 2013 11:30:17 -0400 From: Ben McCann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: pcp@ietf.org Content-Type: multipart/alternative; boundary="------------080904030900040906010504" Subject: [pcp] Clarification to Section 15 of RFC 6887 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, 20 May 2013 15:30:14 -0000 This is a multi-part message in MIME format. --------------080904030900040906010504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm finding the discussion in section 15 of the RFC confusing because the use of 'mapping' in Section 15 is ambiguous to me. (Yes, 'mapping' is defined in the terminology section of the RFC but it's still ambiguous in Section 15). My problem is that the RFC states a MAP opcode creates a 'mapping' but then it doesn't really discuss the difference between an explicit mapping created by PCP and and other implicit mappings created, on demand, by the PCP created explicit mapping. The following points attempt to use the terminology in RFC 6887: * An 'implicit dynamic outbound' mapping defines the transformation of *one* TCP or UDP flow from a client behind the NAT to a server outside the NAT. This mapping is created implicitly when the client connects to the server. Typically the client's source address and port are rewritten by the NAT to some other source address and port owned by the NAT. Most importantly, *both* endpoints of the flow are known. * In contrast, an 'explicit dynamic inbound' mapping created by the PCP MAP opcode only defines *one* endpoint. A server behind the NAT defines its listening endpoint and the NAT provides a corresponding listening endpoint on the outside of the NAT. The IP address and port of clients outside the NAT are unknown, at this time, because all we've created is a 'listener'. * When a client outside the NAT connects to a server behind the NAT via the 'explicit dynamic inbound' mapping then another 'mapping' is created. This 'mapping' has *two* endpoints, like an implicit dynamic outbound mapping, and it is created implicitly using the 'explict dynamic inbound' mapping defined by the PCP MAP opcode. I don't think the RFC does a good job of labeling or describing this kind of mapping. I *think* the RFC also uses the term 'explicit mapping' for this kind of mapping but I find that misleading. This mapping is created implicitly when a TCP SYN packet from a client outside the NAT was transmitted to a server *behind* the NAT. For now, I'm calling this an 'IMPLICIT INBOUND MAPPING'. Note that inbound and outbound IMPLICIT mappings have an 'idle-timeout time' which describes when the mapping can be destroyed due to lack of traffic. That timeout must (I think) be at least 2 minutes for UDP and 124 minutes for TCP. (The exact timeout limits aren't critical to this discussion). The discussion in Section 15 about 'mapping lifetime and deletion' can (I think) be interpreted in different ways depending on the definition of 'mapping'. When a MAP request arrives with a zero lifetime then we have to clean up some inbound mapping but, I argue, that cleanup varies depending on whether the mapping is explicit (created by PCP MAP) or implicit (created implicitly on behalf ofsome *other* explicit inbound mapping). Specifically: * The 'explicit dynamic inbound' mapping created by the PCP MAP opcode must be deleted *immediately*. The server behind the NAT wants no *new* inbound connections. It is no longer 'listening'. * The 'implicit dynamic inbound' mappings, that are TCP and UDP flows connecting two distinct endpoints, must be deleted at the end of their NAT idle-timeout time. I.e. if a packet has been received within the NAT idle-timeout time then the 'implicit dynamic inbound' mapping CANNOT be deleted because a flow is still active between two endpoints. If the 'implicit dynamic inbound' mapping has been idle for longer than the NAT idle-timeout time then it can be deleted, if it hasn't been already. The RFC seems to imply that its OK to delete 'implicit dynamic mapping's that were idle for more than the NAT idle timeout when a PCP MAP opcode is received with a lifetime of zero. That doesn't make sense to me because why wasn't it ALREADY deleted? It's idle. I think this can be boiled down to a simpler description of 'lifetime' and 'timeouts': * Servers behind a NAT use the PCP MAP opcode to start listening for incoming connections from clients outside the NAT. The 'lifetime' within the PCP MAP opcode declares how long the server wants to listen for new connections. This must be refreshed (with another MAPopcode) before the lifetime expires if the server wishes to continue listening. * An 'implicit dynamic inbound' mapping is created when clients connect to the server that declared its intent to listen for connections via the PCP MAP request. The 'idle-timeout' time of that mapping is defined by TCP or UDP protocol and the policy of the NAT box. If neither client nor server transmits packets within this 'idle-timeout' time then the 'implicit dynamic inbound' mapping will be automatically destroyed. * Any 'implicit dynamic inbound' mappings created by an 'explicit inbound mapping' created by PCP MAP that are still active when the 'explicit inbound mapping' is destroyed SHALL NOT be destroyed as a side-effect of destroying the PCP mapping. The 'implicit dynamic inbound' mappings shall be destroyed when the peers either close the connection or when the idle-timeout expires. Is this 'simpler description' consistent with the behavior of PCP lifetimes as intended by Section 15 of RFC 6887? -Ben McCann --------------080904030900040906010504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I'm finding the discussion in section 15 of the RFC confusing because the use of 'mapping' in Section 15 is ambiguous to me. (Yes, 'mapping' is  defined in the terminology section of the RFC but it's still ambiguous in Section 15).

My problem is that the RFC states a MAP opcode creates a 'mapping' but then it doesn't really discuss the difference between an explicit mapping created by PCP and and other implicit mappings created, on demand, by the PCP created explicit mapping. The following points attempt to use the terminology in RFC 6887:
  • An 'implicit dynamic outbound' mapping defines the transformation of *one* TCP or UDP flow from a client behind the NAT to a server outside the NAT. This mapping is created implicitly when the client connects to the server. Typically the client's source address and port are rewritten by the NAT to some other source address and port owned by the NAT. Most importantly, *both* endpoints of the flow are known.
  • In contrast, an 'explicit dynamic inbound' mapping created by the PCP MAP opcode only defines *one* endpoint. A server behind the NAT defines its listening endpoint and the NAT provides a corresponding listening endpoint on the outside of the NAT. The IP address and port of clients outside the NAT are unknown, at this time, because all we've created is a 'listener'.
  • When a client outside the NAT connects to a server behind the NAT via the 'explicit dynamic inbound' mapping then another 'mapping' is created. This 'mapping' has *two* endpoints, like an implicit dynamic outbound mapping, and it is created implicitly using the 'explict dynamic inbound' mapping defined by the PCP MAP opcode. I don't think the RFC does a good job of labeling or describing this kind of mapping. I *think* the RFC also uses the term 'explicit mapping' for this kind of mapping but I find that misleading. This mapping is created implicitly when a TCP SYN packet from a client outside the NAT was transmitted to a server *behind* the NAT. For now, I'm calling this an 'IMPLICIT INBOUND MAPPING'.
Note that inbound and outbound IMPLICIT mappings have an 'idle-timeout time' which describes when the mapping can be destroyed due to lack of traffic. That timeout must (I think) be at least 2 minutes for UDP and 124 minutes for TCP. (The exact timeout limits aren't critical to this discussion).

The discussion in Section 15 about 'mapping lifetime and deletion' can (I think) be interpreted in different ways depending on the definition of 'mapping'. When a MAP request arrives with a zero lifetime then we have to clean up some inbound mapping but, I argue, that cleanup varies depending on whether the mapping is explicit (created by PCP MAP) or implicit (created implicitly on behalf of some *other* explicit inbound mapping).

Specifically:
  • The 'explicit dynamic inbound' mapping created by the PCP MAP opcode must be deleted *immediately*. The server behind the NAT wants no *new* inbound connections. It is no longer 'listening'.
  • The 'implicit dynamic inbound' mappings, that are TCP and UDP flows connecting two distinct endpoints, must be deleted at the end of their NAT idle-timeout time. I.e. if a packet has been received within the NAT idle-timeout time then the 'implicit dynamic inbound' mapping CANNOT be deleted because a flow is still active between two endpoints. If the 'implicit dynamic inbound' mapping has been idle for longer than the NAT idle-timeout time then it can be deleted, if it hasn't been already.
The RFC seems to imply that its OK to delete 'implicit dynamic mapping's that were idle for more than the NAT idle timeout when a PCP MAP opcode is received with a lifetime of zero. That doesn't make sense to me because why wasn't it ALREADY deleted? It's idle.

I think this can be boiled down to a simpler description of 'lifetime' and 'timeouts':
  • Servers behind a NAT use the PCP MAP opcode to start listening for incoming connections from clients outside the NAT. The 'lifetime' within the PCP MAP opcode declares how long the server wants to listen for new connections. This must be refreshed (with another MAP opcode) before the lifetime expires if the server wishes to continue listening.
  • An 'implicit dynamic inbound' mapping is created when clients connect to the server that declared its intent to listen for connections via the PCP MAP request. The 'idle-timeout' time of that mapping is defined by TCP or UDP protocol and the policy of the NAT box. If neither client nor server transmits packets within this 'idle-timeout' time then the 'implicit dynamic inbound' mapping will be automatically destroyed.
  • Any 'implicit dynamic inbound' mappings created by an 'explicit inbound mapping' created by PCP MAP that are still active when the 'explicit inbound mapping' is destroyed SHALL NOT be destroyed as a side-effect of destroying the PCP mapping. The 'implicit dynamic inbound' mappings shall be destroyed when the peers either close the connection or when the idle-timeout expires.
Is this 'simpler description' consistent with the behavior of PCP lifetimes as intended by Section 15 of RFC 6887?

-Ben McCann




--------------080904030900040906010504-- From tireddy@cisco.com Mon May 20 22:46:13 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F9821F8FEB for ; Mon, 20 May 2013 22:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HowbwrJuznXR for ; Mon, 20 May 2013 22:46:08 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id BE11E21F8FB3 for ; Mon, 20 May 2013 22:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4252; q=dns/txt; s=iport; t=1369115168; x=1370324768; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iVjWDUhHuHZ0a5f7RKN+pqSgZLzPv75iGfhlQMspTO0=; b=FLQotEQ6YQllTAZlugFvDjRY6zHgXElYReyj9X9lOTaowmROR4dHK7E+ Nhb94nAMytKyGSBfvSh1OzkjXANNm9NUPShMWW6Rj7fJoKUN0XgpusCLp QYYJGJg/Xs964EV+Xt4l/YkbcMIJnlJMYYRnoFjBNPS0koCL3RvMQLUN9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4FAK0Jm1GtJXG9/2dsb2JhbABZgwgwwVCBCRZ0gh8BAQEDATo/DAQCAQgRBAEBAQoUEDIdCAIEAQ0FCId/Bgy7bo5wMQcGgm1hA5NnhHqQF4MPgiY X-IronPort-AV: E=Sophos;i="4.87,712,1363132800"; d="scan'208";a="212937401" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 21 May 2013 05:45:56 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4L5juCN018286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 05:45:56 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Tue, 21 May 2013 00:45:55 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Reinaldo Penno (repenno)" , Iljitsch van Beijnum Thread-Topic: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s using PCP Thread-Index: AQHOU+x1bXMBRF62MEG/jn6xPv84lpkPI8XA Date: Tue, 21 May 2013 05:45:55 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B70292@xmb-rcd-x10.cisco.com> References: <751A0C06-CDD7-4FCD-84D0-C0E5BFFE12A7@muada.com> <45A697A8FFD7CF48BCF2BE7E106F06040908782B@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040908782B@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.71.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" , "draft-ietf-pcp-nat64-prefix64@tools.ietf.org" Subject: Re: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s using PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 05:46:13 -0000 > -----Original Message----- > From: Reinaldo Penno (repenno) > Sent: Saturday, May 18, 2013 12:54 AM > To: Iljitsch van Beijnum > Cc: pcp@ietf.org; draft-ietf-pcp-nat64-prefix64@tools.ietf.org > Subject: Re: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s u= sing > PCP >=20 > Thanks for the review Iljitsch. >=20 > I think you have a good point on the separation of what can be done with > the discovery of Pref64 alone versus coupled with other mechanisms. The > bitorrent use-case is certainly a good representation of that. >=20 > Load-blancing is also something was discussed but never got into the > draft. There were other initiatives around that, specially in BEHAVE WG > and med was involved in that. This might be something that could be > incorporated into the draft. Load balancing can be solved using PCP authentication, each user-group coul= d be assigned a different Pref64. --Tiru. >=20 > Regards, >=20 > Reinaldo >=20 > On 5/17/13 9:57 AM, "Iljitsch van Beijnum" wrote: >=20 > >On 16 mei 2013, at 13:19, Reinaldo Penno (repenno) > >wrote: > > > >>> Title : Learn NAT64 PREFIX64s using PCP > >>> URL : http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-00 > >>> Authors: M. Boucadair > > > >Ok, here is a brief review. Brief in the sense that I didn't > >re-familiarize myself with the related RFCs. > > > >This is clearly useful. > > > >I found 3.2, and especially 3.2.2 very sparse, I was looking to learn > >more about how this mechanism is useful in practice here. Some more > >applications/protocols could be listed. However, a lot of information is > >provided in 3.3. Unfortunately, there are two issues with this: > > > >1. SIP is a very complex protocol that not everyone may be familiar with > > > >2. Unless I misunderstood, a lot of what happens here is pure NAT64, and > >unrelated to the knowledge of the Pref64: > > > >"the PCP Client issues a PCP MAP request with > > PORT_RESERVATION_OPTION to reserve a pair of ports preserving parity > > and contiguity [I-D.boucadair-pcp-rtp-rtcp]. A pair of ports and an > > external IPv4 address are then returned by the PCP server to the > > requesting PCP Client." > > > >It would be more useful to concentrate on the functionality that is only > >possible when the Pref64 is known at this point. For instance, in the > >case of BitTorrent, IPv4 addresses of prospective peers may be learned > >from a tracker. In order for the client to connect to those peers, it > >needs to synthesize IPv6 representations for those IPv4 addresses by > >combining them with the Pref64. > > > >It would be useful to spell out that the ability to reserve ports and > >learn the external IPv4 address used by the NAT64 (or any NAT) allows fo= r > >receiving incoming sessions. For this, the Pref64 is not needed. The > >Pref64, on the other hand, allows for setting up outgoing connections to > >systems for which only a literal IPv4 address (and not a fully qualified > >domain name) is known. But for this, no other PCP functionality is > >required. (Although in practice it gets more complex when ports are used > >in both directions simultaneously.) > > > >The abstract starts with "This document defines a new PCP extension to > >learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device" but the > >PREFIX64 option only allows for one Pref64 and the option may only appea= r > >once, so the (es) part shouldn't be there. (Would the ability to learn > >multiple Pref64s be useful?? I guess load balancing across NAT64s with > >each a Pref64 of their own is possible.) > > > >In 4.1 a reference to section 7.3 of RFC 6887 would be useful. > > > >Although I was unhappy with the SIP example earlier, I think it's > >appropriate in section 5 as it shows the full complexity of a real-world > >system now that we've learned all the details of the mechanism. I think > >the section title should have "SIP" in it, though. > > > >In the security considerations, I would expect a discussion about what > >happens when a malicious third party impersonates a PCP server and > >provides a fake Pref64. > > > >Iljitsch >=20 From internet-drafts@ietf.org Mon May 20 22:47:42 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6540B21F971A; Mon, 20 May 2013 22:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsr6yWwmooBC; Mon, 20 May 2013 22:47:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B0421F8FB3; Mon, 20 May 2013 22:47:42 -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.50 Message-ID: <20130521054741.32449.41106.idtracker@ietfa.amsl.com> Date: Mon, 20 May 2013 22:47:41 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-description-option-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 05:47:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Port Control Protocol Working Group of th= e IETF. Title : PCP Description Option Author(s) : Mohamed Boucadair Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-description-option-01.txt Pages : 6 Date : 2013-05-20 Abstract: This document extends Port Control Protocol (PCP) with the ability to associate a description with a PCP-instantiated mapping. It does so by defining a new DESCRIPTION option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-description-option There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-description-option-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-description-option-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From repenno@cisco.com Mon May 20 22:55:49 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9347221F9700 for ; Mon, 20 May 2013 22:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RODfCoGvq-Ga for ; Mon, 20 May 2013 22:55:44 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 921B021F9674 for ; Mon, 20 May 2013 22:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4844; q=dns/txt; s=iport; t=1369115744; x=1370325344; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=lRJi0fqFF4s06Cp/m4XLxOmwoUldFFhAakAT9YCkevY=; b=Z86GFt2g+39OdaXAx4+WPAkL5f8fiefiVSGDP0sWnmbqqFJW+5UIV++V BCvupocB2LKMyP0IxsVXMp/sp4ESGfJ0LkzMBxSXK6kXkXu19OapPEXli f46PbIGT1ja0N0eYTfZBuatdz30222b8fpbIoTfJv4Qx1gD2ju+blNzO1 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4FAJILm1GtJV2b/2dsb2JhbABZgwgwwU+BCRZ0gh8BAQECAjo/DAYBCBEEAQEBChRCHQgCBAENBQgBiAQMu26OcA8iBwaCbWEDk2eEepAXgw+CJg X-IronPort-AV: E=Sophos;i="4.87,712,1363132800"; d="scan'208";a="212918903" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 21 May 2013 05:55:44 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4L5th17014111 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 05:55:43 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Tue, 21 May 2013 00:55:43 -0500 From: "Reinaldo Penno (repenno)" To: "Tirumaleswar Reddy (tireddy)" , Iljitsch van Beijnum Thread-Topic: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s using PCP Thread-Index: AQHOVefU0s9emtzEm0KQ94wZjYPXpg== Date: Tue, 21 May 2013 05:55:43 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F060409088873@xmb-rcd-x04.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A14B70292@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.253.3] Content-Type: text/plain; charset="us-ascii" Content-ID: <0B9022B87C075A4BA9273EB2EFB3A4C8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" , "draft-ietf-pcp-nat64-prefix64@tools.ietf.org" Subject: Re: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s using PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 05:55:49 -0000 I believe the idea is to do it dynamically since depends on load, it can not be pre-configured. There was a lot of good discussion on this topic a while back on BEHAVE. This draft captured some of that: http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-03 This presentation is very interesting http://www.ietf.org/proceedings/79/slides/behave-1.pdf On 5/21/13 2:45 AM, "Tirumaleswar Reddy (tireddy)" wrote: >> -----Original Message----- >> From: Reinaldo Penno (repenno) >> Sent: Saturday, May 18, 2013 12:54 AM >> To: Iljitsch van Beijnum >> Cc: pcp@ietf.org; draft-ietf-pcp-nat64-prefix64@tools.ietf.org >> Subject: Re: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s >>using >> PCP >>=20 >> Thanks for the review Iljitsch. >>=20 >> I think you have a good point on the separation of what can be done with >> the discovery of Pref64 alone versus coupled with other mechanisms. The >> bitorrent use-case is certainly a good representation of that. >>=20 >> Load-blancing is also something was discussed but never got into the >> draft. There were other initiatives around that, specially in BEHAVE WG >> and med was involved in that. This might be something that could be >> incorporated into the draft. > >Load balancing can be solved using PCP authentication, each user-group >could be assigned a different Pref64. > >--Tiru. > >>=20 >> Regards, >>=20 >> Reinaldo >>=20 >> On 5/17/13 9:57 AM, "Iljitsch van Beijnum" wrote: >>=20 >> >On 16 mei 2013, at 13:19, Reinaldo Penno (repenno) >> >wrote: >> > >> >>> Title : Learn NAT64 PREFIX64s using PCP >> >>> URL : http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-00 >> >>> Authors: M. Boucadair >> > >> >Ok, here is a brief review. Brief in the sense that I didn't >> >re-familiarize myself with the related RFCs. >> > >> >This is clearly useful. >> > >> >I found 3.2, and especially 3.2.2 very sparse, I was looking to learn >> >more about how this mechanism is useful in practice here. Some more >> >applications/protocols could be listed. However, a lot of information >>is >> >provided in 3.3. Unfortunately, there are two issues with this: >> > >> >1. SIP is a very complex protocol that not everyone may be familiar >>with >> > >> >2. Unless I misunderstood, a lot of what happens here is pure NAT64, >>and >> >unrelated to the knowledge of the Pref64: >> > >> >"the PCP Client issues a PCP MAP request with >> > PORT_RESERVATION_OPTION to reserve a pair of ports preserving parity >> > and contiguity [I-D.boucadair-pcp-rtp-rtcp]. A pair of ports and an >> > external IPv4 address are then returned by the PCP server to the >> > requesting PCP Client." >> > >> >It would be more useful to concentrate on the functionality that is >>only >> >possible when the Pref64 is known at this point. For instance, in the >> >case of BitTorrent, IPv4 addresses of prospective peers may be learned >> >from a tracker. In order for the client to connect to those peers, it >> >needs to synthesize IPv6 representations for those IPv4 addresses by >> >combining them with the Pref64. >> > >> >It would be useful to spell out that the ability to reserve ports and >> >learn the external IPv4 address used by the NAT64 (or any NAT) allows >>for >> >receiving incoming sessions. For this, the Pref64 is not needed. The >> >Pref64, on the other hand, allows for setting up outgoing connections >>to >> >systems for which only a literal IPv4 address (and not a fully >>qualified >> >domain name) is known. But for this, no other PCP functionality is >> >required. (Although in practice it gets more complex when ports are >>used >> >in both directions simultaneously.) >> > >> >The abstract starts with "This document defines a new PCP extension to >> >learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device" but >>the >> >PREFIX64 option only allows for one Pref64 and the option may only >>appear >> >once, so the (es) part shouldn't be there. (Would the ability to learn >> >multiple Pref64s be useful?? I guess load balancing across NAT64s with >> >each a Pref64 of their own is possible.) >> > >> >In 4.1 a reference to section 7.3 of RFC 6887 would be useful. >> > >> >Although I was unhappy with the SIP example earlier, I think it's >> >appropriate in section 5 as it shows the full complexity of a >>real-world >> >system now that we've learned all the details of the mechanism. I think >> >the section title should have "SIP" in it, though. >> > >> >In the security considerations, I would expect a discussion about what >> >happens when a malicious third party impersonates a PCP server and >> >provides a fake Pref64. >> > >> >Iljitsch >>=20 > From mohamed.boucadair@orange.com Mon May 20 23:08:19 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FBD21F9691 for ; Mon, 20 May 2013 23:08:19 -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=[AWL=0.000, 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 JPT+cYU4R60R for ; Mon, 20 May 2013 23:08:15 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id CFBE221F9509 for ; Mon, 20 May 2013 23:08:14 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id D06963240F2; Tue, 21 May 2013 08:08:11 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 5559D27C084; Tue, 21 May 2013 08:08:11 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Tue, 21 May 2013 08:08:11 +0200 From: To: Simon Perreault , "pcp@ietf.org" Date: Tue, 21 May 2013 08:08:10 +0200 Thread-Topic: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s using PCP Thread-Index: Ac5Vaa/kCiPOOSP6QSKqQAhepWZ/pQAf8x+g Message-ID: <94C682931C08B048B7A8645303FDC9F36ECFB4A3A1@PUEXCB1B.nanterre.francetelecom.fr> References: <45A697A8FFD7CF48BCF2BE7E106F0604090861C4@xmb-rcd-x04.cisco.com> <519A38B7.6080005@viagenie.ca> In-Reply-To: <519A38B7.6080005@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.41233 Subject: Re: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s using PCP X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 06:08:19 -0000 Hi Simon, Agree. Fixed in my local copy. Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Si= mon >Perreault >Envoy=E9=A0: lundi 20 mai 2013 16:53 >=C0=A0: pcp@ietf.org >Objet=A0: Re: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s >using PCP > >Le 2013-05-16 13:19, Reinaldo Penno (repenno) a =E9crit : >>> Title : Learn NAT64 PREFIX64s using PCP >>> URL : http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-00 >>> Authors: M. Boucadair > >And here's my review... > >The draft is almost ready. One remaining issue that should be easy to >fix: the reference to draft-boucadair-pcp-rtp-rtcp should be replaced by >one to draft-ietf-pcp-port-set, and the example in section 3.3 adjusted. > >Simon >-- >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From yoshihiro.ohba@toshiba.co.jp Tue May 21 00:14:46 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EE621F8FFA for ; Tue, 21 May 2013 00:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.088 X-Spam-Level: X-Spam-Status: No, score=-8.088 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6LRWutfXBeB for ; Tue, 21 May 2013 00:14:38 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6FF21F92BB for ; Tue, 21 May 2013 00:14:34 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id r4L7ELJ6027183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 May 2013 16:14:21 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r4L7EKx1028672; Tue, 21 May 2013 16:14:20 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 105; Tue, 21 May 2013 16:14:20 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r4L7EKH4028668; Tue, 21 May 2013 16:14:20 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id r4L7EKaa009250; Tue, 21 May 2013 16:14:20 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id SAA09243; Tue, 21 May 2013 16:14:20 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id r4L7EKiv011747; Tue, 21 May 2013 16:14:20 +0900 (JST) Received: from tgxml329.toshiba.local by toshiba.co.jp id r4L7EJji006126; Tue, 21 May 2013 16:14:19 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.217]) by tgxml329.toshiba.local ([133.199.60.16]) with mapi id 14.03.0123.003; Tue, 21 May 2013 16:14:19 +0900 From: To: , , Thread-Topic: [pcp] pcp auth requirements Thread-Index: AQHORXOMRcSeZEmOnUO6Nprz3E76X5kKtxIAgASSsTA= Date: Tue, 21 May 2013 07:14:18 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B12D0CD38@tgxml338.toshiba.local> References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.145.121] msscp.transfermailtomossagent: 103 Content-Type: multipart/alternative; boundary="_000_674F70E5F2BE564CB06B6901FD3DD78B12D0CD38tgxml338toshiba_" MIME-Version: 1.0 Subject: Re: [pcp] pcp auth requirements 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, 21 May 2013 07:14:46 -0000 --_000_674F70E5F2BE564CB06B6901FD3DD78B12D0CD38tgxml338toshiba_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Tiru, In my analysis, Req-4-d-1 is basically introducing a three-state SA model f= or PCP: State 0: unavailable (or non-existent), State 1: partially availab= le only for triggering re-auth, and State 2: fully available. MSCHAPv2 pass= word change function is designed based on this model. I am not going to get into details about the three-state SA model, but even= the three-state SA model will require re-auth trigger to be integrity prot= ected. Having said that, I think the following requirement is sufficient for Req-4= -d: =1B$B!H=1B(BThe server MUST be able to send an integrity protected re-a= uthentication trigger to the client.=1B$B!I=1B(B Regards, Yoshihiro Ohba From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Tirum= aleswar Reddy (tireddy) Sent: Sunday, May 19, 2013 2:24 AM To: Alper Yegin; pcp@ietf.org Subject: Re: [pcp] pcp auth requirements Hi Alper, Please see inline [TR] From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Tuesday, April 30, 2013 12:53 PM To: pcp@ietf.org Subject: [pcp] pcp auth requirements c. If a server wants to send an unsolicited message, but the previous security association has expired 1. The server can continue to use the same SA to protect messages pertaining to that mapping, even if the SA is technically expired. "Expired" means "do not use (even if its still hanging around)". We not only do not need to use expired SAs, but also using something expire= d in any sense is plain wrong -- unless someone wants to redefine what "exp= ired" means. [TR] For example if we consider MSCHAPv2, there is configuration option where se= rver accepts the challenge-response from the client even if the password is= expired and allows it be changed. Please clarify if you have some attack in mind that would cause problems us= ing expired SA. [/TR] - Such server notifications will not change state in the PCP client. - The notification could be a trigger for the client to re-authenticate. Here the document is getting into some solution description. And as for such a solution: Instead of sending a notification that is protected with an expired SA to m= ean "re-authenticate", why not send an explicit message that says "re-authe= nticate"? [TR] The client has trusted the PCP server sometime back using mutual authentica= tion, so it can assume the integrity protected PCP response using expired S= A is coming from the same PCP server and not from some attacker posing as P= CP server. [/TR] What is gained by appearing to use an expired SA (but in fact not really us= ing it! because the payload of the notification is not consumed by the rece= iver). For example, if the server indicates that external IP address/port has changed, the PCP client can then re-authenticate with the server to confirm if the external IP address/port for the mapping has indeed changed. 2. The server can optionally trigger re-authentication with the client. Yes, that's the solution. If the server has something to send to the client= , and there's no live SA, then the server first needs to trigger re-auth, s= etup a fresh SA, then send whatever it wants to send to the client. [TR] We have updated this requirement in the new draft, please have a look. Best Regards, --Tiru. [/TR] Alper --_000_674F70E5F2BE564CB06B6901FD3DD78B12D0CD38tgxml338toshiba_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Tiru,

 <= /o:p>

In my analys= is, Req-4-d-1 is basically introducing a three-state SA model for PCP: Stat= e 0:  unavailable (or non-existent), State 1: partially available only for triggering re-auth, and State 2: fully available. MSCHAPv2 passwo= rd change function is designed based on this model.

 <= /o:p>

I am not goi= ng to get into details about the three-state SA model, but even the three-s= tate SA model will require re-auth trigger to be integrity protected.  

 <= /o:p>

Having said = that, I think the following requirement is sufficient for Req-4-d: =1B$B!H=1B(BThe server MUST be able to send an integrity protected re-authentication trigg= er to the client.=1B$B!I=1B(B

 <= /o:p>

Regards,

Yoshihiro Oh= ba

 <= /o:p>

 

From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy (tire= ddy)
Sent: Sunday, May 19, 2013 2:24 AM
To: Alper Yegin; pcp@ietf.org
Subject: Re: [pcp] pcp auth requirements

 

Hi Alper,

 

Please see inline [TR]

 

 



 
     =
 c.  If a server wants to send an unsolicited message, but the
&nbs=
p;         previous security associ=
ation has expired
 
&nbs=
p;         1.  The server can =
continue to use the same SA to protect
&nbs=
p;             =
messages pertaining to that mapping, even if the SA is

&nbs=
p;             =
technically expired.





"Expired" means &quo=
t;do not use (even if its still hanging around)". 


We not only do not need to use=
 expired SAs, but also using something expired in any sense is plain wrong =
-- unless someone wants to redefine what "expired" means.


 


[TR]=



For =
example if we consider MSCHAPv2, there is configuration option where server=
 accepts the challenge-response from the client even if the password is exp=
ired and allows it be changed. 


 


Plea=
se clarify if you have some attack in mind that would cause problems using =
expired SA.


 


[/TR=
]


 


     =
         -  Such server notifi=
cations will not change state in the


&nbs=
p;            &=
nbsp;   PCP client.


 


&nbs=
p;             =
-  The notification could be a trigger for the client to


&nbs=
p;            &=
nbsp;   re-authenticate.  





Here the document is getting i=
nto some solution description.





And as for such a solution:





Instead of sending a notificat=
ion that is protected with an expired SA to mean "re-authenticate"=
;, why not send an explicit message that says "re-authenticate"?<=
o:p>


 


[TR]=
 


The =
client has trusted the PCP server sometime back using mutual authentication=
, so it can assume the integrity protected PCP response using expired SA is=
 coming from the same PCP server and not from some attacker posing as PCP s=
erver.


[/TR=
]


 


What is gained by appearing to=
 use an expired SA (but in fact not really using it! because the payload of=
 the notification is not consumed by the receiver).







     =
            For exam=
ple, if the server indicates


&nbs=
p;            &=
nbsp;   that external IP address/port has changed, the PCP


&nbs=
p;            &=
nbsp;   client can then re-authenticate with the server to


&nbs=
p;            &=
nbsp;   confirm if the external IP address/port for the mapping


&nbs=
p;            &=
nbsp;   has indeed changed.


 


&nbs=
p;         2.  The server can =
optionally trigger re-authentication with


&nbs=
p;             =
the client.




 






 






Yes, that's the solution. If the server has someth=
ing to send to the client, and there's no live SA, then the server first ne=
eds to trigger re-auth, setup a fresh
 SA, then send whatever it wants to send to the client.

 


[TR]=



 


We h=
ave updated this requirement in the new draft, please have a look.


 


Best=
 Regards,


--Ti=
ru.


 


[/TR=
]


 






 






Alper






 






 






 






 
--_000_674F70E5F2BE564CB06B6901FD3DD78B12D0CD38tgxml338toshiba_-- From bingxuere@gmail.com Tue May 21 01:55:05 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB3821F965C for ; Tue, 21 May 2013 01:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=1.633, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 essKR55CKoDf for ; Tue, 21 May 2013 01:55:00 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id 1069221F9670 for ; Tue, 21 May 2013 01:54:59 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id lf11so224028vcb.40 for ; Tue, 21 May 2013 01:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wrRtePgmuTHLXnEM4ca5QrMtuey5WJ8bAIkLfaKwH/A=; b=kUXq7U0Es8hQoh0GboTq5x/z5sQBHq0gV5/NdKBHwX9xtqKvm5MPdCNsoFf7XKpraQ 8cvbg4fPRwqLcI+GLIeQrfphgxnubU5Yx51OwLtU0u9nXdn5rAl4Q5TxBz7loJoipE0a SnEvNa0GdOcSqdkUtU9u1Bo/V53MGiC2qTOc+s7beWnyo/oe3jNRrJKC8kUYq2Wz7hDM yYmKcycZrGzwBixjAxy3JZcCBYeRPuWDeWgiyegXCqCtGcR96I4p8vflhsRvOzHwijrG SSax9NwE5Qff1gH6heCk60paP6i/PrCjb6hhdGnNEZT3MdlaPS1/WlTFhAl+/+m7ZL9B S7LQ== X-Received: by 10.52.101.163 with SMTP id fh3mr420606vdb.107.1369126499543; Tue, 21 May 2013 01:54:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.224.133 with HTTP; Tue, 21 May 2013 01:54:19 -0700 (PDT) In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040907F7AA@xmb-rcd-x04.cisco.com> References: <45A697A8FFD7CF48BCF2BE7E106F06041E9D48@xmb-rcd-x04.cisco.com> <45A697A8FFD7CF48BCF2BE7E106F06040907F7AA@xmb-rcd-x04.cisco.com> From: Qiong Date: Tue, 21 May 2013 16:54:19 +0800 Message-ID: To: "Reinaldo Penno (repenno)" Content-Type: multipart/alternative; boundary=bcaec548a14fa873fe04dd369abc Cc: "pcp@ietf.org" Subject: Re: [pcp] WG Call for Adoption: The Port Control Protocol in Dual-Stack Lite environments 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, 21 May 2013 08:55:05 -0000 --bcaec548a14fa873fe04dd369abc Content-Type: text/plain; charset=UTF-8 Hi all, I support the adoption. This draft is good start, just have one comment: I think the encapsulation mode is also very important when AFTR is deployed using anycast address and PCP server is co-located in AFTR. In encapsulation mode, it would be easy to guarantee that the same AFTR will be picked for both PCP traffic and subsequent data traffic. So I prefer to move encapsulation mode in the main body. Best wishes Qiong On Fri, May 10, 2013 at 7:03 PM, Reinaldo Penno (repenno) wrote: > Hello, > > This email starts a 2-week consensus call on adopting > > Title : The Port Control Protocol in Dual-Stack Lite environments > Author(s) : F. Dupont t al. > URL : http://tools.ietf.org/html/draft-dupont-pcp-dslite-05 > > Please read the current revision and state you opinion either for or > against adoption (and with reasoning why) in the mailing list. > > The call for adoption ends 24th May 2013. > > Thanks, > > Reinaldo > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --bcaec548a14fa873fe04dd369abc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I support the adoption.= =C2=A0

This draft is good start, just = have one comment:
I think the encapsulation mode is also ve= ry important when AFTR is deployed using anycast address and PCP server is = co-located in AFTR. In encapsulation mode, it would be easy to guarantee th= at the same AFTR will be picked for both PCP traffic and subsequent data tr= affic. So I prefer to move encapsulation mode in the main body.

Best wishes
Qiong




On Fri, May 10, 2013 at 7:03 PM, Reina= ldo Penno (repenno) <repenno@cisco.com> wrote:
Hello,

This email starts a 2-week consensus call on adopting

=C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 : The Port Control Protocol in Dual= -Stack Lite environments
=C2=A0 =C2=A0 =C2=A0Author(s) : F. Dupont t al.
=C2=A0 =C2=A0 =C2=A0URL =C2=A0 =C2=A0 =C2=A0 : http://tools.ietf.o= rg/html/draft-dupont-pcp-dslite-05

Please read the current revision and state you opinion either for or
against adoption (and with reasoning why) in the mailing list.

The call for adoption ends 24th May 2013.

Thanks,

Reinaldo


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



--
=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China T= elecom Beijing Research Institude


Open source code:
lightweig= ht 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--bcaec548a14fa873fe04dd369abc-- From repenno@cisco.com Tue May 21 01:59:18 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3092121F97BF for ; Tue, 21 May 2013 01:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoduyHsK8B9M for ; Tue, 21 May 2013 01:59:13 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAB721F97C7 for ; Tue, 21 May 2013 01:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7439; q=dns/txt; s=iport; t=1369126753; x=1370336353; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=wHWXBJH4d6Li2dFauUgeL6IqJxJdcRtO7lL+ERC0Uyo=; b=Kmc2Q/uKRyYEeERq6h3JMiOwOGosSn/4hcF6IQHHZapAHpNtQE3AZBnz eIxoCCSwuKFfpCiEVqntaWqw/ajxkdpWl37PQ5TpsijgLElCHSMmiKKI+ 5moGwPwyTDRYknbq0qCpByd19dDeRzvFojKryPfTW8ewpIDQwp6Iz8aYz A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAGADs2m1GtJXG+/2dsb2JhbABZgkREMK9liTOGX4FbgQsWdIIfAQEBBAEBARpRCxIBGAEDAQILGQQoBgsUCQgCBA4FCIdzAw8Msn8NiFmMSoEVgREgDQQHgnNhA5VSgw+KdIUjgViBN4FxNQ X-IronPort-AV: E=Sophos;i="4.87,713,1363132800"; d="scan'208,217";a="212810689" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 21 May 2013 08:59:12 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4L8x7gD006965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 08:59:07 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 21 May 2013 03:59:07 -0500 From: "Reinaldo Penno (repenno)" To: Qiong Thread-Topic: Lw4o6 or DS-Lite? (Re: [pcp] WG Call for Adoption: The Port Control Protocol in Dual-Stack Lite environments) Thread-Index: AQHOVgFyeemzj62t2Uy2ljm7z0uTwQ== Date: Tue, 21 May 2013 08:59:06 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F060409088AD5@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.242.165] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F060409088AD5xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: [pcp] Lw4o6 or DS-Lite? (Re: WG Call for Adoption: The Port Control Protocol in Dual-Stack Lite environments) 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, 21 May 2013 08:59:18 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F060409088AD5xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For those supporting this draft, are you thinking (or supporting) DS-Lite o= r actually Lw4o6? I would like to make that distinction. Because if you want this draft to work LW4o6 we need to understand changes = and implications if any. I know, for example, the PORT SEt draft was origin= ally targeted at Lw4o6, not DS-Lite. From: Qiong > Date: Tue, 21 May 2013 16:54:19 +0800 To: Reinaldo Penno > Cc: "pcp@ietf.org" > Subject: Re: [pcp] WG Call for Adoption: The Port Control Protocol in Dual-= Stack Lite environments Hi all, I support the adoption. This draft is good start, just have one comment: I think the encapsulation mode is also very important when AFTR is deployed= using anycast address and PCP server is co-located in AFTR. In encapsulati= on mode, it would be easy to guarantee that the same AFTR will be picked fo= r both PCP traffic and subsequent data traffic. So I prefer to move encapsu= lation mode in the main body. Best wishes Qiong On Fri, May 10, 2013 at 7:03 PM, Reinaldo Penno (repenno) > wrote: Hello, This email starts a 2-week consensus call on adopting Title : The Port Control Protocol in Dual-Stack Lite environments Author(s) : F. Dupont t al. URL : http://tools.ietf.org/html/draft-dupont-pcp-dslite-05 Please read the current revision and state you opinion either for or against adoption (and with reasoning why) in the mailing list. The call for adoption ends 24th May 2013. Thanks, Reinaldo _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp -- =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: http://sourceforge.net/projects/laft6/ PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_45A697A8FFD7CF48BCF2BE7E106F060409088AD5xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <5AA23E3A6AC9814E89AF7E963C1CC3DC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
For those supporting this draft, are you thinking (or supporting) DS-L= ite or actually Lw4o6?  I would like to make that distinction. 

Because if you want this draft to work LW4o6 we need to understand cha= nges and implications if any. I know, for example, the PORT SEt draft was o= riginally targeted at Lw4o6, not DS-Lite.



From: Qiong <bingxuere@gmail.com>
Date: Tue, 21 May 2013 16:54:19 = 3;0800
To: Reinaldo Penno <repenno@cisco.com>
Cc: "pcp@ietf.org" <pcp@ietf.= org>
Subject: Re: [pcp] WG Call for Adop= tion: The Port Control Protocol in Dual-Stack Lite environments

Hi all,

I support the adoption. 

This draft is good start, just have one comment:
I think the encapsulation mode is also very important when = AFTR is deployed using anycast address and PCP server is co-located in AFTR= . In encapsulation mode, it would be easy to guarantee that the same AFTR w= ill be picked for both PCP traffic and subsequent data traffic. So I prefer to move encapsulation mode in the= main body.

Best wishes
Qiong




On Fri, May 10, 2013 at 7:03 PM, Reinaldo Penno = (repenno) <repenno@cisco.com> wrote:
Hello,

This email starts a 2-week consensus call on adopting

     Title     : The Port Control Protocol in Dual= -Stack Lite environments
     Author(s) : F. Dupont t al.
     URL       : http://tools.ietf.org/html/draft-dupont-pcp-dslite-05

Please read the current revision and state you opinion either for or
against adoption (and with reasoning why) in the mailing list.

The call for adoption ends 24th May 2013.

Thanks,

Reinaldo


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



--
=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China Telecom Beijing Research Institude


Open source code:
lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 --_000_45A697A8FFD7CF48BCF2BE7E106F060409088AD5xmbrcdx04ciscoc_-- From bingxuere@gmail.com Tue May 21 05:49:58 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081D521F961C for ; Tue, 21 May 2013 05:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 sHCRCKpD79yp for ; Tue, 21 May 2013 05:49:57 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 50D5921F88AC for ; Tue, 21 May 2013 05:49:56 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro12so576450pbb.27 for ; Tue, 21 May 2013 05:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=fczObQQbd/MajSdFuUPwwX/W5aeS1bIE+EWv5QsUhnk=; b=aA68gL/8Ne/t9F379RFVM1UqCc3Mq8x0j1J4AYGMDCgzukYc4H9R+y2DOBJY7f1OL4 ioHE97e5EMbzBbY+47uoinXfWP4Tl1TMZ4mtk4lfTGvPPOp89j0OYiBa6CQ2HI5X7yZy nd3XvVOjw4SRpH1weyEuqgEdS7rmxSw3d3Emru4+AwKHWzhWPj6yAQmLX8985qq1bj7t SXMF/Ad+cF25WQh5fLsrynLwjO0XlSVdC6VMFlpgYZmUUlW/43N0ANhj00Pg7aJS1MrE Kw18MaUHak+HZyt3PiketBHEUW97qbW4k8wsmTT9G9HnDhyE3Q9U13Sp3a4igP42x74T jb5g== X-Received: by 10.66.243.4 with SMTP id wu4mr3076348pac.72.1369140591049; Tue, 21 May 2013 05:49:51 -0700 (PDT) Received: from [192.168.11.9] ([123.120.231.232]) by mx.google.com with ESMTPSA id ze11sm3201754pab.22.2013.05.21.05.49.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 May 2013 05:49:49 -0700 (PDT) References: <45A697A8FFD7CF48BCF2BE7E106F060409088AD5@xmb-rcd-x04.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F060409088AD5@xmb-rcd-x04.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-B26C25A9-B61D-4235-B50B-85006F3488A6 Content-Transfer-Encoding: 7bit Message-Id: <4DC600EC-AB9A-4091-886E-B6F3F3D87157@gmail.com> X-Mailer: iPad Mail (10A8500) From: "bingxuere@gmail.com" Date: Tue, 21 May 2013 20:49:46 +0800 To: "Reinaldo Penno (repenno)" Cc: "pcp@ietf.org" Subject: Re: [pcp] Lw4o6 or DS-Lite? (Re: WG Call for Adoption: The Port Control Protocol in Dual-Stack Lite environments) 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, 21 May 2013 12:49:58 -0000 --Apple-Mail-B26C25A9-B61D-4235-B50B-85006F3488A6 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Reinaldo=A3=AC My intention here is to support DS-Lite as we are also deploying dslite righ= t now and I think this draft is also quite useful. Best wishes Qiong Sent from my iPad On 2013-5-21, at 16:59, "Reinaldo Penno (repenno)" wrote= : > For those supporting this draft, are you thinking (or supporting) DS-Lite o= r actually Lw4o6? I would like to make that distinction.=20 >=20 > Because if you want this draft to work LW4o6 we need to understand changes= and implications if any. I know, for example, the PORT SEt draft was origin= ally targeted at Lw4o6, not DS-Lite. >=20 >=20 >=20 > From: Qiong > Date: Tue, 21 May 2013 16:54:19 +0800 > To: Reinaldo Penno > Cc: "pcp@ietf.org" > Subject: Re: [pcp] WG Call for Adoption: The Port Control Protocol in Dual= -Stack Lite environments >=20 > Hi all, >=20 > I support the adoption.=20 >=20 > This draft is good start, just have one comment: > I think the encapsulation mode is also very important when AFTR is deploye= d using anycast address and PCP server is co-located in AFTR. In encapsulati= on mode, it would be easy to guarantee that the same AFTR will be picked for= both PCP traffic and subsequent data traffic. So I prefer to move encapsula= tion mode in the main body. >=20 > Best wishes > Qiong >=20 >=20 >=20 >=20 > On Fri, May 10, 2013 at 7:03 PM, Reinaldo Penno (repenno) wrote: >> Hello, >>=20 >> This email starts a 2-week consensus call on adopting >>=20 >> Title : The Port Control Protocol in Dual-Stack Lite environment= s >> Author(s) : F. Dupont t al. >> URL : http://tools.ietf.org/html/draft-dupont-pcp-dslite-05 >>=20 >> Please read the current revision and state you opinion either for or >> against adoption (and with reasoning why) in the mailing list. >>=20 >> The call for adoption ends 24th May 2013. >>=20 >> Thanks, >>=20 >> Reinaldo >>=20 >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >=20 >=20 >=20 > --=20 > =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Qiong Sun > China Telecom Beijing Research Institude >=20 >=20 > Open source code: > lightweight 4over6: http://sourceforge.net/projects/laft6/ > PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/=20 > =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 --Apple-Mail-B26C25A9-B61D-4235-B50B-85006F3488A6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear Reinaldo=EF=BC=8C

<= /div>
My intention here is to support DS-Lite as we are also deploying d= slite right now and I think this draft is also quite useful.

<= /div>
Best wishes
Qiong

Sent from my iPad
On 2013-5-21, at 16:59, "Reinaldo Penno (repenno)" <repenno@cisco.com> wrote:

=
For those supporting this draft, are you thinking (or supporting) DS-Li= te or actually Lw4o6?  I would like to make that distinction. 

Because if you want this draft to work LW4o6 we need to understand chan= ges and implications if any. I know, for example, the PORT SEt draft was ori= ginally targeted at Lw4o6, not DS-Lite.



From: Qiong <bingxuere@gmail.com>
Date: Tue, 21 May 2013 16:54:19 +080= 0
To: Reinaldo Penno <repenno@cisco.com>
Cc: "pcp@ietf.org" <pcp@ietf.org><= br> Subject: Re: [pcp] WG Call for Adopt= ion: The Port Control Protocol in Dual-Stack Lite environments

Hi all,

I support the adoption. 

This draft is good start, just have one comment:
I think the encapsulation mode is also very important when A= FTR is deployed using anycast address and PCP server is co-located in AFTR. I= n encapsulation mode, it would be easy to guarantee that the same AFTR will b= e picked for both PCP traffic and subsequent data traffic. So I prefer to move encapsulation mode in the m= ain body.

Best wishes
Qiong




On Fri, May 10, 2013 at 7:03 PM, Reinaldo Penno (= repenno) <repenno@cisco.com> wrote:
Hello,

This email starts a 2-week consensus call on adopting

     Title     : The Port Control Protocol in Dual-= Stack Lite environments
     Author(s) : F. Dupont t al.
     URL       : http://tools.ietf.org/html/draft-dupont-pcp-dslite-05

Please read the current revision and state you opinion either for or
against adoption (and with reasoning why) in the mailing list.

The call for adoption ends 24th May 2013.

Thanks,

Reinaldo


_______________________________________________
pcp mailing list
pcp@ietf.org
http= s://www.ietf.org/mailman/listinfo/pcp



--
=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China Telecom Beijing Research Institude


Open source code:
lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= --Apple-Mail-B26C25A9-B61D-4235-B50B-85006F3488A6-- From tireddy@cisco.com Tue May 21 07:59:01 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE9A21F9853 for ; Tue, 21 May 2013 07:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kdh2K3VS17+1 for ; Tue, 21 May 2013 07:58:56 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 38DBE21F97E6 for ; Tue, 21 May 2013 07:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39576; q=dns/txt; s=iport; t=1369148333; x=1370357933; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GnQayHr4YDdYUATFx/DM0rzR1xrRIpca3qKOFjJyhfE=; b=bVjWO8NJEXNgkGAQqU6SQB6i3BznqU/HTVSLePAqPO9cTeRBBK+ZDOlw mxXYzLYqrRiXsXyYySore99f2aDQCVVFETY+D/xZS7EeGjyFkdoKBWPw/ CkVonH/1733Z7vZ/WlRh+TU5YYEhPyUQtyS6iRVqhdK17Q2SXBoyFIYSP E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0FAOmKm1GtJXG+/2dsb2JhbABWA4JERDDBT4EJFnSCIwEBAQQtPw0QAgEIEQQBAQsMAQEIAQYHMhQJCAIEDgUIE4dyu1aOaTEGAQYLAQEEAYJbYQOoeIMPgWgCAwQXHg X-IronPort-AV: E=Sophos;i="4.87,714,1363132800"; d="scan'208,217";a="213234204" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 21 May 2013 14:58:52 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4LEwplx027693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 14:58:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 21 May 2013 09:58:51 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Alper Yegin Thread-Topic: [pcp] pcp auth requirements Thread-Index: AQHORaVDKQ3d6G8P5kumseyWFL/c3ZkK012AgANTZYCAASdkoA== Date: Tue, 21 May 2013 14:58:50 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B706A6@xmb-rcd-x10.cisco.com> References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> <8AF116E2-B8E5-4228-8437-B8B4867CA6E2@yegin.org> In-Reply-To: <8AF116E2-B8E5-4228-8437-B8B4867CA6E2@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.73.30] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A14B706A6xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] pcp auth requirements 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, 21 May 2013 14:59:02 -0000 --_000_913383AAA69FF945B8F946018B75898A14B706A6xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alper> I see "The server MUST be able to optionally trigger re-authenticati= on with the client." Alper> Then using expired SA could be to about "using the expired SA to pro= tect the trigger message". The suggestion from Alper is to use expired SA only to trigger re-authentic= ation and this unsolicited message should not convey any other information = in this message or trigger re-authentication from the PCP server without us= ing expired SA. we have three options now : d. If the server wants to send an unsolicited message, but the previous security association for the mapping identified in the original PCP request has expired then Option 1: 1. The server MUST be able to trigger re-authentication with the client. T= he unsolicited message for re-authentication can be integrity protected usi= ng the expired SA. Option 2: 1. The server MUST be able to trigger re-authentication with the client. T= he unsolicited message for re-authentication is not integrity protected usi= ng the expired SA. Option 3: The existing proposal in the draft for REQ-4-d-1. would like to hear comments from others on this requirement. --Tiru. From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Monday, May 20, 2013 1:23 PM To: Tirumaleswar Reddy (tireddy) Cc: pcp@ietf.org Subject: Re: [pcp] pcp auth requirements Hi Tiru, Please see below. c. If a server wants to send an unsolicited message, but the previous security association has expired 1. The server can continue to use the same SA to protect messages pertaining to that mapping, even if the SA is technically expired. "Expired" means "do not use (even if its still hanging around)". We not only do not need to use expired SAs, but also using something expire= d in any sense is plain wrong -- unless someone wants to redefine what "exp= ired" means. [TR] For example if we consider MSCHAPv2, there is configuration option where se= rver accepts the challenge-response from the client even if the password is= expired and allows it be changed. Alper> In that case the password is "expired for login purpose" (i.e., the = user cannot login using the password), but it's still "unexpired for passwo= rd change purpose" (and in fact the previous password is expired even for t= hat purpose). Please clarify if you have some attack in mind that would cause problems us= ing expired SA. Alper> SAs are given finite lifetimes for one of many reasons. It can be fo= r limiting the use of keys because they cannot stand infinite amount of use= in the face of crypto-attacks, it can be for limiting the access to the se= rvice (because the service provider allows finite access to the subscriber)= , it can be for periodically challenging the client to ensure the client de= vice is not compromised, etc. etc. Alper> These are all deployment considerations. At the protocol design leve= l, we won't know why the SA lifetime is set to the value it is set to. Usin= g the SA beyond its lifetime is going to violate one of the deployment cons= iderations, and we won't even know which. And we won't know how to remedy i= t. This is complicated. Alper> It's even more complicated. How long would each party hold on to the= expired SAs? What happens if the receiver has "rightfully" yanked the SA a= fter it expired? Alper> I don't see the utility of using expired SAs either. If the server w= ants to tell the client to re-auth, it should just do that. No point in usi= ng expired SAs to do that. [/TR] - Such server notifications will not change state in the PCP client. - The notification could be a trigger for the client to re-authenticate. Here the document is getting into some solution description. Alper> Just to make sure... I'm saying the document shall not get into the = solution space. And as for such a solution: Instead of sending a notification that is protected with an expired SA to m= ean "re-authenticate", why not send an explicit message that says "re-authe= nticate"? [TR] The client has trusted the PCP server sometime back using mutual authentica= tion, so it can assume the integrity protected PCP response using expired S= A is coming from the same PCP server and not from some attacker posing as P= CP server. [/TR] Alper> The client knows the IP address of the PCP server, right? So, the f= irst line of defense is to check if the IP address of the PCP server is the= expected one. Alper> Let's say the attacker is using the legit PCP server IP address, an= d it worked its way thru ingress filtering. Alper> The worst that happens is (when not using expired SAs), the client i= s triggered to enter the re-auth phase. Alper> If the attacker is not able to receive the responses, then the first= message exchange will hang because the attacker cannot receive and respon= d. Client will timeout and that's it. Alper> If the attacker is able to receive responses as well (somehow it's M= itM), then the re-auth works all the way, until the "authentication" fails. Alper> No serious harm is done. Alper> In either case, this is a minor threat that simply gets the PCP clie= nt into single re-auth when it in fact didn't have to. Alper> Using expired SA prevents that, but the complexity and unknown side = effects are not worth it. What is gained by appearing to use an expired SA (but in fact not really us= ing it! because the payload of the notification is not consumed by the rece= iver). For example, if the server indicates that external IP address/port has changed, the PCP client can then re-authenticate with the server to confirm if the external IP address/port for the mapping has indeed changed. 2. The server can optionally trigger re-authentication with the client. Yes, that's the solution. If the server has something to send to the client= , and there's no live SA, then the server first needs to trigger re-auth, s= etup a fresh SA, then send whatever it wants to send to the client. [TR] We have updated this requirement in the new draft, please have a look. Alper> I see "The server MUST be able to optionally trigger re-authenticati= on with the client." Alper> Then using expired SA could be to about "using the expired SA to pro= tect the trigger message". Alper Best Regards, --Tiru. [/TR] --_000_913383AAA69FF945B8F946018B75898A14B706A6xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alper> I see "The server MUST be able to optionally = trigger re-authentication with the client."

Alper> Then using expired SA could be to about "usin= g the expired SA to protect the trigger message".

 

The suggestion from Alper is to use expired SA only to trigg= er re-authentication and this unsolicited message should not convey any oth= er information in this message or trigger re-authentication from the PCP server without using exp= ired SA.

 

we have three options now :

 =

  = ;    d.  If the server wants to send an unsolicited mes= sage, but the

  = ;        previous security association f= or the mapping

  = ;        identified in the original PCP = request has expired then

 =

Option 1:

 =

1.  The server MUST be able to trigger re-= authentication with the client. The unsolicited message for re-authenticati= on can be integrity protected using the expired SA.

 

Option 2:

 =

1.  The server MUST be able to trigger re-= authentication with the client. The unsolicited message for re-authenticati= on is not integrity protected using the expired SA.

 

Option 3:

 =

The existin= g proposal in the draft for REQ-4-d-1.

 

would like to hear comments from others on this requirement.=

 

--Tiru.

From: Alper Ye= gin [mailto:alper.yegin@yegin.org]
Sent: Monday, May 20, 2013 1:23 PM
To: Tirumaleswar Reddy (tireddy)
Cc: pcp@ietf.org
Subject: Re: [pcp] pcp auth requirements

 

Hi Tiru,

 

Please see below.

 

=       c.  If a server wants to send an unsolicited mess= age, but the

=           previous security as= sociation has expired

 

=           1.  The server = can continue to use the same SA to protect

=             &nb= sp; messages pertaining to that mapping, even if the SA is

=             &nb= sp; technically expired.

 

= "Expired" means "do not use (even if its still hanging aroun= d)". 

= We not only do not need to use expired SAs, but also using something expire= d in any sense is plain wrong -- unless someone wants to redefine what &quo= t;expired" means.

 

= [TR]

= For example if we consider MSCHAPv2, there is configuration option where se= rver accepts the challenge-response from the client even if the password is= expired and allows it be changed. 

 

 

Alper> In that case the password is "expired= for login purpose" (i.e., the user cannot login using the password), = but it's still "unexpired for password change purpose" (and in fact the previous password is expired even for that purpose). 

 

 

= Please clarify if you have some attack in mind that would cause problems us= ing expired SA.

 

Alper> SAs are given finite lifetimes for one of = many reasons. It can be for limiting the use of keys because they cannot st= and infinite amount of use in the face of crypto-attacks, it can be for limiting the access to the service (because the service prov= ider allows finite access to the subscriber), it can be for periodically ch= allenging the client to ensure the client device is not compromised, etc. e= tc. 

 

Alper> These are all deployment considerations. A= t the protocol design level, we won't know why the SA lifetime is set to th= e value it is set to. Using the SA beyond its lifetime is going to violate one of the deployment considerations, and we won't eve= n know which. And we won't know how to remedy it. This is complicated.=

 

Alper> It's even more complicated. How long would= each party hold on to the expired SAs? What happens if the receiver has &q= uot;rightfully" yanked the SA after it expired?

 

Alper> I don't see the utility of using expired S= As either. If the server wants to tell the client to re-auth, it should jus= t do that. No point in using expired SAs to do that.

 

 

 

= [/TR]

 

=             &nb= sp; -  Such server notifications will not change state in the

=             &nb= sp;    PCP client.

 

=             &nb= sp; -  The notification could be a trigger for the client to

=             &nb= sp;    re-authenticate.  

 

= Here the document is getting into some solution description.

 

 

Alper> Just to make sure… I'm saying the document= shall not get into the solution space.

 

 

= And as for such a solution:

 

= Instead of sending a notification that is protected with an expired SA to m= ean "re-authenticate", why not send an explicit message that says= "re-authenticate"?

 

= [TR] 

= The client has trusted the PCP server sometime back using mutual authentica= tion, so it can assume the integrity protected PCP response using expired S= A is coming from the same PCP server and not from some attacker posing as PCP server.

= [/TR]

 

 

Alper>  The client knows the IP address of t= he PCP server, right? So, the first line of defense is to check if the IP a= ddress of the PCP server is the expected one.

Alper>  Let's say the attacker is using the = legit PCP server IP address, and it worked its way thru ingress filtering.<= o:p>

Alper> The worst that happens is (when not using = expired SAs), the client is triggered to enter the re-auth phase.

Alper> If the attacker is not able to receive the= responses, then the first message exchange will hang  because the att= acker cannot receive and respond. Client will timeout and that's it.

Alper> If the attacker is able to receive respons= es as well (somehow it's MitM), then the re-auth works all the way, until t= he "authentication" fails. 

Alper> No serious harm is done. <= /p>

 

Alper> In either case, this is a minor threat tha= t simply gets the PCP client into single re-auth when it in fact didn't hav= e to. 

 

Alper> Using expired SA prevents that, but the co= mplexity and unknown side effects are not worth it. 

 

 

 

= What is gained by appearing to use an expired SA (but in fact not really us= ing it! because the payload of the notification is not consumed by the rece= iver).

 

 

=             &nb= sp;    For example, if the server indicates

=             &nb= sp;    that external IP address/port has changed, the PCP

=             &nb= sp;    client can then re-authenticate with the server to

=             &nb= sp;    confirm if the external IP address/port for the mappi= ng

=             &nb= sp;    has indeed changed.

 

=           2.  The server = can optionally trigger re-authentication with

=             &nb= sp; the client.

 

 

Yes, that's the soluti= on. If the server has something to send to the client, and there's no live = SA, then the server first needs to trigger re-auth, setup a fresh SA, then = send whatever it wants to send to the client.

 

= [TR]

 

= We have updated this requirement in the new draft, please have a look.=

 

 

Alper> I see "The server MUST be able to optionally = trigger re-authentication with the client."

Alper> Then using expired SA could be to about &q= uot;using the expired SA to protect the trigger message".

 

Alper

 

 

 

= Best Regards,

= --Tiru.

 

= [/TR]

 

--_000_913383AAA69FF945B8F946018B75898A14B706A6xmbrcdx10ciscoc_-- From Ted.Lemon@nominum.com Tue May 21 08:29:43 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD25A21F89D5 for ; Tue, 21 May 2013 08:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 xpTLGg1yB7bF for ; Tue, 21 May 2013 08:29:36 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF3721F878C for ; Tue, 21 May 2013 08:29:36 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUZuS37S0rfAehSd26SJpO9Rxbztq0VL9@postini.com; Tue, 21 May 2013 08:29:36 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C11581B8198 for ; Tue, 21 May 2013 08:29:35 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B8B9019005D; Tue, 21 May 2013 08:29:35 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Tue, 21 May 2013 08:29:35 -0700 From: Ted Lemon To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [pcp] pcp auth requirements Thread-Index: AQHORXOJ+mcGknPzdUqous5Dz9jpmpkLw0oAgAKFY4CAAgksAIAACJYA Date: Tue, 21 May 2013 15:29:35 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751AB074@mbx-01.win.nominum.com> References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> <8AF116E2-B8E5-4228-8437-B8B4867CA6E2@yegin.org> <913383AAA69FF945B8F946018B75898A14B706A6@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A14B706A6@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B6307751AB074mbx01winnominum_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] pcp auth requirements 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, 21 May 2013 15:29:43 -0000 --_000_8D23D4052ABE7A4490E77B1A012B6307751AB074mbx01winnominum_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On May 21, 2013, at 10:58 AM, "Tirumaleswar Reddy (tireddy)" > wrote: would like to hear comments from others on this requirement. Suppose we say that reauthentication can be triggered using an expired secu= rity association. Here's how it would go: 1. Server sends signed reauthentication request, using expired SA. 2. Client gets signed request and either: a. remembers the expired SA and validates the message with it b. does not remember the expired SA, and can't validate the message If b is possible, then there is no point in signing the message, because an= attacker can always send a message signed with an unknown SA. So in orde= r to get any benefit from signing a message with an expired SA, you have to= require that the client retain all expired SAs, and reject any message tha= t's signed with an unknown SA, or not signed at all. But I don't think yo= u can do that, because now there is no way to recover from a loss of state= =97once either the server or the client forgets an SA, there is no way for = the server to initiate communication with the client. If that scenario is possible, I don't see any benefit to using expired SAs= =97I can't think of a situation where signing the message with the expired = SA can be assumed to add any security at all. That being the case, I thin= k you should just never use expired SAs. Of course, I am not completely up to speed here, so some of the assumptions= I have made may be wrong. But if not, I think you should just drop this = expired SA idea. --_000_8D23D4052ABE7A4490E77B1A012B6307751AB074mbx01winnominum_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5F0DDEAEDBB7AE4CA7DBEACAFC2DC7DD@nominum.com> Content-Transfer-Encoding: quoted-printable
On May 21, 2013, at 10:58 AM, "Tirumaleswar Reddy (tireddy)"= <tireddy@cisco.com> wr= ote:
would like to hear comments from others on this requireme= nt.
<ad hat off>

Suppose we say that reauthentication can be triggered using an expired= security association.   Here's how it would go:

1. Server sends signed reauthentication request, using expired SA.
2. Client gets signed request and either:
a. rem= embers the expired SA and validates the message with it
b. doe= s not remember the expired SA, and can't validate the message

If b is possible, then there is no point in signing the message, becau= se an attacker can always send a message signed with an unknown SA.   = So in order to get any benefit from signing a message with an expired SA, y= ou have to require that the client retain all expired SAs, and reject any message that's signed with an unknown SA, = or not signed at all.   But I don't think you can do that, because now= there is no way to recover from a loss of state=97once either the server o= r the client forgets an SA, there is no way for the server to initiate communication with the client.

If that scenario is possible, I don't see any benefit to using expired= SAs=97I can't think of a situation where signing the message with the expi= red SA can be assumed to add any security at all.   That being the cas= e, I think you should just never use expired SAs.

Of course, I am not completely up to speed here, so some of the assump= tions I have made may be wrong.   But if not, I think you should just = drop this expired SA idea.

--_000_8D23D4052ABE7A4490E77B1A012B6307751AB074mbx01winnominum_-- From dwing@cisco.com Tue May 21 12:43:58 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6801321F9593 for ; Tue, 21 May 2013 12:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bypMQniARf6D for ; Tue, 21 May 2013 12:43:54 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 33CB821F9590 for ; Tue, 21 May 2013 12:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2360; q=dns/txt; s=iport; t=1369165434; x=1370375034; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=tuqw8VvMjQd+p1lVYrYR+a4MBOoqG4OZybIjdv6nzrA=; b=GEswZouF1rVc486vi2gcy7JNPNwHHJSZciuzCwFWGw1TnSmMCZchp6gF 7JBno/ZD5li7FlcJrcjvqsj1lQHwuy24AoGEjLmJ7/I47YOkKX59RFnVy w2I4T1hI3HXDqz6f8OLlatp21mFxbjWsORrv4TTm7kj2brAa2W4Aqx3m2 E=; X-IronPort-AV: E=Sophos;i="4.87,715,1363132800"; d="scan'208";a="79200537" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 21 May 2013 19:43:54 +0000 Received: from sjc-vpn4-364.cisco.com (sjc-vpn4-364.cisco.com [10.21.81.108]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4LJhrfK025989; Tue, 21 May 2013 19:43:53 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F060409087E21@xmb-rcd-x04.cisco.com> Date: Tue, 21 May 2013 12:43:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <45A697A8FFD7CF48BCF2BE7E106F060409087E21@xmb-rcd-x04.cisco.com> To: Reinaldo Penno (repenno) X-Mailer: Apple Mail (2.1503) Cc: "pcp@ietf.org" Subject: Re: [pcp] PORT_SET for discovering static port set mappings 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, 21 May 2013 19:43:58 -0000 On May 20, 2013, at 3:42 AM, Reinaldo Penno (repenno) = wrote: >=20 >=20 > On 5/20/13 2:54 AM, "Simon Perreault" = wrote: >=20 >> Le 2013-05-18 23:06, Reinaldo Penno (repenno) a =E9crit : >>> Interesting. How about stateless NAT64? >>=20 >> Sure, it could be used for that too. Any NATxy static port set = mapping >> can be discovered. >>=20 >>> And last but not least, how about PEER messages? I will send a = separate >>> message about my experiments with transmission Bittorrent to see = other >>> people's opinion. >>>=20 >>>=20 >>> The current message does not allow the client to specify the = internal >>> port >>> set. >>=20 >> Right. So far we have considered PEER out of scope for this draft. >=20 >=20 > I have the following scenario so we can gauge if PEER is in scope: >=20 > - I changed transmission BT to send a PEER message for every outgoing = TCP > connection it makes. A bittorrent client is operating a symmetric client/server -- it is = making outgoing connections and accepting incoming connections. Seems = MAP, as described in http://tools.ietf.org/html/rfc6887#section-10.2, = would be appropriate. With MAP, the problems below seem to all go away. -d > After running a few tests the issue that bubbled up is that both > Transmission and my FW/NAT is paying a penalty for using PCP PEER this = way > since they both need manage 100s (or 1000s) of PEER mappings. For P2P > software and some video streaming clients that have a high number of > connections, the use of PCP should be simplified. I thought about two = of > ways of doing that: >=20 > - Wildcards in PEER messages >=20 > - PEER Port set. I guess one can argue a port set is a middle ground > between a fully specified 5-tuple and a wildcard. >=20 > Both have issues that need ironing out but I believe it would simplify > considerably PCP use for those types of clients. >=20 >=20 >=20 >>=20 >> Simon >> --=20 >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From dwing@cisco.com Tue May 21 12:58:42 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57F211E8126 for ; Tue, 21 May 2013 12:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5xrNdJyxfIu for ; Tue, 21 May 2013 12:58:38 -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 096D111E811E for ; Tue, 21 May 2013 12:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46574; q=dns/txt; s=iport; t=1369166318; x=1370375918; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=OjSYTkqpJpi8pNIaCDjnwb7ac6ZJsBBuYYcQvA1O1IM=; b=M6E5UHcsnjUnG1zrXm5edlVpbVod2td4WjfpBir9gCDBFYD6rOHiNfqX t2v6UUYzTXVTNZwika5ETvtuZh40YqVRR5nq5J1HwBplyly54qaOhv/x8 RYh3ZWcp00tvtwg6bKTNgn14EVUArb4ftFdzUusaZlBNwIKxyZZqfRrXW 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswFALHQm1GrRDoH/2dsb2JhbABZgkREMLkbiDaBCxZ0giMBAQEDAQEBAWsLBQsLOAENIQYwBhOHewMJBQ2yfA2IUoxDgROBRAeCc2EDiR+MM4FmgSmKdIUjgy8cgSw X-IronPort-AV: E=Sophos;i="4.87,715,1363132800"; d="scan'208,217";a="81707079" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 21 May 2013 19:58:34 +0000 Received: from sjc-vpn4-364.cisco.com (sjc-vpn4-364.cisco.com [10.21.81.108]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4LJwXHE008354; Tue, 21 May 2013 19:58:33 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_FD08694C-6217-4A8A-BF70-50CE126F3EA4" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: <519A4189.407@gmail.com> Date: Tue, 21 May 2013 12:58:33 -0700 Message-Id: <5322C866-1EA4-4B4B-BA6C-6B016A869D52@cisco.com> References: <519A4189.407@gmail.com> To: Ben McCann X-Mailer: Apple Mail (2.1503) Cc: pcp@ietf.org Subject: Re: [pcp] Clarification to Section 15 of RFC 6887 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, 21 May 2013 19:58:42 -0000 --Apple-Mail=_FD08694C-6217-4A8A-BF70-50CE126F3EA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On May 20, 2013, at 8:30 AM, Ben McCann wrote: > I'm finding the discussion in section 15 of the RFC confusing because = the use of 'mapping' in Section 15 is ambiguous to me. (Yes, 'mapping' = is defined in the terminology section of the RFC but it's still = ambiguous in Section 15). >=20 > My problem is that the RFC states a MAP opcode creates a 'mapping' but = then it doesn't really discuss the difference between an explicit = mapping created by PCP and and other implicit mappings created, on = demand, by the PCP created explicit mapping. The following points = attempt to use the terminology in RFC 6887: > An 'implicit dynamic outbound' mapping defines the transformation of = *one* TCP or UDP flow from a client behind the NAT to a server outside = the NAT. This mapping is created implicitly when the client connects to = the server. Typically the client's source address and port are rewritten = by the NAT to some other source address and port owned by the NAT. Most = importantly, *both* endpoints of the flow are known. > In contrast, an 'explicit dynamic inbound' mapping created by the PCP = MAP opcode only defines *one* endpoint. A server behind the NAT defines = its listening endpoint and the NAT provides a corresponding listening = endpoint on the outside of the NAT. The IP address and port of clients = outside the NAT are unknown, at this time, because all we've created is = a 'listener'. > When a client outside the NAT connects to a server behind the NAT via = the 'explicit dynamic inbound' mapping then another 'mapping' is = created. That depends on the implementation of the NAT; in some NATs, that = incoming packet will create an additional data structure within the NAT, = whereas in some other NATs, no additional datastructure is created (thus = now new mapping is created). > This 'mapping' has *two* endpoints, like an implicit dynamic outbound = mapping, and it is created implicitly using the 'explict dynamic = inbound' mapping defined by the PCP MAP opcode. I don't think the RFC = does a good job of labeling or describing this kind of mapping. On purpose, because this gets into detail of how a NATP44 is = implemented. IETF was late to that party, and the best that was done = was BEHAVE which skirted around a lot of the details because there was = no chance of influencing existing NAT44 behavior. > I *think* the RFC also uses the term 'explicit mapping' for this kind = of mapping but I find that misleading. This mapping is created = implicitly when a TCP SYN packet from a client outside the NAT was = transmitted to a server *behind* the NAT. For now, I'm calling this an = 'IMPLICIT INBOUND MAPPING'. Well, okay. But for NATs that don't create any additional datastructure = or state when such a packet arrives, they won't have that concept. > Note that inbound and outbound IMPLICIT mappings have an 'idle-timeout = time' which describes when the mapping can be destroyed due to lack of = traffic. That timeout must (I think) be at least 2 minutes for UDP and = 124 minutes for TCP. (The exact timeout limits aren't critical to this = discussion). >=20 > The discussion in Section 15 about 'mapping lifetime and deletion' can = (I think) be interpreted in different ways depending on the definition = of 'mapping'. When a MAP request arrives with a zero lifetime then we = have to clean up some inbound mapping but, I argue, that cleanup varies = depending on whether the mapping is explicit (created by PCP MAP) or = implicit (created implicitly on behalf of some *other* explicit inbound = mapping).=20 When a MAP with lifetime=3D0 arrives -- or, really, any other lifetime = -- it will not cause a deletion unless the mapping has not been used for = a while. The exact text is at the bottom of Section 15: Furthermore, to reduce port stealing attacks, the assigned external port also SHOULD NOT be reused for an interval equal to the time the PCP- controlled device would normally maintain an idle (no traffic) implicit dynamic mapping (e.g., 2 minutes for UDP [RFC4787] and 124 minutes for TCP [RFC5382]). However, within these time windows, the PCP server SHOULD allow an external port to be reclaimed by the same client, where "same client" means "same internal IP address, internal port, and mapping nonce". > Specifically: > The 'explicit dynamic inbound' mapping created by the PCP MAP opcode = must be deleted *immediately*. The server behind the NAT wants no *new* = inbound connections. It is no longer 'listening'. > The 'implicit dynamic inbound' mappings, that are TCP and UDP flows = connecting two distinct endpoints, must be deleted at the end of their = NAT idle-timeout time. I.e. if a packet has been received within the NAT = idle-timeout time then the 'implicit dynamic inbound' mapping CANNOT be = deleted because a flow is still active between two endpoints. If the = 'implicit dynamic inbound' mapping has been idle for longer than the NAT = idle-timeout time then it can be deleted, if it hasn't been already. > The RFC seems to imply that its OK to delete 'implicit dynamic = mapping's that were idle for more than the NAT idle timeout when a PCP = MAP opcode is received with a lifetime of zero. That doesn't make sense = to me because why wasn't it ALREADY deleted? It's idle. I believe you are saying MAP with Lifetime=3D0 is always useless. The = case where it is useful is if a MAP request is made for a long time = (let's say, 24 hours) and the response indicates the assigned lifetime = is a long time (let's say, 12 hours). Then, an hour later, the client = decides it doesn't want that mapping so it sends a new MAP with = lifetime=3D0. As long as the client never sent any traffic using that = mapping, the mapping can be immediately destroyed. If the client did = send traffic using that mapping, the last paragraph of Section 15 says = the mapping SHOULD persist until the NAT would have normally timed it = out from that client activity. >=20 > I think this can be boiled down to a simpler description of 'lifetime' = and 'timeouts': > Servers behind a NAT use the PCP MAP opcode to start listening for = incoming connections from clients outside the NAT. The 'lifetime' within = the PCP MAP opcode declares how long the server wants to listen for new = connections. This must be refreshed (with another MAP opcode) before the = lifetime expires if the server wishes to continue listening. Sounds good. > An 'implicit dynamic inbound' mapping is created when clients connect = to the server that declared its intent to listen for connections via the = PCP MAP request. The 'idle-timeout' time of that mapping is defined by = TCP or UDP protocol and the policy of the NAT box. If neither client nor = server transmits packets within this 'idle-timeout' time then the = 'implicit dynamic inbound' mapping will be automatically destroyed. I don't see a need to define 'implicit dynamic inbound', especially = considering a NAT does not necessarily need to create state because of = that incoming packet. The only thing that should keep the mapping open = is activity by the client -- sending data on that mapping or refreshing = the mapping with a PCP MAP request. Specifically, activity from the = Internet is not sufficient to keep the mapping open (which is the same = as existing behavior of NATs and firewalls, and conforms to BEHAVE's TCP = and UDP RFCs on NAT and firewall behavior). > Any 'implicit dynamic inbound' mappings created by an 'explicit = inbound mapping' created by PCP MAP that are still active when the = 'explicit inbound mapping' is destroyed SHALL NOT be destroyed as a = side-effect of destroying the PCP mapping. The 'implicit dynamic = inbound' mappings shall be destroyed when the peers either close the = connection or when the idle-timeout expires. > Is this 'simpler description' consistent with the behavior of PCP = lifetimes as intended by Section 15 of RFC 6887? Yes, by my read of what you said. -d >=20 > -Ben McCann >=20 >=20 >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp --Apple-Mail=_FD08694C-6217-4A8A-BF70-50CE126F3EA4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 bn.mccann@gmail.com> = wrote:

=20

My problem is that the RFC states a MAP opcode creates a 'mapping' but then it doesn't really discuss the difference between an
  • An 'implicit dynamic outbound' mapping defines the transformation of *one* TCP or UDP flow from a client behind the NAT to a server In contrast, an 'explicit dynamic inbound' mapping created by the PCP MAP opcode only defines *one* endpoint. A server behind the When a client outside the NAT connects to a server behind the NAT via the 'explicit dynamic inbound' mapping then another 'mapping'
        Note that inbound and outbound IMPLICIT mappings have an 'idle-timeout time' which describes when the mapping can be destroyed due to
        The discussion in Section 15 about 'mapping lifetime and deletion' can (I think) be interpreted in different ways depending on the that cleanup varies depending on whether the mapping is explicit (created by PCP MAP) or implicit (created implicitly on behalf of = Furthermore, to reduce port stealing attacks, the assigned external port also SHOULD NOT be reused for an interval equal to the time the PCP- controlled device would normally maintain an idle (no traffic) implicit dynamic mapping (e.g., 2 = minutes for UDP [RFC4787] and 124
           minutes for TCP [RFC5382]).  However, within =
these time windows, the
   PCP server SHOULD allow an external port to be reclaimed by the same
   client, where "same client" means "same internal IP address, internal
   port, and mapping nonce".


        Specifically:
        • The 'explicit dynamic inbound' mapping created by the PCP MAP opcode must be deleted *immediately*. The server behind the NAT wants no = *new* inbound connections. It is no longer 'listening'.
        • The 'implicit dynamic inbound' mappings, that are TCP and UDP flows connecting two distinct endpoints, must be deleted at the end of The RFC seems to imply that its OK to delete 'implicit dynamic mapping's that were idle for more

          I think this can be boiled down to a simpler description of 'lifetime' and 'timeouts':
          • Servers behind a NAT use the PCP MAP opcode to start listening for incoming connections from clients outside the NAT. The 'lifetime'
            • An 'implicit dynamic inbound' mapping is created when clients connect to the server that declared its intent to listen for
              • Any 'implicit dynamic inbound' mappings created by an 'explicit inbound mapping' created by PCP MAP that are still active when the inbound' mappings shall be destroyed when the peers either close the connection or when the idle-timeout expires.
              Is this 'simpler description' consistent with the behavior of PCP lifetimes as intended by Section 15 of RFC = 6887?

        Yes, by my = read of what you = said.

        -d



        -Ben McCann




        _______________________________________________
        pcp mailing = list
        pcp@ietf.org
        https://www.ietf.org/mail= man/listinfo/pcp

        = --Apple-Mail=_FD08694C-6217-4A8A-BF70-50CE126F3EA4-- From repenno@cisco.com Tue May 21 13:00:24 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256E911E8128 for ; Tue, 21 May 2013 13:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6Denz9h37bt for ; Tue, 21 May 2013 13:00:19 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7F86A11E811E for ; Tue, 21 May 2013 13:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2600; q=dns/txt; s=iport; t=1369166419; x=1370376019; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8cqIyjw86bi5mUsxi3inV4YhOlTgAShFsj5trSXeyz8=; b=bN991T4ZM+jIs4PMNdEqyudrYqiGRZgLvsQC/pAO3LWM/z0fTdr/TsjD XAbIlbaURZKFol0PizWWpi1PrsSHGhewKYv8FyR1MlgL5kS3IdPWvpYPZ UcaP6pfyyV65zF6Z9aqNrehmpOobRWjj2IBi3UA7lPWOeq5yLIJqk301p M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoFALHRm1GtJV2b/2dsb2JhbABZgwgwwVKBCxZ0giUBBAEBASRHCxIBCCJLCyUCBA4FCIgFDLtZjmkxB4InTGEDiGePeohyhyWDD4Im X-IronPort-AV: E=Sophos;i="4.87,715,1363132800"; d="scan'208";a="213387456" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 21 May 2013 20:00:19 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4LK0If0024625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 20:00:18 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Tue, 21 May 2013 15:00:18 -0500 From: "Reinaldo Penno (repenno)" To: "Dan Wing (dwing)" Thread-Topic: [pcp] PORT_SET for discovering static port set mappings Thread-Index: AQHOUwjMWJqbrRT94kiXOQ14KOgabpkLkrWAgAJX7QCAAB49gIACW+2A///SSIA= Date: Tue, 21 May 2013 20:00:18 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040908998C@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.244.154] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] PORT_SET for discovering static port set mappings 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, 21 May 2013 20:00:24 -0000 Yes, but as long as outgoing and incoming use the same internal source ports. I will take some measurements and report back. On 5/21/13 4:43 PM, "Dan Wing" wrote: > >On May 20, 2013, at 3:42 AM, Reinaldo Penno (repenno) >wrote: > >>=20 >>=20 >> On 5/20/13 2:54 AM, "Simon Perreault" >>wrote: >>=20 >>> Le 2013-05-18 23:06, Reinaldo Penno (repenno) a =E9crit : >>>> Interesting. How about stateless NAT64? >>>=20 >>> Sure, it could be used for that too. Any NATxy static port set mapping >>> can be discovered. >>>=20 >>>> And last but not least, how about PEER messages? I will send a >>>>separate >>>> message about my experiments with transmission Bittorrent to see other >>>> people's opinion. >>>>=20 >>>>=20 >>>> The current message does not allow the client to specify the internal >>>> port >>>> set. >>>=20 >>> Right. So far we have considered PEER out of scope for this draft. >>=20 >>=20 >> I have the following scenario so we can gauge if PEER is in scope: >>=20 >> - I changed transmission BT to send a PEER message for every outgoing >>TCP >> connection it makes. > >A bittorrent client is operating a symmetric client/server -- it is >making outgoing connections and accepting incoming connections. Seems >MAP, as described in http://tools.ietf.org/html/rfc6887#section-10.2, >would be appropriate. With MAP, the problems below seem to all go away. > >-d > > >> After running a few tests the issue that bubbled up is that both >> Transmission and my FW/NAT is paying a penalty for using PCP PEER this >>way >> since they both need manage 100s (or 1000s) of PEER mappings. For P2P >> software and some video streaming clients that have a high number of >> connections, the use of PCP should be simplified. I thought about two of >> ways of doing that: >>=20 >> - Wildcards in PEER messages >>=20 >> - PEER Port set. I guess one can argue a port set is a middle ground >> between a fully specified 5-tuple and a wildcard. >>=20 >> Both have issues that need ironing out but I believe it would simplify >> considerably PCP use for those types of clients. >>=20 >>=20 >>=20 >>>=20 >>> Simon >>> --=20 >>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >>> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >>> STUN/TURN server --> http://numb.viagenie.ca >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > From subirdas21@gmail.com Tue May 21 13:33:08 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC0111E80FD for ; Tue, 21 May 2013 13:33:08 -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, HTML_MESSAGE=0.001, 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 Wx4564sdZ8ed for ; Tue, 21 May 2013 13:33:07 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE6111E80FA for ; Tue, 21 May 2013 13:33:07 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id 10so3052416ied.19 for ; Tue, 21 May 2013 13:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=acR73AYZlUEUIJpCPgHjjm9fVbfpcr5FI6HcgDziRdo=; b=WIbXYBW5RyEeA/DlfsI/fhiG/UDcAGOMVJ6d5i/yCb+rtF+GUsezOkQm13vWtEmGYv vzzsMmxc9+DJ7KH+Cn+vd9Ru8MSA58+3Y/W/hDPX7tsEFIS3YmfJtjWd0j4lu6gzVePu q7Pdj0d0XyLn3zw3FRjxzKuxKrg/pww/WKl7u9r88QN9GX+PavVrvjJIMLeDeJQuxKVw 7B9g7EQ+f1SCnRwh74HAwzTJhiTZ22jB12QPKoKcMvjGh05AAH2TLRZ0RBb0vP241Bgr 8YTcDQDihz+g/bFAUI+4GSBgdDgIa0536X+cPkwhWhmJ4LSGSgoDbgI+ZWjeHZ4sGRjq DIVw== MIME-Version: 1.0 X-Received: by 10.50.106.114 with SMTP id gt18mr9110516igb.7.1369168386924; Tue, 21 May 2013 13:33:06 -0700 (PDT) Received: by 10.42.166.7 with HTTP; Tue, 21 May 2013 13:33:06 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751AB074@mbx-01.win.nominum.com> References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> <8AF116E2-B8E5-4228-8437-B8B4867CA6E2@yegin.org> <913383AAA69FF945B8F946018B75898A14B706A6@xmb-rcd-x10.cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751AB074@mbx-01.win.nominum.com> Date: Tue, 21 May 2013 16:33:06 -0400 Message-ID: From: Subir Das To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7bd763fc573d1c04dd405b55 Cc: "pcp@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [pcp] pcp auth requirements 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, 21 May 2013 20:33:08 -0000 --047d7bd763fc573d1c04dd405b55 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree. We should not use an expired SA. -Subir On Tue, May 21, 2013 at 11:29 AM, Ted Lemon wrote: > On May 21, 2013, at 10:58 AM, "Tirumaleswar Reddy (tireddy)" < > tireddy@cisco.com> wrote: > > would like to hear comments from others on this requirement. > > > > Suppose we say that reauthentication can be triggered using an expired > security association. Here's how it would go: > > 1. Server sends signed reauthentication request, using expired SA. > 2. Client gets signed request and either: > a. remembers the expired SA and validates the message with it > b. does not remember the expired SA, and can't validate the message > > If b is possible, then there is no point in signing the message, because > an attacker can always send a message signed with an unknown SA. So in > order to get any benefit from signing a message with an expired SA, you > have to require that the client retain all expired SAs, and reject any > message that's signed with an unknown SA, or not signed at all. But I > don't think you can do that, because now there is no way to recover from = a > loss of state=97once either the server or the client forgets an SA, there= is > no way for the server to initiate communication with the client. > > If that scenario is possible, I don't see any benefit to using expired > SAs=97I can't think of a situation where signing the message with the exp= ired > SA can be assumed to add any security at all. That being the case, I > think you should just never use expired SAs. > > Of course, I am not completely up to speed here, so some of the > assumptions I have made may be wrong. But if not, I think you should ju= st > drop this expired SA idea. > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > > --047d7bd763fc573d1c04dd405b55 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
        I agree. We should not use an expired SA.=A0
        =A0
        -Subir


      On Tue, May 21, 2013 at 11:29 AM, Ted Lemon <Te= d.Lemon@nominum.com> wrote:
      On May 21, 2013, at 10:58 AM, "Tirumaleswar Reddy (tireddy)"= <tireddy@cisco.c= om>=A0wrote:
      would like to hear comments from others on this requirement.=
      <ad hat off>

      Suppose we say that reauthentication can be triggered using an expired= security association. =A0 Here's how it would go:

      1. Server sends signed reauthentication request, using expired SA.
      2. Client gets signed request and either:
      a. remembers the expired S= A and validates the message with it
      b. does not remember the e= xpired SA, and can't validate the message

      If b is possible, then there is no point in signing the message, becau= se an attacker can always send a message signed with an unknown SA. =A0 So = in order to get any benefit from signing a message with an expired SA, you = have to require that the client retain all expired SAs, and reject any message that's signed with an unknown = SA, or not signed at all. =A0 But I don't think you can do that, becaus= e now there is no way to recover from a loss of state=97once either the ser= ver or the client forgets an SA, there is no way for the server to initiate communication with the client.

      If that scenario is possible, I don't see any benefit to using exp= ired SAs=97I can't think of a situation where signing the message with = the expired SA can be assumed to add any security at all. =A0 That being th= e case, I think you should just never use expired SAs.

      Of course, I am not completely up to speed here, so some of the assump= tions I have made may be wrong. =A0 But if not, I think you should just dro= p this expired SA idea.


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


      --047d7bd763fc573d1c04dd405b55-- From cheshire@apple.com Tue May 21 18:59:31 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AB021F8749 for ; Tue, 21 May 2013 18:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYjt+-z1e64y for ; Tue, 21 May 2013 18:59:24 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id AD65121F911B for ; Tue, 21 May 2013 18:59:24 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MN600JJ1G6UTU31@mail-out.apple.com> for pcp@ietf.org; Tue, 21 May 2013 18:59:24 -0700 (PDT) X-AuditID: 11807166-b7faa6d000003acb-77-519c267bb5b2 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id D0.82.15051.B762C915; Tue, 21 May 2013 18:59:24 -0700 (PDT) Received: from chesh1.apple.com (chesh1.apple.com [17.193.13.41]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MN6007I8G6Z7E20@spicerack.apple.com> for pcp@ietf.org; Tue, 21 May 2013 18:59:23 -0700 (PDT) From: Stuart Cheshire Date: Tue, 21 May 2013 18:59:23 -0700 To: pcp@ietf.org Message-id: <0DD77404-5087-49D6-914E-D5A7A9C4C420@apple.com> X-Mailer: Apple Mail (2.1503) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpiluLIzCtJLcpLzFFi42IRbCjW0K1RmxNo0PiE1WLysd+sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK6F36nLWgS7bi0ZwdLA2Mr8W6GDk5JARMJI7sv8MMYYtJXLi3 nq2LkYtDSGAyk8TCzctYIJwVTBIXlzWxgVSxCWhJvPh8BcxmBrLX7zzOBGFrSzx5d4EVxGYR UJWY/XQ5WFxYQE3i0v0usLiIgIDE79WXweK8AjYS91bvYISw9SS2zd3GBnGFrMTr529YJjDy zkKyYhaSFbOQtCxgZF7FKFCUmpNYaaGXWFCQk6qXnJ+7iREcMoVpOxibllsdYhTgYFTi4X1Q OztQiDWxrLgy9xCjBAezkgiv4TWgEG9KYmVValF+fFFpTmrxIUZpDhYlcd7fc2cFCgmkJ5ak ZqemFqQWwWSZODilGhjFGM4oFHH1KE1fNlFJoLW533ylbKn8m4dV8w4+D7qz+ZWA5xKD4Iuv 3I12F7AyVF+o6PGXdFKR6OXOu/m3o7WyNPnZk55JMk9Zozt6Wl/MrhR5v8XJmLn0xu6pbq3q ZYL3bcRt2IX7Ll/oNl2/OGbepOy2IEGW3jMC0Tc+hS7Nu2GQyDtbQYmlOCPRUIu5qDgRAGiH 4uwVAgAA Subject: [pcp] Stability of external 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: Wed, 22 May 2013 01:59:31 -0000 In some recent discussions I had, it became clear that the text below may be a little incomplete: The MAP and PEER requests include a Suggested External IP Address field. Some PCP-controlled devices, especially CGN but also multi- homed NPTv6 networks, have a pool of public-facing IP addresses. PCP allows the client to indicate if it wants a mapping assigned on a specific address of that pool or any address of that pool. Some applications will break if mappings are created on different IP addresses (e.g., active mode FTP), so applications should carefully consider the implications of using this capability. Static mappings for that internal address (e.g., those created by a command-line interface on the PCP server or PCP-controlled device) may exist to a certain external address, and if the suggested external IP address is the IPv4 or IPv6 all-zeros address, PCP SHOULD assign its mappings to the same external address, as this can also help applications using a mix of both static mappings and PCP-created mappings. If, on the other hand, the suggested external IP address contains a non-zero IP address the PCP server SHOULD create a mapping to that external address, even if there are other mappings from that same internal address to a different external address. Once an internal address has no implicit dynamic mappings and no explicit dynamic mappings in the PCP-controlled device, a subsequent implicit or explicit mapping for that internal address MAY be assigned to a different External address. Generally, this reassignment would occur when a CGN device is load balancing newly seen internal addresses to its public pool of external addresses. Specifically, it says: Once an internal address has no implicit dynamic mappings and no explicit dynamic mappings in the PCP-controlled device, a subsequent implicit or explicit mapping for that internal address MAY be assigned to a different External address. That implies the corollary: While an internal address has *some* mappings in the PCP-controlled device, new implicit or explicit mappings for that internal address SHOULD be assigned the *same* external address. Unfortunately, while it implies this, it does not actually state it. To clarify this I propose submitting the following erratum: Change: ... Static mappings for that internal address (e.g., those created by a command-line interface on the PCP server or PCP-controlled device) may exist to a certain external address, and if the suggested external IP address is the IPv4 or IPv6 all-zeros address, PCP SHOULD assign its mappings to the same external address, as this can also help applications using a mix of both static mappings and PCP-created mappings. To: ... Static mappings for that internal address (e.g., those created by a command-line interface on the PCP server or PCP-controlled device) may exist to a certain external address. If the suggested external IP address is the IPv4 or IPv6 all-zeros address, and the internal address currently has *any* active mappings (implicit, explicit, or static) with an external address of the indicated address family, then that external address SHOULD be used for the new mapping. If the existing mappings for that external address family do not all share a single external address, then the choice of which external address is assigned for the new mapping is implementation dependent. Comments? Do other agree that this correctly captures what we intended to say? Stuart Cheshire From cheshire@apple.com Tue May 21 19:08:43 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925BF21F92A1 for ; Tue, 21 May 2013 19:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hy1Gvzb8z5e9 for ; Tue, 21 May 2013 19:08:37 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2B73B21F86C3 for ; Tue, 21 May 2013 19:08:37 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MN600H8RGLDQ331@mail-out.apple.com> for pcp@ietf.org; Tue, 21 May 2013 19:08:13 -0700 (PDT) X-AuditID: 11807157-b7f706d0000006c6-f0-519c288d1b97 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 1A.12.01734.D882C915; Tue, 21 May 2013 19:08:13 -0700 (PDT) Received: from chesh1.apple.com (chesh1.apple.com [17.193.13.41]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MN6007QGGLP7E20@spicerack.apple.com> for pcp@ietf.org; Tue, 21 May 2013 19:08:13 -0700 (PDT) From: Stuart Cheshire Date: Tue, 21 May 2013 19:08:13 -0700 To: pcp@ietf.org Message-id: X-Mailer: Apple Mail (2.1503) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkluLIzCtJLcpLzFFi42IRbCjW0O3VmBNocGq9hsXkY79ZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsa7/MmPBKc6KU6va2BsYT7B3MXJySAiYSBzaeoUFwhaTuHBv PVsXIxeHkMBkJok9v18xQTgrmCS2fD7KBFLFJqAl8eLzFTYQmxnIXr/zOBOErS3x5N0FVhCb RUBV4v/yc8wgtrCAosSaU81gtoiAgMTv1ZeB6jk4eAVsJL68twcJ8wroSWybu40N4ghZidfP 37BMYOSdhWTDLCQbZiFpWcDIvIpRoCg1J7HSRC+xoCAnVS85P3cTIzhgCsN3MP5bZnWIUYCD UYmH90Ht7EAh1sSy4srcQ4wSHMxKIryr1OYECvGmJFZWpRblxxeV5qQWH2KU5mBREuf9OXdW oJBAemJJanZqakFqEUyWiYNTqoExg+958HHPHbVry1kCW08ohu+9q3KM2dTk0JYDhwQbPrl5 8M1QWpOlcVWy7kLodPEjome1na9Uh+ulHJCPyg0S3fbh7HbNS18nVG7Tz0o4miTxtNLVxVBU aEv+qaRP+iZN3tNkrNfePB0n/7Kob7IND99UHgeh4yVLu9P62eJU1b+xzWG2YVZiKc5INNRi LipOBADb8by0FAIAAA== Subject: [pcp] UNSUPP_FAMILY error code 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, 22 May 2013 02:08:43 -0000 In prototyping some PCP server code I ran into the following situation: In a PCP request, the type of address in the Suggested External Address field controls whether an external IPv4 or IPv6 address is allocated. See page 31: if the PCP client ... wants both IPv6 and IPv4 listeners, it sends a MAP request containing the all-zeros IPv6 address in the Suggested External Address field, and sends a second MAP request containing the all-zeros IPv4 address in the Suggested External Address field A NAT gateway that only implements IPv4 can support requests for an external IPv4 address (::FFFF:0.0.0.0 in the Suggested External Address field), but not requests for an external IPv6 address (:: in the Suggested External Address field). Hence, it needs to return an error code if it receives a request with the all-zeros IPv6 address in the Suggested External Address field. What error code? The closest I can see is UNSUPP_PROTOCOL (9), but that's not ideal. It would be better to have an explicit code for this. I propose: UNSUPP_FAMILY, with value 14. Comments? Do other agree that we should have an explicit error code for this case? Stuart Cheshire From eckert@cisco.com Tue May 21 20:54:47 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F8E21F826B for ; Tue, 21 May 2013 20:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtAlFgyzTG-b for ; Tue, 21 May 2013 20:54:43 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2821321F8B98 for ; Tue, 21 May 2013 20:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3340; q=dns/txt; s=iport; t=1369194883; x=1370404483; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=hMafZQgLjlD4tycaBjADLxmV4QJosr41TQ6trfMwISI=; b=THCbyW53LZQEvGgEeWc/PGGPngeQZ/Qg3Dqll2N6tBg+n9EMDwahibsm ERdkhBCahk4Jmiey9cDoOIk0qVPBsdyHn53gVrAZMC1QFtGEOF3p3Vvn7 L0tPBavh8vMkE0a1G22M0Becbw0Fe78G6lGtl3tEburFW/yJ+ftvmpeoh E=; X-IronPort-AV: E=Sophos;i="4.87,718,1363132800"; d="scan'208";a="79230831" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 22 May 2013 03:54:42 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4M3sgC9029342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 May 2013 03:54:42 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r4M3sfZr015580; Tue, 21 May 2013 20:54:41 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r4M3sfIf015579; Tue, 21 May 2013 20:54:41 -0700 Date: Tue, 21 May 2013 20:54:41 -0700 From: Toerless Eckert To: Subir Das Message-ID: <20130522035441.GT21357@cisco.com> References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> <8AF116E2-B8E5-4228-8437-B8B4867CA6E2@yegin.org> <913383AAA69FF945B8F946018B75898A14B706A6@xmb-rcd-x10.cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751AB074@mbx-01.win.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: "pcp@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [pcp] pcp auth requirements 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, 22 May 2013 03:54:48 -0000 I am not sure i understand all the details, but the root requirement seems to be that it must be possible to seamlessly maintain a PCP service in the face of SA's expiring. Obviously that does not mean that you need to trust expired SAs, but it seems to require that you have a scheme to renew SA or swap SAs seamlessly, right ? Also, one related question: If the SA is based on Certificates, are there any epectations on how PCP should deal with expired certificates ? I just ran into the issue that the certificates on my TivoHD expired in february. Of course there are no further SW updates and the certificates where 5-years old. In result, the SSL connections between the Tivo and my PCs failed and i had to hack around the PC side to permit getting the SSL connections to work again. And of course there is non non-SSL option to talk to the Rivo at all. Since that experience i start seeing certificates in embedded devices as the superior SW technology for planned obsolescence. So much easier to plan than trying to find the right shabby HW components. Of course i assume/hope that PCP would start to be used in embedded devices in the home so i fear this is an issue that could hit PCP unless the requirements are set right. Cheers Toerless On Tue, May 21, 2013 at 04:33:06PM -0400, Subir Das wrote: > I agree. We should not use an expired SA. > > -Subir > > > On Tue, May 21, 2013 at 11:29 AM, Ted Lemon wrote: > > > On May 21, 2013, at 10:58 AM, "Tirumaleswar Reddy (tireddy)" < > > tireddy@cisco.com> wrote: > > > > would like to hear comments from others on this requirement. > > > > > > > > Suppose we say that reauthentication can be triggered using an expired > > security association. Here's how it would go: > > > > 1. Server sends signed reauthentication request, using expired SA. > > 2. Client gets signed request and either: > > a. remembers the expired SA and validates the message with it > > b. does not remember the expired SA, and can't validate the message > > > > If b is possible, then there is no point in signing the message, because > > an attacker can always send a message signed with an unknown SA. So in > > order to get any benefit from signing a message with an expired SA, you > > have to require that the client retain all expired SAs, and reject any > > message that's signed with an unknown SA, or not signed at all. But I > > don't think you can do that, because now there is no way to recover from a > > loss of state?once either the server or the client forgets an SA, there is > > no way for the server to initiate communication with the client. > > > > If that scenario is possible, I don't see any benefit to using expired > > SAs?I can't think of a situation where signing the message with the expired > > SA can be assumed to add any security at all. That being the case, I > > think you should just never use expired SAs. > > > > Of course, I am not completely up to speed here, so some of the > > assumptions I have made may be wrong. But if not, I think you should just > > drop this expired SA idea. > > > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp From repenno@cisco.com Tue May 21 21:33:58 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2704921F922A for ; Tue, 21 May 2013 21:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VbhmzdHZJvL for ; Tue, 21 May 2013 21:33:53 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id DC15F21F9232 for ; Tue, 21 May 2013 21:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4230; q=dns/txt; s=iport; t=1369197233; x=1370406833; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=nGVOHoqqo2oG2UHFe+ycXdIbL5DCdHlcnmZozhtaCh0=; b=gYd712TJgKxl22IcEXwbhXACCr3gxkF1yC20w7D/dNSO6cHJ1X/HLHT0 r9aKgU9+sUHeHp5cpNuNRsU3dVHfzDmgulel8vnpbwKRZGjvMfLynRMp/ 6udhYbuutUIrSEVhHsClZNOPgEh4nKYqI6ug8Gm/9Lo1YEnmrqbdDG9PX 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0GAGZJnFGtJXG//2dsb2JhbABagwgwwWqBAhZ0giUBBAEBATc0HQEIIhQ3CyUCBAESCIgFDLtABI5pOIJzYQOoeIMPgiY X-IronPort-AV: E=Sophos;i="4.87,718,1363132800"; d="scan'208";a="213517971" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 22 May 2013 04:33:48 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4M4XmKi011660 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 May 2013 04:33:48 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Tue, 21 May 2013 23:33:47 -0500 From: "Reinaldo Penno (repenno)" To: Stuart Cheshire , "pcp@ietf.org" Thread-Topic: [pcp] Stability of external address Thread-Index: AQHOVpAC6bPPIl8ci0ioqstEiRhSGJkQv3wA Date: Wed, 22 May 2013 04:33:47 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F060409089D1E@xmb-rcd-x04.cisco.com> In-Reply-To: <0DD77404-5087-49D6-914E-D5A7A9C4C420@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.243.8] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Stability of external 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: Wed, 22 May 2013 04:33:59 -0000 I agree. I was pretty sure that at some point in the text we mentioned that RFC4787 REQ-2 should be obeyed when assigning external address, but scanning the text I could not find it. If we propose an errata maybe we should reference REQ-2. On 5/21/13 10:59 PM, "Stuart Cheshire" wrote: >In some recent discussions I had, it became clear that the text below may >be a little incomplete: > > The MAP and PEER requests include a Suggested External IP Address > field. Some PCP-controlled devices, especially CGN but also multi- > homed NPTv6 networks, have a pool of public-facing IP addresses. PCP > allows the client to indicate if it wants a mapping assigned on a > specific address of that pool or any address of that pool. Some > applications will break if mappings are created on different IP > addresses (e.g., active mode FTP), so applications should carefully > consider the implications of using this capability. Static mappings > for that internal address (e.g., those created by a command-line > interface on the PCP server or PCP-controlled device) may exist to a > certain external address, and if the suggested external IP address is > the IPv4 or IPv6 all-zeros address, PCP SHOULD assign its mappings to > the same external address, as this can also help applications using a > mix of both static mappings and PCP-created mappings. If, on the > other hand, the suggested external IP address contains a non-zero IP > address the PCP server SHOULD create a mapping to that external > address, even if there are other mappings from that same internal > address to a different external address. Once an internal address > has no implicit dynamic mappings and no explicit dynamic mappings in > the PCP-controlled device, a subsequent implicit or explicit mapping > for that internal address MAY be assigned to a different External > address. Generally, this reassignment would occur when a CGN device > is load balancing newly seen internal addresses to its public pool of > external addresses. > >Specifically, it says: > > Once an internal address > has no implicit dynamic mappings and no explicit dynamic mappings in > the PCP-controlled device, a subsequent implicit or explicit mapping > for that internal address MAY be assigned to a different External > address. > >That implies the corollary: While an internal address has *some* mappings >in the PCP-controlled device, new implicit or explicit mappings for that >internal address SHOULD be assigned the *same* external address. >Unfortunately, while it implies this, it does not actually state it. > >To clarify this I propose submitting the following erratum: > >Change: > > ... Static mappings > for that internal address (e.g., those created by a command-line > interface on the PCP server or PCP-controlled device) may exist to a > certain external address, > and if the suggested external IP address is > the IPv4 or IPv6 all-zeros address, PCP SHOULD assign its mappings to > the same external address, as this can also help applications using a > mix of both static mappings and PCP-created mappings. > >To: > > ... Static mappings > for that internal address (e.g., those created by a command-line > interface on the PCP server or PCP-controlled device) may exist to a > certain external address. > If the suggested external IP address is the IPv4 or IPv6 all-zeros > address, and the internal address currently has *any* active mappings > (implicit, explicit, or static) with an external address of the > indicated address family, then that external address SHOULD be used > for the new mapping. If the existing mappings for that external > address family do not all share a single external address, then the > choice of which external address is assigned for the new mapping is > implementation dependent. > >Comments? > >Do other agree that this correctly captures what we intended to say? > >Stuart Cheshire > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From repenno@cisco.com Tue May 21 21:35:13 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A106821F920E for ; Tue, 21 May 2013 21:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ1AX+XKhMV0 for ; Tue, 21 May 2013 21:35:08 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 47B2C21F8EB2 for ; Tue, 21 May 2013 21:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1451; q=dns/txt; s=iport; t=1369197308; x=1370406908; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=7kRnTozcgWmCQ8Iu8GhvCaBS2XGs1grXCOWqSwpwGaY=; b=HgODSMWuYmD4h8eKrDefuwl7DHJyw0yOiZydpq/zDP6yOs9DHlCuBUpZ GfNffv9gCxuYH5m6tX9iDfgY75QwDnLN9rQ7tw6LWnBw1TNkb1Akyw5Tc MPeJSbJlUDGCwjOlEaLLHaCrX/2N/17QaNxrPnlM/+DwdIaWTvr/BnG+T A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0GAGZJnFGtJXG//2dsb2JhbABagwgwwWqBAhZ0giUBBAEBATc0HQEIIhQ3CyUCBAESCIgFDLtABI5pOIJzYQOhU4clgw+CJg X-IronPort-AV: E=Sophos;i="4.87,718,1363132800"; d="scan'208";a="213403358" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 22 May 2013 04:35:06 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4M4Z6Rq013755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 May 2013 04:35:06 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 21 May 2013 23:35:05 -0500 From: "Reinaldo Penno (repenno)" To: Stuart Cheshire , "pcp@ietf.org" Thread-Topic: [pcp] UNSUPP_FAMILY error code Thread-Index: AQHOVpFLhzk+wmJ2FkiifnZjmrMpJJkQv9cA Date: Wed, 22 May 2013 04:35:05 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.243.8] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] UNSUPP_FAMILY error code 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, 22 May 2013 04:35:13 -0000 Agreed. On 5/21/13 11:08 PM, "Stuart Cheshire" wrote: >In prototyping some PCP server code I ran into the following situation: > >In a PCP request, the type of address in the Suggested External Address >field controls whether an external IPv4 or IPv6 address is allocated. See >page 31: > > if the PCP client ... wants both IPv6 and IPv4 > listeners, it sends a MAP request containing the all-zeros IPv6 > address in the Suggested External Address field, and sends a second > MAP request containing the all-zeros IPv4 address in the Suggested > External Address field > >A NAT gateway that only implements IPv4 can support requests for an >external IPv4 address (::FFFF:0.0.0.0 in the Suggested External Address >field), but not requests for an external IPv6 address (:: in the >Suggested External Address field). > >Hence, it needs to return an error code if it receives a request with the >all-zeros IPv6 address in the Suggested External Address field. > >What error code? The closest I can see is UNSUPP_PROTOCOL (9), but that's >not ideal. It would be better to have an explicit code for this. I >propose: > >UNSUPP_FAMILY, with value 14. > >Comments? > >Do other agree that we should have an explicit error code for this case? > >Stuart Cheshire > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From alper.yegin@yegin.org Wed May 22 00:22:55 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F05821F9339 for ; Wed, 22 May 2013 00:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.023 X-Spam-Level: X-Spam-Status: No, score=-102.023 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HTML_MESSAGE=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 SRzyfz9QQazT for ; Wed, 22 May 2013 00:22:49 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id D6DC121F9180 for ; Wed, 22 May 2013 00:22:48 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0Ln8wH-1TyZ9X2Mov-00hRdl; Wed, 22 May 2013 03:22:36 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_4FDC6465-D8F4-4D49-A820-5EC9BA004793" From: Alper Yegin In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B12D0CD38@tgxml338.toshiba.local> Date: Wed, 22 May 2013 10:22:27 +0300 Message-Id: References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B12D0CD38@tgxml338.toshiba.local> To: X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:W4VwAPFAePKsF16DiZc3v8TYjcQ/zJ2giwRI3Ar4vPc bQjc7fSP8WpyolxDGZF39Md+YvaEcmmMPfc4dtNBDZZsCyIbwm XeCMBXcfBs4JFPRgbwO7rpB+3DbONWZLQpWkByMsDvztqwq3LI W1/7PhuV5eUyyzLq0nBZ07R0J8nkarrEefxWyWcVx2lwhu3x8q mCYOfoSW4x3yN6na8YRAD+Dkz8bOFLOMbu99qO3RV0WgkZtTNG Q1NJAvsKyK8m1pDzgGRn805VZ9e0/RvMSNwGgzNwSSCOoGGdvY FenK1BwRJvpM441LcarvTVPClRmS6qgmhIDLcA2LAtLbxizqs0 nAInNZY//qcoGU8/J7bbzFVQbvUSYl97g21yT89wBQGY/hSoiR XcvINikeT2d3A== Cc: pcp@ietf.org, tireddy@cisco.com Subject: Re: [pcp] pcp auth requirements 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, 22 May 2013 07:22:55 -0000 --Apple-Mail=_4FDC6465-D8F4-4D49-A820-5EC9BA004793 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp On May 21, 2013, at 10:14 AM, = wrote: > Tiru, > =20 > In my analysis, Req-4-d-1 is basically introducing a three-state SA = model for PCP: State 0: unavailable (or non-existent), State 1: = partially available only for triggering re-auth, and State 2: fully = available. MSCHAPv2 password change function is designed based on this = model. > =20 > I am not going to get into details about the three-state SA model, but = even the three-state SA model will require re-auth trigger to be = integrity protected. =20 > =20 > Having said that, I think the following requirement is sufficient for = Req-4-d: =1B$B!H=1B(BThe server MUST be able to send an integrity = protected re-authentication trigger to the client.=1B$B!I=1B(B > =20 If there is no SA available, then the server can send an un-protected = re-auth trigger. We should allow that. This is equivalent to what happens at the very beginning before the very = first authentication between the client and the server. Alper > Regards, > Yoshihiro Ohba > =20 > =20 > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of = Tirumaleswar Reddy (tireddy) > Sent: Sunday, May 19, 2013 2:24 AM > To: Alper Yegin; pcp@ietf.org > Subject: Re: [pcp] pcp auth requirements > =20 > Hi Alper, > =20 > Please see inline [TR] > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Tuesday, April 30, 2013 12:53 PM > To: pcp@ietf.org > Subject: [pcp] pcp auth requirements > =20 >=20 >=20 > c. If a server wants to send an unsolicited message, but the > previous security association has expired > =20 > 1. The server can continue to use the same SA to protect > messages pertaining to that mapping, even if the SA is > technically expired. >=20 > "Expired" means "do not use (even if its still hanging around)".=20 > We not only do not need to use expired SAs, but also using something = expired in any sense is plain wrong -- unless someone wants to redefine = what "expired" means. > =20 > [TR] > For example if we consider MSCHAPv2, there is configuration option = where server accepts the challenge-response from the client even if the = password is expired and allows it be changed.=20 > =20 > Please clarify if you have some attack in mind that would cause = problems using expired SA. > =20 > [/TR] > =20 > - Such server notifications will not change state in = the > PCP client. > =20 > - The notification could be a trigger for the client to > re-authenticate. =20 >=20 > Here the document is getting into some solution description. >=20 > And as for such a solution: >=20 > Instead of sending a notification that is protected with an expired SA = to mean "re-authenticate", why not send an explicit message that says = "re-authenticate"? > =20 > [TR]=20 > The client has trusted the PCP server sometime back using mutual = authentication, so it can assume the integrity protected PCP response = using expired SA is coming from the same PCP server and not from some = attacker posing as PCP server. > [/TR] > =20 > What is gained by appearing to use an expired SA (but in fact not = really using it! because the payload of the notification is not consumed = by the receiver). >=20 >=20 > For example, if the server indicates > that external IP address/port has changed, the PCP > client can then re-authenticate with the server to > confirm if the external IP address/port for the = mapping > has indeed changed. > =20 > 2. The server can optionally trigger re-authentication with > the client. > =20 > =20 > Yes, that's the solution. If the server has something to send to the = client, and there's no live SA, then the server first needs to trigger = re-auth, setup a fresh SA, then send whatever it wants to send to the = client. > =20 > [TR] > =20 > We have updated this requirement in the new draft, please have a look. > =20 > Best Regards, > --Tiru. > =20 > [/TR] > =20 > =20 > Alper > =20 > =20 > =20 --Apple-Mail=_4FDC6465-D8F4-4D49-A820-5EC9BA004793 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-2022-jp

      Tiru,
       
      In my analysis, Req-4-d-1 is basically introducing a = three-state SA model for PCP: State 0:  unavailable (or = non-existent), State 1: partially available only for triggering re-auth, = and State 2: fully available. MSCHAPv2 password change function is = designed based on this model.
      I am not going to get into details about the three-state SA = model, but even the three-state SA model will require re-auth trigger to = be integrity protected.  
      Having said that, I think the following requirement is = sufficient for Req-4-d: =1B$B!H=1B(BThe server MUST be able to send an integrity = protected re-authentication trigger to the = client.=1B$B!I=1B(B
      Regards,
      Yoshihiro Ohba
       
       
      Hi = Alper,
      Please see inline = [TR]
       
      From: Alper Yegin [mailto:alper.yegin@yegin.org] 
      Sent: Tuesday, April 30, 2013 = 12:53 PM
      To: pcp@ietf.org
      Subject: [pcp] pcp auth = requirements
       

            c.  If a server =
wants to send an unsolicited message, but =
the
        =
        previous security =
association has expired
      "Expired" means "do not use (even if its still hanging =
around)". 
      We not only do not need to use expired SAs, but also =
using something expired in any sense is plain wrong -- unless someone =
wants to redefine what "expired" means.
       
      [TR]
      For example if we consider MSCHAPv2, there is =
configuration option where server accepts the challenge-response from =
the client even if the password is expired and allows it be changed. =

      Please =
clarify if you have some attack in mind that would cause problems using =
expired SA.
       

      Here the document is getting into some solution =
description.
      And as for such a solution:

      Instead of sending a notification that is protected with =
an expired SA to mean "re-authenticate", why not send an explicit =
message that says "re-authenticate"?
       
      [TR] 
      The client has trusted the PCP server sometime =
back using mutual authentication, so it can assume the integrity =
protected PCP response using expired SA is coming from the same PCP =
server and not from some attacker posing as PCP =
server.
      What is gained by appearing to use an expired SA (but in =
fact not really using it! because the payload of the notification is not =
consumed by the receiver).

       
       
       
      Yes, that's the solution. If the = server has something to send to the client, and there's no live SA, then = the server first needs to trigger re-auth, setup a fresh SA, then send = whatever it wants to send to the client.
       
      [TR]
       
      We have updated this requirement in the new draft, =
please have a look.
      Best =
Regards,
       
       
      Alper
       
       
       


      = --Apple-Mail=_4FDC6465-D8F4-4D49-A820-5EC9BA004793-- From alper.yegin@yegin.org Wed May 22 00:30:04 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAA521F8EB2 for ; Wed, 22 May 2013 00:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.615 X-Spam-Level: X-Spam-Status: No, score=-101.615 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_54=0.6, 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 qSzLgkiy0lEn for ; Wed, 22 May 2013 00:29:59 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC4321F8E34 for ; Wed, 22 May 2013 00:29:59 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LpKGb-1U0kvs1aKr-00fP5Z; Wed, 22 May 2013 03:29:53 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <20130522035441.GT21357@cisco.com> Date: Wed, 22 May 2013 10:29:43 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2FD4079A-749C-49E3-A13E-42B1036D5BC0@yegin.org> References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> <8AF116E2-B8E5-4228-8437-B8B4867CA6E2@yegin.org> <913383AAA69FF945B8F946018B75898A14B706A6@xmb-rcd-x10.cisco.com> <8D23D4052ABE7A4490E77B1A012B6307751AB074@mbx-01.win.nominum.com> <20130522035441.GT21357@cisco.com> To: Toerless Eckert X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:EKNIxClsVpE0tRvj9LeJiVev6Iu9Ifra4JWxQV9dOVJ RootCzhdbzjx+tOv7+jNL6Vu95qQU3lO/sV8ZqyYWO1EI+jiHt lBQdFSbVsuDnG2CGM+oK0HkBrZvSHTmYRd1HPw5L5YYnNbDxPO LAaBHV+S7gXO1hu1INH/T+/15OZRg7vAjX0dWNIeHU14mwVzjD FZAegZSRX87CZ6S0SUVSs2gkpfCfBIAJlkKyxITwe2FK42fbdw dqt6Mivv7QDcIn0rmeATv3SO3wY/psHR29DV1bJdWuwIrFXJXX q1NvPQm4GkUtC12Ej4bZT1cbQUMBajiWw1+XsRJoJY0o3Z6AUy XU8puhs3VsM/zbrT7UMuF2IkmL2/4r9+cwsBguovz3NojQxg9Z RALjqKvz+II3w== Cc: "pcp@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [pcp] pcp auth requirements 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, 22 May 2013 07:30:04 -0000 This is a long-term credential management issue, dealing with how the = credentials are installed on the end-points, and how they are = maintained. It's in-scope for architecture and product designs, but falls outside = the scope of PCP design. PCP would assume there exists long-term credentials and take it from = there. On May 22, 2013, at 6:54 AM, Toerless Eckert wrote: > I am not sure i understand all the details, but the root requirement = seems > to be that it must be possible to seamlessly maintain a PCP service in = the face > of SA's expiring. Obviously that does not mean that you need to trust = expired > SAs, but it seems to require that you have a scheme to renew SA or = swap SAs > seamlessly, right ? >=20 > Also, one related question: If the SA is based on Certificates, are = there any > epectations on how PCP should deal with expired certificates ? >=20 > I just ran into the issue that the certificates on my TivoHD expired = in february. > Of course there are no further SW updates and the certificates where = 5-years old. > In result, the SSL connections between the Tivo and my PCs failed and = i had to > hack around the PC side to permit getting the SSL connections to work = again. > And of course there is non non-SSL option to talk to the Rivo at all. >=20 > Since that experience i start seeing certificates in embedded devices = as the > superior SW technology for planned obsolescence. So much easier to = plan > than trying to find the right shabby HW components. >=20 > Of course i assume/hope that PCP would start to be used in embedded = devices in=20 > the home so i fear this is an issue that could hit PCP unless the = requirements > are set right. >=20 > Cheers > Toerless >=20 > On Tue, May 21, 2013 at 04:33:06PM -0400, Subir Das wrote: >> I agree. We should not use an expired SA. >>=20 >> -Subir >>=20 >>=20 >> On Tue, May 21, 2013 at 11:29 AM, Ted Lemon = wrote: >>=20 >>> On May 21, 2013, at 10:58 AM, "Tirumaleswar Reddy (tireddy)" < >>> tireddy@cisco.com> wrote: >>>=20 >>> would like to hear comments from others on this requirement. >>>=20 >>> >>>=20 >>> Suppose we say that reauthentication can be triggered using an = expired >>> security association. Here's how it would go: >>>=20 >>> 1. Server sends signed reauthentication request, using expired SA. >>> 2. Client gets signed request and either: >>> a. remembers the expired SA and validates the message with it >>> b. does not remember the expired SA, and can't validate the message >>>=20 >>> If b is possible, then there is no point in signing the message, = because >>> an attacker can always send a message signed with an unknown SA. = So in >>> order to get any benefit from signing a message with an expired SA, = you >>> have to require that the client retain all expired SAs, and reject = any >>> message that's signed with an unknown SA, or not signed at all. = But I >>> don't think you can do that, because now there is no way to recover = from a >>> loss of state?once either the server or the client forgets an SA, = there is >>> no way for the server to initiate communication with the client. >>>=20 >>> If that scenario is possible, I don't see any benefit to using = expired >>> SAs?I can't think of a situation where signing the message with the = expired >>> SA can be assumed to add any security at all. That being the case, = I >>> think you should just never use expired SAs. >>>=20 >>> Of course, I am not completely up to speed here, so some of the >>> assumptions I have made may be wrong. But if not, I think you = should just >>> drop this expired SA idea. >>>=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 simon.perreault@viagenie.ca Wed May 22 01:15:32 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119E521F930C for ; Wed, 22 May 2013 01:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.070, 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 yBZoemPy+Xpx for ; Wed, 22 May 2013 01:15:30 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 42E6521F92FB for ; Wed, 22 May 2013 01:15:30 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:f83b:cff2:9a05:711]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 89DBF40409 for ; Wed, 22 May 2013 04:15:29 -0400 (EDT) Message-ID: <519C7EAD.6030408@viagenie.ca> Date: Wed, 22 May 2013 10:15:41 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: pcp@ietf.org References: <45A697A8FFD7CF48BCF2BE7E106F060409089D1E@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F060409089D1E@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] Stability of external 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: Wed, 22 May 2013 08:15:32 -0000 Le 2013-05-22 06:33, Reinaldo Penno (repenno) a écrit : > I agree. I was pretty sure that at some point in the text we mentioned > that RFC4787 REQ-2 should be obeyed when assigning external address, but > scanning the text I could not find it. If we propose an errata maybe we > should reference REQ-2. Maybe you are thinking of RFC 6888 REQ-2: REQ-2: A CGN MUST have a default "IP address pooling" behavior of "Paired" (as defined in Section 4.1 of [RFC4787]). Is there any meaningful difference between that and what Stuart is suggesting? If not, then I prefer reusing RFC4787 terminology. Simon > On 5/21/13 10:59 PM, "Stuart Cheshire" wrote: > >> In some recent discussions I had, it became clear that the text below may >> be a little incomplete: >> >> The MAP and PEER requests include a Suggested External IP Address >> field. Some PCP-controlled devices, especially CGN but also multi- >> homed NPTv6 networks, have a pool of public-facing IP addresses. PCP >> allows the client to indicate if it wants a mapping assigned on a >> specific address of that pool or any address of that pool. Some >> applications will break if mappings are created on different IP >> addresses (e.g., active mode FTP), so applications should carefully >> consider the implications of using this capability. Static mappings >> for that internal address (e.g., those created by a command-line >> interface on the PCP server or PCP-controlled device) may exist to a >> certain external address, and if the suggested external IP address is >> the IPv4 or IPv6 all-zeros address, PCP SHOULD assign its mappings to >> the same external address, as this can also help applications using a >> mix of both static mappings and PCP-created mappings. If, on the >> other hand, the suggested external IP address contains a non-zero IP >> address the PCP server SHOULD create a mapping to that external >> address, even if there are other mappings from that same internal >> address to a different external address. Once an internal address >> has no implicit dynamic mappings and no explicit dynamic mappings in >> the PCP-controlled device, a subsequent implicit or explicit mapping >> for that internal address MAY be assigned to a different External >> address. Generally, this reassignment would occur when a CGN device >> is load balancing newly seen internal addresses to its public pool of >> external addresses. >> >> Specifically, it says: >> >> Once an internal address >> has no implicit dynamic mappings and no explicit dynamic mappings in >> the PCP-controlled device, a subsequent implicit or explicit mapping >> for that internal address MAY be assigned to a different External >> address. >> >> That implies the corollary: While an internal address has *some* mappings >> in the PCP-controlled device, new implicit or explicit mappings for that >> internal address SHOULD be assigned the *same* external address. >> Unfortunately, while it implies this, it does not actually state it. >> >> To clarify this I propose submitting the following erratum: >> >> Change: >> >> ... Static mappings >> for that internal address (e.g., those created by a command-line >> interface on the PCP server or PCP-controlled device) may exist to a >> certain external address, >> and if the suggested external IP address is >> the IPv4 or IPv6 all-zeros address, PCP SHOULD assign its mappings to >> the same external address, as this can also help applications using a >> mix of both static mappings and PCP-created mappings. >> >> To: >> >> ... Static mappings >> for that internal address (e.g., those created by a command-line >> interface on the PCP server or PCP-controlled device) may exist to a >> certain external address. >> If the suggested external IP address is the IPv4 or IPv6 all-zeros >> address, and the internal address currently has *any* active mappings >> (implicit, explicit, or static) with an external address of the >> indicated address family, then that external address SHOULD be used >> for the new mapping. If the existing mappings for that external >> address family do not all share a single external address, then the >> choice of which external address is assigned for the new mapping is >> implementation dependent. >> >> Comments? >> >> Do other agree that this correctly captures what we intended to say? >> >> Stuart Cheshire >> >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From yoshihiro.ohba@toshiba.co.jp Wed May 22 01:17:13 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B381A21F95D5 for ; Wed, 22 May 2013 01:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.088 X-Spam-Level: X-Spam-Status: No, score=-6.088 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 OBLzZ1it1dM6 for ; Wed, 22 May 2013 01:17:02 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 58E1021F93F6 for ; Wed, 22 May 2013 01:17:01 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r4M8GkrP012384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 May 2013 17:16:46 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r4M8Gkmn025388; Wed, 22 May 2013 17:16:46 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 812; Wed, 22 May 2013 17:16:46 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r4M8GkCv025383; Wed, 22 May 2013 17:16:46 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r4M8Gkss012227; Wed, 22 May 2013 17:16:46 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id TAA12226; Wed, 22 May 2013 17:16:46 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r4M8GjLI002932; Wed, 22 May 2013 17:16:45 +0900 (JST) Received: from tgxml329.toshiba.local by toshiba.co.jp id r4M8GjQN006069; Wed, 22 May 2013 17:16:45 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.217]) by tgxml329.toshiba.local ([133.199.60.16]) with mapi id 14.03.0123.003; Wed, 22 May 2013 17:16:45 +0900 From: To: Thread-Topic: [pcp] pcp auth requirements Thread-Index: AQHORXOMRcSeZEmOnUO6Nprz3E76X5kKtxIAgASSsTCAAQ6vgIAAo9Bw Date: Wed, 22 May 2013 08:16:44 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B12D0FD42@tgxml338.toshiba.local> References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B12D0CD38@tgxml338.toshiba.local> In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.17.69] msscp.transfermailtomossagent: 103 Content-Type: multipart/alternative; boundary="_000_674F70E5F2BE564CB06B6901FD3DD78B12D0FD42tgxml338toshiba_" MIME-Version: 1.0 Cc: pcp@ietf.org, tireddy@cisco.com Subject: Re: [pcp] pcp auth requirements 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, 22 May 2013 08:17:13 -0000 --_000_674F70E5F2BE564CB06B6901FD3DD78B12D0FD42tgxml338toshiba_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Alper, I agree that we should allow unprotected authentication trigger from the se= rver, but we should distinguish authentication after expiration of SA from = =1B$B!H=1B(Bre-authentication=1B$B!I=1B(B. Yoshihiro Ohba From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, May 22, 2013 4:22 PM To: ohba yoshihiro Cc: tireddy@cisco.com; pcp@ietf.org Subject: Re: [pcp] pcp auth requirements On May 21, 2013, at 10:14 AM, > > wrote: Tiru, In my analysis, Req-4-d-1 is basically introducing a three-state SA model f= or PCP: State 0: unavailable (or non-existent), State 1: partially availab= le only for triggering re-auth, and State 2: fully available. MSCHAPv2 pass= word change function is designed based on this model. I am not going to get into details about the three-state SA model, but even= the three-state SA model will require re-auth trigger to be integrity prot= ected. Having said that, I think the following requirement is sufficient for Req-4= -d: =1B$B!H=1B(BThe server MUST be able to send an integrity protected re-a= uthentication trigger to the client.=1B$B!I=1B(B If there is no SA available, then the server can send an un-protected re-au= th trigger. We should allow that. This is equivalent to what happens at the very beginning before the very fi= rst authentication between the client and the server. Alper Regards, Yoshihiro Ohba From: pcp-bounces@ietf.org [mailto:pcp-bounces= @ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy) Sent: Sunday, May 19, 2013 2:24 AM To: Alper Yegin; pcp@ietf.org Subject: Re: [pcp] pcp auth requirements Hi Alper, Please see inline [TR] From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Tuesday, April 30, 2013 12:53 PM To: pcp@ietf.org Subject: [pcp] pcp auth requirements c. If a server wants to send an unsolicited message, but the previous security association has expired 1. The server can continue to use the same SA to protect messages pertaining to that mapping, even if the SA is technically expired. "Expired" means "do not use (even if its still hanging around)". We not only do not need to use expired SAs, but also using something expire= d in any sense is plain wrong -- unless someone wants to redefine what "exp= ired" means. [TR] For example if we consider MSCHAPv2, there is configuration option where se= rver accepts the challenge-response from the client even if the password is= expired and allows it be changed. Please clarify if you have some attack in mind that would cause problems us= ing expired SA. [/TR] - Such server notifications will not change state in the PCP client. - The notification could be a trigger for the client to re-authenticate. Here the document is getting into some solution description. And as for such a solution: Instead of sending a notification that is protected with an expired SA to m= ean "re-authenticate", why not send an explicit message that says "re-authe= nticate"? [TR] The client has trusted the PCP server sometime back using mutual authentica= tion, so it can assume the integrity protected PCP response using expired S= A is coming from the same PCP server and not from some attacker posing as P= CP server. [/TR] What is gained by appearing to use an expired SA (but in fact not really us= ing it! because the payload of the notification is not consumed by the rece= iver). For example, if the server indicates that external IP address/port has changed, the PCP client can then re-authenticate with the server to confirm if the external IP address/port for the mapping has indeed changed. 2. The server can optionally trigger re-authentication with the client. Yes, that's the solution. If the server has something to send to the client= , and there's no live SA, then the server first needs to trigger re-auth, s= etup a fresh SA, then send whatever it wants to send to the client. [TR] We have updated this requirement in the new draft, please have a look. Best Regards, --Tiru. [/TR] Alper --_000_674F70E5F2BE564CB06B6901FD3DD78B12D0FD42tgxml338toshiba_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

      Hi Alper,

       <= /o:p>

      I agree that= we should allow unprotected authentication trigger from the server, but we= should distinguish authentication after expiration of SA from =1B$B!H=1B(Bre-authentication=1B$B!I=1B(B.

       <= /o:p>

      Yoshihiro Oh= ba

       <= /o:p>

      From: Alper Yegin [mailto:alper.yegin@yegin.org]
      Sent: Wednesday, May 22, 2013 4:22 PM
      To: ohba yoshihiro
      Cc: tireddy@cisco.com; pcp@ietf.org
      Subject: Re: [pcp] pcp auth requirements

       

       

      On May 21, 2013, at 10:14 AM, <yoshihiro.ohba@toshiba.co.jp> <yoshihiro.ohba@toshiba.co.jp<= /a>> wrote:



      Tiru,=

       

      In my analysis, Req-4-d-1 is ba= sically introducing a three-state SA model for PCP: State 0:  unavailable (or non-existent), State 1: partially available only for= triggering re-auth, and State 2: fully available. MSCHAPv2 password change= function is designed based on this model.<= /span>

       

      I am not going to get into deta= ils about the three-state SA model, but even the three-state SA model will require re-auth trigger to be integrity protected.  

       

      Having said that, I think the f= ollowing requirement is sufficient for Req-4-d: =1B$B!H=1B= (BThe server MUST be able to send an integrity protected re-authentication trigg= er to the client.=1B$B!I=1B(B

       

       

      If there is no SA available, then the server can s= end an un-protected re-auth trigger. We should allow that.

      This is equivalent to what happens at the very beg= inning before the very first authentication between the client and the serv= er.

       

      Alper

       

       

       



      Regards,

      Yoshihiro Ohba

       

       

      From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org]<= span class=3D"apple-converted-space"> On Behalf Of Tirumaleswar Reddy (tireddy) Sent: Sunday, May = 19, 2013 2:24 AM
      To: Alper Yegin; <= a href=3D"mailto:pcp@ietf.org"> pcp@ietf.org
      Subject: Re: [pcp]= pcp auth requirements

       

      Hi Alper,

       

      Please see inline [TR]=

       

      From: Alper Yegin [mailto:alper.yegin@yegin.o= rg] 
      Sent: Tuesday, Apr= il 30, 2013 12:53 PM
      To: pcp@ietf.org
      Subject: [pcp] pcp= auth requirements

       



       
        =
;    c.  If a server wants to send an unsolicited messa=
ge, but the
                previ=
ous security association has expired

       
      

                1.&nb=
sp; The server can continue to use the same SA to protect<=
o:p>
      

                =
    messages pertaining to that mapping, even if the SA is
      

                =
    technically expired.

      
      

      "Expir=
ed" means "do not use (even if its still hanging around)".&n=
bsp;
      

      We not only=
 do not need to use expired SAs, but also using something expired in any se=
nse is plain wrong -- unless someone wants to redefine what "expired&q=
uot; means.
      

       
      

      [TR]
      

      For example if we consider MSCHAPv2, there is configuration =
option where server accepts the challenge-response from the client even if =
the password is expired and allows it be changed. 
      

       
      

      Please clarify if you have some attack in mind that would ca=
use problems using expired SA.
      

       
      

      [/TR]
      

       
      

        =
;            - =
 Such server notifications will not change state in the
      

                =
       PCP client.=

      

       
      

                =
    -  The notification could be a trigger for the clie=
nt to
      

                =
       re-authenticate.  
      

      
      

      Here the do=
cument is getting into some solution description.
      

      
      

      And as for =
such a solution:
      

      
      

      Instead of =
sending a notification that is protected with an expired SA to mean "r=
e-authenticate", why not send an explicit message that says "re-a=
uthenticate"?
      

       
      

      [TR] 
      

      The client has trusted the PCP server sometime back using mu=
tual authentication, so it can assume the integrity protected PCP response =
using expired SA is coming from the same PCP server and not from some attac=
ker posing as PCP server.
      

      [/TR]
      

       
      

      What is gai=
ned by appearing to use an expired SA (but in fact not really using it! bec=
ause the payload of the notification is not consumed by the receiver).
      

      

      
      

        =
;            &n=
bsp;  For example, if the server indicates<=
/span>
      

                =
       that external IP address/port has chan=
ged, the PCP
      

                =
       client can then re-authenticate with t=
he server to
      

                =
       confirm if the external IP address/por=
t for the mapping
      

                =
       has indeed changed.<=
o:p>
      

       
      

                2.&nb=
sp; The server can optionally trigger re-authentication with
      

                =
    the client.
      

      

      

       
      

      

      

      

      

       
      

      

      

      

      

      Yes, that's the solution. If the server has something to =
send to the client, and there's no live SA, then the server
 first needs to trigger re-auth, setup a fresh SA, then send whatever it wa=
nts to send to the client.
      

      

      

       
      

      

      [TR]
      

       
      

      We have updated this requirement in the new draft, please ha=
ve a look.
      

       
      

      Best Regards,
      

      --Tiru.
      

       
      

      [/TR]
      

      

       
      

      

      

      

      

       
      

      

      

      

      

      Alper
      

      

      

      

      

       
      

      

      

      

      

       
      

      

      

      

      

       

       

      --_000_674F70E5F2BE564CB06B6901FD3DD78B12D0FD42tgxml338toshiba_-- From simon.perreault@viagenie.ca Wed May 22 01:20:40 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E993F21F936E for ; Wed, 22 May 2013 01:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.063, 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 oWaO89mQVDwU for ; Wed, 22 May 2013 01:20:37 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6E76621F925B for ; Wed, 22 May 2013 01:20:37 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:f83b:cff2:9a05:711]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A543B40409 for ; Wed, 22 May 2013 04:20:35 -0400 (EDT) Message-ID: <519C7FE0.5020605@viagenie.ca> Date: Wed, 22 May 2013 10:20:48 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: pcp@ietf.org References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] UNSUPP_FAMILY error code 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, 22 May 2013 08:20:40 -0000 Le 2013-05-22 06:35, Reinaldo Penno (repenno) a écrit : > Agreed. +1 Simon > On 5/21/13 11:08 PM, "Stuart Cheshire" wrote: > >> In prototyping some PCP server code I ran into the following situation: >> >> In a PCP request, the type of address in the Suggested External Address >> field controls whether an external IPv4 or IPv6 address is allocated. See >> page 31: >> >> if the PCP client ... wants both IPv6 and IPv4 >> listeners, it sends a MAP request containing the all-zeros IPv6 >> address in the Suggested External Address field, and sends a second >> MAP request containing the all-zeros IPv4 address in the Suggested >> External Address field >> >> A NAT gateway that only implements IPv4 can support requests for an >> external IPv4 address (::FFFF:0.0.0.0 in the Suggested External Address >> field), but not requests for an external IPv6 address (:: in the >> Suggested External Address field). >> >> Hence, it needs to return an error code if it receives a request with the >> all-zeros IPv6 address in the Suggested External Address field. >> >> What error code? The closest I can see is UNSUPP_PROTOCOL (9), but that's >> not ideal. It would be better to have an explicit code for this. I >> propose: >> >> UNSUPP_FAMILY, with value 14. >> >> Comments? >> >> Do other agree that we should have an explicit error code for this case? >> >> Stuart Cheshire >> >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From internet-drafts@ietf.org Wed May 22 02:08:07 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA5721F960E; Wed, 22 May 2013 02:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.378 X-Spam-Level: X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D55pU6gN7WdW; Wed, 22 May 2013 02:08:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE0D21F88BF; Wed, 22 May 2013 02:07:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130522090745.18579.33135.idtracker@ietfa.amsl.com> Date: Wed, 22 May 2013 02:07:45 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-nat64-prefix64-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 09:08:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Port Control Protocol Working Group of th= e IETF. Title : Learn NAT64 PREFIX64s using PCP Author(s) : Mohamed Boucadair Filename : draft-ietf-pcp-nat64-prefix64-01.txt Pages : 11 Date : 2013-05-22 Abstract: This document defines a new PCP extension to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-embedded IPv6 addresses. This extension is needed for successful communications when IPv4 addresses are used in referrals. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-nat64-prefix64 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-nat64-prefix64-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Wed May 22 02:16:25 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D576D21F9285 for ; Wed, 22 May 2013 02:16:24 -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=[AWL=0.000, 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 99zJbQZHPNKB for ; Wed, 22 May 2013 02:16:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D488721F95FB for ; Wed, 22 May 2013 02:16:18 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 2547022C9D4 for ; Wed, 22 May 2013 11:16:16 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 82E6B27C077 for ; Wed, 22 May 2013 11:16:15 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 22 May 2013 11:16:14 +0200 From: To: "pcp@ietf.org" Date: Wed, 22 May 2013 11:16:13 +0200 Thread-Topic: [pcp] I-D Action: draft-ietf-pcp-nat64-prefix64-01.txt Thread-Index: Ac5Wy+t2gHLdXEuFSQGV8NLVlzSPIQAABh0w Message-ID: <94C682931C08B048B7A8645303FDC9F36ECFB4A8FF@PUEXCB1B.nanterre.francetelecom.fr> References: <20130522090745.18579.33135.idtracker@ietfa.amsl.com> In-Reply-To: <20130522090745.18579.33135.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Subject: Re: [pcp] I-D Action: draft-ietf-pcp-nat64-prefix64-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 09:16:25 -0000 Dear all, A new version integrating the comments received during the WGLC is now avai= lable online. The main changes in this new version are: * Add a pointer to the draft-ietf-pcp-port-set as suggested by Simon * Enrich Section 3.2.2 as suggested by Iljitsch * Remove Section 3.3 * Add a new TCP example as suggested by Iljitsch * Add a reference to section 7.3 of RFC 6887 as suggested by Iljitsch * Add a security discussion on providing a fake Pref64 as suggested by Ilji= tsch * Clarify the use of multiple prefixes raised by Iljitsch Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >internet-drafts@ietf.org >Envoy=E9=A0: mercredi 22 mai 2013 11:08 >=C0=A0: i-d-announce@ietf.org >Cc=A0: pcp@ietf.org >Objet=A0: [pcp] I-D Action: draft-ietf-pcp-nat64-prefix64-01.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Port Control Protocol Working Group of >the IETF. > > Title : Learn NAT64 PREFIX64s using PCP > Author(s) : Mohamed Boucadair > Filename : draft-ietf-pcp-nat64-prefix64-01.txt > Pages : 11 > Date : 2013-05-22 > >Abstract: > This document defines a new PCP extension to learn the IPv6 > prefix(es) used by a PCP-controlled NAT64 device to build > IPv4-embedded IPv6 addresses. This extension is needed for > successful communications when IPv4 addresses are used in referrals. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-pcp-nat64-prefix64 > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-nat64-prefix64-01 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Wed May 22 02:20:03 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C2421F9600 for ; Wed, 22 May 2013 02:20:03 -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=[AWL=0.000, 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 C+Wut8Rgw+Iw for ; Wed, 22 May 2013 02:19:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id ADEE621F91B0 for ; Wed, 22 May 2013 02:19:58 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id BC592264728 for ; Wed, 22 May 2013 11:19:57 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 9F4F727C06A for ; Wed, 22 May 2013 11:19:57 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 22 May 2013 11:19:57 +0200 From: To: "pcp@ietf.org" Date: Wed, 22 May 2013 11:19:55 +0200 Thread-Topic: [pcp] I-D Action: draft-ietf-pcp-description-option-01.txt Thread-Index: Ac5V5rfMy7bDAVtKRLig6s309oMb5QA5l+1g Message-ID: <94C682931C08B048B7A8645303FDC9F36ECFB4A906@PUEXCB1B.nanterre.francetelecom.fr> References: <20130521054741.32449.41106.idtracker@ietfa.amsl.com> In-Reply-To: <20130521054741.32449.41106.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.22.80320 Subject: Re: [pcp] I-D Action: draft-ietf-pcp-description-option-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 09:20:03 -0000 Re-, This new version integrates the comments received during the WGLC. The main= changes are: * Clarify the procedure to follow to update a description * Clarify the usage of empty DESCRIPTION option * Provide a suggested max length + some editorial changes. Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >internet-drafts@ietf.org >Envoy=E9=A0: mardi 21 mai 2013 07:48 >=C0=A0: i-d-announce@ietf.org >Cc=A0: pcp@ietf.org >Objet=A0: [pcp] I-D Action: draft-ietf-pcp-description-option-01.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Port Control Protocol Working Group of >the IETF. > > Title : PCP Description Option > Author(s) : Mohamed Boucadair > Reinaldo Penno > Dan Wing > Filename : draft-ietf-pcp-description-option-01.txt > Pages : 6 > Date : 2013-05-20 > >Abstract: > This document extends Port Control Protocol (PCP) with the ability to > associate a description with a PCP-instantiated mapping. It does so > by defining a new DESCRIPTION option. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-pcp-description-option > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-pcp-description-option-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-description-option-01 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Wed May 22 02:26:52 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8A421F89FF for ; Wed, 22 May 2013 02:26:52 -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=[AWL=0.000, 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 M9FwmiUQqN67 for ; Wed, 22 May 2013 02:26:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C2BEC21F9632 for ; Wed, 22 May 2013 02:26:39 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 323983248C5 for ; Wed, 22 May 2013 11:26:39 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id DBB1735C06F for ; Wed, 22 May 2013 11:26:38 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Wed, 22 May 2013 11:26:38 +0200 From: To: "pcp@ietf.org" Date: Wed, 22 May 2013 11:26:37 +0200 Thread-Topic: draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options Thread-Index: Ac4fDoX7i8gDML59SJ+Xdp5Ie8f9FQ3v3bSw Message-ID: <94C682931C08B048B7A8645303FDC9F36ECFB4A912@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EB735607B@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB735607B@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Subject: Re: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options 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, 22 May 2013 09:26:52 -0000 Re-, Many thanks for all of you who provided a feedback for this point. As a con= clusion of this discussion, below a proposed change: OLD: 7. PCP Proxy Co-located with a NAT Function When the PCP Proxy is co-located with a NAT function, it MUST update the content of received requests with the mapped port number and the address belonging to the external interface of the PCP Proxy (i.e., after the NAT operation) and not as initially positioned by the PCP Client. For the reverse path, PCP responses MUST be updated by the PCP Proxy to replace the internal port number to what has been initially positioned by the PCP Client. For this purpose the PCP Proxy MUST have an access to the local NAT state maintained locally. Because PCP messages with an unknown OpCode or Option can carry a hidden internal address or internal port which will not be translated: o a PCP Proxy co-located with a NAT SHOULD reject by an UNSUPP_OPCODE error response a received request with an unknown OpCode; o a PCP Proxy co-located with a NAT SHOULD reject by an UNSUPP_OPTION error response a received request with a mandatory- to-process unknown Option; o a PCP Proxy co-located with a NAT MAY remove any optional-to- process unknown Options from received requests before forwarding them. Rejecting unknown Options and OpCodes has the drawback of preventing a PCP Client to make use of new capabilities offered by the PCP Server but not supported by the PCP Proxy even if no IP address and/or port is included in the Option/OpCode. NEW: 7. PCP Proxy Co-located with a NAT Function When the PCP Proxy is co-located with a NAT function, it MUST update the content of received requests with the mapped port number and the address belonging to the external interface of the PCP Proxy (i.e., after the NAT operation) and not as initially conveyed by the PCP Client. For the reverse path, PCP responses MUST be updated by the PCP Proxy to replace the internal port number to what has been initially positioned by the PCP Client. For this purpose the PCP Proxy MUST have an access to the local NAT state maintained locally. By default, the PCP Proxy MUST relay unknown OpCodes and mandatory- to-process unknown Options. Rejecting unknown Options and OpCodes has the drawback of preventing a PCP Client to make use of new capabilities offered by the PCP Server but not supported by the PCP Proxy even if no IP address and/or port is included in the Option/ OpCode. Because PCP messages with an unknown OpCode or mandatory-to-process unknown Options can carry a hidden internal address or internal port which will not be translated, A PCP Proxy MUST be configurable to disable relaying unknown OpCodes and mandatory-to-process unknown Options. If the PCP Proxy is configured to disable relaying unknown OpCodes and mandatory-to-process unknown Options, the PCP Proxy MUST behave as follows: o a PCP Proxy co-located with a NAT MUST reject by an UNSUPP_OPCODE error response a received request with an unknown OpCode. o a PCP Proxy co-located with a NAT MUST reject by an UNSUPP_OPTION error response a received request with a mandatory-to-process unknown Option. If there is no objection, this change will be include in the next version o= f the spec. Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >mohamed.boucadair@orange.com >Envoy=E9=A0: mardi 12 mars 2013 11:44 >=C0=A0: pcp@ietf.org >Objet=A0: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options > >Dear all, > >http://tools.ietf.org/html/draft-ietf-pcp-proxy-02 says: > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Because PCP messages with an unknown OpCode or Option can carry a > hidden internal address or internal port which will not be > translated: > > o a PCP Proxy co-located with a NAT SHOULD reject by an > UNSUPP_OPCODE error response a received request with an unknown > OpCode; > > o a PCP Proxy co-located with a NAT SHOULD reject by an > UNSUPP_OPTION error response a received request with a mandatory- > to-process unknown Option; > > o a PCP Proxy co-located with a NAT MAY remove any optional-to- > process unknown Options from received requests before forwarding > them. > > Rejecting unknown Options and OpCodes has the drawback of preventing > a PCP Client to make use of new capabilities offered by the PCP > Server but not supported by the PCP Proxy even if no IP address > and/or port is included in the Option/OpCode. >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >The reasoning above assumes Options which convey an IP address (and/or por= t >numbers) are naturally defined as mandatory-to-process option. > >Reinaldo suggests the following modifications to the behavior currently >defined in the I-D: > >(1) A PCP Proxy inserts a "this message was proxied" when sending back to >the client. Therefore if PCP client detects that the mappings are not >working as it should, it has a hint as to why. > >(2) The client conveys that some options in this message carry IP addresse= s >and need proxy processing (some IP addresses might not need any Proxy >processing).It does not need to say which options, a bit is fine. Therefor= e >a Proxy that could not process those options can send back a meaningful >error such as "message can not be proxied because contains options with IP >address and I do not know how" > >Any thoughts? > >Thanks. >Cheers, >Med >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From internet-drafts@ietf.org Wed May 22 04:47:38 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CED821F965A; Wed, 22 May 2013 04:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4gkKCdnVUss; Wed, 22 May 2013 04:47:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E30D21F9416; Wed, 22 May 2013 04:47:07 -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.50 Message-ID: <20130522114707.23895.32263.idtracker@ietfa.amsl.com> Date: Wed, 22 May 2013 04:47:07 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-server-selection-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 11:47:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Port Control Protocol Working Group of th= e IETF. Title : PCP Server Selection Author(s) : Mohamed Boucadair Reinaldo Penno Dan Wing Prashanth Patil Tirumaleswar Reddy Filename : draft-ietf-pcp-server-selection-01.txt Pages : 10 Date : 2013-05-22 Abstract: This document specifies the behavior to be followed by the PCP client to contact its PCP server(s) when one or several PCP server names are configured. Multiple names may be configured to a PCP client in some deployment contexts such as multi-homing. This document updates RFC6887. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-server-selection There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-server-selection-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-server-selection-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From repenno@cisco.com Wed May 22 05:50:23 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4668321F869A for ; Wed, 22 May 2013 05:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17BbOza303PW for ; Wed, 22 May 2013 05:50:17 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECC821F852D for ; Wed, 22 May 2013 05:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5503; q=dns/txt; s=iport; t=1369227017; x=1370436617; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=5uk05JD2mSRKzmzoGyDeBO2kHF18qcU10qN/4R9doUg=; b=djZcV55HGpY4UFnNf9EZJ6BqOFYty9/iDm16aCtnRPQquGhGGJoE1p80 SZc1l6YZ0ox9Bn279xImrRcOCx4PYTFRB1pWPR9LsQoFOp9o6U91q+giV FgjglB6Ikue7+UxtZX6oRp9rFvXWd44qw1HA0VfIT4l1BUcQ4rqSyhYEE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0GAJq9nFGtJXG9/2dsb2JhbABagwgwwWyBAxZ0giMBAQEEAQEBax0BCBgKSwslAgQBEgiIBQy7BwSOaTiCc2EDiGegEYMPgiY X-IronPort-AV: E=Sophos;i="4.87,719,1363132800"; d="scan'208";a="213601582" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 22 May 2013 12:50:16 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4MCoGlq024953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 May 2013 12:50:16 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Wed, 22 May 2013 07:50:16 -0500 From: "Reinaldo Penno (repenno)" To: Simon Perreault , "pcp@ietf.org" Thread-Topic: [pcp] Stability of external address Thread-Index: AQHOVpAC6bPPIl8ci0ioqstEiRhSGJkQv3wAgABwToCAABpoAA== Date: Wed, 22 May 2013 12:50:15 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F060409089F73@xmb-rcd-x04.cisco.com> In-Reply-To: <519C7EAD.6030408@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.255.204] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <102D54636ED0794496DEFB4E4BAD2F60@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Stability of external 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: Wed, 22 May 2013 12:50:23 -0000 I thinking about REQ-2 of RFC4787. REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling" behavior of "Paired". Note that this requirement is not applicable to NATs that do not support IP address pooling. On 5/22/13 5:15 AM, "Simon Perreault" wrote: >Le 2013-05-22 06:33, Reinaldo Penno (repenno) a =E9crit : >> I agree. I was pretty sure that at some point in the text we mentioned >> that RFC4787 REQ-2 should be obeyed when assigning external address, but >> scanning the text I could not find it. If we propose an errata maybe we >> should reference REQ-2. > >Maybe you are thinking of RFC 6888 REQ-2: > > REQ-2: A CGN MUST have a default "IP address pooling" behavior of > "Paired" (as defined in Section 4.1 of [RFC4787]). > >Is there any meaningful difference between that and what Stuart is >suggesting? If not, then I prefer reusing RFC4787 terminology. > >Simon > >> On 5/21/13 10:59 PM, "Stuart Cheshire" wrote: >> >>> In some recent discussions I had, it became clear that the text below >>>may >>> be a little incomplete: >>> >>> The MAP and PEER requests include a Suggested External IP Address >>> field. Some PCP-controlled devices, especially CGN but also multi- >>> homed NPTv6 networks, have a pool of public-facing IP addresses. >>>PCP >>> allows the client to indicate if it wants a mapping assigned on a >>> specific address of that pool or any address of that pool. Some >>> applications will break if mappings are created on different IP >>> addresses (e.g., active mode FTP), so applications should carefully >>> consider the implications of using this capability. Static mappings >>> for that internal address (e.g., those created by a command-line >>> interface on the PCP server or PCP-controlled device) may exist to a >>> certain external address, and if the suggested external IP address >>>is >>> the IPv4 or IPv6 all-zeros address, PCP SHOULD assign its mappings >>>to >>> the same external address, as this can also help applications using >>>a >>> mix of both static mappings and PCP-created mappings. If, on the >>> other hand, the suggested external IP address contains a non-zero IP >>> address the PCP server SHOULD create a mapping to that external >>> address, even if there are other mappings from that same internal >>> address to a different external address. Once an internal address >>> has no implicit dynamic mappings and no explicit dynamic mappings in >>> the PCP-controlled device, a subsequent implicit or explicit mapping >>> for that internal address MAY be assigned to a different External >>> address. Generally, this reassignment would occur when a CGN device >>> is load balancing newly seen internal addresses to its public pool >>>of >>> external addresses. >>> >>> Specifically, it says: >>> >>> Once an internal address >>> has no implicit dynamic mappings and no explicit dynamic mappings in >>> the PCP-controlled device, a subsequent implicit or explicit mapping >>> for that internal address MAY be assigned to a different External >>> address. >>> >>> That implies the corollary: While an internal address has *some* >>>mappings >>> in the PCP-controlled device, new implicit or explicit mappings for >>>that >>> internal address SHOULD be assigned the *same* external address. >>> Unfortunately, while it implies this, it does not actually state it. >>> >>> To clarify this I propose submitting the following erratum: >>> >>> Change: >>> >>> ... Static mappings >>> for that internal address (e.g., those created by a command-line >>> interface on the PCP server or PCP-controlled device) may exist to a >>> certain external address, >>> and if the suggested external IP address is >>> the IPv4 or IPv6 all-zeros address, PCP SHOULD assign its mappings >>>to >>> the same external address, as this can also help applications using >>>a >>> mix of both static mappings and PCP-created mappings. >>> >>> To: >>> >>> ... Static mappings >>> for that internal address (e.g., those created by a command-line >>> interface on the PCP server or PCP-controlled device) may exist to a >>> certain external address. >>> If the suggested external IP address is the IPv4 or IPv6 all-zeros >>> address, and the internal address currently has *any* active >>>mappings >>> (implicit, explicit, or static) with an external address of the >>> indicated address family, then that external address SHOULD be used >>> for the new mapping. If the existing mappings for that external >>> address family do not all share a single external address, then the >>> choice of which external address is assigned for the new mapping is >>> implementation dependent. >>> >>> Comments? >>> >>> Do other agree that this correctly captures what we intended to say? >>> >>> Stuart Cheshire >>> >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >> >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >> > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From alper.yegin@yegin.org Wed May 22 14:16:30 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CBA11E8106 for ; Wed, 22 May 2013 14:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.161 X-Spam-Level: X-Spam-Status: No, score=-102.161 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, HTML_MESSAGE=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 uJewkzMmF5Ln for ; Wed, 22 May 2013 14:16:24 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id B562D11E80A2 for ; Wed, 22 May 2013 14:16:23 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MQ2jD-1Ub7eX1rsp-004QCp; Wed, 22 May 2013 17:16:12 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_4BEC3A03-8524-43A3-8E16-EB6DCEF0465F" From: Alper Yegin In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B12D0FD42@tgxml338.toshiba.local> Date: Thu, 23 May 2013 00:16:04 +0300 Message-Id: References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B12D0CD38@tgxml338.toshiba.local> <674F70E5F2BE564CB06B6901FD3DD78B12D0FD42@tgxml338.toshiba.local> To: X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:iXhsP145DX7kclD37MTjC+LhP9Re6+dg4tLbzOqMJ5n NrLFoy0IO49paG5/sCPRPXOaNzbW9O8gC5VaWmwzlgWZIrOr43 rC5essdHoaEhF3AgYdyn6j49BpcAg6VcAaz83F50PxgBCDSow0 lFNkqAjZ1Nlb5gXbYBqkIi8A+ymZnBFx4i1b8pa0hqCZTdBs5z mSXxpCejdhSUAFXXco7a4tijafjlu82kpmksKKrfv0gU924ErU S7rqQ40mcRaFhmCxVkabdvSUVwSIGiF9z8MLPBLQDnCWve/Cir dux7IhPbQlwtBKdxLHTNwwScXqCeJcfbX72v5m1T88tL6OZxgy e5Fj92oAFLIWS5YWEd8Dqi6xfrbJxEOY3y4O25UOHpGtNQ7fM4 U2LXKBpZgv8WA== Cc: pcp@ietf.org, tireddy@cisco.com Subject: Re: [pcp] pcp auth requirements 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, 22 May 2013 21:16:30 -0000 --Apple-Mail=_4BEC3A03-8524-43A3-8E16-EB6DCEF0465F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp Hi Yoshi, Here are the three states: 0. Before PCP client and PCP server has initiated PCP session. 1. There is a PCP session and a live SA. 2. There is a PCP session, but no live SA (i.e., the last used SA is = already expired). If we execute auth in state 0, we call it "(initial) authentication". Auth executed in state 1 is called "re-authenticaiton". I'd call auth executed in state 2 a "re-authentication" as well, unless = we want to give it a more specific name. Alper On May 22, 2013, at 11:16 AM, wrote: > Hi Alper, > =20 > I agree that we should allow unprotected authentication trigger from = the server, but we should distinguish authentication after expiration of = SA from =1B$B!H=1B(Bre-authentication=1B$B!I=1B(B. > =20 > Yoshihiro Ohba > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Wednesday, May 22, 2013 4:22 PM > To: ohba yoshihiro > Cc: tireddy@cisco.com; pcp@ietf.org > Subject: Re: [pcp] pcp auth requirements > =20 > =20 > On May 21, 2013, at 10:14 AM, = wrote: >=20 >=20 > Tiru, > =20 > In my analysis, Req-4-d-1 is basically introducing a three-state SA = model for PCP: State 0: unavailable (or non-existent), State 1: = partially available only for triggering re-auth, and State 2: fully = available. MSCHAPv2 password change function is designed based on this = model. > =20 > I am not going to get into details about the three-state SA model, but = even the three-state SA model will require re-auth trigger to be = integrity protected. =20 > =20 > Having said that, I think the following requirement is sufficient for = Req-4-d: =1B$B!H=1B(BThe server MUST be able to send an integrity = protected re-authentication trigger to the client.=1B$B!I=1B(B > =20 > =20 > If there is no SA available, then the server can send an un-protected = re-auth trigger. We should allow that. > This is equivalent to what happens at the very beginning before the = very first authentication between the client and the server. > =20 > Alper > =20 > =20 > =20 >=20 >=20 > Regards, > Yoshihiro Ohba > =20 > =20 > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of = Tirumaleswar Reddy (tireddy) > Sent: Sunday, May 19, 2013 2:24 AM > To: Alper Yegin; pcp@ietf.org > Subject: Re: [pcp] pcp auth requirements > =20 > Hi Alper, > =20 > Please see inline [TR] > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Tuesday, April 30, 2013 12:53 PM > To: pcp@ietf.org > Subject: [pcp] pcp auth requirements > =20 >=20 >=20 > c. If a server wants to send an unsolicited message, but the > previous security association has expired > =20 > 1. The server can continue to use the same SA to protect > messages pertaining to that mapping, even if the SA is > technically expired. >=20 > "Expired" means "do not use (even if its still hanging around)".=20 > We not only do not need to use expired SAs, but also using something = expired in any sense is plain wrong -- unless someone wants to redefine = what "expired" means. > =20 > [TR] > For example if we consider MSCHAPv2, there is configuration option = where server accepts the challenge-response from the client even if the = password is expired and allows it be changed.=20 > =20 > Please clarify if you have some attack in mind that would cause = problems using expired SA. > =20 > [/TR] > =20 > - Such server notifications will not change state in = the > PCP client. > =20 > - The notification could be a trigger for the client to > re-authenticate. =20 >=20 > Here the document is getting into some solution description. >=20 > And as for such a solution: >=20 > Instead of sending a notification that is protected with an expired SA = to mean "re-authenticate", why not send an explicit message that says = "re-authenticate"? > =20 > [TR]=20 > The client has trusted the PCP server sometime back using mutual = authentication, so it can assume the integrity protected PCP response = using expired SA is coming from the same PCP server and not from some = attacker posing as PCP server. > [/TR] > =20 > What is gained by appearing to use an expired SA (but in fact not = really using it! because the payload of the notification is not consumed = by the receiver). >=20 >=20 > For example, if the server indicates > that external IP address/port has changed, the PCP > client can then re-authenticate with the server to > confirm if the external IP address/port for the = mapping > has indeed changed. > =20 > 2. The server can optionally trigger re-authentication with > the client. > =20 > =20 > Yes, that's the solution. If the server has something to send to the = client, and there's no live SA, then the server first needs to trigger = re-auth, setup a fresh SA, then send whatever it wants to send to the = client. > =20 > [TR] > =20 > We have updated this requirement in the new draft, please have a look. > =20 > Best Regards, > --Tiru. > =20 > [/TR] > =20 > =20 > Alper > =20 > =20 > =20 --Apple-Mail=_4BEC3A03-8524-43A3-8E16-EB6DCEF0465F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-2022-jp Hi Yoshi,

      Here are the three = states:

      0. Before PCP client and PCP server has = initiated PCP session.

      1. There is a PCP = session and a live SA.

      2. There is a PCP = session, but no live SA (i.e., the last used SA is already = expired).


      If we execute auth in = state 0, we call it "(initial) authentication".
      Auth executed = in state 1 is called "re-authenticaiton".
      I'd call auth = executed in state 2 a "re-authentication" as well, unless we want to = give it a more specific = name.

      Alper




      On May 22, 2013, at 11:16 AM, <yoshihiro.ohba@toshiba.co.jp<= /a>> wrote:

      Hi Alper,
      I agree that we should allow unprotected = authentication trigger from the server, but we should distinguish = authentication after expiration of SA from = =1B$B!H=1B(Bre-authentication=1B$B!I=1B(B.
      Yoshihiro Ohba
       
       
      On May 21, 2013, at = 10:14 AM, <yoshihiro.ohba@toshiba.co.jp> = wrote:


      In my = analysis, Req-4-d-1 is basically introducing a three-state SA model for = PCP: State 0:  unavailable (or non-existent), State 1: partially = available only for triggering re-auth, and State 2: fully available. = MSCHAPv2 password change function is designed based on this = model.
      I am = not going to get into details about the three-state SA model, but even = the three-state SA model will require re-auth trigger to be integrity = protected.  
      Having = said that, I think the following requirement is sufficient for = Req-4-d:=1B$B!H=1B(BThe server MUST be able to send an integrity protected = re-authentication trigger to the client.=1B$B!I=1B(B  
      If there is no SA = available, then the server can send an un-protected re-auth trigger. We = should allow that.
      This is equivalent = to what happens at the very beginning before the very first = authentication between the client and the = server.
       
      Alper
       
       
       


       pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy = (tireddy)
      Sent: Sunday, May 19, 2013 2:24 = AM
      To: Alper = Yegin; pcp@ietf.org
      Subject: Re: [pcp] pcp auth = requirements
       
      Hi Alper,
      Please see inline [TR]
       Alper Yegin [mailto:alper.yegin@yegin.org] 
      Sent: Tuesday, April 30, 2013 = 12:53 PM
      To: pcp@ietf.org
      Subject: [pcp] pcp auth = requirements
       

        =
        previous security =
association has expired

      "Expired" means "do = not use (even if its still hanging around)". We not only do not need to use expired SAs, but = also using something expired in any sense is plain wrong -- unless = someone wants to redefine what "expired" means. [TR]For example if we consider MSCHAPv2, = there is configuration option where server accepts the = challenge-response from the client even if the password is expired and = allows it be changed. 
       

      Here the document is getting into some =
solution description.

      And as for such a =
solution:
      Instead of sending =
a notification that is protected with an expired SA to mean =
"re-authenticate", why not send an explicit message that says =
"re-authenticate"?
      [TR] =

      The client has =
trusted the PCP server sometime back using mutual authentication, so it =
can assume the integrity protected PCP response using expired SA is =
coming from the same PCP server and not from some attacker posing as PCP =
server.
      What is gained by =
appearing to use an expired SA (but in fact not really using it! because =
the payload of the notification is not consumed by the =
receiver).

       
       
       
      Yes, that's the solution. If the server has something to send = to the client, and there's no live SA, then the server first needs to = trigger re-auth, setup a fresh SA, then send whatever it wants to send = to the client.
      [TR] We have updated this requirement in the = new draft, please have a look. Best Regards,--Tiru. [/TR]
       
      Alper
       
       
       


      = = --Apple-Mail=_4BEC3A03-8524-43A3-8E16-EB6DCEF0465F-- From yoshihiro.ohba@toshiba.co.jp Wed May 22 15:39:59 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A129D11E814B for ; Wed, 22 May 2013 15:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.088 X-Spam-Level: X-Spam-Status: No, score=-7.088 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2phUxo8wIU8Y for ; Wed, 22 May 2013 15:39:52 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 9A87E21F85DC for ; Wed, 22 May 2013 15:39:51 -0700 (PDT) Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id r4MMdkGk019027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 May 2013 07:39:46 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r4MMdjES032450; Thu, 23 May 2013 07:39:45 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 699; Thu, 23 May 2013 07:39:45 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r4MMdjeB032444; Thu, 23 May 2013 07:39:45 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id r4MMdjDv003516; Thu, 23 May 2013 07:39:45 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id HAA03514; Thu, 23 May 2013 07:39:45 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id r4MMdjId025828; Thu, 23 May 2013 07:39:45 +0900 (JST) Received: from tgxml345.toshiba.local by toshiba.co.jp id r4MMdid3024770; Thu, 23 May 2013 07:39:44 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.217]) by tgxml345.toshiba.local ([133.199.60.32]) with mapi id 14.03.0123.003; Thu, 23 May 2013 07:39:44 +0900 From: To: Thread-Topic: [pcp] pcp auth requirements Thread-Index: AQHORXOMRcSeZEmOnUO6Nprz3E76X5kKtxIAgASSsTCAAQ6vgIAAo9BwgABFGQCAAKzlsA== Date: Wed, 22 May 2013 22:39:43 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B12D1002A@tgxml338.toshiba.local> References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B12D0CD38@tgxml338.toshiba.local> <674F70E5F2BE564CB06B6901FD3DD78B12D0FD42@tgxml338.toshiba.local> In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.16.114] msscp.transfermailtomossagent: 103 Content-Type: multipart/alternative; boundary="_000_674F70E5F2BE564CB06B6901FD3DD78B12D1002Atgxml338toshiba_" MIME-Version: 1.0 Cc: pcp@ietf.org, tireddy@cisco.com Subject: Re: [pcp] pcp auth requirements 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, 22 May 2013 22:39:59 -0000 --_000_674F70E5F2BE564CB06B6901FD3DD78B12D1002Atgxml338toshiba_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Alper, When we talk about re-authentication, we should not care about whether ther= e is a PCP session or not. Please see the following definition in RFC 5247: =1B$B!H=1B(B EAP Re-Authentication EAP authentication between an EAP peer and a server with whom the EAP peer shares valid unexpired EAP keying material. =1B$B!H=1B(B According to the above definition, if authentication is conducted over a li= ve SA, it is re-authentication, otherwise it is not re-authentication. Yoshihiro Ohba From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Thursday, May 23, 2013 6:16 AM To: ohba yoshihiro Cc: tireddy@cisco.com; pcp@ietf.org Subject: Re: [pcp] pcp auth requirements Hi Yoshi, Here are the three states: 0. Before PCP client and PCP server has initiated PCP session. 1. There is a PCP session and a live SA. 2. There is a PCP session, but no live SA (i.e., the last used SA is alread= y expired). If we execute auth in state 0, we call it "(initial) authentication". Auth executed in state 1 is called "re-authenticaiton". I'd call auth executed in state 2 a "re-authentication" as well, unless we = want to give it a more specific name. Alper On May 22, 2013, at 11:16 AM, > wrote: Hi Alper, I agree that we should allow unprotected authentication trigger from the se= rver, but we should distinguish authentication after expiration of SA from = =1B$B!H=1B(Bre-authentication=1B$B!I=1B(B. Yoshihiro Ohba From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, May 22, 2013 4:22 PM To: ohba yoshihiro Cc: tireddy@cisco.com; pcp@ietf.org Subject: Re: [pcp] pcp auth requirements On May 21, 2013, at 10:14 AM, > > wrote: Tiru, In my analysis, Req-4-d-1 is basically introducing a three-state SA model f= or PCP: State 0: unavailable (or non-existent), State 1: partially availab= le only for triggering re-auth, and State 2: fully available. MSCHAPv2 pass= word change function is designed based on this model. I am not going to get into details about the three-state SA model, but even= the three-state SA model will require re-auth trigger to be integrity prot= ected. Having said that, I think the following requirement is sufficient for Req-4= -d: =1B$B!H=1B(BThe server MUST be able to send an integrity protected re-a= uthentication trigger to the client.=1B$B!I=1B(B If there is no SA available, then the server can send an un-protected re-au= th trigger. We should allow that. This is equivalent to what happens at the very beginning before the very fi= rst authentication between the client and the server. Alper Regards, Yoshihiro Ohba From: pcp-bounces@ietf.org [mailto:pcp-bounces= @ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy) Sent: Sunday, May 19, 2013 2:24 AM To: Alper Yegin; pcp@ietf.org Subject: Re: [pcp] pcp auth requirements Hi Alper, Please see inline [TR] From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Tuesday, April 30, 2013 12:53 PM To: pcp@ietf.org Subject: [pcp] pcp auth requirements c. If a server wants to send an unsolicited message, but the previous security association has expired 1. The server can continue to use the same SA to protect messages pertaining to that mapping, even if the SA is technically expired. "Expired" means "do not use (even if its still hanging around)". We not only do not need to use expired SAs, but also using something expire= d in any sense is plain wrong -- unless someone wants to redefine what "exp= ired" means. [TR] For example if we consider MSCHAPv2, there is configuration option where se= rver accepts the challenge-response from the client even if the password is= expired and allows it be changed. Please clarify if you have some attack in mind that would cause problems us= ing expired SA. [/TR] - Such server notifications will not change state in the PCP client. - The notification could be a trigger for the client to re-authenticate. Here the document is getting into some solution description. And as for such a solution: Instead of sending a notification that is protected with an expired SA to m= ean "re-authenticate", why not send an explicit message that says "re-authe= nticate"? [TR] The client has trusted the PCP server sometime back using mutual authentica= tion, so it can assume the integrity protected PCP response using expired S= A is coming from the same PCP server and not from some attacker posing as P= CP server. [/TR] What is gained by appearing to use an expired SA (but in fact not really us= ing it! because the payload of the notification is not consumed by the rece= iver). For example, if the server indicates that external IP address/port has changed, the PCP client can then re-authenticate with the server to confirm if the external IP address/port for the mapping has indeed changed. 2. The server can optionally trigger re-authentication with the client. Yes, that's the solution. If the server has something to send to the client= , and there's no live SA, then the server first needs to trigger re-auth, s= etup a fresh SA, then send whatever it wants to send to the client. [TR] We have updated this requirement in the new draft, please have a look. Best Regards, --Tiru. [/TR] Alper --_000_674F70E5F2BE564CB06B6901FD3DD78B12D1002Atgxml338toshiba_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

      Hi Alper,

       <= /o:p>

      When we talk= about re-authentication, we should not care about whether there is a PCP s= ession or not.

       <= /o:p>

      Please see t= he following definition in RFC 5247:

      =1B$B!H=1B(B=

        = EAP Re-Authentication

        =     EAP authentication between an EAP peer and a server with= whom the

        =     EAP peer shares valid unexpired EAP keying material.

      =1B$B!H=1B(B=

       <= /o:p>

      According to= the above definition, if authentication is conducted over a live SA, it is= re-authentication, otherwise it is not re-authentication.

       <= /o:p>

      Yoshihiro Oh= ba

       <= /o:p>

       <= /o:p>

      From: Alper Yegin [mailto:alper.yegin@yegin.org]
      Sent: Thursday, May 23, 2013 6:16 AM
      To: ohba yoshihiro
      Cc: tireddy@cisco.com; pcp@ietf.org
      Subject: Re: [pcp] pcp auth requirements

       

      Hi Yoshi,

       

      Here are the three states:

       

      0. Before PCP client and PCP server has initiated = PCP session.

       

      1. There is a PCP session and a live SA.

       

      2. There is a PCP session, but no live SA (i.e., t= he last used SA is already expired).

       

       

      If we execute auth in state 0, we call it "(i= nitial) authentication".

      Auth executed in state 1 is called "re-authen= ticaiton".

      I'd call auth executed in state 2 a "re-authe= ntication" as well, unless we want to give it a more specific name.

       

      Alper

       

       

       

       

      On May 22, 2013, at 11:16 AM, <yoshihiro.ohba@toshiba.co.jp> wrote:=



      Hi Alper,

       

      I agree that we should allow un= protected authentication trigger from the server, but we should distinguish authentication after expiration of SA from =1B$B!H=1B(Bre-auth= entication=1B$B!I=1B(B.

       

      Yoshihiro Ohba

       

      From: Alper Yegin [mailto:alper.yegin@yegin.o= rg] 
      Sent: Wednesday, M= ay 22, 2013 4:22 PM
      To: ohba yoshihiro=
      Cc: tireddy@cisco.com; pcp@ietf.org
      Subject: Re: [pcp]= pcp auth requirements

       

       

      On May 21, 2013, at 10:14 AM, <yoshihiro.ohba@toshiba.co.jp> <yoshihiro.ohba@toshiba.co.jp<= /a>> wrote:




      Tiru,

       

      In my analysis, Req-4-d-1 is ba= sically introducing a three-state SA model for PCP: State 0:  unavailable (or non-existent), State 1: partially available only for= triggering re-auth, and State 2: fully available. MSCHAPv2 password change= function is designed based on this model.=

       

      I am not going to get into deta= ils about the three-state SA model, but even the three-state SA model will require re-auth trigger to be integrity protected.  

       

      Having said that, I think the f= ollowing requirement is sufficient for Req-4-d: =1B$B!H=1B= (BThe server MUST be able to send an integrity protected re-authentication trigg= er to the client.=1B$B!I=1B(B=

       

       

      If there is no SA available, then the server can s= end an un-protected re-auth trigger. We should allow that.

      This is equivalent to what happens at the very beg= inning before the very first authentication between the client and the serv= er.

       

      Alper

       

       

       




      Regards,

      Yoshihiro Ohba

       

       

      From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Tirumalesw= ar Reddy (tireddy)
      Sent: Sunday, May = 19, 2013 2:24 AM
      To: Alper Yegin;       pcp@ietf.org
      Subject: Re: [pcp]= pcp auth requirements

       

      Hi Alper,

       

      Please see inline [TR]=

       

      From: Alper Yegin [mailto:alper.yegin@yegin.o= rg] 
      Sent: Tuesday, Apr= il 30, 2013 12:53 PM
      To: pcp@ietf.org
      Subject: [pcp] pcp= auth requirements

       



       
       &nb=
sp;    c.  If a server wants to send an unsolicited mes=
sage, but the
                pre=
vious security association has expired
       
                1.&=
nbsp; The server can continue to use the same SA to protect
               &nbs=
p;    messages pertaining to that mapping, even if the SA is=

               &nbs=
p;    technically expired.<=
/o:p>

       
      "Exp=
ired" means "do not use (even if its still hanging around)".=
 
      We not on=
ly do not need to use expired SAs, but also using something expired in any =
sense is plain wrong -- unless someone wants to redefine what "expired=
" means.
       
      [TR]
      For example if we consider MSCHAPv2, there is configuratio=
n option where server accepts the challenge-response from the client even i=
f the password is expired and allows it be changed. 
       
      Please clarify if you have some attack in mind that would =
cause problems using expired SA.
       
      [/TR]
       
       &nb=
sp;            -&nbs=
p; Such server notifications will not change state in the
               &nbs=
p;       PCP client.
       
               &nbs=
p;    -  The notification could be a trigger for the cl=
ient to
               &nbs=
p;       re-authenticate.  

       
      Here the =
document is getting into some solution description.

       
      And as fo=
r such a solution:

       
      Instead o=
f sending a notification that is protected with an expired SA to mean "=
;re-authenticate", why not send an explicit message that says "re=
-authenticate"?
       
      [TR] 
      The client has trusted the PCP server sometime back using =
mutual authentication, so it can assume the integrity protected PCP respons=
e using expired SA is coming from the same PCP server and not from some att=
acker posing as PCP server.

      [/TR]
      

       
      

      What is g=
ained by appearing to use an expired SA (but in fact not really using it! b=
ecause the payload of the notification is not consumed by the receiver).
      

      

      
      

       &nb=
sp;            =
   For example, if the server indicates
      

               &nbs=
p;       that external IP address/port has ch=
anged, the PCP
      

               &nbs=
p;       client can then re-authenticate with=
 the server to
      

               &nbs=
p;       confirm if the external IP address/p=
ort for the mapping
      

               &nbs=
p;       has indeed changed.
      

       
      

                2.&=
nbsp; The server can optionally trigger re-authentication with
      

               &nbs=
p;    the client.
      

      

      

      

       
      

      

      

      

      

      

      

       
      

      

      

      

      

      

      

      Yes, that's the solution. If the server has something to =
send to the client, and there's no live SA, then the server
 first needs to trigger re-auth, setup a fresh SA, then send whatever it wa=
nts to send to the client.

      

      

      

      

       
      

      

      

      [TR]
      

       
      

      We have updated this requirement in the new draft, please =
have a look.
      

       
      

      Best Regards,
      

      --Tiru.

       
      

      [/TR]
      

      

      

       
      

      

      

      

      

      

      

       
      

      

      

      

      

      

      

      Alper
      

      

      

      

      

      

      

       
      

      

      

      

      

      

      

       
      

      

      

      

      

      

      

       

       

      --_000_674F70E5F2BE564CB06B6901FD3DD78B12D1002Atgxml338toshiba_-- From internet-drafts@ietf.org Wed May 22 23:13:27 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A5911E80FE; Wed, 22 May 2013 23:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDwsk8+0ufvg; Wed, 22 May 2013 23:13:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8007B21F96BE; Wed, 22 May 2013 23:13:02 -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.50 Message-ID: <20130523061302.24784.77892.idtracker@ietfa.amsl.com> Date: Wed, 22 May 2013 23:13:02 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-nat64-prefix64-02.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 06:13:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Port Control Protocol Working Group of th= e IETF. Title : Learn NAT64 PREFIX64s using PCP Author(s) : Mohamed Boucadair Filename : draft-ietf-pcp-nat64-prefix64-02.txt Pages : 12 Date : 2013-05-22 Abstract: This document defines a new PCP extension to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-embedded IPv6 addresses. This extension is needed for successful communications when IPv4 addresses are used in referrals. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-nat64-prefix64 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-nat64-prefix64-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Wed May 22 23:22:01 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F057211E80FB for ; Wed, 22 May 2013 23:22:00 -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=[AWL=0.000, 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 0JTKi5PNiRFP for ; Wed, 22 May 2013 23:21:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 85B1A21F969D for ; Wed, 22 May 2013 23:21:56 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 677063B49CF for ; Thu, 23 May 2013 08:21:51 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 5125A35C045 for ; Thu, 23 May 2013 08:21:51 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 23 May 2013 08:21:51 +0200 From: To: "pcp@ietf.org" Date: Thu, 23 May 2013 08:21:48 +0200 Thread-Topic: [pcp] I-D Action: draft-ietf-pcp-nat64-prefix64-02.txt Thread-Index: Ac5XfK8HYfwU9+KWRgKL5eTTjp+NwAAALcNg Message-ID: <94C682931C08B048B7A8645303FDC9F36ED1F52569@PUEXCB1B.nanterre.francetelecom.fr> References: <20130523061302.24784.77892.idtracker@ietfa.amsl.com> In-Reply-To: <20130523061302.24784.77892.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.23.42718 Subject: Re: [pcp] I-D Action: draft-ietf-pcp-nat64-prefix64-02.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 06:22:01 -0000 Dear all, This version integrates some comments I received offline. The main changes = are: * clarify both WKP and NSP can be returned in the PREFIX64 option * clarify the behavior when PREFIX64 option is enabled but no Pref64 is con= figured * clarify the behavior when an new Pref64 is configured to the PCP server * Add some text on DNSSEC in the security considerations section. Cheers, Med >-----Message d'origine----- >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de >internet-drafts@ietf.org >Envoy=E9=A0: jeudi 23 mai 2013 08:13 >=C0=A0: i-d-announce@ietf.org >Cc=A0: pcp@ietf.org >Objet=A0: [pcp] I-D Action: draft-ietf-pcp-nat64-prefix64-02.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Port Control Protocol Working Group of >the IETF. > > Title : Learn NAT64 PREFIX64s using PCP > Author(s) : Mohamed Boucadair > Filename : draft-ietf-pcp-nat64-prefix64-02.txt > Pages : 12 > Date : 2013-05-22 > >Abstract: > This document defines a new PCP extension to learn the IPv6 > prefix(es) used by a PCP-controlled NAT64 device to build > IPv4-embedded IPv6 addresses. This extension is needed for > successful communications when IPv4 addresses are used in referrals. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-pcp-nat64-prefix64 > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-nat64-prefix64-02 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From alper.yegin@yegin.org Wed May 22 23:47:46 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8A411E819E for ; Wed, 22 May 2013 23:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.248 X-Spam-Level: X-Spam-Status: No, score=-102.248 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=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 D0bHAefNgIQT for ; Wed, 22 May 2013 23:47:40 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 776F311E819D for ; Wed, 22 May 2013 23:47:40 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Mdruv-1Up4uM2iVx-00PaQ0; Thu, 23 May 2013 02:47:38 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_9167EBBE-775C-4106-B8CA-CF05EF50E059" From: Alper Yegin In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B12D1002A@tgxml338.toshiba.local> Date: Thu, 23 May 2013 09:47:29 +0300 Message-Id: References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B12D0CD38@tgxml338.toshiba.local> <674F70E5F2BE564CB06B6901FD3DD78B12D0FD42@tgxml338.toshiba.local> <674F70E5F2BE564CB06B6901FD3DD78B12D1002A@tgxml338.toshiba.local> To: X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:lgZRbuX1iUKQg7ctXYstoRBv9F0Odb3Ybc5qCT3y2xl Ruovr9mrPenqcsYmltNDCEcc6tTkcDeBehfgs0/EvrVl1gk/U3 h4DyKrlvK1VcMRazt+eumJilFG8SJzszOcq65RFq7+Lc6HScgr qScMuUzcJsqBokqK2Lm31u5GiX3CTrLFUuFSXfcxRMNAnu81oN LPrMfikpoyNawhubw28WycyeUt5qt4W4RxEq5Y4YYZ+U1d54cr 5lXD9KzG6bRMeMWEof9fk8AuS2q9hFq8IU9oeE/RrOpAR9B9EM 9bmZTwvqBG0KmHCOA66sXGKDMs4g9/pS6bX4rlSaxQFwKtpjYA osr9hLXfvuHQUVwBSkgkPyCYCElL8xQ2/TcGsXJ3Gloptrs40V XUD1PsnsNTM1Q== Cc: pcp@ietf.org, tireddy@cisco.com Subject: Re: [pcp] pcp auth requirements 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, 23 May 2013 06:47:46 -0000 --Apple-Mail=_9167EBBE-775C-4106-B8CA-CF05EF50E059 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp Yoshi, You are right. In terms of EAP and RFC 5247, only the second case = qualifies for "EAP re-authentication". On the other hand, first and third case are not the same.=20 And I'd conceptually think of the third case as a some sort of = "re-authentication" (apparently not an "EAP re-authentication" per RFC = 5247). Anyways, at least I'd like people to be aware of these three different = cases -- even if we cannot find a proper name to all of them. Alper On May 23, 2013, at 1:39 AM, wrote: > Hi Alper, > =20 > When we talk about re-authentication, we should not care about whether = there is a PCP session or not. > =20 > Please see the following definition in RFC 5247: > =1B$B!H=1B(B > EAP Re-Authentication > EAP authentication between an EAP peer and a server with whom = the > EAP peer shares valid unexpired EAP keying material. > =1B$B!H=1B(B > =20 > According to the above definition, if authentication is conducted over = a live SA, it is re-authentication, otherwise it is not = re-authentication. > =20 > Yoshihiro Ohba > =20 > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Thursday, May 23, 2013 6:16 AM > To: ohba yoshihiro > Cc: tireddy@cisco.com; pcp@ietf.org > Subject: Re: [pcp] pcp auth requirements > =20 > Hi Yoshi, > =20 > Here are the three states: > =20 > 0. Before PCP client and PCP server has initiated PCP session. > =20 > 1. There is a PCP session and a live SA. > =20 > 2. There is a PCP session, but no live SA (i.e., the last used SA is = already expired). > =20 > =20 > If we execute auth in state 0, we call it "(initial) authentication". > Auth executed in state 1 is called "re-authenticaiton". > I'd call auth executed in state 2 a "re-authentication" as well, = unless we want to give it a more specific name. > =20 > Alper > =20 > =20 > =20 > =20 > On May 22, 2013, at 11:16 AM, wrote: >=20 >=20 > Hi Alper, > =20 > I agree that we should allow unprotected authentication trigger from = the server, but we should distinguish authentication after expiration of = SA from =1B$B!H=1B(Bre-authentication=1B$B!I=1B(B. > =20 > Yoshihiro Ohba > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Wednesday, May 22, 2013 4:22 PM > To: ohba yoshihiro > Cc: tireddy@cisco.com; pcp@ietf.org > Subject: Re: [pcp] pcp auth requirements > =20 > =20 > On May 21, 2013, at 10:14 AM, = wrote: >=20 >=20 >=20 > Tiru, > =20 > In my analysis, Req-4-d-1 is basically introducing a three-state SA = model for PCP: State 0: unavailable (or non-existent), State 1: = partially available only for triggering re-auth, and State 2: fully = available. MSCHAPv2 password change function is designed based on this = model. > =20 > I am not going to get into details about the three-state SA model, but = even the three-state SA model will require re-auth trigger to be = integrity protected. =20 > =20 > Having said that, I think the following requirement is sufficient for = Req-4-d: =1B$B!H=1B(BThe server MUST be able to send an integrity = protected re-authentication trigger to the client.=1B$B!I=1B(B > =20 > =20 > If there is no SA available, then the server can send an un-protected = re-auth trigger. We should allow that. > This is equivalent to what happens at the very beginning before the = very first authentication between the client and the server. > =20 > Alper > =20 > =20 > =20 >=20 >=20 >=20 > Regards, > Yoshihiro Ohba > =20 > =20 > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of = Tirumaleswar Reddy (tireddy) > Sent: Sunday, May 19, 2013 2:24 AM > To: Alper Yegin; pcp@ietf.org > Subject: Re: [pcp] pcp auth requirements > =20 > Hi Alper, > =20 > Please see inline [TR] > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Tuesday, April 30, 2013 12:53 PM > To: pcp@ietf.org > Subject: [pcp] pcp auth requirements > =20 >=20 >=20 > c. If a server wants to send an unsolicited message, but the > previous security association has expired > =20 > 1. The server can continue to use the same SA to protect > messages pertaining to that mapping, even if the SA is > technically expired. >=20 > "Expired" means "do not use (even if its still hanging around)".=20 > We not only do not need to use expired SAs, but also using something = expired in any sense is plain wrong -- unless someone wants to redefine = what "expired" means. > =20 > [TR] > For example if we consider MSCHAPv2, there is configuration option = where server accepts the challenge-response from the client even if the = password is expired and allows it be changed.=20 > =20 > Please clarify if you have some attack in mind that would cause = problems using expired SA. > =20 > [/TR] > =20 > - Such server notifications will not change state in = the > PCP client. > =20 > - The notification could be a trigger for the client to > re-authenticate. =20 >=20 > Here the document is getting into some solution description. >=20 > And as for such a solution: >=20 > Instead of sending a notification that is protected with an expired SA = to mean "re-authenticate", why not send an explicit message that says = "re-authenticate"? > =20 > [TR]=20 > The client has trusted the PCP server sometime back using mutual = authentication, so it can assume the integrity protected PCP response = using expired SA is coming from the same PCP server and not from some = attacker posing as PCP server. > [/TR] > =20 > What is gained by appearing to use an expired SA (but in fact not = really using it! because the payload of the notification is not consumed = by the receiver). >=20 >=20 > For example, if the server indicates > that external IP address/port has changed, the PCP > client can then re-authenticate with the server to > confirm if the external IP address/port for the = mapping > has indeed changed. > =20 > 2. The server can optionally trigger re-authentication with > the client. > =20 > =20 > Yes, that's the solution. If the server has something to send to the = client, and there's no live SA, then the server first needs to trigger = re-auth, setup a fresh SA, then send whatever it wants to send to the = client. > =20 > [TR] > =20 > We have updated this requirement in the new draft, please have a look. > =20 > Best Regards, > --Tiru. > =20 > [/TR] > =20 > =20 > Alper > =20 > =20 > =20 --Apple-Mail=_9167EBBE-775C-4106-B8CA-CF05EF50E059 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-2022-jp Yoshi,

      You are right. In terms = of EAP and RFC 5247, only the second case qualifies for "EAP = re-authentication".

      On the other hand, first = and third case are not the same. 
      And I'd conceptually = think of the third case as a some sort of "re-authentication" = (apparently not an "EAP re-authentication" per RFC = 5247).

      Anyways, at least I'd like people to be = aware of these three different cases -- even if we cannot find a proper = name to all of = them.

      Alper



      On May 23, 2013, at 1:39 AM, <yoshihiro.ohba@toshiba.co.jp<= /a>> wrote:

      Hi Alper,
      When we talk about re-authentication, we = should not care about whether there is a PCP session or = not.
       
      Please see = the following definition in RFC 5247:
         EAP = Re-Authentication
            EAP = authentication between an EAP peer and a server with whom = the
            EAP peer shares valid = unexpired EAP keying material.
       
      According to = the above definition, if authentication is conducted over a live SA, it = is re-authentication, otherwise it is not = re-authentication.
       
      Yoshihiro = Ohba
       
       
      Hi = Yoshi,
       
      Here are the three = states:
       
      0. Before PCP client and = PCP server has initiated PCP = session.
       
      1. There is a PCP session = and a live SA.
       
      2. There is a PCP session, = but no live SA (i.e., the last used SA is already = expired).
       
       
      If we execute auth in = state 0, we call it "(initial) = authentication".
      Auth executed in state 1 = is called "re-authenticaiton".
      I'd call auth executed in = state 2 a "re-authentication" as well, unless we want to give it a more = specific name.
       
      Alper
       
       
       
       
      On May 22, 2013, at 11:16 = AM, <yoshihiro.ohba@toshiba.co.jp> = wrote:


      Hi = Alper,
      I agree that = we should allow unprotected authentication trigger from the server, but = we should distinguish authentication after expiration of SA from = =1B$B!H=1B(Bre-authentication=1B$B!I=1B(B.
      Yoshihiro = Ohba
      From: Alper Yegin [ 
      Sent: Wednesday, May 22, 2013 = 4:22 PM
      To: ohba = yoshihiro
      Cc:       tireddy@cisco.com; pcp@ietf.org
      Subject: Re: [pcp] pcp auth = requirements
       
       
      On May 21, 2013, at 10:14 AM, <yoshihiro.ohba@toshiba.co.jp> = <yoshihiro.ohba@toshiba.co.jp> = wrote:



      Tiru,
       
      In my analysis, Req-4-d-1 is = basically introducing a three-state SA model for PCP: State 0: =  unavailable (or non-existent), State 1: partially available only = for triggering re-auth, and State 2: fully available. MSCHAPv2 password = change function is designed based on this model.
       
      I am not going to get into = details about the three-state SA model, but even the three-state SA = model will require re-auth trigger to be integrity protected. =  
       
      Having said that, I think the = following requirement is sufficient for Req-4-d: =1B$B!H=1B(BThe server MUST be able to send = an integrity protected re-authentication trigger to the = client.=1B$B!I=1B(B
       
       
      If there is no SA available, then the server can = send an un-protected re-auth trigger. We should allow = that.
      This is equivalent to = what happens at the very beginning before the very first authentication = between the client and the = server.
       
      Alper
       
       
       



      Regards,
      Yoshihiro Ohba
       
       
      From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy = (tireddy)
      Sent: Sunday, May 19, 2013 2:24 = AM
      To: Alper = Yegin; pcp@ietf.org
      Subject: Re: [pcp] pcp auth = requirements
       
      Hi = Alper,
      Please see = inline [TR]
      From: Alper Yegin [ 
      Sent: Tuesday, April 30, 2013 = 12:53 PM
      To:       pcp@ietf.org
      Subject: [pcp] pcp auth = requirements
     

      =
        previous security =
association has expired
     
    "Expired" means "do =
not use (even if its still hanging around)". 
    We not only do not need to use expired SAs, but =
also using something expired in any sense is plain wrong -- unless =
someone wants to redefine what "expired" means.
     
    [TR]
    For example if we consider MSCHAPv2, =
there is configuration option where server accepts the =
challenge-response from the client even if the password is expired and =
allows it be changed. 
     
    Please clarify if you have some attack in =
mind that would cause problems using expired SA.
     
    [/TR]
     
     
    Here the document =
is getting into some solution description.
    And as for such a =
solution:

    Instead of sending = a notification that is protected with an expired SA to mean = "re-authenticate", why not send an explicit message that says = "re-authenticate"? 
    [TR] 
    The client has trusted the PCP server =
sometime back using mutual authentication, so it can assume the =
integrity protected PCP response using expired SA is coming from the =
same PCP server and not from some attacker posing as PCP =
server.
    [/TR]
     
    What is gained by appearing to use an expired SA =
(but in fact not really using it! because the payload of the =
notification is not consumed by the receiver).

     
     
    Yes, that's the solution. If the server has = something to send to the client, and there's no live SA, then the server = first needs to trigger re-auth, setup a fresh SA, then send whatever it = wants to send to the client.
     
    [TR]
     
    We have updated this requirement in the =
new draft, please have a look.
     
    Best Regards,
    --Tiru.
     
    [/TR]
 
Alper
 
 
 


=
= --Apple-Mail=_9167EBBE-775C-4106-B8CA-CF05EF50E059-- From rafa@um.es Thu May 23 04:24:40 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F7C11E8132 for ; Thu, 23 May 2013 04:24:40 -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 bMJNeuQbfwhM for ; Thu, 23 May 2013 04:24:35 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id C8AE121F8BC5 for ; Thu, 23 May 2013 04:24:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 57BE44C229; Thu, 23 May 2013 13:24:30 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iCfHU3PIyy1d; Thu, 23 May 2013 13:24:29 +0200 (CEST) Received: from inf-205-55.inf.um.es (inf-205-55.inf.um.es [155.54.205.55]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon12.um.es (Postfix) with ESMTPSA id 5B97C4C248; Thu, 23 May 2013 13:24:27 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_B696AFC3-008E-4B6E-806C-A26D91B85A81" From: Rafa Marin Lopez In-Reply-To: Date: Thu, 23 May 2013 13:24:27 +0200 Message-Id: <9FC9E95E-244D-406E-A1F5-3E2847643190@um.es> References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B12D0CD38@tgxml338.toshiba.local> <674F70E5F2BE564CB06B6901FD3DD78B12D0FD42@tgxml338.toshiba.local> <674F70E5F2BE564CB06B6901FD3DD78B12D1002A@tgxml338.toshiba.local> To: Alper Yegin X-Mailer: Apple Mail (2.1283) Cc: pcp@ietf.org Subject: Re: [pcp] pcp auth requirements 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, 23 May 2013 11:24:40 -0000 --Apple-Mail=_B696AFC3-008E-4B6E-806C-A26D91B85A81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp-2 Hi Alper: Under my point of view, even though there are three cases, case 0 and 2 = imply an EAP authentication meanwhile case 1 implies an EAP = re-authentication. In other words, regardless you have case 0 or 2, you = have to create a SA so you need an EAP authentication (no living SA = exists in either case). On the contrary, you have an SA in case 1 that = you need to refresh (EAP re-authentication) So I am not sure if we really need to distinguish case 0 and 2 under = EAP's standpoint (or named them in a different way). Best regards. El 23/05/2013, a las 08:47, Alper Yegin escribi=1B.A=1BNs: > Yoshi, >=20 > You are right. In terms of EAP and RFC 5247, only the second case = qualifies for "EAP re-authentication". >=20 > On the other hand, first and third case are not the same.=20 > And I'd conceptually think of the third case as a some sort of = "re-authentication" (apparently not an "EAP re-authentication" per RFC = 5247). >=20 > Anyways, at least I'd like people to be aware of these three different = cases -- even if we cannot find a proper name to all of them. >=20 > Alper >=20 >=20 >=20 > On May 23, 2013, at 1:39 AM, wrote: >=20 >> Hi Alper, >> =20 >> When we talk about re-authentication, we should not care about = whether there is a PCP session or not. >> =20 >> Please see the following definition in RFC 5247: >> =1B$B!H=1B(B >> EAP Re-Authentication >> EAP authentication between an EAP peer and a server with whom = the >> EAP peer shares valid unexpired EAP keying material. >> =1B$B!H=1B(B >> =20 >> According to the above definition, if authentication is conducted = over a live SA, it is re-authentication, otherwise it is not = re-authentication. >> =20 >> Yoshihiro Ohba >> =20 >> =20 >> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 >> Sent: Thursday, May 23, 2013 6:16 AM >> To: ohba yoshihiro >> Cc: tireddy@cisco.com; pcp@ietf.org >> Subject: Re: [pcp] pcp auth requirements >> =20 >> Hi Yoshi, >> =20 >> Here are the three states: >> =20 >> 0. Before PCP client and PCP server has initiated PCP session. >> =20 >> 1. There is a PCP session and a live SA. >> =20 >> 2. There is a PCP session, but no live SA (i.e., the last used SA is = already expired). >> =20 >> =20 >> If we execute auth in state 0, we call it "(initial) authentication". >> Auth executed in state 1 is called "re-authenticaiton". >> I'd call auth executed in state 2 a "re-authentication" as well, = unless we want to give it a more specific name. >> =20 >> Alper >> =20 >> =20 >> =20 >> =20 >> On May 22, 2013, at 11:16 AM, wrote: >>=20 >>=20 >> Hi Alper, >> =20 >> I agree that we should allow unprotected authentication trigger from = the server, but we should distinguish authentication after expiration of = SA from =1B$B!H=1B(Bre-authentication=1B$B!I=1B(B. >> =20 >> Yoshihiro Ohba >> =20 >> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 >> Sent: Wednesday, May 22, 2013 4:22 PM >> To: ohba yoshihiro >> Cc: tireddy@cisco.com; pcp@ietf.org >> Subject: Re: [pcp] pcp auth requirements >> =20 >> =20 >> On May 21, 2013, at 10:14 AM, = wrote: >>=20 >>=20 >>=20 >> Tiru, >> =20 >> In my analysis, Req-4-d-1 is basically introducing a three-state SA = model for PCP: State 0: unavailable (or non-existent), State 1: = partially available only for triggering re-auth, and State 2: fully = available. MSCHAPv2 password change function is designed based on this = model. >> =20 >> I am not going to get into details about the three-state SA model, = but even the three-state SA model will require re-auth trigger to be = integrity protected. =20 >> =20 >> Having said that, I think the following requirement is sufficient for = Req-4-d: =1B$B!H=1B(BThe server MUST be able to send an integrity = protected re-authentication trigger to the client.=1B$B!I=1B(B >> =20 >> =20 >> If there is no SA available, then the server can send an un-protected = re-auth trigger. We should allow that. >> This is equivalent to what happens at the very beginning before the = very first authentication between the client and the server. >> =20 >> Alper >> =20 >> =20 >> =20 >>=20 >>=20 >>=20 >> Regards, >> Yoshihiro Ohba >> =20 >> =20 >> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of = Tirumaleswar Reddy (tireddy) >> Sent: Sunday, May 19, 2013 2:24 AM >> To: Alper Yegin; pcp@ietf.org >> Subject: Re: [pcp] pcp auth requirements >> =20 >> Hi Alper, >> =20 >> Please see inline [TR] >> =20 >> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 >> Sent: Tuesday, April 30, 2013 12:53 PM >> To: pcp@ietf.org >> Subject: [pcp] pcp auth requirements >> =20 >>=20 >>=20 >> c. If a server wants to send an unsolicited message, but the >> previous security association has expired >> =20 >> 1. The server can continue to use the same SA to protect >> messages pertaining to that mapping, even if the SA is >> technically expired. >>=20 >> "Expired" means "do not use (even if its still hanging around)".=20 >> We not only do not need to use expired SAs, but also using something = expired in any sense is plain wrong -- unless someone wants to redefine = what "expired" means. >> =20 >> [TR] >> For example if we consider MSCHAPv2, there is configuration option = where server accepts the challenge-response from the client even if the = password is expired and allows it be changed.=20 >> =20 >> Please clarify if you have some attack in mind that would cause = problems using expired SA. >> =20 >> [/TR] >> =20 >> - Such server notifications will not change state in = the >> PCP client. >> =20 >> - The notification could be a trigger for the client = to >> re-authenticate. =20 >>=20 >> Here the document is getting into some solution description. >>=20 >> And as for such a solution: >>=20 >> Instead of sending a notification that is protected with an expired = SA to mean "re-authenticate", why not send an explicit message that says = "re-authenticate"? >> =20 >> [TR]=20 >> The client has trusted the PCP server sometime back using mutual = authentication, so it can assume the integrity protected PCP response = using expired SA is coming from the same PCP server and not from some = attacker posing as PCP server. >> [/TR] >> =20 >> What is gained by appearing to use an expired SA (but in fact not = really using it! because the payload of the notification is not consumed = by the receiver). >>=20 >>=20 >> For example, if the server indicates >> that external IP address/port has changed, the PCP >> client can then re-authenticate with the server to >> confirm if the external IP address/port for the = mapping >> has indeed changed. >> =20 >> 2. The server can optionally trigger re-authentication = with >> the client. >> =20 >> =20 >> Yes, that's the solution. If the server has something to send to the = client, and there's no live SA, then the server first needs to trigger = re-auth, setup a fresh SA, then send whatever it wants to send to the = client. >> =20 >> [TR] >> =20 >> We have updated this requirement in the new draft, please have a = look. >> =20 >> Best Regards, >> --Tiru. >> =20 >> [/TR] >> =20 >> =20 >> Alper >> =20 >> =20 >> =20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_B696AFC3-008E-4B6E-806C-A26D91B85A81 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-2022-jp-2 Hi = Alper:

Under my point of view, even though there are = three cases, case 0 and 2 imply an EAP authentication meanwhile case 1 = implies an EAP re-authentication. In other words, regardless you have = case 0 or 2, you have to create a SA so you need an EAP authentication = (no living SA exists in either case). On the contrary, you have an SA in = case 1 that you need to refresh (EAP = re-authentication)

So I am not sure if we = really need to distinguish case 0 and 2 under EAP's standpoint (or named = them in a different way).

Best = regards.

El 23/05/2013, a las 08:47, Alper Yegin = escribi=1B.A=1BNs:


On the other hand, first = and third case are not the same. 
And I'd conceptually = think of the third case as a some sort of "re-authentication" = (apparently not an "EAP re-authentication" per RFC = 5247).

Anyways, at least I'd like people to be = aware of these three different cases -- even if we cannot find a proper = name to all of = them.

Alper



On May 23, 2013, at 1:39 AM, <yoshihiro.ohba@toshiba.co.jp<= /a>> wrote:

Hi Alper,
When we talk about re-authentication, we = should not care about whether there is a PCP session or = not.
 
Please see = the following definition in RFC 5247:
   EAP = Re-Authentication
      EAP = authentication between an EAP peer and a server with whom = the
      EAP peer shares valid = unexpired EAP keying material.
 
According to = the above definition, if authentication is conducted over a live SA, it = is re-authentication, otherwise it is not = re-authentication.
 
Yoshihiro = Ohba
 
 
Hi = Yoshi,
 
Here are the three = states:
 
0. Before PCP client and = PCP server has initiated PCP = session.
 
1. There is a PCP session = and a live SA.
 
2. There is a PCP session, = but no live SA (i.e., the last used SA is already = expired).
 
 
If we execute auth in = state 0, we call it "(initial) = authentication".
Auth executed in state 1 = is called "re-authenticaiton".
I'd call auth executed in = state 2 a "re-authentication" as well, unless we want to give it a more = specific name.
 
Alper
 
 
 
 
On May 22, 2013, at 11:16 = AM, <yoshihiro.ohba@toshiba.co.jp> = wrote:


Hi = Alper,
I agree that = we should allow unprotected authentication trigger from the server, but = we should distinguish authentication after expiration of SA from = =1B$B!H=1B(Bre-authentication=1B$B!I=1B(B.
Yoshihiro = Ohba
From: Alper Yegin [ 
Sent: Wednesday, May 22, 2013 = 4:22 PM
To: ohba = yoshihiro
Cc: tireddy@cisco.com; pcp@ietf.org
Subject: Re: [pcp] pcp auth = requirements
 
 
On May 21, 2013, at 10:14 AM, <yoshihiro.ohba@toshiba.co.jp> = <yoshihiro.ohba@toshiba.co.jp> = wrote:



Tiru,
 
In my analysis, Req-4-d-1 is = basically introducing a three-state SA model for PCP: State 0: =  unavailable (or non-existent), State 1: partially available only = for triggering re-auth, and State 2: fully available. MSCHAPv2 password = change function is designed based on this model.
 
I am not going to get into = details about the three-state SA model, but even the three-state SA = model will require re-auth trigger to be integrity protected. =  
 
Having said that, I think the = following requirement is sufficient for Req-4-d: =1B$B!H=1B(BThe server MUST be able to send = an integrity protected re-authentication trigger to the = client.=1B$B!I=1B(B
 
 
If there is no SA available, then the server can = send an un-protected re-auth trigger. We should allow = that.
This is equivalent to = what happens at the very beginning before the very first authentication = between the client and the = server.
 
Alper
 
 
 



Regards,
Yoshihiro Ohba
 
 
From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy = (tireddy)
Sent: Sunday, May 19, 2013 2:24 = AM
To: Alper = Yegin; pcp@ietf.org
Subject: Re: [pcp] pcp auth = requirements
 
Hi = Alper,
Please see = inline [TR]
From: Alper Yegin [ 
Sent: Tuesday, April 30, 2013 = 12:53 PM
To: pcp@ietf.org
Subject: [pcp] pcp auth = requirements
 

  =
        previous security =
association has expired
 
"Expired" means "do =
not use (even if its still hanging around)". 
We not only do not need to use expired SAs, but =
also using something expired in any sense is plain wrong -- unless =
someone wants to redefine what "expired" means.
 
[TR]
For example if we consider MSCHAPv2, =
there is configuration option where server accepts the =
challenge-response from the client even if the password is expired and =
allows it be changed. 
 
Please clarify if you have some attack in =
mind that would cause problems using expired SA.
 
[/TR]
 
 
Here the document =
is getting into some solution description.
And as for such a =
solution:

Instead of sending = a notification that is protected with an expired SA to mean = "re-authenticate", why not send an explicit message that says = "re-authenticate"? 
[TR] 
The client has trusted the PCP server =
sometime back using mutual authentication, so it can assume the =
integrity protected PCP response using expired SA is coming from the =
same PCP server and not from some attacker posing as PCP =
server.
[/TR]
 
What is gained by appearing to use an expired SA =
(but in fact not really using it! because the payload of the =
notification is not consumed by the receiver).

 
 
Yes, that's the solution. If the server has = something to send to the client, and there's no live SA, then the server = first needs to trigger re-auth, setup a fresh SA, then send whatever it = wants to send to the client.
 
[TR]
 
We have updated this requirement in the =
new draft, please have a look.
 
Best Regards,
--Tiru.
 
[/TR]
 
Alper
 
 
 


= _______________________________________________
pcp = mailing list
pcp@ietf.org
https://www.ietf.org/mail= man/listinfo/pcp

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




= --Apple-Mail=_B696AFC3-008E-4B6E-806C-A26D91B85A81-- From alper.yegin@yegin.org Thu May 23 12:48:51 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F15121F9820 for ; Thu, 23 May 2013 12:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.306 X-Spam-Level: X-Spam-Status: No, score=-102.306 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, HTML_MESSAGE=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 Yhb3lEdSmHau for ; Thu, 23 May 2013 12:48:34 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 53F0C21F8651 for ; Thu, 23 May 2013 12:12:19 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Ma22J-1UtXqU0Z39-00LLWq; Thu, 23 May 2013 15:12:17 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_46CCA9F8-8B40-4E20-B019-075CA764764A" From: Alper Yegin In-Reply-To: <9FC9E95E-244D-406E-A1F5-3E2847643190@um.es> Date: Thu, 23 May 2013 22:12:11 +0300 Message-Id: <1DEE6428-8C1D-4395-B2A3-CCE2E44C97F2@yegin.org> References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B12D0CD38@tgxml338.toshiba.local> <674F70E5F2BE564CB06B6901FD3DD78B12D0FD42@tgxml338.toshiba.local> <674F70E5F2BE564CB06B6901FD3DD78B12D1002A@tgxml338.toshiba.local> <9FC9E95E-244D-406E-A1F5-3E2847643190@um.es> To: Rafa Marin Lopez X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:hHLjGFXOFjSOdzrnlc9felEUVB2zNXlsKKpMyIkN7OT h36+UJut5bIRJewM28pWW8K/ju2Dd9NjTf6cf9Umahwv22yI3/ Tc8xAVf9p3LkzV6BMIGyCoes/ala5SIYFZ3JggeX6Yo/StXYNV TnUcHBjdfF29P/YqZpF4WAVLYOwt8zyyaocVDXBizdLufOAoRQ bPdnzFygz1MABZsZiwQxi9miOFvHTXha+Qjc1s0pehPf5c+Aju 0WFR9+R7Zd3DaCLy3dlMpTNcD01GuvhaxK/iLrzLQcKnLTr7L8 AVEvx3z35s5KpWshqWE42UR4Q24Ek3waoiA/nhjgAOImc2bpmf Rw7y4IqzY5LlaocIMpcI8NOWuCPOZ+c6GCbGe7cAcmpgStjOd6 yb3CV5tgx6pBA== Cc: pcp@ietf.org Subject: Re: [pcp] pcp auth requirements 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, 23 May 2013 19:48:51 -0000 --Apple-Mail=_46CCA9F8-8B40-4E20-B019-075CA764764A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp-2 Hi Rafa, =46rom EAP perpective, 0 and 2 are the same. =46rom EAP lower-layer perspective, they are not the same. Because, = there's already some pre-established state in 2, but not in 0. Alper On May 23, 2013, at 2:24 PM, Rafa Marin Lopez wrote: > Hi Alper: >=20 > Under my point of view, even though there are three cases, case 0 and = 2 imply an EAP authentication meanwhile case 1 implies an EAP = re-authentication. In other words, regardless you have case 0 or 2, you = have to create a SA so you need an EAP authentication (no living SA = exists in either case). On the contrary, you have an SA in case 1 that = you need to refresh (EAP re-authentication) >=20 > So I am not sure if we really need to distinguish case 0 and 2 under = EAP's standpoint (or named them in a different way). >=20 > Best regards. >=20 > El 23/05/2013, a las 08:47, Alper Yegin escribi=1B.A=1BNs: >=20 >> Yoshi, >>=20 >> You are right. In terms of EAP and RFC 5247, only the second case = qualifies for "EAP re-authentication". >>=20 >> On the other hand, first and third case are not the same.=20 >> And I'd conceptually think of the third case as a some sort of = "re-authentication" (apparently not an "EAP re-authentication" per RFC = 5247). >>=20 >> Anyways, at least I'd like people to be aware of these three = different cases -- even if we cannot find a proper name to all of them. >>=20 >> Alper >>=20 >>=20 >>=20 >> On May 23, 2013, at 1:39 AM, wrote: >>=20 >>> Hi Alper, >>> =20 >>> When we talk about re-authentication, we should not care about = whether there is a PCP session or not. >>> =20 >>> Please see the following definition in RFC 5247: >>> =1B$B!H=1B(B >>> EAP Re-Authentication >>> EAP authentication between an EAP peer and a server with whom = the >>> EAP peer shares valid unexpired EAP keying material. >>> =1B$B!H=1B(B >>> =20 >>> According to the above definition, if authentication is conducted = over a live SA, it is re-authentication, otherwise it is not = re-authentication. >>> =20 >>> Yoshihiro Ohba >>> =20 >>> =20 >>> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 >>> Sent: Thursday, May 23, 2013 6:16 AM >>> To: ohba yoshihiro >>> Cc: tireddy@cisco.com; pcp@ietf.org >>> Subject: Re: [pcp] pcp auth requirements >>> =20 >>> Hi Yoshi, >>> =20 >>> Here are the three states: >>> =20 >>> 0. Before PCP client and PCP server has initiated PCP session. >>> =20 >>> 1. There is a PCP session and a live SA. >>> =20 >>> 2. There is a PCP session, but no live SA (i.e., the last used SA is = already expired). >>> =20 >>> =20 >>> If we execute auth in state 0, we call it "(initial) = authentication". >>> Auth executed in state 1 is called "re-authenticaiton". >>> I'd call auth executed in state 2 a "re-authentication" as well, = unless we want to give it a more specific name. >>> =20 >>> Alper >>> =20 >>> =20 >>> =20 >>> =20 >>> On May 22, 2013, at 11:16 AM, wrote: >>>=20 >>>=20 >>> Hi Alper, >>> =20 >>> I agree that we should allow unprotected authentication trigger from = the server, but we should distinguish authentication after expiration of = SA from =1B$B!H=1B(Bre-authentication=1B$B!I=1B(B. >>> =20 >>> Yoshihiro Ohba >>> =20 >>> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 >>> Sent: Wednesday, May 22, 2013 4:22 PM >>> To: ohba yoshihiro >>> Cc: tireddy@cisco.com; pcp@ietf.org >>> Subject: Re: [pcp] pcp auth requirements >>> =20 >>> =20 >>> On May 21, 2013, at 10:14 AM, = wrote: >>>=20 >>>=20 >>>=20 >>> Tiru, >>> =20 >>> In my analysis, Req-4-d-1 is basically introducing a three-state SA = model for PCP: State 0: unavailable (or non-existent), State 1: = partially available only for triggering re-auth, and State 2: fully = available. MSCHAPv2 password change function is designed based on this = model. >>> =20 >>> I am not going to get into details about the three-state SA model, = but even the three-state SA model will require re-auth trigger to be = integrity protected. =20 >>> =20 >>> Having said that, I think the following requirement is sufficient = for Req-4-d: =1B$B!H=1B(BThe server MUST be able to send an integrity = protected re-authentication trigger to the client.=1B$B!I=1B(B >>> =20 >>> =20 >>> If there is no SA available, then the server can send an = un-protected re-auth trigger. We should allow that. >>> This is equivalent to what happens at the very beginning before the = very first authentication between the client and the server. >>> =20 >>> Alper >>> =20 >>> =20 >>> =20 >>>=20 >>>=20 >>>=20 >>> Regards, >>> Yoshihiro Ohba >>> =20 >>> =20 >>> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf = Of Tirumaleswar Reddy (tireddy) >>> Sent: Sunday, May 19, 2013 2:24 AM >>> To: Alper Yegin; pcp@ietf.org >>> Subject: Re: [pcp] pcp auth requirements >>> =20 >>> Hi Alper, >>> =20 >>> Please see inline [TR] >>> =20 >>> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 >>> Sent: Tuesday, April 30, 2013 12:53 PM >>> To: pcp@ietf.org >>> Subject: [pcp] pcp auth requirements >>> =20 >>>=20 >>>=20 >>> c. If a server wants to send an unsolicited message, but the >>> previous security association has expired >>> =20 >>> 1. The server can continue to use the same SA to protect >>> messages pertaining to that mapping, even if the SA is >>> technically expired. >>>=20 >>> "Expired" means "do not use (even if its still hanging around)".=20 >>> We not only do not need to use expired SAs, but also using something = expired in any sense is plain wrong -- unless someone wants to redefine = what "expired" means. >>> =20 >>> [TR] >>> For example if we consider MSCHAPv2, there is configuration option = where server accepts the challenge-response from the client even if the = password is expired and allows it be changed.=20 >>> =20 >>> Please clarify if you have some attack in mind that would cause = problems using expired SA. >>> =20 >>> [/TR] >>> =20 >>> - Such server notifications will not change state in = the >>> PCP client. >>> =20 >>> - The notification could be a trigger for the client = to >>> re-authenticate. =20 >>>=20 >>> Here the document is getting into some solution description. >>>=20 >>> And as for such a solution: >>>=20 >>> Instead of sending a notification that is protected with an expired = SA to mean "re-authenticate", why not send an explicit message that says = "re-authenticate"? >>> =20 >>> [TR]=20 >>> The client has trusted the PCP server sometime back using mutual = authentication, so it can assume the integrity protected PCP response = using expired SA is coming from the same PCP server and not from some = attacker posing as PCP server. >>> [/TR] >>> =20 >>> What is gained by appearing to use an expired SA (but in fact not = really using it! because the payload of the notification is not consumed = by the receiver). >>>=20 >>>=20 >>> For example, if the server indicates >>> that external IP address/port has changed, the PCP >>> client can then re-authenticate with the server to >>> confirm if the external IP address/port for the = mapping >>> has indeed changed. >>> =20 >>> 2. The server can optionally trigger re-authentication = with >>> the client. >>> =20 >>> =20 >>> Yes, that's the solution. If the server has something to send to the = client, and there's no live SA, then the server first needs to trigger = re-auth, setup a fresh SA, then send whatever it wants to send to the = client. >>> =20 >>> [TR] >>> =20 >>> We have updated this requirement in the new draft, please have a = look. >>> =20 >>> Best Regards, >>> --Tiru. >>> =20 >>> [/TR] >>> =20 >>> =20 >>> Alper >>> =20 >>> =20 >>> =20 >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >=20 > ------------------------------------------------------- > Rafael Marin Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- >=20 >=20 >=20 >=20 --Apple-Mail=_46CCA9F8-8B40-4E20-B019-075CA764764A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-2022-jp-2 Hi = Rafa,

=46rom EAP perpective, 0 and 2 are the = same.
=46rom EAP lower-layer perspective, they are not the = same. Because, there's already some pre-established state in 2, but not = in = 0.

Alper


=
On May 23, 2013, at 2:24 PM, Rafa Marin Lopez = wrote:

Hi = Alper:

Under my point of view, even though there are = three cases, case 0 and 2 imply an EAP authentication meanwhile case 1 = implies an EAP re-authentication. In other words, regardless you have = case 0 or 2, you have to create a SA so you need an EAP authentication = (no living SA exists in either case). On the contrary, you have an SA in = case 1 that you need to refresh (EAP = re-authentication)

So I am not sure if we = really need to distinguish case 0 and 2 under EAP's standpoint (or named = them in a different way).

Best = regards.

El 23/05/2013, a las 08:47, Alper Yegin = escribi=1B.A=1BNs:


On the other hand, first = and third case are not the same. 
And I'd conceptually = think of the third case as a some sort of "re-authentication" = (apparently not an "EAP re-authentication" per RFC = 5247).

Anyways, at least I'd like people to be = aware of these three different cases -- even if we cannot find a proper = name to all of = them.

Alper



On May 23, 2013, at 1:39 AM, <yoshihiro.ohba@toshiba.co.jp<= /a>> wrote:

Hi Alper,
When we talk about re-authentication, we = should not care about whether there is a PCP session or = not.
 
Please see = the following definition in RFC 5247:
   EAP = Re-Authentication
      EAP = authentication between an EAP peer and a server with whom = the
      EAP peer shares valid = unexpired EAP keying material.
 
According to = the above definition, if authentication is conducted over a live SA, it = is re-authentication, otherwise it is not = re-authentication.
 
Yoshihiro = Ohba
 
 
Hi = Yoshi,
 
Here are the three = states:
 
0. Before PCP client and = PCP server has initiated PCP = session.
 
1. There is a PCP session = and a live SA.
 
2. There is a PCP session, = but no live SA (i.e., the last used SA is already = expired).
 
 
If we execute auth in = state 0, we call it "(initial) = authentication".
Auth executed in state 1 = is called "re-authenticaiton".
I'd call auth executed in = state 2 a "re-authentication" as well, unless we want to give it a more = specific name.
 
Alper
 
 
 
 
On May 22, 2013, at 11:16 = AM, <yoshihiro.ohba@toshiba.co.jp> = wrote:


Hi = Alper,
I agree that = we should allow unprotected authentication trigger from the server, but = we should distinguish authentication after expiration of SA from = =1B$B!H=1B(Bre-authentication=1B$B!I=1B(B.
Yoshihiro = Ohba
From: Alper Yegin [ 
Sent: Wednesday, May 22, 2013 = 4:22 PM
To: ohba = yoshihiro
Cc: tireddy@cisco.com; pcp@ietf.org
Subject: Re: [pcp] pcp auth = requirements
 
 
On May 21, 2013, at 10:14 AM, <yoshihiro.ohba@toshiba.co.jp> = <yoshihiro.ohba@toshiba.co.jp> = wrote:



Tiru,
 
In my analysis, Req-4-d-1 is = basically introducing a three-state SA model for PCP: State 0: =  unavailable (or non-existent), State 1: partially available only = for triggering re-auth, and State 2: fully available. MSCHAPv2 password = change function is designed based on this model.
 
I am not going to get into = details about the three-state SA model, but even the three-state SA = model will require re-auth trigger to be integrity protected. =  
 
Having said that, I think the = following requirement is sufficient for Req-4-d: =1B$B!H=1B(BThe server MUST be able to send = an integrity protected re-authentication trigger to the = client.=1B$B!I=1B(B
 
 
If there is no SA available, then the server can = send an un-protected re-auth trigger. We should allow = that.
This is equivalent to = what happens at the very beginning before the very first authentication = between the client and the = server.
 
Alper
 
 
 



Regards,
Yoshihiro Ohba
 
 
From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy = (tireddy)
Sent: Sunday, May 19, 2013 2:24 = AM
To: Alper = Yegin; pcp@ietf.org
Subject: Re: [pcp] pcp auth = requirements
 
Hi = Alper,
Please see = inline [TR]
From: Alper Yegin [ 
Sent: Tuesday, April 30, 2013 = 12:53 PM
To: pcp@ietf.org
Subject: [pcp] pcp auth = requirements
 

  =
        previous security =
association has expired
 
"Expired" means "do =
not use (even if its still hanging around)". 
We not only do not need to use expired SAs, but =
also using something expired in any sense is plain wrong -- unless =
someone wants to redefine what "expired" means.
 
[TR]
For example if we consider MSCHAPv2, =
there is configuration option where server accepts the =
challenge-response from the client even if the password is expired and =
allows it be changed. 
 
Please clarify if you have some attack in =
mind that would cause problems using expired SA.
 
[/TR]
 
 
Here the document =
is getting into some solution description.
And as for such a =
solution:

Instead of sending = a notification that is protected with an expired SA to mean = "re-authenticate", why not send an explicit message that says = "re-authenticate"? 
[TR] 
The client has trusted the PCP server =
sometime back using mutual authentication, so it can assume the =
integrity protected PCP response using expired SA is coming from the =
same PCP server and not from some attacker posing as PCP =
server.
[/TR]
 
What is gained by appearing to use an expired SA =
(but in fact not really using it! because the payload of the =
notification is not consumed by the receiver).

 
 
Yes, that's the solution. If the server has = something to send to the client, and there's no live SA, then the server = first needs to trigger re-auth, setup a fresh SA, then send whatever it = wants to send to the client.
 
[TR]
 
We have updated this requirement in the =
new draft, please have a look.
 
Best Regards,
--Tiru.
 
[/TR]
 
Alper
 
 
 


= _______________________________________________
pcp = mailing list
pcp@ietf.org
https://www.ietf.org/ma= ilman/listinfo/pcp

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





= --Apple-Mail=_46CCA9F8-8B40-4E20-B019-075CA764764A-- From tireddy@cisco.com Fri May 24 18:53:50 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B77621F944F for ; Fri, 24 May 2013 18:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD7F-H7p4kTo for ; Fri, 24 May 2013 18:53:45 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 947F721F9446 for ; Fri, 24 May 2013 18:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6529; q=dns/txt; s=iport; t=1369446825; x=1370656425; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=wHwMfHdhTgYNIuw8SSysgYtoqxCHcsh0GGeVhdEAHsM=; b=bMxM747QOhLo4eKQz9lXE3r+jc9vRN/2ELPUkWZOS8MEwvdap9WTGB7A 1XJGplxv41eHihzGHPsuJ+/vauaFFrznHVbtZU3haysJo1jhz8skk2I2y jd4XN8UIRJWUwEItm1lu54wEmL2bNKzEhRD65gUr9oSP52fzjcZludNcO 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgGAHAYoFGtJXHA/2dsb2JhbABagwgwwjeBCRZ0giMBAQEDAQEBAWsXBAIBCBEEAQELHQcnCxQJCAIEARIIh38GDLlLjVqBEjgGgm1hA4hnj32QF4MPgWgHNw X-IronPort-AV: E=Sophos;i="4.87,738,1363132800"; d="scan'208";a="214862397" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 25 May 2013 01:53:45 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4P1rivK015583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 25 May 2013 01:53:44 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Fri, 24 May 2013 20:53:44 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" , "pcp@ietf.org" Thread-Topic: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options Thread-Index: AQHOVur0JYI2UisGT0e6MCCR7oeNHJkURpSQ Date: Sat, 25 May 2013 01:53:43 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B742FA@xmb-rcd-x10.cisco.com> References: <94C682931C08B048B7A8645303FDC9F36EB735607B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36ECFB4A912@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ECFB4A912@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.113.115] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options 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, 25 May 2013 01:53:50 -0000 > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Wednesday, May 22, 2013 2:57 PM > To: pcp@ietf.org > Subject: Re: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options >=20 > Re-, >=20 > Many thanks for all of you who provided a feedback for this point. As a > conclusion of this discussion, below a proposed change: >=20 > OLD: >=20 > 7. PCP Proxy Co-located with a NAT Function >=20 > When the PCP Proxy is co-located with a NAT function, it MUST update > the content of received requests with the mapped port number and the > address belonging to the external interface of the PCP Proxy (i.e., > after the NAT operation) and not as initially positioned by the PCP > Client. For the reverse path, PCP responses MUST be updated by the > PCP Proxy to replace the internal port number to what has been > initially positioned by the PCP Client. For this purpose the PCP > Proxy MUST have an access to the local NAT state maintained locally. > Because PCP messages with an unknown OpCode or Option can carry a > hidden internal address or internal port which will not be > translated: >=20 > o a PCP Proxy co-located with a NAT SHOULD reject by an > UNSUPP_OPCODE error response a received request with an unknown > OpCode; >=20 > o a PCP Proxy co-located with a NAT SHOULD reject by an > UNSUPP_OPTION error response a received request with a mandatory- > to-process unknown Option; >=20 > o a PCP Proxy co-located with a NAT MAY remove any optional-to- > process unknown Options from received requests before forwarding > them. >=20 > Rejecting unknown Options and OpCodes has the drawback of preventing > a PCP Client to make use of new capabilities offered by the PCP > Server but not supported by the PCP Proxy even if no IP address > and/or port is included in the Option/OpCode. >=20 > NEW: >=20 > 7. PCP Proxy Co-located with a NAT Function >=20 > When the PCP Proxy is co-located with a NAT function, it MUST update > the content of received requests with the mapped port number and the > address belonging to the external interface of the PCP Proxy (i.e., > after the NAT operation) and not as initially conveyed by the PCP > Client. For the reverse path, PCP responses MUST be updated by the > PCP Proxy to replace the internal port number to what has been > initially positioned by the PCP Client. For this purpose the PCP > Proxy MUST have an access to the local NAT state maintained locally. >=20 > By default, the PCP Proxy MUST relay unknown OpCodes and mandatory- > to-process unknown Options. Rejecting unknown Options and OpCodes > has the drawback of preventing a PCP Client to make use of new > capabilities offered by the PCP Server but not supported by the PCP > Proxy even if no IP address and/or port is included in the Option/ > OpCode. >=20 > Because PCP messages with an unknown OpCode or mandatory-to-process > unknown Options can carry a hidden internal address or internal port > which will not be translated, A PCP Proxy MUST be configurable to > disable relaying unknown OpCodes and mandatory-to-process unknown > Options. If the PCP Proxy is configured to disable relaying unknown > OpCodes and mandatory-to-process unknown Options, the PCP Proxy MUST > behave as follows: >=20 > o a PCP Proxy co-located with a NAT MUST reject by an UNSUPP_OPCODE > error response a received request with an unknown OpCode. >=20 > o a PCP Proxy co-located with a NAT MUST reject by an UNSUPP_OPTION > error response a received request with a mandatory-to-process > unknown Option. Looks good. --Tiru. >=20 >=20 > If there is no objection, this change will be include in the next version= of > the spec. >=20 > Cheers, > Med >=20 > >-----Message d'origine----- > >De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de > >mohamed.boucadair@orange.com > >Envoy=E9=A0: mardi 12 mars 2013 11:44 > >=C0=A0: pcp@ietf.org > >Objet=A0: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options > > > >Dear all, > > > >http://tools.ietf.org/html/draft-ietf-pcp-proxy-02 says: > > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Because PCP messages with an unknown OpCode or Option can carry a > > hidden internal address or internal port which will not be > > translated: > > > > o a PCP Proxy co-located with a NAT SHOULD reject by an > > UNSUPP_OPCODE error response a received request with an unknown > > OpCode; > > > > o a PCP Proxy co-located with a NAT SHOULD reject by an > > UNSUPP_OPTION error response a received request with a mandatory- > > to-process unknown Option; > > > > o a PCP Proxy co-located with a NAT MAY remove any optional-to- > > process unknown Options from received requests before forwarding > > them. > > > > Rejecting unknown Options and OpCodes has the drawback of preventing > > a PCP Client to make use of new capabilities offered by the PCP > > Server but not supported by the PCP Proxy even if no IP address > > and/or port is included in the Option/OpCode. > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >The reasoning above assumes Options which convey an IP address (and/or p= ort > >numbers) are naturally defined as mandatory-to-process option. > > > >Reinaldo suggests the following modifications to the behavior currently > >defined in the I-D: > > > >(1) A PCP Proxy inserts a "this message was proxied" when sending back t= o > >the client. Therefore if PCP client detects that the mappings are not > >working as it should, it has a hint as to why. > > > >(2) The client conveys that some options in this message carry IP addres= ses > >and need proxy processing (some IP addresses might not need any Proxy > >processing).It does not need to say which options, a bit is fine. Theref= ore > >a Proxy that could not process those options can send back a meaningful > >error such as "message can not be proxied because contains options with = IP > >address and I do not know how" > > > >Any thoughts? > > > >Thanks. > >Cheers, > >Med > >_______________________________________________ > >pcp mailing list > >pcp@ietf.org > >https://www.ietf.org/mailman/listinfo/pcp From tireddy@cisco.com Sun May 26 22:25:45 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A823E21F940B for ; Sun, 26 May 2013 22:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[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 76+cbrsLAcOc for ; Sun, 26 May 2013 22:25:37 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B461621F93F4 for ; Sun, 26 May 2013 22:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2472; q=dns/txt; s=iport; t=1369632337; x=1370841937; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Tm6QIPfg3jN/fi0rxleHwxXUtCnmJxQluEjt1NiNSjA=; b=Ty7Tbht0Kr7tCSwm2J5rE4ktTVeBlScqVb9T+xcUInyqfIruEGuv46Z8 c5GtkPCa8TnlyqhWvLVWXwiNan7Ts2Veo4JiRY77li0qaT91/AX/zSxtv f0N3pHghKlbCt9u6H2PikGd7KLt6+Qv83fSV0dbDBu7hOEycV/qDWcR5l M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEFAOzsolGtJXHB/2dsb2JhbABagwgwgzu+Sg13Fm0HgiMBAQEEIxFDDgYBCBEEAQEDAgYdAwIEMBQBBgEBBQUEEwgBiAQMnQmOaZEBgSaNRj6COzJhA5hkkBeDD4In X-IronPort-AV: E=Sophos;i="4.87,748,1363132800"; d="scan'208";a="215212757" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 27 May 2013 05:25:36 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4R5PS2Q010693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 27 May 2013 05:25:28 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Mon, 27 May 2013 00:25:28 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "pcp@ietf.org" Thread-Topic: New Version Notification for draft-wing-pcp-third-party-authz-00.txt Thread-Index: AQHOWO+LiAeF3trWa0O4+sIvEkxD05kVVqqQ Date: Mon, 27 May 2013 05:25:27 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B74A9B@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.56.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [pcp] FW: New Version Notification for draft-wing-pcp-third-party-authz-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 05:25:45 -0000 SGkgYWxsLA0KDQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHRoaXJkIHBhcnR5IGF1dGhvcml6 YXRpb24gbWVjaGFuaXNtIHRvIGFkZHJlc3MgdGhlIFJFUS0xNCBpbiAiUENQIEF1dGggUmVxdWly ZW1lbnRzIiBkcmFmdC4gSXQgZGVzY3JpYmVzIGEgY3J5cHRvZ3JhcGhpYyB0ZWNobmlxdWUgZm9y IGFuIGFwcGxpY2F0aW9uIHNlcnZlciB0byBwZXJtaXQgYSBmbG93IGFjcm9zcyBhIGZpcmV3YWxs LiAgVGhpcyB0ZWNobmlxdWUgdXNlcyBPQXV0aCBhbmQgYSBuZXcgUENQIG9wdGlvbi4NCg0KY29t bWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KDQpCZXN0IFJlZ2FyZHMsDQotLUF1 dGhvcnMuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogU2F0 dXJkYXksIE1heSAyNSwgMjAxMyA3OjU4IEFNDQpUbzogUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0 aSk7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5v KTsgRGFuIFdpbmcgKGR3aW5nKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC13aW5nLXBjcC10aGlyZC1wYXJ0eS1hdXRoei0wMC50eHQNCg0KDQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtd2luZy1wY3AtdGhpcmQtcGFydHktYXV0aHotMDAudHh0DQpoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IERhbiBXaW5nIGFuZCBwb3N0ZWQgdG8gdGhl DQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtd2luZy1wY3AtdGhpcmQtcGFy dHktYXV0aHoNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIFBDUCBFeHRlbnNpb24gZm9yIFRoaXJk IFBhcnR5IEF1dGhvcml6YXRpb24NCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTA1LTI1DQpHcm91cDoJ CSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTQNClVSTDogICAgICAg ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd2luZy1wY3At dGhpcmQtcGFydHktYXV0aHotMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2luZy1wY3AtdGhpcmQtcGFydHktYXV0aHoNCkh0bWxp emVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2luZy1wY3AtdGhp cmQtcGFydHktYXV0aHotMDANCg0KDQpBYnN0cmFjdDoNCiAgIEl0IGlzIG9mdGVuIGRlc2lyYWJs ZSBmb3IgYW4gYXBwbGljYXRpb24gc2VydmVyIHRvIHBlcm1pdCBhIGZsb3cNCiAgIGFjcm9zcyBh IGZpcmV3YWxsLCBhcyBoYXBwZW5zIHRvZGF5IHdoZW4gYSBmaXJld2FsbCBpbmNsdWRlcyBhbg0K ICAgQXBwbGljYXRpb24gTGF5ZXIgR2F0ZXdheSAoQUxHKSBmdW5jdGlvbi4gIEhvd2V2ZXIsIGFu IEFMRyBoYXMNCiAgIHNldmVyYWwgd2Vha25lc3Nlcy4NCg0KICAgVGhpcyBkb2N1bWVudCBkZXNj cmliZXMgYSBjcnlwdG9ncmFwaGljIHRlY2huaXF1ZSBmb3IgYW4gYXBwbGljYXRpb24NCiAgIHNl cnZlciB0byBwZXJtaXQgYSBmbG93IGFjcm9zcyBhIGZpcmV3YWxsLiAgVGhpcyB0ZWNobmlxdWUg dXNlcyBPQXV0aA0KICAgYW5kIGEgbmV3IFBDUCBvcHRpb24uDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From tireddy@cisco.com Sun May 26 22:41:23 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6203421F8FB6; Sun, 26 May 2013 22:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[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 x6luXo-QzGss; Sun, 26 May 2013 22:41:18 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB0121F8AD1; Sun, 26 May 2013 22:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2024; q=dns/txt; s=iport; t=1369633278; x=1370842878; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=QuUFA/VRgRvsztzngnMSr3CUY57wNSm4fkqoH4de4+g=; b=POrRMicWdEG+CVDxRqWU/DYwAuecgu4ABhyeThpSEuwwlhlKVLaE+Q0q rpV4qjltN2IHFvx597B+qZaMEX60rg3ygGXyrRY4Qml1VF3NMcAAxbFdg 5V22LQMqVLswVCUoyH3vgP9pymx2x9A0iBkU0m0Z+ZdaDrj2Yz54M3ZMs U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoFAFbxolGtJXHB/2dsb2JhbABagwgwgzu+Sg13FnSCIwEBAQQjEUMOBgEIEQQBAQMCBh0DAgQwFAEGAQEFBQQBEggBiAQMq26RAYEmjUY+gjsyYQOYZJAXgw+CJw X-IronPort-AV: E=Sophos;i="4.87,748,1363132800"; d="scan'208";a="215329775" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 27 May 2013 05:41:17 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4R5fHix027226 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 May 2013 05:41:17 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Mon, 27 May 2013 00:41:17 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "rtcweb@ietf.org" , "pcp@ietf.org" Thread-Topic: New Version Notification for draft-penno-rtcweb-pcp-00.txt Thread-Index: AQHOWPEOhCS3F73H6EewJ07BF+QMZ5kVVslw Date: Mon, 27 May 2013 05:41:17 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B74ABC@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.56.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [pcp] FW: New Version Notification for draft-penno-rtcweb-pcp-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 05:41:23 -0000 SGkgYWxsLA0KDQpUaGlzIGRyYWZ0IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBl bm5vLXJ0Y3dlYi1wY3AtMDAgZGVzY3JpYmVzIHRoZSByZWFzb25zIGZvciBXZWJSVEMgYXBwbGlj YXRpb25zIHRvIGJlIFBDUC1hd2FyZSBhbmQgdXNlIFBDUCBhbG9uZyBzaWRlIHdpdGggU1RVTiBh bmQgVFVSTi4gIEl0IGFsc28gZXhwbGFpbnMgdGhlIGJlbmVmaXRzIGZvciBhIG5ldHdvcmsgdGhh dCBkZXBsb3kgUENQLWNvbnRyb2xsZWQgTkFUcyBhbmQgRmlyZXdhbGxzLg0KDQpjb21tZW50cyBh bmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoNCkJlc3QgUmVnYXJkcywNCi0tQXV0aG9ycy4N Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBTYXR1cmRheSwg TWF5IDI1LCAyMDEzIDg6MDkgQU0NClRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBS ZWluYWxkbyBQZW5ubyAocmVwZW5ubyk7IE1vaGFtZWQgQm91Y2FkYWlyOyBEYW4gV2luZyAoZHdp bmcpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXBlbm5vLXJ0 Y3dlYi1wY3AtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXBlbm5vLXJ0 Y3dlYi1wY3AtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJlaW5h bGRvIFBlbm5vIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1l OgkgZHJhZnQtcGVubm8tcnRjd2ViLXBjcA0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgUENQIENv bnNpZGVyYXRpb25zIGZvciBXZWJSVEMgVXNhZ2UNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTA1LTI1 DQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTYNClVS TDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt cGVubm8tcnRjd2ViLXBjcC0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1wZW5uby1ydGN3ZWItcGNwDQpIdG1saXplZDogICAgICAg IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBlbm5vLXJ0Y3dlYi1wY3AtMDANCg0K DQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBtb3RpdmF0aW9ucyBm b3IgV2ViUlRDIGFwcGxpY2F0aW9ucyB0byBiZQ0KICAgUENQLWF3YXJlIGFuZCB0aGUgYmVuZWZp dHMgcHJvdmlkZWQgYnkgUENQLWNhcGFibGUgTkFUcyBhbmQNCiAgIEZpcmV3YWxscy4NCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From simon.perreault@viagenie.ca Mon May 27 01:39:35 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205BF21F8FE5 for ; Mon, 27 May 2013 01:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, 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 P3eDRJf3g-Jb for ; Mon, 27 May 2013 01:39:34 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id B069F21F8D69 for ; Mon, 27 May 2013 01:39:34 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:f83b:cff2:9a05:711]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 261B1403ED for ; Mon, 27 May 2013 04:39:34 -0400 (EDT) Message-ID: <51A31BD4.30501@viagenie.ca> Date: Mon, 27 May 2013 10:39:48 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: pcp@ietf.org References: <913383AAA69FF945B8F946018B75898A14B74ABC@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A14B74ABC@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] FW: New Version Notification for draft-penno-rtcweb-pcp-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 08:39:35 -0000 Le 2013-05-27 07:41, Tirumaleswar Reddy (tireddy) a écrit : > This draft http://tools.ietf.org/html/draft-penno-rtcweb-pcp-00 > describes the reasons for WebRTC applications to be PCP-aware and use > PCP along side with STUN and TURN. It also explains the benefits for > a network that deploy PCP-controlled NATs and Firewalls. Good information overall. Almost all of it could be generalized to anything that uses ICE. The intended status says "Standards Track", but I didn't see any normative text. Did I miss something? Suggestion: hit hard. "WebRTC clients MUST do PCP." :) Simon From alper.yegin@yegin.org Tue May 28 03:17:06 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425D321F9413 for ; Tue, 28 May 2013 03:17:06 -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 n9K6y0I+L5-3 for ; Tue, 28 May 2013 03:17:01 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 80A5B21F9246 for ; Tue, 28 May 2013 03:17:01 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MMTtG-1UnLUt03nq-008ZvN; Tue, 28 May 2013 06:17:00 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <913383AAA69FF945B8F946018B75898A14B74A9B@xmb-rcd-x10.cisco.com> Date: Tue, 28 May 2013 13:16:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <77869F66-5BD6-4611-994F-98BEE37AADDD@yegin.org> References: <913383AAA69FF945B8F946018B75898A14B74A9B@xmb-rcd-x10.cisco.com> To: "Tirumaleswar Reddy (tireddy)" X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:GN+iRpEX1zAPlWyxvWJri/W7lihS9KP0MOAFFmH/PJS rCJerz+qeLvgtRds1GIhez0CqpSse93JG0Mylfblp/vkPUcM0n 6AvZvP/OkJk7X2/fRx3eXd4nWIuMq3wPHCXVnzSpfvzp7X1X77 wyD0OEsY5mnVYEX5MSr9OjnFMzqZ8cKhrHSqPyb5szz7a4vSdK m2Ojev1aTrrE5yqu+b1b9vZwV+QBuyQcN/YR5gAQ+vjUdf7x37 EKIcLOPzA4xNOF2QWOwKglQ9HYi0dhTJcXOxSTM8ZD/zBl+oA2 ZluSsY9x+tKDRsFdg5GRsoAqEPYDN1QAeOfb3YT084x9LBOdMy Hrc0OX6NtgIse9hVkDa633x58YpqhWzNe6Rxlg1kyLEuPF7P10 d6rsxp/COpqig== Cc: "pcp@ietf.org" Subject: Re: [pcp] FW: New Version Notification for draft-wing-pcp-third-party-authz-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 10:17:06 -0000 Hello Tiru, Judging from the Figure 3 in the document, if the main objective is to = get PCP client and PCP server authenticate each other with the help of a = Authorization Server (a trusted third party), let me point out that this = is already achieved with both of the EAP-based solutions. I didn't get under that impression, but in case OAuth is also essential = to the solution, then it can be defined as an EAP method and carried = over EAP. Alper On May 27, 2013, at 8:25 AM, Tirumaleswar Reddy (tireddy) wrote: > Hi all, >=20 > This document describes a third party authorization mechanism to = address the REQ-14 in "PCP Auth Requirements" draft. It describes a = cryptographic technique for an application server to permit a flow = across a firewall. This technique uses OAuth and a new PCP option. >=20 > comments and suggestions are welcome. >=20 > Best Regards, > --Authors. >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Saturday, May 25, 2013 7:58 AM > To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Reinaldo = Penno (repenno); Dan Wing (dwing) > Subject: New Version Notification for = draft-wing-pcp-third-party-authz-00.txt >=20 >=20 > A new version of I-D, draft-wing-pcp-third-party-authz-00.txt > has been successfully submitted by Dan Wing and posted to the > IETF repository. >=20 > Filename: draft-wing-pcp-third-party-authz > Revision: 00 > Title: PCP Extension for Third Party Authorization > Creation date: 2013-05-25 > Group: Individual Submission > Number of pages: 14 > URL: = http://www.ietf.org/internet-drafts/draft-wing-pcp-third-party-authz-00.tx= t > Status: = http://datatracker.ietf.org/doc/draft-wing-pcp-third-party-authz > Htmlized: = http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-00 >=20 >=20 > Abstract: > It is often desirable for an application server to permit a flow > across a firewall, as happens today when a firewall includes an > Application Layer Gateway (ALG) function. However, an ALG has > several weaknesses. >=20 > This document describes a cryptographic technique for an application > server to permit a flow across a firewall. This technique uses = OAuth > and a new PCP option. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From tireddy@cisco.com Tue May 28 04:01:47 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B6D21F94E1 for ; Tue, 28 May 2013 04:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLcx6izJnzAP for ; Tue, 28 May 2013 04:01:41 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6526A21F9497 for ; Tue, 28 May 2013 04:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=53212; q=dns/txt; s=iport; t=1369738900; x=1370948500; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RFh53hVJBKcTD/XLt5xZWHyEq/HyWuMHiwdL3Dd2TqI=; b=kdUIeR+8+xKcXU5MAxS8N5zzNvOet+PZsu7Zj+ezYlbgSFLobs6l0Go8 fs6YtFczHx2brFYGD4s4iQzZ09dssO9nzaCE9OHMMMmuNXYxuvOekgexc hQh6R2DsHg0/8vk1ZiKi73Iqo+jHQjub5QDojFRsbIzo8LDXYnCS4SJDy c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4FACOOpFGtJV2a/2dsb2JhbABWA4JERDDCEoEFFnSCIwEBAQQtPw0QAgEIEQQBAQsOCAEGBzIUCQgCBAENBQgTh3K7do5sMQYBBgsGAYJbYQOoe4MPgic X-IronPort-AV: E=Sophos;i="4.87,757,1363132800"; d="scan'208,217";a="215745072" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 28 May 2013 11:01:39 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4SB1cDq021429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 May 2013 11:01:38 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 28 May 2013 06:01:38 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Alper Yegin , "yoshihiro.ohba@toshiba.co.jp" Thread-Topic: [pcp] pcp auth requirements Thread-Index: AQHORaVDKQ3d6G8P5kumseyWFL/c3ZkK012AgATaxwCAAZScgIAADysAgADZvgCAABdfgIAAiEiAgAKXlIA= Date: Tue, 28 May 2013 11:01:38 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B75207@xmb-rcd-x10.cisco.com> References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B12D0CD38@tgxml338.toshiba.local> <674F70E5F2BE564CB06B6901FD3DD78B12D0FD42@tgxml338.toshiba.local> <674F70E5F2BE564CB06B6901FD3DD78B12D1002A@tgxml338.toshiba.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.29] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A14B75207xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] pcp auth requirements 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, 28 May 2013 11:01:47 -0000 --_000_913383AAA69FF945B8F946018B75898A14B75207xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alper, [1] when the PCP server triggers re-authentication and SA is valid, if the = PCP client does not respond then possibly after N number of re-tries PCP se= rver may want to give up and close the explicit mappings associated with th= e user. This would handle the scenario where PCP client would have crashed = or terminated or connection lost for some reason or the user has logged off= and some other user got the same IP address as the previous user. [2] Even in case 3, we may want similar behavior as [1]. For Case 3, there = could be a scenarios - where PCP server would want to inform the PCP client= that external IP address/port has changed, but the SA is expired. In this = case PCP server would have to trigger re-auth. If re-auth is successful the= n send the mapping update or if there is no response from the client then p= roceed with deleting the explicit mappings after N number of tries. Case 3 could be an optimization to trigger re-authentication only when ther= e is interesting update to be sent from the client or server and not to tri= gger re-authentication before SA expires . --Tiru. From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Thursday, May 23, 2013 12:17 PM To: yoshihiro.ohba@toshiba.co.jp Cc: Tirumaleswar Reddy (tireddy); pcp@ietf.org Subject: Re: [pcp] pcp auth requirements Yoshi, You are right. In terms of EAP and RFC 5247, only the second case qualifies= for "EAP re-authentication". On the other hand, first and third case are not the same. And I'd conceptually think of the third case as a some sort of "re-authenti= cation" (apparently not an "EAP re-authentication" per RFC 5247). Anyways, at least I'd like people to be aware of these three different case= s -- even if we cannot find a proper name to all of them. Alper On May 23, 2013, at 1:39 AM, > wrote: Hi Alper, When we talk about re-authentication, we should not care about whether ther= e is a PCP session or not. Please see the following definition in RFC 5247: " EAP Re-Authentication EAP authentication between an EAP peer and a server with whom the EAP peer shares valid unexpired EAP keying material. " According to the above definition, if authentication is conducted over a li= ve SA, it is re-authentication, otherwise it is not re-authentication. Yoshihiro Ohba From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Thursday, May 23, 2013 6:16 AM To: ohba yoshihiro Cc: tireddy@cisco.com; pcp@ietf.org Subject: Re: [pcp] pcp auth requirements Hi Yoshi, Here are the three states: 0. Before PCP client and PCP server has initiated PCP session. 1. There is a PCP session and a live SA. 2. There is a PCP session, but no live SA (i.e., the last used SA is alread= y expired). If we execute auth in state 0, we call it "(initial) authentication". Auth executed in state 1 is called "re-authenticaiton". I'd call auth executed in state 2 a "re-authentication" as well, unless we = want to give it a more specific name. Alper On May 22, 2013, at 11:16 AM, > wrote: Hi Alper, I agree that we should allow unprotected authentication trigger from the se= rver, but we should distinguish authentication after expiration of SA from = "re-authentication". Yoshihiro Ohba From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Wednesday, May 22, 2013 4:22 PM To: ohba yoshihiro Cc: tireddy@cisco.com; pcp@ietf.org Subject: Re: [pcp] pcp auth requirements On May 21, 2013, at 10:14 AM, > > wrote: Tiru, In my analysis, Req-4-d-1 is basically introducing a three-state SA model f= or PCP: State 0: unavailable (or non-existent), State 1: partially availab= le only for triggering re-auth, and State 2: fully available. MSCHAPv2 pass= word change function is designed based on this model. I am not going to get into details about the three-state SA model, but even= the three-state SA model will require re-auth trigger to be integrity prot= ected. Having said that, I think the following requirement is sufficient for Req-4= -d: "The server MUST be able to send an integrity protected re-authenticati= on trigger to the client." If there is no SA available, then the server can send an un-protected re-au= th trigger. We should allow that. This is equivalent to what happens at the very beginning before the very fi= rst authentication between the client and the server. Alper Regards, Yoshihiro Ohba From: pcp-bounces@ietf.org [mailto:pcp-bounces= @ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy) Sent: Sunday, May 19, 2013 2:24 AM To: Alper Yegin; pcp@ietf.org Subject: Re: [pcp] pcp auth requirements Hi Alper, Please see inline [TR] From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Tuesday, April 30, 2013 12:53 PM To: pcp@ietf.org Subject: [pcp] pcp auth requirements c. If a server wants to send an unsolicited message, but the previous security association has expired 1. The server can continue to use the same SA to protect messages pertaining to that mapping, even if the SA is technically expired. "Expired" means "do not use (even if its still hanging around)". We not only do not need to use expired SAs, but also using something expire= d in any sense is plain wrong -- unless someone wants to redefine what "exp= ired" means. [TR] For example if we consider MSCHAPv2, there is configuration option where se= rver accepts the challenge-response from the client even if the password is= expired and allows it be changed. Please clarify if you have some attack in mind that would cause problems us= ing expired SA. [/TR] - Such server notifications will not change state in the PCP client. - The notification could be a trigger for the client to re-authenticate. Here the document is getting into some solution description. And as for such a solution: Instead of sending a notification that is protected with an expired SA to m= ean "re-authenticate", why not send an explicit message that says "re-authe= nticate"? [TR] The client has trusted the PCP server sometime back using mutual authentica= tion, so it can assume the integrity protected PCP response using expired S= A is coming from the same PCP server and not from some attacker posing as P= CP server. [/TR] What is gained by appearing to use an expired SA (but in fact not really us= ing it! because the payload of the notification is not consumed by the rece= iver). For example, if the server indicates that external IP address/port has changed, the PCP client can then re-authenticate with the server to confirm if the external IP address/port for the mapping has indeed changed. 2. The server can optionally trigger re-authentication with the client. Yes, that's the solution. If the server has something to send to the client= , and there's no live SA, then the server first needs to trigger re-auth, s= etup a fresh SA, then send whatever it wants to send to the client. [TR] We have updated this requirement in the new draft, please have a look. Best Regards, --Tiru. [/TR] Alper --_000_913383AAA69FF945B8F946018B75898A14B75207xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alper,

 

[1] when the PCP server triggers re-authentication and SA is= valid, if the PCP client does not respond then possibly after N number of = re-tries PCP server may want to give up and close the explicit mappings associated with the us= er. This would handle the scenario where PCP client would have crashed or t= erminated or connection lost for some reason or the user has logged off and= some other user got the same IP address as the previous user.

 

[2] Even in case 3, we may want similar behavior as [1]. For= Case 3, there could be a scenarios – where PCP server would want to = inform the PCP client that external IP address/port has changed, but the SA is expired. In this case = PCP server would have to trigger re-auth. If re-auth is successful then sen= d the mapping update or if there is no response from the client then procee= d with deleting the explicit mappings after N number of tries.

 

Case 3 could be an optimization to trigger re-authentication= only when there is interesting update to be sent from the client or server= and not to trigger re-authentication before SA expires .

 

--Tiru.

From: Alper Ye= gin [mailto:alper.yegin@yegin.org]
Sent: Thursday, May 23, 2013 12:17 PM
To: yoshihiro.ohba@toshiba.co.jp
Cc: Tirumaleswar Reddy (tireddy); pcp@ietf.org
Subject: Re: [pcp] pcp auth requirements

 

Yoshi,

 

You are right. In terms of EAP and RFC 5247, only th= e second case qualifies for "EAP re-authentication".

 

On the other hand, first and third case are not the = same. 

And I'd conceptually think of the third case as a so= me sort of "re-authentication" (apparently not an "EAP re-au= thentication" per RFC 5247).

 

Anyways, at least I'd like people to be aware of the= se three different cases -- even if we cannot find a proper name to all of = them.

 

Alper

 

 

 

On May 23, 2013, at 1:39 AM, <yoshihiro.ohba@toshiba.co.jp> wrote:



Hi Alper,

 

When we talk about re-authentication, we should not care abo= ut whether there is a PCP session or not.

 

Please see the following definition in RFC 5247:=

“

   EAP Re-Authentication

      EAP authentication between an= EAP peer and a server with whom the

      EAP peer shares valid unexpir= ed EAP keying material.

“

 

According to the above definition, if authentication is cond= ucted over a live SA, it is re-authentication, otherwise it is not re-authe= ntication.

 

Yoshihiro Ohba

 

 

From: Alper Yegin [mailto:alper.yegin@yegin.org]=  
Sent: Thursday, Ma= y 23, 2013 6:16 AM
To: ohba yoshihiro=
Cc: tireddy@cisco.com; pcp@ietf.org
Subject: Re: [pcp]= pcp auth requirements

 

Hi Yoshi,

 

Here are the three states:

 

0. Before PCP client and PCP server has initiated PC= P session.

 

1. There is a PCP session and a live SA.<= /p>

 

2. There is a PCP session, but no live SA (i.e., the= last used SA is already expired).

 

 

If we execute auth in state 0, we call it "(ini= tial) authentication".

Auth executed in state 1 is called "re-authenti= caiton".

I'd call auth executed in state 2 a "re-authent= ication" as well, unless we want to give it a more specific name.=

 

Alper

 

 

 

 

On May 22, 2013, at 11:16 AM, <yoshihiro.ohba@toshiba.co.jp> wrote:




Hi Alper,

 

I agree that we should allow unprotected authentication trig= ger from the server, but we should distinguish authentication after expirat= ion of SA from “re-authentication”.

 

Yoshihiro Ohba

 

From: Alper Yegin [mailto:alper.yegin@yegin.o= rg] 
Sent: Wednesday, M= ay 22, 2013 4:22 PM
To: ohba yoshihiro=
Cc: tireddy@cisco.com; pcp@ietf.org
Subject: Re: [pcp]= pcp auth requirements

 

 





Tiru,

 

In my analysis, Req-4-d-1 is basically introducing a three-s= tate SA model for PCP: State 0:  unavailable (or non-existent), State = 1: partially available only for triggering re-auth, and State 2: fully available. MSCHAPv2 password ch= ange function is designed based on this model.

 

I am not going to get into details about the three-state SA = model, but even the three-state SA model will require re-auth trigger to be= integrity protected.  

 

Having said that, I think the following requirement is suffi= cient for Req-4-d: “The server MUST be able to send an integrity protected re-authentication trigg= er to the client.”

 

 

If there is no SA available, then the server can sen= d an un-protected re-auth trigger. We should allow that.

This is equivalent to what happens at the very begin= ning before the very first authentication between the client and the server= .

 

Alper

 

 

 





Regards,

Yoshihiro Ohba

 

 

From: pcp-bounces@ietf.org [mailto:p= cp-bounces@ietf.org] = On Behalf Of Tirumalesw= ar Reddy (tireddy)
Sent: Sunday, May = 19, 2013 2:24 AM
To: Alper Yegin; pcp@ietf.org
Subject: Re: [pcp]= pcp auth requirements

 

Hi Alper,

 

Please see inline [TR]

 

From: Alper Yegin [mailto:alper.yegin@yegin.o= rg] 
Sent: Tuesday, Apr= il 30, 2013 12:53 PM
To: pcp@ietf.org
Subject: [pcp] pcp= auth requirements

 



 
      c.  If a server wants to send an=
 unsolicited message, but the
       &=
nbsp;  previous security association has expired
 
          1. =
; The server can continue to use the same SA to protect

      &n=
bsp;       messages pertaining to that mappin=
g, even if the SA is


      &n=
bsp;       technically expired.





"Expired" means "do not use (even if its still hangin=
g around)". 


We not only do not need to use expired SAs, but also using something=
 expired in any sense is plain wrong -- unless someone wants to redefine wh=
at "expired" means.


 


[TR]


For example if we consider MSCHAPv2, there is configuration =
option where server accepts the challenge-response from the client even if =
the password is expired and allows it be changed. 


 


Please clarify if you have some attack in mind that would caus=
e problems using expired SA.


 


[/TR]


 


           &n=
bsp;  -  Such server notifications will not change state in the


      &n=
bsp;          PCP client.


 


          &n=
bsp;   -  The notification could be a trigger for the client=
 to


      &n=
bsp;          re-authenticate.=
  





Here the document is getting into some solution description.<=
o:p>





And as for such a solution:





Instead of sending a notification that is protected with an expired =
SA to mean "re-authenticate", why not send an explicit message th=
at says "re-authenticate"?


 


[TR] 


The client has trusted the PCP server sometime back using mu=
tual authentication, so it can assume the integrity protected PCP response =
using expired SA is coming from the same PCP server and not from some attac=
ker posing as PCP server.


[/TR]


 


What i=
s gained by appearing to use an expired SA (but in fact not really using it=
! because the payload of the notification is not consumed by the receiver).=








           &n=
bsp;     For example, if the server indicates


      &n=
bsp;          that external IP=
 address/port has changed, the PCP


      &n=
bsp;          client can then =
re-authenticate with the server to


      &n=
bsp;          confirm if the e=
xternal IP address/port for the mapping


      &n=
bsp;          has indeed chang=
ed.


 


          2. =
; The server can optionally trigger re-authentication with


      &n=
bsp;       the client.









 


















 


















Yes, that's the solution. If the server has something=
 to send to the client, and there's no live SA, then the server first needs=
 to trigger re-auth, setup a fresh SA, then send whatever
 it wants to send to the client.














 








[TR]

 


We have updated this requirement in the new draft, please have=
 a look.


 


Best Regards,


--Tiru.


 


[/TR]








 


















 


















Alper


















 


















 


















 

 

--_000_913383AAA69FF945B8F946018B75898A14B75207xmbrcdx10ciscoc_-- From tireddy@cisco.com Tue May 28 04:06:28 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC9921F96A2 for ; Tue, 28 May 2013 04:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MeXXz-RpVkP for ; Tue, 28 May 2013 04:06:23 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3274421F96A0 for ; Tue, 28 May 2013 04:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3574; q=dns/txt; s=iport; t=1369739183; x=1370948783; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Uo+6lIh6oHBXDu6JUa1NoDj6bFqEXdj9gPkbC0uFQng=; b=dlPtjAv1eYW5V5JV/AOQboDWs2ZtZozhNaqj0agxC3UGcEjhUUWhyQcJ Zkdf6njWKLve6WxN9x4nEqp2xGTaufEPyUtunXOH16eYchCncNsTCHhty XURXEEBD9hWSTmDiGXdkJp5NDdn/hqaNSiEaCnhKYpjqUDiA0pa+mOd03 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0FAMqOpFGtJV2a/2dsb2JhbABZgwgwwhOBBBZ0giMBAQEDAQEBATctBwkCDAQCAQgRBAEBAQoUCQcnCxQIAQgCBA4FCAESh2wGDLttjmwxBwaCbWEDmGSQF4FYgTeBaiQZ X-IronPort-AV: E=Sophos;i="4.87,757,1363132800"; d="scan'208";a="215671037" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 28 May 2013 11:06:22 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4SB6MIB026602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 May 2013 11:06:22 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 28 May 2013 06:06:22 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Alper Yegin Thread-Topic: [pcp] FW: New Version Notification for draft-wing-pcp-third-party-authz-00.txt Thread-Index: AQHOWO+LiAeF3trWa0O4+sIvEkxD05kVVqqQgAVkPAD//60tIA== Date: Tue, 28 May 2013 11:06:21 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B7522B@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A14B74A9B@xmb-rcd-x10.cisco.com> <77869F66-5BD6-4611-994F-98BEE37AADDD@yegin.org> In-Reply-To: <77869F66-5BD6-4611-994F-98BEE37AADDD@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] FW: New Version Notification for draft-wing-pcp-third-party-authz-00.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 11:06:28 -0000 Hi Alper, Thanks for the comments. Please see inline > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Tuesday, May 28, 2013 3:47 PM > To: Tirumaleswar Reddy (tireddy) > Cc: pcp@ietf.org > Subject: Re: [pcp] FW: New Version Notification for draft-wing-pcp-third- > party-authz-00.txt >=20 > Hello Tiru, >=20 > Judging from the Figure 3 in the document, if the main objective is to ge= t PCP > client and PCP server authenticate each other with the help of a Authoriz= ation > Server (a trusted third party), let me point out that this is already ach= ieved > with both of the EAP-based solutions. In addition to Third-party authorization, PCP server needs a mechanism to v= alidate that the PCP client is only requesting the resources permitted to b= e used by Authorization Server. Various validations that are performed by t= he PCP server for this use case are mentioned in http://tools.ietf.org/html= /draft-wing-pcp-third-party-authz-00#section-5.2 > > I didn't get under that impression, but in case OAuth is also essential t= o the > solution, then it can be defined as an EAP method and carried over EAP. For the use-case mentioned in the draft, PCP Authentication is optional. Th= e OAuth Handle token provided by the Authorization server is carried in a n= ew PCP ACCESS_TOKEN option in the PCP request. --Tiru. >=20 > Alper >=20 >=20 > On May 27, 2013, at 8:25 AM, Tirumaleswar Reddy (tireddy) wrote: >=20 > > Hi all, > > > > This document describes a third party authorization mechanism to addres= s the > REQ-14 in "PCP Auth Requirements" draft. It describes a cryptographic > technique for an application server to permit a flow across a firewall. = This > technique uses OAuth and a new PCP option. > > > > comments and suggestions are welcome. > > > > Best Regards, > > --Authors. > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Saturday, May 25, 2013 7:58 AM > > To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Reinaldo = Penno > (repenno); Dan Wing (dwing) > > Subject: New Version Notification for draft-wing-pcp-third-party-authz- > 00.txt > > > > > > A new version of I-D, draft-wing-pcp-third-party-authz-00.txt > > has been successfully submitted by Dan Wing and posted to the > > IETF repository. > > > > Filename: draft-wing-pcp-third-party-authz > > Revision: 00 > > Title: PCP Extension for Third Party Authorization > > Creation date: 2013-05-25 > > Group: Individual Submission > > Number of pages: 14 > > URL: http://www.ietf.org/internet-drafts/draft-wing-pcp-thi= rd- > party-authz-00.txt > > Status: http://datatracker.ietf.org/doc/draft-wing-pcp-third-p= arty- > authz > > Htmlized: http://tools.ietf.org/html/draft-wing-pcp-third-party- > authz-00 > > > > > > Abstract: > > It is often desirable for an application server to permit a flow > > across a firewall, as happens today when a firewall includes an > > Application Layer Gateway (ALG) function. However, an ALG has > > several weaknesses. > > > > This document describes a cryptographic technique for an application > > server to permit a flow across a firewall. This technique uses OAuth > > and a new PCP option. > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > > pcp mailing list > > pcp@ietf.org > > https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange.com Tue May 28 07:19:39 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5881B21F973F for ; Tue, 28 May 2013 07:19:39 -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 8MmOcVG2SHgW for ; Tue, 28 May 2013 07:19:35 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0306221F977C for ; Tue, 28 May 2013 07:19:34 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 991542DC4CF for ; Tue, 28 May 2013 16:19:33 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 80F3C35C061 for ; Tue, 28 May 2013 16:19:33 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Tue, 28 May 2013 16:19:33 +0200 From: To: "pcp@ietf.org" Date: Tue, 28 May 2013 16:19:32 +0200 Thread-Topic: I-D Action: draft-boucadair-pcp-nat-reveal-01.txt Thread-Index: Ac5bq9C+WL/bqy1ATBicieGbFMsSywAAnuqA Message-ID: <94C682931C08B048B7A8645303FDC9F36ED1F534BE@PUEXCB1B.nanterre.francetelecom.fr> References: <20130528140001.24184.14792.idtracker@ietfa.amsl.com> In-Reply-To: <20130528140001.24184.14792.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.28.135418 Subject: [pcp] TR: I-D Action: draft-boucadair-pcp-nat-reveal-01.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 14:19:39 -0000 Dear all, Comments are more than welcome. Cheers, Med -----Message d'origine----- De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]= De la part de internet-drafts@ietf.org Envoy=E9=A0: mardi 28 mai 2013 16:00 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-boucadair-pcp-nat-reveal-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Using PCP to Reveal a Host behind NAT Author(s) : Mohamed Boucadair Tirumaleswar Reddy Prashanth Patil Dan Wing Filename : draft-boucadair-pcp-nat-reveal-01.txt Pages : 16 Date : 2013-05-28 Abstract: This document describes how to use PCP to retrieve the identity of a host behind a NAT. Two use cases are discussed and the PCP applicability is analyzed. This document extends PCP with a new OpCode called QUERY Opcode. The proposed mechanism is valid for all NAT flavors including NAT44, NAT64 or NPTv6. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-pcp-nat-reveal There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-pcp-nat-reveal-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-nat-reveal-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From alper.yegin@yegin.org Tue May 28 09:03:14 2013 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8AB21F8D70 for ; Tue, 28 May 2013 09:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=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 gPBCKaIp2JDU for ; Tue, 28 May 2013 09:03:07 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id D27F021F9785 for ; Tue, 28 May 2013 09:03:01 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Lrd0n-1UIAUj03en-0136p4; Tue, 28 May 2013 12:02:49 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_0E1563D5-774A-4A92-8218-AFF8737DE567" From: Alper Yegin In-Reply-To: <913383AAA69FF945B8F946018B75898A14B75207@xmb-rcd-x10.cisco.com> Date: Tue, 28 May 2013 19:02:42 +0300 Message-Id: References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B12D0CD38@tgxml338.toshiba.local> <674F70E5F2BE564CB06B6901FD3DD78B12D0FD42@tgxml338.toshiba.local> <674F70E5F2BE564CB06B6901FD3DD78B12D1002A@tgxml338.toshiba.local> <913383AAA69FF945B8F946018B75898A14B75207@xmb-rcd-x10.cisco.com> To: Tirumaleswar Reddy (tireddy) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:2dnfFa9ZkOG5oG8h2ea0hhCxujSqsbctGMttUYJ2qpf 5lFU6HUwSXUtd5hID4VXgxgfwreOC48W2ykCEnOCpWlThfVdcd xzTY7t1Z0ZifpXQF3sG3FoSVusLVPl4PlFF1AcSfN2WS/aH2tr 4xnZhn13boaf004knsiQVt7DBB6BvDYhbsgtE6W37okCKPsu1V 6NU5Qsxutn2bcJ0mFgAmZst8bNiKWHEgXhg30tbn64FfCutdes R/hjG8toU9OyQ6jDncwBgE2d5zXw7IPIvGrEVd69c8v/OLEcbo 1LQDYUO+OMiawtfFi9G8e/wyDrx6XOgdO3rfj2UDVXU+vBcBWh 9Ae5B7C6bnMTme/vCCog66GNioK2+vsEtZNobnBMIDY+ERI8GS gT7i5kbJurS4A== Cc: "pcp@ietf.org" Subject: Re: [pcp] pcp auth requirements 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, 28 May 2013 16:03:14 -0000 --Apple-Mail=_0E1563D5-774A-4A92-8218-AFF8737DE567 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Tiru, I agree. Alper On May 28, 2013, at 2:01 PM, Tirumaleswar Reddy (tireddy) wrote: > Hi Alper, > =20 > [1] when the PCP server triggers re-authentication and SA is valid, if = the PCP client does not respond then possibly after N number of re-tries = PCP server may want to give up and close the explicit mappings = associated with the user. This would handle the scenario where PCP = client would have crashed or terminated or connection lost for some = reason or the user has logged off and some other user got the same IP = address as the previous user. > =20 > [2] Even in case 3, we may want similar behavior as [1]. For Case 3, = there could be a scenarios =96 where PCP server would want to inform the = PCP client that external IP address/port has changed, but the SA is = expired. In this case PCP server would have to trigger re-auth. If = re-auth is successful then send the mapping update or if there is no = response from the client then proceed with deleting the explicit = mappings after N number of tries. > =20 > Case 3 could be an optimization to trigger re-authentication only when = there is interesting update to be sent from the client or server and not = to trigger re-authentication before SA expires . > =20 > --Tiru. > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Thursday, May 23, 2013 12:17 PM > To: yoshihiro.ohba@toshiba.co.jp > Cc: Tirumaleswar Reddy (tireddy); pcp@ietf.org > Subject: Re: [pcp] pcp auth requirements > =20 > Yoshi, > =20 > You are right. In terms of EAP and RFC 5247, only the second case = qualifies for "EAP re-authentication". > =20 > On the other hand, first and third case are not the same.=20 > And I'd conceptually think of the third case as a some sort of = "re-authentication" (apparently not an "EAP re-authentication" per RFC = 5247). > =20 > Anyways, at least I'd like people to be aware of these three different = cases -- even if we cannot find a proper name to all of them. > =20 > Alper > =20 > =20 > =20 > On May 23, 2013, at 1:39 AM, wrote: >=20 >=20 > Hi Alper, > =20 > When we talk about re-authentication, we should not care about whether = there is a PCP session or not. > =20 > Please see the following definition in RFC 5247: > =93 > EAP Re-Authentication > EAP authentication between an EAP peer and a server with whom = the > EAP peer shares valid unexpired EAP keying material. > =93 > =20 > According to the above definition, if authentication is conducted over = a live SA, it is re-authentication, otherwise it is not = re-authentication. > =20 > Yoshihiro Ohba > =20 > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Thursday, May 23, 2013 6:16 AM > To: ohba yoshihiro > Cc: tireddy@cisco.com; pcp@ietf.org > Subject: Re: [pcp] pcp auth requirements > =20 > Hi Yoshi, > =20 > Here are the three states: > =20 > 0. Before PCP client and PCP server has initiated PCP session. > =20 > 1. There is a PCP session and a live SA. > =20 > 2. There is a PCP session, but no live SA (i.e., the last used SA is = already expired). > =20 > =20 > If we execute auth in state 0, we call it "(initial) authentication". > Auth executed in state 1 is called "re-authenticaiton". > I'd call auth executed in state 2 a "re-authentication" as well, = unless we want to give it a more specific name. > =20 > Alper > =20 > =20 > =20 > =20 > On May 22, 2013, at 11:16 AM, wrote: >=20 >=20 >=20 > Hi Alper, > =20 > I agree that we should allow unprotected authentication trigger from = the server, but we should distinguish authentication after expiration of = SA from =93re-authentication=94. > =20 > Yoshihiro Ohba > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Wednesday, May 22, 2013 4:22 PM > To: ohba yoshihiro > Cc: tireddy@cisco.com; pcp@ietf.org > Subject: Re: [pcp] pcp auth requirements > =20 > =20 > On May 21, 2013, at 10:14 AM, = wrote: >=20 >=20 >=20 >=20 > Tiru, > =20 > In my analysis, Req-4-d-1 is basically introducing a three-state SA = model for PCP: State 0: unavailable (or non-existent), State 1: = partially available only for triggering re-auth, and State 2: fully = available. MSCHAPv2 password change function is designed based on this = model. > =20 > I am not going to get into details about the three-state SA model, but = even the three-state SA model will require re-auth trigger to be = integrity protected. =20 > =20 > Having said that, I think the following requirement is sufficient for = Req-4-d: =93The server MUST be able to send an integrity protected = re-authentication trigger to the client.=94 > =20 > =20 > If there is no SA available, then the server can send an un-protected = re-auth trigger. We should allow that. > This is equivalent to what happens at the very beginning before the = very first authentication between the client and the server. > =20 > Alper > =20 > =20 > =20 >=20 >=20 >=20 >=20 > Regards, > Yoshihiro Ohba > =20 > =20 > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of = Tirumaleswar Reddy (tireddy) > Sent: Sunday, May 19, 2013 2:24 AM > To: Alper Yegin; pcp@ietf.org > Subject: Re: [pcp] pcp auth requirements > =20 > Hi Alper, > =20 > Please see inline [TR] > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Tuesday, April 30, 2013 12:53 PM > To: pcp@ietf.org > Subject: [pcp] pcp auth requirements > =20 >=20 >=20 > c. If a server wants to send an unsolicited message, but the > previous security association has expired > =20 > 1. The server can continue to use the same SA to protect > messages pertaining to that mapping, even if the SA is > technically expired. >=20 > "Expired" means "do not use (even if its still hanging around)".=20 > We not only do not need to use expired SAs, but also using something = expired in any sense is plain wrong -- unless someone wants to redefine = what "expired" means. > =20 > [TR] > For example if we consider MSCHAPv2, there is configuration option = where server accepts the challenge-response from the client even if the = password is expired and allows it be changed.=20 > =20 > Please clarify if you have some attack in mind that would cause = problems using expired SA. > =20 > [/TR] > =20 > - Such server notifications will not change state in = the > PCP client. > =20 > - The notification could be a trigger for the client to > re-authenticate. =20 >=20 > Here the document is getting into some solution description. >=20 > And as for such a solution: >=20 > Instead of sending a notification that is protected with an expired SA = to mean "re-authenticate", why not send an explicit message that says = "re-authenticate"? > =20 > [TR]=20 > The client has trusted the PCP server sometime back using mutual = authentication, so it can assume the integrity protected PCP response = using expired SA is coming from the same PCP server and not from some = attacker posing as PCP server. > [/TR] > =20 > What is gained by appearing to use an expired SA (but in fact not = really using it! because the payload of the notification is not consumed = by the receiver). >=20 >=20 > For example, if the server indicates > that external IP address/port has changed, the PCP > client can then re-authenticate with the server to > confirm if the external IP address/port for the = mapping > has indeed changed. > =20 > 2. The server can optionally trigger re-authentication with > the client. > =20 > =20 > Yes, that's the solution. If the server has something to send to the = client, and there's no live SA, then the server first needs to trigger = re-auth, setup a fresh SA, then send whatever it wants to send to the = client. > =20 > [TR] > =20 > We have updated this requirement in the new draft, please have a look. > =20 > Best Regards, > --Tiru. > =20 > [/TR] > =20 > =20 > Alper > =20 > =20 > =20 --Apple-Mail=_0E1563D5-774A-4A92-8218-AFF8737DE567 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Tiru,

I = agree.

Alper

On May 28, = 2013, at 2:01 PM, Tirumaleswar Reddy (tireddy) wrote:

Hi = Alper,
[1] = when the PCP server triggers re-authentication and SA is valid, if the = PCP client does not respond then possibly after N number of re-tries PCP = server may want to give up and close the explicit mappings associated = with the user. This would handle the scenario where PCP client would = have crashed or terminated or connection lost for some reason or the = user has logged off and some other user got the same IP address as the = previous user.
[2] = Even in case 3, we may want similar behavior as [1]. For Case 3, there = could be a scenarios =96 where PCP server would want to inform the PCP = client that external IP address/port has changed, but the SA is expired. = In this case PCP server would have to trigger re-auth. If re-auth is = successful then send the mapping update or if there is no response from = the client then proceed with deleting the explicit mappings after N = number of tries.
Case = 3 could be an optimization to trigger re-authentication only when there = is interesting update to be sent from the client or server and not to = trigger re-authentication before SA expires = .
 Alper = Yegin [mailto:alper.yegin@yegin.org] 
Sent: Thursday, May 23, 2013 = 12:17 PM
To:  Tirumaleswar Reddy = (tireddy); pcp@ietf.org
Subject: Re: [pcp] pcp auth = requirements
You are right. In terms = of EAP and RFC 5247, only the second case qualifies for "EAP = re-authentication".
On the other hand, first = and third case are not the same. 
And I'd conceptually think of the third case as a some = sort of "re-authentication" (apparently not an "EAP re-authentication" = per RFC 5247).
Anyways, at least I'd = like people to be aware of these three different cases -- even if we = cannot find a proper name to all of = them.
On May 23, 2013, at 1:39 = AM, <yoshihiro.ohba@toshiba.co.jp> = wrote:
Hi = Alper,
When we talk about re-authentication, we should not care = about whether there is a PCP session or = not.
Please see the following definition in RFC = 5247:
      = EAP authentication between an EAP peer and a server with whom = the
According to the above definition, if authentication is = conducted over a live SA, it is re-authentication, otherwise it is not = re-authentication.
Yoshihiro Ohba
 
From:Alper Yegin [mailto:alper.yegin@yegin.org] 
Sent: Thursday, May 23, 2013 6:16 = AM
To: ohba = yoshihiro
Cc: tireddy@cisco.com; pcp@ietf.org
Subject: Re: [pcp] pcp auth = requirements
Hi Yoshi,
Here are the three = states:
 
0. Before PCP client and = PCP server has initiated PCP = session.
 
1. There is a PCP session = and a live SA.
 
2. There is a PCP = session, but no live SA (i.e., the last used SA is already = expired).
 
If we execute auth in state 0, we call it = "(initial) authentication".
Auth executed in state 1 = is called "re-authenticaiton".
I'd call auth executed in = state 2 a "re-authentication" as well, unless we want to give it a more = specific name.
 
 
 
On May 22, 2013, at 11:16 AM, <yoshihiro.ohba@toshiba.co.jp> = wrote:



Hi = Alper,
I agree = that we should allow unprotected authentication trigger from the server, = but we should distinguish authentication after expiration of SA from = =93re-authentication=94.
From:Alper Yegin [mailto:alper.yegin@yegin.org] 
Sent: Wednesday, May 22, 2013 = 4:22 PM
To: ohba = yoshihiro
Cc: tireddy@cisco.com; pcp@ietf.org
Subject: Re: [pcp] pcp auth = requirements
 
 
On May 21, 2013, at 10:14 AM, <yoshihiro.ohba@toshiba.co.jp> = <yoshihiro.ohba@toshiba.co.jp> = wrote:
In my analysis, Req-4-d-1 is = basically introducing a three-state SA model for PCP: State 0: =  unavailable (or non-existent), State 1: partially available only = for triggering re-auth, and State 2: fully available. MSCHAPv2 password = change function is designed based on this = model.
I am not going to get into = details about the three-state SA model, but even the three-state SA = model will require re-auth trigger to be integrity protected. =  
Having said that, I think the = following requirement is sufficient for Req-4-d: =93The server = MUST be able to send an integrity protected re-authentication trigger to = the client.=94
 
If there is no SA available, then the server can send an = un-protected re-auth trigger. We should allow = that.
This is = equivalent to what happens at the very beginning before the very first = authentication between the client and the = server.
Yoshihiro = Ohba
From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy = (tireddy)
Sent: Sunday, May 19, 2013 2:24 = AM
To: Alper = Yegin; pcp@ietf.org
Subject: Re: [pcp] pcp auth = requirements
Hi = Alper,
From: Alper Yegin = [mailto:alper.yegin@yegin.org] 
Sent: Tuesday, April 30, 2013 = 12:53 PM
To: pcp@ietf.org
Subject: [pcp] pcp auth = requirements

      c.  If a server wants to =
send an unsolicited message, but the
  =
        previous security =
association has expired
"Expired" means "do not use (even if its still hanging =
around)". 
We not only do not need to use expired SAs, but also using =
something expired in any sense is plain wrong -- unless someone wants to =
redefine what "expired" means.
 
For example =
if we consider MSCHAPv2, there is configuration option where server =
accepts the challenge-response from the client even if the password is =
expired and allows it be changed. 
 
Please =
clarify if you have some attack in mind that would cause problems using =
expired SA.
            =
  -  Such server notifications will not change state in =
the
 

Here the document is getting into some solution =
description.

And as for such a solution:
Instead of sending a notification that is protected with an =
expired SA to mean "re-authenticate", why not send an explicit message =
that says "re-authenticate"?
 
[TR] =

The client has =
trusted the PCP server sometime back using mutual authentication, so it =
can assume the integrity protected PCP response using expired SA is =
coming from the same PCP server and not from some attacker posing as PCP =
server.
What is gained by appearing to use an expired SA (but in fact =
not really using it! because the payload of the notification is not =
consumed by the receiver).

            =
     For example, if the server =
indicates
 
 
Yes, that's the solution. If the server has = something to send to the client, and there's no live SA, then the server = first needs to trigger re-auth, setup a fresh SA, then send whatever it = wants to send to the = client.
[TR]
We have =
updated this requirement in the new draft, please have a =
look.
Best =
Regards,

Subject: Re: [pcp] New Version Notification for draft-wing-pcp-third-party-authz-00.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 May 2013 16:10:51 -0000

Hi Tiru,

>> Judging from the Figure 3 in the document, if the main objective is =
to get PCP
>> client and PCP server authenticate each other with the help of a =
Authorization
>> Server (a trusted third party), let me point out that this is already =
achieved
>> with both of the EAP-based solutions.
>=20
> In addition to Third-party authorization, PCP server needs a mechanism =
to validate that the PCP client is only requesting the resources =
permitted to be used by Authorization Server. Various validations that =
are performed by the PCP server for this use case are mentioned in =
http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-00#section-5.2=

>=20

Yes, this is indeed part of what I'm describing.

Typically, EAP is carried over Foo between the xClint and xServer, and =
over a AAA (Authentication, Authortization, and Accounting) protocol =
[such as RADIUS, Diameter] between the xServer and the Authorization =
Server (a AAA server). The AAA protocol takes care of the =
"authorization", making sure the authenticated Client is only getting =
the services that it is authorized to use.


>>=20
>> I didn't get under that impression, but in case OAuth is also =
essential to the
>> solution, then it can be defined as an EAP method and carried over =
EAP.
>=20
> For the use-case mentioned in the draft, PCP Authentication is =
optional. The OAuth Handle token provided by the Authorization server is =
carried in a new PCP ACCESS_TOKEN option in the PCP request.
>=20

That Token is providing "Client authentication", ensuring that the Token =
indeed is sent by the claimed identity,
But it'd not be providing data-origin authentication and integrity =
protection for the rest of the PCP message.
And in the absence of that, any part of the message aside from the Token =
can be spoofed/modified.

Alper



> --Tiru.
>=20
>>=20
>> Alper
>>=20
>>=20
>> On May 27, 2013, at 8:25 AM, Tirumaleswar Reddy (tireddy) wrote:
>>=20
>>> Hi all,
>>>=20
>>> This document describes a third party authorization mechanism to =
address the
>> REQ-14 in "PCP Auth Requirements" draft. It describes a cryptographic
>> technique for an application server to permit a flow across a =
firewall.  This
>> technique uses OAuth and a new PCP option.
>>>=20
>>> comments and suggestions are welcome.
>>>=20
>>> Best Regards,
>>> --Authors.
>>>=20
>>> -----Original Message-----
>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>>> Sent: Saturday, May 25, 2013 7:58 AM
>>> To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); =
Reinaldo Penno
>> (repenno); Dan Wing (dwing)
>>> Subject: New Version Notification for =
draft-wing-pcp-third-party-authz-
>> 00.txt
>>>=20
>>>=20
>>> A new version of I-D, draft-wing-pcp-third-party-authz-00.txt
>>> has been successfully submitted by Dan Wing and posted to the
>>> IETF repository.
>>>=20
>>> Filename:	 draft-wing-pcp-third-party-authz
>>> Revision:	 00
>>> Title:		 PCP Extension for Third Party Authorization
>>> Creation date:	 2013-05-25
>>> Group:		 Individual Submission
>>> Number of pages: 14
>>> URL:             =
http://www.ietf.org/internet-drafts/draft-wing-pcp-third-
>> party-authz-00.txt
>>> Status:          =
http://datatracker.ietf.org/doc/draft-wing-pcp-third-party-
>> authz
>>> Htmlized:        =
http://tools.ietf.org/html/draft-wing-pcp-third-party-
>> authz-00
>>>=20
>>>=20
>>> Abstract:
>>>  It is often desirable for an application server to permit a flow
>>>  across a firewall, as happens today when a firewall includes an
>>>  Application Layer Gateway (ALG) function.  However, an ALG has
>>>  several weaknesses.
>>>=20
>>>  This document describes a cryptographic technique for an =
application
>>>  server to permit a flow across a firewall.  This technique uses =
OAuth
>>>  and a new PCP option.
>>>=20
>>>=20
>>>=20
>>>=20
>>> The IETF Secretariat
>>>=20
>>> _______________________________________________
>>> pcp mailing list
>>> pcp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/pcp
>=20


From cheshire@apple.com  Tue May 28 11:37:31 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B2F21F949A for ; Tue, 28 May 2013 11:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLLjxMe0YLW7 for ; Tue, 28 May 2013 11:37:25 -0700 (PDT)
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 509DE21F9497 for ; Tue, 28 May 2013 11:37:25 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MNI00JAVUDY5N31@mail-out.apple.com> for pcp@ietf.org; Tue, 28 May 2013 11:37:15 -0700 (PDT)
X-AuditID: 11807158-b7f486d0000079b6-84-51a4f95bb17f
Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay5.apple.com (Apple SCV relay) with SMTP id BC.E4.31158.B59F4A15; Tue, 28 May 2013 11:37:15 -0700 (PDT)
Received: from chesh1.apple.com (chesh1.apple.com [17.193.13.41]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MNI00061UE34W30@spicerack.apple.com> for pcp@ietf.org; Tue, 28 May 2013 11:37:15 -0700 (PDT)
From: Stuart Cheshire 
In-reply-to: <519C7FE0.5020605@viagenie.ca>
Date: Tue, 28 May 2013 11:37:15 -0700
Content-transfer-encoding: quoted-printable
Message-id: <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com>
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca>
To: "pcp@ietf.org" 
X-Mailer: Apple Mail (2.1503)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUi2FCsoRv9c0mgwcqpuhaTj/1mdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrR3LWwFx1gr1rXfY2lgXMrSxcjJISFgIjHj6R9WCFtM4sK9 9WxdjFwcQgKTmSSaFlxkhnBWMEk8+jMFrINZQEei9/s3ZhCbV0BPYtvcbWwgtrCAtsTb27fY QWw2AS2JF5+vgMU5geJNbzYygtgsAqoSf55vYYaYUyOx8947NghbW+LJuwusEDNtJFrvtILt EhLIlVg07zdYXERAUeLAthvsEJfKSrx+/oZlAqPALCQnzUJy0iwkYxcwMq9iFChKzUmsNNVL LCjISdVLzs/dxAgOvcKIHYz/l1kdYhTgYFTi4V3xfUmgEGtiWXFl7iFGCQ5mJRHeSyuBQrwp iZVVqUX58UWlOanFhxilOViUxHn7XwKlBNITS1KzU1MLUotgskwcnFINjPG7OoMtWmSS/z/7 L3PI9XLUnO2Xu1P3LzrwheE8s8b9I+rMjjLn33AsuKJSN1HuR/Ht/gufNev0X5betvi3yZg9 wEx/FePy2lwjnlq7ORxTtt1fklQz+XCXxa1/bvySpU3FG79HhF623PNO6EhW1E7mnxUvlwfV rGu9IfDSwDo249Z/7nWWikosxRmJhlrMRcWJAGiKbwY5AgAA
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 28 May 2013 18:37:31 -0000

On 22 May, 2013, at 01:20, Simon Perreault  =
wrote:

> Le 2013-05-22 06:35, Reinaldo Penno (repenno) a =E9crit :
>> Agreed.
>=20
> +1

Okay. A question for our chairs and AD:

19.3.  Result Codes

   IANA has created a new registry for PCP result codes, numbered 0-255,
   initially populated with the result codes from Section 7.4.  The
   value 255 is Reserved and may be assigned via Standards Action
   [RFC5226].

   The values in the range 14-127 can be assigned via Standards Action
   [RFC5226]

What is required for us to request IANA to allocate UNSUPP_FAMILY with =
value 14? An entire RFC? IETF-wide consensus? WG consensus?

Stuart Cheshire


From Ted.Lemon@nominum.com  Tue May 28 11:58:59 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B14D21F96DF for ; Tue, 28 May 2013 11:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.476
X-Spam-Level: 
X-Spam-Status: No, score=-106.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 t5pDI3lQgz2f for ; Tue, 28 May 2013 11:58:42 -0700 (PDT)
Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 44CA021E809A for ; Tue, 28 May 2013 11:58:42 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUaT+YUniJJL1RWEm8TU82s80kdFvyq12@postini.com; Tue, 28 May 2013 11:58:42 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C1FAD1B81C7 for ; Tue, 28 May 2013 11:58:41 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B6765190052; Tue, 28 May 2013 11:58:41 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Tue, 28 May 2013 11:58:41 -0700
From: Ted Lemon 
To: Stuart Cheshire 
Thread-Topic: [pcp] UNSUPP_FAMILY error code
Thread-Index: AQHOVpFL8brGRjBzTUyoANqbDdutd5kRE6yAgAA/EACACho5gIAABf2A
Date: Tue, 28 May 2013 18:58:41 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com>
In-Reply-To: <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <89B35185D5AB5749846D76CE97C4EB2D@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 28 May 2013 18:58:59 -0000

On May 28, 2013, at 2:37 PM, Stuart Cheshire  wrote:
> What is required for us to request IANA to allocate UNSUPP_FAMILY with va=
lue 14? An entire RFC? IETF-wide consensus? WG consensus?

Oops, to be clear, a standards-track document has to be published by the IE=
TF.   It could be quite short; if the working group can agree on it quickly=
, you could probably have it before Berlin.


From cheshire@apple.com  Tue May 28 16:24:35 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC9421F9307 for ; Tue, 28 May 2013 16:24:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRkkq7QYiEXd for ; Tue, 28 May 2013 16:24:23 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id A49A421F91CB for ; Tue, 28 May 2013 16:24:23 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MNJ00KND7OBSRP1@mail-out.apple.com> for pcp@ietf.org; Tue, 28 May 2013 16:24:19 -0700 (PDT)
X-AuditID: 1180715a-b7f506d000007d18-7a-51a53ca2c33c
Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay6.apple.com (Apple SCV relay) with SMTP id AC.A2.32024.3AC35A15; Tue, 28 May 2013 16:24:19 -0700 (PDT)
Received: from [192.168.241.131] (unknown [64.164.138.146]) by kencur.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MNJ003H17OAFP20@kencur.apple.com> for pcp@ietf.org; Tue, 28 May 2013 16:24:18 -0700 (PDT)
From: Stuart Cheshire 
In-reply-to: <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>
Date: Tue, 28 May 2013 16:24:09 -0700
Message-id: 
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>
To: PCP 
X-Mailer: Apple Mail (2.1085)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUiON1OTXexzdJAg8mXmCwmH/vN6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujA1/nzMXvBOo+PX+CGMDYx9vFyMnh4SAicTUqwvYIGwxiQv3 1gPZXBxCAk1MEvf/tLNCOHOZJCYe3gtWJSygLfH29i12EJtXwFBiyfUtYDazgJbE+p3HmUBs NiD7xecrYPWcAn4S104/ArNZBFQlzs6YwwpRryqx6dppZghbW+LJuwusEDNtJN68n8IOsfgJ o8TW78fAmkWAzlv9+CETxKmyEjvvnGaZwCgwC8kds5DcMQvJ3AWMzKsYBYpScxIrzfQSCwpy UvWS83M3MYKCr6Ewagdjw3KrQ4wCHIxKPLwrvi8JFGJNLCuuzD3EKMHBrCTCmyq4NFCINyWx siq1KD++qDQntfgQozQHi5I4rwkw4IUE0hNLUrNTUwtSi2CyTBycUg2MGuYP97Z+SFnHE9PS 3Ma6/n/liZu2i6v2a/VNbL0xMaB+7astR7x+iX3+U7I1ZLmN5qzjaXwtT3nVYmYLievHL2W9 n7CR06DMcmGk/kH71Zf2ufRWbDlndpZt7i8zBhlm9gmhtcUSTllvzXy6lLKc70yy4WR9sNBz qVO7Te0O6Q4JpaTnRs5KLMUZiYZazEXFiQDbMxzJOgIAAA==
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 28 May 2013 23:24:35 -0000

On 28 May 2013, at 11:58, Ted Lemon wrote:

> On May 28, 2013, at 2:37 PM, Stuart Cheshire  wrote:
>> What is required for us to request IANA to allocate UNSUPP_FAMILY with value 14? An entire RFC? IETF-wide consensus? WG consensus?
> 
> Oops, to be clear, a standards-track document has to be published by the IETF.   It could be quite short; if the working group can agree on it quickly, you could probably have it before Berlin.

Here you go:



WG participants, please review and comment, and if there are no objections we can issue a WGLC.

For your convenience, the text is below.

2.  Introduction

   The Port Control Protocol [RFC6887] allows clients to request
   mappings in NAT gateways and firewalls.  A client can request a
   mapping to an external IPv4 address or to an external IPv6 address.
   The client signifies which family of external address it desires by
   the type of address it puts into the Suggested External Address
   field.

   If the client wants an external IPv4 address, then it populates the
   Suggested External Address field with an IPv4-mapped IPv6 address
   (the first 80 bits set to zero, the next 16 set to one).  This
   includes the case of the all-zeros IPv4 address (::ffff:0:0).

   If the client wants an external IPv6 address, then it populates the
   Suggested External Address field with a native IPv6 address.  This
   includes the case of the all-zeros IPv6 address (::).

   However, some devices may not be able to provide the requested
   external address family.  For example, an IPv4-only NAT cannot
   provide an external IPv6 address.

   In the event that the device cannot provide the requested external
   address family, it MUST return a PCP error reply containing the
   UNSUPP_FAMILY error code.


3.  IANA Considerations

   IANA should allocate the following PCP Result Code:

   14 UNSUPP_FAMILY: Unsupported external address family, e.g., IPv6 in
      a NAT that handles only IPv4.  This is a long lifetime error.

Stuart Cheshire


From yoshihiro.ohba@toshiba.co.jp  Tue May 28 16:27:49 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23F321F8A68 for ; Tue, 28 May 2013 16:27:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.088
X-Spam-Level: 
X-Spam-Status: No, score=-4.088 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 sk2JrbvjO97b for ; Tue, 28 May 2013 16:27:42 -0700 (PDT)
Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0DE21F898B for ; Tue, 28 May 2013 16:27:34 -0700 (PDT)
Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp  with ESMTP id r4SNRS2q011828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 May 2013 08:27:28 +0900 (JST)
Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r4SNRSGE006802; Wed, 29 May 2013 08:27:28 +0900
Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 347; Wed, 29 May 2013 08:27:28 +0900 (JST)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r4SNRSQb006799; Wed, 29 May 2013 08:27:28 +0900
Received: (from root@localhost) by arc1.toshiba.co.jp  id r4SNRSMJ017344; Wed, 29 May 2013 08:27:28 +0900 (JST)
Received: from unknown [133.199.192.144]  by arc1.toshiba.co.jp with ESMTP id JAA17343; Wed, 29 May 2013 08:27:28 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp  with ESMTP id r4SNRSHU010334; Wed, 29 May 2013 08:27:28 +0900 (JST)
Received: from TGXML330.toshiba.local by toshiba.co.jp id r4SNRRJ9028157; Wed, 29 May 2013 08:27:27 +0900 (JST)
Received: from TGXML338.toshiba.local ([169.254.4.217]) by TGXML330.toshiba.local ([133.199.60.204]) with mapi id 14.03.0123.003; Wed, 29 May 2013 08:27:27 +0900
From: 
To: , 
Thread-Topic: [pcp] pcp auth requirements
Thread-Index: AQHORXOMRcSeZEmOnUO6Nprz3E76X5kKtxIAgASSsTCAAQ6vgIAAo9BwgABFGQCAAKzlsP//8sKAgAgiqgCAAFQeAIABCw9w
Date: Tue, 28 May 2013 23:27:25 +0000
Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B12D138C5@tgxml338.toshiba.local>
References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B12D0CD38@tgxml338.toshiba.local>  <674F70E5F2BE564CB06B6901FD3DD78B12D0FD42@tgxml338.toshiba.local>  <674F70E5F2BE564CB06B6901FD3DD78B12D1002A@tgxml338.toshiba.local>  <913383AAA69FF945B8F946018B75898A14B75207@xmb-rcd-x10.cisco.com> 
In-Reply-To: 
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
x-originating-ip: [133.196.20.70]
msscp.transfermailtomossagent: 103
Content-Type: multipart/alternative; boundary="_000_674F70E5F2BE564CB06B6901FD3DD78B12D138C5tgxml338toshiba_"
MIME-Version: 1.0
Cc: pcp@ietf.org
Subject: Re: [pcp] pcp auth requirements
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, 28 May 2013 23:27:49 -0000

--_000_674F70E5F2BE564CB06B6901FD3DD78B12D138C5tgxml338toshiba_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

OK.  Then I suggest forming a requirement without using the term =1B$B!H=1B=
(Bre-authentication=1B$B!I=1B(B, something like:

The server MUST be able to send authentication trigger to the client when t=
here is a mapping.  The authentication trigger MUST be integrity protected =
if there is a SA.

Yoshihiro Ohba

From: Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Wednesday, May 29, 2013 1:03 AM
To: Tirumaleswar Reddy
Cc: ohba yoshihiro; pcp@ietf.org
Subject: Re: [pcp] pcp auth requirements

Tiru,

I agree.

Alper

On May 28, 2013, at 2:01 PM, Tirumaleswar Reddy (tireddy) wrote:


Hi Alper,

[1] when the PCP server triggers re-authentication and SA is valid, if the =
PCP client does not respond then possibly after N number of re-tries PCP se=
rver may want to give up and close the explicit mappings associated with th=
e user. This would handle the scenario where PCP client would have crashed =
or terminated or connection lost for some reason or the user has logged off=
 and some other user got the same IP address as the previous user.

[2] Even in case 3, we may want similar behavior as [1]. For Case 3, there =
could be a scenarios - where PCP server would want to inform the PCP client=
 that external IP address/port has changed, but the SA is expired. In this =
case PCP server would have to trigger re-auth. If re-auth is successful the=
n send the mapping update or if there is no response from the client then p=
roceed with deleting the explicit mappings after N number of tries.

Case 3 could be an optimization to trigger re-authentication only when ther=
e is interesting update to be sent from the client or server and not to tri=
gger re-authentication before SA expires .

--Tiru.
From: Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Thursday, May 23, 2013 12:17 PM
To: yoshihiro.ohba@toshiba.co.jp
Cc: Tirumaleswar Reddy (tireddy); pcp@ietf.org
Subject: Re: [pcp] pcp auth requirements

Yoshi,

You are right. In terms of EAP and RFC 5247, only the second case qualifies=
 for "EAP re-authentication".

On the other hand, first and third case are not the same.
And I'd conceptually think of the third case as a some sort of "re-authenti=
cation" (apparently not an "EAP re-authentication" per RFC 5247).

Anyways, at least I'd like people to be aware of these three different case=
s -- even if we cannot find a proper name to all of them.

Alper



On May 23, 2013, at 1:39 AM, > wrote:



Hi Alper,

When we talk about re-authentication, we should not care about whether ther=
e is a PCP session or not.

Please see the following definition in RFC 5247:
=1B$B!H=1B(B
   EAP Re-Authentication
      EAP authentication between an EAP peer and a server with whom the
      EAP peer shares valid unexpired EAP keying material.
=1B$B!H=1B(B

According to the above definition, if authentication is conducted over a li=
ve SA, it is re-authentication, otherwise it is not re-authentication.

Yoshihiro Ohba


From: Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Thursday, May 23, 2013 6:16 AM
To: ohba yoshihiro
Cc: tireddy@cisco.com; pcp@ietf.org
Subject: Re: [pcp] pcp auth requirements

Hi Yoshi,

Here are the three states:

0. Before PCP client and PCP server has initiated PCP session.

1. There is a PCP session and a live SA.

2. There is a PCP session, but no live SA (i.e., the last used SA is alread=
y expired).


If we execute auth in state 0, we call it "(initial) authentication".
Auth executed in state 1 is called "re-authenticaiton".
I'd call auth executed in state 2 a "re-authentication" as well, unless we =
want to give it a more specific name.

Alper




On May 22, 2013, at 11:16 AM, > wrote:




Hi Alper,

I agree that we should allow unprotected authentication trigger from the se=
rver, but we should distinguish authentication after expiration of SA from =
=1B$B!H=1B(Bre-authentication=1B$B!I=1B(B.

Yoshihiro Ohba

From: Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Wednesday, May 22, 2013 4:22 PM
To: ohba yoshihiro
Cc: tireddy@cisco.com; pcp@ietf.org
Subject: Re: [pcp] pcp auth requirements


On May 21, 2013, at 10:14 AM, > > wrote:





Tiru,

In my analysis, Req-4-d-1 is basically introducing a three-state SA model f=
or PCP: State 0:  unavailable (or non-existent), State 1: partially availab=
le only for triggering re-auth, and State 2: fully available. MSCHAPv2 pass=
word change function is designed based on this model.

I am not going to get into details about the three-state SA model, but even=
 the three-state SA model will require re-auth trigger to be integrity prot=
ected.

Having said that, I think the following requirement is sufficient for Req-4=
-d: =1B$B!H=1B(BThe server MUST be able to send an integrity protected re-a=
uthentication trigger to the client.=1B$B!I=1B(B


If there is no SA available, then the server can send an un-protected re-au=
th trigger. We should allow that.
This is equivalent to what happens at the very beginning before the very fi=
rst authentication between the client and the server.

Alper








Regards,
Yoshihiro Ohba


From: pcp-bounces@ietf.org [mailto:pcp-bounces=
@ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Sunday, May 19, 2013 2:24 AM
To: Alper Yegin; pcp@ietf.org
Subject: Re: [pcp] pcp auth requirements

Hi Alper,

Please see inline [TR]

From: Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Tuesday, April 30, 2013 12:53 PM
To: pcp@ietf.org
Subject: [pcp] pcp auth requirements




      c.  If a server wants to send an unsolicited message, but the

          previous security association has expired



          1.  The server can continue to use the same SA to protect

              messages pertaining to that mapping, even if the SA is

              technically expired.


"Expired" means "do not use (even if its still hanging around)".

We not only do not need to use expired SAs, but also using something expire=
d in any sense is plain wrong -- unless someone wants to redefine what "exp=
ired" means.



[TR]

For example if we consider MSCHAPv2, there is configuration option where se=
rver accepts the challenge-response from the client even if the password is=
 expired and allows it be changed.



Please clarify if you have some attack in mind that would cause problems us=
ing expired SA.



[/TR]



              -  Such server notifications will not change state in the

                 PCP client.



              -  The notification could be a trigger for the client to

                 re-authenticate.


Here the document is getting into some solution description.


And as for such a solution:


Instead of sending a notification that is protected with an expired SA to m=
ean "re-authenticate", why not send an explicit message that says "re-authe=
nticate"?



[TR]

The client has trusted the PCP server sometime back using mutual authentica=
tion, so it can assume the integrity protected PCP response using expired S=
A is coming from the same PCP server and not from some attacker posing as P=
CP server.

[/TR]



What is gained by appearing to use an expired SA (but in fact not really us=
ing it! because the payload of the notification is not consumed by the rece=
iver).



                 For example, if the server indicates

                 that external IP address/port has changed, the PCP

                 client can then re-authenticate with the server to

                 confirm if the external IP address/port for the mapping

                 has indeed changed.



          2.  The server can optionally trigger re-authentication with

              the client.


Yes, that's the solution. If the server has something to send to the client=
, and there's no live SA, then the server first needs to trigger re-auth, s=
etup a fresh SA, then send whatever it wants to send to the client.


[TR]



We have updated this requirement in the new draft, please have a look.



Best Regards,

--Tiru.



[/TR]


Alper





--_000_674F70E5F2BE564CB06B6901FD3DD78B12D138C5tgxml338toshiba_
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable











OK.  Then I suggest forming a requirement without using th=
e term =1B$B!H=1B(Bre-authentication=1B$B!I=1B(B, something like:


 


The server MUST be able to send authentication trigger to the c=
lient when there is a mapping.  The authentication trigger
 MUST be integrity protected if there is a SA.


 


Yoshihiro Ohba


 <=
/o:p>






From:<=
span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"=
;,"sans-serif";mso-fareast-language:JA">
 Alper Yegin [mailto:alper.yegin@yegin.org] 

Sent: Wednesday, May 29, 2013 1:03 AM

To: Tirumaleswar Reddy

Cc: ohba yoshihiro; pcp@ietf.org

Subject: Re: [pcp] pcp auth requirements






 


Tiru,




 






I agree.






 






Alper






 






On May 28, 2013, at 2:01 PM, Tirumaleswar Reddy (t=
ireddy) wrote:















Hi Alper,






 =







[1] when the PCP server trigg=
ers re-authentication and SA is valid, if the PCP client does
 not respond then possibly after N number of re-tries PCP server may want t=
o give up and close the explicit mappings associated with the user. This wo=
uld handle the scenario where PCP client would have crashed or terminated o=
r connection lost for some reason
 or the user has logged off and some other user got the same IP address as =
the previous user.






 =







[2] Even in case 3, we may wa=
nt similar behavior as [1]. For Case 3, there could be a scenarios
 – where PCP server would want to inform the PCP client that external=
 IP address/port has changed, but the SA is expired. In this case PCP serve=
r would have to trigger re-auth. If re-auth is successful then send the map=
ping update or if there is no response
 from the client then proceed with deleting the explicit mappings after N n=
umber of tries.






 =







Case 3 could be an optimizati=
on to trigger re-authentication only when there is interesting
 update to be sent from the client or server and not to trigger re-authenti=
cation before SA expires .






 =







--Tiru.












From: Alper
 Yegin [mailto:alper.yegin@yegin.o=
rg] 

Sent: Thursday, Ma=
y 23, 2013 12:17 PM

To: yoshihiro.ohba@toshiba.co.jp

Cc: Tirumaleswar R=
eddy (tireddy); pcp@ietf.org

Subject: Re: [pcp]=
 pcp auth requirements










 






Yoshi,








 










You are right. In terms of EAP and RFC 5247, only the s=
econd case qualifies for "EAP re-authentication".










 










On the other hand, first and third case are not the sam=
e. 










And I'd conceptually think of the third case as a some =
sort of "re-authentication" (apparently not an "EAP re-authe=
ntication" per RFC
 5247).










 










Anyways, at least I'd like people to be aware of these =
three different cases -- even if we cannot find a proper name to all of the=
m.










 










Alper










 










 










 










On May 23, 2013, at 1:39 AM, <yoshihiro.ohba@toshiba.co.jp> wrote:<=
/o:p>

























Hi Alper,










 










When we talk about re-authentic=
ation, we should not care about whether there is a PCP session
 or not.










 










Please see the following defini=
tion in RFC 5247:










=1B$B!H=1B(B










   EAP Re-Authenticat=
ion










      =
EAP authentication between an EAP peer and a server with whom the










      =
EAP peer shares valid unexpired EAP keying material.=











=1B$B!H=1B(B










 










According to the above definiti=
on, if authentication is conducted over a live SA, it is re-authentication,
 otherwise it is not re-authentication.










 










Yoshihiro Ohba










 










 














From: Alper
 Yegin [mailto:alper.yegin@yegin.o=
rg] 

Sent: Thursday, Ma=
y 23, 2013 6:16 AM

To: ohba yoshihiro=


Cc: tireddy@cisco.com; pcp@ietf.org

Subject: Re: [pcp]=
 pcp auth requirements














 










Hi Yoshi,












 














Here are the three states:














 














0. Before PCP client and PCP server has initiated PCP s=
ession.














 














1. There is a PCP session and a live SA.














 














2. There is a PCP session, but no live SA (i.e., the la=
st used SA is already expired).














 














 














If we execute auth in state 0, we call it "(initia=
l) authentication".














Auth executed in state 1 is called "re-authenticai=
ton".














I'd call auth executed in state 2 a "re-authentica=
tion" as well, unless we want to give it a more specific name.














 














Alper














 














 














 














 














On May 22, 2013, at 11:16 AM, <yoshihiro.ohba@toshiba.co.jp> wrote:=




































Hi Alper,














 














I agree that we should allow un=
protected authentication trigger from the server, but we should
 distinguish authentication after expiration of SA from =1B$B!H=1B(Bre-auth=
entication=1B$B!I=1B(B.














 














Yoshihiro Ohba














 


















From: Alper
 Yegin [mailto:alper.yegin@yegin.o=
rg] 

Sent: Wednesday, M=
ay 22, 2013 4:22 PM

To: ohba yoshihiro=


Cc: tireddy@cisco.com; pcp@ietf.org

Subject: Re: [pcp]=
 pcp auth requirements


















 














 


















On May 21, 2013, at 10:14 AM, <yoshihiro.ohba@toshiba.co.jp> <yoshihiro.ohba@toshiba.co.jp&g=
t;
 wrote:













































Tiru,


















 


















In my analysis, Req-4-d-1 is ba=
sically introducing a three-state SA model for PCP: State 0:
  unavailable (or non-existent), State 1: partially available only for=
 triggering re-auth, and State 2: fully available. MSCHAPv2 password change=
 function is designed based on this model.


















 


















I am not going to get into deta=
ils about the three-state SA model, but even the three-state
 SA model will require re-auth trigger to be integrity protected.  


















 


















Having said that, I think the f=
ollowing requirement is sufficient for Req-4-d: =1B$B!H=1B=
(BThe
 server MUST be able to send an integrity protected re-authentication trigg=
er to the client.=1B$B!I=1B(B


















 




















 


















If there is no SA available, then the server can send a=
n un-protected re-auth trigger. We should allow that.


















This is equivalent to what happens at the very beginnin=
g before the very first authentication between the client and the server.


















 


















Alper


















 


















 


















 













































Regards,=



















Yoshihiro Ohba


















 


















 






















From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On
 Behalf Of Tirumalesw=
ar Reddy (tireddy)

Sent: Sunday, May =
19, 2013 2:24 AM

To: Alper Yegin; pcp@ietf.org

Subject: Re: [pcp]=
 pcp auth requirements






















 


















Hi Alper,


















 =



















Please see inline [TR]=



















 =

























From: Alper
 Yegin [mailto:alper.yegin@yegin.o=
rg] 

Sent: Tuesday, Apr=
il 30, 2013 12:53 PM

To: pcp@ietf.org

Subject: [pcp] pcp=
 auth requirements






















 















 &nb=
sp;    c.  If a server wants to send an unsolicited mes=
sage, but the


          pre=
vious security association has expired


 


          1.&=
nbsp; The server can continue to use the same SA to protect


         &nbs=
p;    messages pertaining to that mapping, even if the SA is=



         &nbs=
p;    technically expired.<=
/span>





"Exp=
ired" means "do not use (even if its still hanging around)".=
 


We not on=
ly do not need to use expired SAs, but also using something expired in any =
sense is plain wrong -- unless someone wants to redefine what "expired=
" means.


 


[TR]


For example if we consider MSCHAPv2, there is configuratio=
n option where server accepts the challenge-response from the client even i=
f the password is expired and allows it be changed. 


 


Please clarify if you have some attack in mind that would =
cause problems using expired SA.

 


[/TR]


 


 &nb=
sp;            -&nbs=
p; Such server notifications will not change state in the


         &nbs=
p;       PCP client.


 


         &nbs=
p;    -  The notification could be a trigger for the cl=
ient to


         &nbs=
p;       re-authenticate.  





Here the =
document is getting into some solution description.





And as fo=
r such a solution:





Instead o=
f sending a notification that is protected with an expired SA to mean "=
;re-authenticate", why not send an explicit message that says "re=
-authenticate"?


 


[TR] 


The client has trusted the PCP server sometime back using =
mutual authentication, so it can assume the integrity protected PCP respons=
e using expired SA is coming from the same PCP server and not from some att=
acker posing as PCP server.


[/TR]


 


What is g=
ained by appearing to use an expired SA (but in fact not really using it! b=
ecause the payload of the notification is not consumed by the receiver).







 &nb=
sp;            =
   For example, if the server indicates=



         &nbs=
p;       that external IP address/port has ch=
anged, the PCP


         &nbs=
p;       client can then re-authenticate with=
 the server to


         &nbs=
p;       confirm if the external IP address/p=
ort for the mapping


         &nbs=
p;       has indeed changed.


 


          2.&=
nbsp; The server can optionally trigger re-authentication with


         &nbs=
p;    the client.











 






















 






















Yes, that's the solution. If the server has something to =
send to the client, and there's no live SA, then the server
 first needs to trigger re-auth, setup a fresh SA, then send whatever it wa=
nts to send to the client.


















 










[TR]


 


We have updated this requirement in the new draft, please =
have a look.


 


Best Regards,


--Tiru.


 


[/TR]










 






















 






















Alper






















 






















 






















 




































 








--_000_674F70E5F2BE564CB06B6901FD3DD78B12D138C5tgxml338toshiba_--


From cheshire@apple.com  Tue May 28 21:42:01 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9229B11E80DF for ; Tue, 28 May 2013 21:42:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMcNY6qkQ8rP for ; Tue, 28 May 2013 21:41:55 -0700 (PDT)
Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1174111E80D3 for ; Tue, 28 May 2013 21:41:55 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MNJ0089VMDUWFB1@mail-out.apple.com> for pcp@ietf.org; Tue, 28 May 2013 21:41:54 -0700 (PDT)
X-AuditID: 1180715a-b7f506d000007d18-f1-51a58712fbbd
Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay6.apple.com (Apple SCV relay) with SMTP id 11.73.32024.21785A15; Tue, 28 May 2013 21:41:54 -0700 (PDT)
Received: from [17.153.101.223] (unknown [17.153.101.223]) by kencur.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MNJ00L35MDUUH30@kencur.apple.com> for pcp@ietf.org; Tue, 28 May 2013 21:41:54 -0700 (PDT)
From: Stuart Cheshire 
In-reply-to: <519C7EAD.6030408@viagenie.ca>
Date: Tue, 28 May 2013 21:41:53 -0700
Message-id: <41825984-3572-45E5-BD1E-8D20FBEB9E1D@apple.com>
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D1E@xmb-rcd-x04.cisco.com> <519C7EAD.6030408@viagenie.ca>
To: Simon Perreault 
X-Mailer: Apple Mail (2.1085)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUiON1OTVeofWmgwY6fShaTj/1mdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsYXR9gKlrNVrNuj3cD4i6WLkZNDQsBEYurV7YwQtpjEhXvr 2boYuTiEBJqYJFauW80E4cxhkvgw5w47SJWwgIHEwf+7mUFsXgFDiSXXt4DFmQW0JNbvPM4E YrMB2S8+X2EDsTkFtCUaj38Di7MIqEq8fD2PEaJeQOLmiT5mCFtb4sm7C6wQM20kmhefA4sL CeRK9F4+AjSfg0MEaFfvbaijZSV23jnNMoFRYBaSK2YhuWIWkqkLGJlXMQoUpeYkVprpJRYU 5KTqJefnbmIEhV1DYdQOxoblVocYBTgYlXh4V3xfEijEmlhWXJl7iFGCg1lJhDdVcGmgEG9K YmVValF+fFFpTmrxIUZpDhYlcV4TG6CUQHpiSWp2ampBahFMlomDU6qBUfKcSejp4mv/bVMu rO3s5F1/aOFawa6FgrnxDY3lNlZHz+umpVknr6ssFHW7euR5fJT3/dWbZ/076+X612pFputV lTUvC29ynbZeE5V975DH1pADk7897Ind7uJ/IacrYMeaBs4wA6VHnSGCBXfzAxzKespWqIbt dlvx+zujwaZr/17en1v2SomlOCPRUIu5qDgRAIJSMqg3AgAA
Cc: pcp@ietf.org
Subject: Re: [pcp] Stability of external 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: Wed, 29 May 2013 04:42:01 -0000

On 22 May 2013, at 1:15, Simon Perreault wrote:

> Maybe you are thinking of RFC 6888 REQ-2:
> 
>   REQ-2:  A CGN MUST have a default "IP address pooling" behavior of
>      "Paired" (as defined in Section 4.1 of [RFC4787]).
> 
> Is there any meaningful difference between that and what Stuart is suggesting? If not, then I prefer reusing RFC4787 terminology.
> 
> Simon

I'm happy for you to suggest specific wording for the erratum.

I'd like us to clarify this, because it affects the assumptions clients can make.

If a client has to assume it may get different external addresses for different ports, then it significantly complicates things like dynamic DNS updates, because the client can't assume a single hostname for all its mapped ports.

Stuart Cheshire


From simon.perreault@viagenie.ca  Wed May 29 01:05:05 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FED21F91A5 for ; Wed, 29 May 2013 01:05:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.5
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, 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 K4QM4UxvLvwe for ; Wed, 29 May 2013 01:05:04 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A47BA21F9195 for ; Wed, 29 May 2013 01:05:04 -0700 (PDT)
Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:245a:a34b:600:fe8b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D40B4414AD; Wed, 29 May 2013 04:05:03 -0400 (EDT)
Message-ID: <51A5B6BF.3000704@viagenie.ca>
Date: Wed, 29 May 2013 10:05:19 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Stuart Cheshire 
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D1E@xmb-rcd-x04.cisco.com> <519C7EAD.6030408@viagenie.ca> <41825984-3572-45E5-BD1E-8D20FBEB9E1D@apple.com>
In-Reply-To: <41825984-3572-45E5-BD1E-8D20FBEB9E1D@apple.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: pcp@ietf.org
Subject: Re: [pcp] Stability of external 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: Wed, 29 May 2013 08:05:05 -0000

Le 2013-05-29 06:41, Stuart Cheshire a écrit :
> If a client has to assume it may get different external addresses for
> different ports, then it significantly complicates things like
> dynamic DNS updates, because the client can't assume a single
> hostname for all its mapped ports.

The thing is that PCP cannot require much more from NATs than what is 
already in RFC 4787s and 6888.

RFC 4787 requires of all NATs:

    REQ-2:  It is RECOMMENDED that a NAT have an "IP address pooling"
       behavior of "Paired".

RFC 6888 makes this requirement stronger for CGNs in particular:

    REQ-2:  A CGN MUST have a default "IP address pooling" behavior of
       "Paired"

Assume we say: PCP-controlled NATs MUST have an "IP address pooling" 
behavior of "Paired".

Even then a PCP client or, more generally, a host behind a NAT cannot 
rely on its external address being always the same for a host of reasons:

- If all ports on an external address get allocated, new mappings will 
have to either be rejected or move to a new external address. The latter 
is what's usually preferred and implemented.

- Local policy. Dumb example: VoIP goes to provider A, bulk goes to B.

- etc. etc. etc.

IMHO it's good advice to recommend a particular behaviour for NATs, but 
it's also bad advice to recommend that clients rely on it.

If an app depends on this NAT behaviour, then it should use the 
PREFER_FAILURE option. I can see that working for DNS updates too. Once 
the client gets an external address, it requests that external address 
for all future mappings. But since ANNOUNCE is not reliable, it would 
need some heuristics to gracefully handle external address changes.

Simon

From simon.perreault@viagenie.ca  Wed May 29 01:40:38 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB7321F90C6 for ; Wed, 29 May 2013 01:40:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Level: 
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075,  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 p7SwhFTOFD5g for ; Wed, 29 May 2013 01:40:38 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 44C2921F90EE for ; Wed, 29 May 2013 01:40:38 -0700 (PDT)
Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:245a:a34b:600:fe8b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4BFD4414AD for ; Wed, 29 May 2013 04:40:34 -0400 (EDT)
Message-ID: <51A5BF11.5030100@viagenie.ca>
Date: Wed, 29 May 2013 10:40:49 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: pcp@ietf.org
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 29 May 2013 08:40:38 -0000

Le 2013-05-29 01:24, Stuart Cheshire a écrit :
> 
>
> WG participants, please review and comment, and if there are no objections we can issue a WGLC.

No objection.

It could be useful to point out that the set of supported external 
address families depends on the internal address family. That is, 
sending the same request over IPv4 and IPv6 could yield different results.

Simon

From repenno@cisco.com  Wed May 29 02:34:30 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A1B21F9121 for ; Wed, 29 May 2013 02:34:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edNWBNbeeyjh for ; Wed, 29 May 2013 02:34:25 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0B321F90CD for ; Wed, 29 May 2013 02:34:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2243; q=dns/txt; s=iport; t=1369820065; x=1371029665; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=qV5p26EKySMY761cEnv6zABG7q7nEheHZBMQZJTeBug=; b=Ev6gAJIvplLpcb+8MYYkuJ0tulvYENx1elKgd9bbNP3hAzqG7KmQK6O0 kQ+/evIJME2c/k59RrxxOqpOZWUpE2LztCCFgWhNaxV/HDhsxJliQ8Mv4 EZEExqjyJZ7ebwgXcd6pgk+kV1+S0rXuI4lND9in9CVKnpCBU7FaAxjav Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkAHAMXKpVGtJXG+/2dsb2JhbABagwkwwXuBBhZ0giUBBAEBAWsLEgEIIksLJQIEAQ0FCIgFDLo3BI5kMQeCc2EDiGegFIMPgic
X-IronPort-AV: E=Sophos;i="4.87,763,1363132800"; d="scan'208";a="213172394"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 29 May 2013 09:34:25 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4T9YOZN007640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 May 2013 09:34:24 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 29 May 2013 04:34:24 -0500
From: "Reinaldo Penno (repenno)" 
To: Simon Perreault , Stuart Cheshire 
Thread-Topic: [pcp] Stability of external address
Thread-Index: AQHOXCbfJ8YSqv3vAU2fp53RUGUle5kcIgmA///mjoA=
Date: Wed, 29 May 2013 09:34:24 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040908CE78@xmb-rcd-x04.cisco.com>
In-Reply-To: <51A5B6BF.3000704@viagenie.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.86.240.52]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "pcp@ietf.org" 
Subject: Re: [pcp] Stability of external 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: Wed, 29 May 2013 09:34:30 -0000

On 5/29/13 5:05 AM, "Simon Perreault"  wrote:

>Le 2013-05-29 06:41, Stuart Cheshire a =E9crit :
>> If a client has to assume it may get different external addresses for
>> different ports, then it significantly complicates things like
>> dynamic DNS updates, because the client can't assume a single
>> hostname for all its mapped ports.
>
>The thing is that PCP cannot require much more from NATs than what is
>already in RFC 4787s and 6888.
>
>RFC 4787 requires of all NATs:
>
>    REQ-2:  It is RECOMMENDED that a NAT have an "IP address pooling"
>       behavior of "Paired".
>
>RFC 6888 makes this requirement stronger for CGNs in particular:
>
>    REQ-2:  A CGN MUST have a default "IP address pooling" behavior of
>       "Paired"
>
>Assume we say: PCP-controlled NATs MUST have an "IP address pooling"
>behavior of "Paired".
>
>Even then a PCP client or, more generally, a host behind a NAT cannot
>rely on its external address being always the same for a host of reasons:
>
>- If all ports on an external address get allocated, new mappings will
>have to either be rejected or move to a new external address. The latter
>is what's usually preferred and implemented.
>
>- Local policy. Dumb example: VoIP goes to provider A, bulk goes to B.
>
>- etc. etc. etc.
>
>IMHO it's good advice to recommend a particular behaviour for NATs, but
>it's also bad advice to recommend that clients rely on it.
>
>If an app depends on this NAT behaviour, then it should use the
>PREFER_FAILURE option. I can see that working for DNS updates too. Once
>the client gets an external address, it requests that external address
>for all future mappings. But since ANNOUNCE is not reliable, it would
>need some heuristics to gracefully handle external address changes.


ANNOUNCE?=20


PREFER_FAILURE works for PCP enabled flows, but regular outgoing flows can
not get feedback if their external mapping broke APP or not. Unless we
create an notification from server to client to let it know about APP
breakage through PCP.



>
>Simon
>_______________________________________________
>pcp mailing list
>pcp@ietf.org
>https://www.ietf.org/mailman/listinfo/pcp


From simon.perreault@viagenie.ca  Wed May 29 02:49:55 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B498321F91BC for ; Wed, 29 May 2013 02:49:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Level: 
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060,  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 jr2r0-pr-jy6 for ; Wed, 29 May 2013 02:49:55 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4E41221F9048 for ; Wed, 29 May 2013 02:49:55 -0700 (PDT)
Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:245a:a34b:600:fe8b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A42AB44B2C; Wed, 29 May 2013 05:49:53 -0400 (EDT)
Message-ID: <51A5CF4F.9090709@viagenie.ca>
Date: Wed, 29 May 2013 11:50:07 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Reinaldo Penno (repenno)" 
References: <45A697A8FFD7CF48BCF2BE7E106F06040908CE78@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040908CE78@xmb-rcd-x04.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] Stability of external 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: Wed, 29 May 2013 09:49:55 -0000

Le 2013-05-29 11:34, Reinaldo Penno (repenno) a écrit :
>> If an app depends on this NAT behaviour, then it should use the
>> PREFER_FAILURE option. I can see that working for DNS updates too. Once
>> the client gets an external address, it requests that external address
>> for all future mappings. But since ANNOUNCE is not reliable, it would
>> need some heuristics to gracefully handle external address changes.
>
> ANNOUNCE?

I was assuming that the DNS update app would create a dummy mapping in 
order to get and lock the external address. Then the PCP server would 
send it ANNOUNCEs when things change, would it not?

Simon

From repenno@cisco.com  Wed May 29 02:55:41 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E813621F92A5 for ; Wed, 29 May 2013 02:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOVlJacKkrMY for ; Wed, 29 May 2013 02:55:28 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1E63321F9298 for ; Wed, 29 May 2013 02:55:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1094; q=dns/txt; s=iport; t=1369821328; x=1371030928; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=VZpKH7A5qFEWoO8pShEkEullXdJ7hPC9vHw5qJ6pTFs=; b=bHOrrROWj5+c+29ukYbkibZrKzcWJ/Rxe6rIPqb6+meuFz9itW1FLDa3 sGQawrhkUU8gsn7Pi7BlMwFlnDO2Jxsvjw8e4oSHHd2Y5ViLA0N84uRH1 rVN3z4oUEB284fbzFV5WHGbxPdBgIi6zyc/ST6kC9fKBciNI9Ezqq6b6i 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiwFAFXPpVGtJXG+/2dsb2JhbABagwnCK4EGFnSCJQEEeRIBCCJWJQIEDgUIiAW6QI5kMQeCc2EDiGeLA5URgw+CJw
X-IronPort-AV: E=Sophos;i="4.87,763,1363132800"; d="scan'208";a="216156505"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 29 May 2013 09:55:07 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4T9t7DE032460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 May 2013 09:55:07 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Wed, 29 May 2013 04:55:06 -0500
From: "Reinaldo Penno (repenno)" 
To: Simon Perreault 
Thread-Topic: [pcp] Stability of external address
Thread-Index: AQHOXCbfJ8YSqv3vAU2fp53RUGUle5kcIgmA///mjoCAADa5gP//zxeA
Date: Wed, 29 May 2013 09:55:06 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040908CEEB@xmb-rcd-x04.cisco.com>
In-Reply-To: <51A5CF4F.9090709@viagenie.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.86.240.52]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <32E6EFBED83B93439E537A41FCB5BE14@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] Stability of external 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: Wed, 29 May 2013 09:55:41 -0000

On 5/29/13 6:50 AM, "Simon Perreault"  wrote:

>Le 2013-05-29 11:34, Reinaldo Penno (repenno) a =E9crit :
>>> If an app depends on this NAT behaviour, then it should use the
>>> PREFER_FAILURE option. I can see that working for DNS updates too. Once
>>> the client gets an external address, it requests that external address
>>> for all future mappings. But since ANNOUNCE is not reliable, it would
>>> need some heuristics to gracefully handle external address changes.
>>
>> ANNOUNCE?
>
>I was assuming that the DNS update app would create a dummy mapping in
>order to get and lock the external address. Then the PCP server would
>send it ANNOUNCEs when things change, would it not?

If just the mapping changes it will send an unsolicited response. If an
event happens that affects all PCP Clients such as a NAT reboot, it will
send an ANNOUNCE.

I'm still not clear how it will detect regular flows breaking APP if app
relies on those flows also having the same external IP. Should they also
create dummy (PEER) mappings?

>
>Simon


From simon.perreault@viagenie.ca  Wed May 29 04:19:15 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A76721F9298 for ; Wed, 29 May 2013 04:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050,  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 KPcSbxTaV+zF for ; Wed, 29 May 2013 04:19:14 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id B123021F928C for ; Wed, 29 May 2013 04:19:14 -0700 (PDT)
Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:245a:a34b:600:fe8b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A7D3044B2C; Wed, 29 May 2013 07:19:13 -0400 (EDT)
Message-ID: <51A5E43F.7060702@viagenie.ca>
Date: Wed, 29 May 2013 13:19:27 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Reinaldo Penno (repenno)" 
References: <45A697A8FFD7CF48BCF2BE7E106F06040908CEEB@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040908CEEB@xmb-rcd-x04.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] Stability of external 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: Wed, 29 May 2013 11:19:15 -0000

Le 2013-05-29 11:55, Reinaldo Penno (repenno) a écrit :
>>>> If an app depends on this NAT behaviour, then it should use the
>>>> PREFER_FAILURE option. I can see that working for DNS updates too. Once
>>>> the client gets an external address, it requests that external address
>>>> for all future mappings. But since ANNOUNCE is not reliable, it would
>>>> need some heuristics to gracefully handle external address changes.
>>>
>>> ANNOUNCE?
>>
>> I was assuming that the DNS update app would create a dummy mapping in
>> order to get and lock the external address. Then the PCP server would
>> send it ANNOUNCEs when things change, would it not?
>
> If just the mapping changes it will send an unsolicited response. If an
> event happens that affects all PCP Clients such as a NAT reboot, it will
> send an ANNOUNCE.

Right, right. That's what I meant. There's a mechanism that will keep 
the DNS updater informed.

> I'm still not clear how it will detect regular flows breaking APP if app
> relies on those flows also having the same external IP. Should they also
> create dummy (PEER) mappings?

If an app cares about those things, it will not only have to create 
dummy PEER mappings, but real PEER mappings that it will create with the 
same suggested external address and the PREFER_FAILURE option. That's 
the only way to be sure.

Simon

From tireddy@cisco.com  Wed May 29 06:10:05 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F63521F8F12 for ; Wed, 29 May 2013 06:10:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkwBapTDegfT for ; Wed, 29 May 2013 06:09:59 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 20E2C21F8F63 for ; Wed, 29 May 2013 06:09:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=93930; q=dns/txt; s=iport; t=1369832998; x=1371042598; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=b1/dQWyvFsLOv9R6dMRZllu1C9AvrCsi7zIvyTp2Vb0=; b=hlRdTmiSIL6MOo6pt7S/J2fyFaRRTwrV+XwY63g4G9qUZxNUE8DruhfA S3dXfnqaDY1xhl/rgptPBC04YByEDB3GlXIDTLqTBFHFMunr+i0mL2xfM qTbTm7rBVoSWSX+X0Fc52KlDD919Mnn3+ATFy9yicbT1S46EppV8jGDHK 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkMHAJP9pVGtJXHB/2dsb2JhbABXA4JFRDDBe4EKFnSCIwEBAQQtPw0QAgEIEQQBAQsOCAEGBzIUCQgCBAENBQgTh3K6UI5kMQYBBgsGAYJbYQOoe4MPgic
X-IronPort-AV: E=Sophos;i="4.87,764,1363132800";  d="scan'208,217";a="216245440"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 29 May 2013 13:09:46 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4TD9kcB002675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 May 2013 13:09:46 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Wed, 29 May 2013 08:09:46 -0500
From: "Tirumaleswar Reddy (tireddy)" 
To: "yoshihiro.ohba@toshiba.co.jp" , "alper.yegin@yegin.org" 
Thread-Topic: [pcp] pcp auth requirements
Thread-Index: AQHORaVDKQ3d6G8P5kumseyWFL/c3ZkK012AgATaxwCAAZScgIAADysAgADZvgCAABdfgIAAiEiAgAKXlICABd80AIAAfEGAgADlvyA=
Date: Wed, 29 May 2013 13:09:45 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A14B75E78@xmb-rcd-x10.cisco.com>
References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B12D0CD38@tgxml338.toshiba.local>  <674F70E5F2BE564CB06B6901FD3DD78B12D0FD42@tgxml338.toshiba.local>  <674F70E5F2BE564CB06B6901FD3DD78B12D1002A@tgxml338.toshiba.local>  <913383AAA69FF945B8F946018B75898A14B75207@xmb-rcd-x10.cisco.com>  <674F70E5F2BE564CB06B6901FD3DD78B12D138C5@tgxml338.toshiba.local>
In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B12D138C5@tgxml338.toshiba.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.103.238.111]
Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A14B75E78xmbrcdx10ciscoc_"
MIME-Version: 1.0
Cc: "pcp@ietf.org" 
Subject: Re: [pcp] pcp auth requirements
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, 29 May 2013 13:10:05 -0000

--_000_913383AAA69FF945B8F946018B75898A14B75E78xmbrcdx10ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks Yoshi for the text :

OLD :

REQ-4-

      d.  If the server wants to send an unsolicited message, but the
          previous security association for the mapping
          identified in the original PCP request has expired

          1.  The server can continue to use the same SA to protect
              messages pertaining to that mapping, even if the SA is
              technically expired.

              -  Such server notifications will not change state in the
                 PCP client.

              -  The notification could be a trigger for the client to
                 re-authenticate.  For example, if the server indicates
                 that external IP address/port has changed, the PCP
                 client can then re-authenticate with the server to
                 confirm if the external IP address/port for the mapping
                 has indeed changed.

          2.  The server MUST be able to optionally trigger re-
              authentication with the client.

NEW :

REQ-4-

      d. The server MUST be able to trigger authentication with the client.=
 The unsolicited message for authentication trigger MUST be integrity prote=
cted if there is valid unexpired SA.

--Tiru.
From: yoshihiro.ohba@toshiba.co.jp [mailto:yoshihiro.ohba@toshiba.co.jp]
Sent: Wednesday, May 29, 2013 4:57 AM
To: alper.yegin@yegin.org; Tirumaleswar Reddy (tireddy)
Cc: pcp@ietf.org
Subject: Re: [pcp] pcp auth requirements

OK.  Then I suggest forming a requirement without using the term "re-authen=
tication", something like:

The server MUST be able to send authentication trigger to the client when t=
here is a mapping.  The authentication trigger MUST be integrity protected =
if there is a SA.

Yoshihiro Ohba

From: Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Wednesday, May 29, 2013 1:03 AM
To: Tirumaleswar Reddy
Cc: ohba yoshihiro; pcp@ietf.org
Subject: Re: [pcp] pcp auth requirements

Tiru,

I agree.

Alper

On May 28, 2013, at 2:01 PM, Tirumaleswar Reddy (tireddy) wrote:

Hi Alper,

[1] when the PCP server triggers re-authentication and SA is valid, if the =
PCP client does not respond then possibly after N number of re-tries PCP se=
rver may want to give up and close the explicit mappings associated with th=
e user. This would handle the scenario where PCP client would have crashed =
or terminated or connection lost for some reason or the user has logged off=
 and some other user got the same IP address as the previous user.

[2] Even in case 3, we may want similar behavior as [1]. For Case 3, there =
could be a scenarios - where PCP server would want to inform the PCP client=
 that external IP address/port has changed, but the SA is expired. In this =
case PCP server would have to trigger re-auth. If re-auth is successful the=
n send the mapping update or if there is no response from the client then p=
roceed with deleting the explicit mappings after N number of tries.

Case 3 could be an optimization to trigger re-authentication only when ther=
e is interesting update to be sent from the client or server and not to tri=
gger re-authentication before SA expires .

--Tiru.
From: Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Thursday, May 23, 2013 12:17 PM
To: yoshihiro.ohba@toshiba.co.jp
Cc: Tirumaleswar Reddy (tireddy); pcp@ietf.org
Subject: Re: [pcp] pcp auth requirements

Yoshi,

You are right. In terms of EAP and RFC 5247, only the second case qualifies=
 for "EAP re-authentication".

On the other hand, first and third case are not the same.
And I'd conceptually think of the third case as a some sort of "re-authenti=
cation" (apparently not an "EAP re-authentication" per RFC 5247).

Anyways, at least I'd like people to be aware of these three different case=
s -- even if we cannot find a proper name to all of them.

Alper



On May 23, 2013, at 1:39 AM, > wrote:


Hi Alper,

When we talk about re-authentication, we should not care about whether ther=
e is a PCP session or not.

Please see the following definition in RFC 5247:
"
   EAP Re-Authentication
      EAP authentication between an EAP peer and a server with whom the
      EAP peer shares valid unexpired EAP keying material.
"

According to the above definition, if authentication is conducted over a li=
ve SA, it is re-authentication, otherwise it is not re-authentication.

Yoshihiro Ohba


From: Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Thursday, May 23, 2013 6:16 AM
To: ohba yoshihiro
Cc: tireddy@cisco.com; pcp@ietf.org
Subject: Re: [pcp] pcp auth requirements

Hi Yoshi,

Here are the three states:

0. Before PCP client and PCP server has initiated PCP session.

1. There is a PCP session and a live SA.

2. There is a PCP session, but no live SA (i.e., the last used SA is alread=
y expired).


If we execute auth in state 0, we call it "(initial) authentication".
Auth executed in state 1 is called "re-authenticaiton".
I'd call auth executed in state 2 a "re-authentication" as well, unless we =
want to give it a more specific name.

Alper




On May 22, 2013, at 11:16 AM, > wrote:



Hi Alper,

I agree that we should allow unprotected authentication trigger from the se=
rver, but we should distinguish authentication after expiration of SA from =
"re-authentication".

Yoshihiro Ohba

From: Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Wednesday, May 22, 2013 4:22 PM
To: ohba yoshihiro
Cc: tireddy@cisco.com; pcp@ietf.org
Subject: Re: [pcp] pcp auth requirements


On May 21, 2013, at 10:14 AM, > > wrote:




Tiru,

In my analysis, Req-4-d-1 is basically introducing a three-state SA model f=
or PCP: State 0:  unavailable (or non-existent), State 1: partially availab=
le only for triggering re-auth, and State 2: fully available. MSCHAPv2 pass=
word change function is designed based on this model.

I am not going to get into details about the three-state SA model, but even=
 the three-state SA model will require re-auth trigger to be integrity prot=
ected.

Having said that, I think the following requirement is sufficient for Req-4=
-d: "The server MUST be able to send an integrity protected re-authenticati=
on trigger to the client."


If there is no SA available, then the server can send an un-protected re-au=
th trigger. We should allow that.
This is equivalent to what happens at the very beginning before the very fi=
rst authentication between the client and the server.

Alper







Regards,
Yoshihiro Ohba


From: pcp-bounces@ietf.org [mailto:pcp-bounces=
@ietf.org] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Sunday, May 19, 2013 2:24 AM
To: Alper Yegin; pcp@ietf.org
Subject: Re: [pcp] pcp auth requirements

Hi Alper,

Please see inline [TR]

From: Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Tuesday, April 30, 2013 12:53 PM
To: pcp@ietf.org
Subject: [pcp] pcp auth requirements




      c.  If a server wants to send an unsolicited message, but the

          previous security association has expired



          1.  The server can continue to use the same SA to protect

              messages pertaining to that mapping, even if the SA is

              technically expired.


"Expired" means "do not use (even if its still hanging around)".

We not only do not need to use expired SAs, but also using something expire=
d in any sense is plain wrong -- unless someone wants to redefine what "exp=
ired" means.



[TR]

For example if we consider MSCHAPv2, there is configuration option where se=
rver accepts the challenge-response from the client even if the password is=
 expired and allows it be changed.



Please clarify if you have some attack in mind that would cause problems us=
ing expired SA.



[/TR]



              -  Such server notifications will not change state in the

                 PCP client.



              -  The notification could be a trigger for the client to

                 re-authenticate.


Here the document is getting into some solution description.


And as for such a solution:


Instead of sending a notification that is protected with an expired SA to m=
ean "re-authenticate", why not send an explicit message that says "re-authe=
nticate"?



[TR]

The client has trusted the PCP server sometime back using mutual authentica=
tion, so it can assume the integrity protected PCP response using expired S=
A is coming from the same PCP server and not from some attacker posing as P=
CP server.

[/TR]



What is gained by appearing to use an expired SA (but in fact not really us=
ing it! because the payload of the notification is not consumed by the rece=
iver).



                 For example, if the server indicates

                 that external IP address/port has changed, the PCP

                 client can then re-authenticate with the server to

                 confirm if the external IP address/port for the mapping

                 has indeed changed.



          2.  The server can optionally trigger re-authentication with

              the client.


Yes, that's the solution. If the server has something to send to the client=
, and there's no live SA, then the server first needs to trigger re-auth, s=
etup a fresh SA, then send whatever it wants to send to the client.


[TR]



We have updated this requirement in the new draft, please have a look.



Best Regards,

--Tiru.



[/TR]


Alper





--_000_913383AAA69FF945B8F946018B75898A14B75E78xmbrcdx10ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

















From: yoshihir=
o.ohba@toshiba.co.jp [mailto:yoshihiro.ohba@toshiba.co.jp]


Sent: Wednesday, May 29, 2013 4:57 AM

To: alper.yegin@yegin.org; Tirumaleswar Reddy (tireddy)

Cc: pcp@ietf.org

Subject: Re: [pcp] pcp auth requirements






 


OK.  Then I suggest forming a requirement without using=
 the term “re-authentication”, something like:


 


The server MUST be able to send authentication trigger to th=
e client when there is a mapping.  The authentication trigger MUST be =
integrity protected if there
 is a SA.


 


Yoshihiro Ohba


 






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


Sent: Wednesday, May 29, 2013 1:03 AM

To: Tirumaleswar Reddy

Cc: ohba yoshihiro; pcp@ietf.org

Subject: Re: [pcp] pcp auth requirements






 


Tiru,




 






I agree.






 






Alper






 






On May 28, 2013, at 2:01 PM, Tirumaleswar Reddy (tireddy) wrote:





 






Hi Alper,






 






[1] when the PCP server triggers re-authenti=
cation and SA is valid, if the PCP client does not respond
 then possibly after N number of re-tries PCP server may want to give up an=
d close the explicit mappings associated with the user. This would handle t=
he scenario where PCP client would have crashed or terminated or connection=
 lost for some reason or the user
 has logged off and some other user got the same IP address as the previous=
 user.






 






[2] Even in case 3, we may want similar beha=
vior as [1]. For Case 3, there could be a scenarios – where
 PCP server would want to inform the PCP client that external IP address/po=
rt has changed, but the SA is expired. In this case PCP server would have t=
o trigger re-auth. If re-auth is successful then send the mapping update or=
 if there is no response from the
 client then proceed with deleting the explicit mappings after N number of =
tries.






 






Case 3 could be an optimization to trigger r=
e-authentication only when there is interesting update to
 be sent from the client or server and not to trigger re-authentication bef=
ore SA expires .






 






--Tiru.












From: Alper
 Yegin [mailto:alper.yegin@yegin.o=
rg] 

Sent: Thursday, Ma=
y 23, 2013 12:17 PM

To: yoshihiro.ohba@toshiba.co.jp

Cc: Tirumaleswar R=
eddy (tireddy); pcp@ietf.org

Subject: Re: [pcp]=
 pcp auth requirements










 






Yoshi,








 










You are right. In terms of EAP and RFC 5247, only the second case qualif=
ies for "EAP re-authentication".










 










On the other hand, first and third case are not the same. 










And I'd conceptually think of the third case as a some sort of "re-=
authentication" (apparently not an "EAP re-authentication" p=
er
 RFC 5247).










 










Anyways, at least I'd like people to be aware of these three different c=
ases -- even if we cannot find a proper name to all of them.










 










Alper










 










 










 










On May 23, 2013, at 1:39 AM, <yoshihiro.ohba@toshiba.co.jp> wrote:









<=
br>













Hi Alper,










 










When we talk about re-authentication, we shoul=
d not care about whether there is a PCP session or not.<=
/span>










 










Please see the following definition in RFC 524=
7:










“










   EAP Re-Authentication<=
/o:p>










      EAP authenticat=
ion between an EAP peer and a server with whom the<=
/p>









      EAP peer shares=
 valid unexpired EAP keying material.










“










 










According to the above definition, if authenti=
cation is conducted over a live SA, it is re-authentication,
 otherwise it is not re-authentication.










 










Yoshihiro Ohba










 










 














From: Alper
 Yegin [mailto:alper.yegin@yegin.o=
rg] 

Sent: Thursday, Ma=
y 23, 2013 6:16 AM

To: ohba yoshihiro=


Cc: tireddy@cisco.com; pcp@ietf.org

Subject: Re: [pcp]=
 pcp auth requirements














 










Hi Yoshi,












 














Here are the three states:














 














0. Before PCP client and PCP server has initiated PCP session.














 














1. There is a PCP session and a live SA.














 














2. There is a PCP session, but no live SA (i.e., the last used SA is alr=
eady expired).














 














 














If we execute auth in state 0, we call it "(initial) authentication=
".














Auth executed in state 1 is called "re-authenticaiton".














I'd call auth executed in state 2 a "re-authentication" as wel=
l, unless we want to give it a more specific name.














 














Alper














 














 














 














 














On May 22, 2013, at 11:16 AM, <yoshihiro.ohba@toshiba.co.jp> wrote:













<=
br>



















Hi Alper,














 














I agree that we should allow unprotected authe=
ntication trigger from the server, but we should distinguish
 authentication after expiration of SA from “re-authentication”=
.














 














Yoshihiro Ohba














 


















From: Alper
 Yegin [mailto:alper.yegin@yegin.o=
rg] 

Sent: Wednesday, M=
ay 22, 2013 4:22 PM

To: ohba yoshihiro=


Cc: tireddy@cisco.com; pcp@ietf.org

Subject: Re: [pcp]=
 pcp auth requirements


















 














 


















On May 21, 2013, at 10:14 AM, <yoshihiro.ohba@toshiba.co.jp> <yoshihiro.ohba@toshiba.co.jp>
 wrote:

















<=
br>

























Tiru,


















 


















In my analysis, Req-4-d-1 is basically introdu=
cing a three-state SA model for PCP: State 0:  unavailable
 (or non-existent), State 1: partially available only for triggering re-aut=
h, and State 2: fully available. MSCHAPv2 password change function is desig=
ned based on this model.


















 


















I am not going to get into details about the t=
hree-state SA model, but even the three-state SA model will
 require re-auth trigger to be integrity protected.  =



















 


















Having said that, I think the following requir=
ement is sufficient for Req-4-d: “The
 server MUST be able to send an integrity protected re-authentication trigg=
er to the client.”


















 




















 


















If there is no SA available, then the server can send an un-protected re=
-auth trigger. We should allow that.


















This is equivalent to what happens at the very beginning before the very=
 first authentication between the client and the server.<=
/p>

















 


















Alper


















 


















 


















 

















<=
br>

























Regards,


















Yoshihiro Ohba


















 


















 






















From: pcp-bounces@ietf.org =
[mailto:pcp-bounces@ietf.org=
] On
 Behalf Of Tirumalesw=
ar Reddy (tireddy)

Sent: Sunday, May =
19, 2013 2:24 AM

To: Alper Yegin; pcp@ietf.org

Subject: Re: [pcp]=
 pcp auth requirements






















 


















Hi Alper,


















 


















Please see inline [TR]


















 
























From: Alper
 Yegin [mailto:alper.yegin@yegin.o=
rg] 

Sent: Tuesday, Apr=
il 30, 2013 12:53 PM

To: pcp@ietf.org

Subject: [pcp] pcp=
 auth requirements






















 















      c.  If a server wants to s=
end an unsolicited message, but the


    &nb=
sp;     previous security association has expired<=
/span><=
/pre>

 


   &nbs=
p;      1.  The server can continue to use th=
e same SA to protect   &nbs=
p;          messages pertainin=
g to that mapping, even if the SA is


   &nbs=
p;          technically expire=
d.





"Expired" means "do not use (even if its still =
hanging around)". 


We not only do not need to use expired SAs, but also using something=
 expired in any sense is plain wrong -- unless someone wants to redefine wh=
at "expired" means.


 


[TR]


For example if we cons=
ider MSCHAPv2, there is configuration option where server accepts the chall=
enge-response from the client even if the password is expired and allows it=
 be changed. =



 


Please clarify if you =
have some attack in mind that would cause problems using expired SA.=



 


[/TR]


 


           &n=
bsp;  -  Such server notifications will not change state in the

   &nbs=
p;             =
PCP client.


 


   &nbs=
p;          -  The notifi=
cation could be a trigger for the client to


   &nbs=
p;             =
re-authenticate.  





Here the document is getting into some solution description.




And as for such a solution:





Instead of sending a notification that is protected with an ex=
pired SA to mean "re-authenticate", why not send an explicit mess=
age that says "re-authenticate"?


 


[TR] 


The client has trusted=
 the PCP server sometime back using mutual authentication, so it can assume=
 the integrity protected PCP response using expired SA is coming from the s=
ame PCP server and not from some attacker posing as PCP server.


[/TR]


 


What is gained by appearing to use an expired SA (but in fact not re=
ally using it! because the payload of the notification is not consumed by t=
he receiver).=








          &n=
bsp;      For example, if the server indicates

   &nbs=
p;             =
that external IP address/port has changed, the PCP


   &nbs=
p;             =
client can then re-authenticate with the server to


   &nbs=
p;             =
confirm if the external IP address/port for the mapping


   &nbs=
p;             =
has indeed changed.


 


   &nbs=
p;      2.  The server can optionally trigger=
 re-authentication with


   &nbs=
p;          the client.=













 






















 






















Yes, that's the solution. If the server has something to send to the cli=
ent, and there's no live SA, then the server first needs to
 trigger re-auth, setup a fresh SA, then send whatever it wants to send to =
the client.


















 










[TR=
]


 


We have updated this r=
equirement in the new draft, please have a look.


 


Best Regards,


--Tiru.


 


[/TR]










 






















 






















Alper






















 






















 






















 




































 










--_000_913383AAA69FF945B8F946018B75898A14B75E78xmbrcdx10ciscoc_--

From tireddy@cisco.com  Wed May 29 06:10:44 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3112921F8FDD for ; Wed, 29 May 2013 06:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SB4bEWdnSq8R for ; Wed, 29 May 2013 06:10:39 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E204621F8F12 for ; Wed, 29 May 2013 06:10:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5348; q=dns/txt; s=iport; t=1369833039; x=1371042639; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BW3MKVgmwSDyXrS1EgC+uZ14h6blAbUMgqi2LUxXF8k=; b=R/z9APlajPHkzIxKpgMuSvyysTZGoRiCNT+SbTXik0WfY6kLNq8ez59E +docc8Zige8w1rz+W0o+beTpYoxLW56X2yOeJN/pkU/9010Xn+WKVHTBB LnlPiRMX431C5h1MWzSXz+BZBrQRy31zc2m2so3k9bA6bQwThj0yk5ATg s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkMHAJP9pVGtJV2c/2dsb2JhbABQAQmDCTDBe4EKFnSCIwEBAQQBAQE3LQcJAgwEAgEIEQQBAQEKCwkJBycLFAkIAgQOAwIIARKHcgy6RI1ZAYEKMQcGBIJpYQOYZJAXgw9AgSokGQ
X-IronPort-AV: E=Sophos;i="4.87,764,1363132800"; d="scan'208";a="216245810"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 29 May 2013 13:10:38 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4TDActU019486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 May 2013 13:10:38 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Wed, 29 May 2013 08:10:37 -0500
From: "Tirumaleswar Reddy (tireddy)" 
To: Alper Yegin 
Thread-Topic: [pcp] New Version Notification for draft-wing-pcp-third-party-authz-00.txt
Thread-Index: AQHOW73r0c0bLIKO+0ePG3hbQSw14pka1pyg
Date: Wed, 29 May 2013 13:10:37 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A14B75EA0@xmb-rcd-x10.cisco.com>
References: <913383AAA69FF945B8F946018B75898A14B74A9B@xmb-rcd-x10.cisco.com> <77869F66-5BD6-4611-994F-98BEE37AADDD@yegin.org> <913383AAA69FF945B8F946018B75898A14B7522B@xmb-rcd-x10.cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.103.238.111]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "pcp@ietf.org" 
Subject: Re: [pcp] New Version Notification for draft-wing-pcp-third-party-authz-00.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 May 2013 13:10:44 -0000

> -----Original Message-----
> From: Alper Yegin [mailto:alper.yegin@yegin.org]
> Sent: Tuesday, May 28, 2013 9:41 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: pcp@ietf.org
> Subject: Re: [pcp] New Version Notification for draft-wing-pcp-third-part=
y-
> authz-00.txt
>=20
> Hi Tiru,
>=20
> >> Judging from the Figure 3 in the document, if the main objective is to=
 get
> PCP
> >> client and PCP server authenticate each other with the help of a
> Authorization
> >> Server (a trusted third party), let me point out that this is already
> achieved
> >> with both of the EAP-based solutions.
> >
> > In addition to Third-party authorization, PCP server needs a mechanism =
to
> validate that the PCP client is only requesting the resources permitted t=
o be
> used by Authorization Server. Various validations that are performed by t=
he
> PCP server for this use case are mentioned in
> http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-00#section-5.=
2
> >
>=20
> Yes, this is indeed part of what I'm describing.
>=20
> Typically, EAP is carried over Foo between the xClint and xServer, and ov=
er a
> AAA (Authentication, Authortization, and Accounting) protocol [such as RA=
DIUS,
> Diameter] between the xServer and the Authorization Server (a AAA server)=
. The
> AAA protocol takes care of the "authorization", making sure the authentic=
ated
> Client is only getting the services that it is authorized to use.

In this case PCP server (Resource server) communicates with the Authorizati=
on Server (WebRTC Server) to identify if the OAuth Handle token is valid an=
d also identify the resources permitted with the Handle token. In this case=
 the token is provided by the WebRTC server (Application Server) and not AA=
A. The WebRTC server could may located in a different administrative domain=
 and the resources authorized by it for a specific purpose only.

>=20
>=20
> >>
> >> I didn't get under that impression, but in case OAuth is also essentia=
l to
> the
> >> solution, then it can be defined as an EAP method and carried over EAP=
.
> >
> > For the use-case mentioned in the draft, PCP Authentication is optional=
. The
> OAuth Handle token provided by the Authorization server is carried in a n=
ew
> PCP ACCESS_TOKEN option in the PCP request.
> >
>=20
> That Token is providing "Client authentication", ensuring that the Token
> indeed is sent by the claimed identity,
> But it'd not be providing data-origin authentication and integrity protec=
tion
> for the rest of the PCP message.
> And in the absence of that, any part of the message aside from the Token =
can
> be spoofed/modified.

In the Security Considerations it's already mentioned that PCP authenticati=
on needs to be taken into account but is not mandatory. The token is design=
ed such that it is applicable to the user it is assigned to and cannot be u=
sed by another party.

Best Regards,
--Tiru.
>=20
> Alper
>=20
>=20
>=20
> > --Tiru.
> >
> >>
> >> Alper
> >>
> >>
> >> On May 27, 2013, at 8:25 AM, Tirumaleswar Reddy (tireddy) wrote:
> >>
> >>> Hi all,
> >>>
> >>> This document describes a third party authorization mechanism to addr=
ess
> the
> >> REQ-14 in "PCP Auth Requirements" draft. It describes a cryptographic
> >> technique for an application server to permit a flow across a firewall=
.
> This
> >> technique uses OAuth and a new PCP option.
> >>>
> >>> comments and suggestions are welcome.
> >>>
> >>> Best Regards,
> >>> --Authors.
> >>>
> >>> -----Original Message-----
> >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> >>> Sent: Saturday, May 25, 2013 7:58 AM
> >>> To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Reinald=
o
> Penno
> >> (repenno); Dan Wing (dwing)
> >>> Subject: New Version Notification for draft-wing-pcp-third-party-auth=
z-
> >> 00.txt
> >>>
> >>>
> >>> A new version of I-D, draft-wing-pcp-third-party-authz-00.txt
> >>> has been successfully submitted by Dan Wing and posted to the
> >>> IETF repository.
> >>>
> >>> Filename:	 draft-wing-pcp-third-party-authz
> >>> Revision:	 00
> >>> Title:		 PCP Extension for Third Party Authorization
> >>> Creation date:	 2013-05-25
> >>> Group:		 Individual Submission
> >>> Number of pages: 14
> >>> URL:             http://www.ietf.org/internet-drafts/draft-wing-pcp-t=
hird-
> >> party-authz-00.txt
> >>> Status:          http://datatracker.ietf.org/doc/draft-wing-pcp-third=
-
> party-
> >> authz
> >>> Htmlized:        http://tools.ietf.org/html/draft-wing-pcp-third-part=
y-
> >> authz-00
> >>>
> >>>
> >>> Abstract:
> >>>  It is often desirable for an application server to permit a flow
> >>>  across a firewall, as happens today when a firewall includes an
> >>>  Application Layer Gateway (ALG) function.  However, an ALG has
> >>>  several weaknesses.
> >>>
> >>>  This document describes a cryptographic technique for an application
> >>>  server to permit a flow across a firewall.  This technique uses OAut=
h
> >>>  and a new PCP option.
> >>>
> >>>
> >>>
> >>>
> >>> The IETF Secretariat
> >>>
> >>> _______________________________________________
> >>> pcp mailing list
> >>> pcp@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/pcp
> >


From dwing@cisco.com  Wed May 29 10:23:45 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55AE21F8EC1 for ; Wed, 29 May 2013 10:23:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2H0BZWxW1Fj for ; Wed, 29 May 2013 10:23:40 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id F214821F8E1C for ; Wed, 29 May 2013 10:23:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4489; q=dns/txt; s=iport; t=1369848206; x=1371057806; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=xPHRan+eC32FETHQhESQQuZTlmfBpYWjEkbq3TmXXnY=; b=VUWnAR+cKww2cudVnksgUA6b+6GDOyweX8LsUqxs7bFYCcfGvdll9Ngn YdV11LI0/MVI+g075roCxJFbjzecaRGFo0NcqgM2sJgB7+X9zRJ0JrEp8 PL6Nqrykx0hxzrmuVjcUYTn6uVMWgxZ/LIs1JvolG1xRmJCDg3Cc4G/i3 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AokGAPw4plGrRDoI/2dsb2JhbABagwkwwX+BChZ0giMBAQEDAQEBATc0CwULC0YnMAYTiAcFDbpOBI5gMweCdmEDiR+OHIYeiyKDLxw
X-IronPort-AV: E=Sophos;i="4.87,765,1363132800"; d="scan'208";a="79826965"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 29 May 2013 17:23:25 +0000
Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4THNO5l015535; Wed, 29 May 2013 17:23:24 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Dan Wing 
In-Reply-To: <0DD77404-5087-49D6-914E-D5A7A9C4C420@apple.com>
Date: Wed, 29 May 2013 10:23:24 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <718D36E7-377A-4E64-BEFF-8F31663D91AD@cisco.com>
References: <0DD77404-5087-49D6-914E-D5A7A9C4C420@apple.com>
To: Stuart Cheshire 
X-Mailer: Apple Mail (2.1503)
Cc: pcp@ietf.org
Subject: Re: [pcp] Stability of external 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: Wed, 29 May 2013 17:23:45 -0000

On May 21, 2013, at 6:59 PM, Stuart Cheshire  wrote:

> In some recent discussions I had, it became clear that the text below =
may be a little incomplete:
>=20
>   The MAP and PEER requests include a Suggested External IP Address
>   field.  Some PCP-controlled devices, especially CGN but also multi-
>   homed NPTv6 networks, have a pool of public-facing IP addresses.  =
PCP
>   allows the client to indicate if it wants a mapping assigned on a
>   specific address of that pool or any address of that pool.  Some
>   applications will break if mappings are created on different IP
>   addresses (e.g., active mode FTP), so applications should carefully
>   consider the implications of using this capability.  Static mappings
>   for that internal address (e.g., those created by a command-line
>   interface on the PCP server or PCP-controlled device) may exist to a
>   certain external address, and if the suggested external IP address =
is
>   the IPv4 or IPv6 all-zeros address, PCP SHOULD assign its mappings =
to
>   the same external address, as this can also help applications using =
a
>   mix of both static mappings and PCP-created mappings.  If, on the
>   other hand, the suggested external IP address contains a non-zero IP
>   address the PCP server SHOULD create a mapping to that external
>   address, even if there are other mappings from that same internal
>   address to a different external address.  Once an internal address
>   has no implicit dynamic mappings and no explicit dynamic mappings in
>   the PCP-controlled device, a subsequent implicit or explicit mapping
>   for that internal address MAY be assigned to a different External
>   address.  Generally, this reassignment would occur when a CGN device
>   is load balancing newly seen internal addresses to its public pool =
of
>   external addresses.
>=20
> Specifically, it says:
>=20
>   Once an internal address
>   has no implicit dynamic mappings and no explicit dynamic mappings in
>   the PCP-controlled device, a subsequent implicit or explicit mapping
>   for that internal address MAY be assigned to a different External
>   address.
>=20
> That implies the corollary: While an internal address has *some* =
mappings in the PCP-controlled device, new implicit or explicit mappings =
for that internal address SHOULD be assigned the *same* external =
address. Unfortunately, while it implies this, it does not actually =
state it.
>=20
> To clarify this I propose submitting the following erratum:
>=20
> Change:
>=20
>   ... Static mappings
>   for that internal address (e.g., those created by a command-line
>   interface on the PCP server or PCP-controlled device) may exist to a
>   certain external address,
>   and if the suggested external IP address is
>   the IPv4 or IPv6 all-zeros address, PCP SHOULD assign its mappings =
to
>   the same external address, as this can also help applications using =
a
>   mix of both static mappings and PCP-created mappings.
>=20
> To:
>=20
>   ... Static mappings
>   for that internal address (e.g., those created by a command-line
>   interface on the PCP server or PCP-controlled device) may exist to a
>   certain external address.
>   If the suggested external IP address is the IPv4 or IPv6 all-zeros
>   address, and the internal address currently has *any* active =
mappings
>   (implicit, explicit, or static) with an external address of the
>   indicated address family, then that external address SHOULD be used
>   for the new mapping.  If the existing mappings for that external
>   address family do not all share a single external address, then the
>   choice of which external address is assigned for the new mapping is
>   implementation dependent.
>=20
> Comments?

Looks reasonable to me.  Based on the rest of this thread, it would be =
additionally helpful to cite REQ-2 of RFC4787 (which is SHOULD level) =
and REQ-2 of RFC6888 (which is MUST level), so your new second sentence =
ends like:

  ... then that external address SHOULD be used for the new mapping, so =
that PCP behavior follows NAT requirements of REQ-2 of [RFC4787] and =
REQ-2 of [RFC6888].

-d

>=20
> Do other agree that this correctly captures what we intended to say?
>=20
> Stuart Cheshire
>=20
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp


From dwing@cisco.com  Wed May 29 10:33:31 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D7621F8EBD for ; Wed, 29 May 2013 10:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1scuclN+EXSN for ; Wed, 29 May 2013 10:33:26 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C10B621F8C20 for ; Wed, 29 May 2013 10:33:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=902; q=dns/txt; s=iport; t=1369848805; x=1371058405; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=lGl85r4msaKTGyAKMxqS0pEUAhmiKYFUMQoTg8VsDCY=; b=KRtSKSK9bXV3Af4ytsHjkQmMmIem0CNkTt+AqAoctX8lEI9ddXYy3k4R UiJ5mlTkdGTCkZvLtWBOwmWUDtBCG4KG/71OsUYY9JYnPrLUPB+8J+tIr 9ThmzNMBIp6E7sso01X964cnNUZ4s8eTw/XL5ZVK0QIz0vxxM2mN9iK1+ I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: At0GAMI6plGrRDoH/2dsb2JhbABagwkwgnSyJoxlgQoWdIIjAQEBAwF5BQsLRlcGE4gHBQ26To5gMweCdmEDiR+OHIEphHWDfYclgy8c
X-IronPort-AV: E=Sophos;i="4.87,765,1363132800"; d="scan'208";a="79311902"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 29 May 2013 17:33:25 +0000
Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4THXOGn010824; Wed, 29 May 2013 17:33:24 GMT
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Dan Wing 
In-Reply-To: <51A5BF11.5030100@viagenie.ca>
Date: Wed, 29 May 2013 10:33:24 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>  <51A5BF11.5030100@viagenie.ca>
To: Simon Perreault 
X-Mailer: Apple Mail (2.1503)
Cc: Stuart Cheshire , pcp@ietf.org
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 29 May 2013 17:33:31 -0000

On May 29, 2013, at 1:40 AM, Simon Perreault =
 wrote:

> Le 2013-05-29 01:24, Stuart Cheshire a =E9crit :
>> 
>>=20
>> WG participants, please review and comment, and if there are no =
objections we can issue a WGLC.
>=20
> No objection.
>=20
> It could be useful to point out that the set of supported external =
address families depends on the internal address family. That is, =
sending the same request over IPv4 and IPv6 could yield different =
results.

Yes, something like:

  The external addresses supported on a network depend on the external =
connectivity and address family translators (e.g., NAT64) on the =
network.  After receiving an UNSUPP_FAMILY error, a PCP client SHOULD =
try sending a new PCP request from an interface with a different address =
family.

-d


From dwing@cisco.com  Wed May 29 10:39:28 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F3D21F937B for ; Wed, 29 May 2013 10:39:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUBdULqJqugR for ; Wed, 29 May 2013 10:39:17 -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 4050A21F8F62 for ; Wed, 29 May 2013 10:39:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6967; q=dns/txt; s=iport; t=1369849157; x=1371058757; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=1inmBTNF8MGCr5x62LWSmnQ+L3SwLnSaboTKLHqOMNY=; b=EK3D/vwsgr5GTehALqI3Gkl+W+CEmDtNGjGE7EmQPSmRam0K2NO231Zu HQ3z9xuLFf6/gDVCSzKPQIIPD/wHRDbPkEztkecK8LVgHvPUUQWsERl4Y rMYwkB4TOriOXgIl9cwC4Bf/M03dZj+khJ0KgZOMt3ZiVhPsLLFlF0EmM 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AokGAO47plGrRDoG/2dsb2JhbABagwkwwX+BChZ0giMBAQEDAQEBAWsLBQsLPwcnHxEZiAcFDbo/jVCBEDMHgnZhA4kfjhyBKYR1iyKDLxyBLAc
X-IronPort-AV: E=Sophos;i="4.87,765,1363132800"; d="scan'208";a="82332773"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 29 May 2013 17:39:16 +0000
Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4THdEHv026980; Wed, 29 May 2013 17:39:15 GMT
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Dan Wing 
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ECFB4A912@PUEXCB1B.nanterre.francetelecom.fr>
Date: Wed, 29 May 2013 10:39:14 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <1455AEDA-6707-4496-8D19-5367CBCB543D@cisco.com>
References: <94C682931C08B048B7A8645303FDC9F36EB735607B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36ECFB4A912@PUEXCB1B.nanterre.francetelecom.fr>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.1503)
Cc: "pcp@ietf.org" 
Subject: Re: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
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, 29 May 2013 17:39:28 -0000

On May 22, 2013, at 2:26 AM, mohamed.boucadair@orange.com wrote:

> Re-,
>=20
> Many thanks for all of you who provided a feedback for this point. As =
a conclusion of this discussion, below a proposed change:
>=20
> OLD:
>=20
> 7. PCP Proxy Co-located with a NAT Function
>=20
>   When the PCP Proxy is co-located with a NAT function, it MUST update
>   the content of received requests with the mapped port number and the
>   address belonging to the external interface of the PCP Proxy (i.e.,
>   after the NAT operation) and not as initially positioned by the PCP
>   Client.  For the reverse path, PCP responses MUST be updated by the
>   PCP Proxy to replace the internal port number to what has been
>   initially positioned by the PCP Client.  For this purpose the PCP
>   Proxy MUST have an access to the local NAT state maintained locally.
>   Because PCP messages with an unknown OpCode or Option can carry a
>   hidden internal address or internal port which will not be
>   translated:
>=20
>   o  a PCP Proxy co-located with a NAT SHOULD reject by an
>      UNSUPP_OPCODE error response a received request with an unknown
>      OpCode;
>=20
>   o  a PCP Proxy co-located with a NAT SHOULD reject by an
>      UNSUPP_OPTION error response a received request with a mandatory-
>      to-process unknown Option;
>=20
>   o  a PCP Proxy co-located with a NAT MAY remove any optional-to-
>      process unknown Options from received requests before forwarding
>      them.
>=20
>   Rejecting unknown Options and OpCodes has the drawback of preventing
>   a PCP Client to make use of new capabilities offered by the PCP
>   Server but not supported by the PCP Proxy even if no IP address
>   and/or port is included in the Option/OpCode.
>=20
> NEW:
>=20
> 7.  PCP Proxy Co-located with a NAT Function
>=20
>   When the PCP Proxy is co-located with a NAT function, it MUST update
>   the content of received requests with the mapped port number and the
>   address belonging to the external interface of the PCP Proxy (i.e.,
>   after the NAT operation) and not as initially conveyed by the PCP
>   Client.  For the reverse path, PCP responses MUST be updated by the
>   PCP Proxy to replace the internal port number to what has been
>   initially positioned by the PCP Client.  For this purpose the PCP
>   Proxy MUST have an access to the local NAT state maintained locally.
>=20
>   By default, the PCP Proxy MUST relay unknown OpCodes and mandatory-
>   to-process unknown Options.  Rejecting unknown Options and OpCodes
>   has the drawback of preventing a PCP Client to make use of new
>   capabilities offered by the PCP Server but not supported by the PCP
>   Proxy even if no IP address and/or port is included in the Option/
>   OpCode.
>=20
>   Because PCP messages with an unknown OpCode or mandatory-to-process
>   unknown Options can carry a hidden internal address or internal port
>   which will not be translated, A PCP Proxy MUST be configurable to
>   disable relaying unknown OpCodes and mandatory-to-process unknown
>   Options. =20

The text needs to be clearer on the suggested default, and why the =
default is suggested.  Otherwise we will have proxies implemented that =
return an error for unknown opcodes, especially because there are =
several sentences explaining what MUST be done when returning an error.


I am still uncomfortable with how this will work in practice.  We need =
to think about a new opcode which has embedded ip address and port =
(somewhat like MAP or PEER) and how that could be successfully deployed =
with a PCP proxy compliant with this document.

-d


> If the PCP Proxy is configured to disable relaying unknown
>   OpCodes and mandatory-to-process unknown Options, the PCP Proxy MUST
>   behave as follows:
>=20
>   o  a PCP Proxy co-located with a NAT MUST reject by an UNSUPP_OPCODE
>      error response a received request with an unknown OpCode.
>=20
>   o  a PCP Proxy co-located with a NAT MUST reject by an UNSUPP_OPTION
>      error response a received request with a mandatory-to-process
>      unknown Option.
>=20
>=20
> If there is no objection, this change will be include in the next =
version of the spec.
>=20
> Cheers,
> Med
>=20
>> -----Message d'origine-----
>> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de
>> mohamed.boucadair@orange.com
>> Envoy=E9 : mardi 12 mars 2013 11:44
>> =C0 : pcp@ietf.org
>> Objet : [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
>>=20
>> Dear all,
>>=20
>> http://tools.ietf.org/html/draft-ietf-pcp-proxy-02 says:
>>=20
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>  Because PCP messages with an unknown OpCode or Option can carry a
>>  hidden internal address or internal port which will not be
>>  translated:
>>=20
>>  o  a PCP Proxy co-located with a NAT SHOULD reject by an
>>     UNSUPP_OPCODE error response a received request with an unknown
>>     OpCode;
>>=20
>>  o  a PCP Proxy co-located with a NAT SHOULD reject by an
>>     UNSUPP_OPTION error response a received request with a mandatory-
>>     to-process unknown Option;
>>=20
>>  o  a PCP Proxy co-located with a NAT MAY remove any optional-to-
>>     process unknown Options from received requests before forwarding
>>     them.
>>=20
>>  Rejecting unknown Options and OpCodes has the drawback of preventing
>>  a PCP Client to make use of new capabilities offered by the PCP
>>  Server but not supported by the PCP Proxy even if no IP address
>>  and/or port is included in the Option/OpCode.
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>=20
>> The reasoning above assumes Options which convey an IP address =
(and/or port
>> numbers) are naturally defined as mandatory-to-process option.
>>=20
>> Reinaldo suggests the following modifications to the behavior =
currently
>> defined in the I-D:
>>=20
>> (1) A PCP Proxy inserts a "this message was proxied" when sending =
back to
>> the client. Therefore if PCP client detects that the mappings are not
>> working as it should, it has a hint as to why.
>>=20
>> (2) The client conveys that some options in this message carry IP =
addresses
>> and need proxy processing (some IP addresses might not need any Proxy
>> processing).It does not need to say which options, a bit is fine. =
Therefore
>> a Proxy that could not process those options can send back a =
meaningful
>> error such as "message can not be proxied because contains options =
with IP
>> address and I do not know how"
>>=20
>> Any thoughts?
>>=20
>> Thanks.
>> Cheers,
>> Med
>> _______________________________________________
>> 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 cheshire@apple.com  Wed May 29 20:52:29 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CF111E80A2 for ; Wed, 29 May 2013 20:52:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1WRKJFELz5X for ; Wed, 29 May 2013 20:52:23 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 21A9821F9223 for ; Wed, 29 May 2013 20:52:17 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Received: from relay2.apple.com ([17.128.113.67]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MNL0022FEQON2X1@mail-out.apple.com> for pcp@ietf.org; Wed, 29 May 2013 20:52:16 -0700 (PDT)
X-AuditID: 11807143-b7f856d000000818-80-51a6ccf0cb68
Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay2.apple.com (Apple SCV relay) with SMTP id 0B.9B.02072.0FCC6A15; Wed, 29 May 2013 20:52:16 -0700 (PDT)
Received: from [10.0.1.15] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by jimbu.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MNL00DGBER3VQ80@jimbu.apple.com> for pcp@ietf.org; Wed, 29 May 2013 20:52:16 -0700 (PDT)
From: Stuart Cheshire 
In-reply-to: <51A5BF11.5030100@viagenie.ca>
Date: Wed, 29 May 2013 20:52:14 -0700
Content-transfer-encoding: quoted-printable
Message-id: 
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>  <51A5BF11.5030100@viagenie.ca>
To: Simon Perreault 
X-Mailer: Apple Mail (2.1085)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUiON1OVffDmWWBBldWSVlMPvab1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGW2fT7IWLOetWDtnOXsD436uLkZODgkBE4lJ+/+zQNhiEhfu rWfrYuTiEBJoYJI48+wUI4Szh0li1qFGJpAqYQFtibe3b7GD2LwChhJLrm8Bs5kFdCR6v39j BrHZBLQkXny+wgZicwLVnz6xEizOIqAqcXHtY0aIegGJmyf6mCFsbYkn7y6wQsy0kVh+uoMJ YvE2Jomufy1ACQ4OEaBlvbehLpWV2HnnNMsERoFZSM6YheSMWUjGLmBkXsUoUJSak1hppJdY UJCTqpecn7uJERR6DYXOOxiPLbM6xCjAwajEw7tBa1mgEGtiWXFl7iFGCQ5mJRHe+XuBQrwp iZVVqUX58UWlOanFhxilOViUxHmNbJYGCgmkJ5akZqemFqQWwWSZODilGhgd1u5K3bzeKuKO pAGX+U7F+QJurEbTWrLY3WtybeIPzo0pWmNxdMHh3VoyEcrafZmvW6Y3MQgEMJqWRXTcWios 8CHz478gpf8nhE5ETebPerJO0I/Jaoa+zynBoOrZcjUrmXmXWi5c/03pzjv5L78ChWcWz/Ka UhgWuudZ01Ih3Vne+17ZbVZiKc5INNRiLipOBACG1VEAOQIAAA==
Cc: pcp@ietf.org
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 03:52:29 -0000

On 29 May 2013, at 1:40, Simon Perreault wrote:

> Le 2013-05-29 01:24, Stuart Cheshire a =E9crit :
>> 
>>=20
>> WG participants, please review and comment, and if there are no =
objections we can issue a WGLC.
>=20
> No objection.
>=20
> It could be useful to point out that the set of supported external =
address families depends on the internal address family. That is, =
sending the same request over IPv4 and IPv6 could yield different =
results.

Good point. How about this updated text?

   Note that while the specific address placed in the Suggested External
   Address field is merely a suggestion that the PCP server is free to
   ignore, the address family is not.  If the suggested address *family*
   cannot be provided by this PCP server, then it MUST return a PCP
   error reply containing the UNSUPP_FAMILY error code.

   The ability to provide the requested external address family may
   depend on the client's internal address.  For example, a gateway that
   supports traditional NAT44, and native IPv6, but not NAT64, is able
   to provide mappings from an internal IPv4 address to an external IPv4
   address, and mappings from an internal IPv6 address to an external
   IPv6 address, but not mappings from an internal IPv6 address to an
   external IPv4 address.  When such a gateway receives a request to map
   an internal IPv4 address to an external IPv4 address it MUST return
   an external IPv4 address, if available, but when it receives a
   request to map an internal IPv6 address to an external IPv4 address
   it MUST return an UNSUPP_FAMILY error.

Stuart Cheshire

From alper.yegin@yegin.org  Wed May 29 23:09:56 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA3521F93E8 for ; Wed, 29 May 2013 23:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=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 YnqulMyv3k+K for ; Wed, 29 May 2013 23:09:50 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 22E1D21F93DC for ; Wed, 29 May 2013 23:09:50 -0700 (PDT)
Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MEoKI-1UfA6B41t4-00Fjmu; Thu, 30 May 2013 02:09:47 -0400
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_146762C5-65D6-492D-A6A4-D3C65C2BC5F3"
From: Alper Yegin 
In-Reply-To: <913383AAA69FF945B8F946018B75898A14B75E78@xmb-rcd-x10.cisco.com>
Date: Thu, 30 May 2013 09:09:39 +0300
Message-Id: <9E1F86C3-0925-4617-8998-E74A5A470B00@yegin.org>
References: <8B30790D-E36B-478D-8F4D-8B86A5E675DE@yegin.org> <913383AAA69FF945B8F946018B75898A14B6EFF0@xmb-rcd-x10.cisco.com> <674F70E5F2BE564CB06B6901FD3DD78B12D0CD38@tgxml338.toshiba.local>  <674F70E5F2BE564CB06B6901FD3DD78B12D0FD42@tgxml338.toshiba.local>  <674F70E5F2BE564CB06B6901FD3DD78B12D1002A@tgxml338.toshiba.local>  <913383AAA69FF945B8F946018B75898A14B75207@xmb-rcd-x10.cisco.com>  <674F70E5F2BE564CB06B6901FD3DD78B12D138C5@tgxml338.toshiba.local> <913383AAA69FF945B8F946018B75898A14B75E78@xmb-rcd-x10.cisco.com>
To: Tirumaleswar Reddy (tireddy) 
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:7b0mz7hh+omeY1h0AkMu8idVYsRixfumi2GxBlurZRo yF94lfm4sl1DdiZdLMU4DJZxhK00Xf69Xr6unHNrywUWhkkSpV NinV9NQ8qA3Lf1+NwMREkNA5MQw9U8QPu9utqeIvhNe/6T4a3c 8Bd2gtIP4r9ULu8ZoaV1KgPXAgRgms2wlJqIxuZjy9agKI3e9x jJ67qEQCNN2t4rVhOXuNv3iwX38ONw/6oZe3uyJgkjElsv15IF dtJRbkz9uZnWOeKPL5BYSFKEqXYjIheyCgyiGEIe212nw6U74S hWYzh6rkXRr1Gv5+hLX93bJqoMuBjhMdk+IyY3AlghoOiwCCl4 s8Ds4Cm48aTUJgMc6W9GK7ZEY1yBg5tpkIssg1mURVtl5oSh7e bSwg14I680h1g==
Cc: "pcp@ietf.org" 
Subject: Re: [pcp] pcp auth requirements
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, 30 May 2013 06:09:56 -0000

--Apple-Mail=_146762C5-65D6-492D-A6A4-D3C65C2BC5F3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

This text makes sense.


On May 29, 2013, at 4:09 PM, Tirumaleswar Reddy (tireddy) wrote:

> Thanks Yoshi for the text :
> =20
> OLD :
> =20
> REQ-4-
> =20
>       d.  If the server wants to send an unsolicited message, but the
>           previous security association for the mapping
>           identified in the original PCP request has expired
> =20
>           1.  The server can continue to use the same SA to protect
>               messages pertaining to that mapping, even if the SA is
>               technically expired.
> =20
>               -  Such server notifications will not change state in =
the
>                  PCP client.
> =20
>               -  The notification could be a trigger for the client to
>                  re-authenticate.  For example, if the server =
indicates
>                  that external IP address/port has changed, the PCP
>                  client can then re-authenticate with the server to
>                  confirm if the external IP address/port for the =
mapping
>                  has indeed changed.
> =20
>           2.  The server MUST be able to optionally trigger re-
>               authentication with the client.
> =20
> NEW :
> =20
> REQ-4-
> =20
>       d. The server MUST be able to trigger authentication with the =
client. The unsolicited message for authentication trigger MUST be =
integrity protected if there is valid unexpired SA.=20
> =20
> --Tiru.
> From: yoshihiro.ohba@toshiba.co.jp =
[mailto:yoshihiro.ohba@toshiba.co.jp]=20
> Sent: Wednesday, May 29, 2013 4:57 AM
> To: alper.yegin@yegin.org; Tirumaleswar Reddy (tireddy)
> Cc: pcp@ietf.org
> Subject: Re: [pcp] pcp auth requirements
> =20
> OK.  Then I suggest forming a requirement without using the term =
=93re-authentication=94, something like:
> =20
> The server MUST be able to send authentication trigger to the client =
when there is a mapping.  The authentication trigger MUST be integrity =
protected if there is a SA.
> =20
> Yoshihiro Ohba
> =20
> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20
> Sent: Wednesday, May 29, 2013 1:03 AM
> To: Tirumaleswar Reddy
> Cc: ohba yoshihiro; pcp@ietf.org
> Subject: Re: [pcp] pcp auth requirements
> =20
> Tiru,
> =20
> I agree.
> =20
> Alper
> =20
> On May 28, 2013, at 2:01 PM, Tirumaleswar Reddy (tireddy) wrote:
> =20
>=20
> Hi Alper,
> =20
> [1] when the PCP server triggers re-authentication and SA is valid, if =
the PCP client does not respond then possibly after N number of re-tries =
PCP server may want to give up and close the explicit mappings =
associated with the user. This would handle the scenario where PCP =
client would have crashed or terminated or connection lost for some =
reason or the user has logged off and some other user got the same IP =
address as the previous user.
> =20
> [2] Even in case 3, we may want similar behavior as [1]. For Case 3, =
there could be a scenarios =96 where PCP server would want to inform the =
PCP client that external IP address/port has changed, but the SA is =
expired. In this case PCP server would have to trigger re-auth. If =
re-auth is successful then send the mapping update or if there is no =
response from the client then proceed with deleting the explicit =
mappings after N number of tries.
> =20
> Case 3 could be an optimization to trigger re-authentication only when =
there is interesting update to be sent from the client or server and not =
to trigger re-authentication before SA expires .
> =20
> --Tiru.
> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20
> Sent: Thursday, May 23, 2013 12:17 PM
> To: yoshihiro.ohba@toshiba.co.jp
> Cc: Tirumaleswar Reddy (tireddy); pcp@ietf.org
> Subject: Re: [pcp] pcp auth requirements
> =20
> Yoshi,
> =20
> You are right. In terms of EAP and RFC 5247, only the second case =
qualifies for "EAP re-authentication".
> =20
> On the other hand, first and third case are not the same.=20
> And I'd conceptually think of the third case as a some sort of =
"re-authentication" (apparently not an "EAP re-authentication" per RFC =
5247).
> =20
> Anyways, at least I'd like people to be aware of these three different =
cases -- even if we cannot find a proper name to all of them.
> =20
> Alper
> =20
> =20
> =20
> On May 23, 2013, at 1:39 AM,  wrote:
>=20
>=20
>=20
> Hi Alper,
> =20
> When we talk about re-authentication, we should not care about whether =
there is a PCP session or not.
> =20
> Please see the following definition in RFC 5247:
> =93
>    EAP Re-Authentication
>       EAP authentication between an EAP peer and a server with whom =
the
>       EAP peer shares valid unexpired EAP keying material.
> =93
> =20
> According to the above definition, if authentication is conducted over =
a live SA, it is re-authentication, otherwise it is not =
re-authentication.
> =20
> Yoshihiro Ohba
> =20
> =20
> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20
> Sent: Thursday, May 23, 2013 6:16 AM
> To: ohba yoshihiro
> Cc: tireddy@cisco.com; pcp@ietf.org
> Subject: Re: [pcp] pcp auth requirements
> =20
> Hi Yoshi,
> =20
> Here are the three states:
> =20
> 0. Before PCP client and PCP server has initiated PCP session.
> =20
> 1. There is a PCP session and a live SA.
> =20
> 2. There is a PCP session, but no live SA (i.e., the last used SA is =
already expired).
> =20
> =20
> If we execute auth in state 0, we call it "(initial) authentication".
> Auth executed in state 1 is called "re-authenticaiton".
> I'd call auth executed in state 2 a "re-authentication" as well, =
unless we want to give it a more specific name.
> =20
> Alper
> =20
> =20
> =20
> =20
> On May 22, 2013, at 11:16 AM,  wrote:
>=20
>=20
>=20
>=20
> Hi Alper,
> =20
> I agree that we should allow unprotected authentication trigger from =
the server, but we should distinguish authentication after expiration of =
SA from =93re-authentication=94.
> =20
> Yoshihiro Ohba
> =20
> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20
> Sent: Wednesday, May 22, 2013 4:22 PM
> To: ohba yoshihiro
> Cc: tireddy@cisco.com; pcp@ietf.org
> Subject: Re: [pcp] pcp auth requirements
> =20
> =20
> On May 21, 2013, at 10:14 AM,  =
 wrote:
>=20
>=20
>=20
>=20
>=20
> Tiru,
> =20
> In my analysis, Req-4-d-1 is basically introducing a three-state SA =
model for PCP: State 0:  unavailable (or non-existent), State 1: =
partially available only for triggering re-auth, and State 2: fully =
available. MSCHAPv2 password change function is designed based on this =
model.
> =20
> I am not going to get into details about the three-state SA model, but =
even the three-state SA model will require re-auth trigger to be =
integrity protected. =20
> =20
> Having said that, I think the following requirement is sufficient for =
Req-4-d: =93The server MUST be able to send an integrity protected =
re-authentication trigger to the client.=94
> =20
> =20
> If there is no SA available, then the server can send an un-protected =
re-auth trigger. We should allow that.
> This is equivalent to what happens at the very beginning before the =
very first authentication between the client and the server.
> =20
> Alper
> =20
> =20
> =20
>=20
>=20
>=20
>=20
>=20
> Regards,
> Yoshihiro Ohba
> =20
> =20
> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of =
Tirumaleswar Reddy (tireddy)
> Sent: Sunday, May 19, 2013 2:24 AM
> To: Alper Yegin; pcp@ietf.org
> Subject: Re: [pcp] pcp auth requirements
> =20
> Hi Alper,
> =20
> Please see inline [TR]
> =20
> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20
> Sent: Tuesday, April 30, 2013 12:53 PM
> To: pcp@ietf.org
> Subject: [pcp] pcp auth requirements
> =20
>=20
>=20
>       c.  If a server wants to send an unsolicited message, but the
>           previous security association has expired
> =20
>           1.  The server can continue to use the same SA to protect
>               messages pertaining to that mapping, even if the SA is
>               technically expired.
>=20
> "Expired" means "do not use (even if its still hanging around)".=20
> We not only do not need to use expired SAs, but also using something =
expired in any sense is plain wrong -- unless someone wants to redefine =
what "expired" means.
> =20
> [TR]
> For example if we consider MSCHAPv2, there is configuration option =
where server accepts the challenge-response from the client even if the =
password is expired and allows it be changed.=20
> =20
> Please clarify if you have some attack in mind that would cause =
problems using expired SA.
> =20
> [/TR]
> =20
>               -  Such server notifications will not change state in =
the
>                  PCP client.
> =20
>               -  The notification could be a trigger for the client to
>                  re-authenticate. =20
>=20
> Here the document is getting into some solution description.
>=20
> And as for such a solution:
>=20
> Instead of sending a notification that is protected with an expired SA =
to mean "re-authenticate", why not send an explicit message that says =
"re-authenticate"?
> =20
> [TR]=20
> The client has trusted the PCP server sometime back using mutual =
authentication, so it can assume the integrity protected PCP response =
using expired SA is coming from the same PCP server and not from some =
attacker posing as PCP server.
> [/TR]
> =20
> What is gained by appearing to use an expired SA (but in fact not =
really using it! because the payload of the notification is not consumed =
by the receiver).
>=20
>=20
>                  For example, if the server indicates
>                  that external IP address/port has changed, the PCP
>                  client can then re-authenticate with the server to
>                  confirm if the external IP address/port for the =
mapping
>                  has indeed changed.
> =20
>           2.  The server can optionally trigger re-authentication with
>               the client.
> =20
> =20
> Yes, that's the solution. If the server has something to send to the =
client, and there's no live SA, then the server first needs to trigger =
re-auth, setup a fresh SA, then send whatever it wants to send to the =
client.
> =20
> [TR]
> =20
> We have updated this requirement in the new draft, please have a look.
> =20
> Best Regards,
> --Tiru.
> =20
> [/TR]
> =20
> =20
> Alper
> =20
> =20
> =20


--Apple-Mail=_146762C5-65D6-492D-A6A4-D3C65C2BC5F3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

This text makes =
sense.


On May 29, 2013, at 4:09 PM, =
Tirumaleswar Reddy (tireddy) wrote:

Thanks Yoshi for the text =
:
 
OLD =
:
 
 
NEW :
REQ-4-
      d. The server MUST be =
able to trigger authentication with the client. The unsolicited message =
for authentication trigger MUST be integrity protected if there is valid =
unexpired SA. 
--Tiru.
OK. =
 Then I suggest forming a requirement without using the term =
=93re-authentication=94, something like:
 
The server MUST be able to send authentication =
trigger to the client when there is a mapping.  The authentication =
trigger MUST be integrity protected if there is a =
SA.
Yoshihiro =
Ohba
From: Alper Yegin =
[mailto:alper.yegin@yegin.org] 
Sent: Wednesday, May 29, 2013 =
1:03 AM
To: Tirumaleswar =
Reddy
Cc: ohba=
 yoshihiro; pcp@ietf.org
Subject: Re: [pcp] pcp auth =
requirements
Tiru,
I =
agree.
On May 28, 2013, at =
2:01 PM, Tirumaleswar Reddy (tireddy) wrote:
 
Hi Alper,
 
[1] when the PCP server triggers =
re-authentication and SA is valid, if the PCP client does not respond =
then possibly after N number of re-tries PCP server may want to give up =
and close the explicit mappings associated with the user. This would =
handle the scenario where PCP client would have crashed or terminated or =
connection lost for some reason or the user has logged off and some =
other user got the same IP address as the previous user.[2] =
Even in case 3, we may want similar behavior as [1]. For Case 3, there =
could be a scenarios =96 where PCP server would want to inform the PCP =
client that external IP address/port has changed, but the SA is expired. =
In this case PCP server would have to trigger re-auth. If re-auth is =
successful then send the mapping update or if there is no response from =
the client then proceed with deleting the explicit mappings after N =
number of tries.
Case =
3 could be an optimization to trigger re-authentication only when there =
is interesting update to be sent from the client or server and not to =
trigger re-authentication before SA expires .
Alper Yegin [mailto:alper.yegin@yegin.org] 
Sent: Thursday, May 23, 2013 =
12:17 PM
To:  Tirumaleswar Reddy =
(tireddy); pcp@ietf.org
Subject: Re: [pcp] pcp auth =
requirementsYou are right. =
In terms of EAP and RFC 5247, only the second case qualifies for "EAP =
re-authentication".
On the other =
hand, first and third case are not the =
same. 
And I'd =
conceptually think of the third case as a some sort of =
"re-authentication" (apparently not an "EAP re-authentication" per RFC =
5247).
Anyways, at =
least I'd like people to be aware of these three different cases -- even =
if we cannot find a proper name to all of =
them.
 
Alper Yegin [mailto:alper.yegin@yegin.org] 
Sent: Thursday, May 23, 2013 6:16 =
AM
To: ohba =
yoshihiro
Cc: tireddy@cisco.com; pcp@ietf.org
Subject: Re: [pcp] pcp auth =
requirements
Hi =
Yoshi,
Here are the three =
states:
0. Before PCP client =
and PCP server has initiated PCP =
session.
1. There is a PCP =
session and a live =
SA.
2. There is a PCP =
session, but no live SA (i.e., the last used SA is already =
expired).
If we execute auth in =
state 0, we call it "(initial) =
authentication".
Auth executed in state =
1 is called =
"re-authenticaiton".
I'd call auth executed =
in state 2 a "re-authentication" as well, unless we want to give it a =
more specific name.
On May 22, 2013, at =
11:16 AM, <
Hi =
Alper,
I =
agree that we should allow unprotected authentication trigger from the =
server, but we should distinguish authentication after expiration of SA =
from =93re-authentication=94.
Tiru,
 
In my analysis, Req-4-d-1 is basically =
introducing a three-state SA model for PCP: State 0:  unavailable =
(or non-existent), State 1: partially available only for triggering =
re-auth, and State 2: fully available. MSCHAPv2 password change function =
is designed based on this model.
 
I am not going to get into details about the =
three-state SA model, but even the three-state SA model will require =
re-auth trigger to be integrity protected.  
 
Having said that, I think the following =
requirement is sufficient for Req-4-d: =93The server =
MUST be able to send an integrity protected re-authentication trigger to =
the client.=94
 
If =
there is no SA available, then the server can send an un-protected =
re-auth trigger. We should allow =
that.
This is =
equivalent to what happens at the very beginning before the very first =
authentication between the client and the =
server.
Regards,
Yoshihiro Ohba
 
 
From: [mailto:pcp-bounces@ietf.org] On Behalf Of Tirumaleswar Reddy =
(tireddy)
Sent: Sunday, May 19, 2013 2:24 =
AM
To: Alper =
Yegin; pcp@ietf.org
Subject: Re: [pcp] pcp auth =
requirements
 
Hi =
Alper,
From: Alper Yegin =
[mailto:alper.yegin@yegin.org] 
Sent: Tuesday, April 30, 2013 =
12:53 PM
To: pcp@ietf.org
Subject: [pcp] pcp auth =
requirements
 
      c.  If a server wants to =
send an unsolicited message, but the
  =
        previous security =
association has expired 
          =
1.  The server can continue to use the same SA to =
protect

"Expired" means "do not use (even if its still hanging =
around)". We not only do not =
need to use expired SAs, but also using something expired in any sense =
is plain wrong -- unless someone wants to redefine what "expired" =
means. 
[TR]For example if we =
consider MSCHAPv2, there is configuration option where server accepts =
the challenge-response from the client even if the password is expired =
and allows it be changed. 
Please clarify if =
you have some attack in mind that would cause problems using expired =
SA. 
[/TR] 
            =
  -  Such server notifications will not change state in =
the
Here the document is getting into some solution =
description.
And as for such a solution:

Instead of sending a notification that is protected with an =
expired SA to mean "re-authenticate", why not send an explicit message =
that says "re-authenticate"?
[TR] 
The client has trusted the PCP server sometime back =
using mutual authentication, so it can assume the integrity protected =
PCP response using expired SA is coming from the same PCP server and not =
from some attacker posing as PCP server.
 
What is gained by appearing to use an expired SA (but in fact =
not really using it! because the payload of the notification is not =
consumed by the receiver).


            =
     For example, if the server =
indicates
 
 
Yes, that's the =
solution. If the server has something to send to the client, and there's =
no live SA, then the server first needs to trigger re-auth, setup a =
fresh SA, then send whatever it wants to send to the client.
 [TR] 
We have updated this requirement in the new draft, =
please have a look. 
Best Regards,
 
[/TR]
 
Alper
 
 
 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 06:32:13 -0000

Hi Stuart, all,

The behavior you are proposing here recalls me what we had in earlier versi=
ons of the pcp specification (version 00 to version 03, PINxy OpCodes) and =
(version 04 to version 13, MAP4 and MAP6 OpCodes). The consensus of the wg =
was to remove that design.=20

This particular text in your proposal:

>   Note that while the specific address placed in the Suggested External
>   Address field is merely a suggestion that the PCP server is free to
>   ignore, the address family is not. =20

is clearly a revival of the MAPx/PEERx opcides.

Cheers,
Med


>-----Message d'origine-----
>De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de
>Stuart Cheshire
>Envoy=E9=A0: jeudi 30 mai 2013 05:52
>=C0=A0: Simon Perreault
>Cc=A0: pcp@ietf.org
>Objet=A0: Re: [pcp] UNSUPP_FAMILY error code
>
>On 29 May 2013, at 1:40, Simon Perreault wrote:
>
>> Le 2013-05-29 01:24, Stuart Cheshire a =E9crit :
>>> 
>>>
>>> WG participants, please review and comment, and if there are no
>objections we can issue a WGLC.
>>
>> No objection.
>>
>> It could be useful to point out that the set of supported external
>address families depends on the internal address family. That is, sending
>the same request over IPv4 and IPv6 could yield different results.
>
>Good point. How about this updated text?
>
>   Note that while the specific address placed in the Suggested External
>   Address field is merely a suggestion that the PCP server is free to
>   ignore, the address family is not.  If the suggested address *family*
>   cannot be provided by this PCP server, then it MUST return a PCP
>   error reply containing the UNSUPP_FAMILY error code.
>
>   The ability to provide the requested external address family may
>   depend on the client's internal address.  For example, a gateway that
>   supports traditional NAT44, and native IPv6, but not NAT64, is able
>   to provide mappings from an internal IPv4 address to an external IPv4
>   address, and mappings from an internal IPv6 address to an external
>   IPv6 address, but not mappings from an internal IPv6 address to an
>   external IPv4 address.  When such a gateway receives a request to map
>   an internal IPv4 address to an external IPv4 address it MUST return
>   an external IPv4 address, if available, but when it receives a
>   request to map an internal IPv6 address to an external IPv4 address
>   it MUST return an UNSUPP_FAMILY error.
>
>Stuart Cheshire
>_______________________________________________
>pcp mailing list
>pcp@ietf.org
>https://www.ietf.org/mailman/listinfo/pcp

From mohamed.boucadair@orange.com  Wed May 29 23:36:39 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D03B21F84CE for ; Wed, 29 May 2013 23:36:39 -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 y9LRAWWSFz5M for ; Wed, 29 May 2013 23:36:35 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id BE9E221F8437 for ; Wed, 29 May 2013 23:36:34 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id AF95B32510F; Thu, 30 May 2013 08:36:33 +0200 (CEST)
Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 9523E4C015; Thu, 30 May 2013 08:36:33 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 30 May 2013 08:36:33 +0200
From: 
To: Dan Wing 
Date: Thu, 30 May 2013 08:36:32 +0200
Thread-Topic: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
Thread-Index: Ac5ck3MUKLkPb4vWTq2xQo6R05oxvQAa/qKw
Message-ID: <94C682931C08B048B7A8645303FDC9F36ED3A0819B@PUEXCB1B.nanterre.francetelecom.fr>
References: <94C682931C08B048B7A8645303FDC9F36EB735607B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36ECFB4A912@PUEXCB1B.nanterre.francetelecom.fr> <1455AEDA-6707-4496-8D19-5367CBCB543D@cisco.com>
In-Reply-To: <1455AEDA-6707-4496-8D19-5367CBCB543D@cisco.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.30.60019
Cc: "pcp@ietf.org" 
Subject: Re: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
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, 30 May 2013 06:36:39 -0000

Hi Dan,



>-----Message d'origine-----
>De=A0: Dan Wing [mailto:dwing@cisco.com]
>Envoy=E9=A0: mercredi 29 mai 2013 19:39
>=C0=A0: BOUCADAIR Mohamed OLNC/OLN
>Cc=A0: pcp@ietf.org
>Objet=A0: Re: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
>
>
>On May 22, 2013, at 2:26 AM, mohamed.boucadair@orange.com wrote:
>
>> Re-,
>>
>> Many thanks for all of you who provided a feedback for this point. As a
>conclusion of this discussion, below a proposed change:
>>
>> OLD:
>>
>> 7. PCP Proxy Co-located with a NAT Function
>>
>>   When the PCP Proxy is co-located with a NAT function, it MUST update
>>   the content of received requests with the mapped port number and the
>>   address belonging to the external interface of the PCP Proxy (i.e.,
>>   after the NAT operation) and not as initially positioned by the PCP
>>   Client.  For the reverse path, PCP responses MUST be updated by the
>>   PCP Proxy to replace the internal port number to what has been
>>   initially positioned by the PCP Client.  For this purpose the PCP
>>   Proxy MUST have an access to the local NAT state maintained locally.
>>   Because PCP messages with an unknown OpCode or Option can carry a
>>   hidden internal address or internal port which will not be
>>   translated:
>>
>>   o  a PCP Proxy co-located with a NAT SHOULD reject by an
>>      UNSUPP_OPCODE error response a received request with an unknown
>>      OpCode;
>>
>>   o  a PCP Proxy co-located with a NAT SHOULD reject by an
>>      UNSUPP_OPTION error response a received request with a mandatory-
>>      to-process unknown Option;
>>
>>   o  a PCP Proxy co-located with a NAT MAY remove any optional-to-
>>      process unknown Options from received requests before forwarding
>>      them.
>>
>>   Rejecting unknown Options and OpCodes has the drawback of preventing
>>   a PCP Client to make use of new capabilities offered by the PCP
>>   Server but not supported by the PCP Proxy even if no IP address
>>   and/or port is included in the Option/OpCode.
>>
>> NEW:
>>
>> 7.  PCP Proxy Co-located with a NAT Function
>>
>>   When the PCP Proxy is co-located with a NAT function, it MUST update
>>   the content of received requests with the mapped port number and the
>>   address belonging to the external interface of the PCP Proxy (i.e.,
>>   after the NAT operation) and not as initially conveyed by the PCP
>>   Client.  For the reverse path, PCP responses MUST be updated by the
>>   PCP Proxy to replace the internal port number to what has been
>>   initially positioned by the PCP Client.  For this purpose the PCP
>>   Proxy MUST have an access to the local NAT state maintained locally.
>>
>>   By default, the PCP Proxy MUST relay unknown OpCodes and mandatory-
>>   to-process unknown Options.  Rejecting unknown Options and OpCodes
>>   has the drawback of preventing a PCP Client to make use of new
>>   capabilities offered by the PCP Server but not supported by the PCP
>>   Proxy even if no IP address and/or port is included in the Option/
>>   OpCode.
>>
>>   Because PCP messages with an unknown OpCode or mandatory-to-process
>>   unknown Options can carry a hidden internal address or internal port
>>   which will not be translated, A PCP Proxy MUST be configurable to
>>   disable relaying unknown OpCodes and mandatory-to-process unknown
>>   Options.
>
>The text needs to be clearer on the suggested default,

[Med] The default and justification are stated in the previous paragraph.=20


 and why the default
>is suggested.  Otherwise we will have proxies implemented that return an
>error for unknown opcodes, especially because there are several sentences
>explaining what MUST be done when returning an error.
>
>
>I am still uncomfortable with how this will work in practice.  We need to
>think about a new opcode which has embedded ip address and port (somewhat
>like MAP or PEER) and how that could be successfully deployed with a PCP
>proxy compliant with this document.
>
>-d
>
>
>> If the PCP Proxy is configured to disable relaying unknown
>>   OpCodes and mandatory-to-process unknown Options, the PCP Proxy MUST
>>   behave as follows:
>>
>>   o  a PCP Proxy co-located with a NAT MUST reject by an UNSUPP_OPCODE
>>      error response a received request with an unknown OpCode.
>>
>>   o  a PCP Proxy co-located with a NAT MUST reject by an UNSUPP_OPTION
>>      error response a received request with a mandatory-to-process
>>      unknown Option.
>>
>>
>> If there is no objection, this change will be include in the next versio=
n
>of the spec.
>>
>> Cheers,
>> Med
>>
>>> -----Message d'origine-----
>>> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de
>>> mohamed.boucadair@orange.com
>>> Envoy=E9 : mardi 12 mars 2013 11:44
>>> =C0 : pcp@ietf.org
>>> Objet : [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
>>>
>>> Dear all,
>>>
>>> http://tools.ietf.org/html/draft-ietf-pcp-proxy-02 says:
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>  Because PCP messages with an unknown OpCode or Option can carry a
>>>  hidden internal address or internal port which will not be
>>>  translated:
>>>
>>>  o  a PCP Proxy co-located with a NAT SHOULD reject by an
>>>     UNSUPP_OPCODE error response a received request with an unknown
>>>     OpCode;
>>>
>>>  o  a PCP Proxy co-located with a NAT SHOULD reject by an
>>>     UNSUPP_OPTION error response a received request with a mandatory-
>>>     to-process unknown Option;
>>>
>>>  o  a PCP Proxy co-located with a NAT MAY remove any optional-to-
>>>     process unknown Options from received requests before forwarding
>>>     them.
>>>
>>>  Rejecting unknown Options and OpCodes has the drawback of preventing
>>>  a PCP Client to make use of new capabilities offered by the PCP
>>>  Server but not supported by the PCP Proxy even if no IP address
>>>  and/or port is included in the Option/OpCode.
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>
>>> The reasoning above assumes Options which convey an IP address (and/or
>port
>>> numbers) are naturally defined as mandatory-to-process option.
>>>
>>> Reinaldo suggests the following modifications to the behavior currently
>>> defined in the I-D:
>>>
>>> (1) A PCP Proxy inserts a "this message was proxied" when sending back
>to
>>> the client. Therefore if PCP client detects that the mappings are not
>>> working as it should, it has a hint as to why.
>>>
>>> (2) The client conveys that some options in this message carry IP
>addresses
>>> and need proxy processing (some IP addresses might not need any Proxy
>>> processing).It does not need to say which options, a bit is fine.
>Therefore
>>> a Proxy that could not process those options can send back a meaningful
>>> error such as "message can not be proxied because contains options with
>IP
>>> address and I do not know how"
>>>
>>> Any thoughts?
>>>
>>> Thanks.
>>> Cheers,
>>> Med
>>> _______________________________________________
>>> 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  Thu May 30 02:36:25 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5EE21F84CA for ; Thu, 30 May 2013 02:36:25 -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 k7goBLtf8JIp for ; Thu, 30 May 2013 02:36:21 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C915721F8B2B for ; Thu, 30 May 2013 02:36:20 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 1374F22D4EF for ; Thu, 30 May 2013 11:36:20 +0200 (CEST)
Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id ECBFC27C054 for ; Thu, 30 May 2013 11:36:19 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 30 May 2013 11:36:19 +0200
From: 
To: "pcp@ietf.org" 
Date: Thu, 30 May 2013 11:36:19 +0200
Thread-Topic: I-D Action: draft-boucadair-pcp-flow-examples-01.txt
Thread-Index: Ac5dF99jAf/7F3frQ4qvvQWHDWGrJgAAQaig
Message-ID: <94C682931C08B048B7A8645303FDC9F36ED3A08301@PUEXCB1B.nanterre.francetelecom.fr>
References: <20130530092631.2199.13076.idtracker@ietfa.amsl.com>
In-Reply-To: <20130530092631.2199.13076.idtracker@ietfa.amsl.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.30.84224
Subject: [pcp] TR: I-D Action: draft-boucadair-pcp-flow-examples-01.txt
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 May 2013 09:36:25 -0000

Dear all,

This updated version includes two additional use case suggested by Dan.

Don't hesitate to share any use case you think it is worth to be documented=
 this I-D.

Cheers,
Med

-----Message d'origine-----
De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]=
 De la part de internet-drafts@ietf.org
Envoy=E9=A0: jeudi 30 mai 2013 11:27
=C0=A0: i-d-announce@ietf.org
Objet=A0: I-D Action: draft-boucadair-pcp-flow-examples-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.


	Title           : PCP Flow Examples
	Author(s)       : Mohamed Boucadair
	Filename        : draft-boucadair-pcp-flow-examples-01.txt
	Pages           : 32
	Date            : 2013-05-30

Abstract:
   This document provides a set of examples to illustrate PCP
   operations.  It is a companion document to the base PCP
   specification.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-boucadair-pcp-flow-examples

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-boucadair-pcp-flow-examples-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-flow-examples-01


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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

From simon.perreault@viagenie.ca  Thu May 30 02:53:23 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4A721F963A for ; Thu, 30 May 2013 02:53:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.329
X-Spam-Level: 
X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.271,  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 Uacb6yRhan31 for ; Thu, 30 May 2013 02:53:23 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0006521F9590 for ; Thu, 30 May 2013 02:53:19 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 103864689C; Thu, 30 May 2013 05:53:18 -0400 (EDT)
Message-ID: <51A7218E.1000704@viagenie.ca>
Date: Thu, 30 May 2013 11:53:18 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: mohamed.boucadair@orange.com
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>  <51A5BF11.5030100@viagenie.ca>  <94C682931C08B048B7A8645303FDC9F36ED3A08198@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED3A08198@PUEXCB1B.nanterre.francetelecom.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 09:53:23 -0000

Le 2013-05-30 08:32, mohamed.boucadair@orange.com a écrit :
> The behavior you are proposing here recalls me what we had in earlier versions of the pcp specification (version 00 to version 03, PINxy OpCodes) and (version 04 to version 13, MAP4 and MAP6 OpCodes). The consensus of the wg was to remove that design.
>
> This particular text in your proposal:
>
>>    Note that while the specific address placed in the Suggested External
>>    Address field is merely a suggestion that the PCP server is free to
>>    ignore, the address family is not.
>
> is clearly a revival of the MAPx/PEERx opcides.

This is not quite right. MAPx/PEERx were transformed into MAP/PEER 
precisely because the external address type, which was encoded in the 
opcode, is now encoded in the suggested external address field. The 
semantics have not changed. Only the syntax has.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From simon.perreault@viagenie.ca  Thu May 30 02:58:45 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3985221F9473 for ; Thu, 30 May 2013 02:58:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.359
X-Spam-Level: 
X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.241,  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 ZfTm1sGdKtBH for ; Thu, 30 May 2013 02:58:44 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id EC70F21F8956 for ; Thu, 30 May 2013 02:58:37 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 46DDB4689C; Thu, 30 May 2013 05:58:37 -0400 (EDT)
Message-ID: <51A722CC.5030506@viagenie.ca>
Date: Thu, 30 May 2013 11:58:36 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: Stuart Cheshire 
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>  <51A5BF11.5030100@viagenie.ca> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: pcp@ietf.org
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 09:58:45 -0000

Le 2013-05-30 05:52, Stuart Cheshire a écrit :
>> It could be useful to point out that the set of supported external address families depends on the internal address family. That is, sending the same request over IPv4 and IPv6 could yield different results.
>
> Good point. How about this updated text?
>
>     Note that while the specific address placed in the Suggested External
>     Address field is merely a suggestion that the PCP server is free to
>     ignore, the address family is not.  If the suggested address *family*
>     cannot be provided by this PCP server, then it MUST return a PCP
>     error reply containing the UNSUPP_FAMILY error code.

This is important. And I think it is right. I cannot imagine a use case 
where a client doesn't know or care about the external address family.

>     The ability to provide the requested external address family may
>     depend on the client's internal address.

internal address *family*.

>     For example, a gateway that
>     supports traditional NAT44, and native IPv6, but not NAT64, is able
>     to provide mappings from an internal IPv4 address to an external IPv4
>     address, and mappings from an internal IPv6 address to an external
>     IPv6 address, but not mappings from an internal IPv6 address to an
>     external IPv4 address.  When such a gateway receives a request to map
>     an internal IPv4 address to an external IPv4 address it MUST return

s/MUST/MAY/

Quotas, local policy, the weather, etc. may all impact the server's 
willingness to serve that request.

>     an external IPv4 address, if available, but when it receives a
>     request to map an internal IPv6 address to an external IPv4 address
>     it MUST return an UNSUPP_FAMILY error.

Good.

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 teemu.savolainen@nokia.com  Thu May 30 03:38:40 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22BE21F9354 for ; Thu, 30 May 2013 03:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.741
X-Spam-Level: 
X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_PROFIT1=3.858, 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 munVQiAa6HAi for ; Thu, 30 May 2013 03:38:34 -0700 (PDT)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id A0E8B21F96B2 for ; Thu, 30 May 2013 03:38:33 -0700 (PDT)
Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r4UAcQFb005937 for ; Thu, 30 May 2013 13:38:26 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 30 May 2013 13:38:34 +0300
Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.106]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0328.011; Thu, 30 May 2013 10:39:25 +0000
From: 
To: 
Thread-Topic: My review of draft-ietf-pcp-nat64-prefix64-02
Thread-Index: Ac5dHuevWC0dHYarTvOOt4eFkySJdg==
Date: Thu, 30 May 2013 10:39:25 +0000
Message-ID: <916CE6CF87173740BC8A2CE44309696204718CB6@008-AM1MPN1-051.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.163.28.175]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 30 May 2013 10:38:34.0448 (UTC) FILETIME=[D5E98D00:01CE5D21]
X-Nokia-AV: Clean
Subject: [pcp] My review of draft-ietf-pcp-nat64-prefix64-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: Thu, 30 May 2013 10:38:40 -0000

Hi,

I read through most of the draft. I am not that expert in PCP so my focus i=
s on discovery in general.

The Introduction has a justification text:"This extension is required to he=
lp establishing communications  between IPv6-only hosts and remote IPv4-onl=
y hosts.", which is not exactly correct, as we already have one solution fo=
r that problem: draft-ietf-behave-nat64-discovery-heuristic.

The IESG approval email for heuristic-draft had text:
-
Working Group Summary

    The document specifies a heuristic that is not perfect and so some
    points were rough, but the constraint for this document was to operate
    without changes to code (only configuration) in existing networks.
    Given that constraint, there was strong consensus.  Relaxing the
    constraint would allow one to do better, and that is the focus of a
    draft recently submitted to the PCP WG.
-
Furthermore, draft-ietf-behave-nat64-learn-analysis-03.txt (RFC Editor's qu=
eue, now cleared due resolution of MISSREF) analyses various solutions that=
 we had on the table at March 2012. In particular the learn-analysis talks =
about application layer protocols (such as STUN) in section 5.8, but also l=
ists Issues (from #1 to #5). I think this PCP solution solves the issues, B=
UT with additional box on the network (PCP).

All in all, I think this document should reference to heuristic as existing=
 solution and learn-analysis as discussion paper of the problem, and say th=
at PCP solution solves the Issues (please double check that it does), but a=
lso adds the benefits that come with explicit provisioning tool - but with =
a cost of requiring said provisioning tool (PCP).

Actually, the reference to analysis document could be at section 3.1 that l=
ists the Issues listed in learn-analysis this PCP solution solves (and what=
 more is solved). The "stale Pref64::/n" is the same as Issue #4 in learn a=
nalysis?

The 3.2 could reference to learn-analysis section 4 as well, as I think the=
re is overlap?

Now that you have explicit tool for provisioning Pref64::/n, why do you not=
 provision also the suffix introduced in RFC6052? Wouldn't that make this m=
ore future proof? The format shown in 4.1 could have variable length suffix=
 field. In fact, having suffix included would allow *fixed length* 128 bit =
field-length, which might be optimized to be 96 bit field (128-32, with fir=
st bits for prefix and remaining for suffix - dropping bits for IPv4).

It seems this solution does not solve the destination-dependent Pref64::/n =
"problem" discussed in heuristic-discovery section "5.1.  Mapping of IPv4 A=
ddress Ranges to IPv6 Prefixes" ? If so, it should be mentioned that this i=
s not solved/supported.

Best regards,

	Teemu





From mohamed.boucadair@orange.com  Thu May 30 04:30:22 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A995021F946C for ; Thu, 30 May 2013 04:30:22 -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=[AWL=0.000,  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 M5v+LU-SQSmG for ; Thu, 30 May 2013 04:30:18 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 299B821F949A for ; Thu, 30 May 2013 04:30:16 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 243A822C126; Thu, 30 May 2013 13:30:15 +0200 (CEST)
Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 0515C23804B; Thu, 30 May 2013 13:30:15 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 30 May 2013 13:30:14 +0200
From: 
To: Simon Perreault 
Date: Thu, 30 May 2013 13:30:13 +0200
Thread-Topic: [pcp] UNSUPP_FAMILY error code
Thread-Index: Ac5dG4UQbYEDp4VcRHmzXtHZXjPbwwADCsJQ
Message-ID: <94C682931C08B048B7A8645303FDC9F36ED3A0836A@PUEXCB1B.nanterre.francetelecom.fr>
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>  <51A5BF11.5030100@viagenie.ca>  <94C682931C08B048B7A8645303FDC9F36ED3A08198@PUEXCB1B.nanterre.francetelecom.fr> <51A7218E.1000704@viagenie.ca>
In-Reply-To: <51A7218E.1000704@viagenie.ca>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.30.104530
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 11:30:22 -0000

Simon,=20

I disagree.

The client does not know in advance the capabilities of the PCP-controlled =
devices. A client does not know what type(s) of address(es) it will need to=
 establish communications with remotes peers (e.g., application using refer=
rals). A client may gather all external addresses/ports from pcp servers it=
 is aware of, and signal them to remote peers.

Unlike MAP4/MAP6, the server receiving a MAP request is not obliged to retu=
rn an IP address following the indication included in the suggested externa=
l IP address field. It will try to best accommodate it, but if not, it woul=
d be fine if it returns another AF address; then it is up to the client to =
make use of it or not.=20

In another words: we should not use Suggested IP Address as PREFER_AF optio=
n ;-)

Cheers,
Med


>-----Message d'origine-----
>De=A0: Simon Perreault [mailto:simon.perreault@viagenie.ca]
>Envoy=E9=A0: jeudi 30 mai 2013 11:53
>=C0=A0: BOUCADAIR Mohamed OLNC/OLN
>Cc=A0: Stuart Cheshire; pcp@ietf.org
>Objet=A0: Re: [pcp] UNSUPP_FAMILY error code
>
>Le 2013-05-30 08:32, mohamed.boucadair@orange.com a =E9crit :
>> The behavior you are proposing here recalls me what we had in earlier
>versions of the pcp specification (version 00 to version 03, PINxy OpCodes=
)
>and (version 04 to version 13, MAP4 and MAP6 OpCodes). The consensus of th=
e
>wg was to remove that design.
>>
>> This particular text in your proposal:
>>
>>>    Note that while the specific address placed in the Suggested Externa=
l
>>>    Address field is merely a suggestion that the PCP server is free to
>>>    ignore, the address family is not.
>>
>> is clearly a revival of the MAPx/PEERx opcides.
>
>This is not quite right. MAPx/PEERx were transformed into MAP/PEER
>precisely because the external address type, which was encoded in the
>opcode, is now encoded in the suggested external address field. The
>semantics have not changed. Only the syntax has.
>
>Simon
>--
>DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>STUN/TURN server               --> http://numb.viagenie.ca

From simon.perreault@viagenie.ca  Thu May 30 04:54:23 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C5421F9019 for ; Thu, 30 May 2013 04:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.383
X-Spam-Level: 
X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.217,  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 oeSCb3ZMJeaZ for ; Thu, 30 May 2013 04:54:22 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D2DCD21F8FE9 for ; Thu, 30 May 2013 04:54:21 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8DFEB4689C; Thu, 30 May 2013 07:54:16 -0400 (EDT)
Message-ID: <51A73DE7.20505@viagenie.ca>
Date: Thu, 30 May 2013 13:54:15 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: mohamed.boucadair@orange.com
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>  <51A5BF11.5030100@viagenie.ca>  <94C682931C08B048B7A8645303FDC9F36ED3A08198@PUEXCB1B.nanterre.francetelecom.fr> <51A7218E.1000704@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A0836A@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED3A0836A@PUEXCB1B.nanterre.francetelecom.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 11:54:23 -0000

Le 2013-05-30 13:30, mohamed.boucadair@orange.com a écrit :
> The client does not know in advance the capabilities of the
> PCP-controlled devices. A client does not know what type(s) of
> address(es) it will need to establish communications with remotes
> peers (e.g., application using referrals). A client may gather all
> external addresses/ports from pcp servers it is aware of, and signal
> them to remote peers.

So then it needs to send two MAP requests, one for an IPv4 external 
address and another for an IPv6 external address. Just sending one 
request and letting the server decide the external address family will 
yield one mapping of one family, not all of them.

> Unlike MAP4/MAP6, the server receiving a MAP request is not obliged
> to return an IP address following the indication included in the
> suggested external IP address field. It will try to best accommodate
> it, but if not, it would be fine if it returns another AF address;
> then it is up to the client to make use of it or not.

What use case do you have in mind? I can't understand why you would want 
the server to behave this way.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From mohamed.boucadair@orange.com  Thu May 30 05:00:06 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688A121F9354 for ; Thu, 30 May 2013 05:00:06 -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 tTXAnocxyIcb for ; Thu, 30 May 2013 05:00:02 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2F621F937A for ; Thu, 30 May 2013 05:00:02 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 99E4C264411; Thu, 30 May 2013 14:00:01 +0200 (CEST)
Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 6CB7C35C05A; Thu, 30 May 2013 14:00:01 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Thu, 30 May 2013 14:00:01 +0200
From: 
To: Simon Perreault , Stuart Cheshire 
Date: Thu, 30 May 2013 13:59:59 +0200
Thread-Topic: [pcp] UNSUPP_FAMILY error code
Thread-Index: Ac5dHEm6TG/hrWFGQm2gPLnawrMsSQAD28yw
Message-ID: <94C682931C08B048B7A8645303FDC9F36ED3A08385@PUEXCB1B.nanterre.francetelecom.fr>
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>  <51A5BF11.5030100@viagenie.ca>  <51A722CC.5030506@viagenie.ca>
In-Reply-To: <51A722CC.5030506@viagenie.ca>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.30.104530
Cc: "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 12:00:06 -0000

Re-,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Si=
mon
>Perreault
>Envoy=E9=A0: jeudi 30 mai 2013 11:59
>=C0=A0: Stuart Cheshire
>Cc=A0: pcp@ietf.org
>Objet=A0: Re: [pcp] UNSUPP_FAMILY error code
>
>Le 2013-05-30 05:52, Stuart Cheshire a =E9crit :
>>> It could be useful to point out that the set of supported external
>address families depends on the internal address family. That is, sending
>the same request over IPv4 and IPv6 could yield different results.
>>
>> Good point. How about this updated text?
>>
>>     Note that while the specific address placed in the Suggested Externa=
l
>>     Address field is merely a suggestion that the PCP server is free to
>>     ignore, the address family is not.  If the suggested address *family=
*
>>     cannot be provided by this PCP server, then it MUST return a PCP
>>     error reply containing the UNSUPP_FAMILY error code.
>
>This is important. And I think it is right. I cannot imagine a use case
>where a client doesn't know or care about the external address family.

[Med] That's not the question. The question is how an application can maxim=
ize the chances to establish successful sessions. Take the example of a Web=
RTC agent behind a NAT64 and NPTv6: should this agent request only an IPv6 =
address because it is IPv6-enabled? For me it should not. It should contact=
 PCP-enabled devices it is aware of and retrieve the external addresses man=
aged by those devices (e.g., an IPv4 address form a NAT64, an IPv6 address =
for a NPTv6); all these external addresses will be signaled to remote WebRT=
C agents. ALL @ses should be signaled because a local agent does not know i=
n advance the capabilities of the remote webRTC agent.

So repeating myself:
* the client can indicate a preferred AF=20
* the server can accept to honor it or not the preference. If the preferred=
 AF is not available, the server can return another address of distinct AF.
* the client is free to make use of the information returned by the server

No need for defining a new error code because the client is able to make a =
local decision.


>
>>     The ability to provide the requested external address family may
>>     depend on the client's internal address.
>
>internal address *family*.
>
>>     For example, a gateway that
>>     supports traditional NAT44, and native IPv6, but not NAT64, is able
>>     to provide mappings from an internal IPv4 address to an external IPv=
4
>>     address, and mappings from an internal IPv6 address to an external
>>     IPv6 address, but not mappings from an internal IPv6 address to an
>>     external IPv4 address.  When such a gateway receives a request to ma=
p
>>     an internal IPv4 address to an external IPv4 address it MUST return
>
>s/MUST/MAY/
>
>Quotas, local policy, the weather, etc. may all impact the server's
>willingness to serve that request.
>
>>     an external IPv4 address, if available, but when it receives a
>>     request to map an internal IPv6 address to an external IPv4 address
>>     it MUST return an UNSUPP_FAMILY error.
>
>Good.
>
>Simon
>--
>DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>STUN/TURN server               --> http://numb.viagenie.ca
>_______________________________________________
>pcp mailing list
>pcp@ietf.org
>https://www.ietf.org/mailman/listinfo/pcp

From simon.perreault@viagenie.ca  Thu May 30 05:11:01 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1744221F9273 for ; Thu, 30 May 2013 05:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.403
X-Spam-Level: 
X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.197,  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 CYDoBxm4gpqS for ; Thu, 30 May 2013 05:11:00 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 96A8A21F9371 for ; Thu, 30 May 2013 05:11:00 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B9FA04689C; Thu, 30 May 2013 08:10:59 -0400 (EDT)
Message-ID: <51A741D2.70503@viagenie.ca>
Date: Thu, 30 May 2013 14:10:58 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: mohamed.boucadair@orange.com
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>  <51A5BF11.5030100@viagenie.ca>  <51A722CC.5030506@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A08385@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED3A08385@PUEXCB1B.nanterre.francetelecom.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 12:11:01 -0000

Le 2013-05-30 13:59, mohamed.boucadair@orange.com a écrit :
> So repeating myself:
> * the client can indicate a preferred AF
> * the server can accept to honor it or not the preference. If the preferred
> AF is not available, the server can return another address of
> distinct AF.
> * the client is free to make use of the information
> returned by the server

So a client that asks for two mappings, one IPv6 and one IPv4, and gets, 
for example, two IPv4 mappings and would deduce that IPv6 is not 
supported. It would then delete one mapping and just go on its way. 
Hmmm... That would work I suppose, but there's a inefficiency: a useless 
mapping was created, and the client has to delete it. It seems to me 
that an error code would be cleaner.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From mohamed.boucadair@orange.com  Thu May 30 05:30:01 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C122121F92BB for ; Thu, 30 May 2013 05:30:01 -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 RLTJV6wuh-wq for ; Thu, 30 May 2013 05:29:57 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E48B821F91B8 for ; Thu, 30 May 2013 05:29:56 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 920583B5255; Thu, 30 May 2013 14:29:55 +0200 (CEST)
Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 6739323806F; Thu, 30 May 2013 14:29:55 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 30 May 2013 14:29:53 +0200
From: 
To: Simon Perreault 
Date: Thu, 30 May 2013 14:29:52 +0200
Thread-Topic: [pcp] UNSUPP_FAMILY error code
Thread-Index: Ac5dLsBconuauMHZRVyAn30c5oWZewAAf36w
Message-ID: <94C682931C08B048B7A8645303FDC9F36ED3A083AF@PUEXCB1B.nanterre.francetelecom.fr>
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>  <51A5BF11.5030100@viagenie.ca>  <51A722CC.5030506@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A08385@PUEXCB1B.nanterre.francetelecom.fr> <51A741D2.70503@viagenie.ca>
In-Reply-To: <51A741D2.70503@viagenie.ca>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 12:30:01 -0000

Re-,

Please see inline.


>-----Message d'origine-----
>De=A0: Simon Perreault [mailto:simon.perreault@viagenie.ca]
>Envoy=E9=A0: jeudi 30 mai 2013 14:11
>=C0=A0: BOUCADAIR Mohamed OLNC/OLN
>Cc=A0: Stuart Cheshire; pcp@ietf.org
>Objet=A0: Re: [pcp] UNSUPP_FAMILY error code
>
>Le 2013-05-30 13:59, mohamed.boucadair@orange.com a =E9crit :
>> So repeating myself:
>> * the client can indicate a preferred AF
>> * the server can accept to honor it or not the preference. If the
>preferred
>> AF is not available, the server can return another address of
>> distinct AF.
>> * the client is free to make use of the information
>> returned by the server
>
>So a client that asks for two mappings, one IPv6 and one IPv4, and gets,
>for example, two IPv4 mappings
[Med] If the same internal port is indicated in both requests, only one map=
ping will be created not two.

 and would deduce that IPv6 is not
>supported.
[Med] Yes.

 It would then delete one mapping and just go on its way.
[Med] If two internal ports are indicated in the two requests, then yes.

>Hmmm... That would work I suppose, but there's a inefficiency: a useless
>mapping was created, and the client has to delete it. It seems to me
>that an error code would be cleaner.

[Med] The cleaner way IMHO is to extend pcp with the capability to discover=
 PCP server capabilities.

>
>Simon
>--
>DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>STUN/TURN server               --> http://numb.viagenie.ca

From simon.perreault@viagenie.ca  Thu May 30 05:36:08 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062F921F92B7 for ; Thu, 30 May 2013 05:36:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level: 
X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, 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 tEctfXx7DX1r for ; Thu, 30 May 2013 05:36:07 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 769F121F929F for ; Thu, 30 May 2013 05:36:07 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 70BC44689C; Thu, 30 May 2013 08:36:06 -0400 (EDT)
Message-ID: <51A747B5.4030506@viagenie.ca>
Date: Thu, 30 May 2013 14:36:05 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: mohamed.boucadair@orange.com
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>  <51A5BF11.5030100@viagenie.ca>  <51A722CC.5030506@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A08385@PUEXCB1B.nanterre.francetelecom.fr> <51A741D2.70503@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083AF@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED3A083AF@PUEXCB1B.nanterre.francetelecom.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 12:36:08 -0000

Le 2013-05-30 14:29, mohamed.boucadair@orange.com a écrit :
>> So a client that asks for two mappings, one IPv6 and one IPv4, and gets,
>> for example, two IPv4 mappings
> [Med] If the same internal port is indicated in both requests, only one mapping will be created not two.

Right, which is why the client will *not* use the same internal 
address+port for the two mappings. In your use case, the client *wants* 
to get two mappings, one IPv4 and the other IPv6, so that it can 
maximize its reachability.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From mohamed.boucadair@orange.com  Thu May 30 05:53:59 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAF921F9397 for ; Thu, 30 May 2013 05:53:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.319
X-Spam-Level: 
X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[AWL=-1.929, BAYES_00=-2.599, FRT_PROFIT1=3.858, 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 3RKzXCP98obn for ; Thu, 30 May 2013 05:53:49 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 90E4021F929F for ; Thu, 30 May 2013 05:53:49 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id D9F26264870; Thu, 30 May 2013 14:53:48 +0200 (CEST)
Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id BF79C27C046; Thu, 30 May 2013 14:53:48 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 30 May 2013 14:53:48 +0200
From: 
To: "teemu.savolainen@nokia.com" , "pcp@ietf.org" 
Date: Thu, 30 May 2013 14:53:47 +0200
Thread-Topic: My review of draft-ietf-pcp-nat64-prefix64-02
Thread-Index: Ac5dHuevWC0dHYarTvOOt4eFkySJdgAE4xHA
Message-ID: <94C682931C08B048B7A8645303FDC9F36ED3A083DC@PUEXCB1B.nanterre.francetelecom.fr>
References: <916CE6CF87173740BC8A2CE44309696204718CB6@008-AM1MPN1-051.mgdnok.nokia.com>
In-Reply-To: <916CE6CF87173740BC8A2CE44309696204718CB6@008-AM1MPN1-051.mgdnok.nokia.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319
Subject: Re: [pcp] My review of draft-ietf-pcp-nat64-prefix64-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: Thu, 30 May 2013 12:53:59 -0000

Hi Teemu,

Thank you for the review.

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De=A0: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de
>teemu.savolainen@nokia.com
>Envoy=E9=A0: jeudi 30 mai 2013 12:39
>=C0=A0: pcp@ietf.org
>Objet=A0: [pcp] My review of draft-ietf-pcp-nat64-prefix64-02
>
>Hi,
>
>I read through most of the draft. I am not that expert in PCP so my focus
>is on discovery in general.
>
>The Introduction has a justification text:"This extension is required to
>help establishing communications  between IPv6-only hosts and remote IPv4-
>only hosts.", which is not exactly correct, as we already have one solutio=
n
>for that problem: draft-ietf-behave-nat64-discovery-heuristic.
>
>The IESG approval email for heuristic-draft had text:
>-
>Working Group Summary
>
>    The document specifies a heuristic that is not perfect and so some
>    points were rough, but the constraint for this document was to operate
>    without changes to code (only configuration) in existing networks.
>    Given that constraint, there was strong consensus.  Relaxing the
>    constraint would allow one to do better, and that is the focus of a
>    draft recently submitted to the PCP WG.
>-
>Furthermore, draft-ietf-behave-nat64-learn-analysis-03.txt (RFC Editor's
>queue, now cleared due resolution of MISSREF) analyses various solutions
>that we had on the table at March 2012. In particular the learn-analysis
>talks about application layer protocols (such as STUN) in section 5.8, but
>also lists Issues (from #1 to #5). I think this PCP solution solves the
>issues, BUT with additional box on the network (PCP).
>
>All in all, I think this document should reference to heuristic as existin=
g
>solution and learn-analysis as discussion paper of the problem, and say
>that PCP solution solves the Issues (please double check that it does), bu=
t
>also adds the benefits that come with explicit provisioning tool - but wit=
h
>a cost of requiring said provisioning tool (PCP).
[Med] I added this text:=20

   A more elaborated discussion can be found at
   [I-D.ietf-behave-nat64-learn-analysis].  A solution which solves some
   of these issues is specified in
   [I-D.ietf-behave-nat64-discovery-heuristic].

>
>Actually, the reference to analysis document could be at section 3.1 that
>lists the Issues listed in learn-analysis this PCP solution solves (and
>what more is solved). The "stale Pref64::/n" is the same as Issue #4 in
>learn analysis?
[Med] Yes.

>
>The 3.2 could reference to learn-analysis section 4 as well, as I think
>there is overlap?
[Med] I added this text to Section 3.2:

   This section provides some use cases to illustrate the problem space.
   More details can be found at Section 4 of
   [I-D.ietf-behave-nat64-learn-analysis].

>
>Now that you have explicit tool for provisioning Pref64::/n, why do you no=
t
>provision also the suffix introduced in RFC6052? Wouldn't that make this
>more future proof? The format shown in 4.1 could have variable length
>suffix field. In fact, having suffix included would allow *fixed length*
>128 bit field-length, which might be optimized to be 96 bit field (128-32,
>with first bits for prefix and remaining for suffix - dropping bits for
>IPv4).
[Med] I'm not sure there is a value to configure the suffix. The implementa=
tion I'm aware does not allow to configure other suffixes. My personal opin=
ion is we should not include it in the option format.

>
>It seems this solution does not solve the destination-dependent Pref64::/n
>"problem" discussed in heuristic-discovery section "5.1.  Mapping of IPv4
>Address Ranges to IPv6 Prefixes" ? If so, it should be mentioned that this
>is not solved/supported.
[Med] I guess you are referring to what we had in http://tools.ietf.org/htm=
l/draft-boucadair-pcp-nat64-prefix64-option-02#page-6. The support of this =
case will complicates the design option for a corner case. I added this sen=
tence:

   This option does not solve the destination-dependent Pref64::/n
   discovery problem discussed in Section 5.1 of
   [I-D.ietf-behave-nat64-discovery-heuristic].


>
>Best regards,
>
>	Teemu
>
>
>
>
>_______________________________________________
>pcp mailing list
>pcp@ietf.org
>https://www.ietf.org/mailman/listinfo/pcp

From mohamed.boucadair@orange.com  Thu May 30 05:59:16 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC2921F91B7 for ; Thu, 30 May 2013 05:59:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.055
X-Spam-Level: 
X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=0.193,  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 ZAPZ8TNLA23O for ; Thu, 30 May 2013 05:59:12 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id CD42721F90F4 for ; Thu, 30 May 2013 05:59:11 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 1B62B18C9AE; Thu, 30 May 2013 14:59:11 +0200 (CEST)
Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id EBB3135C05A; Thu, 30 May 2013 14:59:10 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 30 May 2013 14:59:10 +0200
From: 
To: Simon Perreault 
Date: Thu, 30 May 2013 14:59:09 +0200
Thread-Topic: [pcp] UNSUPP_FAMILY error code
Thread-Index: Ac5dMkJjQPpPpo16QuCQyf9wyJC9KgAApWZg
Message-ID: <94C682931C08B048B7A8645303FDC9F36ED3A083E3@PUEXCB1B.nanterre.francetelecom.fr>
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>  <51A5BF11.5030100@viagenie.ca>  <51A722CC.5030506@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A08385@PUEXCB1B.nanterre.francetelecom.fr> <51A741D2.70503@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083AF@PUEXCB1B.nanterre.francetelecom.fr> <51A747B5.4030506@viagenie.ca>
In-Reply-To: <51A747B5.4030506@viagenie.ca>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 12:59:16 -0000

Why?
The client can use the same internal port for both MAP requests: the only d=
iff is the AF zero address indicated in the suggested external address.
The server will return the same result for both requests if it does support=
 only one AF.
No error message. No port quota consumption.

>-----Message d'origine-----
>De=A0: Simon Perreault [mailto:simon.perreault@viagenie.ca]
>Envoy=E9=A0: jeudi 30 mai 2013 14:36
>=C0=A0: BOUCADAIR Mohamed OLNC/OLN
>Cc=A0: Stuart Cheshire; pcp@ietf.org
>Objet=A0: Re: [pcp] UNSUPP_FAMILY error code
>
>Le 2013-05-30 14:29, mohamed.boucadair@orange.com a =E9crit :
>>> So a client that asks for two mappings, one IPv6 and one IPv4, and gets=
,
>>> for example, two IPv4 mappings
>> [Med] If the same internal port is indicated in both requests, only one
>mapping will be created not two.
>
>Right, which is why the client will *not* use the same internal
>address+port for the two mappings. In your use case, the client *wants*
>to get two mappings, one IPv4 and the other IPv6, so that it can
>maximize its reachability.
>
>Simon
>--
>DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>STUN/TURN server               --> http://numb.viagenie.ca

From simon.perreault@viagenie.ca  Thu May 30 06:02:41 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A7E21F8FE9 for ; Thu, 30 May 2013 06:02:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.41
X-Spam-Level: 
X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.190,  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 Bx7CfIS-jryG for ; Thu, 30 May 2013 06:02:40 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D849521F8F2F for ; Thu, 30 May 2013 06:02:40 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0BF654689C; Thu, 30 May 2013 09:02:39 -0400 (EDT)
Message-ID: <51A74DEF.7090608@viagenie.ca>
Date: Thu, 30 May 2013 15:02:39 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: mohamed.boucadair@orange.com
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>  <51A5BF11.5030100@viagenie.ca>  <51A722CC.5030506@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A08385@PUEXCB1B.nanterre.francetelecom.fr> <51A741D2.70503@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083AF@PUEXCB1B.nanterre.francetelecom.fr> <51A747B5.4030506@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083E3@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED3A083E3@PUEXCB1B.nanterre.francetelecom.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 13:02:41 -0000

Le 2013-05-30 14:59, mohamed.boucadair@orange.com a écrit :
> The client can use the same internal port for both MAP requests: the only diff is the AF zero address indicated in the suggested external address.
> The server will return the same result for both requests if it does support only one AF.

What if the server supports two AFs? That's the whole point...

Simon

> No error message. No port quota consumption.


-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From mohamed.boucadair@orange.com  Thu May 30 06:11:17 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4CA21F9294 for ; Thu, 30 May 2013 06:11:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.073
X-Spam-Level: 
X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.175,  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 gCOnuEvMtvWx for ; Thu, 30 May 2013 06:11:13 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B572C21F90CD for ; Thu, 30 May 2013 06:11:06 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 7E7282DD033; Thu, 30 May 2013 15:11:05 +0200 (CEST)
Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 58F6835C05B; Thu, 30 May 2013 15:11:05 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Thu, 30 May 2013 15:11:05 +0200
From: 
To: Simon Perreault 
Date: Thu, 30 May 2013 15:11:03 +0200
Thread-Topic: [pcp] UNSUPP_FAMILY error code
Thread-Index: Ac5dNfgzRgpzgLCkRLqyfzvvX7+BBwAANtrw
Message-ID: <94C682931C08B048B7A8645303FDC9F36ED3A083F2@PUEXCB1B.nanterre.francetelecom.fr>
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>  <51A5BF11.5030100@viagenie.ca>  <51A722CC.5030506@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A08385@PUEXCB1B.nanterre.francetelecom.fr> <51A741D2.70503@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083AF@PUEXCB1B.nanterre.francetelecom.fr> <51A747B5.4030506@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083E3@PUEXCB1B.nanterre.francetelecom.fr> <51A74DEF.7090608@viagenie.ca>
In-Reply-To: <51A74DEF.7090608@viagenie.ca>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 13:11:17 -0000

I guess it will honor the suggested AF in each requests; unless it can't (e=
.g., port quota).=20

>-----Message d'origine-----
>De=A0: Simon Perreault [mailto:simon.perreault@viagenie.ca]
>Envoy=E9=A0: jeudi 30 mai 2013 15:03
>=C0=A0: BOUCADAIR Mohamed OLNC/OLN
>Cc=A0: Stuart Cheshire; pcp@ietf.org
>Objet=A0: Re: [pcp] UNSUPP_FAMILY error code
>
>Le 2013-05-30 14:59, mohamed.boucadair@orange.com a =E9crit :
>> The client can use the same internal port for both MAP requests: the onl=
y
>diff is the AF zero address indicated in the suggested external address.
>> The server will return the same result for both requests if it does
>support only one AF.
>
>What if the server supports two AFs? That's the whole point...
>
>Simon
>
>> No error message. No port quota consumption.
>
>
>--
>DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>STUN/TURN server               --> http://numb.viagenie.ca

From simon.perreault@viagenie.ca  Thu May 30 06:42:21 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4FB21F9193 for ; Thu, 30 May 2013 06:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.424
X-Spam-Level: 
X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.176,  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 oteUGBdaEorK for ; Thu, 30 May 2013 06:42:20 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id B947121F84D9 for ; Thu, 30 May 2013 06:42:20 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CBCE44689C; Thu, 30 May 2013 09:42:19 -0400 (EDT)
Message-ID: <51A7573A.3080906@viagenie.ca>
Date: Thu, 30 May 2013 15:42:18 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: mohamed.boucadair@orange.com
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>  <51A5BF11.5030100@viagenie.ca>  <51A722CC.5030506@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A08385@PUEXCB1B.nanterre.francetelecom.fr> <51A741D2.70503@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083AF@PUEXCB1B.nanterre.francetelecom.fr> <51A747B5.4030506@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083E3@PUEXCB1B.nanterre.francetelecom.fr> <51A74DEF.7090608@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083F2@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED3A083F2@PUEXCB1B.nanterre.francetelecom.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 13:42:21 -0000

Le 2013-05-30 15:11, mohamed.boucadair@orange.com a écrit :
> I guess it will honor the suggested AF in each requests; unless it can't (e.g., port quota).

Exactly.

Please allow me to summarize what we have agreed on so far.

We have a client that wants to maximize its reachability. It requests 
two mappings, one with suggested external AF IPv4 and the other IPv6. 
The requests will have different internal port so that they don't 
conflict. The client will advertise whatever it gets (could be zero, 
one, or two external AFs) to its peer.

Now we have two server behaviour proposals. To requests containing an 
unsupported suggested external AF, the server will either...

a) reply with UNSUPP_FAMILY,

or

b) allocate a mapping with an external AF that it does support.


Both proposals make it possible for the client to discover the set of 
supported external AFs. However, when an AF is not supported b) creates 
a useless mapping that needs to be deleted by the client.

Is this correct?

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 repenno@cisco.com  Thu May 30 06:52:16 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B23421F8B05 for ; Thu, 30 May 2013 06:52:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25uITwioghAz for ; Thu, 30 May 2013 06:52:11 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D972821F89C3 for ; Thu, 30 May 2013 06:52:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1562; q=dns/txt; s=iport; t=1369921931; x=1371131531; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=vPlBeGn+9T6eoKnHeNpn0k83IDR+Dw/veI556PRbtNQ=; b=AEXZ0IZ8I9SbJeZ+h6NdvaiquoBy/3fnFp8CNaT17rlhVyGwlUYwNZcz I9TKvtBLoSXU5HqynN9Y45atpsyhq09jR3+r81jBw9zHPgZwo8Vv/g/OO enCsdKpP3qvoa746LXsINj36/K7rOBZi65LTCBNOcOvNjPKQ+WV6bJ/gq 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgwGADRYp1GtJV2Y/2dsb2JhbABZgwkwwgt9FnSCJQEEAQEBJEcLEgEIIksLJQIEAQ0FCIgFDLp5jWN/MQeCdmEDiGePfYhyhyWDD4FpPg
X-IronPort-AV: E=Sophos;i="4.87,770,1363132800"; d="scan'208";a="216698789"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 30 May 2013 13:52:10 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4UDqAsl010860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 May 2013 13:52:10 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Thu, 30 May 2013 08:52:09 -0500
From: "Reinaldo Penno (repenno)" 
To: Simon Perreault , "mohamed.boucadair@orange.com" 
Thread-Topic: [pcp] UNSUPP_FAMILY error code
Thread-Index: AQHOXOkno2rcLHyPsEGQfvT7Mipfj5kd0oAAgAAh6oCAAAMRAIAABUgAgAABvYCAAAZxgIAAAPuAgAACWYCAAAi7AP//0HOA
Date: Thu, 30 May 2013 13:52:09 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040908D7DE@xmb-rcd-x04.cisco.com>
In-Reply-To: <51A7573A.3080906@viagenie.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.86.245.126]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <73C6FBE3CF5A574EB68010E25533C3D6@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 13:52:16 -0000

On 5/30/13 10:42 AM, "Simon Perreault"  wrote:

>Le 2013-05-30 15:11, mohamed.boucadair@orange.com a =E9crit :
>> I guess it will honor the suggested AF in each requests; unless it
>>can't (e.g., port quota).
>
>Exactly.
>
>Please allow me to summarize what we have agreed on so far.
>
>We have a client that wants to maximize its reachability. It requests
>two mappings, one with suggested external AF IPv4 and the other IPv6.
>The requests will have different internal port so that they don't
>conflict.=20


Why they can not conflict? There are two different address families.



>The client will advertise whatever it gets (could be zero,
>one, or two external AFs) to its peer.
>
>Now we have two server behaviour proposals. To requests containing an
>unsupported suggested external AF, the server will either...
>
>a) reply with UNSUPP_FAMILY,
>
>or
>
>b) allocate a mapping with an external AF that it does support.
>
>
>Both proposals make it possible for the client to discover the set of
>supported external AFs. However, when an AF is not supported b) creates
>a useless mapping that needs to be deleted by the client.
>
>Is this correct?
>
>Simon
>--=20
>DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>STUN/TURN server               --> http://numb.viagenie.ca
>_______________________________________________
>pcp mailing list
>pcp@ietf.org
>https://www.ietf.org/mailman/listinfo/pcp


From simon.perreault@viagenie.ca  Thu May 30 06:55:50 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105AC21F8B16 for ; Thu, 30 May 2013 06:55:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.164,  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 7ew+EuBed1HE for ; Thu, 30 May 2013 06:55:46 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id F2CE221F861F for ; Thu, 30 May 2013 06:55:44 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0E9E44689C; Thu, 30 May 2013 09:55:43 -0400 (EDT)
Message-ID: <51A75A5F.9040603@viagenie.ca>
Date: Thu, 30 May 2013 15:55:43 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Reinaldo Penno (repenno)" 
References: <45A697A8FFD7CF48BCF2BE7E106F06040908D7DE@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040908D7DE@xmb-rcd-x04.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 13:55:50 -0000

Le 2013-05-30 15:52, Reinaldo Penno (repenno) a écrit :
>> We have a client that wants to maximize its reachability. It requests
>> two mappings, one with suggested external AF IPv4 and the other IPv6.
>> The requests will have different internal port so that they don't
>> conflict.
>
> Why they can not conflict? There are two different address families.

Consider an IPv4-only client. It will send two requests to the PCP 
server, over IPv4, trying to get an IPv4 and an IPv6 external addresses. 
The internal IPv4 port must be different for the two requets otherwise 
there will be a conflict, even if the external AFs are different.

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 repenno@cisco.com  Thu May 30 07:01:47 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5847221F85B8 for ; Thu, 30 May 2013 07:01:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level: 
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1C7kHDeazXIb for ; Thu, 30 May 2013 07:01:41 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5C78621F8B5F for ; Thu, 30 May 2013 07:01:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1339; q=dns/txt; s=iport; t=1369922493; x=1371132093; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8IBJQQ6MPQCHtph4Rf0f+S0v8ilJlxRQoN7HDjC00Ho=; b=Fnj5psE9E4L3nKp7OVeBxkSHAmd1LBbkDwyeP5CwF4Jec5ywsSkVNVFq nWj55n41ybkRctXQfx4YjEVuFwGen65f1uJE0mlu9n8P0l2MVU9TouTFf 0dYgjofEyZ8OUBlxAPWzFc78lIwRTd76DHcpWEvxnkRQ4lJfJbKOqJe9t g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsGAG5ap1GtJXG9/2dsb2JhbABZgwkwwgt9FnSCJQEEJ1ISAQgiViUCBA4FCIgFuwmOYjEHgnZhA4hnj32Icoclgw+CJw
X-IronPort-AV: E=Sophos;i="4.87,770,1363132800"; d="scan'208";a="216702838"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 30 May 2013 14:01:29 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4UE1SiA013050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 May 2013 14:01:28 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Thu, 30 May 2013 09:01:28 -0500
From: "Reinaldo Penno (repenno)" 
To: Simon Perreault 
Thread-Topic: [pcp] UNSUPP_FAMILY error code
Thread-Index: AQHOXOkno2rcLHyPsEGQfvT7Mipfj5kd0oAAgAAh6oCAAAMRAIAABUgAgAABvYCAAAZxgIAAAPuAgAACWYCAAAi7AP//0HOAgAAzTID//89OgA==
Date: Thu, 30 May 2013 14:01:28 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040908D801@xmb-rcd-x04.cisco.com>
In-Reply-To: <51A75A5F.9040603@viagenie.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.86.245.126]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 14:01:47 -0000

Sorry, I'm probably missing something. Let's suppose the IPv4-ony client
gets two external IP:ports, one IPv4 and another IPv6. When the source
IPv6 incoming connection gets translated to an IPv4 source address, if it
does not conflict with any other IPv4 native session, there is no
conflict, right? From the client perspective it is just a bunch of
incoming IPv4 connections.

On 5/30/13 10:55 AM, "Simon Perreault"  wrote:

>Le 2013-05-30 15:52, Reinaldo Penno (repenno) a =E9crit :
>>> We have a client that wants to maximize its reachability. It requests
>>> two mappings, one with suggested external AF IPv4 and the other IPv6.
>>> The requests will have different internal port so that they don't
>>> conflict.
>>
>> Why they can not conflict? There are two different address families.
>
>Consider an IPv4-only client. It will send two requests to the PCP
>server, over IPv4, trying to get an IPv4 and an IPv6 external addresses.
>The internal IPv4 port must be different for the two requets otherwise
>there will be a conflict, even if the external AFs are different.
>
>Simon
>--=20
>DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>STUN/TURN server               --> http://numb.viagenie.ca


From mohamed.boucadair@orange.com  Thu May 30 07:04:44 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC21C21F85B8 for ; Thu, 30 May 2013 07:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level: 
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.161,  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 O8PrcSo6dt7L for ; Thu, 30 May 2013 07:04:37 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 135B821F8E9A for ; Thu, 30 May 2013 07:04:31 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 1C8373B5205; Thu, 30 May 2013 16:04:27 +0200 (CEST)
Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id EE05E238048; Thu, 30 May 2013 16:04:26 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Thu, 30 May 2013 16:04:26 +0200
From: 
To: Simon Perreault 
Date: Thu, 30 May 2013 16:04:25 +0200
Thread-Topic: [pcp] UNSUPP_FAMILY error code
Thread-Index: Ac5dO4NlBYh/BDLBSJuSKHC6IHxrgwAAIRyQ
Message-ID: <94C682931C08B048B7A8645303FDC9F36ED3A0846F@PUEXCB1B.nanterre.francetelecom.fr>
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>  <51A5BF11.5030100@viagenie.ca>  <51A722CC.5030506@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A08385@PUEXCB1B.nanterre.francetelecom.fr> <51A741D2.70503@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083AF@PUEXCB1B.nanterre.francetelecom.fr> <51A747B5.4030506@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083E3@PUEXCB1B.nanterre.francetelecom.fr> <51A74DEF.7090608@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083F2@PUEXCB1B.nanterre.francetelecom.fr> <51A7573A.3080906@viagenie.ca>
In-Reply-To: <51A7573A.3080906@viagenie.ca>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.30.124245
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 14:04:44 -0000

Agree modulo the following minor precision:=20
* two mappings are created only if distinct internal ports are indicated in=
 both MAP requests.=20

If pcp supports capability discovery:=20
* The extra mapping can be avoided=20
* useless MAP requests can be avoided too: only one request will be sent to=
 the server instead of two requests.

Now, where should we put the bar?

(1) no useless MAP requests?
(2) no extra mapping at all?
(3) combination of (1) and (3)

Cheers,
Med

>-----Message d'origine-----
>De=A0: Simon Perreault [mailto:simon.perreault@viagenie.ca]
>Envoy=E9=A0: jeudi 30 mai 2013 15:42
>=C0=A0: BOUCADAIR Mohamed OLNC/OLN
>Cc=A0: Stuart Cheshire; pcp@ietf.org
>Objet=A0: Re: [pcp] UNSUPP_FAMILY error code
>
>Le 2013-05-30 15:11, mohamed.boucadair@orange.com a =E9crit :
>> I guess it will honor the suggested AF in each requests; unless it can't
>(e.g., port quota).
>
>Exactly.
>
>Please allow me to summarize what we have agreed on so far.
>
>We have a client that wants to maximize its reachability. It requests
>two mappings, one with suggested external AF IPv4 and the other IPv6.
>The requests will have different internal port so that they don't
>conflict. The client will advertise whatever it gets (could be zero,
>one, or two external AFs) to its peer.
>
>Now we have two server behaviour proposals. To requests containing an
>unsupported suggested external AF, the server will either...
>
>a) reply with UNSUPP_FAMILY,
>
>or
>
>b) allocate a mapping with an external AF that it does support.
>
>
>Both proposals make it possible for the client to discover the set of
>supported external AFs. However, when an AF is not supported b) creates
>a useless mapping that needs to be deleted by the client.
>
>Is this correct?
>
>Simon
>--
>DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>STUN/TURN server               --> http://numb.viagenie.ca

From simon.perreault@viagenie.ca  Thu May 30 07:11:28 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9730621F871C for ; Thu, 30 May 2013 07:11:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.146
X-Spam-Level: 
X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, 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 TbuByI98nKat for ; Thu, 30 May 2013 07:11:28 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 19A8621F85F4 for ; Thu, 30 May 2013 07:10:59 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E37DF4689C; Thu, 30 May 2013 10:10:57 -0400 (EDT)
Message-ID: <51A75DF1.6080408@viagenie.ca>
Date: Thu, 30 May 2013 16:10:57 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Reinaldo Penno (repenno)" 
References: <45A697A8FFD7CF48BCF2BE7E106F06040908D801@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040908D801@xmb-rcd-x04.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 14:11:28 -0000

Le 2013-05-30 16:01, Reinaldo Penno (repenno) a écrit :
> Sorry, I'm probably missing something. Let's suppose the IPv4-ony client
> gets two external IP:ports, one IPv4 and another IPv6. When the source
> IPv6 incoming connection gets translated to an IPv4 source address, if it
> does not conflict with any other IPv4 native session, there is no
> conflict, right? From the client perspective it is just a bunch of
> incoming IPv4 connections.

Assuming the 44 and 46 mappings have the same internal port... (which I 
assert is impossible but let's try it anyway)

There will be a conflict when the internal host sends a packet to the 
outside from this internal port. Will NAT44 or NAT46 be applied to the 
mapping? A mapping being endpoint-independent by PCP MAP definition, we 
can't use the destination to answer that question.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From simon.perreault@viagenie.ca  Thu May 30 07:13:46 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FED21F880F for ; Thu, 30 May 2013 07:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163,  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 v8oFItE3hszr for ; Thu, 30 May 2013 07:13:45 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3080021F8700 for ; Thu, 30 May 2013 07:13:43 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E2E984689C; Thu, 30 May 2013 10:13:42 -0400 (EDT)
Message-ID: <51A75E96.1030303@viagenie.ca>
Date: Thu, 30 May 2013 16:13:42 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: mohamed.boucadair@orange.com
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>  <51A5BF11.5030100@viagenie.ca>  <51A722CC.5030506@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A08385@PUEXCB1B.nanterre.francetelecom.fr> <51A741D2.70503@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083AF@PUEXCB1B.nanterre.francetelecom.fr> <51A747B5.4030506@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083E3@PUEXCB1B.nanterre.francetelecom.fr> <51A74DEF.7090608@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083F2@PUEXCB1B.nanterre.francetelecom.fr> <51A7573A.3080906@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A0846F@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED3A0846F@PUEXCB1B.nanterre.francetelecom.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 14:13:46 -0000

Le 2013-05-30 16:04, mohamed.boucadair@orange.com a écrit :
> Agree modulo the following minor precision:
> * two mappings are created only if distinct internal ports are indicated in both MAP requests.

Yes.

But why would a client send different requests with the same internal port?

> If pcp supports capability discovery:
> * The extra mapping can be avoided
> * useless MAP requests can be avoided too: only one request will be sent to the server instead of two requests.
>
> Now, where should we put the bar?
>
> (1) no useless MAP requests?
> (2) no extra mapping at all?
> (3) combination of (1) and (3)

If you just replace the useless MAP request with a capability discovery 
request, you haven't gained anything efficiency-wise but you have 
increased complexity a lot.

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 Ted.Lemon@nominum.com  Thu May 30 07:14:37 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F01621F8733 for ; Thu, 30 May 2013 07:14:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.54
X-Spam-Level: 
X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 4Qx1g1BWAi99 for ; Thu, 30 May 2013 07:14:31 -0700 (PDT)
Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id D7D0D21F8825 for ; Thu, 30 May 2013 07:14:30 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUadexn8VgBHtn8f58ttdHkc9rseMy3Q5@postini.com; Thu, 30 May 2013 07:14:30 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 461CB1B8199 for ; Thu, 30 May 2013 07:14:30 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 39615190052; Thu, 30 May 2013 07:14:30 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 30 May 2013 07:14:30 -0700
From: Ted Lemon 
To: Simon Perreault 
Thread-Topic: [pcp] UNSUPP_FAMILY error code
Thread-Index: AQHOVpFL8brGRjBzTUyoANqbDdutd5kRE6yAgAA/EACACho5gIAABf2AgABKLICAAJuIgIABQbQAgABmXACAACHqgIAAAxIAgAAFSACAAAG8gIAABnKAgAAA+4CAAAJYgIAACLwAgAACwICAAAD/gIAABT+A
Date: Thu, 30 May 2013 14:14:29 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751BB71A@mbx-01.win.nominum.com>
References: <45A697A8FFD7CF48BCF2BE7E106F06040908D7DE@xmb-rcd-x04.cisco.com> <51A75A5F.9040603@viagenie.ca>
In-Reply-To: <51A75A5F.9040603@viagenie.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 14:14:37 -0000

On May 30, 2013, at 9:55 AM, Simon Perreault  =
wrote:
> Consider an IPv4-only client. It will send two requests to the PCP server=
, over IPv4, trying to get an IPv4 and an IPv6 external addresses. The inte=
rnal IPv4 port must be different for the two requets otherwise there will b=
e a conflict, even if the external AFs are different.

In this particular use case packets arriving via IPv4 and IPv6 would both b=
e delivered to the same port, which seems okay, not a conflict.


From simon.perreault@viagenie.ca  Thu May 30 07:16:02 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4888521F8F9E for ; Thu, 30 May 2013 07:16:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.446
X-Spam-Level: 
X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.154,  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 8fnJRtjXJY0K for ; Thu, 30 May 2013 07:16:01 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA1F21F871C for ; Thu, 30 May 2013 07:16:01 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7E1354689C; Thu, 30 May 2013 10:16:00 -0400 (EDT)
Message-ID: <51A75F1F.9070703@viagenie.ca>
Date: Thu, 30 May 2013 16:15:59 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: Ted Lemon 
References: <45A697A8FFD7CF48BCF2BE7E106F06040908D7DE@xmb-rcd-x04.cisco.com> <51A75A5F.9040603@viagenie.ca> <8D23D4052ABE7A4490E77B1A012B6307751BB71A@mbx-01.win.nominum.com>
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751BB71A@mbx-01.win.nominum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 14:16:02 -0000

Le 2013-05-30 16:14, Ted Lemon a écrit :
> On May 30, 2013, at 9:55 AM, Simon Perreault  wrote:
>> Consider an IPv4-only client. It will send two requests to the PCP server, over IPv4, trying to get an IPv4 and an IPv6 external addresses. The internal IPv4 port must be different for the two requets otherwise there will be a conflict, even if the external AFs are different.
>
> In this particular use case packets arriving via IPv4 and IPv6 would both be delivered to the same port, which seems okay, not a conflict.

See my reply to Reinaldo. The conflict is in the other direction.

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 repenno@cisco.com  Thu May 30 07:16:06 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9DF21F8FED for ; Thu, 30 May 2013 07:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.849
X-Spam-Level: 
X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qSBgZ4h39wa for ; Thu, 30 May 2013 07:16:01 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B24C721F8733 for ; Thu, 30 May 2013 07:15:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1450; q=dns/txt; s=iport; t=1369923360; x=1371132960; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=PlXb6y46rlT3j1d23N0kC8DSfIumF02QF7OW2tW+Fto=; b=MOtDIx5VK5WJllXwNHGJOkM6HHsYG7aCrQnWcv/iTTjTz8eI1oIdpOhH XmFt85ZC6IJDeV7AlR0Ob07RRBMzRs97jC27CiAfwwLYOnkaiO2GcDMkP 1KRVj47+BjYP8xmB90KZelq1Njn9tqzhrBYZ95KvFd6npBHohOTb3mUJj g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAGVdp1GtJV2d/2dsb2JhbABZgwkwwg99FnSCIwEBAQMBJ1IFDQEIIlYlAgQOBQiHfwa7HY5rMQeCdmEDiGiPf4hyhyWDD4In
X-IronPort-AV: E=Sophos;i="4.87,770,1363132800"; d="scan'208";a="216734759"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 30 May 2013 14:15:56 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4UEFt8u008274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 May 2013 14:15:55 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Thu, 30 May 2013 09:15:54 -0500
From: "Reinaldo Penno (repenno)" 
To: Simon Perreault 
Thread-Topic: [pcp] UNSUPP_FAMILY error code
Thread-Index: AQHOXOkno2rcLHyPsEGQfvT7Mipfj5kd0oAAgAAh6oCAAAMRAIAABUgAgAABvYCAAAZxgIAAAPuAgAACWYCAAAi7AP//0HOAgAAzTID//89OgIAANPSA///PFQA=
Date: Thu, 30 May 2013 14:15:54 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040908D837@xmb-rcd-x04.cisco.com>
In-Reply-To: <51A75DF1.6080408@viagenie.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.86.245.126]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <019AA445E7024746885B6FF99429B697@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 14:16:06 -0000

On 5/30/13 11:10 AM, "Simon Perreault"  wrote:

>Le 2013-05-30 16:01, Reinaldo Penno (repenno) a =E9crit :
>> Sorry, I'm probably missing something. Let's suppose the IPv4-ony client
>> gets two external IP:ports, one IPv4 and another IPv6. When the source
>> IPv6 incoming connection gets translated to an IPv4 source address, if
>>it
>> does not conflict with any other IPv4 native session, there is no
>> conflict, right? From the client perspective it is just a bunch of
>> incoming IPv4 connections.
>
>Assuming the 44 and 46 mappings have the same internal port... (which I
>assert is impossible but let's try it anyway)
>
>There will be a conflict when the internal host sends a packet to the
>outside from this internal port.

[RP] The outside addresses will all be v4 address since incoming packets
will go through the NAT. V6 packets will become IPv4 packets. As long as
the source IP:port of these incoming packets do not conflict, the answer,
which will be directed to those will not conflict either.

> Will NAT44 or NAT46 be applied to the
>mapping? A mapping being endpoint-independent by PCP MAP definition, we
>can't use the destination to answer that question.
>
>Simon
>--=20
>DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>STUN/TURN server               --> http://numb.viagenie.ca


From simon.perreault@viagenie.ca  Thu May 30 07:18:37 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712D421F8B90 for ; Thu, 30 May 2013 07:18:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.854
X-Spam-Level: 
X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.454, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, 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 LZehOUWROwFf for ; Thu, 30 May 2013 07:18:36 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id B9A1221F88A9 for ; Thu, 30 May 2013 07:18:36 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3612B4689C; Thu, 30 May 2013 10:18:35 -0400 (EDT)
Message-ID: <51A75FBA.5090402@viagenie.ca>
Date: Thu, 30 May 2013 16:18:34 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Reinaldo Penno (repenno)" 
References: <45A697A8FFD7CF48BCF2BE7E106F06040908D837@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040908D837@xmb-rcd-x04.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 14:18:37 -0000

Le 2013-05-30 16:15, Reinaldo Penno (repenno) a écrit :
>>> Sorry, I'm probably missing something. Let's suppose the IPv4-ony client
>>> gets two external IP:ports, one IPv4 and another IPv6. When the source
>>> IPv6 incoming connection gets translated to an IPv4 source address, if
>>> it
>>> does not conflict with any other IPv4 native session, there is no
>>> conflict, right? From the client perspective it is just a bunch of
>>> incoming IPv4 connections.
>>
>> Assuming the 44 and 46 mappings have the same internal port... (which I
>> assert is impossible but let's try it anyway)
>>
>> There will be a conflict when the internal host sends a packet to the
>> outside from this internal port.
>
> [RP] The outside addresses will all be v4 address since incoming packets
> will go through the NAT. V6 packets will become IPv4 packets. As long as
> the source IP:port of these incoming packets do not conflict, the answer,
> which will be directed to those will not conflict either.

Sorry, I can't make sense of this.

I think you misread. I'm talking about internal --> external packet flow.

Simon

>> Will NAT44 or NAT46 be applied to the
>> mapping? A mapping being endpoint-independent by PCP MAP definition, we
>> can't use the destination to answer that question.

-- 
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 repenno@cisco.com  Thu May 30 07:31:16 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561A921F8E93 for ; Thu, 30 May 2013 07:31:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.699
X-Spam-Level: 
X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shYh2tx-oFIf for ; Thu, 30 May 2013 07:31:08 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0213C21F920B for ; Thu, 30 May 2013 07:29:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2274; q=dns/txt; s=iport; t=1369924198; x=1371133798; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=iaYMGJvCrhUSGfTZHLHDcdZZ0CvxATWzdgc2SZzUO9c=; b=EuJPHHM503qAn7xwvxw9+hrm+yZa+LJVnZhABmE69KsFZPhgvj5CHvu+ lPOxeQ50M+LE4xmaadKGCBN93KIFuYVBxo+Q2twEM9QmveGnMTm/LR336 nJ8PSvEhTRiEskYy03a6aOsNrn692/d6FkJHj+4w0DX19BfMDMMgPVjzK 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAHVhp1GtJXG8/2dsb2JhbABZgwkwwg99FnSCJQEEJ1ISAQgiViUCBA4FCIgFux6OazEHgnZhA4hoj3+Icoclgw+CJw
X-IronPort-AV: E=Sophos;i="4.87,770,1363132800"; d="scan'208";a="216716024"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 30 May 2013 14:29:49 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4UETneZ014819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 May 2013 14:29:49 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 30 May 2013 09:29:49 -0500
From: "Reinaldo Penno (repenno)" 
To: Simon Perreault 
Thread-Topic: [pcp] UNSUPP_FAMILY error code
Thread-Index: AQHOXOkno2rcLHyPsEGQfvT7Mipfj5kd0oAAgAAh6oCAAAMRAIAABUgAgAABvYCAAAZxgIAAAPuAgAACWYCAAAi7AP//0HOAgAAzTID//89OgIAANPSA///PFQAABmGJAP//0NeA
Date: Thu, 30 May 2013 14:29:49 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040908D861@xmb-rcd-x04.cisco.com>
In-Reply-To: <51A75FBA.5090402@viagenie.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.86.245.126]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <66D33D43184D6D43A956E46FF5EB1633@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 14:31:16 -0000

Okay, client creates to MAP mappings

(1) 2000::1, 10000 -> 100.0.0.2:80

(2) 200.0.0.2, 10000 -> 100.0.0.2:80


Connections are started from the outside (this is a MAP mapping). A packet
from 2001::1 to 2000::1 will get translated to

10.0.0.2: 3000 (or some other IP address:port depending on translation
algorithm) -> 100.0.0.2:80

Host at 100:0.0.2:80 will send reply packets to 10.0.0.2:3000 which will
be translated to IPv6.

Public Internet Ipv4 hosts will send packets to 100.0.0.2:80 and its
source will not get translated, replies will be sent to the source address
of the packet.


Is that what you mean?



On 5/30/13 11:18 AM, "Simon Perreault"  wrote:

>Le 2013-05-30 16:15, Reinaldo Penno (repenno) a =E9crit :
>>>> Sorry, I'm probably missing something. Let's suppose the IPv4-ony
>>>>client
>>>> gets two external IP:ports, one IPv4 and another IPv6. When the source
>>>> IPv6 incoming connection gets translated to an IPv4 source address, if
>>>> it
>>>> does not conflict with any other IPv4 native session, there is no
>>>> conflict, right? From the client perspective it is just a bunch of
>>>> incoming IPv4 connections.
>>>
>>> Assuming the 44 and 46 mappings have the same internal port... (which I
>>> assert is impossible but let's try it anyway)
>>>
>>> There will be a conflict when the internal host sends a packet to the
>>> outside from this internal port.
>>
>> [RP] The outside addresses will all be v4 address since incoming packets
>> will go through the NAT. V6 packets will become IPv4 packets. As long as
>> the source IP:port of these incoming packets do not conflict, the
>>answer,
>> which will be directed to those will not conflict either.
>
>Sorry, I can't make sense of this.
>
>I think you misread. I'm talking about internal --> external packet flow.
>
>Simon
>
>>> Will NAT44 or NAT46 be applied to the
>>> mapping? A mapping being endpoint-independent by PCP MAP definition, we
>>> can't use the destination to answer that question.
>
>--=20
>DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>STUN/TURN server               --> http://numb.viagenie.ca


From mohamed.boucadair@orange.com  Thu May 30 07:33:11 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB31121F8411 for ; Thu, 30 May 2013 07:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.148, 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 bRhpkJTvIVMX for ; Thu, 30 May 2013 07:33:06 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id AD46B21F8E1C for ; Thu, 30 May 2013 07:32:23 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 5AC7618C531; Thu, 30 May 2013 16:32:22 +0200 (CEST)
Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 3E7BF27C053; Thu, 30 May 2013 16:32:22 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 30 May 2013 16:32:22 +0200
From: 
To: Simon Perreault 
Date: Thu, 30 May 2013 16:32:20 +0200
Thread-Topic: [pcp] UNSUPP_FAMILY error code
Thread-Index: Ac5dP+TsXODpYyGQSZ2rSG47p8W1OAAASGWg
Message-ID: <94C682931C08B048B7A8645303FDC9F36ED3A08499@PUEXCB1B.nanterre.francetelecom.fr>
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>  <51A5BF11.5030100@viagenie.ca>  <51A722CC.5030506@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A08385@PUEXCB1B.nanterre.francetelecom.fr> <51A741D2.70503@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083AF@PUEXCB1B.nanterre.francetelecom.fr> <51A747B5.4030506@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083E3@PUEXCB1B.nanterre.francetelecom.fr> <51A74DEF.7090608@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083F2@PUEXCB1B.nanterre.francetelecom.fr> <51A7573A.3080906@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A0846F@PUEXCB1B.nanterre.francetelecom.fr> <51A75E96.1030303@viagenie.ca>
In-Reply-To: <51A75E96.1030303@viagenie.ca>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 14:33:11 -0000

I won't discuss the capability complexity for now because I'd like we focus=
 on the optimization we want to achieve, whether the use case is a valid on=
e or not, whether a failure is experienced, etc.


>-----Message d'origine-----
>De=A0: Simon Perreault [mailto:simon.perreault@viagenie.ca]
>Envoy=E9=A0: jeudi 30 mai 2013 16:14
>=C0=A0: BOUCADAIR Mohamed OLNC/OLN
>Cc=A0: Stuart Cheshire; pcp@ietf.org
>Objet=A0: Re: [pcp] UNSUPP_FAMILY error code
>
>Le 2013-05-30 16:04, mohamed.boucadair@orange.com a =E9crit :
>> Agree modulo the following minor precision:
>> * two mappings are created only if distinct internal ports are indicated
>in both MAP requests.
>
>Yes.
>
>But why would a client send different requests with the same internal port=
?
>
>> If pcp supports capability discovery:
>> * The extra mapping can be avoided
>> * useless MAP requests can be avoided too: only one request will be sent
>to the server instead of two requests.
>>
>> Now, where should we put the bar?
>>
>> (1) no useless MAP requests?
>> (2) no extra mapping at all?
>> (3) combination of (1) and (3)
>
>If you just replace the useless MAP request with a capability discovery
>request, you haven't gained anything efficiency-wise but you have
>increased complexity a lot.
>
>Simon
>--
>DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>STUN/TURN server               --> http://numb.viagenie.ca

From simon.perreault@viagenie.ca  Thu May 30 07:35:30 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C314621F8B90 for ; Thu, 30 May 2013 07:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.432
X-Spam-Level: 
X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.168,  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 hMN74a-buCt3 for ; Thu, 30 May 2013 07:35:22 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA5E21F8263 for ; Thu, 30 May 2013 07:35:19 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 642F84689C; Thu, 30 May 2013 10:35:17 -0400 (EDT)
Message-ID: <51A763A4.4040300@viagenie.ca>
Date: Thu, 30 May 2013 16:35:16 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Reinaldo Penno (repenno)" 
References: <45A697A8FFD7CF48BCF2BE7E106F06040908D861@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040908D861@xmb-rcd-x04.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 14:35:30 -0000

Le 2013-05-30 16:29, Reinaldo Penno (repenno) a écrit :
> Okay, client creates to MAP mappings
>
> (1) 2000::1, 10000 -> 100.0.0.2:80
>
> (2) 200.0.0.2, 10000 -> 100.0.0.2:80

(assuming left = external and right = internal)

> Connections are started from the outside (this is a MAP mapping).

Stop right here. A mapping created with MAP also applies to connections 
initiated from the inside. That's precisely why there's a conflict in 
the internal --> external direction.

Above, the arrows should be bidirectional.

> A packet
> from 2001::1 to 2000::1 will get translated to
>
> 10.0.0.2: 3000 (or some other IP address:port depending on translation
> algorithm) -> 100.0.0.2:80
>
> Host at 100:0.0.2:80 will send reply packets to 10.0.0.2:3000 which will
> be translated to IPv6.
>
> Public Internet Ipv4 hosts will send packets to 100.0.0.2:80 and its
> source will not get translated, replies will be sent to the source address
> of the packet.
>
>
> Is that what you mean?

No. I'm not talking about reply packets, which could work if the NAT 
tracks sessions. I'm talking about packets not associated with an 
existing session, sent by the internal host to the outside, with 
100.0.0.2:80 as source. Where should those go? If the NAT doesn't track 
sessions, reply packet sourced from 100.0.0.2:80 are also concerned.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From dwing@cisco.com  Thu May 30 07:39:03 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D957521F8EB2 for ; Thu, 30 May 2013 07:39:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.441
X-Spam-Level: 
X-Spam-Status: No, score=-110.441 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315, 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 bBaSox8EpHQr for ; Thu, 30 May 2013 07:38:59 -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 7F56C21F8FA3 for ; Thu, 30 May 2013 07:38:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9290; q=dns/txt; s=iport; t=1369924733; x=1371134333; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Arb0HjRAcLARn1TX7/4LsrUz+79cEv7RO2eMBk5tzuU=; b=YeOihrCowDz7rM4YxGYI/DzQq6K2tT5skBStwZGcMrbv7p5aFUp8aKkr 43HsK+Eiu3yAD30E5cJWAsGMjDeiSLIZCYQ3I7TpkpNvzQk1SKfYGdVjy DSYfwL7IFKxGIp8lompQrPGz0k1C6LbYfyf5tv+xKAj1ZFV5KG8WP4Ri8 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAAVkp1GrRDoI/2dsb2JhbABZgwkwwg99FnSCIwEBAQMBAQEBawsFCwsYJwcnHxEZiAcFDbsdjVmBEDMHgnZhA4kgjh6BKYR1iyKDLxyBLAc
X-IronPort-AV: E=Sophos;i="4.87,770,1363132800"; d="scan'208";a="82406449"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 30 May 2013 14:38:38 +0000
Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4UEcadJ004644; Thu, 30 May 2013 14:38:36 GMT
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Dan Wing 
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED3A0819B@PUEXCB1B.nanterre.francetelecom.fr>
Date: Thu, 30 May 2013 07:38:36 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <1852EA08-8846-4052-B751-5EFCBCB4C2F4@cisco.com>
References: <94C682931C08B048B7A8645303FDC9F36EB735607B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36ECFB4A912@PUEXCB1B.nanterre.francetelecom.fr> <1455AEDA-6707-4496-8D19-5367CBCB543D@cisco.com> <94C682931C08B048B7A8645303FDC9F36ED3A0819B@PUEXCB1B.nanterre.francetelecom.fr>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.1503)
Cc: "pcp@ietf.org" 
Subject: Re: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
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, 30 May 2013 14:39:04 -0000

On May 29, 2013, at 11:36 PM, mohamed.boucadair@orange.com wrote:

> Hi Dan,
>=20
>=20
>=20
>> -----Message d'origine-----
>> De : Dan Wing [mailto:dwing@cisco.com]
>> Envoy=E9 : mercredi 29 mai 2013 19:39
>> =C0 : BOUCADAIR Mohamed OLNC/OLN
>> Cc : pcp@ietf.org
>> Objet : Re: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown =
Options
>>=20
>>=20
>> On May 22, 2013, at 2:26 AM, mohamed.boucadair@orange.com wrote:
>>=20
>>> Re-,
>>>=20
>>> Many thanks for all of you who provided a feedback for this point. =
As a
>> conclusion of this discussion, below a proposed change:
>>>=20
>>> OLD:
>>>=20
>>> 7. PCP Proxy Co-located with a NAT Function
>>>=20
>>>  When the PCP Proxy is co-located with a NAT function, it MUST =
update
>>>  the content of received requests with the mapped port number and =
the
>>>  address belonging to the external interface of the PCP Proxy (i.e.,
>>>  after the NAT operation) and not as initially positioned by the PCP
>>>  Client.  For the reverse path, PCP responses MUST be updated by the
>>>  PCP Proxy to replace the internal port number to what has been
>>>  initially positioned by the PCP Client.  For this purpose the PCP
>>>  Proxy MUST have an access to the local NAT state maintained =
locally.
>>>  Because PCP messages with an unknown OpCode or Option can carry a
>>>  hidden internal address or internal port which will not be
>>>  translated:
>>>=20
>>>  o  a PCP Proxy co-located with a NAT SHOULD reject by an
>>>     UNSUPP_OPCODE error response a received request with an unknown
>>>     OpCode;
>>>=20
>>>  o  a PCP Proxy co-located with a NAT SHOULD reject by an
>>>     UNSUPP_OPTION error response a received request with a =
mandatory-
>>>     to-process unknown Option;
>>>=20
>>>  o  a PCP Proxy co-located with a NAT MAY remove any optional-to-
>>>     process unknown Options from received requests before forwarding
>>>     them.
>>>=20
>>>  Rejecting unknown Options and OpCodes has the drawback of =
preventing
>>>  a PCP Client to make use of new capabilities offered by the PCP
>>>  Server but not supported by the PCP Proxy even if no IP address
>>>  and/or port is included in the Option/OpCode.
>>>=20
>>> NEW:
>>>=20
>>> 7.  PCP Proxy Co-located with a NAT Function
>>>=20
>>>  When the PCP Proxy is co-located with a NAT function, it MUST =
update
>>>  the content of received requests with the mapped port number and =
the
>>>  address belonging to the external interface of the PCP Proxy (i.e.,
>>>  after the NAT operation) and not as initially conveyed by the PCP
>>>  Client.  For the reverse path, PCP responses MUST be updated by the
>>>  PCP Proxy to replace the internal port number to what has been
>>>  initially positioned by the PCP Client.  For this purpose the PCP
>>>  Proxy MUST have an access to the local NAT state maintained =
locally.
>>>=20
>>>  By default, the PCP Proxy MUST relay unknown OpCodes and mandatory-
>>>  to-process unknown Options.  Rejecting unknown Options and OpCodes
>>>  has the drawback of preventing a PCP Client to make use of new
>>>  capabilities offered by the PCP Server but not supported by the PCP
>>>  Proxy even if no IP address and/or port is included in the Option/
>>>  OpCode.
>>>=20
>>>  Because PCP messages with an unknown OpCode or mandatory-to-process
>>>  unknown Options can carry a hidden internal address or internal =
port
>>>  which will not be translated, A PCP Proxy MUST be configurable to
>>>  disable relaying unknown OpCodes and mandatory-to-process unknown
>>>  Options.
>>=20
>> The text needs to be clearer on the suggested default,
>=20
> [Med] The default and justification are stated in the previous =
paragraph.=20

I have thought about this some more, and I am concerned not with the =
wording, but that the industry will not be able to update the =
configuration of the millions of deployed PCP proxies to block a new =
opcode or a new mandatory-to-process option that really does need =
processing within the PCP proxy.  Additionally, PCP proxy developers =
will be worried about new opcodes which necessitate updating state in =
the PCP proxy, and will be reluctant to follow this part of the =
(eventual) RFC.


How about a different approach:  a proxy, when forwarding a PCP request, =
indicates whenever it does not support an opcode or does not support a =
mandatory-to-process option that it is proxying.  This indication would =
be using a new option we would define in the pcp-proxy document, lets =
call it FORWARDED-WITHOUT-COMPREHENSION.  The final PCP server (which is =
not proxying) already has to understand any new opcode and any new =
mandatory-to-process option (or it will generate an error).  The PCP =
server, which is processing the new opcode or the new =
mandatory-to-process option must know the semantics of that new option =
(the poor PCP proxy does not), and if the semantics need PCP proxy =
involvement, it returns a new error we define, lets call that error =
NEEDS_PROXY_COMPREHENSION.  This technique has the advantage that PCP =
proxies don't need to be updated to block new opcodes or block new =
mandatory-to-process options.

-d


>=20
>=20
> and why the default
>> is suggested.  Otherwise we will have proxies implemented that return =
an
>> error for unknown opcodes, especially because there are several =
sentences
>> explaining what MUST be done when returning an error.
>>=20
>>=20
>> I am still uncomfortable with how this will work in practice.  We =
need to
>> think about a new opcode which has embedded ip address and port =
(somewhat
>> like MAP or PEER) and how that could be successfully deployed with a =
PCP
>> proxy compliant with this document.
>>=20
>> -d
>>=20
>>=20
>>> If the PCP Proxy is configured to disable relaying unknown
>>>  OpCodes and mandatory-to-process unknown Options, the PCP Proxy =
MUST
>>>  behave as follows:
>>>=20
>>>  o  a PCP Proxy co-located with a NAT MUST reject by an =
UNSUPP_OPCODE
>>>     error response a received request with an unknown OpCode.
>>>=20
>>>  o  a PCP Proxy co-located with a NAT MUST reject by an =
UNSUPP_OPTION
>>>     error response a received request with a mandatory-to-process
>>>     unknown Option.
>>>=20
>>>=20
>>> If there is no objection, this change will be include in the next =
version
>> of the spec.
>>>=20
>>> Cheers,
>>> Med
>>>=20
>>>> -----Message d'origine-----
>>>> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part =
de
>>>> mohamed.boucadair@orange.com
>>>> Envoy=E9 : mardi 12 mars 2013 11:44
>>>> =C0 : pcp@ietf.org
>>>> Objet : [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown =
Options
>>>>=20
>>>> Dear all,
>>>>=20
>>>> http://tools.ietf.org/html/draft-ietf-pcp-proxy-02 says:
>>>>=20
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>> Because PCP messages with an unknown OpCode or Option can carry a
>>>> hidden internal address or internal port which will not be
>>>> translated:
>>>>=20
>>>> o  a PCP Proxy co-located with a NAT SHOULD reject by an
>>>>    UNSUPP_OPCODE error response a received request with an unknown
>>>>    OpCode;
>>>>=20
>>>> o  a PCP Proxy co-located with a NAT SHOULD reject by an
>>>>    UNSUPP_OPTION error response a received request with a =
mandatory-
>>>>    to-process unknown Option;
>>>>=20
>>>> o  a PCP Proxy co-located with a NAT MAY remove any optional-to-
>>>>    process unknown Options from received requests before forwarding
>>>>    them.
>>>>=20
>>>> Rejecting unknown Options and OpCodes has the drawback of =
preventing
>>>> a PCP Client to make use of new capabilities offered by the PCP
>>>> Server but not supported by the PCP Proxy even if no IP address
>>>> and/or port is included in the Option/OpCode.
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>=20
>>>> The reasoning above assumes Options which convey an IP address =
(and/or
>> port
>>>> numbers) are naturally defined as mandatory-to-process option.
>>>>=20
>>>> Reinaldo suggests the following modifications to the behavior =
currently
>>>> defined in the I-D:
>>>>=20
>>>> (1) A PCP Proxy inserts a "this message was proxied" when sending =
back
>> to
>>>> the client. Therefore if PCP client detects that the mappings are =
not
>>>> working as it should, it has a hint as to why.
>>>>=20
>>>> (2) The client conveys that some options in this message carry IP
>> addresses
>>>> and need proxy processing (some IP addresses might not need any =
Proxy
>>>> processing).It does not need to say which options, a bit is fine.
>> Therefore
>>>> a Proxy that could not process those options can send back a =
meaningful
>>>> error such as "message can not be proxied because contains options =
with
>> IP
>>>> address and I do not know how"
>>>>=20
>>>> Any thoughts?
>>>>=20
>>>> Thanks.
>>>> Cheers,
>>>> Med
>>>> _______________________________________________
>>>> 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
>=20


From repenno@cisco.com  Thu May 30 07:43:35 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C043C21F9121 for ; Thu, 30 May 2013 07:43:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.224
X-Spam-Level: 
X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMENq4qQItW8 for ; Thu, 30 May 2013 07:43:25 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1EE21F84E7 for ; Thu, 30 May 2013 07:43:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1820; q=dns/txt; s=iport; t=1369925004; x=1371134604; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6nJJ+HKVmyn39ryocajsdfVjtzPjoMKmnHHXS9AAlj4=; b=VHbV2Oe77SfmaBVZIDnpywV2wlvMztD3m2q8PZend1i3HUVMrzF/hnpm dBkn8n1DrkiLkwuN6qwuSuwoYKfW2nVLh+5CS0MVFgLwQ2lse1JdAhsaA NLq89j2F8x7rfN63sA43YQjUmrZ8/0yBvRO5f0iCJclW3f8SK4xDHqNqs E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAMdkp1GtJXG8/2dsb2JhbABZgwkwwg99FnSCJQEEJ1ISAQgiViUCBA4FCIgFuy2OazEHgnZhA4hoj3+Icoclgw+CJw
X-IronPort-AV: E=Sophos;i="4.87,770,1363132800"; d="scan'208";a="216552718"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 30 May 2013 14:43:23 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4UEhNSZ032706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 May 2013 14:43:23 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 30 May 2013 09:43:22 -0500
From: "Reinaldo Penno (repenno)" 
To: Simon Perreault 
Thread-Topic: [pcp] UNSUPP_FAMILY error code
Thread-Index: AQHOXOkno2rcLHyPsEGQfvT7Mipfj5kd0oAAgAAh6oCAAAMRAIAABUgAgAABvYCAAAZxgIAAAPuAgAACWYCAAAi7AP//0HOAgAAzTID//89OgIAANPSA///PFQAABmGJAP//0NeAgAAz0wD//8/1gA==
Date: Thu, 30 May 2013 14:43:21 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040908D89F@xmb-rcd-x04.cisco.com>
In-Reply-To: <51A763A4.4040300@viagenie.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.86.245.126]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <9C45FC9FAED1874FAF66C5696529062C@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 14:43:35 -0000

On 5/30/13 11:35 AM, "Simon Perreault"  wrote:

>Le 2013-05-30 16:29, Reinaldo Penno (repenno) a =E9crit :
>> Okay, client creates to MAP mappings
>>
>> (1) 2000::1, 10000 -> 100.0.0.2:80
>>
>> (2) 200.0.0.2, 10000 -> 100.0.0.2:80
>
>(assuming left =3D external and right =3D internal)
>
>> Connections are started from the outside (this is a MAP mapping).
>
>Stop right here. A mapping created with MAP also applies to connections
>initiated from the inside. That's precisely why there's a conflict in
>the internal --> external direction.
>
>Above, the arrows should be bidirectional.
>
>> A packet
>> from 2001::1 to 2000::1 will get translated to
>>
>> 10.0.0.2: 3000 (or some other IP address:port depending on translation
>> algorithm) -> 100.0.0.2:80
>>
>> Host at 100:0.0.2:80 will send reply packets to 10.0.0.2:3000 which will
>> be translated to IPv6.
>>
>> Public Internet Ipv4 hosts will send packets to 100.0.0.2:80 and its
>> source will not get translated, replies will be sent to the source
>>address
>> of the packet.
>>
>>
>> Is that what you mean?
>
>No. I'm not talking about reply packets, which could work if the NAT
>tracks sessions. I'm talking about packets not associated with an
>existing session, sent by the internal host to the outside, with
>100.0.0.2:80 as source. Where should those go?

If destination is within the pool controlled by the NAT46, it goes there,
otherwise it goes through NAT44.


>If the NAT doesn't track
>sessions, reply packet sourced from 100.0.0.2:80 are also concerned.
>
>Simon
>--=20
>DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>STUN/TURN server               --> http://numb.viagenie.ca


From simon.perreault@viagenie.ca  Thu May 30 07:47:08 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C28921F8633 for ; Thu, 30 May 2013 07:47:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level: 
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.160,  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 i4h3691x6fL0 for ; Thu, 30 May 2013 07:47:05 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 089F921F8411 for ; Thu, 30 May 2013 07:47:04 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 33BB0403FF; Thu, 30 May 2013 10:47:03 -0400 (EDT)
Message-ID: <51A76666.1050208@viagenie.ca>
Date: Thu, 30 May 2013 16:47:02 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Reinaldo Penno (repenno)" 
References: <45A697A8FFD7CF48BCF2BE7E106F06040908D89F@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040908D89F@xmb-rcd-x04.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 14:47:08 -0000

Le 2013-05-30 16:43, Reinaldo Penno (repenno) a écrit :
>> No. I'm not talking about reply packets, which could work if the NAT
>> tracks sessions. I'm talking about packets not associated with an
>> existing session, sent by the internal host to the outside, with
>> 100.0.0.2:80 as source. Where should those go?
>
> If destination is within the pool controlled by the NAT46, it goes there,
> otherwise it goes through NAT44.

No. This is what I meant by "A mapping being endpoint-independent by PCP 
MAP definition, we can't use the destination to answer that question."

    Note also that all NAT mappings (created by PCP or otherwise) are by
    necessity bidirectional and symmetric.  For any packet going in one
    direction (in or out) that is translated by the NAT, a reply going in
    the opposite direction needs to have the corresponding opposite
    translation done so that the reply arrives at the right endpoint.
    This means that if a client creates a MAP mapping, and then later
    sends an outgoing packet using the mapping's internal address,
    protocol, and port, the NAT should translate that packet's internal
    address and port to the mapping's external address and port, so that
    replies addressed to the external address and port are correctly
    translated back to the mapping's internal address and port.

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 repenno@cisco.com  Thu May 30 07:51:56 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C9E21F859A for ; Thu, 30 May 2013 07:51:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level: 
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 yLsIWjIqVo80 for ; Thu, 30 May 2013 07:51:49 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 73AD221F8C03 for ; Thu, 30 May 2013 07:51:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1763; q=dns/txt; s=iport; t=1369925508; x=1371135108; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6hPfPCj5k4+43ZSUFYQt+r1/z4iZuaNGPSsazzZPRv4=; b=HgH0NDGHGcCa4ml9YaOia2Mom9/V7J/PLFFmeiIzaAqBmNSrd3EwqzW+ JpuAqWz/eiVWaMp37Bw+WRq1KDZ/w1ZJ5ZBCgIzYat3sXbQthC1s8iax9 NVxVrpq7yfxA+H9iwIyptp6hb/0tey43BPtFGQhB/LKkEDOgp4hwat4T+ c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAN1mp1GtJV2b/2dsb2JhbABZgwkwwg99FnSCIwEBAQMBJ1ISAQgiViUCBA4FCId/BrsujmsxB4J2YQOIaI9/iHKHJYMPgic
X-IronPort-AV: E=Sophos;i="4.87,770,1363132800"; d="scan'208";a="216749913"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 30 May 2013 14:51:48 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4UEpldF009047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 May 2013 14:51:47 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Thu, 30 May 2013 09:51:47 -0500
From: "Reinaldo Penno (repenno)" 
To: Simon Perreault 
Thread-Topic: [pcp] UNSUPP_FAMILY error code
Thread-Index: AQHOXOkno2rcLHyPsEGQfvT7Mipfj5kd0oAAgAAh6oCAAAMRAIAABUgAgAABvYCAAAZxgIAAAPuAgAACWYCAAAi7AP//0HOAgAAzTID//89OgIAANPSA///PFQAABmGJAP//0NeAgAAz0wD//8/1gIAAM1UA///PBQA=
Date: Thu, 30 May 2013 14:51:46 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040908D901@xmb-rcd-x04.cisco.com>
In-Reply-To: <51A76666.1050208@viagenie.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.86.245.126]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <7432892449103245A42F0D422055768F@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 14:51:56 -0000

On 5/30/13 11:47 AM, "Simon Perreault"  wrote:

>Le 2013-05-30 16:43, Reinaldo Penno (repenno) a =E9crit :
>>> No. I'm not talking about reply packets, which could work if the NAT
>>> tracks sessions. I'm talking about packets not associated with an
>>> existing session, sent by the internal host to the outside, with
>>> 100.0.0.2:80 as source. Where should those go?
>>
>> If destination is within the pool controlled by the NAT46, it goes
>>there,
>> otherwise it goes through NAT44.
>
>No. This is what I meant by "A mapping being endpoint-independent by PCP
>MAP definition, we can't use the destination to answer that question."


There are two NATs, two mappings. EIM applies to the same NAT.

>
>    Note also that all NAT mappings (created by PCP or otherwise) are by
>    necessity bidirectional and symmetric.  For any packet going in one
>    direction (in or out) that is translated by the NAT, a reply going in
>    the opposite direction needs to have the corresponding opposite
>    translation done so that the reply arrives at the right endpoint.
>    This means that if a client creates a MAP mapping, and then later
>    sends an outgoing packet using the mapping's internal address,
>    protocol, and port, the NAT should translate that packet's internal
>    address and port to the mapping's external address and port, so that
>    replies addressed to the external address and port are correctly
>    translated back to the mapping's internal address and port.
>
>Simon
>--=20
>DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>STUN/TURN server               --> http://numb.viagenie.ca


From mohamed.boucadair@orange.com  Thu May 30 07:57:43 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC2921F8E3C for ; Thu, 30 May 2013 07:57:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.953
X-Spam-Level: 
X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_MILLIONSOF=0.315, 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 7vw13qtXnWwf for ; Thu, 30 May 2013 07:57:38 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E1FFB21F907E for ; Thu, 30 May 2013 07:57:37 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 90A23325677; Thu, 30 May 2013 16:57:36 +0200 (CEST)
Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 7629135C05A; Thu, 30 May 2013 16:57:36 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Thu, 30 May 2013 16:57:36 +0200
From: 
To: Dan Wing 
Date: Thu, 30 May 2013 16:57:34 +0200
Thread-Topic: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
Thread-Index: Ac5dQ2LIR6pVFOxlS7ipsHh+qIRjSwAAWzCw
Message-ID: <94C682931C08B048B7A8645303FDC9F36ED3A084C5@PUEXCB1B.nanterre.francetelecom.fr>
References: <94C682931C08B048B7A8645303FDC9F36EB735607B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36ECFB4A912@PUEXCB1B.nanterre.francetelecom.fr> <1455AEDA-6707-4496-8D19-5367CBCB543D@cisco.com> <94C682931C08B048B7A8645303FDC9F36ED3A0819B@PUEXCB1B.nanterre.francetelecom.fr> <1852EA08-8846-4052-B751-5EFCBCB4C2F4@cisco.com>
In-Reply-To: <1852EA08-8846-4052-B751-5EFCBCB4C2F4@cisco.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.30.143018
Cc: "pcp@ietf.org" 
Subject: Re: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
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, 30 May 2013 14:57:43 -0000

Re-,

Please see inline.
Cheers,
Med

>-----Message d'origine-----
>De=A0: Dan Wing [mailto:dwing@cisco.com]
>Envoy=E9=A0: jeudi 30 mai 2013 16:39
>=C0=A0: BOUCADAIR Mohamed OLNC/OLN
>Cc=A0: pcp@ietf.org
>Objet=A0: Re: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
>
>
>On May 29, 2013, at 11:36 PM, mohamed.boucadair@orange.com wrote:
>
>> Hi Dan,
>>
>>
>>
>>> -----Message d'origine-----
>>> De : Dan Wing [mailto:dwing@cisco.com]
>>> Envoy=E9 : mercredi 29 mai 2013 19:39
>>> =C0 : BOUCADAIR Mohamed OLNC/OLN
>>> Cc : pcp@ietf.org
>>> Objet : Re: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Option=
s
>>>
>>>
>>> On May 22, 2013, at 2:26 AM, mohamed.boucadair@orange.com wrote:
>>>
>>>> Re-,
>>>>
>>>> Many thanks for all of you who provided a feedback for this point. As =
a
>>> conclusion of this discussion, below a proposed change:
>>>>
>>>> OLD:
>>>>
>>>> 7. PCP Proxy Co-located with a NAT Function
>>>>
>>>>  When the PCP Proxy is co-located with a NAT function, it MUST update
>>>>  the content of received requests with the mapped port number and the
>>>>  address belonging to the external interface of the PCP Proxy (i.e.,
>>>>  after the NAT operation) and not as initially positioned by the PCP
>>>>  Client.  For the reverse path, PCP responses MUST be updated by the
>>>>  PCP Proxy to replace the internal port number to what has been
>>>>  initially positioned by the PCP Client.  For this purpose the PCP
>>>>  Proxy MUST have an access to the local NAT state maintained locally.
>>>>  Because PCP messages with an unknown OpCode or Option can carry a
>>>>  hidden internal address or internal port which will not be
>>>>  translated:
>>>>
>>>>  o  a PCP Proxy co-located with a NAT SHOULD reject by an
>>>>     UNSUPP_OPCODE error response a received request with an unknown
>>>>     OpCode;
>>>>
>>>>  o  a PCP Proxy co-located with a NAT SHOULD reject by an
>>>>     UNSUPP_OPTION error response a received request with a mandatory-
>>>>     to-process unknown Option;
>>>>
>>>>  o  a PCP Proxy co-located with a NAT MAY remove any optional-to-
>>>>     process unknown Options from received requests before forwarding
>>>>     them.
>>>>
>>>>  Rejecting unknown Options and OpCodes has the drawback of preventing
>>>>  a PCP Client to make use of new capabilities offered by the PCP
>>>>  Server but not supported by the PCP Proxy even if no IP address
>>>>  and/or port is included in the Option/OpCode.
>>>>
>>>> NEW:
>>>>
>>>> 7.  PCP Proxy Co-located with a NAT Function
>>>>
>>>>  When the PCP Proxy is co-located with a NAT function, it MUST update
>>>>  the content of received requests with the mapped port number and the
>>>>  address belonging to the external interface of the PCP Proxy (i.e.,
>>>>  after the NAT operation) and not as initially conveyed by the PCP
>>>>  Client.  For the reverse path, PCP responses MUST be updated by the
>>>>  PCP Proxy to replace the internal port number to what has been
>>>>  initially positioned by the PCP Client.  For this purpose the PCP
>>>>  Proxy MUST have an access to the local NAT state maintained locally.
>>>>
>>>>  By default, the PCP Proxy MUST relay unknown OpCodes and mandatory-
>>>>  to-process unknown Options.  Rejecting unknown Options and OpCodes
>>>>  has the drawback of preventing a PCP Client to make use of new
>>>>  capabilities offered by the PCP Server but not supported by the PCP
>>>>  Proxy even if no IP address and/or port is included in the Option/
>>>>  OpCode.
>>>>
>>>>  Because PCP messages with an unknown OpCode or mandatory-to-process
>>>>  unknown Options can carry a hidden internal address or internal port
>>>>  which will not be translated, A PCP Proxy MUST be configurable to
>>>>  disable relaying unknown OpCodes and mandatory-to-process unknown
>>>>  Options.
>>>
>>> The text needs to be clearer on the suggested default,
>>
>> [Med] The default and justification are stated in the previous paragraph=
.
>
>I have thought about this some more, and I am concerned not with the
>wording, but that the industry will not be able to update the configuratio=
n
>of the millions of deployed PCP proxies to block a new opcode or a new
>mandatory-to-process option that really does need processing within the PC=
P
>proxy.=20

[Med] This is a configuration parameter which is available at the proxy. Th=
e user can change the config or it can be positioned using any device manag=
ement protocol TR-69 by the provider (think about managed CPE case). For th=
e remaining cases, this is more problematic.


 Additionally, PCP proxy developers will be worried about new
>opcodes which necessitate updating state in the PCP proxy, and will be
>reluctant to follow this part of the (eventual) RFC.

>
>
>How about a different approach:  a proxy, when forwarding a PCP request,
>indicates whenever it does not support an opcode or does not support a
>mandatory-to-process option that it is proxying.  This indication would be
>using a new option we would define in the pcp-proxy document, lets call it
>FORWARDED-WITHOUT-COMPREHENSION.  The final PCP server (which is not
>proxying) already has to understand any new opcode and any new mandatory-
>to-process option (or it will generate an error).  The PCP server, which i=
s
>processing the new opcode or the new mandatory-to-process option must know
>the semantics of that new option (the poor PCP proxy does not), and if the
>semantics need PCP proxy involvement, it returns a new error we define,
>lets call that error NEEDS_PROXY_COMPREHENSION.  This technique has the
>advantage that PCP proxies don't need to be updated to block new opcodes o=
r
>block new mandatory-to-process options.

[Med] This would work too, but I'm sure there will be a demand to have a co=
nfiguration feature which will allow to reveal unsupported opcodes using FO=
RWARDED-WITHOUT-COMPREHENSION. I'm not sure this alternative is better or w=
orse compared to the one depicted in the proposed text.

>
>-d
>
>
>>
>>
>> and why the default
>>> is suggested.  Otherwise we will have proxies implemented that return a=
n
>>> error for unknown opcodes, especially because there are several
>sentences
>>> explaining what MUST be done when returning an error.
>>>
>>>
>>> I am still uncomfortable with how this will work in practice.  We need
>to
>>> think about a new opcode which has embedded ip address and port
>(somewhat
>>> like MAP or PEER) and how that could be successfully deployed with a PC=
P
>>> proxy compliant with this document.
>>>
>>> -d
>>>
>>>
>>>> If the PCP Proxy is configured to disable relaying unknown
>>>>  OpCodes and mandatory-to-process unknown Options, the PCP Proxy MUST
>>>>  behave as follows:
>>>>
>>>>  o  a PCP Proxy co-located with a NAT MUST reject by an UNSUPP_OPCODE
>>>>     error response a received request with an unknown OpCode.
>>>>
>>>>  o  a PCP Proxy co-located with a NAT MUST reject by an UNSUPP_OPTION
>>>>     error response a received request with a mandatory-to-process
>>>>     unknown Option.
>>>>
>>>>
>>>> If there is no objection, this change will be include in the next
>version
>>> of the spec.
>>>>
>>>> Cheers,
>>>> Med
>>>>
>>>>> -----Message d'origine-----
>>>>> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de
>>>>> mohamed.boucadair@orange.com
>>>>> Envoy=E9 : mardi 12 mars 2013 11:44
>>>>> =C0 : pcp@ietf.org
>>>>> Objet : [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
>>>>>
>>>>> Dear all,
>>>>>
>>>>> http://tools.ietf.org/html/draft-ietf-pcp-proxy-02 says:
>>>>>
>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>> Because PCP messages with an unknown OpCode or Option can carry a
>>>>> hidden internal address or internal port which will not be
>>>>> translated:
>>>>>
>>>>> o  a PCP Proxy co-located with a NAT SHOULD reject by an
>>>>>    UNSUPP_OPCODE error response a received request with an unknown
>>>>>    OpCode;
>>>>>
>>>>> o  a PCP Proxy co-located with a NAT SHOULD reject by an
>>>>>    UNSUPP_OPTION error response a received request with a mandatory-
>>>>>    to-process unknown Option;
>>>>>
>>>>> o  a PCP Proxy co-located with a NAT MAY remove any optional-to-
>>>>>    process unknown Options from received requests before forwarding
>>>>>    them.
>>>>>
>>>>> Rejecting unknown Options and OpCodes has the drawback of preventing
>>>>> a PCP Client to make use of new capabilities offered by the PCP
>>>>> Server but not supported by the PCP Proxy even if no IP address
>>>>> and/or port is included in the Option/OpCode.
>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>>
>>>>> The reasoning above assumes Options which convey an IP address (and/o=
r
>>> port
>>>>> numbers) are naturally defined as mandatory-to-process option.
>>>>>
>>>>> Reinaldo suggests the following modifications to the behavior
>currently
>>>>> defined in the I-D:
>>>>>
>>>>> (1) A PCP Proxy inserts a "this message was proxied" when sending bac=
k
>>> to
>>>>> the client. Therefore if PCP client detects that the mappings are not
>>>>> working as it should, it has a hint as to why.
>>>>>
>>>>> (2) The client conveys that some options in this message carry IP
>>> addresses
>>>>> and need proxy processing (some IP addresses might not need any Proxy
>>>>> processing).It does not need to say which options, a bit is fine.
>>> Therefore
>>>>> a Proxy that could not process those options can send back a
>meaningful
>>>>> error such as "message can not be proxied because contains options
>with
>>> IP
>>>>> address and I do not know how"
>>>>>
>>>>> Any thoughts?
>>>>>
>>>>> Thanks.
>>>>> Cheers,
>>>>> Med
>>>>> _______________________________________________
>>>>> 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 simon.perreault@viagenie.ca  Thu May 30 08:05:10 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7559621F8551 for ; Thu, 30 May 2013 08:05:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.153,  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 KGdNkDlGBTZS for ; Thu, 30 May 2013 08:05:09 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 34B7D21F8EBB for ; Thu, 30 May 2013 08:05:07 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A87C84713F; Thu, 30 May 2013 11:05:05 -0400 (EDT)
Message-ID: <51A76AA0.4030803@viagenie.ca>
Date: Thu, 30 May 2013 17:05:04 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Reinaldo Penno (repenno)" 
References: <45A697A8FFD7CF48BCF2BE7E106F06040908D901@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040908D901@xmb-rcd-x04.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Stuart Cheshire , "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 15:05:10 -0000

Le 2013-05-30 16:51, Reinaldo Penno (repenno) a écrit :
>>>> No. I'm not talking about reply packets, which could work if the NAT
>>>> tracks sessions. I'm talking about packets not associated with an
>>>> existing session, sent by the internal host to the outside, with
>>>> 100.0.0.2:80 as source. Where should those go?
>>>
>>> If destination is within the pool controlled by the NAT46, it goes
>>> there,
>>> otherwise it goes through NAT44.
>>
>> No. This is what I meant by "A mapping being endpoint-independent by PCP
>> MAP definition, we can't use the destination to answer that question."
>
> There are two NATs, two mappings. EIM applies to the same NAT.

I'm not too sure what you mean by "two NATs". In our examples so far 
there is a single PCP-controlled device that performs multiple NATxy 
functions. In this particular one, the PCP-controlled device does NAT44 
and NAT46. It MUST NOT simultaneously map the same internal IPv4 port to 
an IPv4 and an IPv6 external ports. Otherwise, the PCP client has no 
idea where its packets will go.

In other words, going back to the numerical example:

(1) 2000::1, 10000 <-> 100.0.0.2:80
(2) 200.0.0.2, 10000 <-> 100.0.0.2:80

Those two mappings, having been handed out by the PCP server to the PCP 
client and therefore needing to obey the PCP protocol definition of what 
a mapping is, impose conflicting requirements on the PCP-controlled device:

(1) Packets sourced from 100.0.0.2:80 MUST be translated to 2000::1, 10000.
(2) Packets sourced from 100.0.0.2:80 MUST be translated to 200.0.0.2, 
10000.

There is no way the PCP-controlled device can simultaneously obey those 
two requirements.

Now, all this doesn't apply if there are two PCP-controlled devices.

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 cheshire@apple.com  Thu May 30 08:43:46 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A154C21F8FF8 for ; Thu, 30 May 2013 08:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PpOnSW1QE2o for ; Thu, 30 May 2013 08:43:40 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id E123721F9509 for ; Thu, 30 May 2013 08:43:38 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MNM00H1XBOCJJ31@mail-out.apple.com> for pcp@ietf.org; Thu, 30 May 2013 08:43:35 -0700 (PDT)
X-AuditID: 11807158-b7f486d0000079b6-d3-51a773a79b89
Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay5.apple.com (Apple SCV relay) with SMTP id DC.1F.31158.7A377A15; Thu, 30 May 2013 08:43:35 -0700 (PDT)
Received: from [17.153.24.140] (unknown [17.153.24.140]) by kencur.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MNM00FPOBONQL50@kencur.apple.com> for pcp@ietf.org; Thu, 30 May 2013 08:43:35 -0700 (PDT)
From: Stuart Cheshire 
In-reply-to: 
Date: Thu, 30 May 2013 08:43:35 -0700
Message-id: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com>
References: 
To: pcp@ietf.org
X-Mailer: Apple Mail (2.1503)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUiON1OTXd58fJAg+U3NC0mH/vN6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujHmzb7EV7BGt+H6pooHxqUAXIweHhICJxKdFJV2MnECmmMSF e+vZuhi5OIQEmpgkXvzfxQ7hzGKS6JhwlhGkillAS2L9zuNMIDavgJ7Etrnb2EBsYQFtibe3 b7GD2GxANS8+XwGLcwrYSpz6eYEZxGYRUJXo/3+BFWKOtsSTdxA2r4CNxPSunywgthCQ3bex DaxXREBA4vfqy0wQ18lKvH7+hmUCI/8sJGfMQnLGLCRjFzAyr2IUKErNSaw01UssKMhJ1UvO z93ECAqvhsKIHYz/l1kdYhTgYFTi4c1IWh4oxJpYVlyZe4hRgoNZSYS3wBkoxJuSWFmVWpQf X1Sak1p8iFGag0VJnNfYZmmgkEB6YklqdmpqQWoRTJaJg1OqgbFh0jUm3tKAiaoXJvfUrBUx 9Oc3bQqzWeu76YnVxiXHOLtn62s1KH4S+hm3ucbU3jHjvWrZhdjZ6a+nXDrQlRMlttX88P/b 9761fpfUl/fhZk1V/a/3ZseajvbLaut2zZfSjHM4c8143ZQPu6as2sF4cUX0ji77ta3WaxRL 9xom1hS+WzNNnUOJpTgj0VCLuag4EQA8fGPbKwIAAA==
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 15:43:46 -0000

On 30 May 2013, at 4:30 AM, mohamed.boucadair@orange.com wrote:

> Unlike MAP4/MAP6, the server receiving a MAP request is not obliged to return an IP address following the indication included in the suggested external IP address field. It will try to best accommodate it, but if not, it would be fine if it returns another AF address; then it is up to the client to make use of it or not. 
> 
> In another words: we should not use Suggested IP Address as PREFER_AF option ;-)

RFC 6887 states that the client uses the appropriate all-zeros address in the Suggested External Address field to control what family of external address it gets:

   When operating a server (see Sections 10.1 and 10.2), the PCP client
   knows if it wants an IPv4 listener, IPv6 listener, or both on the
   Internet.  The PCP client also knows if it has an IPv4 address or
   IPv6 address configured on one of its interfaces.  It takes the union
   of this knowledge to decide to which of its PCP servers to send the
   request (e.g., an IPv4 address or an IPv6 address), and whether to
   send one or two MAP requests for each of its interfaces (e.g., if the
   PCP client has only an IPv4 address but wants both IPv6 and IPv4
   listeners, it sends a MAP request containing the all-zeros IPv6
   address in the Suggested External Address field, and sends a second
   MAP request containing the all-zeros IPv4 address in the Suggested
   External Address field).  If the PCP client has both an IPv4 and IPv6
   address, and only wants an IPv4 listener, it sends one MAP request
   from its IPv4 address (if the PCP server supports NAT44 or IPv4
   firewall) or one MAP request from its IPv6 address (if the PCP server
   supports NAT64).  The PCP client can simply request the desired
   mapping to determine if the PCP server supports the desired mapping.

and

   the application constructs a PCP message with the MAP Opcode, with
   the external address set to the appropriate all-zeros address,
   depending on whether it wants a public IPv4 or IPv6 address.

We really need WG consensus on whether the external address family is a firm requirement or merely a hint, so client writers know what to expect.

I don't see any benefit in requiring client writers to handle the client unexpectedly getting an address family it doesn't want.

That's also a code path that's likely to be poorly tested. I can imagine lots of IPv4-only devices being tested with IPv4-only NATs and shipped today, and then, a couple of years from now, crashing the first time they unexpectedly get handed an IPv6 address.

We'll be shooting ourselves in the foot if we choose that path.

Stuart Cheshire


From cheshire@apple.com  Thu May 30 08:54:24 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA6A21F9602 for ; Thu, 30 May 2013 08:54:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkOtyHurrdAM for ; Thu, 30 May 2013 08:54:13 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 07D1021F968F for ; Thu, 30 May 2013 08:54:12 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MNM00L65C69O6X0@mail-out.apple.com> for pcp@ietf.org; Thu, 30 May 2013 08:54:09 -0700 (PDT)
X-AuditID: 1180715a-b7f506d000007d18-96-51a776215832
Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay6.apple.com (Apple SCV relay) with SMTP id 14.C5.32024.12677A15; Thu, 30 May 2013 08:54:09 -0700 (PDT)
Received: from [17.153.24.140] (unknown [17.153.24.140]) by kencur.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MNM00LDUC69KA30@kencur.apple.com> for pcp@ietf.org; Thu, 30 May 2013 08:54:09 -0700 (PDT)
From: Stuart Cheshire 
In-reply-to: 
Date: Thu, 30 May 2013 08:54:09 -0700
Message-id: <685FEEA2-5F4A-470C-A0EC-9FB14339A296@apple.com>
References: 
To: pcp@ietf.org
X-Mailer: Apple Mail (2.1503)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUiON1OTVexbHmgQdciU4vJx36zOjB6LFny kymAMYrLJiU1J7MstUjfLoErY/eXY4wFy4QrvvdvZW5g3MXfxcjJISFgIrHn0Fk2CFtM4sK9 9UA2F4eQQBOTxPOd21kgnFlMEqe/f2QHqWIW0JJYv/M4E4jNK6AnsW3uNrBuYQFtibe3b4HV sAHVvPh8BSzOKWArcernBWYQm0VAVWL+3TdMEHO0JZ68u8AKMcdG4sCCt4wgthCQ3bexDaxX REBA4vfqy0wQ18lKvH7+hmUCI/8sJGfMQnLGLCRjFzAyr2IUKErNSaw000ssKMhJ1UvOz93E CAqxhsKoHYwNy60OMQpwMCrx8B5IWR4oxJpYVlyZe4hRgoNZSYS3wBkoxJuSWFmVWpQfX1Sa k1p8iFGag0VJnNfEZmmgkEB6YklqdmpqQWoRTJaJg1OqgbH5qnNQ5+T33u8YNmV8Tml63zWB rTzUhDep8ELR38OLG96En4hldnaZo2yqEnhyI9dfsxpzvpCiTu37NrqpYs2GT3In9m+wzKp8 M/H2Ppl5vY3JDS6/A4LO2F1g07L91y/EL/L25fU2Zc5D8oZ1JucKfmxf/oJxSY44Z+eMWzqW 7p8tLFVClViKMxINtZiLihMB0oyjFS0CAAA=
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 15:54:25 -0000

On 30 May 2013, at 7:10 AM, Simon Perreault  wrote:

> Assuming the 44 and 46 mappings have the same internal port... (which I assert is impossible but let's try it anyway)
> 
> There will be a conflict when the internal host sends a packet to the outside from this internal port. Will NAT44 or NAT46 be applied to the mapping? A mapping being endpoint-independent by PCP MAP definition, we can't use the destination to answer that question.

I see your concern here, but I think you're mistaken.

Example configuration:

PCP Client listens on 2620:...:403e port 80
PCP Client issues MAP request for external IPv6;
 gateway creates firewall mapping and returns 2620:...:403e port 80
PCP Client issues MAP request for external IPv4;
 gateway creates NAT mapping and returns 173.164.252.149 port 49152

Now, consider two scenarios:
1. Inbound IPv6 packet arrives from A:B, addressed to 2620:...:403e port 80
   Gateway delivers packet unmodified to internal host
   Internal host replies
   Gateway delivers reply unmodified to remote peer

2. Inbound IPv4 packet arrives from A:B, addressed to 173.164.252.149 port 49152
   NAT64 has to translate IPv4 packet to IPv6
   - IPv6 destination address becomes 2620:...:403e port 80
   - NAT64 has to make up a new source address, e.g. 64:ff9b::...
   Gateway delivers fabricated IPv6 packet to internal host
   Internal host replies
   Gateway recognizes that destination address 64:ff9b::... is a fabricated NAT64 address
   Gateway translates IPv6 packet back to IPv4
   Gateway delivers fabricated IPv4 reply to remote peer

So, a given internal address and port can have two external address families, because the destination address on the outbound packet tells the gateway what handling is required.

Superficially this may seem like it violates the requirement that a NAT gateway have endpoint address independent mappings, but I think in reality there's no such thing as endpoint address *family* independent mappings. We can require a NAT gateway to use the same external IPv4 address regardless of which remote IPv4 peer it is talking to, but there's no way to require it to use a single external address for both remote IPv4 peers and remote IPv6 peers. It simply has to use an external IPv4 address for remote IPv4 peers and an external IPv6 address for remote IPv6 peers.

Stuart Cheshire


From simon.perreault@viagenie.ca  Thu May 30 08:57:25 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B9B21F9401 for ; Thu, 30 May 2013 08:57:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.454
X-Spam-Level: 
X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.146,  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 i9trMCE0SeCt for ; Thu, 30 May 2013 08:57:14 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 03BD621F93A5 for ; Thu, 30 May 2013 08:57:10 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5823C403FF for ; Thu, 30 May 2013 11:57:09 -0400 (EDT)
Message-ID: <51A776D4.8070509@viagenie.ca>
Date: Thu, 30 May 2013 17:57:08 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: pcp@ietf.org
References:  <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com>
In-Reply-To: <17CE9F8C-D9E0-4BD5-88E9-BBD73709C318@apple.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 15:57:25 -0000
X-List-Received-Date: Thu, 30 May 2013 15:57:25 -0000

Le 2013-05-30 17:43, Stuart Cheshire a écrit :
> We really need WG consensus on whether the external address family is a firm requirement or merely a hint, so client writers know what to expect.

+1

> I don't see any benefit in requiring client writers to handle the client unexpectedly getting an address family it doesn't want.

+1

> That's also a code path that's likely to be poorly tested. I can imagine lots of IPv4-only devices being tested with IPv4-only NATs and shipped today, and then, a couple of years from now, crashing the first time they unexpectedly get handed an IPv6 address.
>
> We'll be shooting ourselves in the foot if we choose that path.

+1

FWIW, the server implementation I helped create does not fallback on a 
different address type. To be honest, it never crossed my mind that this 
could be possible.

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 cheshire@apple.com  Thu May 30 09:03:40 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E0F21F8517 for ; Thu, 30 May 2013 09:03:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhT+fCDn1-SQ for ; Thu, 30 May 2013 09:03:33 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 41F7C21F96CE for ; Thu, 30 May 2013 09:02:00 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay7.apple.com ([17.128.113.101]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MNM00HWDCIXJJ31@mail-out.apple.com> for pcp@ietf.org; Thu, 30 May 2013 09:01:45 -0700 (PDT)
X-AuditID: 11807165-b7f496d000000613-76-51a777e949a4
Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay7.apple.com (Apple SCV relay) with SMTP id 95.7A.01555.9E777A15; Thu, 30 May 2013 09:01:45 -0700 (PDT)
Received: from [17.153.24.140] (unknown [17.153.24.140]) by kencur.apple.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MNM00FJACIXQL60@kencur.apple.com> for pcp@ietf.org; Thu, 30 May 2013 09:01:45 -0700 (PDT)
From: Stuart Cheshire 
In-reply-to: <51A75E96.1030303@viagenie.ca>
Date: Thu, 30 May 2013 09:01:45 -0700
Message-id: <471E665B-2F16-4370-BFDD-5A0BDE4A95EC@apple.com>
References: <45A697A8FFD7CF48BCF2BE7E106F060409089D2E@xmb-rcd-x04.cisco.com> <519C7FE0.5020605@viagenie.ca> <92633035-BEE1-419A-B7C9-BBB80D89C785@apple.com> <8D23D4052ABE7A4490E77B1A012B6307751B6EDB@mbx-01.win.nominum.com>  <51A5BF11.5030100@viagenie.ca>  <51A722CC.5030506@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A08385@PUEXCB1B.nanterre.francetelecom.fr> <51A741D2.70503@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083AF@PUEXCB1B.nanterre.francetelecom.fr> <51A747B5.4030506@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083E3@PUEXCB1B.nanterre.francetelecom.fr> <51A74DEF.7090608@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A083F2@PUEXCB1B.nanterre.francetelecom.fr> <51A7573A.3080906@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36ED3A0846F@PUEXCB1B.nanterre.francetelecom.fr> <51A75E96.1030303@viagenie.ca>
To: Simon Perreault 
X-Mailer: Apple Mail (2.1503)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUiON1OTfdl+fJAgw3/zC0mH/vN6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujD3/FzAW3GatuLBcsoHxKEsXIyeHhICJRH9nLxuELSZx4d56 MFtIoIlJYn2nfxcjF5A9i0ni2uRr7CAJZgEdid7v35hBbF4BPYltc7eBNQgLaEu8vX0LrIZN QEvixecrYHFOoPiH+6vBlrEIqEpsu/+CFWKOvcSlU82MELa2xJN3F1ghZtpIdF3czwKx+CS7 xKcLnUBFHBwiAoYSvbehjpaVeP38DcsERoFZSE6aheSkWUjGLmBkXsUoUJSak1hprpdYUJCT qpecn7uJERR2DYWpOxgbl1sdYhTgYFTi4c1IWh4oxJpYVlyZe4hRgoNZSYS3wBkoxJuSWFmV WpQfX1Sak1p8iFGag0VJnNfEZmmgkEB6YklqdmpqQWoRTJaJg1OqgXHnls2rPu4wCK0TF28R jK8pflWyv6Cg9VvkmQtcBY/qTHqOqcesL5yo5XrDyrk0li/m4k0lE1ef9NZld6KkM4vOp4oH xb+ZfVFLZNvlpBzX6CnRkoIT6wOv5Ye6vbD8tlXp9n72cI4V7zbMqYmckj2Z9+3ExPSK7YHB nusfTtCo7g2LOfQ2TomlOCPRUIu5qDgRAIaQklo3AgAA
Cc: "pcp@ietf.org" 
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 16:03:40 -0000

On 30 May 2013, at 7:13 AM, Simon Perreault  wrote:

> If you just replace the useless MAP request with a capability discovery request, you haven't gained anything efficiency-wise but you have increased complexity a lot.

I agree.

In general, the two-step process "Can you do X? Okay then, please do X" can often be collapsed into an atomic one-step "Please do X or give me an error code if not".

And since a robust client needs to handle the two-step scenario where the server says yes to step one and then fails step two, step one becomes redundant and can be skipped, which takes us back to the previously-described atomic one-step operation.

Stuart Cheshire


From simon.perreault@viagenie.ca  Thu May 30 09:26:33 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EBD21F9782 for ; Thu, 30 May 2013 09:26:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.46
X-Spam-Level: 
X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.140,  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 rehJAn4gZCIF for ; Thu, 30 May 2013 09:26:19 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA9921F9774 for ; Thu, 30 May 2013 09:26:09 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6C506403FF; Thu, 30 May 2013 12:25:57 -0400 (EDT)
Message-ID: <51A77D94.9050008@viagenie.ca>
Date: Thu, 30 May 2013 18:25:56 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: Stuart Cheshire 
References:  <685FEEA2-5F4A-470C-A0EC-9FB14339A296@apple.com>
In-Reply-To: <685FEEA2-5F4A-470C-A0EC-9FB14339A296@apple.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: pcp@ietf.org
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 16:26:33 -0000

Le 2013-05-30 17:54, Stuart Cheshire a écrit :
> Example configuration:
>
> PCP Client listens on 2620:...:403e port 80
> PCP Client issues MAP request for external IPv6;
>   gateway creates firewall mapping and returns 2620:...:403e port 80
> PCP Client issues MAP request for external IPv4;
>   gateway creates NAT mapping and returns 173.164.252.149 port 49152
>
> Now, consider two scenarios:
> 1. Inbound IPv6 packet arrives from A:B, addressed to 2620:...:403e port 80
>     Gateway delivers packet unmodified to internal host
>     Internal host replies
>     Gateway delivers reply unmodified to remote peer
>
> 2. Inbound IPv4 packet arrives from A:B, addressed to 173.164.252.149 port 49152
>     NAT64 has to translate IPv4 packet to IPv6
>     - IPv6 destination address becomes 2620:...:403e port 80
>     - NAT64 has to make up a new source address, e.g. 64:ff9b::...
>     Gateway delivers fabricated IPv6 packet to internal host
>     Internal host replies
>     Gateway recognizes that destination address 64:ff9b::... is a fabricated NAT64 address
>     Gateway translates IPv6 packet back to IPv4
>     Gateway delivers fabricated IPv4 reply to remote peer
>
> So, a given internal address and port can have two external address families, because the destination address on the outbound packet tells the gateway what handling is required.

I appreciate you taking the time to craft a detailed example.

That example is very special because it uses the well-known NAT64 
prefix. Using the well-known NAT64 prefix means that we can reasonably 
expect the PCP client to figure out that IPv6 packets it sends to that 
prefix will preferably match the NAT64 mapping, even though they could 
also match the NAT66 mapping.

But we can't rely on the well-known NAT64 prefix being always present to 
disambiguate.

- What would happen if a network-specific NAT64 prefix is used? How can 
the PCP client know what will happen (NAT64 or NAT66) to packets it 
sends if it doesn't know about that prefix?

- What would happen in the NAT44 + NAT46 example we've been discussing? 
There is no well-known prefix to help disambiguate.

Note that I'm not considering only replies to connections initiated from 
the outside. I'm also interested in connections initiated from the 
inside, which MAP also covers.

I see that using PCP to run a dual-stack server is a good use case, but 
MAP doesn't enable it because it is symmetric. To do that we would need 
a kind of mapping that only applies to connections initiated from the 
outside.

> Superficially this may seem like it violates the requirement that a NAT gateway have endpoint address independent mappings, but I think in reality there's no such thing as endpoint address *family* independent mappings. We can require a NAT gateway to use the same external IPv4 address regardless of which remote IPv4 peer it is talking to, but there's no way to require it to use a single external address for both remote IPv4 peers and remote IPv6 peers. It simply has to use an external IPv4 address for remote IPv4 peers and an external IPv6 address for remote IPv6 peers.

I suppose I could be convinced that this is true. But it still doesn't 
change the fact that the client in general has no way of knowing which 
of two matching mappings will apply. That's the problem.

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 cheshire@apple.com  Thu May 30 09:30:51 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47CC21F96A9 for ; Thu, 30 May 2013 09:30:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOtijtAyIrGV for ; Thu, 30 May 2013 09:30:33 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id E62F421F9660 for ; Thu, 30 May 2013 09:30:29 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MNM00CWRDTUUA10@mail-out.apple.com> for pcp@ietf.org; Thu, 30 May 2013 09:30:19 -0700 (PDT)
X-AuditID: 11807166-b7faa6d000003acb-60-51a77e9b845c
Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay8.apple.com (Apple SCV relay) with SMTP id F2.89.15051.B9E77A15; Thu, 30 May 2013 09:30:19 -0700 (PDT)
Received: from [10.0.1.15] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by kencur.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MNM00FQYDUIQL70@kencur.apple.com> for pcp@ietf.org; Thu, 30 May 2013 09:30:19 -0700 (PDT)
From: Stuart Cheshire 
In-reply-to: <51A77D94.9050008@viagenie.ca>
Date: Thu, 30 May 2013 09:30:18 -0700
Message-id: 
References:  <685FEEA2-5F4A-470C-A0EC-9FB14339A296@apple.com> <51A77D94.9050008@viagenie.ca>
To: Simon Perreault 
X-Mailer: Apple Mail (2.1085)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUiON1OTXd23fJAg809AhaTj/1mdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqzZ8QU7OSo+r7rE0sD4iK2LkYNDQsBEYs216C5GTiBTTOLC vfVAYS4OIYEmJomvs7vYIZx9TBK3Dh9nAakSFtCWeHv7FjuIzStgKLHk+hYwm1lAS2L9zuNM IDYbkP3i8xU2EJsTqP7ovddgNouAqkRD+ykmiHoBiZsn+pghbG2JJ+8usELMtJE4dvk71OI+ RolX35awglwqArSs9zYLxKWyEjvvnGaZwCgwC8kZs5CcMQvJ2AWMzKsYBYpScxIrLfQSCwpy UvWS83M3MYLCrqEwbQdj03KrQ4wCHIxKPLwZScsDhVgTy4orcw8xSnAwK4nwFjgDhXhTEiur Uovy44tKc1KLDzFKc7AoifOa2iwNFBJITyxJzU5NLUgtgskycXBKNTCuk68OfbJJXPPN8R8M Cu//3HZ/YSXh/OjQ8dUx2z96HbnIGH2I6Zhnsc7Mj/+3M6yyUTfKWrhxob3N+VKe0+oCdbWN Oi8Y7nDU+Gd8C84Su/Ag9kxts/3Lo5uF9OLTqlYwCfActE7Pi6j73iv6metD1g+jrZvVA8PL 2U/LzswwLZJZkHHe1lOJpTgj0VCLuag4EQAxL0frNwIAAA==
Cc: pcp@ietf.org
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 16:30:54 -0000

On 30 May 2013, at 9:25, Simon Perreault wrote:

> - What would happen if a network-specific NAT64 prefix is used? How can the PCP client know what will happen (NAT64 or NAT66) to packets it sends if it doesn't know about that prefix?
> 
> - What would happen in the NAT44 + NAT46 example we've been discussing? There is no well-known prefix to help disambiguate.
> 
> Note that I'm not considering only replies to connections initiated from the outside. I'm also interested in connections initiated from the inside, which MAP also covers.

I agree that outbound connections (and packets) need to work.

I don't think the client needs to know what will happen. But the gateway does know. If the destination is a "real" address then the packet is sent to that address. If the destination address belongs to the address-family-translating gateway's address pool, then the gateway MUST translate it to the other address family, because the destination is not a "real" address and will go nowhere useful if sent as-is.

Stuart Cheshire


From cheshire@apple.com  Thu May 30 09:34:22 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CCF21F929F for ; Thu, 30 May 2013 09:34:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbuNvkt5T6ep for ; Thu, 30 May 2013 09:34:16 -0700 (PDT)
Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id CE9ED21F8F12 for ; Thu, 30 May 2013 09:34:15 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay7.apple.com ([17.128.113.101]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MNM00JCYE13JLW0@mail-out.apple.com> for pcp@ietf.org; Thu, 30 May 2013 09:34:15 -0700 (PDT)
X-AuditID: 11807165-b7f496d000000613-63-51a77f8756ca
Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay7.apple.com (Apple SCV relay) with SMTP id C1.0A.01555.78F77A15; Thu, 30 May 2013 09:34:15 -0700 (PDT)
Received: from [10.0.1.15] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by koseret.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MNM002C8E127B70@koseret.apple.com> for pcp@ietf.org; Thu, 30 May 2013 09:34:15 -0700 (PDT)
From: Stuart Cheshire 
In-reply-to: <51A5CF4F.9090709@viagenie.ca>
Date: Thu, 30 May 2013 09:34:14 -0700
Message-id: <2B94BBF4-6FE0-4BC7-BC59-D74EC9BBD5D5@apple.com>
References: <45A697A8FFD7CF48BCF2BE7E106F06040908CE78@xmb-rcd-x04.cisco.com> <51A5CF4F.9090709@viagenie.ca>
To: Simon Perreault 
X-Mailer: Apple Mail (2.1085)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUiON1OXbe9fnmgQdNnFYvJx36zOjB6LFny kymAMYrLJiU1J7MstUjfLoEro2nCK7aCD2wVMya3MTUwHmbtYuTkkBAwkbj7bD+ULSZx4d56 ti5GLg4hgRYmic+b1rJAOAeYJP5vW8QCUiUsYCBx8P9uZhCbV8BQYsn1LewgNrOAlsT6nceZ QGw2IPvF5ytsIDangLbEubtXGLsYOThYBFQlVh+WgCgPlpgybwpUq7bEk3cXWCFG2kicvPEO rFVIIFfi+IvbYK0iQKt6b7NA3CkrsfPOaZYJjAKzkBwxC8kRs5BMXcDIvIpRoCg1J7HSXC+x oCAnVS85P3cTIyjsGgpTdzA2Lrc6xCjAwajEw5uRtDxQiDWxrLgy9xCjBAezkghvgTNQiDcl sbIqtSg/vqg0J7X4EKM0B4uSOK+JzdJAIYH0xJLU7NTUgtQimCwTB6dUA6OW0LaWaX6t0/bO SGdb++7K4VdrMttelkctSZ/4RPyO27LQC01HObbwvy3USVheqTkjZ2XR08Wlnpvbgydfrah4 arHY0OX3PLHYeRcWxx1ca98ya1NDdv5btvs1My6Z6X3ljrhiyOe/rb1KoqtH4Wng1OK/17+v FPy8mXvSrMVV8o88TrxT11VSYinOSDTUYi4qTgQAa1YcgjcCAAA=
Cc: "pcp@ietf.org" 
Subject: Re: [pcp] Stability of external 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: Thu, 30 May 2013 16:34:23 -0000

On 29 May 2013, at 2:50, Simon Perreault wrote:

> I was assuming that the DNS update app would create a dummy mapping in order to get and lock the external address. Then the PCP server would send it ANNOUNCEs when things change, would it not?

I was not proposing dummy mappings. The internal host creates *real* mappings for its services, and creates SRV records giving the external ports. The question is whether those SRV records can share a single target hostname, which points to a single target address (which is what Mac OS X currently does).

Requiring the code to potentially generate multiple different target hostnames pointing to different target addresses would add significant complexity (which is why we haven't done that). With NAT-PMP this was not an issue because there was only a single external address.

Stuart Cheshire


From simon.perreault@viagenie.ca  Thu May 30 10:05:38 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79AB21F936E for ; Thu, 30 May 2013 10:05:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.465
X-Spam-Level: 
X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.135,  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 261N9YEtroAW for ; Thu, 30 May 2013 10:05:38 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id EDFBD21F9360 for ; Thu, 30 May 2013 10:05:37 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4DC73403FF; Thu, 30 May 2013 13:05:37 -0400 (EDT)
Message-ID: <51A786E0.2060003@viagenie.ca>
Date: Thu, 30 May 2013 19:05:36 +0200
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
To: Stuart Cheshire 
References:  <685FEEA2-5F4A-470C-A0EC-9FB14339A296@apple.com> <51A77D94.9050008@viagenie.ca> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: pcp@ietf.org
Subject: Re: [pcp] UNSUPP_FAMILY error code
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, 30 May 2013 17:05:38 -0000

Le 2013-05-30 18:30, Stuart Cheshire a écrit :
> On 30 May 2013, at 9:25, Simon Perreault wrote:
>
>> - What would happen if a network-specific NAT64 prefix is used? How can the PCP client know what will happen (NAT64 or NAT66) to packets it sends if it doesn't know about that prefix?
>>
>> - What would happen in the NAT44 + NAT46 example we've been discussing? There is no well-known prefix to help disambiguate.
>>
>> Note that I'm not considering only replies to connections initiated from the outside. I'm also interested in connections initiated from the inside, which MAP also covers.
>
> I agree that outbound connections (and packets) need to work.
>
> I don't think the client needs to know what will happen. But the gateway does know. If the destination is a "real" address then the packet is sent to that address. If the destination address belongs to the address-family-translating gateway's address pool, then the gateway MUST translate it to the other address family, because the destination is not a "real" address and will go nowhere useful if sent as-is.

Hmmm... I started replying to this with a counter-example where the 
client *needs* to know what will happen, but I could not make it work. 
What you're saying seems correct. I need to sleep on this.

Now, the second and somewhat less important reason that mappings cannot 
share the same internal port is that, as the RFC is currently written, 
two matchings do not involve the external address.

a) Servers match requests against existing mappings on the internal 
address + port. This happens before the suggested external address field 
is inspected. Section "11.3. Processing a MAP Request":

    If the internal port, protocol, and internal address match an
    existing static mapping (which will have no nonce), then a PCP reply
    is sent giving the external address and port of that static mapping,
    using the nonce from the PCP request.  The server does not record the
    nonce.

    [...]

    It is possible that a mapping might already exist for a requested
    internal address, protocol, and port.  If so, the PCP server takes
    the following actions:

    [...]

    If no mapping exists for the internal address, protocol, and port,
    and the PCP server is able to create a mapping using the suggested
    external address and port, it SHOULD do so.

b) Clients match responses with requests on the internal address + port. 
Section "11.4. Processing a MAP Response":

    After performing common PCP response processing, the response is
    further matched with a previously sent MAP request by comparing the
    internal IP address (the destination IP address of the PCP response,
    or other IP address specified via the THIRD_PARTY option), the
    protocol, the internal port, and the mapping nonce.  Other fields are
    not compared, because the PCP server sets those fields.

Could these two things be updated in your draft? We would need to say 
basically that the suggested external address family is also part of the 
match tuple in both cases. There would be two consequences to that:

- The client would now be expected to set the suggested external address 
family correctly in refresh requests.

- The server could not reply with an external address family different 
from the one contained in the request.


Thanks all for the frenetic exchange!

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 tireddy@cisco.com  Thu May 30 10:27:23 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE8421F9487 for ; Thu, 30 May 2013 10:27:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.142
X-Spam-Level: 
X-Spam-Status: No, score=-9.142 tagged_above=-999 required=5 tests=[AWL=1.142,  BAYES_00=-2.599, 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 zwIr4r9Gu1Sw for ; Thu, 30 May 2013 10:27:18 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 953A821F92E8 for ; Thu, 30 May 2013 10:27:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10475; q=dns/txt; s=iport; t=1369934838; x=1371144438; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=C/bVfmdDsUPweDcEKh7osUwmL4cAbJGGZF6dSiHFL3Q=; b=aRUZRKartEAgc2mAfU2GbM6v+UdZrRwwqzBDCA8BG1HabE2q0metSbJ+ rkXOj94F1wMh1mLpEEr0IKelg9o6Ag1lnxV7FXTok/46srtfHD23NtxkE GmeXuny9RB/NIZ/xfJVftR6N3h15rkuB3MQbkU/c6v8Z2wTaGr9KMpZqr o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAI+Kp1GtJXG9/2dsb2JhbABZgwkwwhZ+FnSCIwEBAQMBAQEBawsFBwQCAQgRBAEBAQodBycLFAkIAgQBDQUIh38GDLtkjVmBEjEHBoJwYQOIaI9/kBeDD4FoBzg
X-IronPort-AV: E=Sophos;i="4.87,772,1363132800"; d="scan'208";a="216851521"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 30 May 2013 17:27:17 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4UHRH1v020603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 May 2013 17:27:17 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Thu, 30 May 2013 12:27:17 -0500
From: "Tirumaleswar Reddy (tireddy)" 
To: "Dan Wing (dwing)" , "mohamed.boucadair@orange.com" 
Thread-Topic: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
Thread-Index: AQHOXUYU9lilxLsKUEa7NuFiIZdmrZkd5J1A
Date: Thu, 30 May 2013 17:27:16 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A14B777FB@xmb-rcd-x10.cisco.com>
References: <94C682931C08B048B7A8645303FDC9F36EB735607B@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36ECFB4A912@PUEXCB1B.nanterre.francetelecom.fr> <1455AEDA-6707-4496-8D19-5367CBCB543D@cisco.com> <94C682931C08B048B7A8645303FDC9F36ED3A0819B@PUEXCB1B.nanterre.francetelecom.fr> <1852EA08-8846-4052-B751-5EFCBCB4C2F4@cisco.com>
In-Reply-To: <1852EA08-8846-4052-B751-5EFCBCB4C2F4@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.52.96]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "pcp@ietf.org" 
Subject: Re: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
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, 30 May 2013 17:27:23 -0000

> -----Original Message-----
> From: Dan Wing (dwing)
> Sent: Thursday, May 30, 2013 8:09 PM
> To: mohamed.boucadair@orange.com
> Cc: pcp@ietf.org
> Subject: Re: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
>=20
>=20
> On May 29, 2013, at 11:36 PM, mohamed.boucadair@orange.com wrote:
>=20
> > Hi Dan,
> >
> >
> >
> >> -----Message d'origine-----
> >> De : Dan Wing [mailto:dwing@cisco.com]
> >> Envoy=E9 : mercredi 29 mai 2013 19:39
> >> =C0 : BOUCADAIR Mohamed OLNC/OLN
> >> Cc : pcp@ietf.org
> >> Objet : Re: [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Optio=
ns
> >>
> >>
> >> On May 22, 2013, at 2:26 AM, mohamed.boucadair@orange.com wrote:
> >>
> >>> Re-,
> >>>
> >>> Many thanks for all of you who provided a feedback for this point. As=
 a
> >> conclusion of this discussion, below a proposed change:
> >>>
> >>> OLD:
> >>>
> >>> 7. PCP Proxy Co-located with a NAT Function
> >>>
> >>>  When the PCP Proxy is co-located with a NAT function, it MUST update
> >>>  the content of received requests with the mapped port number and the
> >>>  address belonging to the external interface of the PCP Proxy (i.e.,
> >>>  after the NAT operation) and not as initially positioned by the PCP
> >>>  Client.  For the reverse path, PCP responses MUST be updated by the
> >>>  PCP Proxy to replace the internal port number to what has been
> >>>  initially positioned by the PCP Client.  For this purpose the PCP
> >>>  Proxy MUST have an access to the local NAT state maintained locally.
> >>>  Because PCP messages with an unknown OpCode or Option can carry a
> >>>  hidden internal address or internal port which will not be
> >>>  translated:
> >>>
> >>>  o  a PCP Proxy co-located with a NAT SHOULD reject by an
> >>>     UNSUPP_OPCODE error response a received request with an unknown
> >>>     OpCode;
> >>>
> >>>  o  a PCP Proxy co-located with a NAT SHOULD reject by an
> >>>     UNSUPP_OPTION error response a received request with a mandatory-
> >>>     to-process unknown Option;
> >>>
> >>>  o  a PCP Proxy co-located with a NAT MAY remove any optional-to-
> >>>     process unknown Options from received requests before forwarding
> >>>     them.
> >>>
> >>>  Rejecting unknown Options and OpCodes has the drawback of preventing
> >>>  a PCP Client to make use of new capabilities offered by the PCP
> >>>  Server but not supported by the PCP Proxy even if no IP address
> >>>  and/or port is included in the Option/OpCode.
> >>>
> >>> NEW:
> >>>
> >>> 7.  PCP Proxy Co-located with a NAT Function
> >>>
> >>>  When the PCP Proxy is co-located with a NAT function, it MUST update
> >>>  the content of received requests with the mapped port number and the
> >>>  address belonging to the external interface of the PCP Proxy (i.e.,
> >>>  after the NAT operation) and not as initially conveyed by the PCP
> >>>  Client.  For the reverse path, PCP responses MUST be updated by the
> >>>  PCP Proxy to replace the internal port number to what has been
> >>>  initially positioned by the PCP Client.  For this purpose the PCP
> >>>  Proxy MUST have an access to the local NAT state maintained locally.
> >>>
> >>>  By default, the PCP Proxy MUST relay unknown OpCodes and mandatory-
> >>>  to-process unknown Options.  Rejecting unknown Options and OpCodes
> >>>  has the drawback of preventing a PCP Client to make use of new
> >>>  capabilities offered by the PCP Server but not supported by the PCP
> >>>  Proxy even if no IP address and/or port is included in the Option/
> >>>  OpCode.
> >>>
> >>>  Because PCP messages with an unknown OpCode or mandatory-to-process
> >>>  unknown Options can carry a hidden internal address or internal port
> >>>  which will not be translated, A PCP Proxy MUST be configurable to
> >>>  disable relaying unknown OpCodes and mandatory-to-process unknown
> >>>  Options.
> >>
> >> The text needs to be clearer on the suggested default,
> >
> > [Med] The default and justification are stated in the previous paragrap=
h.
>=20
> I have thought about this some more, and I am concerned not with the word=
ing,
> but that the industry will not be able to update the configuration of the
> millions of deployed PCP proxies to block a new opcode or a new mandatory=
-to-
> process option that really does need processing within the PCP proxy.
> Additionally, PCP proxy developers will be worried about new opcodes whic=
h
> necessitate updating state in the PCP proxy, and will be reluctant to fol=
low
> this part of the (eventual) RFC.
>=20
>=20
> How about a different approach:  a proxy, when forwarding a PCP request,
> indicates whenever it does not support an opcode or does not support a
> mandatory-to-process option that it is proxying.  This indication would b=
e
> using a new option we would define in the pcp-proxy document, lets call i=
t
> FORWARDED-WITHOUT-COMPREHENSION. =20

This option FORWARDED-WITHOUT-COMPREHENSION would also have to indicate the=
 new mandatory-to-process options in the PCP request the proxy did not unde=
rstand. For example to handle the scenario where multiple new mandatory-to-=
process options are included, only some of them PCP proxy supports
and some of these options may or may not require PCP proxy processing.


> The final PCP server (which is not proxying)

If there are multiple PCP proxies b/w the PCP client and PCP server. If the=
 upstream PCP proxy receives a PCP request with FORWARDED-WITHOUT-COMPREHEN=
SION but understands all the mandatory-to-process options or the new opcode=
, the behavior of this proxy will also have to be defined.

--Tiru.

> already has to understand any new opcode and any new mandatory-to-process
> option (or it will generate an error).  The PCP server, which is processi=
ng
> the new opcode or the new mandatory-to-process option must know the seman=
tics
> of that new option (the poor PCP proxy does not), and if the semantics ne=
ed
> PCP proxy involvement, it returns a new error we define, lets call that e=
rror
> NEEDS_PROXY_COMPREHENSION. This technique has the advantage that PCP prox=
ies
> don't need to be updated to block new opcodes or block new mandatory-to-
> process options.


>=20
> -d
>=20
>=20
> >
> >
> > and why the default
> >> is suggested.  Otherwise we will have proxies implemented that return =
an
> >> error for unknown opcodes, especially because there are several senten=
ces
> >> explaining what MUST be done when returning an error.
> >>
> >>
> >> I am still uncomfortable with how this will work in practice.  We need=
 to
> >> think about a new opcode which has embedded ip address and port (somew=
hat
> >> like MAP or PEER) and how that could be successfully deployed with a P=
CP
> >> proxy compliant with this document.
> >>
> >> -d
> >>
> >>
> >>> If the PCP Proxy is configured to disable relaying unknown
> >>>  OpCodes and mandatory-to-process unknown Options, the PCP Proxy MUST
> >>>  behave as follows:
> >>>
> >>>  o  a PCP Proxy co-located with a NAT MUST reject by an UNSUPP_OPCODE
> >>>     error response a received request with an unknown OpCode.
> >>>
> >>>  o  a PCP Proxy co-located with a NAT MUST reject by an UNSUPP_OPTION
> >>>     error response a received request with a mandatory-to-process
> >>>     unknown Option.
> >>>
> >>>
> >>> If there is no objection, this change will be include in the next ver=
sion
> >> of the spec.
> >>>
> >>> Cheers,
> >>> Med
> >>>
> >>>> -----Message d'origine-----
> >>>> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part d=
e
> >>>> mohamed.boucadair@orange.com
> >>>> Envoy=E9 : mardi 12 mars 2013 11:44
> >>>> =C0 : pcp@ietf.org
> >>>> Objet : [pcp] draft-ietf-pcp-proxy: Unknown OpCode & Unknown Options
> >>>>
> >>>> Dear all,
> >>>>
> >>>> http://tools.ietf.org/html/draft-ietf-pcp-proxy-02 says:
> >>>>
> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>>> Because PCP messages with an unknown OpCode or Option can carry a
> >>>> hidden internal address or internal port which will not be
> >>>> translated:
> >>>>
> >>>> o  a PCP Proxy co-located with a NAT SHOULD reject by an
> >>>>    UNSUPP_OPCODE error response a received request with an unknown
> >>>>    OpCode;
> >>>>
> >>>> o  a PCP Proxy co-located with a NAT SHOULD reject by an
> >>>>    UNSUPP_OPTION error response a received request with a mandatory-
> >>>>    to-process unknown Option;
> >>>>
> >>>> o  a PCP Proxy co-located with a NAT MAY remove any optional-to-
> >>>>    process unknown Options from received requests before forwarding
> >>>>    them.
> >>>>
> >>>> Rejecting unknown Options and OpCodes has the drawback of preventing
> >>>> a PCP Client to make use of new capabilities offered by the PCP
> >>>> Server but not supported by the PCP Proxy even if no IP address
> >>>> and/or port is included in the Option/OpCode.
> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>>>
> >>>> The reasoning above assumes Options which convey an IP address (and/=
or
> >> port
> >>>> numbers) are naturally defined as mandatory-to-process option.
> >>>>
> >>>> Reinaldo suggests the following modifications to the behavior curren=
tly
> >>>> defined in the I-D:
> >>>>
> >>>> (1) A PCP Proxy inserts a "this message was proxied" when sending ba=
ck
> >> to
> >>>> the client. Therefore if PCP client detects that the mappings are no=
t
> >>>> working as it should, it has a hint as to why.
> >>>>
> >>>> (2) The client conveys that some options in this message carry IP
> >> addresses
> >>>> and need proxy processing (some IP addresses might not need any Prox=
y
> >>>> processing).It does not need to say which options, a bit is fine.
> >> Therefore
> >>>> a Proxy that could not process those options can send back a meaning=
ful
> >>>> error such as "message can not be proxied because contains options w=
ith
> >> IP
> >>>> address and I do not know how"
> >>>>
> >>>> Any thoughts?
> >>>>
> >>>> Thanks.
> >>>> Cheers,
> >>>> Med
> >>>> _______________________________________________
> >>>> 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
> >
>=20


From teemu.savolainen@nokia.com  Fri May 31 05:55:24 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADAD21F9701 for ; Fri, 31 May 2013 05:55:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.741
X-Spam-Level: 
X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_PROFIT1=3.858, 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 JIGndMiC49x2 for ; Fri, 31 May 2013 05:55:19 -0700 (PDT)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 936B421F93DA for ; Fri, 31 May 2013 05:55:19 -0700 (PDT)
Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r4VCtDa1006710; Fri, 31 May 2013 15:55:14 +0300
Received: from vaebh106.NOE.Nokia.com ([10.160.244.32]) by vaebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 31 May 2013 15:55:23 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.48]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 31 May 2013 15:55:23 +0300
Received: from 008-AM1MPN1-053.mgdnok.nokia.com ([169.254.3.166]) by 008-AM1MMR1-014.mgdnok.nokia.com ([2002:4136:1e30::4136:1e30]) with mapi id 14.02.0328.011; Fri, 31 May 2013 12:56:15 +0000
From: 
To: , 
Thread-Topic: My review of draft-ietf-pcp-nat64-prefix64-02
Thread-Index: Ac5dHuevWC0dHYarTvOOt4eFkySJdgAE4xHAADJ54/A=
Date: Fri, 31 May 2013 12:56:15 +0000
Message-ID: <916CE6CF87173740BC8A2CE44309696204727C80@008-AM1MPN1-053.mgdnok.nokia.com>
References: <916CE6CF87173740BC8A2CE44309696204718CB6@008-AM1MPN1-051.mgdnok.nokia.com> <94C682931C08B048B7A8645303FDC9F36ED3A083DC@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED3A083DC@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.163.25.100]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 31 May 2013 12:55:23.0253 (UTC) FILETIME=[1D278A50:01CE5DFE]
X-Nokia-AV: Clean
Subject: Re: [pcp] My review of draft-ietf-pcp-nat64-prefix64-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: Fri, 31 May 2013 12:55:24 -0000

Hi Med,=20

Thanks for quick reply.

> [Med] I added this text:=20
>   A more elaborated discussion can be found at
>  [I-D.ietf-behave-nat64-learn-analysis].  A solution which solves some
>   of these issues is specified in
>   [I-D.ietf-behave-nat64-discovery-heuristic].

I guess that is enough. Some discussion around might be nice (e.g. comparis=
on, additional thoughts for why PCP option was standardized and why heurist=
ic was not enough), but I'm not sure it is actually required.

> [Med] I added this text to Section 3.2:
>   This section provides some use cases to illustrate the problem space.
 >  More details can be found at Section 4 of
 >  [I-D.ietf-behave-nat64-learn-analysis].

Ok.

>>Now that you have explicit tool for provisioning Pref64::/n, why do you=20
>>not provision also the suffix introduced in RFC6052? Wouldn't that make=20
>>this more future proof? The format shown in 4.1 could have variable=20
>>length suffix field. In fact, having suffix included would allow *fixed=20
>>length*
>>128 bit field-length, which might be optimized to be 96 bit field=20
>>(128-32, with first bits for prefix and remaining for suffix - dropping=20
>>bits for IPv4).
>[Med] I'm not sure there is a value to configure the suffix. The implement=
ation I'm aware does not allow to configure other suffixes. My personal opi=
nion is we should not include it in the option format.

AFAIK the suffix is defined in RFC6052 for some possible future uses (there=
's some discuss in RFC6052 section 4.1). If the PCP option would support de=
livery of the suffix information (esp. if suffix were to be a static value =
per deliver Pref64::/n and not e.g. facility for providing checksum neutral=
ity), it might be more future proof if some use for suffix is actually take=
n into use some day.

However, if the decision is not to deliver suffix, it could be worthwhile t=
o have couple of word saying that in the generation of synthetic IPv6 addre=
sses, suffix of zero MUST be used and that if in the future the suffix is t=
aken into use in protocol translation system, and the host can be involved =
in setting the suffix in sensible manner, a new PCP option may be needed.

> [Med] I guess you are referring to what we had in http://tools.ietf.org/h=
tml/draft-boucadair-pcp-nat64-prefix64-option-02#page-6. The support of thi=
s >case will complicates the design option for a corner case. I added this =
sentence:
>   This option does not solve the destination-dependent Pref64::/n
 >  discovery problem discussed in Section 5.1 of
 >  [I-D.ietf-behave-nat64-discovery-heuristic].

Oh I had missed that draft revision text:) Sure, it would complicate. Howev=
er, this consideration was really wanted to be included in the heuristic-dr=
aft, and hence I think it should be included in this document as well.=20

Best regards,

	Teemu

From ssenthil@cisco.com  Fri May 31 11:30:24 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A49C21F8EF2 for ; Fri, 31 May 2013 11:30:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtYFAnya1dHj for ; Fri, 31 May 2013 11:30:19 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DB18A21F84F9 for ; Fri, 31 May 2013 11:30:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=280; q=dns/txt; s=iport; t=1370025019; x=1371234619; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=m2Zt/A3ROJP/Rf7NPXELWddJSTfpB53FZpNZaCsWK7I=; b=K4+KSBesR7dQx0AOEYx50qh/kchsPZpR+mkinNufgPHXv5iWStNKCvlv 6Rp4B0l3BYiMdVZDY1oiQaoKgLnAoYtlwPT+juEqRG/Irxo4fsZ+B9mO2 SUUX65sJnsRy5mqjMGhW4+yTO0D7/rretwIANGzlf+WElb+FsFAD97BUL 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhsGANLrqFGtJV2b/2dsb2JhbABagwm/HoEDFm0HgiUBBHkSASpWJQIEDg2IBboLjnAxB4J2YQOIaKAWgw+CJw
X-IronPort-AV: E=Sophos;i="4.87,780,1363132800"; d="scan'208";a="217336356"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 31 May 2013 18:30:18 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4VIUI5A024425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 May 2013 18:30:18 GMT
Received: from xmb-rcd-x15.cisco.com ([169.254.5.94]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Fri, 31 May 2013 13:30:17 -0500
From: "Senthil Sivakumar (ssenthil)" 
To: "mohamed.boucadair@orange.com" 
Thread-Topic: Review of draft-ietf-pcp-nat64-prefix64-02
Thread-Index: AQHOXizllAGNv6BFaUShlQ5KKEfYCg==
Date: Fri, 31 May 2013 18:30:16 +0000
Message-ID: 
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36ED3A083DC@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.4.130416
x-originating-ip: [10.117.198.134]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "pcp@ietf.org" 
Subject: [pcp] Review of draft-ietf-pcp-nat64-prefix64-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: Fri, 31 May 2013 18:30:24 -0000

Overall, this is a well-written draft and is ready for progressing.
The only comment I have is this document doesn=B9t address the multiple
prefixes that could be present on a NAT64 device.
Any guidelines on which prefix should be reported would be useful.

Thanks
Senthil


From trac@tools.ietf.org  Fri May 31 15:55:16 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA0221F888F for ; Fri, 31 May 2013 15:54:19 -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 Fa4RVk5Zd-qW for ; Fri, 31 May 2013 15:54:18 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F396921F881F for ; Fri, 31 May 2013 15:54:13 -0700 (PDT)
Received: from localhost ([127.0.0.1]:43014 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UiYD3-0007UC-Fe; Sat, 01 Jun 2013 00:54:09 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "pcp issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-pcp-nat64-prefix64@tools.ietf.org, ssenthil@cisco.com
X-Trac-Project: pcp
Date: Fri, 31 May 2013 22:54:09 -0000
X-URL: http://tools.ietf.org/pcp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/63
Message-ID: <087.ac7253502d63a2734c727a805a0fb5f7@tools.ietf.org>
X-Trac-Ticket-ID: 63
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-pcp-nat64-prefix64@tools.ietf.org, ssenthil@cisco.com, pcp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: mohamed.boucadair@orange.com
Resent-Message-Id: <20130531225417.F396921F881F@ietfa.amsl.com>
Resent-Date: Fri, 31 May 2013 15:54:13 -0700 (PDT)
Resent-From: trac@tools.ietf.org
Cc: pcp@ietf.org
Subject: [pcp]  #63: Handling multiple prefixes
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: Fri, 31 May 2013 22:55:17 -0000

#63: Handling multiple prefixes

 The only comment I have is this document doesn't address the multiple
 prefixes that could be present on a NAT64 device.
 Any guidelines on which prefix should be reported would be useful.

-- 
-------------------------------------+-------------------------------------
 Reporter:  Senthil Sivakumar        |      Owner:  draft-ietf-pcp-
  (ssenthil)     |  nat64-prefix64@tools.ietf.org
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  nat64-prefix64           |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: 
pcp 


From trac@tools.ietf.org  Fri May 31 16:19:43 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4802B21F88D8 for ; Fri, 31 May 2013 16:19:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.706
X-Spam-Level: 
X-Spam-Status: No, score=-99.706 tagged_above=-999 required=5 tests=[AWL=-0.964, BAYES_00=-2.599, FRT_PROFIT1=3.858, 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 3roF+LOIoNZT for ; Fri, 31 May 2013 16:19:37 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 183B721F848E for ; Fri, 31 May 2013 16:07:53 -0700 (PDT)
Received: from localhost ([127.0.0.1]:44457 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UiYPg-0001gZ-2I; Sat, 01 Jun 2013 01:07:12 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "pcp issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-pcp-nat64-prefix64@tools.ietf.org, teemu.savolainen@nokia.com
X-Trac-Project: pcp
Date: Fri, 31 May 2013 23:07:12 -0000
X-URL: http://tools.ietf.org/pcp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/64
Message-ID: <064.8793b93d389eea6b51bc55b5712fe096@tools.ietf.org>
X-Trac-Ticket-ID: 64
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-pcp-nat64-prefix64@tools.ietf.org, teemu.savolainen@nokia.com, pcp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: mohamed.boucadair@orange.com
Resent-Message-Id: <20130531230756.183B721F848E@ietfa.amsl.com>
Resent-Date: Fri, 31 May 2013 16:07:53 -0700 (PDT)
Resent-From: trac@tools.ietf.org
Cc: pcp@ietf.org
Subject: [pcp]  #64: Teemu's comments on draft-ietf-pcp-nat64-prefix64-02
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: Fri, 31 May 2013 23:19:43 -0000

#64: Teemu's comments on draft-ietf-pcp-nat64-prefix64-02

 I read through most of the draft. I am not that expert in PCP so my focus
 is on discovery in general.

 The Introduction has a justification text:"This extension is required to
 help establishing communications  between IPv6-only hosts and remote
 IPv4-only hosts.", which is not exactly correct, as we already have one
 solution for that problem: draft-ietf-behave-nat64-discovery-heuristic.

 The IESG approval email for heuristic-draft had text:
 -
 Working Group Summary

     The document specifies a heuristic that is not perfect and so some
     points were rough, but the constraint for this document was to operate
     without changes to code (only configuration) in existing networks.
     Given that constraint, there was strong consensus.  Relaxing the
     constraint would allow one to do better, and that is the focus of a
     draft recently submitted to the PCP WG.
 -
 Furthermore, draft-ietf-behave-nat64-learn-analysis-03.txt (RFC Editor's
 queue, now cleared due resolution of MISSREF) analyses various solutions
 that we had on the table at March 2012. In particular the learn-analysis
 talks about application layer protocols (such as STUN) in section 5.8, but
 also lists Issues (from #1 to #5). I think this PCP solution solves the
 issues, BUT with additional box on the network (PCP).

 All in all, I think this document should reference to heuristic as
 existing solution and learn-analysis as discussion paper of the problem,
 and say that PCP solution solves the Issues (please double check that it
 does), but also adds the benefits that come with explicit provisioning
 tool - but with a cost of requiring said provisioning tool (PCP).

 Actually, the reference to analysis document could be at section 3.1 that
 lists the Issues listed in learn-analysis this PCP solution solves (and
 what more is solved). The "stale Pref64::/n" is the same as Issue #4 in
 learn analysis?

 The 3.2 could reference to learn-analysis section 4 as well, as I think
 there is overlap?

 Now that you have explicit tool for provisioning Pref64::/n, why do you
 not provision also the suffix introduced in RFC6052? Wouldn't that make
 this more future proof? The format shown in 4.1 could have variable length
 suffix field. In fact, having suffix included would allow *fixed length*
 128 bit field-length, which might be optimized to be 96 bit field (128-32,
 with first bits for prefix and remaining for suffix - dropping bits for
 IPv4).

 It seems this solution does not solve the destination-dependent Pref64::/n
 "problem" discussed in heuristic-discovery section "5.1.  Mapping of IPv4
 Address Ranges to IPv6 Prefixes" ? If so, it should be mentioned that this
 is not solved/supported.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-pcp-
  teemu.savolainen@nokia.com         |  nat64-prefix64@tools.ietf.org
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  nat64-prefix64           |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: 
pcp 


From dthaler@microsoft.com  Fri May 31 17:34:22 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492FD21F8605 for ; Fri, 31 May 2013 17:34:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.466
X-Spam-Level: 
X-Spam-Status: No, score=-97.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8Zn9Y6KWj+M for ; Fri, 31 May 2013 17:34:15 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 4F37321F854E for ; Fri, 31 May 2013 17:34:15 -0700 (PDT)
Received: from BY2FFO11FD018.protection.gbl (10.1.15.204) by BY2FFO11HUB024.protection.gbl (10.1.14.138) with Microsoft SMTP Server (TLS) id 15.0.707.0; Sat, 1 Jun 2013 00:34:13 +0000
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD018.mail.protection.outlook.com (10.1.14.106) with Microsoft SMTP Server (TLS) id 15.0.698.0 via Frontend Transport; Sat, 1 Jun 2013 00:34:12 +0000
Received: from tx2outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.3.136.1; Sat, 1 Jun 2013 00:34:10 +0000
Received: from mail52-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Sat, 1 Jun 2013 00:34:09 +0000
Received: from mail52-tx2 (localhost [127.0.0.1])	by mail52-tx2-R.bigfish.com (Postfix) with ESMTP id AB5003400F8	for ; Sat,  1 Jun 2013 00:34:09 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -4
X-BigFish: PS-4(zzc85fhzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz17326ah186M18c673h5eeeK8275bh8275dhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh17ej9a9j1155h)
Received-SPF: softfail (mail52-tx2: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=dthaler@microsoft.com; helo=BL2PRD0310HT002.namprd03.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BN1PR03MB268; H:BN1PR03MB267.namprd03.prod.outlook.com; LANG:en; 
Received: from mail52-tx2 (localhost.localdomain [127.0.0.1]) by mail52-tx2 (MessageSwitch) id 1370046847959851_9212; Sat,  1 Jun 2013 00:34:07 +0000 (UTC)
Received: from TX2EHSMHS008.bigfish.com (unknown [10.9.14.250])	by mail52-tx2.bigfish.com (Postfix) with ESMTP id E4DF824006A; Sat,  1 Jun 2013 00:34:07 +0000 (UTC)
Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by TX2EHSMHS008.bigfish.com (10.9.99.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 1 Jun 2013 00:34:07 +0000
Received: from BN1PR03MB268.namprd03.prod.outlook.com (10.255.200.20) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.311.1; Sat, 1 Jun 2013 00:34:06 +0000
Received: from BN1PR03MB267.namprd03.prod.outlook.com (10.255.200.17) by BN1PR03MB268.namprd03.prod.outlook.com (10.255.200.20) with Microsoft SMTP Server (TLS) id 15.0.698.13; Sat, 1 Jun 2013 00:34:05 +0000
Received: from BN1PR03MB267.namprd03.prod.outlook.com ([169.254.15.233]) by BN1PR03MB267.namprd03.prod.outlook.com ([169.254.15.233]) with mapi id 15.00.0698.010; Sat, 1 Jun 2013 00:34:04 +0000
From: Dave Thaler 
To: "draft-ietf-pcp-nat64-prefix64@tools.ietf.org" 
Thread-Topic: Comments on  draft-ietf-pcp-nat64-prefix64-02
Thread-Index: Ac5eXnzFuvsf6bqRT0e9D2Vte/Z4hA==
Date: Sat, 1 Jun 2013 00:34:04 +0000
Message-ID: <4ca214b2e2264f409935b918f6b71ab2@BN1PR03MB267.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:1a:3:9cea:481:7406:5371]
Content-Type: multipart/alternative; boundary="_000_4ca214b2e2264f409935b918f6b71ab2BN1PR03MB267namprd03pro_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BN1PR03MB268.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(243025003)(189002)(199002)(59766001)(16236675002)(53806001)(56776001)(71186001)(54316002)(51856001)(76786001)(74502001)(69226001)(79102001)(33646001)(46102001)(76482001)(74706001)(74366001)(512954002)(20776003)(47446002)(77982001)(56816002)(76176001)(63696002)(16676001)(6806003)(81542001)(65816001)(15202345002)(81342001)(47976001)(50986001)(47736001)(31966008)(4396001)(74876001)(49866001)(74316001)(74662001)(44976003)(80022001)(76796001)(76576001)(54356001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB024; H:TK5EX14HUBC102.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0864A36BBF
Cc: "pcp@ietf.org" 
Subject: [pcp] Comments on  draft-ietf-pcp-nat64-prefix64-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: Sat, 01 Jun 2013 00:34:22 -0000

--_000_4ca214b2e2264f409935b918f6b71ab2BN1PR03MB267namprd03pro_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Looks pretty good.  My marked up copy is at
http://research.microsoft.com/~dthaler/draft-ietf-pcp-nat64-prefix64-02.pdf
(or for those who can use .docx:
http://research.microsoft.com/~dthaler/draft-ietf-pcp-nat64-prefix64-02.doc=
x).

Summary:

1)      Text appears contradictory as to whether remembering which server a=
 Pref64

was from is required or just a SHOULD. My preference is to change the SHOUL=
D

to a MUST, and then the rest of the text is fine.

2)      Add reference to draft-ietf-behave-nat64-discovery-heuristic and ex=
plain what

cases this handles that the simple heuristic cannot.

3)      Steal a few phrases from draft-ietf-behave-nat64-discovery-heuristi=
c that are

applicable here too.

4)      Various grammatical corrections/suggestions.


-Dave

--_000_4ca214b2e2264f409935b918f6b71ab2BN1PR03MB267namprd03pro_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Looks pretty good.  My marked up copy is at


http://research.microsoft.com/~dthaler/=
draft-ietf-pcp-nat64-prefix64-02.pdf


(or for those who can use .docx:


http://research.microsoft.com/~dthaler=
/draft-ietf-pcp-nat64-prefix64-02.docx).



 


Summary:


1)     
Text appears contradictory as to whether rememberin=
g which server a Pref64


was from is required or just a SHOULD. My pre=
ference is to change the SHOULD


to a MUST, and then the rest of the text is f=
ine.


2)     
Add reference to draft-ietf-behave-nat64-discovery-=
heuristic and explain what


cases this handles that the simple heuristic =
cannot.


3)     
Steal a few phrases from draft-ietf-behave-nat64-di=
scovery-heuristic that are


applicable here too.


4)     
Various grammatical corrections/suggestions.


 


-Dave






--_000_4ca214b2e2264f409935b918f6b71ab2BN1PR03MB267namprd03pro_--

From trac@tools.ietf.org  Fri May 31 17:35:32 2013
Return-Path: 
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8CA21F8AD5 for ; Fri, 31 May 2013 17:35:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.313
X-Spam-Level: 
X-Spam-Status: No, score=-101.313 tagged_above=-999 required=5 tests=[AWL=1.286, 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 ynWTxK1ZcRCt for ; Fri, 31 May 2013 17:35:31 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEC021F86F0 for ; Fri, 31 May 2013 17:35:30 -0700 (PDT)
Received: from localhost ([127.0.0.1]:49434 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UiZn5-0002fZ-Uy; Sat, 01 Jun 2013 02:35:27 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "pcp issue tracker" 
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-pcp-nat64-prefix64@tools.ietf.org, dthaler@microsoft.com
X-Trac-Project: pcp
Date: Sat, 01 Jun 2013 00:35:27 -0000
X-URL: http://tools.ietf.org/pcp/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/65
Message-ID: <059.b0df0ae726efb01039302bce1946c177@tools.ietf.org>
X-Trac-Ticket-ID: 65
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-pcp-nat64-prefix64@tools.ietf.org, dthaler@microsoft.com, pcp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: mohamed.boucadair@orange.com
Resent-Message-Id: <20130601003531.3FEC021F86F0@ietfa.amsl.com>
Resent-Date: Fri, 31 May 2013 17:35:30 -0700 (PDT)
Resent-From: trac@tools.ietf.org
Cc: pcp@ietf.org
Subject: [pcp] #65: Dave Thaler's comments on draft-ietf-pcp-nat64-prefix64-02
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: Sat, 01 Jun 2013 00:35:32 -0000

#65: Dave Thaler's comments on draft-ietf-pcp-nat64-prefix64-02

 Looks pretty good.  My marked up copy is at
 http://research.microsoft.com/~dthaler/draft-ietf-pcp-
 nat64-prefix64-02.pdf
 (or for those who can use .docx:
 http://research.microsoft.com/~dthaler/draft-ietf-pcp-
 nat64-prefix64-02.docx).

 Summary:
 1)      Text appears contradictory as to whether remembering which server
 a Pref64 was from is required or just a SHOULD. My preference is to change
 the SHOULD to a MUST, and then the rest of the text is fine.
 2)      Add reference to draft-ietf-behave-nat64-discovery-heuristic and
 explain what cases this handles that the simple heuristic cannot.
 3)      Steal a few phrases from draft-ietf-behave-nat64-discovery-
 heuristic that are applicable here too.
 4)      Various grammatical corrections/suggestions.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-pcp-
  dthaler@microsoft.com  |  nat64-prefix64@tools.ietf.org
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:               |    Version:
  nat64-prefix64         |   Keywords:
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: 
pcp