From repenno@cisco.com Sat Dec 1 06:49:35 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D10C11E809A for ; Sat, 1 Dec 2012 06:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_54=1, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtWnQJmi+nHa for ; Sat, 1 Dec 2012 06:49:34 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C611F11E8097 for ; Sat, 1 Dec 2012 06:49:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2594; q=dns/txt; s=iport; t=1354373375; x=1355582975; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=hsHMsv3oKqCy3SYXxH1/y6ms4wO3NehLfLnAbJ3XaAA=; b=f8iZrZd18hg6XTSCzHCIDGzIdzqP9eh55GgESCDQVNZWM8askP4u4NQK //AkooAfmjJ1AfLp4nZcvGv5712Du5+LBhkSj9v81LShOJtND/wz+RCk9 YqUD9YcIHRQUDbPdSfUccmg9Mold6eQIPKvLlyX8quQ5PhsX0dPNEtCzl g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANAXulCtJV2c/2dsb2JhbABEwAYWc4IgAQQBAQEkRx0BCCJLCyUCBAESCIgIDL5JjF2DQ2EDlx2PK4JygWQ9 X-IronPort-AV: E=McAfee;i="5400,1158,6912"; a="148298107" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 01 Dec 2012 14:49:34 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qB1EnYCJ025004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 1 Dec 2012 14:49:34 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.203]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Sat, 1 Dec 2012 08:49:34 -0600 From: "Reinaldo Penno (repenno)" To: Simon Perreault , "pcp@ietf.org" Thread-Topic: [pcp] Comments on draft-tsou-pcp-natcoord-08 Thread-Index: AQHNzW7tUdQudtqM2EefCyX9WZI71pgCnQWAgAGxUYA= Date: Sat, 1 Dec 2012 14:49:33 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604186368@xmb-rcd-x04.cisco.com> In-Reply-To: <50B8915F.9090108@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.74.241] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] Comments on draft-tsou-pcp-natcoord-08 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 Dec 2012 14:49:35 -0000 On 11/30/12 8:58 AM, "Simon Perreault" wrote: >Hi Reinaldo, > >Le 2012-11-28 14:47, Reinaldo Penno (repenno) a =E9crit : >> In both 2 and 3 NAT could be performed by PCP controlled device. There >>is >> no discussion of this aspect (maybe due to Lw4o6 drivers) but if the >> mechanism is to be generic, we need to define how it would work. As I >> think about it , it seems there are quite a few issues to be ironed out. > >As mentioned in the presentation, there are ONLY TWO differences between >MAP and MAP_PORT_SET: > >- MAP maps a single port, MAP_PORT_SET maps a set of ports. (Obviously!) > >- MAP_PORT_SET has the limitation that NAT is optionally applied to the >address (as for MAP), but *never* applied to ports. > >If someone can find a way to make MAP_PORT_SET work with NAT applied to >ports, please do suggest it. A few comments here: 1 - MAP_PORT_SET delegates ports as opposed to installing a translation port mapping. This is almost a firewall application and would be good if it could be applied in that case as well. IN other words, allow a application to open bulk ports in firewalls. 2 - A important distinction of MAP and MAP_PORT_SET is that MAP nails down a single mapping port out of many that can continue to be used for NAPT44/NAT64, etc. I believe this should still be possible. In other words, create a 1:1 bulk mapping as I suggest below while leaving other ports within the subscriber quota for regular NAT. 3 - Suggestion on MAP_PORT_SET applied to ports Client sends a MAP_PORT_SET indicating its internal available range, say, 1024-2047 (1024 ports). The CPE certainly knows the internal range it has available, there is no ambiguity here. Server, allocates external ports 32000-32511 ports. Those 512 ports would be mapped 1:1 into the internal ports beginning with the first one. So, 32000<->1024 32001<->1025 =8A 32511<->2047 4 - NAT could still be done for outbound 1:1 if host performs source port control. So in this case MAP_PORT_SET could be used for NAPT in a SLNAT44 fashion as we discussed when CPE is in bridge mode. Let me know your thoughts. Thanks, Reinaldo =20 > >Agreed? > >Thanks, >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 bingxuere@gmail.com Sun Dec 2 05:45:11 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FC021F8964 for ; Sun, 2 Dec 2012 05:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[AWL=-0.688, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_54=1, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02zhk3uOcAoC for ; Sun, 2 Dec 2012 05:45:07 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1226121F875F for ; Sun, 2 Dec 2012 05:45:07 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so1661720iaz.31 for ; Sun, 02 Dec 2012 05:45:06 -0800 (PST) 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=RZvuC9mOHrwkjbP6w6RrYXcyqSXsG1e15Bvyxchtw7g=; b=EyQBs0pmuvDLmkMxzo9MzHDqRHZbCt+jSvuxkODxzumpZURdlEpGaop+HnjZDZzoaQ vvs5BbnZvCYBcX/BYgUS6Z4qkbnUKdRKh0cx4dtPjPQHe2dOs/KHRXnRjVqpZfs9qVNh zbjQn9gd6vYpXasRo2y47UdFUF5jNaGECkLvOfSQgZVtQXcfP9J1Vz0jQ/xcff/wQsdN 2tuTWHauhLGwTiGt7NBx5xyZeB0s2axJ8HfaRyCCUDyF2vYDZt4QQHbY77HJY/DVcxah WVVOMdznvyfcxvmCKgzpclE94hT6+e3mIgw684Dvt5673jAbEppWAj+3PL14thdryL6S lCHg== Received: by 10.42.118.13 with SMTP id v13mr5429684icq.44.1354455906536; Sun, 02 Dec 2012 05:45:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.76.200 with HTTP; Sun, 2 Dec 2012 05:44:26 -0800 (PST) In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604186368@xmb-rcd-x04.cisco.com> References: <50B8915F.9090108@viagenie.ca> <45A697A8FFD7CF48BCF2BE7E106F0604186368@xmb-rcd-x04.cisco.com> From: Qiong Date: Sun, 2 Dec 2012 21:44:26 +0800 Message-ID: To: "Reinaldo Penno (repenno)" Content-Type: multipart/alternative; boundary=20cf30223e412c4d3204cfded7bd Cc: "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-tsou-pcp-natcoord-08 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, 02 Dec 2012 13:45:12 -0000 --20cf30223e412c4d3204cfded7bd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Reinaldo, Thanks for your explaination. Below is my consideration. On Sat, Dec 1, 2012 at 10:49 PM, Reinaldo Penno (repenno) wrote: > On 11/30/12 8:58 AM, "Simon Perreault" > wrote: > > > A few comments here: > > 1 - MAP_PORT_SET delegates ports as opposed to installing a translation > port mapping. This is almost a firewall application and would be good if > it could be applied in that case as well. IN other words, allow a > application to open bulk ports in firewalls. > [Qiong] I think this is fine:) > > 2 - A important distinction of MAP and MAP_PORT_SET is that MAP nails dow= n > a single mapping port out of many that can continue to be used for > NAPT44/NAT64, etc. I believe this should still be possible. In other > words, create a 1:1 bulk mapping as I suggest below while leaving other > ports within the subscriber quota for regular NAT. > [Qiong] I'm still a little confusing about this 1:1 bulk mapping.In 1:1 port mapping, if the CPE will not do NAPT, but just the CGN(PCP server) will do the port mapping. Then, why does this CPE request MAP_PORT_SET? Only to inform the PCP server with its internal port range ? I think in most cases, the internal port range is a full range (0~65535), right ? Best wishes Qiong > > 3 - Suggestion on MAP_PORT_SET applied to ports > > Client sends a MAP_PORT_SET indicating its internal available range, say, > 1024-2047 (1024 ports). The CPE certainly knows the internal range it has > available, there is no ambiguity here. > > Server, allocates external ports 32000-32511 ports. Those 512 ports would > be mapped 1:1 into the internal ports beginning with the first one. > > So, > > 32000<->1024 > 32001<->1025 > =C5=A0 > 32511<->2047 > > 4 - NAT could still be done for outbound 1:1 if host performs source port > control. So in this case MAP_PORT_SET could be used for NAPT in a SLNAT44 > fashion as we discussed when CPE is in bridge mode. > > Let me know your thoughts. --=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 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 --20cf30223e412c4d3204cfded7bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Reinaldo,

Thanks for your explainati= on. Below is my consideration.

On Sat, De= c 1, 2012 at 10:49 PM, Reinaldo Penno (repenno) <repenno@cisco.com>= wrote:
On 11/30/12 8:58 AM, "= ;Simon Perreault" <s= imon.perreault@viagenie.ca> wrote:


A few comments here:

1 - MAP_PORT_SET delegates ports as opposed to installing a translation
port mapping. This is almost a firewall application and would be good if it could be applied in that case as well. IN other words, allow a
application to open bulk ports in firewalls.
[Qiong] I= think this is fine:)

2 - A important distinction of MAP and MAP_PORT_SET is that MAP nails down<= br> a single mapping port out of many that can continue to be used for
NAPT44/NAT64, etc. I believe this should still be possible. In other
words, create a 1:1 bulk mapping as I suggest below while leaving other
ports within the subscriber quota for regular NAT.
[Qi= ong] I'm still a little confusing about this 1:1 bulk mapping.In 1:1 po= rt mapping, if the CPE will not do NAPT, but just the CGN(PCP server) will = do the port mapping. Then, why does this CPE request MAP_PORT_SET? Only to = inform the PCP server with its internal port range ? I think in most cases,= the internal port range is a full range (0~65535), right ?

Best wishes
Qiong

3 - Suggestion on MAP_PORT_SET applied to ports

Client sends a MAP_PORT_SET indicating its internal available range, say, 1024-2047 (1024 ports). The CPE certainly knows the internal range it has available, there is no ambiguity here.

Server, allocates external ports 32000-32511 ports. Those 512 ports would be mapped 1:1 into the internal ports beginning with the first one.

So,

32000<->1024
32001<->1025
=C5=A0
32511<->2047

4 - NAT could still be done for outbound 1:1 if host performs source port control. So in this case MAP_PORT_SET could be used for NAPT in a SLNAT44 fashion as we discussed when CPE is in bridge mode.

Let me know your thoughts.



-- <= br>=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 cod= e:
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

--20cf30223e412c4d3204cfded7bd-- From repenno@cisco.com Sun Dec 2 06:46:57 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6313821F8C6D for ; Sun, 2 Dec 2012 06:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=-0.801, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_54=1, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nPTrhvX4SNY for ; Sun, 2 Dec 2012 06:46:53 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id CDEE721F8C65 for ; Sun, 2 Dec 2012 06:46:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9232; q=dns/txt; s=iport; t=1354459613; x=1355669213; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=q8fRt8fp/t5+njOiZKtfbu3aDL5TH9VXxMJmZureEFw=; b=HYl8Ub0r8Pd0sjEMRfLqmLV1AIYegvPCl5qrKDqcdJi9S+MxH2tk6Ozp FH39oGDdSeBY1gfxjB2aeFDrXgFxt8sJPtu7CbjicAfIDgLW9b5blDAsK tFpXrrvOx5z7BCPA3/9Tt5++t4mx8W0kZapp8XSXmXHLNvOGyTP3OB2gV A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FAFhou1CtJXHB/2dsb2JhbABEgkmDY6dIkhYWc4IeAQEBBAQcBANSEgEIEQMBAgsdBCQRFAkIAgQOBQiHdgMPDKwJDIgFDYlUi1dpHYMSMWEDlCyCcYobhRCCcoFkPQ X-IronPort-AV: E=McAfee;i="5400,1158,6913"; a="148462139" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 02 Dec 2012 14:46:52 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qB2EkqxN025831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 2 Dec 2012 14:46:52 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.203]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Sun, 2 Dec 2012 08:46:52 -0600 From: "Reinaldo Penno (repenno)" To: Qiong Thread-Topic: [pcp] Comments on draft-tsou-pcp-natcoord-08 Thread-Index: AQHNzW7tUdQudtqM2EefCyX9WZI71pgCnQWAgAGxUYCAAaGqAP//6AwA Date: Sun, 2 Dec 2012 14:46:51 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604186400@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.118.205] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F0604186400xmbrcdx04ciscocom_" MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-tsou-pcp-natcoord-08 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, 02 Dec 2012 14:46:57 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F0604186400xmbrcdx04ciscocom_ Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable From: Qiong > Date: Sun, 2 Dec 2012 21:44:26 +0800 To: Reinaldo Penno > Cc: Simon Perreault >, "pcp@ietf.org" > Subject: Re: [pcp] Comments on draft-tsou-pcp-natcoord-08 Dear Reinaldo, Thanks for your explaination. Below is my consideration. On Sat, Dec 1, 2012 at 10:49 PM, Reinaldo Penno (repenno) > wrote: On 11/30/12 8:58 AM, "Simon Perreault" > wrote: A few comments here: 1 - MAP_PORT_SET delegates ports as opposed to installing a translation port mapping. This is almost a firewall application and would be good if it could be applied in that case as well. IN other words, allow a application to open bulk ports in firewalls. [Qiong] I think this is fine:) 2 - A important distinction of MAP and MAP_PORT_SET is that MAP nails down a single mapping port out of many that can continue to be used for NAPT44/NAT64, etc. I believe this should still be possible. In other words, create a 1:1 bulk mapping as I suggest below while leaving other ports within the subscriber quota for regular NAT. [Qiong] I'm still a little confusing about this 1:1 bulk mapping.In 1:1 por= t mapping, if the CPE will not do NAPT, but just the CGN(PCP server) will d= o the port mapping. Then, why does this CPE request MAP_PORT_SET? Only to i= nform the PCP server with its internal port range ? I think in most cases, = the internal port range is a full range (0~65535), right ? [Reinaldo] There are two use cases: 1 =96 Map a range of ports to a server/CPE. Certainly having one mapping is= better than many individual ones 2 =96 There are cases where the range of ports restricted as described in S= LNAT44 and other drafts. Best wishes Qiong 3 - Suggestion on MAP_PORT_SET applied to ports Client sends a MAP_PORT_SET indicating its internal available range, say, 1024-2047 (1024 ports). The CPE certainly knows the internal range it has available, there is no ambiguity here. Server, allocates external ports 32000-32511 ports. Those 512 ports would be mapped 1:1 into the internal ports beginning with the first one. So, 32000<->1024 32001<->1025 =8A 32511<->2047 4 - NAT could still be done for outbound 1:1 if host performs source port control. So in this case MAP_PORT_SET could be used for NAPT in a SLNAT44 fashion as we discussed when CPE is in bridge mode. Let me know your thoughts. -- =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_45A697A8FFD7CF48BCF2BE7E106F0604186400xmbrcdx04ciscocom_ Content-Type: text/html; charset="windows-1250" Content-ID: Content-Transfer-Encoding: quoted-printable


From: Qiong <bingxuere@gmail.com>
Date: Sun, 2 Dec 2012 21:44:26 += ;0800
To: Reinaldo Penno <repenno@cisco.com>
Cc: Simon Perreault <simon.perreault@viagenie.ca>, &q= uot;pcp@ietf.org" <pcp@ietf.org>
Subject: Re: [pcp] Comments on draf= t-tsou-pcp-natcoord-08

Dear Reinaldo,

Thanks for your explaination. Below is my consideration.

On Sat, Dec 1, 2012 at 10:49 PM, Reinaldo Penno = (repenno) <repenno@cisco.com> wrote:
On 11/30/12 8:58 AM, "Simon Perreault" <simon.perreault@viagenie.ca&= gt; wrote:


A few comments here:

1 - MAP_PORT_SET delegates ports as opposed to installing a translation
port mapping. This is almost a firewall application and would be good if it could be applied in that case as well. IN other words, allow a
application to open bulk ports in firewalls.
[Qiong] I think this is fine:)

2 - A important distinction of MAP and MAP_PORT_SET is that MAP nails down<= br> a single mapping port out of many that can continue to be used for
NAPT44/NAT64, etc. I believe this should still be possible. In other
words, create a 1:1 bulk mapping as I suggest below while leaving other
ports within the subscriber quota for regular NAT.
[Qiong] I'm still a little confusing about this 1:1 bulk mapping.In 1:= 1 port mapping, if the CPE will not do NAPT, but just the CGN(PCP server) w= ill do the port mapping. Then, why does this CPE request MAP_PORT_SET? Only= to inform the PCP server with its internal port range ? I think in most cases, the internal port range is a = full range (0~65535), right ?


[Reinaldo] There are two use cases: 

1 =96 Map a range of ports to a server/CPE. Certainly having one mappi= ng is better than many individual ones
2 =96 There are cases where the range of ports restricted as described= in SLNAT44 and other drafts.



Best wishes
Qiong

3 - Suggestion on MAP_PORT_SET applied to ports

Client sends a MAP_PORT_SET indicating its internal available range, say, 1024-2047 (1024 ports). The CPE certainly knows the internal range it has available, there is no ambiguity here.

Server, allocates external ports 32000-32511 ports. Those 512 ports would be mapped 1:1 into the internal ports beginning with the first one.

So,

32000<->1024
32001<->1025
=8A
32511<->2047

4 - NAT could still be done for outbound 1:1 if host performs source port control. So in this case MAP_PORT_SET could be used for NAPT in a SLNAT44 fashion as we discussed when CPE is in bridge mode.

Let me know your thoughts.



--
=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_45A697A8FFD7CF48BCF2BE7E106F0604186400xmbrcdx04ciscocom_-- From bingxuere@gmail.com Sun Dec 2 22:42:27 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C9821F84F8 for ; Sun, 2 Dec 2012 22:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_54=1, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5pgagrcZ2hf for ; Sun, 2 Dec 2012 22:42:26 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1D05321F857E for ; Sun, 2 Dec 2012 22:42:26 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so2058806iaz.31 for ; Sun, 02 Dec 2012 22:42:25 -0800 (PST) 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=xEnAyoN+TkPOVevFz/A/pbTAVYt5nZl8M34VlXZpXwQ=; b=vB1uQWXMgFsAP/9TJp0HFYukwHwtOl80fQvffDvQQfkjoaaS/XpNJMEAmQVE952lQ4 SVhGsPekEVWK1NUpnbAI4j6Q5w6na3FKVTBf8tC42EOFTKBiBsn0bYfZwiJNe7LzaLCb LFtSr4BPejk2LnGZ7JXBQpUe/mDmTcDdaW2apRPAx6KOcE8EVE6/wzt24QL+hLM1ycqd aX+wGaQMRy9n3MSKvE16VT5AwAzOVmFr0J0vOZfdo6aclr3YQwtbU3N/0jNB1vrmL6rc PI5JB/WaANzsnOFBO8MPwwQ3R/ALbLJMA7r9/JPiF2HruN0CvGWOgWb9j4H6AeE6XXVg Os6A== Received: by 10.50.45.137 with SMTP id n9mr5366019igm.25.1354516945728; Sun, 02 Dec 2012 22:42:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.76.200 with HTTP; Sun, 2 Dec 2012 22:41:45 -0800 (PST) In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604186400@xmb-rcd-x04.cisco.com> References: <45A697A8FFD7CF48BCF2BE7E106F0604186400@xmb-rcd-x04.cisco.com> From: Qiong Date: Mon, 3 Dec 2012 14:41:45 +0800 Message-ID: To: "Reinaldo Penno (repenno)" Content-Type: multipart/alternative; boundary=14dae93403a56472c904cfed0d28 Cc: "pcp@ietf.org" Subject: Re: [pcp] Comments on draft-tsou-pcp-natcoord-08 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, 03 Dec 2012 06:42:27 -0000 --14dae93403a56472c904cfed0d28 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Reinaldo, Thanks for your suggestion. I think MAP_PORT_SET can be used in your proposed use cases. We will update the draft to reflect this requirement. Best wishes Qiong On Sun, Dec 2, 2012 at 10:46 PM, Reinaldo Penno (repenno) wrote: > > > From: Qiong > Date: Sun, 2 Dec 2012 21:44:26 +0800 > To: Reinaldo Penno > Cc: Simon Perreault , "pcp@ietf.org" < > pcp@ietf.org> > Subject: Re: [pcp] Comments on draft-tsou-pcp-natcoord-08 > > Dear Reinaldo, > > Thanks for your explaination. Below is my consideration. > > On Sat, Dec 1, 2012 at 10:49 PM, Reinaldo Penno (repenno) < > repenno@cisco.com> wrote: > >> On 11/30/12 8:58 AM, "Simon Perreault" >> wrote: >> >> >> A few comments here: >> >> 1 - MAP_PORT_SET delegates ports as opposed to installing a translation >> port mapping. This is almost a firewall application and would be good if >> it could be applied in that case as well. IN other words, allow a >> application to open bulk ports in firewalls. >> > [Qiong] I think this is fine:) > >> >> 2 - A important distinction of MAP and MAP_PORT_SET is that MAP nails do= wn >> a single mapping port out of many that can continue to be used for >> NAPT44/NAT64, etc. I believe this should still be possible. In other >> words, create a 1:1 bulk mapping as I suggest below while leaving other >> ports within the subscriber quota for regular NAT. >> > [Qiong] I'm still a little confusing about this 1:1 bulk mapping.In 1:1 > port mapping, if the CPE will not do NAPT, but just the CGN(PCP server) > will do the port mapping. Then, why does this CPE request MAP_PORT_SET? > Only to inform the PCP server with its internal port range ? I think in > most cases, the internal port range is a full range (0~65535), right ? > > > [Reinaldo] There are two use cases: > > 1 =E2=80=93 Map a range of ports to a server/CPE. Certainly having one m= apping > is better than many individual ones > 2 =E2=80=93 There are cases where the range of ports restricted as descri= bed in > SLNAT44 and other drafts. > > > > Best wishes > Qiong > >> >> 3 - Suggestion on MAP_PORT_SET applied to ports >> >> Client sends a MAP_PORT_SET indicating its internal available range, say= , >> 1024-2047 (1024 ports). The CPE certainly knows the internal range it ha= s >> available, there is no ambiguity here. >> >> Server, allocates external ports 32000-32511 ports. Those 512 ports woul= d >> be mapped 1:1 into the internal ports beginning with the first one. >> >> So, >> >> 32000<->1024 >> 32001<->1025 >> =C5=A0 >> 32511<->2047 >> >> 4 - NAT could still be done for outbound 1:1 if host performs source por= t >> control. So in this case MAP_PORT_SET could be used for NAPT in a SLNAT4= 4 >> fashion as we discussed when CPE is in bridge mode. >> >> Let me know your thoughts. > > > > > -- > =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 > > > --=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 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 --14dae93403a56472c904cfed0d28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Reinaldo,

Thanks for your suggestion. I think MAP_PORT_SET can = be used in your proposed use cases. We will update the draft to reflect thi= s requirement.

Best wishes
Qiong


On Sun, Dec 2, 2012 at 10:46 PM, Reinald= o Penno (repenno) <repenno@cisco.com> wrote:


From: Qiong <bingxuere@gmail.com>
Date: Sun, 2 Dec 2012 21:44:26 +080= 0
To: Reinaldo Penno <repenno@cisco.com>
Cc: Simon Perreault <simon.perreault@viage= nie.ca>, "pcp= @ietf.org" <p= cp@ietf.org>
Subject: Re: [pcp] Comments on draf= t-tsou-pcp-natcoord-08

Dear Reinaldo,

Thanks for your explaination. Below is my consideration.

On Sat, Dec 1, 2012 at 10:49 PM, Reinaldo Penno = (repenno) <repenno@cisco.com> wrote:
On 11/30/12 8:58 AM, "Simon Perreault" <simon.perreault@viagenie.ca= > wrote:


A few comments here:

1 - MAP_PORT_SET delegates ports as opposed to installing a translation
port mapping. This is almost a firewall application and would be good if it could be applied in that case as well. IN other words, allow a
application to open bulk ports in firewalls.
[Qiong] I think this is fine:)

2 - A important distinction of MAP and MAP_PORT_SET is that MAP nails down<= br> a single mapping port out of many that can continue to be used for
NAPT44/NAT64, etc. I believe this should still be possible. In other
words, create a 1:1 bulk mapping as I suggest below while leaving other
ports within the subscriber quota for regular NAT.
[Qiong] I'm still a little confusing about this 1:1 bulk mapping.I= n 1:1 port mapping, if the CPE will not do NAPT, but just the CGN(PCP serve= r) will do the port mapping. Then, why does this CPE request MAP_PORT_SET? = Only to inform the PCP server with its internal port range ? I think in most cases, the internal port range is a = full range (0~65535), right ?


[Reinaldo] There are two use cases:=C2=A0

1 =E2=80=93 Map a range of ports to a server/CPE. Certainly having one= mapping is better than many individual ones
2 =E2=80=93 There are cases where the range of ports restricted as des= cribed in SLNAT44 and other drafts.



Best wishes
Qiong

3 - Suggestion on MAP_PORT_SET applied to ports

Client sends a MAP_PORT_SET indicating its internal available range, say, 1024-2047 (1024 ports). The CPE certainly knows the internal range it has available, there is no ambiguity here.

Server, allocates external ports 32000-32511 ports. Those 512 ports would be mapped 1:1 into the internal ports beginning with the first one.

So,

32000<->1024
32001<->1025
=C5=A0
32511<->2047

4 - NAT could still be done for outbound 1:1 if host performs source port control. So in this case MAP_PORT_SET could be used for NAPT in a SLNAT44 fashion as we discussed when CPE is in bridge mode.

Let me know your thoughts.



--
=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



--
=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 Be= ijing Research Institude


Open source code:
lightweight 4over6= : h= ttp://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

--14dae93403a56472c904cfed0d28-- From alper.yegin@yegin.org Mon Dec 3 01:00:05 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2E021F88A4 for ; Mon, 3 Dec 2012 01:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.26 X-Spam-Level: X-Spam-Status: No, score=-101.26 tagged_above=-999 required=5 tests=[AWL=-1.075, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phBViDjCEgqK for ; Mon, 3 Dec 2012 01:00:05 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id DB83221F88E0 for ; Mon, 3 Dec 2012 01:00:04 -0800 (PST) Received: from [192.168.2.7] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LuOhb-1TEoWS3EaF-011a54; Mon, 03 Dec 2012 03:59:53 -0500 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: Date: Mon, 3 Dec 2012 10:59:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2EF2D7DF-04C2-4F9D-8569-63132CB06301@yegin.org> References: <45A697A8FFD7CF48BCF2BE7E106F0604184E52@xmb-rcd-x04.cisco.com> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:7aA23+bUGOBEfGUMxE2DereN/9bZf8ij4W6kQjZctuc nRNJHklyMgtXbnz3HmSSwjzy/73j42y9dPPifBHQZm9sZVFKto LyzZ7wOVJW/fbow+4hS0jT1n8vaHtU8/GxkTn0yWRnl6LQavmI EjUVhKvOFjCD9NIGmV/v6ERTnBTfX1uDMNzqbh/Hlbu0Ebvefj zjx6yQnMn6ME1sfqrzVJ19aIZQU37y5YG15k3P5cBrnKRaa7/U CWKebr6Y9AXITntVV9G3uYWvzY6ZfJ/5EJCkLdFAJcPE8d3+qC z+cb/mmCgqsUyIfYELzGi+LU+hDdwJ1blwrHZOgKR2K0groLOu mFzPCHh3YmfcFrVN2p5SORMREBCM7tJ+2QWoLdKvTZPqDPB9ap pg8+Vt/rwpPyw== Cc: pcp@ietf.org Subject: Re: [pcp] Unsolicited Messages to Client with no security association 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, 03 Dec 2012 09:00:05 -0000 On Nov 30, 2012, at 1:58 PM, Sam Hartman wrote: >>>>>> "Alper" =3D=3D Alper Yegin writes: >=20 > Alper> Sam, Even if what you were saying made sense (which I > Alper> strongly disagree for the very reasons Yoshi has been > Alper> explaining), it does not matter. Let me explain: >=20 > Alper> You are claiming there is a deployment case where = unsolicited > Alper> messages from the server does not need to be > Alper> integrity-protected. Nevertheless, there would also be > Alper> deployment cases where server wants to integrity-protect all > Alper> of the messages. >=20 > Alper, saying a thing again and again does not make it true. > I claim there is no security reason for a server to want to integrity > protect all its messages. > That is precisely the disagreement, and asserting your position again > and again doesn't move the discussion forward. > I've provided you with a framework of threats and security = requirements > in which to argue about whether there is a reason for a server to > require that responses be integrity protected. > Please construct an argument rather than repeat yourself. If you don't > like my framework, please propose your own. Are you not reading? I already stated that. Simple solution is to let = the server initiate re-auth when it has a message to send to the client = but it does not have a live SA with the client. (I still don't understand why this is not OK to the extent that you keep = coming up with really "creative" ideas such as below). > Alternatively, step aside and let us move on and get some work done. >=20 I'm afraid we have a different definition of work. I don't count = reinventing the wheel as work. > We both agree that clients need to be able to validate the integrity = of > responses. That means the response either needs to be sent with > integrity, or the client needs to be able to solicit the same > information with integrity protection. >=20 Let's say we do that. Next time the client receives a message from the server, if the message = is not integrity protected, that tells the client "the server has = something to tell you". Well, the client shall in no way try to parse the content of the message = because it's not integrity protected. All it says is "the server has = something to tell you". In your approach, in response to such a message, the client shall = initiate re-auth. Once re-auth is done, now the client sends a solicitation: "please send = me that last message again". Now, this is funky. Never seen such a design before. Have you, or has = anyone? And=85. It simply has "server initiated re-auth" hidden in it. Look, the = very first message sent by the server in fact is the message that = initiates the re-authentication.=20 Instead of sending the PCP message, the server could send a trigger to = initiate re-auth.=20 Much simpler. You just re-invented server initiated re-auth in a really non-straight = forward way, with more intrusion into the PCP design. Alper > --Sam From hartmans@painless-security.com Mon Dec 3 08:03:36 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A774321F8574 for ; Mon, 3 Dec 2012 08:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qynilEvcfTd for ; Mon, 3 Dec 2012 08:03:36 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 21E9D21F854C for ; Mon, 3 Dec 2012 08:03:35 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id BCA342003E; Mon, 3 Dec 2012 11:01:44 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 75C2F420E; Mon, 3 Dec 2012 11:03:32 -0500 (EST) From: Sam Hartman To: Yoshihiro Ohba References: <45A697A8FFD7CF48BCF2BE7E106F0604153730@xmb-aln-x04.cisco.com> <87A8FD6F-BB3D-4545-B317-A19B7426D56F@yegin.org> <50B779E7.7070507@toshiba.co.jp> <50B7FE88.1030406@toshiba.co.jp> <50B8243D.7090605@toshiba.co.jp> <50B949FA.70503@toshiba.co.jp> Date: Mon, 03 Dec 2012 11:03:32 -0500 In-Reply-To: <50B949FA.70503@toshiba.co.jp> (Yoshihiro Ohba's message of "Sat, 01 Dec 2012 09:06:18 +0900") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] Unsolicited Messages to Client with no security association 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, 03 Dec 2012 16:03:36 -0000 >>>>> "Yoshihiro" == Yoshihiro Ohba writes: Yoshihiro> (2012/11/30 21:19), Sam Hartman wrote: >> R4) An attacker MUST NOT be able to force the client or server to >> perform re-authentication unless the client or server desires >> re-authentication. Yoshihiro> The text looks like a requirement for an attacker's Yoshihiro> functionality, but I believe that is not your intent. Yoshihiro> How about this? Yoshihiro> R4) A client and a server MUST be able to detect and Yoshihiro> ignore false re-authentication trigger messages sent by Yoshihiro> attackers. Hi. I'm fine with the above. I've been struggling for a couple of days with a response because I'm still not sure an explicit re-authentication message (instead of something that sometimes triggers re-auth) is required. But I realized that at this point we both seem to agree on the requirement and we'd just be quibbling over wording. So if by re-authentication trigger messages we mean any message that triggers re-authentication regardless of whether it's called a re-authentication message, I think we understand the requirement you're proposing. --Sam From yoshihiro.ohba@toshiba.co.jp Mon Dec 3 16:32:14 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93A721F88FB for ; Mon, 3 Dec 2012 16:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.089 X-Spam-Level: X-Spam-Status: No, score=-5.089 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lK1OHUeohMKT for ; Mon, 3 Dec 2012 16:32:10 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 387F821F8912 for ; Mon, 3 Dec 2012 16:32:10 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id qB40W7uO016031; Tue, 4 Dec 2012 09:32:07 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id qB40W7rF024081; Tue, 4 Dec 2012 09:32:07 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id KAA24077; Tue, 4 Dec 2012 09:32:06 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id qB40W65R015074; Tue, 4 Dec 2012 09:32:06 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id qB40W67e015844; Tue, 4 Dec 2012 09:32:06 +0900 (JST) Received: from [133.199.146.200] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MEH00A7FDH6ZN40@mail.po.toshiba.co.jp>; Tue, 04 Dec 2012 09:32:06 +0900 (JST) Date: Tue, 04 Dec 2012 09:31:55 +0900 From: Yoshihiro Ohba In-reply-to: To: Sam Hartman Message-id: <50BD447B.2020606@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <45A697A8FFD7CF48BCF2BE7E106F0604153730@xmb-aln-x04.cisco.com> <87A8FD6F-BB3D-4545-B317-A19B7426D56F@yegin.org> <50B779E7.7070507@toshiba.co.jp> <50B7FE88.1030406@toshiba.co.jp> <50B8243D.7090605@toshiba.co.jp> <50B949FA.70503@toshiba.co.jp> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Cc: pcp@ietf.org Subject: Re: [pcp] Unsolicited Messages to Client with no security association 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, 04 Dec 2012 00:32:15 -0000 (2012/12/04 1:03), Sam Hartman wrote: > > Yoshihiro> R4) A client and a server MUST be able to detect and > Yoshihiro> ignore false re-authentication trigger messages sent by > Yoshihiro> attackers. > > Hi. I'm fine with the above. I've been struggling for a couple of days > with a response because I'm still not sure an explicit re-authentication > message (instead of something that sometimes triggers re-auth) is > required. But I realized that at this point we both seem to agree on > the requirement and we'd just be quibbling over wording. > > So if by re-authentication trigger messages we mean any message that > triggers re-authentication regardless of whether it's called a > re-authentication message, I think we understand the requirement you're > proposing. That is correct. I am not sure what you are planning to do for EAP over PCP, but as you may know PANA approaches meet all the requirements. Yoshihiro Ohba > > > > --Sam > From simon.perreault@viagenie.ca Thu Dec 6 02:21:09 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D9F21F8697 for ; Thu, 6 Dec 2012 02:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-guFYAFsKw2 for ; Thu, 6 Dec 2012 02:21:09 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 141CF21F8698 for ; Thu, 6 Dec 2012 02:21:09 -0800 (PST) Received: from porto.nomis80.org (85-169-39-219.rev.numericable.fr [85.169.39.219]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9677D469E7 for ; Thu, 6 Dec 2012 05:21:07 -0500 (EST) Message-ID: <50C07190.4020305@viagenie.ca> Date: Thu, 06 Dec 2012 11:21:04 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: pcp@ietf.org References: <45A697A8FFD7CF48BCF2BE7E106F0604184E52@xmb-rcd-x04.cisco.com> <2EF2D7DF-04C2-4F9D-8569-63132CB06301@yegin.org> In-Reply-To: <2EF2D7DF-04C2-4F9D-8569-63132CB06301@yegin.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] Unsolicited Messages to Client with no security association 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, 06 Dec 2012 10:21:09 -0000 Le 2012-12-03 09:59, Alper Yegin a écrit : >> We both agree that clients need to be able to validate the integrity of >> responses. That means the response either needs to be sent with >> integrity, or the client needs to be able to solicit the same >> information with integrity protection. >> > > Let's say we do that. "That" meaning "let the client solicit the same information with integrity protection", I assume. > Next time the client receives a message from the server, if the message is not integrity protected, that tells the client "the server has something to tell you". > Well, the client shall in no way try to parse the content of the message because it's not integrity protected. All it says is "the server has something to tell you". > In your approach, in response to such a message, the client shall initiate re-auth. > Once re-auth is done, now the client sends a solicitation: "please send me that last message again". > > Now, this is funky. Never seen such a design before. Have you, or has anyone? Another problem with this design is that it will surely be mis-implemented by clients that will not do re-auth and will instead trust the contents of the initial message as if it was protected. It's a trap for implementers. > And…. It simply has "server initiated re-auth" hidden in it. Look, the very first message sent by the server in fact is the message that initiates the re-authentication. > Instead of sending the PCP message, the server could send a trigger to initiate re-auth. > Much simpler. > > You just re-invented server initiated re-auth in a really non-straight forward way, with more intrusion into the PCP design. I still share Alper's understanding fully. 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 hartmans@painless-security.com Tue Dec 11 06:37:12 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B774B21F8484 for ; Tue, 11 Dec 2012 06:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXgVUgFV7QUy for ; Tue, 11 Dec 2012 06:37:12 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 008BE21F87F9 for ; Tue, 11 Dec 2012 06:37:11 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 7A3F820161; Tue, 11 Dec 2012 09:35:02 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D02C943F0; Tue, 11 Dec 2012 09:37:00 -0500 (EST) From: Sam Hartman To: Simon Perreault References: <45A697A8FFD7CF48BCF2BE7E106F0604184E52@xmb-rcd-x04.cisco.com> <2EF2D7DF-04C2-4F9D-8569-63132CB06301@yegin.org> <50C07190.4020305@viagenie.ca> Date: Tue, 11 Dec 2012 09:37:00 -0500 In-Reply-To: <50C07190.4020305@viagenie.ca> (Simon Perreault's message of "Thu, 06 Dec 2012 11:21:04 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org Subject: Re: [pcp] Unsolicited Messages to Client with no security association 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, 11 Dec 2012 14:37:12 -0000 Simon and I spoke about the server-initiated messages last Friday. It was an interesting conversation and we'd like to report on our different approaches to the WG in the hopes of informing the discussion and moving things forward. Simon was approaching PCP authentication from the ISP standpoint, where the primary goal is to protect the client. I was approaching things assuming the primary user of authentication will be enterprise authentication and protecting the authorization of the server will be one of the important goals of PCP authentication. The big attack that we're concerned about when we consider unsolicited updates is a change in mappings. For example consider a case where a client is using a mapping for media announcements in SDP. The server sends an unsolicited update because the mapping has changed and so the client starts using the new address in new SDP announcements. If an attacker convinces the client to use an external address of the attacker's choice, then the attacker can potentially intercept media. Simon said that he's most concerned about this type of attack when considering unsolicited messages. Neither of us could come up with very significant attacks on announce messages. Potentially you could cause a client to spend a lot of time updating mappings with a fake announce message. However, there's a significant gap in our defense against this attack. We support clients that that only authenticate when the server requires it. Such a client sends an unauthenticated request and performs authentication when it receives an authentication required error. Rather than attacking an unsolicited update, an attacker could simply reply to the initial request with an unauthenticated answer. There are some circumstances where the attacker might not be able to do that but would be able to attack an unsolicited update. However, in most circumstances, the same sorts of attacks that could be mounted against unsolicited updates can be mounted against initial responses. The full defense against this sort of attack is for the client to require authentication all the time. I think this is going to require explicit configuration of the client. Simon and I both agree that clients that require authentication all the time MUST verify the integrity of the contents of unsolicited responses. If there are circumstances where these responses do not include integrity related to a current security association, then those messages MUST NOT be trusted without soliciting an integrity protected version. Obviously if we end up with a solution where we have server initiated re-auth that servers are required to use, then the responses will always be protected by a current security association. Simon is concerned about a solution where integrity protection is sometimes absent from unsolicited responses. He's concerned that people will make an implementation error and accept unprotected responses when they should not. he said that having some security information in the message , including a protected indication that a SA had been deleted, reduced this concern somewhat. I pointed out that under my proposal, an attacker could not generate a valid unprotected message until the attacker had seen an unprotected message. If the client did re-authenticate at that point, then the attacker would no longer be able to produce an valid unprotected message. In my mind the biggest advantage of my proposal is that servers do not need to queue messages while authentication takes place. Clients may need to queue information on what mappings to solicit updates for. I think the biggest question to the WG is whether partially defending against the mapping change attack is worth requiring servers to queue outgoing unsolicited messages. Simon has reviewed this summary and agrees that it describes our meeting. From repenno@cisco.com Tue Dec 11 21:23:04 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181F121F88C6 for ; Tue, 11 Dec 2012 21:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.332 X-Spam-Level: X-Spam-Status: No, score=-10.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-8dJzLvhB0t for ; Tue, 11 Dec 2012 21:23:01 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6C021F869F for ; Tue, 11 Dec 2012 21:23:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4646; q=dns/txt; s=iport; t=1355289781; x=1356499381; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=tA2VE0EgM6j/tynQ4p/jQgrHVx64Kc7IXLOdrSHD2+Q=; b=HAe3qMO1K0WwNSrP3eJWrVGnej5M0LzpNfRVc7fqcoK7WfQ5r6RSMU8C NHw9xAh5dKTuNcFNQB4qTQKLA6AA+nTKLbFk2+J+kemZpT/I5EVZsBcxr wC+TEFZOA8N5UVfyAypR+mjgS/ZDeVhuV+UI2GtGnB2Pfy84E8LshZSdU A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOwTyFCtJXG//2dsb2JhbABFvnwWc4IgAQQBAQE3NAsSAQgiFDcLJQIEAQ0FCBOHdgy8CgSQLWEDpk+Cc4Ii X-IronPort-AV: E=Sophos;i="4.84,264,1355097600"; d="scan'208";a="148966418" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 12 Dec 2012 05:23:00 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBC5N0Js004350 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Dec 2012 05:23:00 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.29]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Tue, 11 Dec 2012 23:23:00 -0600 From: "Reinaldo Penno (repenno)" To: Sam Hartman , Simon Perreault Thread-Topic: [pcp] Unsolicited Messages to Client with no security association Thread-Index: AQHN2CjAeiR17VEXek+aaUslGKlKuA== Date: Wed, 12 Dec 2012 05:23:00 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06041A1612@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.88.238] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Unsolicited Messages to Client with no security association 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, 12 Dec 2012 05:23:04 -0000 Hello Sam/Simon, Some comments inline.. On 12/11/12 12:37 PM, "Sam Hartman" wrote: > >Simon and I spoke about the server-initiated messages last Friday. It >was an interesting conversation and we'd like to report on our different >approaches to the WG in the hopes of informing the discussion and moving >things forward. >Simon was approaching PCP authentication from the ISP standpoint, where >the primary goal is to protect the client. I was approaching things >assuming the primary user of authentication will be enterprise >authentication and protecting the authorization of the server will be >one of the important goals of PCP authentication. > >The big attack that we're concerned about when we consider unsolicited >updates is a change in mappings. For example consider a case where a >client is using a mapping for media announcements in SDP. The server >sends an unsolicited update because the mapping has changed and so the >client starts using the new address in new SDP announcements. If an >attacker convinces the client to use an external address of the >attacker's choice, then the attacker can potentially intercept media. >Simon said that he's most concerned about this type of attack when >considering unsolicited messages. > >Neither of us could come up with very significant attacks on announce >messages. Potentially you could cause a client to spend a lot of time >updating mappings with a fake announce message. > >However, there's a significant gap in our defense against this >attack. We support clients that that only authenticate when the server >requires it. >Such a client sends an unauthenticated request and performs >authentication when it receives an authentication required error. >Rather than attacking an unsolicited update, an attacker could simply >reply to the initial request with an unauthenticated answer. There are >some circumstances where the attacker might not be able to do that but >would be able to attack an unsolicited update. >However, in most circumstances, the same sorts of attacks that could be >mounted against unsolicited updates can be mounted against initial >responses. With one detail. The window of opportunity to attack unsolicited responses is much larger than initial response. > >The full defense against this sort of attack is for the client to >require authentication all the time. I think this is going to require >explicit configuration of the client. Simon and I both agree that >clients that require authentication all the time MUST verify the >integrity of the contents of unsolicited responses. If there are >circumstances where these responses do not include integrity related to >a current security association, then those messages MUST NOT be trusted >without soliciting an integrity protected version. Obviously if we end >up with a solution where we have server initiated re-auth that servers >are required to use, then the responses will always be protected by a >current security association. > >Simon is concerned about a solution where integrity protection is >sometimes absent from unsolicited responses. He's concerned that people >will make an implementation error and accept unprotected responses when >they should not. he said that having some security information in the >message , including a protected indication that a SA had been deleted, >reduced this concern somewhat. I pointed out that under my proposal, an >attacker could not generate a valid unprotected message until the >attacker had seen an unprotected message. Could you explain this part? I looked at the draft and was under the impression that as long as the attacker could look at PCP messages going by it could at any point send an unprotected unsolicited response. Even before seeing an unprotected message from server. >If the client did >re-authenticate at that point, then the attacker would no longer be able >to produce an valid unprotected message. > >In my mind the biggest advantage of my proposal is that servers do not >need to queue messages while authentication takes place. >Clients may need to queue information on what mappings to solicit >updates for. > >I think the biggest question to the WG is whether partially defending >against the mapping change attack is worth requiring servers to queue >outgoing unsolicited messages. > >Simon has reviewed this summary and agrees that it describes our >meeting. >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp From internet-drafts@ietf.org Wed Dec 19 01:09:35 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F17C21F8B15; Wed, 19 Dec 2012 01:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.131 X-Spam-Level: X-Spam-Status: No, score=-102.131 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Za1QkrcaVQDy; Wed, 19 Dec 2012 01:09:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38EF21F8AF8; Wed, 19 Dec 2012 01:09:34 -0800 (PST) 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.37 Message-ID: <20121219090934.22003.39414.idtracker@ietfa.amsl.com> Date: Wed, 19 Dec 2012 01:09:34 -0800 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-upnp-igd-interworking-06.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, 19 Dec 2012 09:09:35 -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 : Universal Plug and Play (UPnP) Internet Gateway Device (= IGD)-Port Control Protocol (PCP) Interworking Function Author(s) : Mohamed Boucadair Reinaldo Penno Dan Wing Filename : draft-ietf-pcp-upnp-igd-interworking-06.txt Pages : 24 Date : 2012-12-19 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-upnp-igd-interworking There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-upnp-igd-interworking-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-upnp-igd-interworking-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cathy.zhou@huawei.com Thu Dec 20 00:28:10 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0653A21F8472 for ; Thu, 20 Dec 2012 00:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkK5GrlRNUXF for ; Thu, 20 Dec 2012 00:28:09 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0F29A21F846B for ; Thu, 20 Dec 2012 00:28:08 -0800 (PST) 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 ANZ96375; Thu, 20 Dec 2012 08:28:07 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 08:27:48 +0000 Received: from SZXEML430-HUB.china.huawei.com (10.72.61.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 08:27:53 +0000 Received: from SZXEML527-MBX.china.huawei.com ([169.254.3.147]) by szxeml430-hub.china.huawei.com ([10.72.61.38]) with mapi id 14.01.0323.003; Thu, 20 Dec 2012 16:27:44 +0800 From: "Zhouqian (Cathy)" To: "mohamed.boucadair@orange.com" , "pcp@ietf.org" Thread-Topic: draft-ietf-pcp-proxy-01 Thread-Index: AQHNfFtQglT2FR9y7E+uIv3odqkuvJghxfUA Date: Thu, 20 Dec 2012 08:27:44 +0000 Message-ID: References: <20120817092347.27948.43556.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36E512B43CD@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E512B43CD@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [pcp] draft-ietf-pcp-proxy-01 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, 20 Dec 2012 08:28:10 -0000 Dear Med and all, When looking over section 10 of this document, there is one more advanced f= eature in my mind that may be added for PCP proxy.=20 In [I-D.ietf-pcp-base], the PCP server could send the ANNOUNCE response to = both multicast and unicast addresses. For multicast address case, it only a= pplies when the network is layer2 network and there is a multicast link bet= ween PCP client and PCP server. If there is no multicast link between PCP c= lient and PCP server, one access router (e.g., PCP proxy) may perform the m= ulticast address/unicast address conversion function. When the PCP proxy re= ceives the ANNOUNCE message from the PCP server, it replaces the unicast ad= dress of itself with the PCP client's multicast address and sends ANNOUNCE = message to the multicast address. It is required that the network between t= he PCP proxy and the PCP client is layer2.=20 Any comments? Best Regards, Cathy > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: Friday, August 17, 2012 5:33 PM > To: pcp@ietf.org > Subject: [pcp] draft-ietf-pcp-proxy-01 >=20 > Dear all, >=20 > A new version is now available online: > http://tools.ietf.org/html/draft-ietf-pcp-proxy-01 >=20 > The main changes in -01 are as follows: >=20 > * The reference architecture is updated: the PCP proxy is not restricted = to > the CP router deployment case. > * Add a new section to specify the behaviour when the PCP Proxy is not > co-located with a NAT function > * Add a new section for mappings repair > * More discussion for the multiple PCP Servers scenario > * Text is cleanup >=20 > A detailed diff is available here: >=20 > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-proxy-01 >=20 > Please review this new version and provide input. >=20 > Cheers, > Med > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From tireddy@cisco.com Thu Dec 20 22:42:59 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A1421F8AC1 for ; Thu, 20 Dec 2012 22:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLc1TY3Nr8lz for ; Thu, 20 Dec 2012 22:42:58 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C2E7221F8ABF for ; Thu, 20 Dec 2012 22:42:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2372; q=dns/txt; s=iport; t=1356072179; x=1357281779; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=VTBSYwKon7wNw9cdGujbLLft6uE0AdUpgH+7Ue/tuv4=; b=LanvT2IwexKMuvGbjQzI0GvamPyjkq3+4GwLmLKfqdyq7QSNmGkz3dVn x7ex2HuRHrTVbQgWze8kAuckzcvxUEnRZD2rVBavLVyFELC8x+hyik9g+ l9T8Se2s4PncjqImnhFV9BIG2BNkbKQq5ovCmL5RSozR4UeGfIGP0RVir 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAO0D1FCtJV2Z/2dsb2JhbABEg226BxZzgh4BAQEEAQEBNzQXBgEIEQEDAQELFAkuCxQDBgoEARIIAYgKBwW3OoxXg2JhA5cnjyyCdIIi X-IronPort-AV: E=Sophos;i="4.84,328,1355097600"; d="scan'208";a="155355506" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 21 Dec 2012 06:42:57 +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 qBL6gvCL002852 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Dec 2012 06:42:57 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.128]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Fri, 21 Dec 2012 00:42:57 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" , "pcp@ietf.org" Thread-Topic: [pcp] draft-ietf-pcp-proxy-01 Thread-Index: AQHN3uybfXVjAbB6bU6t4S6LHaLs+ZgizVgw Date: Fri, 21 Dec 2012 06:42:56 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A148C07A6@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.81.251] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] draft-ietf-pcp-proxy-01 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, 21 Dec 2012 06:42:59 -0000 Hi Med, Comments [1] Section 3 PCP Server Discovery and Provisioning :=20 You may also want to add details that PCP Proxy would use similar mechanism= just like PCP client to discover the PCP server. [2] Section 5 Control of the Firewall :=20 Firewall rules would be typically to block any unsolicited traffic from out= side to inside. For PCP request/response this will not be a problem, but wo= uld have issues with unsolicited ANNOUNCE. In this case PCP Authentication = looks mandatory to handle man-in-middle attacks trying to act as PCP Server= . [3] Section 5 : Replace REMOTE_PEER_FILTER with FILTER option [4] Section 8 MAP/PEER handling : you may also want to clarify PCP proxy be= havior when PCP client uses THIRD_PARTY option. [5] Section 10.1 Multiple PCP servers : There could be another scenarios th= at PCP proxy would forward the PCP request to one of the PCP servers depend= ing on the fields set in PCP request (for specific use cases please refer t= o http://tools.ietf.org/html/draft-rpcw-pcp-pmipv6-serv-discovery-00 , http= ://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-02#section-8)] [6] How is it ensured that only the PCP proxy can communicate with the PCP = server and not any other PCP client ? --Tiru. > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: Friday, August 17, 2012 5:33 PM > To: pcp@ietf.org > Subject: [pcp] draft-ietf-pcp-proxy-01 >=20 > Dear all, >=20 > A new version is now available online: > http://tools.ietf.org/html/draft-ietf-pcp-proxy-01 >=20 > The main changes in -01 are as follows: >=20 > * The reference architecture is updated: the PCP proxy is not restricted = to > the CP router deployment case. > * Add a new section to specify the behaviour when the PCP Proxy is not > co-located with a NAT function > * Add a new section for mappings repair > * More discussion for the multiple PCP Servers scenario > * Text is cleanup >=20 > A detailed diff is available here: >=20 > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-proxy-01 >=20 > Please review this new version and provide input. >=20 > Cheers, > Med > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp