From tireddy@cisco.com Mon Oct 1 09:18: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 A228A21F87B9 for ; Mon, 1 Oct 2012 09:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 N3rjf1nOsTsZ for ; Mon, 1 Oct 2012 09:18:08 -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 75D2621F87B5 for ; Mon, 1 Oct 2012 09:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9006; q=dns/txt; s=iport; t=1349108288; x=1350317888; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oA2YuhZ86fCfAg54l4Zz1UwQ6H88fwga6Avif4DoMkw=; b=PO9w4ir9VvVB8LDB+YzHsqocR7ECCEzkWfHDwqxZueD6cC5nBW69eQWv +56SX9ylQJZldtZZAONyG/7+sTZbdS95eV/cPY0EQjSHBuvyxviXvokUP 7+h92rHVYAtpuX7HW8R1g6tjnB+GjhOT/rb69VsO8vWziiaGf/+xabfQF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALTBaVCtJV2b/2dsb2JhbABFvjeBCIIgAQEBBBIBFBM/DAQCAQgRBAEBCxQFBAcyFAkIAgQBDQUIDAcHh2OZK6ANix8chU9gA6QrgWmCZ4FbPA X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="scan'208";a="127147382" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 01 Oct 2012 16:18:07 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q91GI64D031395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Oct 2012 16:18:06 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.241]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Mon, 1 Oct 2012 11:18:06 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Dan Wing (dwing)" , "'Sam Hartman'" , "pcp@ietf.org" Thread-Topic: [pcp] draft-ietf-pcp-base-27: objection to security considerations change; ietf last call requested Thread-Index: AQHNnat7+So7PPnEyU6F/txywAFSNJeknyCQ Date: Mon, 1 Oct 2012 16:18:05 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A147DBD13@xmb-rcd-x10.cisco.com> References: <057c01cd9d35$b086e370$1194aa50$@com> In-Reply-To: <057c01cd9d35$b086e370$1194aa50$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.73.107] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19226.000 x-tm-as-result: No--53.869100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp-ads@tools.ietf.org" , "stephen.farrell@cs.tcd.ie" Subject: Re: [pcp] draft-ietf-pcp-base-27: objection to security considerations change; ietf last call requested 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, 01 Oct 2012 16:18:09 -0000 Hi Dan - Yes, we should go with options c) and d) Few comments a)If a flow is created which matched the PCP request (MAP/PEER request) If H2 tries to delete MAP, should it be permitted because a flow still exis= ts ? Would the security attack be prevented if only H2 is permitted to delete MA= P only after all the sessions associated with the MAP/PEER request are clos= ed ? For TCP flows N1 could have a TCP state machine to detect when the flow is = closed/terminated.=20 2) For UDP in addition to d) and client H1 will anyhow will have to send ke= ep lives to keep the NAT bindings alive (since it is not PCP-aware and will= have to use technique like RFC 6263)=20 3) Since anyway N2 does not support PCP, it can block PCP using simple port= -based ACL. Legitimate hosts may not even have an application that would wo= rk in this case (let's say use UPnP with N2 and PCP with N1) ?=20 --Tiru. > -----Original Message----- > From: Dan Wing (dwing) > Sent: Friday, September 28, 2012 10:27 AM > To: 'Sam Hartman'; pcp@ietf.org > Cc: stephen.farrell@cs.tcd.ie; pcp-ads@tools.ietf.org > Subject: Re: [pcp] draft-ietf-pcp-base-27: objection to security > considerations change; ietf last call requested >=20 > Sam, PCP working group, >=20 > > -----Original Message----- > > From: Sam Hartman [mailto:hartmans@painless-security.com] > > Sent: Sunday, September 23, 2012 11:38 AM > > To: pcp@ietf.org > > Cc: pcp-ads@tools.ietf.org; stephen.farrell@cs.tcd.ie > > Subject: draft-ietf-pcp-base-27: objection to security considerations > > change; ietf last call requested > > > > > > Hi. > > draft-ietf-pcp-base-27 relaxes restrictions in the simple threat model > > (section 18.1). > > In particular, it permits the lifetime of a mapping to be reduced or a > > mapping to be deleted. > > > > I understand that reducing the lifetime of mappings is useful, and > > think > > that many deployments that implement a security mechanism (and thus > > fall under the advanced threat model) will choose to have a relaxed > > authorization policy about deleting mappings. > > I think the mapping nonce changes introduced in pcp-base-27 will help > > make that possible. > > > > However, for the simple threat model our goal is not to decrease the > > security of the Internet by deploying a PCP server. > > We fail to accomplish that. > > > > Here's an example of an attack where enabling PCP decreases the > > security > > of a network. > > > > N1 is a NAT with PCP capability. > > > > N2 is a NAT without PCP capability. > > > > H1 and H2 are hosts behind N2.; N2 is behind N1. > > That is, the path from H1 or H2 to the Internet looks like > > {H1,H2}->N2->N1. > > > > > From the standpoint of N1, H1 and H2 have the same internal address. > > That permits H1 and H2 to create mappings on each others' behalf. > > However, H1 and H2 cannot spoof each others' IP addresses from the > > standpoint of N2. For example, H1 and H2 might be on different internal > > subnets or address spoofing prevention may be in use. > > > > H1 is a host that either does not support PCP or follows the spec > > recommendation not to use PCP through a NAT that does not support PCP. > > > > H2 would like to capture H1's traffic. > > H2 guesses that some traffic will be sent from H1 towards x. H2 > > guesses that port P will be used as the external port on N2 (the > > internal port from N1's standpoint). > > So, N1 will see traffic from towards x. > > Before H1 sends this traffic, H2 requests a PCP mapping for ; it > > could use either the map or peer opcode. > > This traffic is mapped to appear to come from . > > > > Later, H2 wants to capture the reply traffic; because H2 created the > > mapping, H2 knows the mapping nonce and can delete the mapping. > > > > Now, H2 needs to convince N1 to allocate Q such that traffic to > > will eventually make its way to H2. > > That depends on attacking N1's port allocation algorithm. This is > > probably not an attack H2 can mount with 100% chance of success. > > However by using multiple mappings to amplify the attack, trying to > > exploit any races in N1, etc. > > This is the kind of attack that looks hard until someone has it > > working, > > then becomes very easy. > > > > If N1 disables PCP, the attack is impossible if H1 sends traffic often > > enough to keep the mapping alive. > > This is just one attack I found while not looking very hard. > > I don't have time to perform detailed security analysis on this change, > > but I have fairly high confidence that it does introduce harm. I > > suspect > > that if we look we'll find other attacks. > > > > If I end up in the rough within the working group and we send this > > change to the IESG, I believe a new IETF last call is > > required. Typically a protocol like PCP would be required to have a > > mandatory-to-implement security mechanism according to BCP 61. We have > > tried to strike a compromise to permit PCP to move forward more quickly > > than the security mechanism work. Many people have reviewed PCP; this > > has been discussed widely in the security community and elsewhere. If > > the working group is going to change this compromise after IESG review, > > the IETF needs to be given a change to re-review and to suggest > > balancing changes and debate questions like whether PCP should be > > required to have a BCP 61 security mechanism. >=20 >=20 > Thanks for describing this attack. >=20 > Given the same scenario -- namely, a victim not using PCP and an attacker > using PCP -- how would PCP authentication prevent the attack? The only > way I see is if the attacker lacks authorization to create mappings or la= cks > authorization to delete mappings. >=20 >=20 > I have enumerated the mitigations discussed so far and provided > my analysis of each. I hopes will foster further technical > discussion: >=20 > a. Require PCP authentication. >=20 > Requires attacker to lack authorization to create a mapping or > lack authorization to delete a mapping. >=20 > Analysis: May not be useful for preventing such an attack on > CGN, because PCP authentication is likely rare for CGN > deployments, according to REQ-9-D of > draft-ietf-behave-lsn-requirements. >=20 >=20 > b. Prohibit reducing lifetime of a mapping. >=20 > That is, revert to draft-pcp-base-26. >=20 > Analysis: Prevents the described attack. However, this can > create a denial of service for a normal PCP that is making a > bunch of PCP mappings -- the PCP client can consume all of its > mappings with no way to remove them. This harms successful > use of PCP. We can mitigate this harm by strongly suggesting > large port quotas, allowing un-acknowledged TCP RST to > shortcut this prohibition, or separate suggesting separate > port quota space for PCP-created mappings and implicit > mappings (so PCP cannot consume all of the port quota). >=20 > Note: the specific text in the Security Considerations of > pcp-base-26, which has been there for many versions, only > prohibited shortening PEER mappings. Based on the > description of the attack above and the text in REQ-9 of > draft-ietf-behave-lsn-requirements, draft-ietf-pcp-base > needs to worry about both MAP and PEER mappings. >=20 >=20 > c. Prevent same internal host from acquiring same external port. >=20 > After a port is mapped using PCP, prevent the same internal IP > address from remapping that same external port to a different > internal port for a period of time. Allow a different internal > IP address to map that same external port. >=20 > Analysis: Prevents the described attack. This solution is > superior to (b), because it does not harm the user's port quota. > After the PCP client issues a Delete, the port can be allocated > to a different internal host. An attacking host would need a > more sophisticated attack, specifically it would need to > coordinate with another attacking host behind the same PCP- > speaking NAT (that is, the two attacking hosts would need to be > in different NATted homes and both homes are behind the same > PCP-speaking CGN). >=20 >=20 > d. Do not immediately delete mappings created by MAP or PEER. >=20 > Instead, only allow the lifetime to be reduced to a few minutes. > For TCP, suggested value RFC5382's "transitory connection idle- > timeout" of 4 minutes; for UDP, RFC4787's 2 minutes. >=20 > Analysis: Forces attacker to wait longer before the attacker can > re-map the port to themselves. Attack will fail if victim host > sends traffic during the 4 (TCP) or 2 (UDP) minutes. >=20 > -d >=20 >=20 From iesg-secretary@ietf.org Mon Oct 1 11:19:19 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4911F0D31; Mon, 1 Oct 2012 11:19: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=[AWL=0.000, BAYES_00=-2.599, 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 uIt40b0Esvuj; Mon, 1 Oct 2012 11:19:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDD01F0D17; Mon, 1 Oct 2012 11:19:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121001181919.9952.96922.idtracker@ietfa.amsl.com> Date: Mon, 01 Oct 2012 11:19:19 -0700 Cc: pcp@ietf.org Subject: [pcp] PCP WG Virtual Interim Meeting, Wednesday, October 17, 2012 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, 01 Oct 2012 18:19:19 -0000 The PCP Working Group will hold a virtual interim meeting on Wednesday, = October 17, 2012, at 7AM PDT, using WebEx. Agenda and dial-in information will be posted at: = http://tools.ietf.org/wg/pcp/trac/wiki From internet-drafts@ietf.org Tue Oct 2 17:42:42 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CBA21F85F9; Tue, 2 Oct 2012 17:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, 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 4dAEmhTA1K5L; Tue, 2 Oct 2012 17:42:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA7421F8602; Tue, 2 Oct 2012 17:42:41 -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.34 Message-ID: <20121003004241.26140.96564.idtracker@ietfa.amsl.com> Date: Tue, 02 Oct 2012 17:42:41 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-base-28.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, 03 Oct 2012 00:42: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 : Port Control Protocol (PCP) Author(s) : Dan Wing Stuart Cheshire Mohamed Boucadair Reinaldo Penno Paul Selkirk Filename : draft-ietf-pcp-base-28.txt Pages : 108 Date : 2012-10-02 Abstract: The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-base There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-base-28 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-base-28 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dwing@cisco.com Tue Oct 2 17:44: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 2896721F855B for ; Tue, 2 Oct 2012 17:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.587 X-Spam-Level: X-Spam-Status: No, score=-110.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 cvlxehn7le2q for ; Tue, 2 Oct 2012 17:44:09 -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 853FF21F861E for ; Tue, 2 Oct 2012 17:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=898; q=dns/txt; s=iport; t=1349225048; x=1350434648; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=YrYomJMOkJtOTkoecrYLM07OHlPAfwBGql/dMGtCpdI=; b=UIBOzd51EK9tBhvDsk3E+kyKfQevoaaGa/rvsQ/KaGXfh+08ylx9dtfR sieV9U33L3Zbw2GApe/UNfn6CgdYQ8cFFvy5+sj6KUQYCbHcsdo9xaHYC oMwt1tM4syFzqwD0sZWt9ZY461VCLnxL6X9j0lNtZkfYoG32/aYdDjAEJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicKABuJa1CrRDoG/2dsb2JhbABFrkuPEAOBD4EIgicICgEXEEwFGFAjHAEEHheHYpZegSiPVpBHizhzghKDIAOIWIURlkKBaYMHgTsBIw X-IronPort-AV: E=Sophos;i="4.80,525,1344211200"; d="scan'208";a="57693795" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 03 Oct 2012 00:44:08 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q930i8jh032634 for ; Wed, 3 Oct 2012 00:44:08 GMT From: "Dan Wing" To: Date: Tue, 2 Oct 2012 17:44:06 -0700 Message-ID: <081901cda100$32261180$96723480$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2hADFahXx77J8NRDuM/iRceyYQZw== Content-Language: en-us Subject: [pcp] pcp-base-28 posted 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, 03 Oct 2012 00:44:10 -0000 I received little feedback from the working group, so made the edits that I felt reasonable and helpful for the protocol. Please discuss the changes, decide if they are appropriate, and post to the list. Summary of changes are: o When processing MAP request or processing PEER request, Mapping Nonce validation only applies to Basic Threat Model, and not to THIRD_PARTY. o A maximum payload size of 1100 keeps PCP packets below IPv6's 1280 MTU limit while still allowing some room for encapsulation. This accomodates EAP over PANA over PCP (EAP needs 1020 octets, per RFC3748), should PCP authentication decide to use EAP over PANA over PCP. o Both MAP and PEER-created mappings cannot have their lifetimes reduced beyond normal UDP/TCP timesouts. o Disallow re-assigning External Port to same internal host. -d From simon.perreault@viagenie.ca Wed Oct 3 06:05:51 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC4121F84C5 for ; Wed, 3 Oct 2012 06:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-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 vSdXn0Hei+Sw for ; Wed, 3 Oct 2012 06:05:51 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD8721F84C8 for ; Wed, 3 Oct 2012 06:05:51 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:9dcb:5c32:7b37:b414]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 73035414AE for ; Wed, 3 Oct 2012 09:05:50 -0400 (EDT) Message-ID: <506C382D.50502@viagenie.ca> Date: Wed, 03 Oct 2012 09:05:49 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: pcp@ietf.org References: <081901cda100$32261180$96723480$@com> In-Reply-To: <081901cda100$32261180$96723480$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] pcp-base-28 posted 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, 03 Oct 2012 13:05:51 -0000 Looks good. In particular the two last items eliminate the possibility of attack that Sam identified. Simon Le 2012-10-02 20:44, Dan Wing a écrit : > I received little feedback from the working group, so made the edits that I > felt reasonable and helpful for the protocol. Please discuss the changes, > decide if they are appropriate, and post to the list. > > Summary of changes are: > o When processing MAP request or processing PEER request, Mapping > Nonce validation only applies to Basic Threat Model, and not to > THIRD_PARTY. > > o A maximum payload size of 1100 keeps PCP packets below IPv6's 1280 > MTU limit while still allowing some room for encapsulation. This > accomodates EAP over PANA over PCP (EAP needs 1020 octets, per > RFC3748), should PCP authentication decide to use EAP over PANA > over PCP. > > o Both MAP and PEER-created mappings cannot have their lifetimes > reduced beyond normal UDP/TCP timesouts. > > o Disallow re-assigning External Port to same internal host. > > -d > > > _______________________________________________ > 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 yoshihiro.ohba@toshiba.co.jp Thu Oct 4 20:03:34 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA25621F845E for ; Thu, 4 Oct 2012 20:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.126 X-Spam-Level: X-Spam-Status: No, score=-7.126 tagged_above=-999 required=5 tests=[AWL=0.964, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, 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 SH85JwXSAQ1s for ; Thu, 4 Oct 2012 20:03:34 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 1178B21F842C for ; Thu, 4 Oct 2012 20:03:33 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q9533Wbv009774 for ; Fri, 5 Oct 2012 12:03:32 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q9533WB9015297 for pcp@ietf.org; Fri, 5 Oct 2012 12:03:32 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id NAA15296; Fri, 5 Oct 2012 12:03:32 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q9533V7d021848 for ; Fri, 5 Oct 2012 12:03:32 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q9533VIT005922; Fri, 5 Oct 2012 12:03:31 +0900 (JST) Received: from [133.196.20.203] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MBE006R3GHV3JG0@mail.po.toshiba.co.jp> for pcp@ietf.org; Fri, 05 Oct 2012 12:03:31 +0900 (JST) Date: Fri, 05 Oct 2012 12:03:35 +0900 From: Yoshihiro Ohba To: pcp@ietf.org Message-id: <506E4E07.3000807@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Subject: [pcp] Capability discovery 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, 05 Oct 2012 03:03:34 -0000 There has been a question on what to do when PCP client supports PCP authentication while PCP server does not, and vise versa. The same issue will exist for future PCP extensions. I would like to hear opinions whether defining a capability discovery exchange in PCP base specification ever makes sense, where the capability discovery exchange is expected to happen prior to any other PCP opcodes. Best Regards, Yoshihiro Ohba From yoshihiro.ohba@toshiba.co.jp Thu Oct 4 20:18:13 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE44A11E8091 for ; Thu, 4 Oct 2012 20:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.246 X-Spam-Level: X-Spam-Status: No, score=-7.246 tagged_above=-999 required=5 tests=[AWL=0.843, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, 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 YnpXemQhfQ+T for ; Thu, 4 Oct 2012 20:18:13 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 227B411E809B for ; Thu, 4 Oct 2012 20:18:13 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q953IA47014285 for ; Fri, 5 Oct 2012 12:18:10 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q953IAgU024322 for pcp@ietf.org; Fri, 5 Oct 2012 12:18:10 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id NAA24319; Fri, 5 Oct 2012 12:18:10 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q953I9tj027449 for ; Fri, 5 Oct 2012 12:18:09 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q953I9xl007323; Fri, 5 Oct 2012 12:18:09 +0900 (JST) Received: from [133.196.20.203] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MBE0061EH693JH0@mail.po.toshiba.co.jp> for pcp@ietf.org; Fri, 05 Oct 2012 12:18:09 +0900 (JST) Date: Fri, 05 Oct 2012 12:18:13 +0900 From: Yoshihiro Ohba To: pcp@ietf.org Message-id: <506E5175.3020802@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Subject: [pcp] Revising PANA side-by-side approach 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, 05 Oct 2012 03:18:13 -0000 Since PCP Version 0 is used by draft-cheshire-nat-pmp, I plan to revise PANA side-by-side approach I-D (draft-ohba-pcp-pana) to use Bit 0 instead of Bits 5-6-7. The new logic is that when bit 0 is 1 it's PANA, otherwise it's PCP and alike. If there is an issue with the new logic, please let me know. I also plan to submit PANA encasulation approach as a separate I-D before the next interim meeting. Regards, Yoshihiro Ohba From mohamed.boucadair@orange.com Thu Oct 4 22:56: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 A4CB821F869C for ; Thu, 4 Oct 2012 22:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 etUmlCHJGcVu for ; Thu, 4 Oct 2012 22:56:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 59EB421F869F for ; Thu, 4 Oct 2012 22:56:57 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id B21E022C227; Fri, 5 Oct 2012 07:56:56 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 98446238056; Fri, 5 Oct 2012 07:56:56 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 5 Oct 2012 07:56:56 +0200 From: To: Yoshihiro Ohba , "pcp@ietf.org" Date: Fri, 5 Oct 2012 07:56:55 +0200 Thread-Topic: [pcp] Capability discovery Thread-Index: Ac2ipgQ9TMqmFrUURvCzP+mrrjyOUQAFr2vA Message-ID: <94C682931C08B048B7A8645303FDC9F36E5F75BE63@PUEXCB1B.nanterre.francetelecom.fr> References: <506E4E07.3000807@toshiba.co.jp> In-Reply-To: <506E4E07.3000807@toshiba.co.jp> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Subject: Re: [pcp] Capability discovery 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, 05 Oct 2012 05:56:59 -0000 Dear Yoshihiro, FYI, this document proposes an option to retrieve the capabilities of the P= CP-controlled device: http://tools.ietf.org/html/draft-boucadair-pcp-capability-00 The current version does only describe whether the controlled device is NAT= 44, NAT46, NAT64, IPv4 FW, IPv6 FW, Port Range Router.=20 This feature is defined as an option but can be elected to be defined as st= andalone OpCode. The capabilities set format can be modified to support new= capabilities: e.g., authentication support, list of supported opcodes, etc= .=20 Saying that, IMHO we need further analyze what are the gains and the impact= s on the PCP server to support such feature: * Is it reducing exchanged messages?=20 * Does it harm if we try an opcode no matter if the PCP server supports it = or not? * Reduce delay before establishing a session? * Be a trigger to decide whether all available PCP Servers need to be conta= cted in // or select only one? Cheers, Med >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Yoshihiro Ohba >Envoy=E9 : vendredi 5 octobre 2012 05:04 >=C0 : pcp@ietf.org >Objet : [pcp] Capability discovery > >There has been a question on what to do when PCP client supports PCP >authentication >while PCP server does not, and vise versa. The same issue will=20 >exist for >future PCP extensions. > >I would like to hear opinions whether defining a capability discovery >exchange >in PCP base specification ever makes sense, where the capability >discovery exchange is >expected to happen prior to any other PCP opcodes. > >Best Regards, >Yoshihiro Ohba > > > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp >= From yoshihiro.ohba@toshiba.co.jp Thu Oct 4 23:57:24 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 729A621F85A2 for ; Thu, 4 Oct 2012 23:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.34 X-Spam-Level: X-Spam-Status: No, score=-5.34 tagged_above=-999 required=5 tests=[AWL=-1.251, 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 4BAjebdgIwu6 for ; Thu, 4 Oct 2012 23:57:23 -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 9646821F85A4 for ; Thu, 4 Oct 2012 23:57:23 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q956vMnK019875; Fri, 5 Oct 2012 15:57:22 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q956vLVt004332; Fri, 5 Oct 2012 15:57:21 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id RAA04331; Fri, 5 Oct 2012 15:57:21 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q956vL28016633; Fri, 5 Oct 2012 15:57:21 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q956vLre024221; Fri, 5 Oct 2012 15:57:21 +0900 (JST) Received: from [133.196.20.203] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MBE0067HRBL3KM0@mail.po.toshiba.co.jp>; Fri, 05 Oct 2012 15:57:21 +0900 (JST) Date: Fri, 05 Oct 2012 15:57:25 +0900 From: Yoshihiro Ohba In-reply-to: <94C682931C08B048B7A8645303FDC9F36E5F75BE63@PUEXCB1B.nanterre.francetelecom.fr> To: mohamed.boucadair@orange.com Message-id: <506E84D5.2050502@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT References: <506E4E07.3000807@toshiba.co.jp> <94C682931C08B048B7A8645303FDC9F36E5F75BE63@PUEXCB1B.nanterre.francetelecom.fr> 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] Capability discovery 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, 05 Oct 2012 06:57:24 -0000 So there are two ways for capability discovery: - Use a PCP Opcode - Use a PCP Option If the WG has not decided which way to use for capability discovery, I would have to mention the two ways in the two PANA I-Ds I am working on. Is this OK? Yoshihiro Ohba (2012/10/05 14:56), mohamed.boucadair@orange.com wrote: > Dear Yoshihiro, > > FYI, this document proposes an option to retrieve the capabilities of the PCP-controlled device: > http://tools.ietf.org/html/draft-boucadair-pcp-capability-00 > > The current version does only describe whether the controlled device is NAT44, NAT46, NAT64, IPv4 FW, IPv6 FW, Port Range Router. > > This feature is defined as an option but can be elected to be defined as standalone OpCode. The capabilities set format can be modified to support new capabilities: e.g., authentication support, list of supported opcodes, etc. > > Saying that, IMHO we need further analyze what are the gains and the impacts on the PCP server to support such feature: > > * Is it reducing exchanged messages? > * Does it harm if we try an opcode no matter if the PCP server supports it or not? > * Reduce delay before establishing a session? > * Be a trigger to decide whether all available PCP Servers need to be contacted in // or select only one? > > > Cheers, > Med > >> -----Message d'origine----- >> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la >> part de Yoshihiro Ohba >> Envoyé : vendredi 5 octobre 2012 05:04 >> À : pcp@ietf.org >> Objet : [pcp] Capability discovery >> >> There has been a question on what to do when PCP client supports PCP >> authentication >> while PCP server does not, and vise versa. The same issue will >> exist for >> future PCP extensions. >> >> I would like to hear opinions whether defining a capability discovery >> exchange >> in PCP base specification ever makes sense, where the capability >> discovery exchange is >> expected to happen prior to any other PCP opcodes. >> >> Best Regards, >> Yoshihiro Ohba >> >> >> >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >> From mohamed.boucadair@orange.com Fri Oct 5 00:41:21 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 2145321F8609 for ; Fri, 5 Oct 2012 00:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 p1g48o2vlO7l for ; Fri, 5 Oct 2012 00:41:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 461C221F8604 for ; Fri, 5 Oct 2012 00:41:15 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 5D0163B40EF; Fri, 5 Oct 2012 09:41:14 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 42A244C015; Fri, 5 Oct 2012 09:41:14 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Fri, 5 Oct 2012 09:41:14 +0200 From: To: Yoshihiro Ohba Date: Fri, 5 Oct 2012 09:41:12 +0200 Thread-Topic: [pcp] Capability discovery Thread-Index: Ac2ixq+uyPFYOtP+QHONbMpSxrqSAwABSpBw Message-ID: <94C682931C08B048B7A8645303FDC9F36E5F75BF6B@PUEXCB1B.nanterre.francetelecom.fr> References: <506E4E07.3000807@toshiba.co.jp> <94C682931C08B048B7A8645303FDC9F36E5F75BE63@PUEXCB1B.nanterre.francetelecom.fr> <506E84D5.2050502@toshiba.co.jp> In-Reply-To: <506E84D5.2050502@toshiba.co.jp> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: "pcp@ietf.org" Subject: Re: [pcp] Capability discovery 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, 05 Oct 2012 07:41:21 -0000 Re-, Mentioning the two ways is OK. Still the main point is to assess the benefits of this option/Opcode. If in= your draft you can discuss how it can be useful for the authentication cas= e, this would be a good input. Cheers, Med=20 >-----Message d'origine----- >De : Yoshihiro Ohba [mailto:yoshihiro.ohba@toshiba.co.jp]=20 >Envoy=E9 : vendredi 5 octobre 2012 08:57 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : pcp@ietf.org >Objet : Re: [pcp] Capability discovery > >So there are two ways for capability discovery: > >- Use a PCP Opcode >- Use a PCP Option > >If the WG has not decided which way to use for capability discovery, >I would have to mention the two ways in the two PANA I-Ds I am=20 >working on. > >Is this OK? > >Yoshihiro Ohba > >(2012/10/05 14:56), mohamed.boucadair@orange.com wrote: >> Dear Yoshihiro, >> >> FYI, this document proposes an option to retrieve the=20 >capabilities of the PCP-controlled device: >> http://tools.ietf.org/html/draft-boucadair-pcp-capability-00 >> >> The current version does only describe whether the=20 >controlled device is NAT44, NAT46, NAT64, IPv4 FW, IPv6 FW,=20 >Port Range Router. >> >> This feature is defined as an option but can be elected to=20 >be defined as standalone OpCode. The capabilities set format=20 >can be modified to support new capabilities: e.g.,=20 >authentication support, list of supported opcodes, etc. >> >> Saying that, IMHO we need further analyze what are the gains=20 >and the impacts on the PCP server to support such feature: >> >> * Is it reducing exchanged messages? >> * Does it harm if we try an opcode no matter if the PCP=20 >server supports it or not? >> * Reduce delay before establishing a session? >> * Be a trigger to decide whether all available PCP Servers=20 >need to be contacted in // or select only one? >> >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la >>> part de Yoshihiro Ohba >>> Envoy=E9 : vendredi 5 octobre 2012 05:04 >>> =C0 : pcp@ietf.org >>> Objet : [pcp] Capability discovery >>> >>> There has been a question on what to do when PCP client supports PCP >>> authentication >>> while PCP server does not, and vise versa. The same issue will >>> exist for >>> future PCP extensions. >>> >>> I would like to hear opinions whether defining a capability=20 >discovery >>> exchange >>> in PCP base specification ever makes sense, where the capability >>> discovery exchange is >>> expected to happen prior to any other PCP opcodes. >>> >>> Best Regards, >>> Yoshihiro Ohba >>> >>> >>> >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >>> > >= From margaretw42@gmail.com Fri Oct 5 06:07: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 658A621F871C for ; Fri, 5 Oct 2012 06:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTUNOOF4trCJ for ; Fri, 5 Oct 2012 06:07:56 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B8B7A21F872E for ; Fri, 5 Oct 2012 06:07:56 -0700 (PDT) Received: by mail-gg0-f172.google.com with SMTP id i4so445594ggn.31 for ; Fri, 05 Oct 2012 06:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=TKWy+iqtXiRelxMM0vibuumEYeEBkXHOD7XpiX6u8hE=; b=jZFlPZoQiYFsADTZ8oBHBCSInW7pKlOLNOW/nheGpAuZOZK6g82vgKNCqvaZVHBZRI JuLzWtJnWE3L/imWPhKDcdlGGOJesqT75OH6azoiwWA4EFGWj8HCbn1rX+RyPcZivB4G GDpqJnsCxHx5Lv3JP9Fi8UZl8vEGSGkMrbdP84IlZ5dbSxC78MgPbPwojg3Q+n2DFvNo jML7jXrDsLqFR6QuVvP8/bwKjmXyDyb0VnCyzAOED53qqUwAFXa6xGCDrZEhgbs0hLs2 q9R7SlKU8A4/s8RqP+3Ygo3gquLxfZFEpd1+iAJasNYi55zrtqUtjPSjQGgPiaOwZTDq qgBA== Received: by 10.100.78.6 with SMTP id a6mr191468anb.80.1349442476255; Fri, 05 Oct 2012 06:07:56 -0700 (PDT) Received: from [192.168.11.122] ([97.67.164.9]) by mx.google.com with ESMTPS id f15sm9627519anm.9.2012.10.05.06.07.52 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 06:07:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <506E5175.3020802@toshiba.co.jp> Date: Fri, 5 Oct 2012 09:07:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <712CABEE-96A2-493A-B2F8-94BC2548E0FD@lilacglade.org> References: <506E5175.3020802@toshiba.co.jp> To: Yoshihiro Ohba X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Revising PANA side-by-side approach 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, 05 Oct 2012 13:07:57 -0000 Hi Yoshi, The concern that I have with this approach is that it seems short-sited = to me... If we expect PANA to be used as a generic authentication mechanism, = rather than being used specifically for network access authentication, I = think we need to do two things: 1) Provide a clear explanation of what parts of PANA will be used with = PCP. For example, the notion of a network access enforcement point = doesn't really make sense in a PCP context.=20 2) Describe a clean mechanism that allows PANA to be used for = authentication of other protocols. Overloading a single bit in the PCP version field, because it happens to = coincide with a flag bit in PANA doesn't seem like a method that will = work for other protocols, and I am concerned that it doesn't provide a = clean basis for moving forward. Margaret On Oct 4, 2012, at 11:18 PM, Yoshihiro Ohba wrote: > Since PCP Version 0 is used by draft-cheshire-nat-pmp, I plan to > revise PANA side-by-side approach I-D (draft-ohba-pcp-pana) to use > Bit 0 instead of Bits 5-6-7. The new logic is that when bit 0 is 1 = it's > PANA, > otherwise it's PCP and alike. If there is an issue with the new logic, > please let me know. >=20 > I also plan to submit PANA encasulation approach as a separate I-D > before the next interim meeting. >=20 > Regards, > Yoshihiro Ohba >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From dwing@cisco.com Fri Oct 5 06:56: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 61DD221F86F4 for ; Fri, 5 Oct 2012 06:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.587 X-Spam-Level: X-Spam-Status: No, score=-110.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 TwPYkwavYMlk for ; Fri, 5 Oct 2012 06:56:58 -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 CB6CC21F86EC for ; Fri, 5 Oct 2012 06:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1243; q=dns/txt; s=iport; t=1349445418; x=1350655018; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=vdx4fg141qyaYhphf1vsUwGS3ScPX0lfQx7Z38DhtRc=; b=Tsnrgf3mRZ6p6tdOQW8oQN+Cg5eNdTouJvGBjjnsXG8S9F47/x1Ga8mr b/9bNPSHVTKth1tGmMeozvsUpoAwljSi0K92ibarDeyCkYdULQhdaRFjb 97jZkPtUtrKbj22hQgTc15lNUm6b5MOLnsoaQBjs9XPJ6+PnuvkJLCEf9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJHmblCrRDoH/2dsb2JhbABFrwGQHoEIgiABAQEDAQEBAQUKARcQNBAHAQMCCQ8CBAEBKAcZDhUKCQgBAQQBEgsXh10FDJgVoAgEiz6GCQOIWIURlkeBaYMN X-IronPort-AV: E=Sophos;i="4.80,541,1344211200"; d="scan'208";a="57955405" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 05 Oct 2012 13:56:58 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q95Duwdb025863; Fri, 5 Oct 2012 13:56:58 GMT From: "Dan Wing" To: "'Yoshihiro Ohba'" , References: <506E4E07.3000807@toshiba.co.jp> In-Reply-To: <506E4E07.3000807@toshiba.co.jp> Date: Fri, 5 Oct 2012 06:56:58 -0700 Message-ID: <034101cda301$4972d690$dc5883b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2ipgN2df1pB4eXRlqF02782B4YzQAWtDJA Content-Language: en-us Subject: Re: [pcp] Capability discovery 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, 05 Oct 2012 13:56:59 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Yoshihiro Ohba > Sent: Thursday, October 04, 2012 8:04 PM > To: pcp@ietf.org > Subject: [pcp] Capability discovery > > There has been a question on what to do when PCP client supports PCP > authentication > while PCP server does not, and vise versa. Yes, that problem needs to be solved. > The same issue will exist for future PCP extensions. I disagree that problem exists for PCP extensions. The client can simply try to use the extension, and will either get back an error (e.g., UNSUPP_OPCODE or UNSUPP_OPTION error), or the option will not be included in the response (for options outside the mandatory- to-process range). > I would like to hear opinions whether defining a capability discovery > exchange > in PCP base specification ever makes sense, where the capability > discovery exchange is > expected to happen prior to any other PCP opcodes. I have not found that capability discovery is necessary. -d > Best Regards, > Yoshihiro Ohba > > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From yoshihiro.ohba@toshiba.co.jp Fri Oct 5 07:37:25 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 D1D2521F8762 for ; Fri, 5 Oct 2012 07:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.077 X-Spam-Level: X-Spam-Status: No, score=-5.077 tagged_above=-999 required=5 tests=[AWL=-0.988, 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 C3Lfmsh3R5CH for ; Fri, 5 Oct 2012 07:37:25 -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 1B04E21F8747 for ; Fri, 5 Oct 2012 07:37:24 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q95EbMp6013984; Fri, 5 Oct 2012 23:37:22 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q95EbMmi007920; Fri, 5 Oct 2012 23:37:22 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id ZAA07919; Fri, 5 Oct 2012 23:37:22 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q95EbMjf000742; Fri, 5 Oct 2012 23:37:22 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q95EbMh4008521; Fri, 5 Oct 2012 23:37:22 +0900 (JST) Received: from [133.199.16.47] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MBF00CE4CLYIU40@mail.po.toshiba.co.jp>; Fri, 05 Oct 2012 23:37:22 +0900 (JST) Date: Fri, 05 Oct 2012 23:37:13 +0900 From: Yoshihiro Ohba In-reply-to: <712CABEE-96A2-493A-B2F8-94BC2548E0FD@lilacglade.org> To: Margaret Wasserman Message-id: <506EF099.3030503@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <506E5175.3020802@toshiba.co.jp> <712CABEE-96A2-493A-B2F8-94BC2548E0FD@lilacglade.org> 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] Revising PANA side-by-side approach 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, 05 Oct 2012 14:37:25 -0000 Hi Margaret, (2012/10/05 22:07), Margaret Wasserman wrote: > Hi Yoshi, > > The concern that I have with this approach is that it seems short-sited to me... > > If we expect PANA to be used as a generic authentication mechanism, rather than being used specifically for network access authentication, I think we need to do two things: > > 1) Provide a clear explanation of what parts of PANA will be used with PCP. For example, the notion of a network access enforcement point doesn't really make sense in a PCP context. I agree that EP is not needed in the context of PCP authentication. We probably do not need to use 'I' (IP Reconfiguration) and 'P' (Ping) flags either. > > 2) Describe a clean mechanism that allows PANA to be used for authentication of other protocols. > > Overloading a single bit in the PCP version field, because it happens to coincide with a flag bit in PANA doesn't seem like a method that will work for other protocols, and I am concerned that it doesn't provide a clean basis for moving forward. The single bit use is specific to PCP. If some other protocol operating over port X wants to multiplex PANA, then a different set of bits may be used for port X. I would like to hear from you if there is a cleaner way. Yoshihiro Ohba > Margaret > > > On Oct 4, 2012, at 11:18 PM, Yoshihiro Ohba wrote: > >> Since PCP Version 0 is used by draft-cheshire-nat-pmp, I plan to >> revise PANA side-by-side approach I-D (draft-ohba-pcp-pana) to use >> Bit 0 instead of Bits 5-6-7. The new logic is that when bit 0 is 1 it's >> PANA, >> otherwise it's PCP and alike. If there is an issue with the new logic, >> please let me know. >> >> I also plan to submit PANA encasulation approach as a separate I-D >> before the next interim meeting. >> >> Regards, >> Yoshihiro Ohba >> >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp > From yoshihiro.ohba@toshiba.co.jp Fri Oct 5 08:14:29 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 E4BC821F869E for ; Fri, 5 Oct 2012 08:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.015 X-Spam-Level: X-Spam-Status: No, score=-7.015 tagged_above=-999 required=5 tests=[AWL=1.074, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, 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 AGfA9vg5bes5 for ; Fri, 5 Oct 2012 08:14:29 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id C93A321F869C for ; Fri, 5 Oct 2012 08:14:28 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q95FEPtD027105; Sat, 6 Oct 2012 00:14:25 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q95FEPVV010653; Sat, 6 Oct 2012 00:14:25 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id AAA10652; Sat, 6 Oct 2012 00:14:25 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q95FEPKY025858; Sat, 6 Oct 2012 00:14:25 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q95FEPcx020522; Sat, 6 Oct 2012 00:14:25 +0900 (JST) Received: from [133.199.16.47] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MBF00CLBEBPIV50@mail.po.toshiba.co.jp>; Sat, 06 Oct 2012 00:14:25 +0900 (JST) Date: Sat, 06 Oct 2012 00:14:16 +0900 From: Yoshihiro Ohba In-reply-to: <034101cda301$4972d690$dc5883b0$@com> To: Dan Wing Message-id: <506EF948.40303@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <506E4E07.3000807@toshiba.co.jp> <034101cda301$4972d690$dc5883b0$@com> 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] Capability discovery 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, 05 Oct 2012 15:14:30 -0000 (2012/10/05 22:56), Dan Wing wrote: >> -----Original Message----- >> From:pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of >> Yoshihiro Ohba >> Sent: Thursday, October 04, 2012 8:04 PM >> To:pcp@ietf.org >> Subject: [pcp] Capability discovery >> >> There has been a question on what to do when PCP client supports PCP >> authentication >> while PCP server does not, and vise versa. > Yes, that problem needs to be solved. > >> The same issue will exist for future PCP extensions. > I disagree that problem exists for PCP extensions. The client can > simply try to use the extension, and will either get back an error > (e.g., UNSUPP_OPCODE or UNSUPP_OPTION error), or the option will > not be included in the response (for options outside the mandatory- > to-process range). In that case, the problem is specific to side-by-side PANA approach which does not use PCP opcode/options. Is this correct? Yoshihiro Ohba >> I would like to hear opinions whether defining a capability discovery >> exchange >> in PCP base specification ever makes sense, where the capability >> discovery exchange is >> expected to happen prior to any other PCP opcodes. > I have not found that capability discovery is necessary. > > -d > > > >> Best Regards, >> Yoshihiro Ohba >> >> >> >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp From dthaler@microsoft.com Fri Oct 5 10:42: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 D71E921F87C1 for ; Fri, 5 Oct 2012 10:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.482 X-Spam-Level: X-Spam-Status: No, score=-105.482 tagged_above=-999 required=5 tests=[AWL=1.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 LKU9oMT377Gn for ; Fri, 5 Oct 2012 10:42:12 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 41F9A21F87B3 for ; Fri, 5 Oct 2012 10:42:12 -0700 (PDT) Received: from mail209-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 5 Oct 2012 17:42:11 +0000 Received: from mail209-va3 (localhost [127.0.0.1]) by mail209-va3-R.bigfish.com (Postfix) with ESMTP id 073E564013B; Fri, 5 Oct 2012 17:42:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VS-29(zzbb2dI98dI9371I542M1432Izz1202h1d1ah1d2ahzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received-SPF: pass (mail209-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail209-va3 (localhost.localdomain [127.0.0.1]) by mail209-va3 (MessageSwitch) id 1349458928965862_1047; Fri, 5 Oct 2012 17:42:08 +0000 (UTC) Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.241]) by mail209-va3.bigfish.com (Postfix) with ESMTP id E7738C80062; Fri, 5 Oct 2012 17:42:08 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 5 Oct 2012 17:42:08 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.318.3; Fri, 5 Oct 2012 17:42:08 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.114]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0318.003; Fri, 5 Oct 2012 10:42:07 -0700 From: Dave Thaler To: Yoshihiro Ohba , Dan Wing Thread-Topic: [pcp] Capability discovery Thread-Index: AQHNoqYGedw27p7IoES7IkeY9rafx5erMp4AgAAVmQD//7O2sA== Date: Fri, 5 Oct 2012 17:42:07 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B8101A7@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <506E4E07.3000807@toshiba.co.jp> <034101cda301$4972d690$dc5883b0$@com> <506EF948.40303@toshiba.co.jp> In-Reply-To: <506EF948.40303@toshiba.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "pcp@ietf.org" Subject: Re: [pcp] Capability discovery 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, 05 Oct 2012 17:42:13 -0000 Yoshihiro Ohba writes:=20 > (2012/10/05 22:56), Dan Wing wrote: > >> -----Original Message----- > >> From:pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > >> Yoshihiro Ohba > >> Sent: Thursday, October 04, 2012 8:04 PM To:pcp@ietf.org > >> Subject: [pcp] Capability discovery > >> > >> There has been a question on what to do when PCP client supports PCP > >> authentication while PCP server does not, and vise versa. > > Yes, that problem needs to be solved. > > > >> The same issue will exist for future PCP extensions. > > I disagree that problem exists for PCP extensions. The client can > > simply try to use the extension, and will either get back an error > > (e.g., UNSUPP_OPCODE or UNSUPP_OPTION error), or the option will > > not be included in the response (for options outside the mandatory- > > to-process range). >=20 > In that case, the problem is specific to side-by-side PANA approach > which does not use PCP opcode/options. Is this correct? Yes, I believe that's correct. -Dave=20 From alper.yegin@yegin.org Fri Oct 5 13:23:24 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 792D421F842D for ; Fri, 5 Oct 2012 13:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, 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 ucNkOtxNFqiR for ; Fri, 5 Oct 2012 13:23:24 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id DAE3F21F8667 for ; Fri, 5 Oct 2012 13:23:23 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MC4Ay-1TBSz50sLo-009GR7; Fri, 05 Oct 2012 16:23:22 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B8101A7@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Fri, 5 Oct 2012 23:23:00 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <506E4E07.3000807@toshiba.co.jp> <034101cda301$4972d690$dc5883b0$@com> <506EF948.40303@toshiba.co.jp> <9B57C850BB53634CACEC56EF4853FF653B8101A7@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> To: Dave Thaler X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:k/2+LamTG10JHP+UvOQmE6C3pNrvcjU3qyLlchYYiN1 mYZybcUSKCFEaSoXmUdMEccU46NBpWMC5yImtiMifwylrMGmOJ vaqLepNxBx9FMLmJM6wVPIKmAz6m10k6sY2LOyDBdtYSgWbN/V /gjyKtACEblbcubG7eq2wwMLCUtmG8r+Usa2NpadLnT3zJ9MtA t1wseGyYaDacfNDYGy1j4R3BtRfuM7ZdQeE1KAoIQlpTjvNy5u ZU346QiacHo71azRaKrhh2kqbAvjVCENOY0dErkW18pe8z2o8r +jUX4o3biFEtLbTa6Alb5ST544AwSl8vuxqIj467Vc0muEmlM/ sZzCoXDMKldl0GHv0iIETgW5XO+ZG4/EM1WN2GYo5tc/QoKCUO GYe1ZCg8eQEBw== Cc: "pcp@ietf.org" Subject: Re: [pcp] Capability discovery 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, 05 Oct 2012 20:23:24 -0000 >>>> -----Original Message----- >>>> From:pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf = Of >>>> Yoshihiro Ohba >>>> Sent: Thursday, October 04, 2012 8:04 PM To:pcp@ietf.org >>>> Subject: [pcp] Capability discovery >>>>=20 >>>> There has been a question on what to do when PCP client supports = PCP >>>> authentication while PCP server does not, and vise versa. >>> Yes, that problem needs to be solved. >>>=20 >>>> The same issue will exist for future PCP extensions. >>> I disagree that problem exists for PCP extensions. The client can >>> simply try to use the extension, and will either get back an error >>> (e.g., UNSUPP_OPCODE or UNSUPP_OPTION error), or the option will >>> not be included in the response (for options outside the mandatory- >>> to-process range). >>=20 >> In that case, the problem is specific to side-by-side PANA approach >> which does not use PCP opcode/options. Is this correct? >=20 > Yes, I believe that's correct. Let's look at the whole space and see where the issue arises. 1. PANA tunneling No problem.=20 2. PANA port-sharing (side-by-side) 2.1. DHCP-based PCP server discovery Not a problem, we can easily define auth_requirement as an attribute of = the PCP server. 2.2. Implicit (non-DHCP-based) PCP server discovery (PCP server is the = default gateway). 2.2.a. Client and server supports auth No problem 2.2.b. Client does not support, server supports&requires auth Not a problem. Server sends an error in response to unauthenticated = request. 2.2.c. Client and server does not support auth No problem 2.2.d. Client supports auth, server does not support auth. Earlier example to cause an issue was when the client starts with auth, = and the server does not understand what was going on (server would think = the client is talking version PCP 128). But, we can easily require "clients that do not know the server's = capability and policy" to start with "no auth" and see what happens. Either the PCP goes thru, which is fine; or the client receives a PCP = auth error in which case it learns to go back and try with auth. So, overall, there does not seem to be an issue. Am I missing something? Alper From hartmans@painless-security.com Fri Oct 5 13:31:42 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1934A21F858F for ; Fri, 5 Oct 2012 13:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.349 X-Spam-Level: **** X-Spam-Status: No, score=4.349 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.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 CLtucEy+WAFx for ; Fri, 5 Oct 2012 13:31:41 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 7641121F8582 for ; Fri, 5 Oct 2012 13:31:39 -0700 (PDT) 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.suchdamage.org (Postfix) with ESMTPS id 53AC720180; Fri, 5 Oct 2012 16:31:25 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A3FA94AD5; Fri, 5 Oct 2012 16:31:23 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <506E4E07.3000807@toshiba.co.jp> <034101cda301$4972d690$dc5883b0$@com> <506EF948.40303@toshiba.co.jp> <9B57C850BB53634CACEC56EF4853FF653B8101A7@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Fri, 05 Oct 2012 16:31:23 -0400 In-Reply-To: (Alper Yegin's message of "Fri, 5 Oct 2012 23:23:00 +0300") 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] Capability discovery 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, 05 Oct 2012 20:31:42 -0000 >>>>> "Alper" == Alper Yegin writes: Alper> Let's look at the whole space and see where the issue arises. Alper> 1. PANA tunneling No problem. Agreed. If by tunneling you mean encapsulation. Alper> 2. PANA port-sharing (side-by-side) Alper> 2.1. DHCP-based PCP server discovery Not a problem, we can Alper> easily define auth_requirement as an attribute of the PCP Alper> server. I don't think this is a reasonable thing to do. It requires the DHCP servenr to be aware of capability changes in the PANA server. I think DHCP is good for discovering the identities of services, but not for capability discovery. Alper> 2.2.d. Client supports auth, server does not support auth. Alper> Earlier example to cause an issue was when the client starts Alper> with auth, and the server does not understand what was going Alper> on (server would think the client is talking version PCP Alper> 128). Alper> But, we can easily require "clients that do not know the Alper> server's capability and policy" to start with "no auth" and Alper> see what happens. Either the PCP goes thru, which is fine; Alper> or the client receives a PCP auth error in which case it Alper> learns to go back and try with auth. This does not work for clients who have a security requirement of requiring authentication even if the server does not require this. If the client wants integrity protection of the response, this is important. For example the client can have confidence that its mapping is created and that the response is not spoofed. For nat traversal, this is not a big deal. For firewall policy changes this can be a huge deal. From alper.yegin@yegin.org Fri Oct 5 13:36: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 AB0A221F85EA for ; Fri, 5 Oct 2012 13:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 yKel8GkoY+nO for ; Fri, 5 Oct 2012 13:36:57 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id DC13A21F85B1 for ; Fri, 5 Oct 2012 13:36:56 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LfTRR-1Tmkxl2U9Z-00pQQ6; Fri, 05 Oct 2012 16:36:46 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_ACDC3A60-2121-4659-8FAA-66DB0ABD93B7" From: Alper Yegin In-Reply-To: <712CABEE-96A2-493A-B2F8-94BC2548E0FD@lilacglade.org> Date: Fri, 5 Oct 2012 23:36:26 +0300 Message-Id: References: <506E5175.3020802@toshiba.co.jp> <712CABEE-96A2-493A-B2F8-94BC2548E0FD@lilacglade.org> To: Margaret Wasserman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:6XfM5Goi2qx9gUtV0TotdyYPRUavYdTuHR6P1qJGlWw 9D6oxV5YrJQBHBZETni28avg3bONDp899WfcjD2J/clm+Z3aD4 nJQG2k7uupogkm2Yy+JLWNDez3er4E70v+oJ4Q0jquAoNwaDG3 aQg4JStZpHvts/ycrD59JcZ0y6/zBaj5P4EYn2PXCiEh4Er9vq VmEmtr1lchRbGRz/DrK/asKfiJ+O9BWhYHcyNlq3mvbhd02ujd yGHdr/wMnn5QZ8woHSowrK+zG8dUnoOIQ+ohZ2qelFqw+I31ve /jvlD1wVfzdukKbhVZzFs4UQipozLmTHY+wydmBz+nzi56C+fG ezppnSmR/jKaysb+8p+tKO6HeNr4iHqOxNA8rRCb8dT9xznQqq 8yYTTd55YxWWg== Cc: pcp@ietf.org Subject: Re: [pcp] Revising PANA side-by-side approach 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, 05 Oct 2012 20:36:57 -0000 --Apple-Mail=_ACDC3A60-2121-4659-8FAA-66DB0ABD93B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Just to add to few things to what Yoshi said=85 >=20 > Hi Yoshi, >=20 > The concern that I have with this approach is that it seems = short-sited to me... >=20 > If we expect PANA to be used as a generic authentication mechanism, = rather than being used specifically for network access authentication, I = think we need to do two things: >=20 > 1) Provide a clear explanation of what parts of PANA will be used with = PCP. For example, the notion of a network access enforcement point = doesn't really make sense in a PCP context.=20 PANA spec recognizes the possibility that the authenticator and the = enforcement point may be separate. This is a possible case in access networks. While this possibility is recognized, it does not make any difference on = the authentication procedure as you can see from RFC 5191. (and in the case of PCP use, enforcement point and PAA are co-located.) > 2) Describe a clean mechanism that allows PANA to be used for = authentication of other protocols. >=20 > Overloading a single bit in the PCP version field, because it happens = to coincide with a flag bit in PANA doesn't seem like a method that will = work for other protocols, and I am concerned that it doesn't provide a = clean basis for moving forward. >=20 This is done here just because folks wanted to share the same port for = PANA and PCP. I'm in fact seeking further clarification on this need. I had asked this = on the ML http://www.ietf.org/mail-archive/web/pcp/current/msg02395.html = (*) but no one answered. So, I'm not sure how necessary this port = sharing is.=20 And I don't know if anyone else would require the same for another = protocol down the road.=20 So, when we need to do this for other protocols, I don't think we'd need = to do port sharing. (*) I had said "I wasn't on the jabber at previous IETF, so maybe I = missed some of the discussions." in that email. I made a typo. I meant = "I was on the jabber (not in the meeting room), so maybe I missed some = of the discussions." Alper > Margaret >=20 >=20 > On Oct 4, 2012, at 11:18 PM, Yoshihiro Ohba wrote: >=20 >> Since PCP Version 0 is used by draft-cheshire-nat-pmp, I plan to >> revise PANA side-by-side approach I-D (draft-ohba-pcp-pana) to use >> Bit 0 instead of Bits 5-6-7. The new logic is that when bit 0 is 1 = it's >> PANA, >> otherwise it's PCP and alike. If there is an issue with the new = logic, >> please let me know. >>=20 >> I also plan to submit PANA encasulation approach as a separate I-D >> before the next interim meeting. >>=20 >> Regards, >> Yoshihiro Ohba >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp --Apple-Mail=_ACDC3A60-2121-4659-8FAA-66DB0ABD93B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Just = to add to few things to what Yoshi = said=85



Hi = Yoshi,

The concern that I have with this approach is that it = seems short-sited to me...

If we expect PANA to be used as a = generic authentication mechanism, rather than being used specifically = for network access authentication, I think we need to do two = things:

1) Provide a clear explanation of what parts of PANA will = be used with PCP.   For example, the notion of a network = access enforcement point doesn't really make sense in a PCP context. =

PANA spec recognizes the = possibility that the authenticator and the enforcement point may be = separate.
This is a possible case in access = networks.
While this possibility is recognized, it does not = make any difference on the authentication procedure as you can see from = RFC 5191.

(and in the case of PCP use, = enforcement point and PAA are = co-located.)

2) = Describe a clean mechanism that allows PANA to be used for = authentication of other protocols.

Overloading a single bit in = the PCP version field, because it happens to coincide with a flag bit in = PANA doesn't seem like a method that will work for other protocols, and = I am concerned that it doesn't provide a clean basis for moving = forward.


This is done here = just because folks wanted to share the same port for PANA and = PCP.
I'm in fact seeking further clarification on this need. I = had asked this on the ML ht= tp://www.ietf.org/mail-archive/web/pcp/current/msg02395.html (*) but = no one answered. So, I'm not sure how necessary this port sharing = is. 
And I don't know if anyone else would require the = same for another protocol down the road. 
So, when we = need to do this for other protocols, I don't think we'd need to do port = sharing.

(*) I had said "I wasn't on the jabber at previous IETF, so maybe I missed = some of the discussions." in that email. I made a typo. I meant "I was = on the jabber (not in the meeting room), so maybe I missed some of the = discussions."

Alper





Margaret


On Oct 4, 2012, at 11:18 PM, = Yoshihiro Ohba wrote:

Since PCP Version = 0 is used by draft-cheshire-nat-pmp, I plan = to
revise PANA side-by-side = approach I-D (draft-ohba-pcp-pana) to use
Bit 0 instead of Bits 5-6-7. The new logic is that when = bit 0 is 1 it's
PANA,
otherwise = it's PCP and alike. If there is an issue with the new = logic,
please let me = know.

I also plan to = submit PANA encasulation approach as a separate = I-D
before the next interim = meeting.

Regards,
Yoshihiro= Ohba

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

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

= --Apple-Mail=_ACDC3A60-2121-4659-8FAA-66DB0ABD93B7-- From hartmans@painless-security.com Fri Oct 5 13:43:44 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164E621F8532 for ; Fri, 5 Oct 2012 13:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.348 X-Spam-Level: **** X-Spam-Status: No, score=4.348 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.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 ASfoYMPzYLYx for ; Fri, 5 Oct 2012 13:43:43 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 938D321F84FD for ; Fri, 5 Oct 2012 13:43:43 -0700 (PDT) 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.suchdamage.org (Postfix) with ESMTPS id DECEE20289; Fri, 5 Oct 2012 16:43:29 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B5EA44AD5; Fri, 5 Oct 2012 16:43:28 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <506E5175.3020802@toshiba.co.jp> <712CABEE-96A2-493A-B2F8-94BC2548E0FD@lilacglade.org> Date: Fri, 05 Oct 2012 16:43:28 -0400 In-Reply-To: (Alper Yegin's message of "Fri, 5 Oct 2012 23:36:26 +0300") 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] Revising PANA side-by-side approach 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, 05 Oct 2012 20:43:44 -0000 >>>>> "Alper" == Alper Yegin writes: Alper> port sharing is. And I don't know if anyone else would Alper> require the same for another protocol down the road. So, Alper> when we need to do this for other protocols, I don't think Alper> we'd need to do port sharing. The explanation Stuart gave you in the meeting for port sharing applies fairly universally. I've generally found that applications with authentication over the same port are significantly easier to deploy. One of the many issues is firewalls, but the other issues Stuart described also apply. From margaretw42@gmail.com Fri Oct 5 17:59:07 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D985221F861C for ; Fri, 5 Oct 2012 17:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iW6W-XP4fWiQ for ; Fri, 5 Oct 2012 17:59:07 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B45521F857A for ; Fri, 5 Oct 2012 17:59:07 -0700 (PDT) Received: by mail-gh0-f172.google.com with SMTP id g10so703982ghb.31 for ; Fri, 05 Oct 2012 17:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=LRdd6JwYBabj2HOqsk0GPn8GbmB/dKsjxvPq2Vh2T80=; b=RFXuObEzm2tFS31A2S7xc2+JwV1AATwj0Qfa+bNjrsYSijXuX4FPKyS5J4bav9nyFP updfmOIVLYo1YjMEC6OfENjoJkWw1FeqCfckiTp6ykzyS8kVtf33vytZY0MzqcQzXi0D ISNOCceqoBjc3EYMYiIKcF9Y/rIykdrfvLUe4oyMmQrwaVrIAopOQvy5n22ab6QIhZWO fu7WWRKf38rqV+yoYieK8Wf3PULUaeJ87xkb0ZWPdt5ULso3Hxuvt6vDrobOPO8XSAOp PMjmkIXuG/Acfkvh1lzW03pp0xlMWrZJg5hEzABMNdzWV/YiEyKdDt0hyMm5T0iFSpr+ /4nA== Received: by 10.236.191.69 with SMTP id f45mr10416290yhn.8.1349485146898; Fri, 05 Oct 2012 17:59:06 -0700 (PDT) Received: from [192.168.1.100] (66-190-170-209.dhcp.crtn.ga.charter.com. [66.190.170.209]) by mx.google.com with ESMTPS id e24sm16467084yhh.4.2012.10.05.17.58.58 (version=SSLv3 cipher=OTHER); Fri, 05 Oct 2012 17:59:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <506EF099.3030503@toshiba.co.jp> Date: Fri, 5 Oct 2012 20:58:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <506E5175.3020802@toshiba.co.jp> <712CABEE-96A2-493A-B2F8-94BC2548E0FD@lilacglade.org> <506EF099.3030503@toshiba.co.jp> To: Yoshihiro Ohba X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Revising PANA side-by-side approach 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, 06 Oct 2012 00:59:08 -0000 Hi Yoshi, >> 1) Provide a clear explanation of what parts of PANA will be used = with PCP. For example, the notion of a network access enforcement = point doesn't really make sense in a PCP context. >=20 > I agree that EP is not needed in the context of PCP authentication. We = probably do not need > to use 'I' (IP Reconfiguration) and 'P' (Ping) flags either. I doubt we have any major disconnect regarding what parts of PANA = would/wouldn't be used with PCP. However, we need to capture that = understanding and document it, for people who are attempting to = implement PANA for use with PCP. I believe we will find that we are = only using a fairly small subset of PANA for this purpose. >> 2) Describe a clean mechanism that allows PANA to be used for = authentication of other protocols. >>=20 >> Overloading a single bit in the PCP version field, because it happens = to coincide with a flag bit in PANA doesn't seem like a method that will = work for other protocols, and I am concerned that it doesn't provide a = clean basis for moving forward. The cleanest mechanism, IMO, would be to define a demultiplexing header = that is used to determine whether the contents beyond that header are a = PCP packet or a PANA packet. If we want to send that header over the = PCP port, though, it needs to look like a PCP header, which quickly = devolves to the encapsulation approach. Margaret From yoshihiro.ohba@toshiba.co.jp Fri Oct 5 18:24:34 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E665921F8669 for ; Fri, 5 Oct 2012 18:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.078 X-Spam-Level: X-Spam-Status: No, score=-5.078 tagged_above=-999 required=5 tests=[AWL=-0.989, 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 4ErJwvRLGyiT for ; Fri, 5 Oct 2012 18:24:34 -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 422A321F865F for ; Fri, 5 Oct 2012 18:24:33 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q961OVKd008143; Sat, 6 Oct 2012 10:24:31 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q961OVnm001706; Sat, 6 Oct 2012 10:24:31 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id LAA01705; Sat, 6 Oct 2012 10:24:31 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q961OV5x024951; Sat, 6 Oct 2012 10:24:31 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q961OUBZ002054; Sat, 6 Oct 2012 10:24:30 +0900 (JST) Received: from [133.199.18.23] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MBG00CXT6KTIU70@mail.po.toshiba.co.jp>; Sat, 06 Oct 2012 10:24:30 +0900 (JST) Date: Sat, 06 Oct 2012 10:24:33 +0900 From: Yoshihiro Ohba In-reply-to: To: Margaret Wasserman Message-id: <506F8851.2000103@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <506E5175.3020802@toshiba.co.jp> <712CABEE-96A2-493A-B2F8-94BC2548E0FD@lilacglade.org> <506EF099.3030503@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] Revising PANA side-by-side approach 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, 06 Oct 2012 01:24:35 -0000 Hi Margaret, (2012/10/06 9:58), Margaret Wasserman wrote: > Hi Yoshi, > >>> 1) Provide a clear explanation of what parts of PANA will be used with PCP. For example, the notion of a network access enforcement point doesn't really make sense in a PCP context. >> I agree that EP is not needed in the context of PCP authentication. We probably do not need >> to use 'I' (IP Reconfiguration) and 'P' (Ping) flags either. > I doubt we have any major disconnect regarding what parts of PANA would/wouldn't be used with PCP. However, we need to capture that understanding and document it, for people who are attempting to implement PANA for use with PCP. I believe we will find that we are only using a fairly small subset of PANA for this purpose. I would rather think that the difference that I mentioned above is small. I would say more than 90% of code is the same, that is one reason why I suggest to use PANA. >>> 2) Describe a clean mechanism that allows PANA to be used for authentication of other protocols. >>> >>> Overloading a single bit in the PCP version field, because it happens to coincide with a flag bit in PANA doesn't seem like a method that will work for other protocols, and I am concerned that it doesn't provide a clean basis for moving forward. > The cleanest mechanism, IMO, would be to define a demultiplexing header that is used to determine whether the contents beyond that header are a PCP packet or a PANA packet. If we want to send that header over the PCP port, though, it needs to look like a PCP header, which quickly devolves to the encapsulation approach. I may be misunderstanding, but I don't think this is cleaner, as the demultiplexing header needs to look like a PCP header for PCP. Yoshihiro Ohba > Margaret > > > From alper.yegin@yegin.org Fri Oct 5 23:56:50 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28E121F8669 for ; Fri, 5 Oct 2012 23:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, 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 ckS3WxO1CC3w for ; Fri, 5 Oct 2012 23:56:50 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA1A21F85E7 for ; Fri, 5 Oct 2012 23:56:50 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MYhC6-1Sxmz749cw-00Vqc7; Sat, 06 Oct 2012 02:56:46 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Sat, 6 Oct 2012 09:56:24 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <661F3891-C8CE-498E-ACAA-1BBAE9DE4480@yegin.org> References: <506E4E07.3000807@toshiba.co.jp> <034101cda301$4972d690$dc5883b0$@com> <506EF948.40303@toshiba.co.jp> <9B57C850BB53634CACEC56EF4853FF653B8101A7@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:vqsDCLDlx/1IVwnIl0x+pLIs6K9uC6UKY5rgPzcyDRF iI7pHZRGNY6DeGMgm+2tqvXER5c/Wh12Pjzc9Ijv2migcc8BDI RVgyWdbW/JWHMq99XUiL0J0X69BFw6HFWkKAabWUdPRA2aIq/k VX0K8wluDIcADA+F9lWJQ72Oh1i2trovxSMROqN/9Z6Ay1lXMc JTJPdpgug3/j9FYMjyPqlYRv9QjiYNazh78LkNhO27q9Qj5mMc 9l1EUetxxuhyZGCB2sbmlRd9u2d8HzQtBAcIm3LtlVmPOg1yHi MEKi1Ek5oUv6MWoxiQ7t50fL8L1Y3YYBnS4BkUNkUpwAyA6kXZ 4P50yoPkkzmv8lMS5NZjxRM5/msZpqr1ZNLb1of6hK4Ox2xf2V qcG+jwhI38Ztg== Cc: "pcp@ietf.org" Subject: Re: [pcp] Capability discovery 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, 06 Oct 2012 06:56:51 -0000 >=20 > Alper> Let's look at the whole space and see where the issue = arises. >=20 > Alper> 1. PANA tunneling No problem. > Agreed. If by tunneling you mean encapsulation. >=20 > Alper> 2. PANA port-sharing (side-by-side) >=20 > Alper> 2.1. DHCP-based PCP server discovery Not a problem, we can > Alper> easily define auth_requirement as an attribute of the PCP > Alper> server. >=20 > I don't think this is a reasonable thing to do. > It requires the DHCP servenr to be aware of capability changes in the > PANA server. > I think DHCP is good for discovering the identities of services, but = not > for capability discovery. >=20 That's so not true.=20 DHCP is defined and used for not only delivering "identities" but also a = whole bunch of configuration parameters. Just browse any few DHCP RFCs, you'll see immediately. > Alper> 2.2.d. Client supports auth, server does not support auth. > Alper> Earlier example to cause an issue was when the client starts > Alper> with auth, and the server does not understand what was going > Alper> on (server would think the client is talking version PCP > Alper> 128). >=20 > Alper> But, we can easily require "clients that do not know the > Alper> server's capability and policy" to start with "no auth" and > Alper> see what happens. Either the PCP goes thru, which is fine; > Alper> or the client receives a PCP auth error in which case it > Alper> learns to go back and try with auth. >=20 > This does not work for clients who have a security requirement of > requiring authentication even if the server does not require this. > If the client wants integrity protection of the response, this is > important. >=20 > For example the client can have confidence that its mapping is created > and that the response is not spoofed. > For nat traversal, this is not a big deal. > For firewall policy changes this can be a huge deal. In this case you are already using DHCP for PCP server discovery = (because firewall does not have to be on the first hop). And with the PCP server attribute we provide in DHCP option, issue would = be addressed. (And if we were not using DHCP, then PANA client would timeout and = indicate auth failure to the PCP client. Not as fast as figuring out the = problem using DHCP, but still an acceptable result when dealing with = misconfigured networks such as in this example) Alper =20 From alper.yegin@yegin.org Sat Oct 6 00:00:50 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 544C521F8669 for ; Sat, 6 Oct 2012 00:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, 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 omkhNGeCrHsc for ; Sat, 6 Oct 2012 00:00:49 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id B859721F865D for ; Sat, 6 Oct 2012 00:00:49 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MQxxm-1Sq71Q3V4I-00UkEm; Sat, 06 Oct 2012 03:00:47 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Sat, 6 Oct 2012 10:00:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <506E5175.3020802@toshiba.co.jp> <712CABEE-96A2-493A-B2F8-94BC2548E0FD@lilacglade.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:Ke0nJRFi0ufKjrqqznee0oj9SkQC2eligUSrz3/aoP5 VPOJJnBJ9X9t0MoKXKfZ5s6cTITiFVvYFVLh9NikokHsysNoJN qDytl8dKRN8lv/xa4guasehijfBkkTZWUXFI2GHgwIovbcnokz 7+frxgFhw6V1MzvhkBVjOQSre/hbcqOWUI7gLRZb5i1tP/LCHU nga3Muo43tBJwBke60XooBTCDkG+ApI9oWGAU1K8zejOssEUyO dlh0Lj4CX972t02o4Sug3YNHcyUTu++fSIZF+W+7zSFwJsLrY5 Dnw3fOEOqM3GRh9njHWXStzjsDF0mS05/ppQjKdyz8ebjSBtoX ehUWCAVTEGKTjjZN+irwpnVRknho6dyxPPaGjXe42WT74fiPGC FCN4vBRBoWcHQ== Cc: pcp@ietf.org Subject: Re: [pcp] Revising PANA side-by-side approach 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, 06 Oct 2012 07:00:50 -0000 >>>>>> "Alper" =3D=3D Alper Yegin writes: >=20 > Alper> port sharing is. And I don't know if anyone else would > Alper> require the same for another protocol down the road. So, > Alper> when we need to do this for other protocols, I don't think > Alper> we'd need to do port sharing. >=20 > The explanation Stuart gave you in the meeting for port sharing = applies > fairly universally. > I've generally found that applications with authentication over the = same > port are significantly easier to deploy. > One of the many issues is firewalls, but the other issues Stuart > described also apply. Sam, I'm seeking elaboration on "Stuart explanation". What I remember is = a high-level "configuring two ports is harder than configuring one". = Maybe more was said but I couldn't capture it. In the interest of time = in the call I didn't go after it. You seem to have an understanding of = it , since you are referring to it. Can you elaborate on the issue? What's the firewall issue?=20 You are just naming the issues "Firewall issue", "Stuart issue". Can you = expand them a bit beyond their titles? Alper= From margaretw42@gmail.com Sat Oct 6 13:13:20 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 81C0821F84B6 for ; Sat, 6 Oct 2012 13:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 pruLJAJefwlc for ; Sat, 6 Oct 2012 13:13:19 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C54B21F84B5 for ; Sat, 6 Oct 2012 13:13:19 -0700 (PDT) Received: by mail-gh0-f172.google.com with SMTP id g10so845511ghb.31 for ; Sat, 06 Oct 2012 13:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=NegPEe/U9uWGjIxLAZVEqpsxxU/xC835XAg+77KMYOw=; b=KS6H892P91A/rG2z0vlnHZL5PrUS74YGANnQtlfRYALOwLF9bVx4QZtQYy7ST6KwKb CrQqhQXyrTHwmlPKwcFJoxyO3+veFeWfTXvrFw8JAZdnXxSXjSjgFXnPDKvcSRNRtC1O 15SCVjCjUFtYLBP045Yl99Jp6XIrUNVy7R5TStjyF7FiiBFPwdfc2n+wt2nv2U56HZPG Hq49aQNQDXcwG4OmPeRQDq8cdDwk3PdeN8jBexnz8gTefJhHJfwMWxhdTRlijnewBgUq BmW3DPJOoe2MjoXTno2c166NMZ78Tg+yssb9TTLBldr59hleko06Lmt9KhlS2ptud7h2 fVGQ== Received: by 10.236.124.44 with SMTP id w32mr11581144yhh.76.1349554398857; Sat, 06 Oct 2012 13:13:18 -0700 (PDT) Received: from [192.168.1.100] (66-190-170-209.dhcp.crtn.ga.charter.com. [66.190.170.209]) by mx.google.com with ESMTPS id l16sm13138196anm.6.2012.10.06.13.13.13 (version=SSLv3 cipher=OTHER); Sat, 06 Oct 2012 13:13:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-31--267478127 From: Margaret Wasserman In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B7D6413@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Sat, 6 Oct 2012 16:13:12 -0400 Message-Id: <6144A080-849D-41BE-8C90-236AFA2262DC@lilacglade.org> References: <9B57C850BB53634CACEC56EF4853FF653B7D63B5@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B7D6413@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> To: Dave Thaler X-Mailer: Apple Mail (2.1084) Cc: "pcp@ietf.org" Subject: Re: [pcp] Scheduling next WebEx interim meeting 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, 06 Oct 2012 20:13:20 -0000 --Apple-Mail-31--267478127 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Dave, Did you end up scheduling this meeting? Margaret On Sep 28, 2012, at 2:38 PM, Dave Thaler wrote: > For comparison, I=92ve also put in a late option on the 12th just to = get a comparison > if someone is unavailable all the week of the 15th. > =20 > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of = Dave Thaler > Sent: Friday, September 28, 2012 11:35 AM > To: pcp@ietf.org > Subject: [pcp] Scheduling next WebEx interim meeting > =20 > Once I heard back from various key security discussion participants > (authors/presenters/chairs/ADs) via email, it turned out > that no day during the week of Oct 8th would work. Rather > than trying to hold an interim when the relevant parties cannot be = there, > I want to see if a day early (Mon/Tues/Wed) the following week would = work. > =20 > I=92ve created a doodle poll at > http://doodle.com/cc78mg3yrx2g3bm7 > =20 > Please list your availability there. If none of those work and you = believe > you=92re a key participant, send me mail with your closest = availability. > =20 > -Dave > =20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp --Apple-Mail-31--267478127 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Hi Dave,

Did you = end up scheduling this = meeting?

Margaret

On = Sep 28, 2012, at 2:38 PM, Dave Thaler wrote:

For comparison, I=92ve also put in a late option on the = 12th just = to get a comparison
if someone is unavailable all the week of the = 15th.
 
From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org]=  On Behalf Of Dave = Thaler
Sent: Friday, September 28, 2012 = 11:35 AM
To: pcp@ietf.org
Subject: [pcp] Scheduling next WebEx = interim meeting
 
Once I heard back from various = key security discussion participants
(authors/presenters/chairs/ADs) via email, it turned = out
that no day during the week of Oct = 8th would = work.   Rather
than trying to hold an interim = when the relevant parties cannot be there,
I want to see if a day early (Mon/Tues/Wed) the following = week would work.
 
I=92ve created a doodle poll at
_____________________________________= __________
pcp mailing list
 Subject: Re: [pcp] Scheduling next WebEx interim meeting 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, 08 Oct 2012 18:55:47 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B81F99ATK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, it was announced to the list in the message here: http://www.ietf.org/mail-archive/web/pcp/current/msg02419.html -Dave From: Margaret Wasserman [mailto:margaretw42@gmail.com] Sent: Saturday, October 6, 2012 1:13 PM To: Dave Thaler Cc: pcp@ietf.org Subject: Re: [pcp] Scheduling next WebEx interim meeting Hi Dave, Did you end up scheduling this meeting? Margaret On Sep 28, 2012, at 2:38 PM, Dave Thaler wrote: For comparison, I've also put in a late option on the 12th just to get a co= mparison if someone is unavailable all the week of the 15th. From: pcp-bounces@ietf.org [mailto:pcp-bounces= @ietf.org] On Behalf Of Dave Thaler Sent: Friday, September 28, 2012 11:35 AM To: pcp@ietf.org Subject: [pcp] Scheduling next WebEx interim meeting Once I heard back from various key security discussion participants (authors/presenters/chairs/ADs) via email, it turned out that no day during the week of Oct 8th would work. Rather than trying to hold an interim when the relevant parties cannot be there, I want to see if a day early (Mon/Tues/Wed) the following week would work. I've created a doodle poll at http://doodle.com/cc78mg3yrx2g3bm7 Please list your availability there. If none of those work and you believ= e you're a key participant, send me mail with your closest availability. -Dave _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp --_000_9B57C850BB53634CACEC56EF4853FF653B81F99ATK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, it was announced to = the list in the message here:

http://www.ietf.org/mail-= archive/web/pcp/current/msg02419.html

 <= /p>

-Dave

 <= /p>

From: Margar= et Wasserman [mailto:margaretw42@gmail.com]
Sent: Saturday, October 6, 2012 1:13 PM
To: Dave Thaler
Cc: pcp@ietf.org
Subject: Re: [pcp] Scheduling next WebEx interim meeting<= /span>

 

 

Hi Dave,

 

Did you end up scheduling this meeting?

 

Margaret

 

On Sep 28, 2012, at 2:38 PM, Dave Thaler wrote:=



For comparison, I’v= e also put in a late option on the 12th just to get a comparison=

if someone is unavailable= all the week of the 15th.=

 

From: pcp-bounces@ietf.org [mailto:p= cp-bounces@ietf.org] = On Behalf Of Dave Thale= r
Sent: Friday, Sept= ember 28, 2012 11:35 AM
To: pcp@ietf.org
Subject: [pcp] Sch= eduling next WebEx interim meeting

 

Once I heard back from various key secu= rity discussion participants

(authors/presenters/chairs/ADs) via ema= il, it turned out

that no day during the week of Oct 8th would work.&nb= sp;  Rather

than trying to hold an interim when the= relevant parties cannot be there,

I want to see if a day early (Mon/Tues/= Wed) the following week would work.

 

I’ve created a doodle poll at

 

Please list your availability there.&nb= sp;  If none of those work and you believe

you’re a key participant, send me= mail with your closest availability.

 

-Dave

 

_____________________________________= __________
pcp mailing list
pcp@ietf.org
https://www.ietf.org/= mailman/listinfo/pcp

 

--_000_9B57C850BB53634CACEC56EF4853FF653B81F99ATK5EX14MBXW604w_-- From yoshihiro.ohba@toshiba.co.jp Mon Oct 8 14:47:13 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07AB1F0C5C for ; Mon, 8 Oct 2012 14:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.023 X-Spam-Level: X-Spam-Status: No, score=-5.023 tagged_above=-999 required=5 tests=[AWL=-0.934, 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 sKtOTzkr6vUh for ; Mon, 8 Oct 2012 14:47:13 -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 CD95A1F041F for ; Mon, 8 Oct 2012 14:47:12 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q98Ll921029789; Tue, 9 Oct 2012 06:47:09 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q98Ll96a008078; Tue, 9 Oct 2012 06:47:09 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id GAA08077; Tue, 9 Oct 2012 06:47:08 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q98Ll8e0010372; Tue, 9 Oct 2012 06:47:08 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q98Ll8ui006828; Tue, 9 Oct 2012 06:47:08 +0900 (JST) Received: from [133.199.16.248] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MBL008RIGIHVP80@mail.po.toshiba.co.jp>; Tue, 09 Oct 2012 06:47:08 +0900 (JST) Date: Tue, 09 Oct 2012 06:47:06 +0900 From: Yoshihiro Ohba In-reply-to: <9B57C850BB53634CACEC56EF4853FF653B8101A7@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> To: Dave Thaler Message-id: <507349DA.4030907@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <506E4E07.3000807@toshiba.co.jp> <034101cda301$4972d690$dc5883b0$@com> <506EF948.40303@toshiba.co.jp> <9B57C850BB53634CACEC56EF4853FF653B8101A7@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> 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] Capability discovery 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, 08 Oct 2012 21:47:13 -0000 OK. Then how about the following approches? - For PANA encapsulation approach, we use what Dan mentioned, i.e., the client simply try to use the extension and get an error from the server not supporing the extension. - For PANA side-by-side approach: The PCP client supporting PCP authentication MAY send an unauthenticated ANNOUNCE request prior to initiating PANA in order to know whether a PCP server supports PCP authentication. A PCP server supporting PCP authentication SHALL return an unauthenticated ANNOUNCE response with (new) "AUTHENTICATION_REQUIRED" result code. A PCP server not supporting PCP authentication SHALL return an unauthenticated ANNOUNCE response with "SUCCESS" result code. Regards, Yoshihiro Ohba (2012/10/06 2:42), Dave Thaler wrote: > Yoshihiro Ohba writes: >> (2012/10/05 22:56), Dan Wing wrote: >>>> -----Original Message----- >>>> From:pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of >>>> Yoshihiro Ohba >>>> Sent: Thursday, October 04, 2012 8:04 PM To:pcp@ietf.org >>>> Subject: [pcp] Capability discovery >>>> >>>> There has been a question on what to do when PCP client supports PCP >>>> authentication while PCP server does not, and vise versa. >>> Yes, that problem needs to be solved. >>> >>>> The same issue will exist for future PCP extensions. >>> I disagree that problem exists for PCP extensions. The client can >>> simply try to use the extension, and will either get back an error >>> (e.g., UNSUPP_OPCODE or UNSUPP_OPTION error), or the option will >>> not be included in the response (for options outside the mandatory- >>> to-process range). >> In that case, the problem is specific to side-by-side PANA approach >> which does not use PCP opcode/options. Is this correct? > Yes, I believe that's correct. > > -Dave > > > From yoshihiro.ohba@toshiba.co.jp Tue Oct 9 08:33: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 B1C9A21F8748 for ; Tue, 9 Oct 2012 08:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.974 X-Spam-Level: X-Spam-Status: No, score=-4.974 tagged_above=-999 required=5 tests=[AWL=-0.885, 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 ecnirJW116Aj for ; Tue, 9 Oct 2012 08:33:12 -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 05ADF21F873C for ; Tue, 9 Oct 2012 08:33:11 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q99FXBXa004030 for ; Wed, 10 Oct 2012 00:33:11 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q99FXBrY000068 for pcp@ietf.org; Wed, 10 Oct 2012 00:33:11 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id AAA00067; Wed, 10 Oct 2012 00:33:10 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q99FXAoZ023821 for ; Wed, 10 Oct 2012 00:33:10 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q99FXAVb004488; Wed, 10 Oct 2012 00:33:10 +0900 (JST) Received: from [133.199.17.11] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MBM00ECNTV7LL70@mail.po.toshiba.co.jp> for pcp@ietf.org; Wed, 10 Oct 2012 00:33:10 +0900 (JST) Date: Wed, 10 Oct 2012 00:33:06 +0900 From: Yoshihiro Ohba In-reply-to: <20121009152937.22680.1133.idtracker@ietfa.amsl.com> To: "pcp@ietf.org" Message-id: <507443B2.6010503@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7bit X-Forwarded-Message-Id: <20121009152937.22680.1133.idtracker@ietfa.amsl.com> References: <20121009152937.22680.1133.idtracker@ietfa.amsl.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Subject: [pcp] Fwd: New Version Notification for draft-ohba-pcp-pana-encap-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, 09 Oct 2012 15:33:12 -0000 A new I-D on PANA encapsulation approach has been submitted. Comments are appreciated. Yoshihiro Ohba -------- Original Message -------- Subject: New Version Notification for draft-ohba-pcp-pana-encap-00.txt Date: Tue, 09 Oct 2012 08:29:37 -0700 From: internet-drafts@ietf.org To: yoshihiro.ohba@toshiba.co.jp CC: alper.yegin@yegin.org, sdas@appcomsci.com A new version of I-D, draft-ohba-pcp-pana-encap-00.txt has been successfully submitted by Yoshihiro Ohba and posted to the IETF repository. Filename: draft-ohba-pcp-pana-encap Revision: 00 Title: Provisioning Message Authentication Key for PCP using PANA (Encapsulation Approach) Creation date: 2012-10-09 WG ID: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-ohba-pcp-pana-encap-00.txt Status: http://datatracker.ietf.org/doc/draft-ohba-pcp-pana-encap Htmlized: http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-00 Abstract: This document specifies a mechanism for provisioning PCP (Port Control Protocol) message authentication key by encapsulating PANA (Protocol for carrying Authentication for Network Access) in PCP. The IETF Secretariat From alper.yegin@yegin.org Fri Oct 12 01:30: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 65B8221F8540 for ; Fri, 12 Oct 2012 01:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, 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 YsiWjwc9W-EO for ; Fri, 12 Oct 2012 01:30:04 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id BFCE421F8545 for ; Fri, 12 Oct 2012 01:30:04 -0700 (PDT) Received: from [192.168.2.7] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Lpu1v-1TpJ0w1nr5-00fgyG; Fri, 12 Oct 2012 04:30:03 -0400 From: Alper Yegin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Oct 2012 11:29:46 +0300 Message-Id: <0BC19EAB-01F2-4AB9-B706-FD7C98FFAE86@yegin.org> To: pcp@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:YXKLCH8E8E5r1s5ReWtLYDp9vkd7JYRcHPibgF1bkZ/ flh9VGgOB8SLASN42INLwwM650ojYQFDuJNy2993rDLbBAwbDt o5XlvOIN2jAb8rN+uORoeiUoSRsH2Y/KlxJjVBOidkaJdLsXIE coRx6v0uXoLPTbPH3xsHyvvyhrb9p1b0ZfbhLvZ0NY89VMqsMZ Kr+sisV0yY45otq3XlgWKGUAdZ3YwNww4kAIfSnR8eobARF3p9 XPg5SjbElv5AkTEclai17awEK24qFKtcKG+UXWIcyVx4SKST4H /23SCekLdF+Fd6RgR7Jh1lviJAIzulM4/GNrG16jM6Ys0Y5Nol 8L2lPjdzki97UMyN7eSoYTgwNcNENvjPGMs0KkxgHnNbcP5o+5 VWTtua7Fw15Qw== Subject: [pcp] Server's auth policy discovery 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, 12 Oct 2012 08:30:05 -0000 Hello, Let me compile the auth policy discovery solutions that were discussed = on the ML so far. There are 3 possible auth policies on a PCP server 1. auth not used (not supported, or disabled) 2. use of auth is optional (i.e., PCP Client's decision) 3. auth is mandatory to use The question is, how does the PCP client know the server's policy. With the tunneled PANA approach: The client starts with either unauthenticated PCP or PANA-over-PCP, then = observes what it gets back from the server. Either an error, or progress = of what it started. With the port-sharing PANA approach: PCP client starts without using auth, and observes what happens. If the server policy is 1 or 2, then PCP works without a problem. If the server policy is 3, then the PCP server returns an appropriate = error message. Now, coming to Sam's scenario where it is not acceptable for some PCP = clients to operate in unauthenticated mode. He said this is needed for the firewall case. In that case, DHCP-based discovery needs to be used (irrespective of the = auth scenario), as the firewall is not necessarily the first-hop router = from PCP Client's perspective. We can update the DHCP-based discovery solution to deliver "auth policy" = of the PCP server along with the "IP address of the server". In addition to DHCP-based solution, or alternatively, we can define an = ANNOUNCE-based single round-trip between the PCP client and PCP server = for the client to discover the server's auth policy before proceeding.=20= Alper From mohamed.boucadair@orange.com Fri Oct 12 01:32:52 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8DC21F8540 for ; Fri, 12 Oct 2012 01:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0oSD7+0BzwU for ; Fri, 12 Oct 2012 01:32:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 74EBB21F853C for ; Fri, 12 Oct 2012 01:32:51 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 3983F3B4210 for ; Fri, 12 Oct 2012 10:32:50 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 20F0C27C053 for ; Fri, 12 Oct 2012 10:32:50 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Fri, 12 Oct 2012 10:32:49 +0200 From: To: "pcp@ietf.org" Date: Fri, 12 Oct 2012 10:32:48 +0200 Thread-Topic: I-D Action: draft-boucadair-pcp-capability-01.txt Thread-Index: Ac2nuiw2+PouyU8cQIi0yw3SfvPMtgAmbtrg Message-ID: <94C682931C08B048B7A8645303FDC9F36E632061ED@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.12.80323 Subject: [pcp] TR: I-D Action: draft-boucadair-pcp-capability-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: Fri, 12 Oct 2012 08:32:52 -0000 Dear all, We submitted an updated version of this draft.=20 Comments are welcome. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : jeudi 11 octobre 2012 16:09 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-boucadair-pcp-capability-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Retrieving the Capabilities of a PCP-controlled Device Author(s) : Mohamed Boucadair Tirumaleswar Reddy Filename : draft-boucadair-pcp-capability-01.txt Pages : 9 Date : 2012-10-11 Abstract: This document extends Port Control Protocol (PCP) with the ability to retrieve the capabilities of PCP-controlled device: CAPABILITY Option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-pcp-capability There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-pcp-capability-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-capability-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 hartmans@painless-security.com Fri Oct 12 03:51:08 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 7C05E21F8594 for ; Fri, 12 Oct 2012 03:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.345 X-Spam-Level: **** X-Spam-Status: No, score=4.345 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.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 RNjQjTLANQZJ for ; Fri, 12 Oct 2012 03:51:07 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id A69CB21F8559 for ; Fri, 12 Oct 2012 03:51:07 -0700 (PDT) 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.suchdamage.org (Postfix) with ESMTPS id 992AC2033A; Fri, 12 Oct 2012 06:50:51 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EF0B14AD5; Fri, 12 Oct 2012 06:51:02 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <0BC19EAB-01F2-4AB9-B706-FD7C98FFAE86@yegin.org> Date: Fri, 12 Oct 2012 06:51:02 -0400 In-Reply-To: <0BC19EAB-01F2-4AB9-B706-FD7C98FFAE86@yegin.org> (Alper Yegin's message of "Fri, 12 Oct 2012 11:29:46 +0300") 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] Server's auth policy discovery 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, 12 Oct 2012 10:51:08 -0000 Hi. As I've mentioned previously, I consider DHCP-based discovery of auth policy a significant down-side to an approach that requires it. For many of the same reasons that you want to avoid one port for authentication and one port for the protocol, you want to avoid one system for security policy discovery with another system for using that policy. Tightly-coupled systems are easier to debug and support. In this particular case, if auth policy discovery is in-band, you avoid the failure modes where the discovery solution has bad information. --Sam From yoshihiro.ohba@toshiba.co.jp Fri Oct 12 04:07:56 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EA121F85A4 for ; Fri, 12 Oct 2012 04:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.93 X-Spam-Level: X-Spam-Status: No, score=-4.93 tagged_above=-999 required=5 tests=[AWL=-0.841, 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 dHhrNYf614+N for ; Fri, 12 Oct 2012 04:07:55 -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 9795121F85A1 for ; Fri, 12 Oct 2012 04:07:55 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q9CB7sCZ028422 for ; Fri, 12 Oct 2012 20:07:54 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q9CB7sRb000235 for pcp@ietf.org; Fri, 12 Oct 2012 20:07:54 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id WAA00234; Fri, 12 Oct 2012 20:07:54 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q9CB7sKr017355 for ; Fri, 12 Oct 2012 20:07:54 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q9CB7sIx010779; Fri, 12 Oct 2012 20:07:54 +0900 (JST) Received: from [133.199.16.62] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MBS009281L3LC80@mail.po.toshiba.co.jp> for pcp@ietf.org; Fri, 12 Oct 2012 20:07:54 +0900 (JST) Date: Fri, 12 Oct 2012 20:07:54 +0900 From: Yoshihiro Ohba In-reply-to: To: pcp@ietf.org Message-id: <5077FA0A.9030308@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <0BC19EAB-01F2-4AB9-B706-FD7C98FFAE86@yegin.org> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Subject: Re: [pcp] Server's auth policy discovery 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, 12 Oct 2012 11:07:56 -0000 Is discoverying binary policy (auth unsupported/supported) is enough, or is discovering three-policy (auth unsupported/mandated/optional) needed? Yoshihiro Ohba (2012/10/12 19:51), Sam Hartman wrote: > Hi. > As I've mentioned previously, I consider DHCP-based discovery of auth > policy a significant down-side to an approach that requires it. > > For many of the same reasons that you want to avoid one port for > authentication and one port for the protocol, you want to avoid one > system for security policy discovery with another system for using that > policy. Tightly-coupled systems are easier to debug and support. In > this particular case, if auth policy discovery is in-band, you avoid the > failure modes where the discovery solution has bad information. > > --Sam > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From hartmans@painless-security.com Fri Oct 12 04:35: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 6B59421F8594 for ; Fri, 12 Oct 2012 04:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.344 X-Spam-Level: **** X-Spam-Status: No, score=4.344 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.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 fkPhxJNPutX5 for ; Fri, 12 Oct 2012 04:35:36 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id EE17621F857E for ; Fri, 12 Oct 2012 04:35:35 -0700 (PDT) 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.suchdamage.org (Postfix) with ESMTPS id F354520132; Fri, 12 Oct 2012 07:35:19 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8A0054AD5; Fri, 12 Oct 2012 07:35:31 -0400 (EDT) From: Sam Hartman To: Yoshihiro Ohba References: <0BC19EAB-01F2-4AB9-B706-FD7C98FFAE86@yegin.org> <5077FA0A.9030308@toshiba.co.jp> Date: Fri, 12 Oct 2012 07:35:31 -0400 In-Reply-To: <5077FA0A.9030308@toshiba.co.jp> (Yoshihiro Ohba's message of "Fri, 12 Oct 2012 20:07:54 +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] Server's auth policy discovery 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, 12 Oct 2012 11:35:36 -0000 >>>>> "Yoshihiro" == Yoshihiro Ohba writes: Yoshihiro> Is discoverying binary policy (auth Yoshihiro> unsupported/supported) is enough, or is discovering Yoshihiro> three-policy (auth unsupported/mandated/optional) needed? I think discovering auth supported is sufficient. From alper.yegin@yegin.org Fri Oct 12 04:41:51 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB2021F853B for ; Fri, 12 Oct 2012 04:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, 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 qY7QaqoVJASF for ; Fri, 12 Oct 2012 04:41:51 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 65ADA21F8533 for ; Fri, 12 Oct 2012 04:41:51 -0700 (PDT) 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 0M54zu-1TZWbR3QR4-00z2tZ; Fri, 12 Oct 2012 07:41:49 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Fri, 12 Oct 2012 14:41:29 +0300 Content-Transfer-Encoding: 7bit Message-Id: <22CCCEB5-FA7E-474A-B890-5A6EB16E44DB@yegin.org> References: <0BC19EAB-01F2-4AB9-B706-FD7C98FFAE86@yegin.org> <5077FA0A.9030308@toshiba.co.jp> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:i+4e7sFOZNHPxnXDcsTB45djzIjb0bn1jrxEe9IOldX UrS/lhFAn2rigpjmhyCcLGPxI1/R/wRxfZalh6r8QEkXso8VHj P7c2Ae4PNAZ0ok/95URCUoRqodQuhpI1cbh8GsE99ng30FsNhc OtDYz8UHTJ2n4jizpcpHYVcVJJvkm6gvkBwp4jQ7lxJNk8SjYh oxT7EzM+Zm44lZznpqgZh7Hi/QhQfPubF68m0x9L0PQS3R/kkY ivI7oIpMu1zi5F3zJ3GRwmXm3iB4TKtHATXhJwgzAbrmpLaTKg MKUH5kcKeq/m8kkyvD4ClITA8NdAiI+rkOgvICIcXw9FTNbbjT ovqLfpI20oxawGdpO08DydWNXxY5A5jx7M41xFeXVrsV51rrGq yCKnWySUWD6gA== Cc: pcp@ietf.org Subject: Re: [pcp] Server's auth policy discovery 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, 12 Oct 2012 11:41:52 -0000 Sam, On Oct 12, 2012, at 2:35 PM, Sam Hartman wrote: >>>>>> "Yoshihiro" == Yoshihiro Ohba writes: > > Yoshihiro> Is discoverying binary policy (auth > Yoshihiro> unsupported/supported) is enough, or is discovering > Yoshihiro> three-policy (auth unsupported/mandated/optional) needed? > > I think discovering auth supported is sufficient. So, you suggest eliminating case 2 below? 1. auth not used (not supported, or disabled) 2. use of auth is optional (i.e., PCP Client's decision) 3. auth is mandatory to use Alper From hartmans@painless-security.com Fri Oct 12 05:09:44 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138E721F857E for ; Fri, 12 Oct 2012 05:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.343 X-Spam-Level: **** X-Spam-Status: No, score=4.343 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.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 kShCeCSCVNYd for ; Fri, 12 Oct 2012 05:09:43 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 86C9C21F8574 for ; Fri, 12 Oct 2012 05:09:43 -0700 (PDT) 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.suchdamage.org (Postfix) with ESMTPS id 4848320200; Fri, 12 Oct 2012 08:09:28 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6DDEE4AD5; Fri, 12 Oct 2012 08:09:40 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <0BC19EAB-01F2-4AB9-B706-FD7C98FFAE86@yegin.org> <5077FA0A.9030308@toshiba.co.jp> <22CCCEB5-FA7E-474A-B890-5A6EB16E44DB@yegin.org> Date: Fri, 12 Oct 2012 08:09:40 -0400 In-Reply-To: <22CCCEB5-FA7E-474A-B890-5A6EB16E44DB@yegin.org> (Alper Yegin's message of "Fri, 12 Oct 2012 14:41:29 +0300") 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] Server's auth policy discovery 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, 12 Oct 2012 12:09:44 -0000 >>>>> "Alper" == Alper Yegin writes: Alper> Sam, Alper> On Oct 12, 2012, at 2:35 PM, Sam Hartman wrote: >>>>>> "Yoshihiro" == Yoshihiro Ohba writes: >> Yoshihiro> Is discoverying binary policy (auth Yoshihiro> unsupported/supported) is enough, or is discovering Yoshihiro> three-policy (auth unsupported/mandated/optional) needed? >> >> I think discovering auth supported is sufficient. Alper> So, you suggest eliminating case 2 below? Alper> 1. auth not used (not supported, or disabled) 2. use of auth Alper> is optional (i.e., PCP Client's decision) 3. auth is Alper> mandatory to use No. I simply think that if you know whether the server supports auth then you can avoid sending auth to a server known not to support it, which is a problem in the PANA port sharing case. I guess what I should have said is that if clients who want to use auth have a way to discover if auth is supported, then I don't think we have any concerns. --Sam From alper.yegin@yegin.org Fri Oct 12 05:44:50 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F68121F84DC for ; Fri, 12 Oct 2012 05:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, 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 c1toNPE7vETM for ; Fri, 12 Oct 2012 05:44:49 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 1477121F84A2 for ; Fri, 12 Oct 2012 05:44:49 -0700 (PDT) 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 0Me8la-1T0Ajd06kY-00Pz7q; Fri, 12 Oct 2012 08:44:48 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Fri, 12 Oct 2012 15:44:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0BC19EAB-01F2-4AB9-B706-FD7C98FFAE86@yegin.org> <5077FA0A.9030308@toshiba.co.jp> <22CCCEB5-FA7E-474A-B890-5A6EB16E44DB@yegin.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:iWfwkQ1+RYHdB46epb3DeB3h9Mol3kc737ffzkPQSfi WdJUHyFIgPLdxJ5V4xm2+bZK300lx1VfJOLmUocn+JsYpSeiVZ BS5a0faWJQlUz1b3VEQkXxxpyjgP569rvQ5mysJwxvoCZzWSKg sRq/0kJ5809AuX/RK5lCcQLg1C6Nl5hg7sMtZNWqUze0cC/Nrf NRU5tyAhf2Lucb+/grg83P9rU63GXZGdHDDMg5v3BmQmTQocLE 9mlFgs2EIddpXjpPqgh2YIXJq2snuUa1iXhIufqK3hxa7vahxJ 8L9EYBtDg+MRDfkGiSemTzc8pFMo+csGBGmcHrqUBFFj/+/g64 G0TyDytwZ/8rmlqPUwb7LRJT9UIBa/hCG/i6EI21hOHHGCaDet 3NhiUoK269MkA== Cc: pcp@ietf.org Subject: Re: [pcp] Server's auth policy discovery 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, 12 Oct 2012 12:44:50 -0000 Sam, For a client to decide whether it will use auth or not, it needs to know = the server policy. A server that implements auth does not mean that the client must use = auth. Server may still be configured to allow unauth clients. This is why I have three distinct cases. And this I'm asking independent of the PANA port-sharing discussion. As for dealing with discovery for PANA port-sharing, either: - We agree that it's OK for all clients to start with "no auth", or - We use a DHCP-based solution (I know you are not happy with this), or - We use an ANNOUNCE-based auth policy discovery solution At least one of these would handle the issue. Alper On Oct 12, 2012, at 3:09 PM, Sam Hartman wrote: >>>>>> "Alper" =3D=3D Alper Yegin writes: >=20 > Alper> Sam, > Alper> On Oct 12, 2012, at 2:35 PM, Sam Hartman wrote: >=20 >>>>>>> "Yoshihiro" =3D=3D Yoshihiro Ohba = writes: >>>=20 > Yoshihiro> Is discoverying binary policy (auth > Yoshihiro> unsupported/supported) is enough, or is discovering > Yoshihiro> three-policy (auth unsupported/mandated/optional) = needed? >>>=20 >>> I think discovering auth supported is sufficient. >=20 > Alper> So, you suggest eliminating case 2 below? >=20 > Alper> 1. auth not used (not supported, or disabled) 2. use of auth > Alper> is optional (i.e., PCP Client's decision) 3. auth is > Alper> mandatory to use >=20 > No. I simply think that if you know whether the server supports auth > then you can avoid sending auth to a server known not to support it, > which is a problem in the PANA port sharing case. >=20 > I guess what I should have said is that if clients who want to use = auth > have a way to discover if auth is supported, then I don't think we = have > any concerns. >=20 > --Sam From hartmans@painless-security.com Fri Oct 12 05:56:39 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 541F821F84EF for ; Fri, 12 Oct 2012 05:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.342 X-Spam-Level: **** X-Spam-Status: No, score=4.342 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.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 uPQpgdCpbja7 for ; Fri, 12 Oct 2012 05:56:38 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id A995921F84CE for ; Fri, 12 Oct 2012 05:56:38 -0700 (PDT) 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.suchdamage.org (Postfix) with ESMTPS id 8564920200; Fri, 12 Oct 2012 08:56:23 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A09FC4AD5; Fri, 12 Oct 2012 08:56:35 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <0BC19EAB-01F2-4AB9-B706-FD7C98FFAE86@yegin.org> <5077FA0A.9030308@toshiba.co.jp> <22CCCEB5-FA7E-474A-B890-5A6EB16E44DB@yegin.org> Date: Fri, 12 Oct 2012 08:56:35 -0400 In-Reply-To: (Alper Yegin's message of "Fri, 12 Oct 2012 15:44:28 +0300") 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] Server's auth policy discovery 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, 12 Oct 2012 12:56:39 -0000 >>>>> "Alper" == Alper Yegin writes: Alper> Sam, For a client to decide whether it will use auth or not, Alper> it needs to know the server policy. A server that implements Alper> auth does not mean that the client must use auth. Server may Alper> still be configured to allow unauth clients. Alper> This is why I have three distinct cases. I understand that's your model. My model is different, but probably isomorphic. Alper> And this I'm asking independent of the PANA port-sharing Alper> discussion. Alper> As for dealing with discovery for PANA port-sharing, either: Alper> - We agree that it's OK for all clients to start with "no Alper> auth", or - We use a DHCP-based solution (I know you are not Or we have a capability discovery mechanism or we have a specific opcode for "do you support auth?" From margaretw42@gmail.com Fri Oct 12 05:57:08 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 5633C21F84EF for ; Fri, 12 Oct 2012 05:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 PRMJZ0pr474l for ; Fri, 12 Oct 2012 05:57:07 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 86BE421F84CE for ; Fri, 12 Oct 2012 05:57:07 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so2571256qcg.31 for ; Fri, 12 Oct 2012 05:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=YH0ZOyPgb/jHp7F1YfKDQT1H+xjQOZUsbA6zfEnmMWg=; b=dhsJnN/itps4iwDqTFwWVmWJHfd5zxJlNYzuhA/OrBPOe1BpzpMEeKsANFIw1wt/VZ 4egHEBxqQF/ZQhAoEQ41l6gtwv2lQrl8Hnl5dlKqMkM2BkGyfuXkFm2r2LrkaorKTIqT T2sIn4cpmznM1DNgU6l3wMW+9+pnAer71BCSbnSEK/zcUn3ChLo97GPGhi4ZqEpFgsKV cLCnTQzlKTpOnEzAs2DDMh0xQMXCa/EGGVxF3c0DRK+FEHZx+KxbLqcisO7w789j+u5w KeTHTjyA+v1oFdBq0PdAY5eelPOrnQ2kDZUESX1dqoa5bYLJwa7FOe4BAtUkw+3ri07u u5Iw== Received: by 10.224.138.143 with SMTP id a15mr7151804qau.64.1350046627092; Fri, 12 Oct 2012 05:57:07 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id gd19sm6448410qeb.0.2012.10.12.05.56.54 (version=SSLv3 cipher=OTHER); Fri, 12 Oct 2012 05:57:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-51-224742783 From: Margaret Wasserman In-Reply-To: Date: Fri, 12 Oct 2012 08:56:53 -0400 Message-Id: <3463AFCA-54F0-4D22-A286-DAEC67C7C852@lilacglade.org> References: <0BC19EAB-01F2-4AB9-B706-FD7C98FFAE86@yegin.org> <5077FA0A.9030308@toshiba.co.jp> <22CCCEB5-FA7E-474A-B890-5A6EB16E44DB@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Server's auth policy discovery 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, 12 Oct 2012 12:57:08 -0000 --Apple-Mail-51-224742783 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 12, 2012, at 8:44 AM, Alper Yegin wrote: >=20 > As for dealing with discovery for PANA port-sharing, either: > - We agree that it's OK for all clients to start with "no auth", or What does this mean? There are two cases I can think of where a client = might "start with" an authenticated request: 1) Where a client is configured to do so. or 2) Where a client is attempting to renew a mapping that was originally = granted via an authenticated request. How can we say, in either case, that the client should start with "no = auth"? > - We use a DHCP-based solution (I know you are not happy with this), = or > - We use an ANNOUNCE-based auth policy discovery solution >=20 > At least one of these would handle the issue. I think I am confused about what problem you are trying to solve here... If a client sends an authenticated request in either of the encapsulated = cases (PANA or PCP-Specific), an error will be returned (by the PCP = server) indicating (to the PCP client) that the opcode is not supported, = and the client will know that authentication is not supported. If the = client is willing to try an unauthenticated request, it can do so at = that time. The only problem that I am aware of is for the demux case, because the = error will not be returned to the process that is actually trying to do = the authentication (the PANA client_ -- it will go back to the PCP = client. Therefore, the PANA client might keep retrying, even though the = PCP server has returned an error. Also, the PCP client needs to include = special handling of the "unsupported version" error that occurs when = authentication is being attempted, so that it knows to try an = unauthenticated request. =20 Margaret --Apple-Mail-51-224742783 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

As for dealing = with discovery for PANA port-sharing, either:
- We agree that it's OK = for all clients to start with "no auth", = or

What does this mean?  There = are two cases I can think of where a client might "start with" an = authenticated request:

1) Where a client is = configured to do so.
or
2) Where a client is = attempting to renew a mapping that was originally granted via an = authenticated request.

How can we say, in = either case, that the client should start with "no = auth"?

- We use = a DHCP-based solution (I know you are not happy with this), or
- We = use an ANNOUNCE-based auth policy discovery solution

At least one = of these would handle the issue.

I = think I am confused about what problem you are trying to solve = here...

If a client sends an authenticated = request in either of the encapsulated cases (PANA or PCP-Specific), an = error will be returned (by the PCP server) indicating (to the PCP = client) that the opcode is not supported, and the client will know that = authentication is not supported.  If the client is willing to try = an unauthenticated request, it can do so at that = time.

The only problem that I am aware of is = for the demux case, because the error will not be returned to the = process that is actually trying to do the authentication (the PANA = client_ -- it will go back to the PCP client.  Therefore, the PANA = client might keep retrying, even though the PCP server has returned an = error.  Also, the PCP client needs to include special handling of = the "unsupported version" error that occurs when authentication is being = attempted, so that it knows to try an unauthenticated request. =  

Margaret


= --Apple-Mail-51-224742783-- From alper.yegin@yegin.org Fri Oct 12 06:29:02 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4072421F84BF for ; Fri, 12 Oct 2012 06:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 DSIJdf+cdxL0 for ; Fri, 12 Oct 2012 06:29:01 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8884121F84A6 for ; Fri, 12 Oct 2012 06:29:01 -0700 (PDT) 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 0LiTe0-1TuteT2c8K-00caGt; Fri, 12 Oct 2012 09:28:59 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_5DD46DD1-F727-460D-884E-4EA2AC67998E" From: Alper Yegin In-Reply-To: <3463AFCA-54F0-4D22-A286-DAEC67C7C852@lilacglade.org> Date: Fri, 12 Oct 2012 16:28:39 +0300 Message-Id: References: <0BC19EAB-01F2-4AB9-B706-FD7C98FFAE86@yegin.org> <5077FA0A.9030308@toshiba.co.jp> <22CCCEB5-FA7E-474A-B890-5A6EB16E44DB@yegin.org> <3463AFCA-54F0-4D22-A286-DAEC67C7C852@lilacglade.org> To: Margaret Wasserman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:BCnvoUrpQq7bisYfwj2caiOJqf101BDjum6qPXLPZxe O2Ba2iBdFCgFXsfnJEGCnkwl/OGeEnDhSHlCot1TFu1PM7G27B ozPAob8MhdBoMUcEJEAsawzRszKwBazubDUuQ/IByA9WBoWwvp 32Yjz6iB7lczqd0KuwJw1u6TsyMeklAAJ/PGZkQkGlrtPyHLjt tSGSeCofE0FUflyduyJcq4BGyRPDdixyqyoTCZL2OBy30gFZGQ x9z/+Fqh+ajpfvrYTJ/UnGeJr/0HuZHXlVMRhRU7AD+PO4Uogc IlGHD1ZALwTbnbJtroN/O63WfRSTBhyxJm9a3Dc5BEZx6yZVQM Mbs+xkWKUqkVKExr15IILbmf65xmS2rMHu/vrMb6B95R0Otap+ lz1m3kju0Y8iw== Cc: pcp@ietf.org Subject: Re: [pcp] Server's auth policy discovery 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, 12 Oct 2012 13:29:02 -0000 --Apple-Mail=_5DD46DD1-F727-460D-884E-4EA2AC67998E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > On Oct 12, 2012, at 8:44 AM, Alper Yegin wrote: >>=20 >> As for dealing with discovery for PANA port-sharing, either: >> - We agree that it's OK for all clients to start with "no auth", or >=20 > What does this mean? There are two cases I can think of where a = client might "start with" an authenticated request: >=20 > 1) Where a client is configured to do so. > or > 2) Where a client is attempting to renew a mapping that was originally = granted via an authenticated request. >=20 > How can we say, in either case, that the client should start with "no = auth"? >=20 Let me expand on it. A client that does not know the server's authentication policy needs to = discover the server's policy. One of the ways to achieve that discovery (as there are two others = below) is for such client to send an unauthenticated PCP request and see = what happens. If the server accepts that request (i.e., no auth error is returned), = then client now knows this server allows unauthenticated PCP requests. If the server returns an auth error, then now the client knows this = server does not allow unauthenticated PCP requests. >> - We use a DHCP-based solution (I know you are not happy with this), = or >> - We use an ANNOUNCE-based auth policy discovery solution >>=20 >> At least one of these would handle the issue. >=20 > I think I am confused about what problem you are trying to solve = here... >=20 > If a client sends an authenticated request in either of the = encapsulated cases (PANA or PCP-Specific), an error will be returned (by = the PCP server) indicating (to the PCP client) that the opcode is not = supported, and the client will know that authentication is not = supported. If the client is willing to try an unauthenticated request, = it can do so at that time. >=20 > The only problem that I am aware of is for the demux case, because the = error will not be returned to the process that is actually trying to do = the authentication (the PANA client_ -- it will go back to the PCP = client. Therefore, the PANA client might keep retrying, even though the = PCP server has returned an error. Also, the PCP client needs to include = special handling of the "unsupported version" error that occurs when = authentication is being attempted, so that it knows to try an = unauthenticated request. =20 >=20 This is the issue we are addressing with the 3 approaches I enumerated. Alper > Margaret >=20 >=20 --Apple-Mail=_5DD46DD1-F727-460D-884E-4EA2AC67998E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Oct 12, = 2012, at 8:44 AM, Alper Yegin wrote:

As for = dealing with discovery for PANA port-sharing, either:
- We agree that = it's OK for all clients to start with "no auth", = or

What does this mean?  There = are two cases I can think of where a client might "start with" an = authenticated request:

1) Where a client is = configured to do so.
or
2) Where a client is = attempting to renew a mapping that was originally granted via an = authenticated request.

How can we say, in = either case, that the client should start with "no = auth"?



Let me expand on it.
A client that does not know the = server's authentication policy needs to discover the server's = policy.
One of the ways to achieve that discovery (as there = are two others below) is for such client to send an unauthenticated PCP = request and see what happens.
If the server accepts that = request (i.e., no auth error is returned), then client now knows this = server allows unauthenticated PCP requests.
If the server = returns an auth error, then now the client knows this server does not = allow unauthenticated PCP = requests.



- We use a DHCP-based solution (I know you are not = happy with this), or
- We use an ANNOUNCE-based auth policy discovery = solution

At least one of these would handle the = issue.

I think I am confused about what = problem you are trying to solve here...

If a = client sends an authenticated request in either of the encapsulated = cases (PANA or PCP-Specific), an error will be returned (by the PCP = server) indicating (to the PCP client) that the opcode is not supported, = and the client will know that authentication is not supported.  If = the client is willing to try an unauthenticated request, it can do so at = that time.

The only problem that I am aware of = is for the demux case, because the error will not be returned to the = process that is actually trying to do the authentication (the PANA = client_ -- it will go back to the PCP client.  Therefore, the PANA = client might keep retrying, even though the PCP server has returned an = error.  Also, the PCP client needs to include special handling of = the "unsupported version" error that occurs when authentication is being = attempted, so that it knows to try an unauthenticated request. =  



This is the issue we are addressing with the 3 approaches I = enumerated.

Alper







<= /div>
; Sun, 14 Oct 2012 14:01:16 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.203]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Sun, 14 Oct 2012 09:01:16 -0500 From: "Prashanth Patil (praspati)" To: "pcp@ietf.org" Thread-Topic: New Version Notification for draft-patil-pcp-multihoming-00.txt Thread-Index: AQHNp6DQ8UWiVLIBUUmZ5Sj6OlQ3Epe5iYGA Date: Sun, 14 Oct 2012 14:01:15 +0000 Message-ID: In-Reply-To: <20121011110847.4463.15895.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.65.72.137] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19272.001 x-tm-as-result: No--37.509600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_B235506D63D65E43B2E40FD27715372E134B92A8xmbrcdx07ciscoc_" MIME-Version: 1.0 Cc: "Tirumaleswar Reddy \(tireddy\)" Subject: [pcp] FW: New Version Notification for draft-patil-pcp-multihoming-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: Sun, 14 Oct 2012 14:01:18 -0000 --_000_B235506D63D65E43B2E40FD27715372E134B92A8xmbrcdx07ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In a multihomed network, there may be multiple PCP servers providing NAT or= Firewall functions to hosts within the network. The main problem in such s= ituations is 'one client, multiple servers'. This draft discusses PCP clien= t behavior in such multihoming scenarios. Comments and feedback welcome. Thanks, Prashanth On 11/10/12 4:38 PM, "internet-drafts@ietf.org" > wrote: A new version of I-D, draft-patil-pcp-multihoming-00.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository. Filename: draft-patil-pcp-multihoming Revision: 00 Title: Using PCP to control NAT and Firewalls in Multihoming Creation date: 2012-10-11 WG ID: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-patil-pcp-multih= oming-00.txt Status: http://datatracker.ietf.org/doc/draft-patil-pcp-multihomin= g Htmlized: http://tools.ietf.org/html/draft-patil-pcp-multihoming-00 Abstract: This note describes how Port Control Protocol (PCP) can be used to control NATs and Firewalls in multihoming deployments. The IETF Secretariat --_000_B235506D63D65E43B2E40FD27715372E134B92A8xmbrcdx07ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <72B028C59E32CE4F8E7C041CE9EA0CC0@cisco.com> Content-Transfer-Encoding: quoted-printable
In a multihomed network, there may be multiple PCP servers providing N= AT or Firewall functions to hosts within the network. The main pr= oblem in such situations is 'one client, multiple servers'. This draft= discusses PCP client behavior in such multihoming scenarios.

Comments and feedback welcome.

Thanks,
Prashanth

On 11/10/12 4:38 PM, "internet-drafts@ietf.org" <internet-drafts@ietf.org> wrote= :


A new version of I-D, draft-patil-pcp-multihoming-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to th= e
IETF repository.

Filename: draft-patil-pcp-multihoming
Revision: 00
Title: Using PCP = to control NAT and Firewalls in Multihoming
Creation date: 2012-10-11
WG ID: Individual= Submission
Number of pages: 9
URL:           =   http://www.ietf.org/internet-drafts/draft-patil-pcp-multihoming-00.txt<= /div>


Abstract:
   This note describes how Port Control Protocol (PCP) can b= e used to
   control NATs and Firewalls in multihoming deployments.

           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       


The IETF Secretariat


--_000_B235506D63D65E43B2E40FD27715372E134B92A8xmbrcdx07ciscoc_-- From yoshihiro.ohba@toshiba.co.jp Mon Oct 15 16:11:49 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 0549C1F0423 for ; Mon, 15 Oct 2012 16:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.215 X-Spam-Level: X-Spam-Status: No, score=-7.215 tagged_above=-999 required=5 tests=[AWL=0.874, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, 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 U8-LNXEpDZSr for ; Mon, 15 Oct 2012 16:11:43 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 68A351F0381 for ; Mon, 15 Oct 2012 16:11:42 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q9FNBg11029614 for ; Tue, 16 Oct 2012 08:11:42 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q9FNBgvh014879 for pcp@ietf.org; Tue, 16 Oct 2012 08:11:42 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id JAA14868; Tue, 16 Oct 2012 08:11:41 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q9FNBfHa023263 for ; Tue, 16 Oct 2012 08:11:41 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q9FNBfwC000045; Tue, 16 Oct 2012 08:11:41 +0900 (JST) Received: from [133.196.20.181] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MBY005ROJ3HUNG0@mail.po.toshiba.co.jp> for pcp@ietf.org; Tue, 16 Oct 2012 08:11:41 +0900 (JST) Date: Tue, 16 Oct 2012 08:11:48 +0900 From: Yoshihiro Ohba To: "pcp@ietf.org" Message-id: <507C9834.6050700@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Subject: [pcp] Two PANA drafts are ready 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, 15 Oct 2012 23:11:49 -0000 The following two drafts for PANA-based approaches are ready for discussion in Oct-17 interim meeting. Side-by-side/port-sharing: http://tools.ietf.org/html/draft-ohba-pcp-pana-03 Encapsulation http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-00 Regards, Yoshihiro Ohba From hartmans@painless-security.com Mon Oct 15 20:56:50 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337351F0CA0 for ; Mon, 15 Oct 2012 20:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.365 X-Spam-Level: **** X-Spam-Status: No, score=4.365 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.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 UmdCfOlhUW0P for ; Mon, 15 Oct 2012 20:56:49 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 945A41F0C9C for ; Mon, 15 Oct 2012 20:56:49 -0700 (PDT) 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.suchdamage.org (Postfix) with ESMTPS id 6AA5120146 for ; Mon, 15 Oct 2012 23:56:33 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DE6EC4AD5; Mon, 15 Oct 2012 23:56:40 -0400 (EDT) From: Sam Hartman To: pcp@ietf.org Date: Mon, 15 Oct 2012 23:56:40 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [pcp] Agenda question about Wednesday's meeting 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, 16 Oct 2012 03:56:50 -0000 Hi. First, I want to thank the folks working on the PANA proposals. Based on discussion, I think the issues resolved at the last meeting regarding version negotiation and other discussions that were PANA-specific brought up at the meeting have been resolved to my satisfaction. I still prefer the PANA encapsulation option to the PANA demultiplexing option, although I agree that both PANA options will work. At last meeting, we got kind of stuck in the details of the specific proposals. It was good that we discussed the specific version number to use and it was good that we discussed some of the rationale for single ports. However, we didn't get around to discussing the broader architectural questions like: 1) Does PCP need re-authentication 2) Do we want authentication to be server or client initiated in PCP? ETc. We had some great discussion leading up to the last meeting and were approaching understanding of the architectural issues that I think we need to consider in order to make a decision about the authentication approach. However, we got stuck in the details and didn't get a chance to discuss these issues. I want to confirm that we're going to give priority to these architectural issues in this call, focusing on them rather than updates to the PANA proposals or discussion of the specifics of the PCP-specific approach. I hope we're all on the same page on that. If not, I'd like to start an agenda bashing discussion now. From dthaler@microsoft.com Mon Oct 15 21:36:46 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B681F0CA4 for ; Mon, 15 Oct 2012 21:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.943 X-Spam-Level: X-Spam-Status: No, score=-103.943 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 sIdc-j2yazKO for ; Mon, 15 Oct 2012 21:36:45 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE931F0CA8 for ; Mon, 15 Oct 2012 21:36:45 -0700 (PDT) Received: from mail101-am1-R.bigfish.com (10.3.201.229) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Tue, 16 Oct 2012 04:36:43 +0000 Received: from mail101-am1 (localhost [127.0.0.1]) by mail101-am1-R.bigfish.com (Postfix) with ESMTP id EE9B2C012F; Tue, 16 Oct 2012 04:36:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz9371I542M1432Izz1202h1d1ah1d2ahzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received-SPF: pass (mail101-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail101-am1 (localhost.localdomain [127.0.0.1]) by mail101-am1 (MessageSwitch) id 1350362201738320_26627; Tue, 16 Oct 2012 04:36:41 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.238]) by mail101-am1.bigfish.com (Postfix) with ESMTP id A93863E0060; Tue, 16 Oct 2012 04:36:41 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 16 Oct 2012 04:36:40 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.318.3; Tue, 16 Oct 2012 04:36:38 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.318.3; Mon, 15 Oct 2012 21:36:37 -0700 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.111]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0318.003; Mon, 15 Oct 2012 21:36:37 -0700 From: Dave Thaler To: Sam Hartman , "pcp@ietf.org" Thread-Topic: [pcp] Agenda question about Wednesday's meeting Thread-Index: AQHNq1JJqaYRxcMAAUezIFxTjuMPZpe7V85Q Date: Tue, 16 Oct 2012 04:36:36 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B855ED3@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [pcp] Agenda question about Wednesday's meeting 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, 16 Oct 2012 04:36:46 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Sam Hartman > Sent: Monday, October 15, 2012 8:57 PM > To: pcp@ietf.org > Subject: [pcp] Agenda question about Wednesday's meeting >=20 > Hi. > First, I want to thank the folks working on the PANA proposals. > Based on discussion, I think the issues resolved at the last meeting rega= rding > version negotiation and other discussions that were PANA-specific brought > up at the meeting have been resolved to my satisfaction. > I still prefer the PANA encapsulation option to the PANA demultiplexing > option, although I agree that both PANA options will work. >=20 > At last meeting, we got kind of stuck in the details of the specific prop= osals. It > was good that we discussed the specific version number to use and it was > good that we discussed some of the rationale for single ports. > However, we didn't get around to discussing the broader architectural > questions like: >=20 > 1) Does PCP need re-authentication >=20 > 2) Do we want authentication to be server or client initiated in PCP? >=20 > ETc. > We had some great discussion leading up to the last meeting and were > approaching understanding of the architectural issues that I think we nee= d to > consider in order to make a decision about the authentication approach. > However, we got stuck in the details and didn't get a chance to discuss = these > issues. >=20 > I want to confirm that we're going to give priority to these architectura= l issues > in this call, focusing on them rather than updates to the PANA proposals = or > discussion of the specifics of the PCP-specific approach. I hope we're a= ll on > the same page on that. If not, I'd like to start an agenda bashing discu= ssion > now. > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp Unless my co-chair disagrees, that is my plan. We didn't get to Margaret'= s slides last time so assuming she's willing, I'll let her present first and = hopefully that will generate a good discussion of architectural issues. =20 The two PANA drafts are quite short and last meeting I think folks generall= y understood at a high level the differences, although it's great to see they= got updated/written up accordingly. -Dave From alper.yegin@yegin.org Mon Oct 15 23:25: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 8318A21F87EF for ; Mon, 15 Oct 2012 23:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, 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 OtTeHLItRwiK for ; Mon, 15 Oct 2012 23:25:35 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id E19A921F87EA for ; Mon, 15 Oct 2012 23:25:34 -0700 (PDT) Received: from [192.168.2.4] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MeQLf-1SzR9p1YFz-00Q7YS; Tue, 16 Oct 2012 02:25:33 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: Date: Tue, 16 Oct 2012 09:25:16 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:eENszQ+EkHonmY8aUrR/ig6nzoXR+P6/WRBn4N0TRvN wGlZ+y4dG0AOm8r6iQtuuG84pyH8wKx6FXhouJDrhWnqugClF2 ln+riFhBUPyijnn/1g1pDOj2EPz+9y5D1g7Ok2x7wQu1Febu0K 10iP4aBXycyzfOx9O6GYToZWq7dMDUDPNQseKBAtHKpVw6RoOZ ZDf/ip69A0szcXr35UZCj/Er4amGDjc16b/55Js/fxmZDjHMOb vfzl1nOFsAG1G5hGjWl+wBCATDPBVsQLg7olIAi8QdVVgeddpU sdcLukOuAEc3lSoSWkE5DxR3n0hxIJDnarASiy2n9YqH4MLZKw kbmp903cpe5IvIOIL16jSFTqIHqmuKLHUo6pb5ziP/io/mxIXi oKPaCDwBXhzDA== Cc: pcp@ietf.org Subject: [pcp] Architectural questions (was Re: Agenda question about Wednesday's meeting) 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, 16 Oct 2012 06:25:35 -0000 Hi Sam, > However, we didn't get around to discussing the broader architectural > questions like: >=20 Let's get these rolling=85. > 1) Does PCP need re-authentication >=20 Authentication is for authorization, and it comes with finite lifetime. The authorized service (e.g., "port mapping", "firewall rule") is good = within the authorized lifetime of the service. Before the lifetime exceeds, authorization either needs to be "extended" = via re-authentication, or left to expire and disappear. We need to support re-authentication for PCP. > 2) Do we want authentication to be server or client initiated in PCP? >=20 EAP (RFC 3748) by its design is server initiated and driven (requests = always come from the server side). "EAP" can be triggered externally (e.g., by the mean of "EAP lower = layer") from client side. Having provided these background info, what's the significance of this = question? Alper =20 > ETc. From dxhbupt@gmail.com Tue Oct 16 01:42:02 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF77A21F8861 for ; Tue, 16 Oct 2012 01:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yB8B7feJCRlx for ; Tue, 16 Oct 2012 01:42:02 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CA75821F883D for ; Tue, 16 Oct 2012 01:41:54 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so4525051lam.31 for ; Tue, 16 Oct 2012 01:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=mV/JtOpVlHx33m5OeBh45mwZ6nY81vcS40wP0ZqBvso=; b=rfF325tY6lTUISAKIo/cVDrwUiRAoqiG9tYguDq3YFzsy4WWI+CmDrRsuBplVhnbp8 I3F6kPkMvM0LfvmNpOkNnNjpKixE6A977iJkhtV4vmXsYID6ZIYkPZkNiFywrm0mZeN4 ZKmVZywILJUNGaTTZTFfFTvKwfJfUQdB402+9mDa0QSuSP0fhl0GeKDo4uHiB9NA5TG4 Qx82lAOT+UWMmyKn1R6ToOTAXOtm8lnc5QHFkknWJ2mfYQYReUF5BLkNsSxNKftLBwMH NW4tBW5bJYu/s+s2MLga1Y7Rbhvt66SeMYV8DSFB9P/a/eTH1hUdzH+pMdZARWkFa6D7 0x8g== MIME-Version: 1.0 Received: by 10.112.39.161 with SMTP id q1mr5211209lbk.131.1350376913829; Tue, 16 Oct 2012 01:41:53 -0700 (PDT) Received: by 10.112.59.137 with HTTP; Tue, 16 Oct 2012 01:41:53 -0700 (PDT) Date: Tue, 16 Oct 2012 16:41:53 +0800 Message-ID: From: Xiaohong Deng To: pcp@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [pcp] An open source PCP testing tool available 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, 16 Oct 2012 08:42:03 -0000 Hi all, FYI -An open source software of PCP testing tool, is made available and can be downloaded at: https://sourceforge.net/projects/pcptestingsuits/, and it is distributed under the Apache 2.0 license, the text of which is available at http://www.apache.org/licenses/LICENSE-2.0.html This testing tool consists of Port Control Protocol (PCP) functionality and a web UI, where user can specify each field of PCP packets, for testing purpose. Common request/response header, both MAP and PEER Opcode, and (filter and other) options are supported as per PCP base draft. It works in both server and client manner, aiming at providing a means to validate a third party=92s PCP client and/or server implementation. A PCP Wireshark dissector, implemented by a Luc script, is also coming along with this testing tool, to help with problem diagnosis. PCP base draft implementation refers to: http://tools.ietf.org/html/draft-ietf-pcp-base-24 Cheers, Xiaohong From dthaler@microsoft.com Tue Oct 16 13:48: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 34B4B21F879E for ; Tue, 16 Oct 2012 13:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.434 X-Spam-Level: X-Spam-Status: No, score=-103.434 tagged_above=-999 required=5 tests=[AWL=-0.836, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 upbTBo+xzuW2 for ; Tue, 16 Oct 2012 13:48:10 -0700 (PDT) Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.28]) by ietfa.amsl.com (Postfix) with ESMTP id AD07A21F8797 for ; Tue, 16 Oct 2012 13:48:10 -0700 (PDT) Received: from BY2FFO11FD012.protection.gbl (10.1.15.201) by BY2FFO11HUB033.protection.gbl (10.1.14.117) with Microsoft SMTP Server (TLS) id 15.0.516.0; Tue, 16 Oct 2012 20:49:11 +0000 Received: from TK5EX14HUBC106.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.516.0 via Frontend Transport; Tue, 16 Oct 2012 20:49:11 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.318.3; Tue, 16 Oct 2012 20:47:40 +0000 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.111]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0318.003; Tue, 16 Oct 2012 13:47:40 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: PCP Interim Meeting WebEx info Thread-Index: Ac2r3v1AEIrOfgORS2iNZEMaOQ6dHg== Date: Tue, 16 Oct 2012 20:47:39 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B85CF49@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B85CF49TK5EX14MBXW603w_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(15594001)(74662001)(16406001)(15202345001)(33656001)(3846001)(20776001)(50986001)(31966008)(47976001)(44976002)(47736001)(4396001)(42186003)(4196001)(1076001)(5343635001)(74502001)(551544001)(51856001)(49866001)(16826001)(47446002)(5343655001)(16696001)(8716001)(46102001)(512874001)(316001)(3556001)(3746001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0636271852 Subject: [pcp] PCP Interim Meeting WebEx info 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, 16 Oct 2012 20:48:12 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B85CF49TK5EX14MBXW603w_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2Ugbm93IGhhdmUgb2ZmaWNpYWwgSUVURiBXZWJFeCBzdXBwb3J0LiAgIENvbm5lY3Rpb24gaW5m b3JtYXRpb24gaXMgYmVsb3cuDQoNCi1EYXZlDQoNClRvcGljOiBQQ1AgSW50ZXJpbSBNZWV0aW5n DQpEYXRlOiBXZWRuZXNkYXksIE9jdG9iZXIgMTcsIDIwMTINClRpbWU6IDc6MDAgYW0sIFBhY2lm aWMgRGF5bGlnaHQgVGltZSAoU2FuIEZyYW5jaXNjbywgR01ULTA3OjAwKQ0KTWVldGluZyBOdW1i ZXI6IDY0MCA4MjYgMjIyDQpNZWV0aW5nIFBhc3N3b3JkOiAxMjM0NTY3OA0KDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRvIGpvaW4g dGhlIG9ubGluZSBtZWV0aW5nIChOb3cgZnJvbSBtb2JpbGUgZGV2aWNlcyEpDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoxLiBHbyB0byBo dHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/RUQ9MTYyNjEwNjU3JlVJRD0xMjgxMTky MDM3JlBXPU5OakUxTldSbU9UVTAmUlQ9TWlNMA0KMi4gSWYgcmVxdWVzdGVkLCBlbnRlciB5b3Vy IG5hbWUgYW5kIGVtYWlsIGFkZHJlc3MuDQozLiBJZiBhIHBhc3N3b3JkIGlzIHJlcXVpcmVkLCBl bnRlciB0aGUgbWVldGluZyBwYXNzd29yZDogMTIzNDU2NzgNCjQuIENsaWNrICJKb2luIi4NCg0K VG8gdmlldyBpbiBvdGhlciB0aW1lIHpvbmVzIG9yIGxhbmd1YWdlcywgcGxlYXNlIGNsaWNrIHRo ZSBsaW5rOg0KaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP0VEPTE2MjYxMDY1NyZV SUQ9MTI4MTE5MjAzNyZQVz1OTmpFMU5XUm1PVFUwJk9SVD1NaU0wDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRvIGpvaW4gdGhlIGF1 ZGlvIGNvbmZlcmVuY2Ugb25seQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTogMS02 NTAtNDc5LTMyMDgNCg0KQWNjZXNzIGNvZGU6NjQwIDgyNiAyMjINCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRm9yIGFzc2lzdGFuY2UN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N CjEuIEdvIHRvIGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tYw0KMi4gT24gdGhlIGxlZnQg bmF2aWdhdGlvbiBiYXIsIGNsaWNrICJTdXBwb3J0Ii4NCg0KWW91IGNhbiBjb250YWN0IG1lIGF0 Og0KcGNwLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86cGNwLWNoYWlyc0B0b29scy5pZXRm Lm9yZz4NCg0KDQpUbyB1cGRhdGUgdGhpcyBtZWV0aW5nIHRvIHlvdXIgY2FsZW5kYXIgcHJvZ3Jh bSAoZm9yIGV4YW1wbGUgTWljcm9zb2Z0IE91dGxvb2spLCBjbGljayB0aGlzIGxpbms6DQpodHRw czovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/RUQ9MTYyNjEwNjU3JlVJRD0xMjgxMTkyMDM3 JklDUz1NUlMxJkxEPTEmUkQ9MiZTVD0xJlNIQTI9QUFBQUFrVHljUloyYTBNT09XeG5WY2pxbjBm OXNGVFNyR0tmRU1RVS1xQmFhaHdYJlJUPU1pTTANCg0KDQpXZWJFeCB3aWxsIGF1dG9tYXRpY2Fs bHkgc2V0dXAgTWVldGluZyBNYW5hZ2VyIGZvciBXaW5kb3dzIHRoZSBmaXJzdCB0aW1lIHlvdSBq b2luIGEgbWVldGluZy4gVG8gc2F2ZSB0aW1lLCB5b3UgY2FuIHNldHVwIHByaW9yIHRvIHRoZSBt ZWV0aW5nIGJ5IGNsaWNraW5nIHRoaXMgbGluazoNCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 Zi9tZWV0aW5nY2VudGVyL21jc2V0dXAucGhwDQoNCg0KDQoNClNpZ24gdXAgZm9yIGEgZnJlZSB0 cmlhbCBvZiBXZWJFeA0KaHR0cDovL3d3dy53ZWJleC5jb20vZ28vbWNlbWZyZWV0cmlhbA0KDQpo dHRwOi8vd3d3LndlYmV4LmNvbQ0KDQpDQ1A6KzE2NTA0NzkzMjA4eDY0MDgyNjIyMiMNCg0KSU1Q T1JUQU5UIE5PVElDRTogVGhpcyBXZWJFeCBzZXJ2aWNlIGluY2x1ZGVzIGEgZmVhdHVyZSB0aGF0 IGFsbG93cyBhdWRpbyBhbmQgYW55IGRvY3VtZW50cyBhbmQgb3RoZXIgbWF0ZXJpYWxzIGV4Y2hh bmdlZCBvciB2aWV3ZWQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLiBCeSBqb2lu aW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29y ZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byB0aGUgcmVjb3JkaW5nLCBkaXNjdXNzIHlv dXIgY29uY2VybnMgd2l0aCB0aGUgbWVldGluZyBob3N0IHByaW9yIHRvIHRoZSBzdGFydCBvZiB0 aGUgcmVjb3JkaW5nIG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLiBQbGVhc2Ugbm90ZSB0aGF0 IGFueSBzdWNoIHJlY29yZGluZ3MgbWF5IGJlIHN1YmplY3QgdG8gZGlzY292ZXJ5IGluIHRoZSBl dmVudCBvZiBsaXRpZ2F0aW9uLg0K --_000_9B57C850BB53634CACEC56EF4853FF653B85CF49TK5EX14MBXW603w_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCW1zby1saWdhdHVyZXM6bm9uZTt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBub3cNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5oYXZlIG9mZmljaWFsIElFVEYgV2ViRXggc3VwcG9y dC4mbmJzcDsmbmJzcDsgQ29ubmVjdGlvbiBpbmZvcm1hdGlvbiBpcyBiZWxvdy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4t RGF2ZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGJyPg0KVG9waWM6 IFBDUCBJbnRlcmltIE1lZXRpbmcgPGJyPg0KRGF0ZTogV2VkbmVzZGF5LCBPY3RvYmVyIDE3LCAy MDEyIDxicj4NClRpbWU6IDc6MDAgYW0sIFBhY2lmaWMgRGF5bGlnaHQgVGltZSAoU2FuIEZyYW5j aXNjbywgR01ULTA3OjAwKSA8YnI+DQpNZWV0aW5nIE51bWJlcjogNjQwIDgyNiAyMjIgPGJyPg0K TWVldGluZyBQYXNzd29yZDogMTIzNDU2NzggPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8YnI+DQpUbyBqb2lu IHRoZSBvbmxpbmUgbWVldGluZyAoTm93IGZyb20gbW9iaWxlIGRldmljZXMhKSA8YnI+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIDxicj4N CjEuIEdvIHRvIDxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9FRD0x NjI2MTA2NTcmYW1wO1VJRD0xMjgxMTkyMDM3JmFtcDtQVz1OTmpFMU5XUm1PVFUwJmFtcDtSVD1N aU0wIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/ RUQ9MTYyNjEwNjU3JmFtcDtVSUQ9MTI4MTE5MjAzNyZhbXA7UFc9Tk5qRTFOV1JtT1RVMCZhbXA7 UlQ9TWlNMDwvYT4NCjxicj4NCjIuIElmIHJlcXVlc3RlZCwgZW50ZXIgeW91ciBuYW1lIGFuZCBl bWFpbCBhZGRyZXNzLiA8YnI+DQozLiBJZiBhIHBhc3N3b3JkIGlzIHJlcXVpcmVkLCBlbnRlciB0 aGUgbWVldGluZyBwYXNzd29yZDogMTIzNDU2NzggPGJyPg0KNC4gQ2xpY2sgJnF1b3Q7Sm9pbiZx dW90Oy4gPGJyPg0KPGJyPg0KVG8gdmlldyBpbiBvdGhlciB0aW1lIHpvbmVzIG9yIGxhbmd1YWdl cywgcGxlYXNlIGNsaWNrIHRoZSBsaW5rOiA8YnI+DQo8YSBocmVmPSJodHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvai5waHA/RUQ9MTYyNjEwNjU3JmFtcDtVSUQ9MTI4MTE5MjAzNyZhbXA7UFc9 Tk5qRTFOV1JtT1RVMCZhbXA7T1JUPU1pTTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2lldGYu d2ViZXguY29tL2lldGYvai5waHA/RUQ9MTYyNjEwNjU3JmFtcDtVSUQ9MTI4MTE5MjAzNyZhbXA7 UFc9Tk5qRTFOV1JtT1RVMCZhbXA7T1JUPU1pTTA8L2E+DQo8YnI+DQo8YnI+DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIDxicj4NClRvIGpv aW4gdGhlIGF1ZGlvIGNvbmZlcmVuY2Ugb25seSA8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIDxicj4NCkNhbGwtaW4gdG9sbCBudW1i ZXIgKFVTL0NhbmFkYSk6IDEtNjUwLTQ3OS0zMjA4IDxicj4NCjxicj4NCkFjY2VzcyBjb2RlOjY0 MCA4MjYgMjIyIDxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KRm9yIGFzc2lzdGFuY2UgPGJyPg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8YnI+DQoxLiBH byB0byA8YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWM8L2E+DQo8YnI+DQoyLiBPbiB0aGUg bGVmdCBuYXZpZ2F0aW9uIGJhciwgY2xpY2sgJnF1b3Q7U3VwcG9ydCZxdW90Oy4gPGJyPg0KPGJy Pg0KWW91IGNhbiBjb250YWN0IG1lIGF0OiA8YnI+DQo8YSBocmVmPSJtYWlsdG86cGNwLWNoYWly c0B0b29scy5pZXRmLm9yZyI+cGNwLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT4gPGJyPg0KPGJy Pg0KPGJyPg0KVG8gdXBkYXRlIHRoaXMgbWVldGluZyB0byB5b3VyIGNhbGVuZGFyIHByb2dyYW0g KGZvciBleGFtcGxlIE1pY3Jvc29mdCBPdXRsb29rKSwgY2xpY2sgdGhpcyBsaW5rOg0KPGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP0VEPTE2MjYxMDY1NyZh bXA7VUlEPTEyODExOTIwMzcmYW1wO0lDUz1NUlMxJmFtcDtMRD0xJmFtcDtSRD0yJmFtcDtTVD0x JmFtcDtTSEEyPUFBQUFBa1R5Y1JaMmEwTU9PV3huVmNqcW4wZjlzRlRTckdLZkVNUVUtcUJhYWh3 WCZhbXA7UlQ9TWlNMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 Zi9qLnBocD9FRD0xNjI2MTA2NTcmYW1wO1VJRD0xMjgxMTkyMDM3JmFtcDtJQ1M9TVJTMSZhbXA7 TEQ9MSZhbXA7UkQ9MiZhbXA7U1Q9MSZhbXA7U0hBMj1BQUFBQWtUeWNSWjJhME1PT1d4blZjanFu MGY5c0ZUU3JHS2ZFTVFVLXFCYWFod1gmYW1wO1JUPU1pTTA8L2E+DQo8YnI+DQo8YnI+DQo8YnI+ DQpXZWJFeCB3aWxsIGF1dG9tYXRpY2FsbHkgc2V0dXAgTWVldGluZyBNYW5hZ2VyIGZvciBXaW5k b3dzIHRoZSBmaXJzdCB0aW1lIHlvdSBqb2luIGEgbWVldGluZy4gVG8gc2F2ZSB0aW1lLCB5b3Ug Y2FuIHNldHVwIHByaW9yIHRvIHRoZSBtZWV0aW5nIGJ5IGNsaWNraW5nIHRoaXMgbGluazoNCjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tZWV0aW5nY2VudGVyL21j c2V0dXAucGhwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21l ZXRpbmdjZW50ZXIvbWNzZXR1cC5waHA8L2E+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQpTaWduIHVwIGZvciBhIGZyZWUgdHJpYWwgb2YgV2ViRXggPGJyPg0KPGEgaHJlZj0iaHR0cDov L3d3dy53ZWJleC5jb20vZ28vbWNlbWZyZWV0cmlhbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93 d3cud2ViZXguY29tL2dvL21jZW1mcmVldHJpYWw8L2E+DQo8YnI+DQo8YnI+DQo8YSBocmVmPSJo dHRwOi8vd3d3LndlYmV4LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cud2ViZXguY29t PC9hPiA8YnI+DQo8YnI+DQpDQ1A6JiM0MzsxNjUwNDc5MzIwOHg2NDA4MjYyMjIjIDxicj4NCjxi cj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoaXMgV2ViRXggc2VydmljZSBpbmNsdWRlcyBhIGZlYXR1 cmUgdGhhdCBhbGxvd3MgYXVkaW8gYW5kIGFueSBkb2N1bWVudHMgYW5kIG90aGVyIG1hdGVyaWFs cyBleGNoYW5nZWQgb3Igdmlld2VkIGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZC4g Qnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3Vj aCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQNCiB0byB0aGUgcmVjb3JkaW5nLCBk aXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgbWVldGluZyBob3N0IHByaW9yIHRvIHRoZSBz dGFydCBvZiB0aGUgcmVjb3JkaW5nIG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLiBQbGVhc2Ug bm90ZSB0aGF0IGFueSBzdWNoIHJlY29yZGluZ3MgbWF5IGJlIHN1YmplY3QgdG8gZGlzY292ZXJ5 IGluIHRoZSBldmVudCBvZiBsaXRpZ2F0aW9uLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9B57C850BB53634CACEC56EF4853FF653B85CF49TK5EX14MBXW603w_-- From dthaler@microsoft.com Tue Oct 16 14:08:15 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEB611E80E4 for ; Tue, 16 Oct 2012 14:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.412 X-Spam-Level: X-Spam-Status: No, score=-103.412 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 K4RHAgDlOpiu for ; Tue, 16 Oct 2012 14:08:13 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1CF11E80D5 for ; Tue, 16 Oct 2012 14:08:13 -0700 (PDT) Received: from BL2FFO11FD016.protection.gbl (10.173.161.200) by BL2FFO11HUB029.protection.gbl (10.173.161.53) with Microsoft SMTP Server (TLS) id 15.0.516.0; Tue, 16 Oct 2012 21:09:08 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD016.mail.protection.outlook.com (10.173.160.224) with Microsoft SMTP Server (TLS) id 15.0.516.0 via Frontend Transport; Tue, 16 Oct 2012 21:09:07 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.2.318.3; Tue, 16 Oct 2012 21:07:45 +0000 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.111]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0318.003; Tue, 16 Oct 2012 14:07:45 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: Interim agenda/slides page active Thread-Index: Ac2r4khIrg17XChoSESsrY0xserLMg== Date: Tue, 16 Oct 2012 21:07:44 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B85D055@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B85D055TK5EX14MBXW603w_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(5343635001)(5343655001)(4396001)(8716001)(512954001)(74662001)(51856001)(1076001)(4196001)(16406001)(44976002)(16696001)(50986001)(47976001)(16826001)(49866001)(47736001)(3846001)(15202345001)(74502001)(47446002)(46102001)(42186003)(33656001)(20776001)(31966008)(316001)(3746001)(3556001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0636271852 Subject: [pcp] Interim agenda/slides page active 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, 16 Oct 2012 21:08:15 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B85D055TK5EX14MBXW603w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/proceedings/interim/2012/10/17/pcp/proceedings.html is now active. So far I have put up the slides received for the last interim that we didn'= t get to. Please submit any updated slides or additional requests to the chairs. Since this meeting is considered part 2 of the previous interim, only secur= ity items are in scope for this interim. -Dave --_000_9B57C850BB53634CACEC56EF4853FF653B85D055TK5EX14MBXW603w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://www.ietf.org/proceedings/interim/201= 2/10/17/pcp/proceedings.html

is now active.

 

So far I have put up the slides received for the las= t interim that we didn’t get to.

 

Please submit any updated slides or additional reque= sts to the chairs.

 

Since this meeting is considered part 2 of the previ= ous interim, only security items

are in scope for this interim.

 

-Dave

--_000_9B57C850BB53634CACEC56EF4853FF653B85D055TK5EX14MBXW603w_-- From dthaler@microsoft.com Tue Oct 16 14:38:11 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9683121F8744 for ; Tue, 16 Oct 2012 14:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.992 X-Spam-Level: X-Spam-Status: No, score=-102.992 tagged_above=-999 required=5 tests=[AWL=-1.193, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Vs2bX-X9TXPK for ; Tue, 16 Oct 2012 14:38:11 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.30]) by ietfa.amsl.com (Postfix) with ESMTP id DE21621F8743 for ; Tue, 16 Oct 2012 14:38:10 -0700 (PDT) Received: from BY2FFO11FD014.protection.gbl (10.1.15.201) by BY2FFO11HUB030.protection.gbl (10.1.14.115) with Microsoft SMTP Server (TLS) id 15.0.516.0; Tue, 16 Oct 2012 21:39:04 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD014.mail.protection.outlook.com (10.1.14.76) with Microsoft SMTP Server (TLS) id 15.0.516.0 via Frontend Transport; Tue, 16 Oct 2012 21:39:04 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.318.3; Tue, 16 Oct 2012 21:37:40 +0000 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.111]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0318.003; Tue, 16 Oct 2012 14:37:40 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: LAST CALL on three drafts: base, dhcp, and upnp-igd Thread-Index: Ac2r5naEfo+pQWJZTLCST4PXoGBf2g== Date: Tue, 16 Oct 2012 21:37:39 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B85DA95@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B85DA95TK5EX14MBXW603w_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(44976002)(74502001)(16826001)(512954001)(31966008)(16406001)(49866001)(51856001)(47446002)(1076001)(47736001)(4396001)(47976001)(3846001)(15202345001)(4196001)(50986001)(16696001)(46102001)(74662001)(33656001)(42186003)(5343635001)(8716001)(5343655001)(20776001)(316001)(3556001)(217873001)(3746001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0636271852 Subject: [pcp] LAST CALL on three drafts: base, dhcp, and upnp-igd 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, 16 Oct 2012 21:38:11 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B85DA95TK5EX14MBXW603w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This message begins a new WGLC on the following three drafts (all have been= through one WGLC already). draft-ietf-pcp-base-28 draft-ietf-pcp-dhcp-05 draft-ietf-pcp-upnp-igd-interworking-04 This last call will conclude on Tuesday October 30. -Dave --_000_9B57C850BB53634CACEC56EF4853FF653B85DA95TK5EX14MBXW603w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This message begins a new WGLC on the following thre= e drafts (all have been through one WGLC already).

 

draft-ietf-pcp-base-28

draft-ietf-pcp-dhcp-05

draft-ietf-pcp-upnp-igd-interworking-04

 

This last call will conclude on Tuesday October 30.<= o:p>

 

-Dave

--_000_9B57C850BB53634CACEC56EF4853FF653B85DA95TK5EX14MBXW603w_-- From phdgang@gmail.com Wed Oct 17 01:00:43 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4CF21F85E7 for ; Wed, 17 Oct 2012 01:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, 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 oQ7f9Q3Qq+cN for ; Wed, 17 Oct 2012 01:00:42 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5978F21F8593 for ; Wed, 17 Oct 2012 01:00:42 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so7820194vbb.31 for ; Wed, 17 Oct 2012 01:00:41 -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=jkkVCnwW+sBvTv+xhD2Z+0rYR5kTe6Nz41Xqayodbc4=; b=USbQUubuip28KaRGkffcooT3qG4FVoIRkGw99cG+8n3gFlv9ICUg1DdNKTMEWC/hT+ ODU8hXAUZJ4RLZC0nmVoEx60myI5whyer91IfTtaGDrqNGGVcuW/rj6PBZThVmZT0Q0q XeovpL+upeDgsT34m1K1/DuFARe7Suk9DLH6t2EviyAEe57AOzehkO8rM7bjaykPpgA7 KwylDS1orkQ/mLaNf9ZeW+3aj5mHlTh2qpNwGzdixVxZjGjIj2t85I411Q5TRgMCOnn8 o0WlQHKGamfZtMMONMAwLBD9249mUSezpm2VLYlLaok92yJj3rX2m3dO3yoq/2cAkSNp vGVQ== MIME-Version: 1.0 Received: by 10.58.18.239 with SMTP id z15mr10100091ved.27.1350460841674; Wed, 17 Oct 2012 01:00:41 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Wed, 17 Oct 2012 01:00:41 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Oct 2012 16:00:41 +0800 Message-ID: From: GangChen To: "Prashanth Patil (praspati)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "pcp@ietf.org" Subject: Re: [pcp] FW: New Version Notification for draft-rpcw-pcp-pmipv6-serv-discovery-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, 17 Oct 2012 08:00:43 -0000 Hello authors, Few questions are below trying to make further clarifications. 1. I have a little confusion on the statement " If the dynamic outbound mapping is for the local access network then there are two cases to consider - In the first case where there is a nested NAT[I-D.penno-pcp-nested-nat], the mobile access gateway will function as both PCP server and PCP proxy forwarding the accepted PCP request to CGN PCP server. In the second case, where there is no CGN, mobile access gateway will function as a PCP server in the local access network. " When the traffic is heading to the NAT in local access network, there is no NAT processing in homenet. Wondering to know what is the case of nested NAT you refer to? 2. What is the goal of designing mobility options? I read the Section 3, it seems a smart PCP proxy is sufficient to handle the traffic dispatch? what the consideration to this option? 3. How do you handle the case of IPv6 offloading? Best Regards Gang 2012/9/17, Prashanth Patil (praspati) : > This is an updated version after accommodating review comments. > > Comments and suggestions welcome. > > -Prashanth > > > >> >>On 31/08/12 8:53 PM, "internet-drafts@ietf.org" >>wrote: >> >>> >>>A new version of I-D, draft-rpcw-pcp-pmipv6-serv-discovery-01.txt >>>has been successfully submitted by Prashanth Patil and posted to the >>>IETF repository. >>> >>>Filename: draft-rpcw-pcp-pmipv6-serv-discovery >>>Revision: 01 >>>Title: PCP Server Discovery with IPv4 traffic offload for Proxy Mobile >>>IPv6 >>>Creation date: 2012-08-31 >>>WG ID: Individual Submission >>>Number of pages: 13 >>>URL: >>>http://www.ietf.org/internet-drafts/draft-rpcw-pcp-pmipv6-serv-discovery- >>>0 >>>1.txt >>>Status: >>>http://datatracker.ietf.org/doc/draft-rpcw-pcp-pmipv6-serv-discovery >>>Htmlized: >>>http://tools.ietf.org/html/draft-rpcw-pcp-pmipv6-serv-discovery-01 >>>Diff: >>>http://www.ietf.org/rfcdiff?url2=draft-rpcw-pcp-pmipv6-serv-discovery-01 >>> >>>Abstract: >>> This document proposes a solution to PCP Server Discovery problems in >>> Proxy Mobile IPv6 (PMIPv6) networks when both home network traffic >>> and traffic off-loaded to local access network require traversing a >>> gateway implementing NAT and/or Firewall. This draft proposes >>> enhancements to DHCPv4 Relay Agent by introducing a new sub-option >>> under DHCPv4 Relay Option and to PMIPv6 signaling through additional >>> options to Proxy Binding Update/Acknowledgement messages. >>> >>> >>> >>> >>> >>>The IETF Secretariat >>> >> > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From alper.yegin@yegin.org Wed Oct 17 05:55:16 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 6703421F87D3 for ; Wed, 17 Oct 2012 05:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 xDl0ETNxF1f4 for ; Wed, 17 Oct 2012 05:55:15 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id CD8DD21F87A8 for ; Wed, 17 Oct 2012 05:55:09 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LcSJK-1Tn2zM1za2-00jmLV; Wed, 17 Oct 2012 08:55:09 -0400 From: Alper Yegin Content-Type: multipart/alternative; boundary="Apple-Mail=_5353E846-2451-4131-B362-3AF5F2FFF4E9" Date: Wed, 17 Oct 2012 15:54:52 +0300 References: To: pcp@ietf.org Message-Id: <2A480A44-5E43-4A57-92F6-AF1AAF0D3D76@yegin.org> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:KiBmiUUZlsE5zTLwsdnmaxiEslDaaAwg7FQrCb980cZ uVyPDpw0FdRvcEDirwy5qHBvxAw7WRkpqxnonDEVU9+5PP/Xu+ hZqR3conwWrer0c4VP+OiJOVxSU7XsQF+WUF80CI65MmQJTLxd dSQj80RZ88vV9ApzR/uWSbkE/TQ1ZFTGhSvSRObPquzjvqDZ/3 OShRSG86zhFrLVrWFuXCpFiW7wxD2gMesC0Bz6+wlT9sdGX3ZL lKJRa+BgfkG3l4IyJ98kAZ8+vZWF4jHjx3mK+hUFrfIyXY2SSd y5a7UOkL8RfKqyVWFl66BxUYOlxsgoalUYkVG8DqB5B+hAPVYz po9GLiKT4KCGMZVWFL3d6+bhBGyA7SYdApx7wiA3TBlimjsPL2 E9CYtGONtgM1Q== Subject: [pcp] Fwd: PPT for today's discussion X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 12:55:16 -0000 --Apple-Mail=_5353E846-2451-4131-B362-3AF5F2FFF4E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, I sent this to the chairs, but due to timezone issue they may not have a = chance to upload until the last minute. So, here is one more PPT for today's discussions. Alper Begin forwarded message: > From: Alper Yegin > Subject: PPT for today's discussion > Date: October 17, 2012 12:23:38 PM GMT+03:00 > To: Dave Thaler , Alain Durand = > Cc: Yoshihiro Ohba , Yasuyuki Tanaka = , Subir Das >=20 > Dear PCP Chairs, >=20 > Please also add the attached PPT to today's agenda. >=20 > Thanks. >=20 > Alper >=20 >=20 --Apple-Mail=_5353E846-2451-4131-B362-3AF5F2FFF4E9 Content-Type: multipart/mixed; boundary="Apple-Mail=_4F89AB3A-B064-4727-B5F2-54754D37218E" --Apple-Mail=_4F89AB3A-B064-4727-B5F2-54754D37218E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: Alper Yegin <alper.yegin@yegin.org>
Subject: PPT for today's = discussion
Date: October 17, 2012 12:23:38 PM = GMT+03:00
To: Dave Thaler <dthaler@microsoft.com>, = Alain Durand <adurand@juniper.net>
=
Cc: Yoshihiro Ohba = <yoshihiro.ohba@toshiba.co.jp<= /a>>, Yasuyuki Tanaka <yatch@isl.rdc.toshiba.co.jp>, Subir Das <sdas@appcomsci.com>

Dear PCP Chairs,

Please also add the attached PPT to = today's = agenda.

Thanks.

Alper


= --Apple-Mail=_4F89AB3A-B064-4727-B5F2-54754D37218E Content-Disposition: attachment; filename=PCP-authentication.pptx Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="PCP-authentication.pptx" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCmETYRHwIAANUQAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM mEtv2zAMgO8D9h8MXYdYSbe13RCnhz1OexRo9wNUm0m0yZIgMVnz70fbeahBVtexjeQSg5ZJfqQU 0vT45jFX0RKcl0YnbBQPWQQ6NZnUs4T9uv86uGaRR6EzoYyGhK3As5vJ61fj+5UFH5G29gmbI9qP nPt0DrnwsbGgaWVqXC6QRDfjVqR/xAz4xXB4yVOjETQOsLDBJuPPMBULhdGXR7pdkZA6iz5VzxWu EiasVTIVSKC8WOUH9X5bmO0pyrxwXC4c1nmQek8l9LXU2V5AAzOdyhQyky5yCiO2DjxdS7RckSgp PHcHiJRF/x9QB8o382qrFMakWbryc2n9m3UqftIeOplBdCsc/hA5JYxbizxki59P6hGB7uKOcyF1 HYxXRPhdeMqO54Ew6possP0ipjVNPxxNCC56yUQTgrcnJ3h3coL3JyHQBsFv/h2B0PmpDGzXnYw5 VX6zwA3VE7FzrifW68iKwnbrjPVd79XWcB3BUsLfXgi2husIkNot8PK3/WaUZmo9igcFd7hS0Hne cWe6jqIs79/Eik7munJXQvskhO2SWnng6Fimfip6Fe+xTP3U+HZM/VT9dkz99IF2TJdd17sOzvjV GTJdnyHThzNkGg3PEeqUlTzoqu2L98u66q6Pty/NtR5pbi1fW2gMd9B88zdjaKE9sPQGBg4lPDuI bj3SXN3c4d60DcVHggyyA755+VFi8g8AAP//AwBQSwMEFAAGAAgAAAAhAKPsgiYNAQAA4gIAAAsA CAJfcmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACsksFOwzAMhu9IvEPk+5puIITQ0l0Q0m4IlQcwidsG2iRKPLS9 PWGHlUqjmgTH2PGf78/v9WY/9OKTYrLeKVgWJQhy2hvrWgWv9dPiHkRidAZ770jBgRJsquur9Qv1 yHkodTYkkVVcUtAxhwcpk+5owFT4QC53Gh8H5HyMrQyoP7AluSrLOxl/akA10RRboyBuzQ2I+hDy y3/RlgMxGmSU2kdahJjJItvsRdQYW2IFxuvnXE7HG0WmBnke6PZyIN80VtOj17uBHJ/xLGnP5AyZ eSQMYY5o+Z9EU+bxf0JgGSKlbOSY+xzQ6nKg3/dhzIy73fDm0PYjzSmtU694D9R+ZyYnm1l9AQAA //8DAFBLAwQUAAYACAAAACEAY1wjtMEAAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUx LnhtbC5yZWxzhI/BasMwEETvhfyD2HskO4dSimVfQiCQU3E+YJHWtogtCa0S6r+vjjYEepwd5s1O 0/0us3hRYhe8hlpWIMibYJ0fNdz7y/ELBGf0FufgScNKDF17+Gh+aMZcQjy5yKJQPGuYco7fSrGZ aEGWIZIvzhDSgrnINKqI5oEjqVNVfaq0ZUC7Y4qr1ZCutgbRr7E0/88Ow+AMnYN5LuTzmwrFs7N0 wzU8c8FiGilrkHJ7562oZXkfVNuo3dz2DwAA//8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAA IAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUyLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8i CJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJ GA7NclFfacBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhn uwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQ SwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNC54bWwu cmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIX vIa1rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cN acRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuoo a5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQBbd7ZIbgEAAL4HAAAfAAgBcHB0 L19yZWxzL3ByZXNlbnRhdGlvbi54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAALyVTWvDMAyG74P9h+D74qRf+6BpL2PQw2Cs3Q9wEzUxS2xjqd3672fK1iah9S6ml4Be Y+lBcvRO599NHe3AotQqY2mcsAhUrgupyox9rF7uHliEJFQhaq0gY3tANp/d3kzfoRbkLmElDUYu i8KMVUTmiXPMK2gExtqAcicbbRtBLrQlNyL/FCXwQZJMuG3nYLNOzmhRZMwuijRl0WpvXOn/k+vN RubwrPNtA4rO1OA7CV9vVht0SYUtgTJ2lGKHyvgFikFICnLtgRPBIeSHb+qFGAaFEOsalrSv3USP zaCT6CUJCYK1LOBVIIE9gbRE5K3A26CgQzoU7QH9onghgg7JAzHwDWgUfEDnOzH0QYyvBDHyQUyu BDH2QdyHhFCaAPv/S0tE3gq8T9Xt9nCrtXImobfUB+vIyDuhF+4xJJyxUrn9sgQi52ythdc74L04 jddSXTQFZ5bh+mcsYM+ajtLf2+Id1539AAAA//8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAA IAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU1LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8i CJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJ GA7NclFfacBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhn uwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQ SwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMy54bWwu cmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIX vIa1rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cN acRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuoo a5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQAuZBi/qQIAAOINAAAUAAAAcHB0 L3ByZXNlbnRhdGlvbi54bWzsl1FvmzAQx98n7Tsgv04dgRCgKKTSOlWq1GnRSD+AC5cE1djINmnS T7+z4xZK9tD38YZ9d3/f/Xx2nOXNsWHeAaSqBc9J8H1GPOClqGq+y8nj5u4qJZ7SlFeUCQ45OYEi N6uvX5Zt1kpQwDXVGOqhDFcZzcle6zbzfVXuoaHqu2iBo20rZEM1DuXOryR9QfmG+eFsFvsNrTlx 8fIz8WK7rUv4KcquweXPIhKYzUPt61a9qbWfURtW8TEltRcvRQtlTdmaqd98U2sGBatygpAUPUDR PSnQd4JrheiIRzstbkVjFNW6LnWHH8Z5hbAUq35RpUHeVw9Kj2a8GkXDIEqidB5HSFxmZgZ9A+Kv lv6/wrnQoEaSH+Z6kcSJfDC7LPa4taLTI6HRbC+VOqmRQ1/SsLz76lzYIh5UFBoFW9C7ORmY55fm IY/o0nw9iF5cmGPcq3easTGfaQ7zLF698piT6yCKZjP0L085idNFagf61GLbq1IC8Ojo0rMkXdi7 pwl707A1VrClHdMbOOpCnxisljTDufVauq8/a+kxak4a8KvHwmY3dGEHFrTo01D5YLuOsh2eUkY8 lNnQp+I1J9EiwWOERWpmXYA+8B/y2TakORPcDdEFN22HB2/d8VIb+yALhUoBFky8Z5DmIjCaxq4E q6u7mjE7MIcabpn0DhRX08dze4687Kqe4balJbL71vArpk1xNAM6MgA9G0o1MpSqx4GccN9o5ngY IfwMezRvECY+BorjM+/5nNsSb6j/vn8MFMcn6vkE8ySITfdPgAwVB2gxAJSGqb0eJkCGigMU94DC MMUGmjoI72VDxQFKBoCSaG5/qKYOMlQcoLQHZOjg+2O6gw7MUHGArgeA4kUyXdL26WOo2Jfs5RMT n7fDvzSrvwAAAP//AwBQSwMEFAAGAAgAAAAhAAKEM8WZBAAAvgsAABUAAABwcHQvc2xpZGVzL3Ns aWRlNC54bWysVttuGzcQfS/QfyD2qX1Y636F5UCSpSJA4giW/QEUl5IW4ZJbkitbLQLkQ9qfy5f0 DFcbubHlxm5eVisuOXPmzOHMnL+5zxTbSetSo0dR46weMamFSVK9GUW3N/O4HzHnuU64MlqOor10 0ZuLn386z4dOJQyntRvyUbT1Ph/Wak5sZcbdmcmlxre1sRn3+Gs3tcTyO1jNVK1Zr3drGU91dDhv v+e8Wa9TIS+NKDKpfWnESsU9kLttmrvKWv491nIrHcyE0/+CdIHIxFIl9OvyGyslvendbzZf5gsb Pl/tFpalCfiKmOYZaIlqhw+HbeGvxja81L45vqks8eH92mYX53yI2Nj9KAL5e3riEB/Ke89EuSiO q2L74Ym9Yjt7YnetcgAEX51SVGVEj8NpVuHcpF5J1vgaVbmV4+g7Iz46pg3ipPDL8MTVrjJGMZP5 fMv8Pgcznkwd9pUfAx/VfgdOA1n+fmKSPQW+wm9Y5EPl/NLvlQyEADYfwjgeoF9xUqjU8e2SrPOh v5iNF7GBluPFdFG7vVycgwAP/sMpPGEAvitHeC2ZOM1Hq+JjarSHWthCcSG3RiXSsia5hVaq2F/I TpogtxWBJ4ihsL6RSLvTw/UJOml063V6D9FXauk3mwOsR4w00x606s1el3Y81AJxTtArJirKyZ3G jR0X3qxTz9aIeim4QhZ7vQ4ZVXqZi2uZFIJu3SiC+xIAzJdpIxsvy9q0sBbcqj1LUXiyXEkvn8hc SB8elPqdOlD3vB7ep86h4jDogl1LXvgt/KQi3Hnmijw31p/29JzSbqTYalhSQJ0beFmpH4R5UniW SJduNCHnzElR2NTDjTXeCKNYStfPM8ndvrbm7pURXMs41TviA25ADLvbSqnYL6s9k1hmK2OtoXp9 QMPW1mRsMb4a/3qaspck5woxCCW5hec9+/L5LytjYSWSA5/khxWarhlhw31mW2OSL5//pvA5W0nv 8Y3nYIULlJot1wcbRUg5GcDu01Cfy+6UVEg6kS64TkmU1HRK5XBKwN1TX7SUiWPeMC48wzaAopqk zB3AKr4nyDqppBe+OSpvLJPO8Q0ifx3gGXFwFIhmBISZ9VE9H+XePdBV6h0zdwEdC+jiEt1BW5Ad tM0h6iPFaOXs7exmfhrhS7IP+RVOEsQUWcawkIBeBpQs45pvAtsU0S7FZWCZSQrF6Rqc9g4TC275 9ePWUFb+Q/34Qdte1kfaVR9ZKsTDropsBSk8bCat/9dMylaLgQymMa/9MYp+L7jFFYkwplCfCc0q NF4q/eHltR14jbGPZp8/J+3JbNC67MadcaMfX/bbjXgwa4zjfnfeGLTG/f5g0PgUHcYAR5FroCtb dfuYSNijtf9KzGPGsXIc0ND/3jk0+zzMTSiZBHAy6Dan/Uk8abTncfty0IvH824nnnda7fZ00h9P W7NPAJQ32sOy9Bj9tpppsfhojsxSYY0za3+GRlUrB9JaTrc7N2mYSRv1w2C74+hRnUGv20IP7oUO HKAF8iuwiKAaNYWy73n+YRfqEiZo5G4alnJUBerf2HrcQqGDtn8AAAD//wMAUEsDBBQABgAIAAAA IQCQmEd38QMAABwKAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTMueG1srFZdb9s2FH0fsP9A6Kl7UGz5 a7IRJ5AdezDQpEbsdsDeGIq2iFEkR9JO3KH/fYeS1axNYjRtH2zLFHl4z+G95/L88qGUZM+tE1qN o+SsHRGumM6F2o6j9+t5nEbEeapyKrXi4+jAXXR58esv52bkZE6wWrkRHUeF92bUajlW8JK6M224 wruNtiX1+Gu3rdzSe6CWstVptwetkgoVHdfbb1mvNxvB+JVmu5IrX4NYLqlH5K4QxjVo5lvQjOUO MNXqL0K6ADO2knn4dWZtOQ9Pav+HNSuztNXrm/3SEpFDr4goWkKWqHV8cZxW/VWYhofWV8u3DRId PWxseXFOR+BGHsYRxD+EbyyiI/7gCasH2eMoK949M5cVs2dmt5oNEMHnTQOrmtFTOp2Gzlp4yUny mVU9lWLpW83+dkRp8Az0a3rsZt+ABc4B3hTEHwyU8QHqOK9+WenRzHfQtBLLP0x0fgjE7/BbDdKR dH7lD5JXgiBsOgI4viC/pCFDuYrfrwI6HfmLP4sD2TlOltlNdnkO9h7iV0vwjdXYuNkFj7UML4vR bcSYauWRKmQpKeOFljm3pBP2RKI0xF8pjchxsI16r1ElEFUoqmzn9UZ4skFsK0YlhE777TYSSKqV Ybc837FQGOMIxYZhRAsNamUDxuuEzRRZzNbzoxHYnLy5nU9JPxkmvz0jc6X16ZPKpOU0PxCaa+N5 Tu4OxHG4EJVE+wL61pZjc/cyPhKHyL086nh6v7/E9o5zslj+HLjZerUg153rn4OWrRcrhLb+8DLc qaxfQy9OKD7+XpNgvLHTO8s4EaWRPJhl7ZHfB3+9k14AhzBdltwygTP6Cpj4gnpS0D0nhjqH8xSo GKsN8dz5E0d4itZceAdgQFp9BxovR/+aRLjhWym2AoCElnqHqtYbAqe1lLxJ+nGnTaRQ3IVRNEGO +rI4GnLLmVYbsSVohJW9kCVaGbkvBCsq6ZX2RHGeg3tYspwuT1QGV/mSWnr71MW+x6d6jU+tpEDE N7vyDgX0f7Pq/phZ1T6Obg9oXAY+jqN/dtTigCP0wOBjlRlWrh68/4fsfYM7RWis/056k9mwezWI +1mSxldpL4mHsySL08E8GXazNB0Ok0/Rsce4wFwhuroPdB9zBXhh7PWKVw2i6f5IkLcOzcRUTXln RQhwMhx0pukkniS9edy7Gv4eZ/NBP573u73edJJm0+7sEwIySW/E4HbBjRfNhQmDTy4ppWBWO73x Z6i0Vn3baRl9z63RqCdceJL28da0p7C9zmCACNJeOqjcvYqtUr+JFhSaiwyT9pqad/uq4HA/w+FN qyGDNA69AVMfpwTu0O0/AAAA//8DAFBLAwQUAAYACAAAACEAsVlHogQEAAB0CgAAFQAAAHBwdC9z bGlkZXMvc2xpZGUyLnhtbMxW3W4iNxi9r9R3sOYqq9aBgYEFFLLiJ1SV0gSF5KrqhfGYMK3Hdm1D oNVKfYe+YZ+kxx4m2S3ZVdJWVbmYMR7783eOz/dz9m5XSrIV1hVaDZP0tJkQobjOC3U/TO5uZ7SX EOeZypnUSgyTvXDJu/MvvzgzAydzgt3KDdgwWXtvBo2G42tRMneqjVD4ttK2ZB5/7X0jt+wBVkvZ aDWb3UbJCpUc9tuX7NerVcHFVPNNKZSvjFghmYfnbl0YV1szL7FmrHAwE3d/5NI5kPGFzMPbmVsr RBip7TfWLMzcxs9X27klRQ6+EqJYCVqSxuHDYVn8q7AMg8Zftt/Xlthgt7Ll+RkbABvZDROQvw9P bGIDsfOEV5P8aZavr59Zy9cXz6xu1AfAg8dDA6oK0TGcVg3ntvBSkPQRVbWUYeul5j85ojRwBvgV PH61rY0FzMG8WRO/N2DGB1OHddXHyEe93oHTSJbfjXW+D8CXeMdJNpDOL/xeikgI3GYDGMcD9EsW FCoUvVsE62zgz69N1MIZcHvQHhfjiX04sraPYUXAp2lo1zRMtPIQCZlLxsVay1xY0gqnQSI15FeS UuS40pq31/ARICqE02jj9arwRKqF4Tci3/AAGjab+EWeawbDjmMCwTcpmb0cJp00a3cguULlADlM 6GEi7FtuwjlXm/Jwi8yyZcHnwhY6PxwSg+HzF3LnEPBkProakZOb2YR00n5K/vjtd3IxmlONrEPv pvM3z9xXvDQ8Hn3tp1kGeERuZYy6F/kszZpdvtrpRZELutxThzc5KU7F6dcVBCRBMp/MSXCc+LUg DqFPjLb+Dfke2W3lqV4vGTXcUMMUo832D/8zbLcbpYQU+Ue4OLO2wFzEBYCfQIOywAxtNl+E6QNZ NZNKUFeoHwidEJAhRSDBqXwOXd0cB3MVtEci+LxgZwjWqNYVgnWYfFX+SKWvUsO/o+apWBUqCJoR JR6ChonUDxCxZHso4uRR1OCwEYRdq+KBOSdQCFWUBttAO8oXPNYe2mz9Z4S+LgtmdRZcyBAJyAVL oPwwFbb/WSqs6gO6CJhGk/HLMPl5w6wXFikpZsmYamO1CIKJg79bNlboVULB/nWcjS/67WmXdkZp j057WUr7F+mI9rqztN8e9Xr9fvo+OWQ9F5AreBfk6s9bT9EMey+R8DHjmHnqKlDiLx1KlYnFfmOL 4OC4321NemM6TrMZzab9t3Q063borNPOssm4N5q0L97DIZNmA25FFNG3dSOGyaPmpyy41U6v/CnX ZaPqohomCNfoIjZSafPQjW0Zsms7e9vOuv1OtxcTffQtsl97Cwh1g8Sl/Y6Z622MZ/R9uLxJnDKI kxDsWPq0JGAHb38CAAD//wMAUEsDBBQABgAIAAAAIQAWAAkHxAMAALUJAAAVAAAAcHB0L3NsaWRl cy9zbGlkZTEueG1szFZbc9o6EH7vzPkPGr+eIbaJCeAJdAIpnc7kwhT60EchC+wiSxpJUEjn/Pez WtlJmtBOHsOD0WV39e23F+ny46EWZM+NrZQcRelZEhEumSoquRlF35azziAi1lFZUKEkH0VHbqOP 438+XOrcioKAtrQ5HUWlczqPY8tKXlN7pjSXsLdWpqYOpmYTF4b+BKu1iLtJchHXtJJRo2/eoq/W 64rxa8V2NZcuGDFcUAfIbVlp21rTb7GmDbdgBrV/gzQGz9hCFP7f6qXh3I/k/rPRCz03uH23nxtS FcBXRCStgZYobjYaMZxKEINB/EJ901qi+WFt6vElzcE3chhFQP7Rf0GJ5vzgCAuL7GmVlfcnZFn5 6YR03B4ACB4P9V4Fj167023dWVZOcJI+ehVEKajeKLa1RCrw07sf3GN3+9aY99mb1yVxRw3MMGfQ WiMa9pGSVsUCrciXO0xUcfS+r+AfF2kurFu4o+DICSCnOdiHD0RAUJ+kXHa+Lbx1mrvxfDonVztX QmgrhsElt9yVqrCXwIaDYKA+fMEUoGiPhGGg5c/knP+NHOINQbDSyONoaDpJTliUj4R5773Oi1QY nA+gTDAfsnSY9ZJhcLHNin6/3828gM+NNOsnSbeHFD9Z0sa6z1zVxA9GkeHMITq6v7HOwwASGhHk IiB54qQNg28PoF8q8xAR8UXaUTRMswzOdjjJev0uTMzzndVvO05MlcD0ppKBHcwKxCIVREutqwZP iLunow07jvciBZYIFRvoUZBQESn4eklXi4dRhKf74104gdMbOTFbrE3fHGQzBZES8gU60HwnGfjT hopN+DoEjc2ZI3uKdgI/Vre7q90d9D9YpTmc/RXQWH84hmDLje+dPl5oSImqmFVC4MQ3RD4VJhh2 h1AzkCPPpRAoFsyaMiiaf+sfHeGaiNMXG5yGDWZfbDDbZEBAiBEWgbswbkrJ4/pzJaFj6cUbnFlt AodiV9+qIjjYS+DXwMDLwPuOpz9z2BdhyHo3/q6geZeVUeS+XNETVfqesFK7O+62FVlSSbfvHOxi t6oMuaanOt874vRKaG7Idw6VeSL4r1s0dur2WoZuCL3M3ze+L+5MNYp+TSbDi+50MOlM0mzWya6H /c7V7KLXmfXOs2w6GVxNzz/9B4Wq0yxnhuMl8aV9ycDiq9dDXTGjrFq7M6bqODxDYq1+cqNVhS+R NGmeM9g8oA8M+0m3G1o24AVsUAH4j2hh2L4wmDC3VN/voURoDg8nxw3UCyxpaFThqngm4n2Hl8n/ AAAA//8DAFBLAwQUAAYACAAAACEA6nB8+cIDAAA3CgAAFQAAAHBwdC9zbGlkZXMvc2xpZGU1Lnht bMRW227jNhB9L9B/IPSuyLLl1BbiLGzHLgpsHSPOfgBNUZGwFMmStGO32H/vIWVt2o2zu9kG6Isu vAznnOGcmat3h0aQPTe2VnISpRe9iHDJVFHLh0n04X4ZjyJiHZUFFUrySXTkNnp3/fNPVzq3oiDY LW1OJ1HlnM6TxLKKN9ReKM0l5kplGurwax6SwtBHWG1E0u/1LpOG1jI67Tffs1+VZc34jWK7hkvX GjFcUAfPbVVr21nT32NNG25hJuz+l0vXQMY2ovBvq+8N5/5L7n81eqPXJkyv9mtD6gJ8RUTSBrRE yWnitCz8SizDR/LF9ofOEs0PpWmur2gObOQwiUD+0T+xieb84AhrB9nTKKtuz6xl1eLM6qQ7AB58 PtSjahE9h9Pv4NzXTnCSfkbVLqXY+l6xj5ZIBZwefguPrfadMY/Zm9cVcUcNZpw3dVrXTgY+uvUW nAay3GGmiqMHvsU7DNJcWLdxR8EDIXCb5jCOB+gX1N9QLuMPG2+d5u56PV1N4y21vCBTrY2iuIz2 Ciw4BCFsxRNW4EB3Gj5bOl4mZdCRMlfS4cqQtaCMV0oU3JC+PxsXpiPglRTVBQLcsfgadjxgieSa 7pwqa0dK+LZhVIDwcX/Yw0UScqPZHS92zCfIJELSYRjegoOWYW/jdQRv6oLH22Ns8Sae7TPkBobx 8CHaixO6b8TNqHNh+tJS4PrrljZcUxNymqgyeEggXWQ9XxMFkYtdxePH2nDyUO+hRaQU/FBva1G7 49tAwR15Iyi3knsM8JjcQarMHrfaU062tUMCcl5Y4hTZckKFUIw6zENuid1prYzz6Pw7thU1/geK 3DLzMtCv5db9TkouTj68bOL/CfsKPCAJTkTgur+Ng28XzIVkVNtdW6zCVaw4LS5IPyOQeUPJ9ui4 JQhRG2NN2UfuzqB4nXRlnXRthM/Y1a7Z+hP+oV+D/6ZfrcSjEYBp9Al/TqI/dtQ4biKURy9tIWeD 4PuyED5+VPlLtBu+5v41y2aL8eDmMh5O01F8M8rSeLxIp/HocpmOB9PRaDxOP0Wn8mM9cgnv2hIx fOIU9vwYl8UamnH3vKS8VCxCzegaA4TvvUV90aFe70ztHZyNL/vz0Syepdkyzm7Gv8TT5eUwXg4H WTafjabzweITHNJpljPDg1791vVSGHzWvzQ1g0Sq0l0w1SRtI5Ro9ciNVnXohdLeqaHaU6+5o0HW y7JhNg6CH3wL7HfeAkLX4zBhfqf6dh+SH60bgjcPQxqq4csFlj4t8djB298AAAD//wMAUEsDBBQA BgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91 dDExLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92 mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVm oAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2l M3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAA LAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ0LnhtbC5yZWxzhI/BCsIwEETv gv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2 Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZV tVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbq a277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMv X3JlbHMvc2xpZGVMYXlvdXQzLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG 2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPm EuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L8392 6Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAA ACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ2Lnht bC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWT ErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+ OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCY esoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBw dC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ1LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7S ehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDij tzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2 iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA //8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMv c2xpZGVMYXlvdXQxLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jf m2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF 4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDM YyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEAZK/C gvMHAABYLgAAIQAAAHBwdC9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIxLnhtbOxaXW7jRhJ+XyB3 IJjHBUfir0hh5ECyR9kBnFlj7BygRbYsrimS22w5doIAc4e9QW6RzVuOMidJVXU3RdmSY+/ICysw YEhks1jdXd9X1VUlv/3mZllY11w0eVWObPdN37Z4mVZZXl6O7O8vpk5sW41kZcaKquQj+5Y39jdH X/3tbT1siuw71kguLNBRNkM2shdS1sNer0kXfMmaN1XNS3g2r8SSSbgVl71MsB9A97Loef1+1Fuy vLT1++Ix71fzeZ7ykypdLXkplRLBCyZh/c0irxujrX6MtlrwBtTQ2xtLOoL9pedFht+zS/X5kc+t PLsBK/X7rn30lg1pn/y4ENY1K0b27NK1e0dve/gKCOsrfLmpLwTneFVefyvq8/pM4E364fpMgE5Q aVslW4J9UQE90GJ0W4KYUrzx+qXRxIY3c7HEFYF5LFghoHiLn/ASG/IbaaVqMF2Ppot/bpFNF++2 SPfMBLC1dlLcldrR/e14ZjsXuSy4dVawlC+qIgOukIloh+o1sGJ9WqVXjVVWsGc0hdoqGMcoxv3j VPXCkrc1WEmiWi2nHsLKyla+IfuaRbdWCcIBkI5M4w2CyI837RN7XhLhc7SS6wZ+H25wLWtFtWjk t7xaWngxsgVPJRGBXZ82UokaEUJfLaQeyptJld0iGDP4BszB4+D9RSV+tK3ifdmM7MQNAphb0g2t 1LZE98ls44ksjiugHLzByhT0jOxUClpLCd42XslqnusVqSlx8qKR5/K24EQLAI8NwazwAQsqGDq8 FM7FR2UVeXRc5OmVJSuLZ7m0tKuT5SEigBY0jCTzkBZeZmdMsI+tMl46359rA8JkgJAxA1wq7uxm kN8yCOnbJZCHKr+UQGgTW3szLRHpgyR7Io9cIAxyiixqHG2DSEHohUnkazsYPzUseUFEQiY8iTvg ZFZxTSSk7T+dS2gwolKzwSXgFZFTfZhZKC48zNhznlZlZhX8mheP0EhMeljjxSIXj1dIKD+scFqt hFw8eomBYtZDpp3m860KIfDv1SMD45EnTG6GdNr2l3pkJiHR+BFiIivm2jMJH3LI/8EzIz+Evzue 6bm+34Z4PwpdL3z5jrkR4cnTTBynmH5duOiJrLiEBK6wcSzjcwzDaE4XoxOONVWRZ9O8KOgGE7R1 4iJvVD4j81KqVGYQrg+/NsuhWN/RA36qZqIHEApwIepaHzQ4F3nxvMgoz/nJjSduMu6PHffYnTj9 KBg48fRk4ITRSRi73tTzE/dnOAbpmM+AaTJfcr26o7DnQsbnumvfBr04x36ZHhqmT6sK09vu6UMO +aVcn8NRTej8e8UEzKD5rg6Jp5xEvusFJqXZTvg4Cf/ShDdZz8uj/H45GRlOnoMbc+vDajm7w0yK ZF/KTKjpQPU2chLxnxSMozD0HybnXz0aq4T85VGzjcaTYPIu8U8iJxy7sXMSB66TvHPHThxN3cQf x3HSicYNMq8EdmDElUefP/369edP/91DLKZywBTIkBNCLYUZPmaHK5GP7J8mkyTyjuOJM3GDqROc JANnPI1CZxr6QXA8icfH/rufYVm1GwxTwamcf5/ptgIM3msFLPNUVE01l2/SatlTPYVeXf3ARV3B GYiHTF/3Jqiyd5O+F7r9QZRQukBro1rBrBa2YNoFaSG+Y7UFzQA4jiUU9nC6juzsCq5mlx6OQXUs b+Aqu4IrlqbQgQAJfWFG4LkaaWV8MwK1kXoEG9MXZiQ0I3CGqUeRGYEIsijy8gqMgV+2Na+Kf6gB c4Wbo77OKbutVvJ9ppGAqGBG6BT33GAQxH4UJFCjDrF/Id5nurDfJQup2FpW13A7ZcFWrV6dXe6U Bfu0svp03ikLlmtldbzcKQv5bisb3bPMhh1CsHYrO/gTWcChlaUOxIbFN/UOOrJEvQdkoVHX6nUp 731AeAM403HpmEIDv5hbiwx6C4Ad5Cz0nUHfQmuXN9RNaJA01BegW4wOOhfUSSme0RZEwQs2O4eU 1LRhhFQNDM5Oy4kAXgLq2Mgr9S1MuoCuBHQLz1ZlCtPqpludTrC5ho2j9CzVCSstCRJSGNNPZ6sP 0LGkfLkTgaHJAnqvuMBu52NzY1CCqrsZNC2U0tQ59LZG9t+X/3IKidBDNsruPOBMPUibOw/SBh/s yqM3rQpdRWha3DPxkonTke0HXoIby0sI0WAqxwyYsuC57Q+mVG2QOxhMKygpMJtXZhqLnBXKGLPV 8YIJK4WPkf350y9qtAOVSh6eA6pyF1SlswOq0nkQKmK8h2WYgmMAcGDAa+Hw4hBKKojJukp78XD8 5x4cXvxcnrNHOBADHYD8NRymmdvBw4upLDoYPO67h/dskWyPeCAIGo+gg4fumh4wHlv8AwPgs5ws e8QDQdB4hGs8vH44IDat49Vh+cfvv90PV4cAB2Kg4Yg6cIRuQNHpUOHYdppjgvDi3QNB0HgMOngk A5cOv1c8HpMI7zFcIQgaj3iNh8ptN9KrwwpXB+sfCILGI+ngEccRNfpe/eP/7B8IAky5URrWw0ou uGgLRaiozhRqurZSP/V3f51fi5jCXZUxz1KwdCo8FVUPssIzTYz9FxCHZp/tJRf9O8srf8CfdpRA /gD/d+Q5OgKHRqDtNYkbezElXa8etqNKoJznlUHgYjvS9kGgWoivDNqRR0PSRmX/q4F2JLZROHgN 0tTcbjPNbnIJief6NyD8Fdf8R/jRHwAAAP//AwBQSwMEFAAGAAgAAAAhAEuUdzQKBAAAFQwAACIA AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTEueG1stFbbjts2EH0v0H8g1GetTN0sCWsH li9Fgc1mETt5ZyR6LYQSVZJ27BYB8lvt5+RLMqREb3bX3Trd7YtsicPDmXNmhnP5al8ztKNCVrwZ Ofhi4CDaFLysmtuR8261cBMHSUWakjDe0JFzoNJ5Nf75p8s2k6y8Ige+VQgwGpmRkbNRqs08TxYb WhN5wVvawNqai5ooeBW3XinIJ8CumecPBrFXk6px+v3inP18va4KOuPFtqaN6kAEZUSB/3JTtdKi teegtYJKgDG777ukDi1EC8SoVaUYnTTlau8gYy92sIKdMVBQLFmJGlLDh/dgWhWEIWOPgDG0ontl zGS7EpTqDc3uV9Eu2xthdl/vbgSqSo3Wozhev9CbmdcGzOCP92D7rUUi2X4t6vElyYAdtB85IOJB P2ETycAJVHQfi7uvxebNCdtiMz9h7dkDwIPjoaB/20X0OBzfhvOAFHwMr9tDAOOKFx8lajgErHno 4iyudxZVB6/PaTeo00RpPRzERQXKdRL1uzpTQ5PdLQ3V1v8jQXHsp+Ggo8kfhnGQ3OfKH0RDs64Z i5IIR35kDrFIcEgH3WZqn/PyoJn+AL8gqE6akUOJDr6DZVIt1YFRowewRjIICR5gzIguNCXc1dvO Vo2nrCo+IsURLSuFXhOpqEAmaqhEQLkEPRSkQ49Cm/KGCPL2CEYb992y9xYOA1eti8ZrTeY/Sxc8 lk4n0A0jBd1wVoIrvsaG3Lca/ScVNVcPRIRKgDS1KXC+mGE0hF5iUv6UlvEAp4le/7+0hBRDbMeO Bffj2mqGjbTynragsEmW7mFPMQQ9nUFLWnDoP4zuKDsD0Qj6NOJqU4nzAYMulZ8iYsG3Qm3OdjE8 A7FanwSEDviiFRLaCpkRRe8Vhgn7uYVRKrhw/4DLi7C105eE6eSmr+leaP583+BMOdoat23I9JrH jWcNF5a+cf4M41meJMncnQ9j3x3EYegmcTB0J8liOg3DIEpw/tnpe24JoaqqpvrW080n8jBcvRjf JRfg6qWXpTqyVC84103w+y5kMuK5ZK+V6Nj+fUsEnGAJ/5cm9COEvywjsWVkyaqSoutt/eEBL+ae ei4vMNoB9ElqTLN44VzMw3yeBrPYjSY4cWdJiN10jieQkAucBpMkSVN8zEWpI2/Auy4Vv37565ev X/5+gUw0t6Md1KAlX0m4ZVszP21FBSWT52nsT5PczXG4cMNZCtWyiCN3EQVhOM2TyTSYfwa3Whxm haBmqvyt7Kdb+PhoIq2rQnDJ1+qi4LXXjbZeyz9R0fLKTLd40I/IOwIXDI5xmODAT60I4KXpB9Zb CEGPpOZ6ZuI1ad/soGGQDIZxyO6p+dTC+A0JrE3vTHTsdpwffwMAAP//AwBQSwMEFAAGAAgAAAAh ADTNuc4fAQAAxwcAACwAAABwcHQvc2xpZGVNYXN0ZXJzL19yZWxzL3NsaWRlTWFzdGVyMS54bWwu cmVsc8TV3WrDIBgG4PPB7kG+88WYtukPNT0Zg8KORncBEr/8sESD2rHc/aQwSGBzFAKeCBp8ffIe 6PH01XfkE41tteLAkhQIqlLLVtUc3i8vTzsg1gklRacVchjRwql4fDi+YSec32SbdrDEpyjLoXFu OFBqywZ7YRM9oPJfKm164fzU1HQQ5YeokWZpmlMzzYBilknOkoM5S8aAXMbBH/1/uK6qtsRnXV57 VO6XM6jtWomvYtRX52OFqdFxSJLpup1OGEv8DwD9w5YtaXO+NJypbiv0NoYdSzLurijU0KIF3SvL QrJVzM5WIdk6pmwdkm1iyjYhWR5Tlodk25iybUjmb/Z4F+suJNvHlO1DMubfx3ilsfTHRmfPb/EN AAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVs cy9zbGlkZUxheW91dDIueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj 6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFF FoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfo EMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQBO NxzOxAMAADULAAAiAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEwLnhtbKxWXW/bNhR9 H7D/QGjPiixLdiQhdmHZ1jAgTYPa3TtLUZFQStRIWrU3FOjf2n5Of0kvKdFpmixwG7/4g7o8vPfc o8N79WpfM9RRISvezBz/YuQg2hCeV83dzHm3zdzIQVLhJseMN3TmHKh0Xs1//eWqTSTLr/GB7xQC jEYmeOaUSrWJ50lS0hrLC97SBp4VXNRYwV9x5+UCfwTsmnnj0Wjq1bhqnGG/OGU/L4qK0BUnu5o2 qgcRlGEF+cuyaqVFa09BawWVAGN2P0xJHVqoFohR272DTJzoYMV35lA62bAcNbiGhW2lGEVAEPoT giuCGdrSvTJhst0KSvWGpvtdtJv2VpjdN92tQFWu0QYUxxseDGHmbwNh8MP7bvudRcLJvhD1/Aon wArazxxo3kF/wiacQBKI9IvkfpWUb56IJeX6iWjPHgAZHA+Fvrd9RY/LGdtyelL8Y1V9KIat15x8 kKjhUKcuvy+P3HQWTNes4dsS9S1Qmt8hrn9o+LDxEjg1ZKl9yvODLvw9fJtFnDCpNurAqCEE0sYJ gMMH0M+wVrgS7vatRseJmi9ZRT4gxRHNK4VeY6moQOZ8eAUA5QoIUdCPAYU2+S0W+O0RjDbuu41J FSdwGORpk4KfPWv/z11guXsgI3TLMKElZzmkMtbYID7L1k/xqdlxEBcV6L4XuANSBJ3YZvwIydo5 AIVinXRP42PKoUOIdewozB9vgZay6YB80AJohOlp/2FPMXU83+gNJRxeWEY7yk5ANLw/j7gtK3E6 YNBT9RwRGd8JVZ6cYngCYlU8CQhOcVYhh1bIK6zoA/2asl+q31zBhfQ3mDtmhVWucTxjC9o8XuQP BRi7duZ/otUiXY6nmTu+DNbudB36bjSNV+7aT8MwysI0CuJPzmBSOZSqqprq20F7xMTz4Wry/Xtx Aa5+dF6qJ5bqjHPtVd+ahVHES8kulOjZ/muHBZxgCf8ZrzAm+9gdzsvI1DKyYVVO0c2ufv8dL5Nz mCiMPgD9JDXGLM6sxTRM13GwmrqThR+5qwi0GK/9BQgy8+NgEUVx7B+1KHXlDWTXS/HL539/+/L5 vzMo0VxidqABS76WcBm2Zs7YiQpemTSNp+NllLqpH2ZuuIov3UU2nbjZJAjDZRotlsH6E6TV+mFC BDVT1x/5MP3B4qOJra6I4JIX6oLw2utHP6/lH6loeWWmP380jJAdhgsmGI2jy+no0rf6hCyNH9hs oQQ9uplblInXuH3TgWHgBIZVUPfSLLUwnoJWdeh9iK7djrvzrwAAAP//AwBQSwMEFAAGAAgAAAAh AFBstlr7BAAAzREAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OS54bWysWOtu2zYU /j9g7yBovxWZusuIU/gSDwPSNGjcB2AkOhaq2yjatTcU6Gttj9Mn2TkUaVu5rI6rP7ZEHX4814+H vHy3LXJjw3iTVeXIJBcD02BlUqVZ+TgyPy3mVmQajaBlSvOqZCNzxxrz3dWvv1zWwyZPb+iuWgsD MMpmSEfmSoh6aNtNsmIFbS6qmpXwbVnxggp45Y92yukXwC5y2xkMArugWWmq+fyU+dVymSVsViXr gpWiBeEspwL0b1ZZ3Wi0+hS0mrMGYOTsrkpiV4O1dZYstqYhxfgGBoh5BZYn93lqlLSAgbssEWvO jC+ZWBlTWqMeUqapF5wxlC43v/P6vr7jcurt5o4bWYpQCsK01QclJl9LEIMH+8n0R41Eh9slL64u 6RA8YmxHJgRuh78wiQ7ZVhhJO5gcRpPVhxdkk9X1C9K2XgA02C8KMa9bi56b42hzFpnImUH2VrWi FKbeVMnnxigrsBPNb81LbjcaDG1G+HpltO4XCKXk2o/SH1q+kT7Viu49QcLYcSLIW7DciyDLBk+8 4ntR4MGggb7xgyB0I7mIRoJFWuh6KLaTKt2hSx/gHyJHy2RVQaY+4Aw6zBtxL3Y5xBmeNzkBjQya P0Ip5ZAFdJiy5UcYav4amZDvsOSDtnwvD0Hu4oCL6RAcAT8wNadYiYJbi4/tkuJqmmfJZ0NUBksz YbynjWDckL6CUgVlEFBIWInCyvSOcop6tGCstD7dK4thMTBXmyktxxC8HmdXx1ln/l1OE7aq8hSU cBAV6kPH9KyoQ9GZUCGQvjpHzot9QJww9Fun6YLohN4jBPNDeaKtp/+J/asBLyi/kQWYlSmwCT5i 9B7Wt0CZctZRGriQB2pFlTAoC48O5k4L5fkhShmn4DkHCxSIwnMPeDHxZL6fhIeSoDQm5SZHEIXn HfCIGxKsqtMUxLzfAyKKAvSPACMo2PMAEUUBBgdAIABQ8CwNEUUBhkeAoScjd4bJiKIAowMgop0e lI4PEUUBxkeAgR+eGRREeZmG+uUOT3PHAuvxmDhczJCfJQ6kaOhWgGtXNF8qDpGUBFV9Hof4LuwO 7fZw2FU7JBINYDdpFzlh/5Bs8NKm8SYOIZ0axU1HpcOZHEI6nIQgCu9MDiGddO2BQ+KeKaSD1wOD dPB6IJAOXg/80cHrgT46eK+zB5ITbCL7tlSm1ZuaGuQJ2dM0naYGNqc3Ny6+Jp8ZFaxDPl4f5JOK Z9RD2n3vVe6RlKdbL91hdhhCvsh+cAknDjw1/D12Aycce641u/aIFTjwFLnEs6aOE7tkFvuTeP7V VA10CqaKrGB4bMGe0LcJHJkIOTgTcPFTvzwfaFfPqwp702Omlw3ZzzL9UvDW23+uKYcVdL/4g4bx LQ7v1yOh9sh9nqXMuF0XD0/8EvSRhHAkB+gXXfODffAtrtnn4sSbXMfuLLD8MYmsWQQJGV+TsRUF cxK74yiKY7LPxQYtL0G7NhW/f/vnt+/f/u0hE2XLrg/bQBg3DRx+ankGXvMMSmYyiQNnGk2sCfHm ljeLQ2s8D3xr7rueN51E46l7/RXUqok3TDiTtwF/pOpWAgaf3SQUWcKrplqKi6Qq7PZKwq6rL4zX VSZvJchAXW1sKNCf63teSNwgaM+ZUjd57tLaggl4pyBboJy/p/WHjeRKuESB7J7KoRquTSBKKHoQ Qdv1NczVfwAAAP//AwBQSwMEFAAGAAgAAAAhAO54NaeVBAAAoRAAACEAAABwcHQvc2xpZGVMYXlv dXRzL3NsaWRlTGF5b3V0MS54bWzMWNtu20YQfS/QfyDYZ5ri/QJbgS5WUcBxjMj5gDW5sogsL12u FKlFgPxW+zn5kswMuaKcOK2RCoVeJGo5O3vmzOzuGV2+2pXC2HLZFnV1ZToXI9PgVVbnRfV4Zb67 X1ixabSKVTkTdcWvzD1vzVfjn3+6bNJW5DdsX2+UAT6qNmVX5lqpJrXtNlvzkrUXdcMreLeqZckU /JSPdi7ZB/BdCtsdjUK7ZEVl9vPlS+bXq1WR8XmdbUpeqc6J5IIpwN+ui6bV3pqXeGskb8ENzX4K Se0biFYVSnDTIDO5hQHHHEPk2VLkRsVKGLhHC2MpipzTq7a5l5yjUbX9VTbL5k7SjNvtnTSKHD30 M027f9Gb0c8KzODB/mr6o/bE0t1KluNLlgIRxu7KhHzt8RMmsZTvlJF1g9kwmq3fPGObra+fsbb1 AoDgsCikuuki+jYcV4fTEeEcoupMGUy9qbP3rVHVECeG34WX3W61M4wZ3Tdro2M9U5K89abde6JE T2mJVo31QEYYB/GoY8R1vJHvBk95iaLI9dEA2XH8aDTqLI6j7lw3qdpN63yPrD7AN2WFpaJVS7UX nNgGTlgKyOEDcisY7hglrfu33aJqPBNF9t5QtcHzQhmvWau4NBQVTIteLmFdBcnuvfAqv2OSvT04 45X1bkkksBQWAwY0KHjsUvL9xHg6McvNQ7emi66geDXzP5SbdvPQ5QaKGSpNp/PlOXK8yAn7JHlx HMIx8DRJIWSIskhJigIXrbFodLop+K5kNB/PJgkzI7bCgVoxSiZvaLMUVQ4bnh6ZeIQjD4oNNi44 2NzCAUeJzfkKkoCDbQ0be1EIQT/wVOMzIY0tE5DqHR4GkMGiUt1IFIwOUOkIRGMCfuQHwtD+4bHH h37g0R2g+kGEzBjnhxdB9ni9AW/i+LSzzg8vguzx+gPeQxmeH2BE2QMOjgDHbkzb4vwAI8oecDgA dt0Ydu5ZljCi7AFHR4Aj3zvTPYcoe8DxABjRnummQ5Q94OQIcBhEdPafXw0jSjqq9RWP6H/shocr 8v+65H19yc+Z4sadYBlf1yIHmeGd4rLPFYj/P0BIM7GCq4gu/O4uRn1KhOHDkrhDSUIyaZApz17L g3ZagYpGSfyn5/mzZDJ3LD9wJtZ04sdWErkLK3ADkAJ+OAunwUezV4c5hKqKkve37ziwHWgDHGdQ U+AXs3daPRVoqhd1jTrumGz/FGSvQIgQ279vmIQVNOH/IrFI0/2jDhoIPy0joWaEuh/jdlM+fMUL ye//rDhFDq6fpYYULTUGp6vFqT+9Trx5aAUTJ7bmse9YyTVUZRwunMSbxHGSOIdabLHvqwAd1psa f/701y+fP/19gkokjas7SWjrblpoFBpq8DaygC0znSahO4un1tTxF5Y/TyJrsggDaxF4vj+bxpOZ d/0RYDWOn2aSU4f7W9532jD4TXdcFpms23qlLrK6tLs2227qD1w2NShc3GKjvl0n+esFbgz71neo +AEvoKQeRaOFIeyTqeUQ8jVr3mzpSoA/BqC6QRnDUAN/BUB5oulggrHrvxbGXwAAAP//AwBQSwME FAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5 b3V0Ny54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBv dpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnF ZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6d pTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEA ACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OC54bWwucmVsc4SPwQrCMBBE 74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/h dj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTW VbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U2 6mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRz L19yZWxzL3NsaWRlTGF5b3V0OS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTb BtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj 5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/ dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgA AAAhANXRkvG+AAAANwEAAC0AAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTAu eG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/Wsa xZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmG SL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZU sJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDEHxkPqwMAAP4KAAAhAAAA cHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDIueG1srFbhbts2EP4/YO9AaL8VWZYsy0Lswpat YUCaBrX7AIxERVopkSNp1e5QoK+1PU6fZEdKTJo2DdzFPyxL5N3Hu48fj3f56tBQ1BEha9bOHf9i 5CDS5qyo27u5826XubGDpMJtgSlrydw5Eum8Wvz6yyVPJC2u8JHtFQKMViZ47lRK8cTzZF6RBssL xkkLcyUTDVbwKe68QuAPgN1QbzwaRV6D69YZ/MUp/qws65ysWb5vSKt6EEEoVhC/rGouLRo/BY0L IgHGeD8OSR05ZMtu/3SQMRIdfPrOAvLOt7RALW5gYFcrShCwg1LWKkAyBpLvBCHatO1+F3zLb4Tx u+5uBKoLjTP4O94wMZiZzxbM4MX7xv3OIuHkUIpmcYkTIAMd5g7s2VE/wQkn5KBQ3g/mD6N59eYJ 27zaPGHt2QUggvtFYbt5n9H36YxtOj0d/n1WvSkG1yuWv5eoZZCnTr9PL7/uLJjOWcPzCvXMK83s YNdPGj6svQRODVnqsGLFUSd+C/9mECdUqq06UmIIgbBxAuDwAPop1sJWwt291eg4UYuU1vl7pBgi Ra3QaywVEcisD8oHlEsgRMF+DCikLW6wwG/vwUjrvtuaUHECi0GcNih47Vn7MXeB5W4QELqhOCcV owUEMdaoIDjL008yWRegA0v2GUgEzhHt6L3Ufp5ULU7DqXxEKlBrdql/2FVM5M9v3ZbkDA4fJR2h JyAaPp9H3FW1OB0w6DX0HBEZ2wtVnRxieAJiXT4JCGf/rNIMrTTXWJFHujRp/39d9ie8UHCzfIQq jWnpQFnUWjU1zBx0XQ5edOJLKNK61v49ibLpaJ2O3SAdj9woC8fubBrE7miyGY9S+GWp/8kZyk4B qaq6IbrS61M/8Xy4Y3z/QVyAq6fOS/XEUp0xpqvP10XAKOKlZJdK9Gz/tccCVrCEn7E6nJeRyDKy pXVB0PW+uf2Gl8nLimMvQuhhAPpJakyxOLMWV+FqMwvWkTtZ+rG7jkPfnW38pRtHmT8LlnE8mz1o UerMW4iul+KXz//89uXzv2dQormWbIsCJflKwvXGTeewFzUcmdVqFo3TeOWu/DBzw/Vs6i6zaOJm kyAM01W8TIPNJwiL+2GSC2Lapz+KoY2Dwe9ar6bOBZOsVBc5a7y+h/M4+0AEZ7Vp4/zR0At2GC4Y P55GQeBPp2aTIV6I0tQDGy0M6TbM3I5UvMb8TQcFAyfQdYK6UzPEoc+E+1ObPpjo3G3fuvgPAAD/ /wMAUEsDBBQABgAIAAAAIQCXtw1G4gQAAPUQAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxh eW91dDMueG1szFjbbttGEH0v0H8g2GdaJEXxIlgKrFsbwHGMyPmANbmyiCwvXa4UqUWB/Fb7OfmS nlmSujguKieC4RebWs7OnjkzszPDyzebTBhrLqu0yAemc2GbBs/jIknzh4H58W5mhaZRKZYnTBQ5 H5hbXplvhj//dFn2K5Fcs22xUgZ05FWfDcylUmW/06niJc9YdVGUPMe7RSEzpvBTPnQSyT5DdyY6 rm37nYyludnsl6fsLxaLNOaTIl5lPFe1EskFU8BfLdOyarWVp2grJa+gRu8+hqS2JaytePwbZ4lp aEG5xpJjDmF7PBeJkbMMC3Me0+EGCXKp31blneSc5PL1r7Kcl7dSb7pZ30ojTUhJs9nsNC8aMf0z hxgeOo+2P7SaWH+zkNnwkvXBhrEZmHDalv5iE+vzjTLiejHer8bL90/IxsvpE9Kd9gAg2B0Kf5e1 Rd+a47bm3KVKcMPZWVWLMmy9LuJPlZEXsJPMr82Lb9atMrKZ1JdLo6ZekapGrn6p+WjlK81pC3TH ROC6Xaer6fA824/sR6QEQeB6WDSIGqfru3bQ04e0mnBIrbrsq82oSLZE6T3+w3Msj5cFolTRDtYX lZqrrYCf8bwWDhAZTDwgjQSigPUTvviApeqPgYkjcea9dnzMwAATojm22Ql3H2sE2awPSvAHSgSj fFTSuvtQH66GY5HGnwxVGDxJlfGOVYpLQ7OGhAUsUqi0Wq2F58ktk4wQ1cp4bn2cNyBwGAxvDdYc kDP+2+OguI7+Owq3W8FiviwE4t9wSSUSpHXtdzmfCDeRKQjjNla+KwbcyPYDxMNRYhzHQM+2nTBo eKjz6pQYuK91PhUDGZPXOifTPMHlQo/kxvvVDW5QjeQgMnAL1q+rQqTJLBWCZPUFysdCGmsm4PcN 3TpwZ5qreiUAbB3acPJOWDv7QA/e1SfVwVWHKOlBzLkUrTVSrxcABeg+Aa4TviBcwtjA7e7hRg4y +1S4/gvCJYwNXG8P1+kGDqE4jV6yjHQcePHAweeNBgLZ4O0d4A3dkJz8+vASyAavv8fruiHofY14 CWSDNzjAG3jd09PtJeOBQDZ4wz1eAnt6vr0kXgLZ4I0O8Pq94HXmG4Gsb+KDxkGXeUKPO3nXwmmz nlX2qQrrql8dlX1UgGeXdq8t7ROm+FFp13X0R0t7ojBQoCVaMrFoS3xdyajd1QzRw1yTVTdjuqFo m5O2G9OFtC2/+oemcoG+nDrsP6Op2w3sMLKmkT+1gpE3s6JoHFj2aDSe2X5v4kXTv8ym2Uxgqkoz 3pTZYa/jYLRwnD2Z0Euxdt4uqtdSPSsK6t4O+yjvHH3UQsma7d9XTOKElvD/aaqeQ/h5GfFbRubo hrhxs8ruH/Gi2/UfDUKMrlD9JDW6f0UHeM5YHHmjadSd+FbvygmtSeg5VjR1rqzQnzlR9yoMo8jZ xWJFludAR/Gmhl+//P3L1y//nCESdVvbDqa4MK4rjAelnhdXMkXKjEaR747DkTVykC3eJAqsq5nf s2a9rueNR+HVuIuUwR7H68eS66n5bdJM71j8ZuLO0lgWVbFQF3GRderRvVMWn7ksC7SylGJ28wlA 97luGEReFGAq0/24xqYnkxYtTKDJWw8YQr5j5fu1vivxsQHRjX4ZSyU+LyCASXQvQra3nyuG/wIA AP//AwBQSwMEFAAGAAgAAAAhAD6XVip0BAAAjxEAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRl TGF5b3V0NC54bWzsWNtu4zYQfS/QfyDUZ0WibpGEJAvLl6JANgnW3g9gJDpWVxJVknbiLRbY32o/ Z7+kQ0p0bo6dtH4q8pLI1OHhzOFwNMOTD3d1hVaUi5I1pxY+ci1Em5wVZXNzan2eTezYQkKSpiAV a+iptabC+nD2808nbSqq4pys2VIi4GhESk6thZRt6jgiX9CaiCPW0gbezRmviYSf/MYpOLkF7rpy PNeNnJqUjdXP56+Zz+bzMqcjli9r2siOhNOKSLBfLMpWGLb2NWwtpwJo9OzHJsl1C97KW3Z5/buF NI6vYARbZ+B6Pq0K1JAaBma3DA1ZI4FGvxLtjFOqQM3qV95O2yuuZ1ysrjgqC8XQz7Sc/kUP0z8b gMGD82T6jWEi6d2c12cnJAUl0N2pBRu2Vn9hEknpnUR5N5jfj+aLyy3YfDHegnbMAmDBZlHY67bz 6Lk7nnFnVsqKIrzxqoMSmHrO8i8CNQz8VO537uUXK0OmfFb07QL1siuqHte91HoYvABNtVjyLmPF Wjl+Df/1IEkrIadyXVEtCJhNUiCHPyB/RVRUS27PPil2ksqzYVXmX5BkiBalRB+JkJQjqV0RiuUE BJGwHz0LbYorwsmnDRlt7M9TbSpJYTGw0xgFj51qL2vnG+36AEJXFcnpglUFGOEpVgg1o9MblRRf 4QCQam5B0EFEGNlfkFOJ8SSwgvAYjqiOLhy5rnrWmpkYC1w/hnELqUgLQi9MIr8XomPSAnQ7azTZ ulFq7WpVYX1SSFrQuZJX2e/F3aKg/gMAPHpbsMFDrAEA1t+CdR9iDQCwwXMsfmSDAQA23Ic1AMBG +7AGANjjfVgDAGy8D2sAgE32YTuA0ro/QWpj9AGCmQgYNmnm7QdKBY0+T+LRgYLFugX0UmYVHau7 j+2U5qwpUEVXtHoFoz5Luxlni5K/nlBH+m7CCVtyuXi1iUF3unZJOynnWwkh7x80LQW70pL2/GBp SW+MTu4qUeiHh1l+W1qKgvg9L0FCf89L6XteMvnTpM7/dV4KTV4aEUkf1Uo6ef77pNRVnYWEVudJ 1aRrnpfzk67QdhY3umTS37g5tAyq/v8Tu0nge0lmu9gLbS8MxnYWj0f2YDDAvudnboyzb1ZfChfg qixrqvoOVYmGDoamB+P7jx7wqleH/QRERuoJY6oifliYhv+tMO3Enkveqf3HknBYwZSpe+rUtwh+ WEWOjSLTqiwouljW1090iQ6hCzTVQL1Vmj3fyrdIs4nFLMjGiT+K7HCAY3sUB9hOxnhgx9EEJ/4g jpMEb2JRKM8bsK4LxR/f//rlx/e/DxCJulMwbTOUiucCWq5Wd7NLXsKRybIk8oZxZmc4mNjBKDm2 B5MotCehHwTDLB4M/fE3MKvFQZpzqvv534r+XgEGn90F1GXOmWBzeZSz2ukuFZyW3VLeslLfK2C3 v5xYESh8fR/aCy/Aid5ksBes1PWKsRaG1KWA7tgq/pG0lysoaEgK1yAQ3UM91MLFB+ySgt5DlO/m IuXsHwAAAP//AwBQSwMEFAAGAAgAAAAhAAhZPJNKBQAAHRIAACEAAABwcHQvc2xpZGVMYXlvdXRz L3NsaWRlTGF5b3V0OC54bWzEWNtu2zYYvh+wdyC0a8WmzhKSFD4OA9I0qN0HoCU61iqJGkW7docC fa3tcfok+0mKju24sXMAduMo0sdP//H7KV6+W5cFWlHe5Ky6svBF10K0SlmWV/dX1qfp2I4s1AhS ZaRgFb2yNrSx3l3/+stlnTRFdkM2bCkQcFRNQq6shRB10uk06YKWpLlgNa3g2Zzxkgj4l993Mk6+ AHdZdJxuN+iUJK+sdj0/Zz2bz/OUDlm6LGklNAmnBRFgf7PI68aw1eew1Zw2QKNW75skNjV4y2Z/ TtcWUjC+ghvYugbP00mRoYqUcGPAKgEM6EsuFmhAammHwjT1lFMq0dXqd15P6juult6u7jjKM0nV Ulid9kELU/9WAIOLzsHye8NEkvWcl9eXJIGIoPWVBYnbyF9YRBK6FijVN9OHu+niwxFsuhgdQXfM C8CC7Ush57X26LE7jnFnmouCIrz1SkMJLL1h6ecGVQz8lO5r99LblSGTPkv6eoF0+IWkanH6oYqH wTcqpsbQbSQ8P4TaUuFwQrfrH8TE7XYjF7sWkpHBOHBaxK7HmrlOxLrPso2M6Az+QuJIlS4YFOpM x7loxERsCkgzSYpVgcEgRIp76KQCioAkGZ1/hFvN1ysLTAKbZsbxLR5yDNc7PBBhkkAc4AeWFkQ2 ouD29KN+pbgeFHn6GQmGaJYL9J40gnKkQgWdCsZIQqFoFQutsjvCibRDk9HK/jRRUSUJvAxCatyE S53gn6cZ4rZf+HcFSemCFRkY4UhWaA+T0mcmPc+gZE1dnJ9v1w99mUNZ/8cS7mOMAaET7ke+iyH7 svhM5Si3demZSJiEq27azU6b5YPkurLgNOUOAC6dtkR3CyHaxRoAYN0jWG8XawCA9Y5gZYFtbTAA wPqnsAYA2OAU1gAAG57CGgBgo1NYAwBsfAqrAcfaBlYiYNjq4PPbSCqn6qJmr43gZaov9Y95i6rV p5t1QlNWZaigK1qcwag66GnG6SLn5xOqSn+acMyWHIbXuSZ6sshOMObzo4QwmN5UjDwjRlOZtl0l Um6/XIn0+JGaD7sfEO8FKeYWTG3QJ5UhNYakYqiLiSpYqZ3yllGVY/MIe66PdZs+DOm9geQFMe4G r9YnVBJ+ozYFeZXB/kReStNmy1vYxqkE7kgS3pMZOcUkFhpJqlNLZabqWXx7cnggcS1fjD35VnQW 3560Hchgy4fdEAfnEsZPSKXhi5xIKvVZBu7xHchpy+c4EZj3Er4DyTV8oaemzvPtO5Dllk+SnZ2Q PX8PpNvwBX74snz8b/IOzWzmv9oSyL3Mz3dCvhGfIRF0T3yUQr5WfDLxSHqwnu/yk+Co9kBbP3hw dAejGl/NsDl8wcivkL+H3dHIH3jY7jp+z3ZDuIpDZ2CPhl4c9rzA7UbeN6vdkGfgqshLKj+D5CbT 72D4BMP4YbIBr3z0tjofmFCPGZOb3V2l9+U4em2w54LraP+1JBze0Go9PrEZfU7A3zYioYnIpMgz im6X5ewgLsFbxAU+8YH6aGhOzMHnhGZbi32vP4rdYWD7PRzZw0jW4gj37CgY49jtRVEc420tNtLz CqzTpfjj+z+//fj+7xtUoup98/EOG4ubBr6mavVNveQ5tEy/HwfOIOrbfeyNbW8Yh3ZvHPj22Hc9 b9CPegN39A3MqrGXpJyq04U/svaUA24+Opko85Szhs3FRcrKjj7i6NTsC+U1y9UpB+62RyUrArtb mHV+gKMwCtWGX9mm9iLGWnBBnlGoxij4e1J/WKmRDocyUN0DdauGYxjIkoQ+QKTv5ljn+j8AAAD/ /wMAUEsDBBQABgAIAAAAIQBUq/QC+QIAAB0HAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxh eW91dDcueG1srFXhbpswEP4/ae+A2G9KnAAFlKSCJEyTurZa2gdwjWlQwfZsJ0s2VeprbY/TJ9nZ hHZrO6nS8gfMcXf+vu/O5/HJtm2cDZWq5mzioqOB61BGeFmzm4l7dVl4sesojVmJG87oxN1R5Z5M 378bi1Q15Sne8bV2IAdTKZ64K61F6vuKrGiL1REXlMG/issWa/iUN34p8TfI3Tb+cDCI/BbXzN3H y7fE86qqCZ1zsm4p010SSRusAb9a1UL12cRbsglJFaSx0X9D0jsBbK8bzG5dx7rJDRiQOwXmZNmU DsMtGHLrYYxKXEpKzYptPkqxFBfS+p5tLqRTlyZ2H+P6+x97N/vJwA0W/rPwmz4TTreVbKdjnIIE znbiQqV25glBOKVb7ZDOSJ6sZHX+ii9ZLV7x9vsNAMHjpoZVx+glnWFPZ441dS4aTOiKNyWVDnok 2EVhyHLKya1yGAfKRomOKTnb9HkNfbOTWDmd9KWGxvsORcRN5YJ+QA5ZslYh42wXfbwCua2Oepvz cmc0uYa3NeK0UXqpdw21WgEjnFZQQVOUH2i+yIsiH3hZOEReNAsSL1tEkReGySJMwnyQZ9md24MC qrpuqWkDnOpp6CNoQYTGoJ4GRDavrQcrL7DEX6D00CBwlCjzrpaWNk4BAGDvgcKyE/nfUo96qQvO NQj8p9jDQ4hdadmp/XWNJezQC94XqqvOfwlOD6pI0CuybOqSOmfr9vqZLqND6AIjDlK/Ko3V3Spy uF7Mg3yRjObQfBmKvXkcIC9ZoMyLowIloyyOkwQ99qIyzBmg61rx4f7nh4f7XwfoRNuQ/SyDwXKq oLWFHTFrWcORyfMkGs7i3MtRUHjBPDn2siIKvSIcBcEsj7PZaHEHsAQKUiKpna6fyv2UB+OLydzW RHLFK31EeOt3I94X/BuVgtd2yqPB/qrY4GbijhBCg+gYDY/tibLY7Jnq0QIFM6MNbNLIz1icb2Bg 4BQuJejumTUJuIb2Y+jJxXDvr7XpbwAAAP//AwBQSwMEFAAGAAgAAAAhAEhohjs6AwAAYggAACEA AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ni54bWysVu1O2zAU/T9p72Blv0PqNglJRIua lk6T+BKFBzCJSyMc27Pdrt2ExGttj8OT7NpJgAGT0NY/aWJfH99zfHxvDw43NUNrqnQl+NDDez0P UV6IsuI3Q+/qcuYnHtKG8JIwwenQ21LtHY4+fjiQmWblMdmKlUGAwXVGht7SGJkFgS6WtCZ6T0jK YW4hVE0MfKqboFTkG2DXLOj3enFQk4p77Xr1nvVisagKOhXFqqbcNCCKMmIgf72spO7Q5HvQpKIa YNzqP1MyWwlsTWUYPeNs6yEXqtYwiL0RsC/mrESc1DBwaaOQC7MzWl4qSu0bX39Wci7PlVtwuj5X qCotQLvQC9qJNsx9cgiDl+DF8psOiWSbhapHByQDLdBm6MGRbe0TFpGMbgwqmsHiabRYnr0RWyyP 3ogOug0gg8dNLauG0Ws6/Y5OowN+ZNWEElh6LIpbjbgAnpZ+Q684XXdglrOFl0v0TPg2rpl0enTx GjR1YplNLsqtJX4Nv26QZEybudky6gSBtEkG4PAA+RmxvjbKv7yw6CQzowmriltkBKJlZdAJ0YYq 5A4ejA8oByCIgfNoUSgvz4kiF49glPtXc5cqyWAzyLNLCl4b1f6u3aDTbkoMReeMFHQpWAkZ9C0k 2KwT6Z9kLA3c3u9wEwhbeOA9MAZ2RnFqWs3/S9YFXAFr6B9xHOc5Huf+NOlN/SgOx36awme0349n +5PpBI/TO6892xKomqqm9h5ZaaMAwz3G+ElowLVTu5U67KSeCWGP+LnYg12IvTCqUfvriijYoRO8 8/sOfLxbRaJOkTmrSopOV/X1C13CXegCfQKg35TGmXzHXszD/CgdTGM/GuMEDBliPz3CYz+JZzgd jJMkTfGjF7VlziG7xooP9z8/Pdz/2oET3d3v+gAU5WMNNUS68rxSFVyZPE/j/iTJ/RyHMz+cpvv+ eBZH/iwahOEkT8aTwdEdpCVxmBWKuhb1pWxbJQy+am91VSihxcLsFaIOmj4ZSPGNKikq1ypxr+23 a8KGXj8KkziK+r3IFS+Xm6sHXbZAwTY5V4WYOiHybA0Fg2TQ2cHdEzckoZdDnbKhTyGWe/ffYPQb AAD//wMAUEsDBBQABgAIAAAAIQDtVXCdzwUAAEQbAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlk ZUxheW91dDUueG1s7FnbbttGEH0v0H8g2GdGWt4pWA4sWSoKOLYRKR+wJlcRG5LLLleynSJAfqv9 nHxJZ5Zcibo5smK0D/WLTZGHh3PZORzOnr19yDNjyUSV8qJvkjdd02BFzJO0+Ng3P0zHVmgalaRF QjNesL75yCrz7fnPP52VvSpLrugjX0gDOIqqR/vmXMqy1+lU8ZzltHrDS1bAtRkXOZXwU3zsJILe A3eedexu1+/kNC3M5n5xzP18NktjdsnjRc4KWZMIllEJ9lfztKw0W3kMWylYBTTq7k2T5GMJ3sp7 Pn2Y3vObu99NQ4HFEk4T8xz8jydZYhQ0hxNDnpdUpBUv1JWqnArGEFMsfxXlpLwV6obr5a0w0gQJ mhvNTnOhgamfBcDgoLN1+0fNRHsPM5Gfn9EeRMN46JuQtEf8CzfRHnuQRlyfjNdn4/nNHmw8H+1B d/QDwILVQyHfZe3Rrju2dmeayowZZOVVDaVw6xWPP1VGwcFPdL92L75eajL0GenLudGEHqkaXH1R xUPjK4ipCpZ8GPDkER2/g//qJO1llZzIxwxSAMfLjKgE0F7CZu/r0LZOg7dtODhJe2AK/IFkZRTr QApr+h5toT15PszS+JMhucGSVBrvaCWZMKRyvMJnngGhhOw1LKxIbqmg8NyGjBXWh4lyjPbgYeCV dgEO6xgfjrSzijSm+TajMZvzLAELbKSERalDelLQMYQmrFBYPjpHB2KPsdhaha4XQE2rpUg8xyPE qUOmF6TbdbskBD3BZek7UeArm9urDbOKXuiI6KQatIjnHATirqZsJ6zJr5FTcaVKIS0SqGk8RCPv FtcgXCp3dfqN6nPftF209E672VoO6tAGOxpC7dVRrN1dVqRCO8BMZ80aEVdZcAwrCXdZkaphddes xAmIj+CjaBVyMwTI1dB6LdrQDpUNp9IiV0Prr2ltOwQTfsBa5GpogxZt4DpqHZ5qLXI1tOGaFjmP T9me2CJXQxu1aH0v+KGUIZdSm3ZNKBHDh8CqW70Y1NOfJWpYuUrTqg1Rg4p9tnC5WriGvJBQnhva pYTidO3Cgp7TbNYoV60q+PJUkcGDiQoSymudg8PKZZPADQPvCeVyIo9APSDiGOlSytPOzc77aC1I NWULAIdaP9rihVWzwmoAYLUqtLBKPFZYDQCsLvU2FhfiCqsBgNX1exCrAYDVRXkQqwGA1ZV2EKsB gNXlcxCrAYCta0K/71V8lS6ufPvPikZVDvzRpanesk/3GxMW8yIxMrZk2Z4y3GZUq/9pxuk8FccT Nm/xp9RjzBdCzo820a2r60nGdLaXENrbF+2nPC1L0+1+Shl5uibVTWzdT6E+/bGgAhrFRqJUTFU/ e7RE+a7XtcFc6J0OdVckAOF67a765mt3BR3ua3fVN53/SXflaxnb112pZuZ0JdtVLyWNJ6vXoQ5r rV6vHRbGfLNjee2w1rOWJz9Ltvuh1w5rNXnaGGON/6UOK9DSdEkl2/jq87ENPF2X6g4rkTCf3vz+ I/VHzMEPQPXU7QkTnFzPAdUP9Q09gxEvDmz/HHk2cVznwgrJ0LUubXdoDfzAs4ZBF0Y5o1E0Jt0v ZjO7TMBVmeYM58Q4DPQ6BCbVhKzbd+DFSy/bzMJorR5HjznHoWR7PBi8RLBnEhrY3fcB+c6s8DkB f9mIRDoikyxNmHG9yO+24qK+4390EcJOCFDvDc13hhHPCc1qLQ7cwShyLn3LuyChdRm6xIpGBJam PyaRcxGGUURWa7FCzwuwrl6K377+9cu3r3+/wEpU02q9zwGSfFXB1LtU2w8LkULJDAaRbw/DgTUg 7thyL6PAuhj7njX2HNcdDsKLoTP6AmaVxO3FgqlNmN+SZjMITu5s4ORpLHjFZ/JNzPNOvRPUKfk9 EyVP1WYQ6TY7SksKcy/H75Ku5wdEdUBgL1ipBu7aWjiFmzhKhTLxjpY3S/VRCntXUD9DdaqE3SrI EkLXEPRd736d/wMAAP//AwBQSwMEFAAGAAgAAAAhAJOqfZi7AAAAJAEAADAAAABwcHQvaGFuZG91 dE1hc3RlcnMvX3JlbHMvaGFuZG91dE1hc3RlcjEueG1sLnJlbHOEj8EKwjAQRO+C/xD2btIqiEjT XkToVeoHhGSbBtskJFHs3xvoxYLgZWFm2TezVfOeRvLCEI2zHEpaAEErnTJWc7h3190JSEzCKjE6 ixxmjNDU2011w1GkfBQH4yPJFBs5DCn5M2NRDjiJSJ1Hmze9C5NIWQbNvJAPoZHti+LIwjcD6hWT tIpDaFUJpJt9Tv7Pdn1vJF6cfE5o048IlnIvzEARNCYOlC7OMg80dwVWV2z1W/0BAAD//wMAUEsD BBQABgAIAAAAIQAnkva3IgQAAFMNAAAlAAAAcHB0L2hhbmRvdXRNYXN0ZXJzL2hhbmRvdXRNYXN0 ZXIxLnhtbORX227bOBB9X2D/gdA+K5Ksq4XYheVEbYFegrr9AFqiLCGUqCVp125RoL/V/Zx+yQ4p MbHTtOglD3t5sUbDmdHM8PBwfP5o31K0I1w0rJtZ3plrIdIVrGy6zcx68zq3EwsJibsSU9aRmXUg wno0//238z6tQcu28jkWknAEcTqR4plVS9mnjiOKmrRYnLGedLBWMd5iCa9845Qcv4X4LXUmrhs5 LW46a/Tn3+PPqqopyAUrti3p5BCEE4ol1CDqphcmWv890XpOBITR3icpzaHGYkVL9Vxvht9XpEJN uYdOua5nzc9xquskS8rRDtOZtd54ljM/d5QLGI+Schb9a06IkrrdY96v+iuuXooXuysOMSGkhTrc Qo9VAL0wmunXDsyGwCfuGxMJp/uKtyojaA+CDGEnD+oXnHBK9hIVg7K41Rb1y3tsi/ryHmvHfABK u/moqmqo6MtyJqacJwSXAJArigtSM6pk3SNd4uAHbeyfseJaoI5B0aoXQ63QHRNZNUB9q6+RPPTQ prrkgM13M+vPLeYAwdFlsIMsuxtXoXttCvh2hybT2EtcaJ7qUxDGAFEd+Na750I+JqxFSphZnBRS IwHvngmp0sapMdHbP3y9T+U+Y+VB7cYanrDpcOzAv2b8nYXo007MrKkXBPBpqV/0xy3Ej1fWJyuS LhlgbtxjKuRKHihADKd0Rz0oGmG6gWNNdX4lqV6BSnXMu61qtNRpH0eAfQXYdOUV5li5UawYgXT2 m9XYD7CALpuqQByw8HVE+AYRF1iSEzxMVMhfxUMpT+EwHtQfhoWfJEHkQbK3B8Ucn/8iOPjPgqOi peat937mZr4XJ3aceLEdL4PEzrJJbvt+spi4iyjPouwDoFqf2hL2XjYtyZvNlpOX2+HsyHnoeMDk nqeOj9RohPgPj8HAYDBnTF1bx6zkPwQKK3mHlQYYaoRrUlIspgVDbN9kpyRKwgmA8YTF/5UwRLgr gOvgihyKOSabfyRdhQYqK9qUBL3Ytus7gAkeAjCClhD6PurSu/5DmDmmrv8jcn6dy/JwGUynyaUd Xk5dO5wGmT31c98Ol74fL7w487LFDZcJBYwONk/xlJx//vjpj88f/3oABtOXqRkX4fKBwULdj+oa 2vJmZr3Psmk0WSaZnXlBbgcX09he5FFo56EfBMssWSz9yw+QVu8FacGJHm6fluOQDcovBuO2KTgT rJJnBWudYcJ2evaW8J41esj23HFS13MuUHUUh67rG2KD3DSvmWyhBDM8F5Q/xz2C0RhGEQljrtyD VF6DtN5MlA5mRbkHqbwGCRcFzONgMQpGA+uD5sbGNxq4rIclKGwUjCY0GjjOw1JkNJGFatp019AM 9bBQxeiTQWGk4YDXFYJhU4/UQO/6WcLkNgyGd/4Izf8GAAD//wMAUEsDBBQABgAIAAAAIQAKGrkr YgYAAGUdAAAhAAAAcHB0L25vdGVzTWFzdGVycy9ub3Rlc01hc3RlcjEueG1s7FnpbhpJEP6/0r5D a/bnagJzMAzIEAGGxJKTWLbzAM1MAyN6ju1pHDtRpLxW9nHyJFvVB4ftODjxRnsgS9D0Ud319VdH l4+eX+ecXDFRZ2XRc7xnTYewIinTrJj3nLeXEzd2SC1pkVJeFqzn3LDaed7/9ZejqluUktWvaC2Z ICClqLu05yykrLqNRp0sWE7rZ2XFChiblSKnEn6KeSMV9B1Iz3nDbzajRk6zwjHrxT7ry9ksS9hx maxyVkgtRDBOJWhQL7KqttKqfaRVgtUgRq3eOVIfNEwueIrf07n+PGczkqXXgFOz6Tn9I9pVerIR F+SK8p4znXtOo3/UwCUw2bRwcV1dCsawVVy9ENVFdSbwR/L66kyATBDpkILmgDAKUANmmvpZwDQt eGf53Eqi3euZyPFEAA+BE8I93uAnLKJddi1JojuTTW+yeHPP3GQxvmd2w24Aqq03Ra20RnfV8a06 LxlNgSBnnCZsUXJsK4yUinodwFidlsmyJkUJSiMWWldAx0pGAHCvakHkTQUwLVIBzHzfc/5YUQEU NEv0PDhlsV5aK6ytAg8j5HfaXtwE8BCnsNUGiirBm9WVqOULVuYEGz1HsEQqJtCr01risWnXTlHX r3evuvJ6WKY3eBtT+IZLB6OD9YtSvHcIPynqntPxwhC2luqH2twhYntkujMi+agEzpk75rW8kDcc KEa7/Ip7oDShfA5GzdX5UjY7hy5EzNtoZWaqY29LgHsF2hTpGRUUl3GK/oAV7tsLgwfMAJStVtDU XPg6IwLLiGMq2Q4ffBT5o3xIpWNs89FMCOI4jDw438Y2rMX8F/kgvpcPM54qV/Vh0PYmx+Nm6A6i YeR6gzByB6O45XZax+1O6IdRGAQfgcjKUFO4bpnlbJLNV4K9WWlzkf1WwwPn7XloMVIREOQ/Pe1C S7sLnqWMnOR0vsu+4NvsA790XoKxoo8uRwuwBTaoK7D8/VxVzdOTfG7oqciu/BM6NNWwPu4rjsrz wqCJPgnoGcUtdE87Xl27KeOzgtDv4GTtiWxQsB5pL6dFIbJPMs7VJrwg79BjtEEmXk5dAow4ij9Q 7Cb2gYdfmn23ZsHt8kIp+hM8IaFFAh615yRSBQTY27hFpczf4NVall6vMRvacWvht4mFt7Tl+DBq 3QpzGCx245z2coq1j6KRoQ6yKAzg7zaNWmEcYacOfUA6Q7R16N8Etr1oBIf7CTeuSXrnkjH6QWxb R0cwNdoV60AmhXt5rq1I9kc8S5ZEloSlmSQmoZUYAWoMqPXGQaHBAgqK+urD7qISFtjggV0uWFIW KeHsivE9JCo38bDEy0Um9heoCPOwwEm5EnKx9xEVv78hMZvdK/Cpc4vIWuGkBDPczTZbT2GGM/An O9mmtkIFwaOsULvxGIzRh4xDsfdfnWusPe5UK2P9LVrCPzINbVuq6Hzg9Sqf3iJM9BSEgZgPou/j jOLjoziznZ/+H5nz4wlrM5xEQXs8cJvjjueOj8OxO5x0QjfoePHAj1uhP2qvE9YaE8UCLg85LPtf Pn3+7cunPzc++7vTVBURbRkArP60hry3Uq/zlch6zofhsBP5o3joDr1w4obHnbY7mEQtd9IKwnA0 jAejYPwRjlV5YTcRTBUtTlJTPIHOOwWPPEtEWZcz+Swp84aunDSq8h0TVZmp4onXNBUYVb8IfD/2 wDHF9gUOp1Qpij0tqGCLIgkXr2hFoOQBT0wJqbG8hla6hNZ07mMf1ADkNbTSJbRokkCdBWaYhu2B cd2znhPYHniR6SFQzDRsT8v2QP6lhyLbA7FgwbNiCWDgl0NmJX+pO2xLG/hiRqCIgCkCAfeuvlPI 6FXubKpbd17UORWnaqZ9WhN4V1/S6QU8q025gAip8g7C6GkxFHAOQATLU4X5CfvhEwJqYGerQr8h kGm3H+hkyQSW5PCxjuNbOfWduhNAjzpBcrIzS+2qnmEzqL70nN/zwuVSO2pGbw0wqgeS+tZAUhvZ +oRqm3XdQHl5H9MtDY0F4YAPgmKiYLDBR9V4gAEHfBAUg0+4wccL2l6Er5ADQIiKAai1BVDsx6pC eQAIUTEARRuAIIQBgQ4MAheNqBiA2lsAtcMAg8rBxDiiYgCKNwAhOqoScjAxRMUA1NkCKGq1D05a pT6IisqQ1X9DTb6Ir7vNP0f7fwEAAP//AwBQSwMEFAAGAAgAAAAhAJMKbXUTBwAA5x0AABQAAABw cHQvdGhlbWUvdGhlbWUxLnhtbOxZzW8bRRS/I/E/jPbexk6cNInqVLFjt9CmjWK3qMfx7tg7zezO amacxDfUHpGQEAVxQeLGAQGVWolL+WsCRVCk/gu8mdld78TjxinhQ9AcWu/s77157/c+5mOvXjtO GDokQlKeNoP65VqASBryiKajZnC33720HiCpcBphxlPSDCZEBte23n3nKt5UMUkIAvlUbuJmECuV bS4tyRCGsbzMM5LCuyEXCVbwKEZLkcBHoDdhS8u12tpSgmkaoBQnoPbOcEhDgvpaZbBVKO8weEyV 1AMhEz2tmjgSBhsd1DVCTmSbCXSIWTOAeSJ+1CfHKkAMSwUvmkHN/AVLW1eX8GYuxNQc2Ypc1/zl crlAdLBs5hSjQTlpvdvYuLJT6jcApmZxnU6n3amX+gwAhyF4am2p6mx01+utQmcFZH/O6m7XVmsN F1/RvzJj80ar1VrdyG2xSg3I/mzM4Ndra43tZQdvQBa/OoNvtLbb7TUHb0AWvzaD717ZWGu4eAOK GU0PZtA6oN1urr2EDDm74YWvA3y9lsOnKMiGMrv0FEOeqnm5luAHXHQBoIEMK5oiNcnIEIeQxW3M 6EBQPQHeJLjyxg6FcmZIz4VkKGimmsH7GYaKmOp79fzbV8+folfPn5w8fHby8IeTR49OHn5vdTmC N3A6qgq+/PqT37/8EP329KuXjz/z42UV//N3H/3046d+IFTQ1KIXnz/55dmTF198/Os3jz3wbYEH VXifJkSi2+QI7fMEfDPEuJaTgTifRD/GtCqxnY4kTrGexaO/o2IHfXuCGfbgWsRl8J6ADuIDXh8/ cAzuxWKs8pA7nt2MEwe4yzlrceFl4aaeq0Jzf5yO/JOLcRW3j/Ghb+42Tp34dsYZtE7qU9mOiWPm HsOpwiOSEoX0O35AiIev+5Q6vO7SUHDJhwrdp6iFqZeSPh042TQVukETiMvEZyDE2+Fm9x5qcebz eoccukioCsw8xvcJc2i8jscKJz6VfZywKuG3sIp9RvYmIqziOlJBpEeEcdSJiJQ+mTsC/K0E/SZ0 D3/Yd9kkcZFC0QOfzluY8ypyhx+0Y5xkPmyPpnEV+548gBTFaI8rH3yXuxWinyEOOJ0b7nuUOOE+ uxvcpSPHpGmC6Ddj4YnldcKd/O1N2BAT02qgrzvtOqHp2969cO/eFtRbPDdOdex5uNN9us1FRP/9 bXoHj9M9ApUxu1a97dJvu3Twn+/S8+r54nvztB1Dp9Z7J7vpNlvwZO4OfEgZ66kJI7ek2YRLWISi LgxqOXP6JOWJLIvhp65kmMDBjQQ2Mkhw9QFVcS/GGWzg64FWMpK56pFEGZdwcDTDXt0aD4cAZY+d q/pAYjuHxGqXR3Z4RQ8X545SjbFqZA63xUQrWsGik61cyZWCb28yWV0btfBsdWOaaYrObKXLmmJz QAfKS9dgsGQTdjcI9kTA8hqc//XUcPDBjESadxujIiwmCn9NiHKvrSMxjogNkTNcYbNuYlek0Ix/ 2j2bI+djs2QNSDvbCJMW8/NnQZILBVOSQfB0NbG0WlssRUfNYGN1eTVAIc6awRCOvPAzySBoUu8H MRvBvVGohM3aM2vRFOnU4w1/VtXhFmNOwThlnAmpdrCMbQzNqzxULNUzWfuXVxs62S7GAU8zWcyK lXVIkX/MCgi1G1oyHJJQVYNdGdHc2ce8E/KxIqIXR0dowMZiH0P4gVPtT0Ql3FyYgtYPcM2m2Tav 3N6ad5rq5ZbB2XHMshjn3VJf0xQVZ+Gmn5Q2mKeKeeCb13bj3Pld0RV/Ua5U0/h/5opeDuAWYSXS EQjhlldgpCulGXChYg5dKItp2BWw7pveAdkCV7XwGsiHu2bzvyCH+n9bc1aHKWs4DKp9OkKCwnKi YkHIHrQlk31nKKvnS49VyXJFJqMq5srMmj0gh4T1dQ9c0z04QDGkuukmeRswuNP55z7nFTQY6T1K td6cTlYunbYG/u6Niy1mcOrUXkLnb8F/aWK5uk9XPytvxIs1suqIfjHdJTWKqnAWv42NfKo3NGGR Bbiy1tqONePx8mphHERx1mMYLPczGdwFIf0PrH9UhMx+uNALap/vQ29F8B3C8ocgqy/prgYZpBuk /TWAfY8dtMmkVVlq852PZq1YrC94o1rOe4psbdki8T4n2eUmyp3OqcWLJDtn2OHajs2lGiJ7ukRh aFicQ0xgzBev6kcpPngAgd6B6/8xs5+pZAZPpg6yPWGya8CjSf6TSbvg2qzTZxiNZOk+GSIaHRfn j5IJW0L2U0mxRTZoLaYTrRRc8R0aXMEcr0XtalkKL58tXEqYmaFll8LmUs2nAD6U5Y1bH+0Ab5us 9VoXV8EUS/8MZQsY76fMe/JZlDJ7UHxtoN6AMnX8espypoC82cSDT50Cw9GrZ/ovLDo2003Kbv0B AAD//wMAUEsDBBQABgAIAAAAIQC0z1gZuwAAACQBAAAsAAAAcHB0L25vdGVzTWFzdGVycy9fcmVs cy9ub3Rlc01hc3RlcjEueG1sLnJlbHOEj8EKwjAQRO+C/xD2btL2ICJNehGhV6kfENJtGmyTkESx f2+gFwuCl4WZZd/M1s17nsgLQzTOcihpAQStcr2xmsO9ux5OQGKStpeTs8hhwQiN2O/qG04y5aM4 Gh9JptjIYUzJnxmLasRZRuo82rwZXJhlyjJo5qV6SI2sKoojC98MEBsmaXsOoe1LIN3ic/J/thsG o/Di1HNGm35EsJR7YQbKoDFxoHR11lnR3BWYqNnmN/EBAAD//wMAUEsDBBQABgAIAAAAIQCTCm11 EwcAAOcdAAAUAAAAcHB0L3RoZW1lL3RoZW1lMy54bWzsWc1vG0UUvyPxP4z23sZOnDSJ6lSxY7fQ po1it6jH8e7YO83szmpmnMQ31B6RkBAFcUHixgEBlVqJS/lrAkVQpP4LvJnZXe/E48Yp4UPQHFrv 7O+9ee/3PuZjr147Thg6JEJSnjaD+uVagEga8oimo2Zwt9+9tB4gqXAaYcZT0gwmRAbXtt595yre VDFJCAL5VG7iZhArlW0uLckQhrG8zDOSwrshFwlW8ChGS5HAR6A3YUvLtdraUoJpGqAUJ6D2znBI Q4L6WmWwVSjvMHhMldQDIRM9rZo4EgYbHdQ1Qk5kmwl0iFkzgHkiftQnxypADEsFL5pBzfwFS1tX l/BmLsTUHNmKXNf85XK5QHSwbOYUo0E5ab3b2LiyU+o3AKZmcZ1Op92pl/oMAIcheGptqepsdNfr rUJnBWR/zupu11ZrDRdf0b8yY/NGq9Va3chtsUoNyP5szODXa2uN7WUHb0AWvzqDb7S22+01B29A Fr82g+9e2VhruHgDihlND2bQOqDdbq69hAw5u+GFrwN8vZbDpyjIhjK79BRDnqp5uZbgB1x0AaCB DCuaIjXJyBCHkMVtzOhAUD0B3iS48sYOhXJmSM+FZChopprB+xmGipjqe/X821fPn6JXz5+cPHx2 8vCHk0ePTh5+b3U5gjdwOqoKvvz6k9+//BD99vSrl48/8+NlFf/zdx/99OOnfiBU0NSiF58/+eXZ kxdffPzrN4898G2BB1V4nyZEotvkCO3zBHwzxLiWk4E4n0Q/xrQqsZ2OJE6xnsWjv6NiB317ghn2 4FrEZfCegA7iA14fP3AM7sVirPKQO57djBMHuMs5a3HhZeGmnqtCc3+cjvyTi3EVt4/xoW/uNk6d +HbGGbRO6lPZjolj5h7DqcIjkhKF9Dt+QIiHr/uUOrzu0lBwyYcK3aeohamXkj4dONk0FbpBE4jL xGcgxNvhZvceanHm83qHHLpIqArMPMb3CXNovI7HCic+lX2csCrht7CKfUb2JiKs4jpSQaRHhHHU iYiUPpk7AvytBP0mdA9/2HfZJHGRQtEDn85bmPMqcocftGOcZD5sj6ZxFfuePIAUxWiPKx98l7sV op8hDjidG+57lDjhPrsb3KUjx6Rpgug3Y+GJ5XXCnfztTdgQE9NqoK877Tqh6dvevXDv3hbUWzw3 TnXsebjTfbrNRUT//W16B4/TPQKVMbtWve3Sb7t08J/v0vPq+eJ787QdQ6fWeye76TZb8GTuDnxI GeupCSO3pNmES1iEoi4Majlz+iTliSyL4aeuZJjAwY0ENjJIcPUBVXEvxhls4OuBVjKSueqRRBmX cHA0w17dGg+HAGWPnav6QGI7h8Rql0d2eEUPF+eOUo2xamQOt8VEK1rBopOtXMmVgm9vMlldG7Xw bHVjmmmKzmyly5pic0AHykvXYLBkE3Y3CPZEwPIanP/11HDwwYxEmncboyIsJgp/TYhyr60jMY6I DZEzXGGzbmJXpNCMf9o9myPnY7NkDUg72wiTFvPzZ0GSCwVTkkHwdDWxtFpbLEVHzWBjdXk1QCHO msEQjrzwM8kgaFLvBzEbwb1RqITN2jNr0RTp1OMNf1bV4RZjTsE4ZZwJqXawjG0Mzas8VCzVM1n7 l1cbOtkuxgFPM1nMipV1SJF/zAoItRtaMhySUFWDXRnR3NnHvBPysSKiF0dHaMDGYh9D+IFT7U9E JdxcmILWD3DNptk2r9zemnea6uWWwdlxzLIY591SX9MUFWfhpp+UNpininngm9d249z5XdEVf1Gu VNP4f+aKXg7gFmEl0hEI4ZZXYKQrpRlwoWIOXSiLadgVsO6b3gHZAle18BrIh7tm878gh/p/W3NW hylrOAyqfTpCgsJyomJByB60JZN9Zyir50uPVclyRSajKubKzJo9IIeE9XUPXNM9OEAxpLrpJnkb MLjT+ec+5xU0GOk9SrXenE5WLp22Bv7ujYstZnDq1F5C52/Bf2liubpPVz8rb8SLNbLqiH4x3SU1 iqpwFr+NjXyqNzRhkQW4stbajjXj8fJqYRxEcdZjGCz3MxncBSH9D6x/VITMfrjQC2qf70NvRfAd wvKHIKsv6a4GGaQbpP01gH2PHbTJpFVZavOdj2atWKwveKNaznuKbG3ZIvE+J9nlJsqdzqnFiyQ7 Z9jh2o7NpRoie7pEYWhYnENMYMwXr+pHKT54AIHegev/MbOfqWQGT6YOsj1hsmvAo0n+k0m74Nqs 02cYjWTpPhkiGh0X54+SCVtC9lNJsUU2aC2mE60UXPEdGlzBHK9F7WpZCi+fLVxKmJmhZZfC5lLN pwA+lOWNWx/tAG+brPVaF1fBFEv/DGULGO+nzHvyWZQye1B8baDegDJ1/HrKcqaAvNnEg0+dAsPR q2f6Lyw6NtNNym79AQAA//8DAFBLAwQUAAYACAAAACEAkwptdRMHAADnHQAAFAAAAHBwdC90aGVt ZS90aGVtZTIueG1s7FnNbxtFFL8j8T+M9t7GTpw0iepUsWO30KaNYreox/Hu2DvN7M5qZpzEN9Qe kZAQBXFB4sYBAZVaiUv5awJFUKT+C7yZ2V3vxOPGKeFD0Bxa7+zvvXnv9z7mY69eO04YOiRCUp42 g/rlWoBIGvKIpqNmcLffvbQeIKlwGmHGU9IMJkQG17befecq3lQxSQgC+VRu4mYQK5VtLi3JEIax vMwzksK7IRcJVvAoRkuRwEegN2FLy7Xa2lKCaRqgFCeg9s5wSEOC+lplsFUo7zB4TJXUAyETPa2a OBIGGx3UNUJOZJsJdIhZM4B5In7UJ8cqQAxLBS+aQc38BUtbV5fwZi7E1BzZilzX/OVyuUB0sGzm FKNBOWm929i4slPqNwCmZnGdTqfdqZf6DACHIXhqbanqbHTX661CZwVkf87qbtdWaw0XX9G/MmPz RqvVWt3IbbFKDcj+bMzg12trje1lB29AFr86g2+0ttvtNQdvQBa/NoPvXtlYa7h4A4oZTQ9m0Dqg 3W6uvYQMObvhha8DfL2Ww6coyIYyu/QUQ56qebmW4AdcdAGggQwrmiI1ycgQh5DFbczoQFA9Ad4k uPLGDoVyZkjPhWQoaKaawfsZhoqY6nv1/NtXz5+iV8+fnDx8dvLwh5NHj04efm91OYI3cDqqCr78 +pPfv/wQ/fb0q5ePP/PjZRX/83cf/fTjp34gVNDUohefP/nl2ZMXX3z86zePPfBtgQdVeJ8mRKLb 5Ajt8wR8M8S4lpOBOJ9EP8a0KrGdjiROsZ7Fo7+jYgd9e4IZ9uBaxGXwnoAO4gNeHz9wDO7FYqzy kDue3YwTB7jLOWtx4WXhpp6rQnN/nI78k4txFbeP8aFv7jZOnfh2xhm0TupT2Y6JY+Yew6nCI5IS hfQ7fkCIh6/7lDq87tJQcMmHCt2nqIWpl5I+HTjZNBW6QROIy8RnIMTb4Wb3Hmpx5vN6hxy6SKgK zDzG9wlzaLyOxwonPpV9nLAq4bewin1G9iYirOI6UkGkR4Rx1ImIlD6ZOwL8rQT9JnQPf9h32SRx kULRA5/OW5jzKnKHH7RjnGQ+bI+mcRX7njyAFMVojysffJe7FaKfIQ44nRvue5Q44T67G9ylI8ek aYLoN2PhieV1wp387U3YEBPTaqCvO+06oenb3r1w794W1Fs8N0517Hm40326zUVE//1tegeP0z0C lTG7Vr3t0m+7dPCf79Lz6vnie/O0HUOn1nsnu+k2W/Bk7g58SBnrqQkjt6TZhEtYhKIuDGo5c/ok 5Yksi+GnrmSYwMGNBDYySHD1AVVxL8YZbODrgVYykrnqkUQZl3BwNMNe3RoPhwBlj52r+kBiO4fE apdHdnhFDxfnjlKNsWpkDrfFRCtawaKTrVzJlYJvbzJZXRu18Gx1Y5ppis5spcuaYnNAB8pL12Cw ZBN2Nwj2RMDyGpz/9dRw8MGMRJp3G6MiLCYKf02Icq+tIzGOiA2RM1xhs25iV6TQjH/aPZsj52Oz ZA1IO9sIkxbz82dBkgsFU5JB8HQ1sbRaWyxFR81gY3V5NUAhzprBEI688DPJIGhS7wcxG8G9UaiE zdoza9EU6dTjDX9W1eEWY07BOGWcCal2sIxtDM2rPFQs1TNZ+5dXGzrZLsYBTzNZzIqVdUiRf8wK CLUbWjIcklBVg10Z0dzZx7wT8rEiohdHR2jAxmIfQ/iBU+1PRCXcXJiC1g9wzabZNq/c3pp3murl lsHZccyyGOfdUl/TFBVn4aaflDaYp4p54JvXduPc+V3RFX9RrlTT+H/mil4O4BZhJdIRCOGWV2Ck K6UZcKFiDl0oi2nYFbDum94B2QJXtfAayIe7ZvO/IIf6f1tzVocpazgMqn06QoLCcqJiQcgetCWT fWcoq+dLj1XJckUmoyrmysyaPSCHhPV1D1zTPThAMaS66SZ5GzC40/nnPucVNBjpPUq13pxOVi6d tgb+7o2LLWZw6tReQudvwX9pYrm6T1c/K2/EizWy6oh+Md0lNYqqcBa/jY18qjc0YZEFuLLW2o41 4/HyamEcRHHWYxgs9zMZ3AUh/Q+sf1SEzH640Atqn+9Db0XwHcLyhyCrL+muBhmkG6T9NYB9jx20 yaRVWWrznY9mrVisL3ijWs57imxt2SLxPifZ5SbKnc6pxYskO2fY4dqOzaUaInu6RGFoWJxDTGDM F6/qRyk+eACB3oHr/zGzn6lkBk+mDrI9YbJrwKNJ/pNJu+DarNNnGI1k6T4ZIhodF+ePkglbQvZT SbFFNmgtphOtFFzxHRpcwRyvRe1qWQovny1cSpiZoWWXwuZSzacAPpTljVsf7QBvm6z1WhdXwRRL /wxlCxjvp8x78lmUMntQfG2g3oAydfx6ynKmgLzZxINPnQLD0atn+i8sOjbTTcpu/QEAAP//AwBQ SwMECgAAAAAAAAAhAM/uoathJAAAYSQAABcAAABkb2NQcm9wcy90aHVtYm5haWwuanBlZ//Y/+AA EEpGSUYAAQEBAEgASAAA/+IHuElDQ19QUk9GSUxFAAEBAAAHqGFwcGwCIAAAbW50clJHQiBYWVog B9kAAgAZAAsAGgALYWNzcEFQUEwAAAAAYXBwbAAAAAAAAAAAAAAAAAAAAAAAAPbWAAEAAAAA0y1h cHBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALZGVzYwAA AQgAAABvZHNjbQAAAXgAAAVsY3BydAAABuQAAAA4d3RwdAAABxwAAAAUclhZWgAABzAAAAAUZ1hZ WgAAB0QAAAAUYlhZWgAAB1gAAAAUclRSQwAAB2wAAAAOY2hhZAAAB3wAAAAsYlRSQwAAB2wAAAAO Z1RSQwAAB2wAAAAOZGVzYwAAAAAAAAAUR2VuZXJpYyBSR0IgUHJvZmlsZQAAAAAAAAAAAAAAFEdl bmVyaWMgUkdCIFByb2ZpbGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAG1sdWMAAAAAAAAAHgAAAAxza1NLAAAAKAAAAXhockhSAAAAKAAAAaBjYUVTAAAA JAAAAchwdEJSAAAAJgAAAex1a1VBAAAAKgAAAhJmckZVAAAAKAAAAjx6aFRXAAAAFgAAAmRpdElU AAAAKAAAAnpuYk5PAAAAJgAAAqJrb0tSAAAAFgAAAshjc0NaAAAAIgAAAt5oZUlMAAAAHgAAAwBk ZURFAAAALAAAAx5odUhVAAAAKAAAA0pzdlNFAAAAJgAAAqJ6aENOAAAAFgAAA3JqYUpQAAAAGgAA A4hyb1JPAAAAJAAAA6JlbEdSAAAAIgAAA8ZwdFBPAAAAJgAAA+hubE5MAAAAKAAABA5lc0VTAAAA JgAAA+h0aFRIAAAAJAAABDZ0clRSAAAAIgAABFpmaUZJAAAAKAAABHxwbFBMAAAALAAABKRydVJV AAAAIgAABNBhckVHAAAAJgAABPJlblVTAAAAJgAABRhkYURLAAAALgAABT4AVgFhAGUAbwBiAGUA YwBuAP0AIABSAEcAQgAgAHAAcgBvAGYAaQBsAEcAZQBuAGUAcgBpAQ0AawBpACAAUgBHAEIAIABw AHIAbwBmAGkAbABQAGUAcgBmAGkAbAAgAFIARwBCACAAZwBlAG4A6AByAGkAYwBQAGUAcgBmAGkA bAAgAFIARwBCACAARwBlAG4A6QByAGkAYwBvBBcEMAQzBDAEOwRMBD0EOAQ5ACAEPwRABD4ERAQw BDkEOwAgAFIARwBCAFAAcgBvAGYAaQBsACAAZwDpAG4A6QByAGkAcQB1AGUAIABSAFYAQpAadSgA IABSAEcAQgAggnJfaWPPj/AAUAByAG8AZgBpAGwAbwAgAFIARwBCACAAZwBlAG4AZQByAGkAYwBv AEcAZQBuAGUAcgBpAHMAawAgAFIARwBCAC0AcAByAG8AZgBpAGzHfLwYACAAUgBHAEIAINUEuFzT DMd8AE8AYgBlAGMAbgD9ACAAUgBHAEIAIABwAHIAbwBmAGkAbAXkBegF1QXkBdkF3AAgAFIARwBC ACAF2wXcBdwF2QBBAGwAbABnAGUAbQBlAGkAbgBlAHMAIABSAEcAQgAtAFAAcgBvAGYAaQBsAMEA bAB0AGEAbADhAG4AbwBzACAAUgBHAEIAIABwAHIAbwBmAGkAbGZukBoAIABSAEcAQgAgY8+P8GWH TvZOAIIsACAAUgBHAEIAIDDXMO0w1TChMKQw6wBQAHIAbwBmAGkAbAAgAFIARwBCACAAZwBlAG4A ZQByAGkAYwOTA7UDvQO5A7oDzAAgA8ADwQO/A8YDrwO7ACAAUgBHAEIAUABlAHIAZgBpAGwAIABS AEcAQgAgAGcAZQBuAOkAcgBpAGMAbwBBAGwAZwBlAG0AZQBlAG4AIABSAEcAQgAtAHAAcgBvAGYA aQBlAGwOQg4bDiMORA4fDiUOTAAgAFIARwBCACAOFw4xDkgOJw5EDhsARwBlAG4AZQBsACAAUgBH AEIAIABQAHIAbwBmAGkAbABpAFkAbABlAGkAbgBlAG4AIABSAEcAQgAtAHAAcgBvAGYAaQBpAGwA aQBVAG4AaQB3AGUAcgBzAGEAbABuAHkAIABwAHIAbwBmAGkAbAAgAFIARwBCBB4EMQRJBDgEOQAg BD8EQAQ+BEQEOAQ7BEwAIABSAEcAQgZFBkQGQQAgBioGOQYxBkoGQQAgAFIARwBCACAGJwZEBjkG JwZFAEcAZQBuAGUAcgBpAGMAIABSAEcAQgAgAFAAcgBvAGYAaQBsAGUARwBlAG4AZQByAGUAbAAg AFIARwBCAC0AYgBlAHMAawByAGkAdgBlAGwAcwBldGV4dAAAAABDb3B5cmlnaHQgMjAwNyBBcHBs ZSBJbmMuLCBhbGwgcmlnaHRzIHJlc2VydmVkLgBYWVogAAAAAAAA81IAAQAAAAEWz1hZWiAAAAAA AAB0TQAAPe4AAAPQWFlaIAAAAAAAAFp1AACscwAAFzRYWVogAAAAAAAAKBoAABWfAAC4NmN1cnYA AAAAAAAAAQHNAABzZjMyAAAAAAABDEIAAAXe///zJgAAB5IAAP2R///7ov///aMAAAPcAADAbP/h AHRFeGlmAABNTQAqAAAACAAEARoABQAAAAEAAAA+ARsABQAAAAEAAABGASgAAwAAAAEAAgAAh2kA BAAAAAEAAABOAAAAAAAAAEgAAAABAAAASAAAAAEAAqACAAQAAAABAAABAKADAAQAAAABAAAAwAAA AAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCADAAQADAREAAhEBAxEB/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAEC AwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHB CSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0 dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX 2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD+/igAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoA KACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgD5Z/az/av8K/sjeDPAHivxH8Pfil8V dU+KXxh8E/Av4f8AgD4Pad4L1Hxr4l+IXj+HWZ/D9hbD4heOvhx4Ts7J49B1Bru/1XxZYRQERKqy tJgAHh+m/wDBUD9ms/A34xfGrxlp3xb+F+o/AP4p6L8Cfil8CfHfw7u/+GhdF+OPjFfB0nw3+E2i fDrwff8Ai6Hx94s+K8fxD8CT/DOf4e694q8M+LbXxRZXtj4iFnZa1caWAY/iv/gphoXw3+DPxR+M fxd/Y+/ba+EMfw0134G+HbPwF47+HHwpTxZ8T9S/aI+Lnh/4J/De2+GXiHw18bvEnwf1TUJPHXij RLfxR4f8SfFPwr4p8GaZf2mp+JtC02C9sBdgHuv7Mv7Y/gT9prxF8Xvh5a+Afi78F/jL8BrzwXD8 Wfgp8cvDOh+HfH/hTS/iTpWp6z8O/FMd14N8VePfAPibwn42tNB8Rx6Hr/g/xx4hs21Dw3r2l6gb DUtMntQAYXxg/b4+BHwQ/az/AGc/2NvGo8Zn4pftMW2tT+E9b0jQbO8+Hvg2e103xRf+D9N+Jvia fWbO58Mal8W7rwL460H4VW9po+sr4o8Q+Dde0ueXS5IbV7wA+xJdZ0eA6oJ9W02E6JbLe60Jb61j OkWckM1yl3qm+Uf2fbPb289wtxd+VE0ME0ocpG7AA8Oh/ak+B1/8Wfif8B9H8eaTqvxi+Enw58Ff FLxf4GhNxDdw+FPiKPiMfB0+nancW8ej6ze6kPhV4zmvtL0a+1DU9AsbKx1HXrPT7LWtHnvgDP8A 2TP2mPCP7WX7PXwJ+PPh63t/DNx8bfgd8Kfjkfh1ea9pmseKPBWjfFjwdpXjDSNN10WPku7W8Opm yTU/sNpa6jJayzWsaodigHvNp4k8O6hqmq6JYa/ot7rWhCBtc0i01WxudU0ZbpDLbNqthDO93pwu YwZIDeRQiZAXj3KCaAK1p4x8I38t3DY+KfDl7NYaRZa/fRWmuaZcy2Whalbtd6drd3HDdO9vpF/a o9zZalMEs7q3VpoJpI1LAA+Z/BH7bHwT+LvhH4UeOfgXfah8bPDvxY+JVz8OrOXwZdeF9H1bwnBp WteLvDfiXx74u8NfEbxL4F8SReCfDGv+Dr/TdSk0DSfEHii++3aVqPh3wxrek3T38IB9Qw+JPD1x rt34Xg17RZ/E1hZQ6nf+HYdUsZNdstOuHVLfULvSEnbULayndlSG7mt0gldlVJGJAIB5v4//AGgf g18M/hX8U/jX4t+IfhqD4afBXw14p8V/E3xJpOoR+JI/C2leDNKutZ8QRXdj4eOp6lPrNrZWcwg8 PWdpca7qF40Gnafp91f3NvbygGL4X/aJ8FePfGXw58NfDu01Dx/4e+Inw78R/EZfiT4Y1bwRc+Ef B9ho7+Cv7E0Xxlpl74usfiFp+veOLbxk954Zh03wPq+nwR+GfEMHifUvDt4ml22qAHsGm+J/DWtX ms6fo/iHQ9Wv/DtyLPxBZabq1hf3mhXjKzraazbWtxLNplyyI7iC9SCUqrMFIBIAG6Z4p8Ma1eS6 fo/iPQdWv4dO07WJrHTNX0+/vItJ1iIz6Tqktta3EsyadqkIM2nXzILa9iBktpZV5oA+PPjn/wAF A/gP+zx+1Z+zL+yD8R7fx3bfET9qy18S3Hw+8UaZ4f0+++G2gT6BqWjeH9O0/wAf+IZddtdU8P3v jXxb4i0HwZ4MNn4f1mz1LxXrOlaRqF5pUmpWL3ABY+O/7fPwM/Z7/ab/AGXv2S/Gdt461f4sftX6 vrOleCB4R0DT9W8N+DY9MsdQu9N1X4n6vea5pU3hnTPGFxoviHS/Bp07T9f1DXNQ8M+JSmnwWGg6 nf2wB9gHxH4eGu/8Iude0b/hJjYHVf8AhHTqlj/bp0wSeUdS/sjz/wC0PsAl/dG8+z/Z/M+TzN3F AHw18Sf+CjfwB8MfAD4rfH/4a6tF8ZtH+Dnx28Pfs9eNfD/h29fQtUsfHuo/tE+Ef2cPECxvrdgh utJ8N+LPFMmowa5ZWt3oPijTtKmfw7q15b3UF6AD7n0vxBoOuW13e6LrekaxZ6fe3mm393pepWWo W1lqOnNs1Cwu57SaaK2vbF/kvLWZ0ntW+WeNDxQBHoniXw54m05tY8N+INE8QaSs1xbtqmiarY6t pyz2jFLuBr6wnuLYTWrgrcRmXfCwKyhTxQB85+Gv2rvBXi39qjxR+zFoNpFqsnhr9m3wL+0gfiTp fiDSdT8Kaho3jb4p/FL4Wf8ACN2y2TSsuoaLqXwu1G/v783j2pi1CO08uK4tJywB9H6D4i0DxTpk OteGNc0fxHo9y80dvq2g6nZavpk8lvM8FwkN/p89xayvBPHJDMqSs0UyPG4V1YAA2KACgAoAKACg AoAKACgD8q/+Crnwl+LHxj8JfsU+Hvg9d/EPw/4j0b/goh+zh4s1T4hfDXwVpXjzXPhR4Y0fTPiN Fq3xLvtH8SeF/GPhC20Pw3JfWY1DVfGegXvhazkvLZNTX9/CrAHzr+1X+wV4o+BXwc+H/wAYvg5b fGb9sD4w/Dv/AIKN/Ab/AIKCftM3Hie68Eal8e/2krH4feHW+Efim18H+H/Cvhv4a/Db+3Phl8Kp vD+rfCX4U+EPD3gzRZ4/hhpXh3QLefxTqqy6uAH7f3xj1/8Ab1/Yf+KPw/8A2cvgn+2j4W8Q6T8f v+CeupWPi3x5+yR8VPhRr1veWP7en7P/AIk8W6p4F+Hvxy8CaR4u8Y3PwY8NeFNW8eeO9cn+Gur/ AAt0TRdOa81XX9U0601u3swD9I/2Zf2Q9F/Z28U/GL4o638V/ij8fvjr8frnwMfiv8Z/i4fAFj4h 1nRPhhpWr6P8OPBWg+FfhR4F+Gvw58H+CvBNv4j8T3Oj6ToPg+3v7vVfFHiDWfEWsa7q2pS3gAPw o/aB/ZX/AOCiX7Umn/8ABQ39qL4Z+F/hb4F8Ra/8cvA3iP8AZX8LfGL4ffF7Sv2jbLS/+CYPja+1 P9naXwCq6toen+HNB+OXxj8PfFPx74ZXXvDN3/b/AIO+O9zev9o0DX7BQAaX7Rvj74pTaf8A8FT9 aX9kb9sTWdf/AOCl3/BM34FXH7OfhLwX+zd8VPF91D46vf2bfjv4D8bfCn4qa3YeGovD3wW+IXwx 1nxn4fuPFHhj4van4H1zUbO8Fj4P0zxL4pMHhucA9k+B3wC8GfCf/gol4s8V+Nf2TdbtvGnx0/4J vfsh6b8F/jZpP7LniPxLpfh342fCzwp+1tov7RGi+LfjT4e8AappPwU+Jus+BvFHw08O6o/xC8Te DdU+Iult4c8FWd5r19Bpeg0AeRfsOfsOX/7PXhf/AIIReMfhV+zRqPwV+MU37KHxN8Iftd+OofhR rmgeMNO8Q+L/ANjjRNfg0T9qHWZtHg8RJ9j+Ofhrw3b6B4b+J12g8N+INEsPCHhax0lbK10eEA8m /wCCa37J2v8Ahzxb+yzqPxRtvjJ8PP2vfgP8KPjt4f8A2gPD9j/wTc+Lnwu/4W34z8dfC/xdoPxK j+N37fU8Gp/Cj9pXwx4u+KlxYfGPwF4g03xjr9/478c6f4d1jStO0a6/4SDS9MAPXP2H/wBg3Sfg z4a/4IQ63pP7Jt14D8Xa5+yf8Sfh3+3Zqt58IdT0/wASalaeOv2NtC1HVvAf7Vt/q2if2tcWVx8W PDui6Ho3hH4tTNZ6Bq+l2Pgjw5pmmW1nb6JEAeR/s0fsieDPC/wi/YI8P+E/2Gdb+HP7T/7MX/BV m3s/j745j/Y68R+AfEVj8Mrr4k/tWarpPizS/jU3w00nSviV8GX8F3Xw9vH8Z+CfGfijwHomlap4 K0vW9R0q8n0rTVAPfv2RfBXgr4R/D343eHfH/wDwTy+Jnxb/AOCn/h7W/wDgoL8QPHHxP8W/sveL 9O0P48ap4t1v41a74Fih/bf1nwZb/DnxR8N/j18PNQ8BfCTwP4N0H4keJdb8O6fc6N4Y1nwFo8Hg XUL3RwD43+Hv7MvxC+PFt+2/pGg/smaZofhL45/8EZvH3gGLwD4X/wCCafxJ/YK+C5/az8M69c65 8LPhfYeAvjXe6tcfEH4m/CLXvE5HgT4m3ENrHbzxSXHgfWL0+HNRk0EA+jdG/Zwl8Rat+zF8Rv2B f2U/EP7MfxF8R/8ABJH/AIKWfB/VvGz/ALKPir9lDW/DP7VGoaH+xjofwf0/4tT+Jvhz8O9UsfEi fEHSPHN74E1rxP5ll4ki0Dxr4k8CarreiW2p6swB0P7LfwY8E6l8Zv2FNU/ZL/Ys+MX7LWqfAf8A ZZ+O/gv9ubxF43/Zf+In7OMni2TxR8GtB8O+Fvgx4q8aeM/BvhCz/as+Id78eoLH4pW/jXwbq3xZ 0O0j8N+IfF0njaG68eWj+IAC1+wP+xKf2eLH/ggZ478E/sxa38J/iYP2YfHnhP8AbR8YWfwv13w5 47hu/E/7H/h7XpPDH7TPiG50mHxFby2/xl8LeHtO8MeHvifeRp4V8QaLpnhDwrY6RHp9po8IB9Hf 8FEv2O/iJ+1l+2EdA8K6J4m0LzP+CYP7Rlj8KvjbFoWo/wDCIfDX9q/wh+1r+x18aP2cLq48Xmzf RdO8UaV48+GVh42stCkv7fWNW8O+FvEU1rC1haajPAAfK/w4+Gv7Un7SHiL9jX/goD8d/wBnD4of DH45fHP/AIKX/AjUfE/wc1fwZ4kfxL+zF+yn+zj+yz+1l8MvCeneOrGWwnv/AAb4Z1z40eNvif8A Fu51vXJLLTHk+O/hHT7mWK7l06KUA89+EP7J/im//a8lT9oeX4seB/2kvDP/AAVA+IX7RHh34j+D v+CbXxZ8c6z8SvhdP8cdb134b26/8FF/DsGtfDPQPgD4v/ZsvvDfwZ8ceCPFXiHw8fh/4Ps7z4bX /hJdQ0vQLvVgChrP7JPhbS/2Mv8Agp/+yx4J/Yt8beDvi7r/APwUP0zxJLD8P/2V/Hngqw+Jf7LP jX/gof8AC34j/DN/hp8YPBXgLSfDXj/wV4T+E1zrN83hz4f+NdT1L4O6X4f12fWNI8H2umx3TgHq n7VX7F3ij4a+Ov8Agof8P/2Wf2W9f8P/ALMHjH4Z/wDBIbx749+C/wABPhtJ4M8JfHnwV8Nf2pvj vH+2r8NvhTpXhuy0Hwr4m+J3ij9lrwv4T8K/EHwh4amfxN4x8LT+EPCmsW13L4o8O298AcT8ZvgB 4g+KXhn/AIKSeM/+Cf8A+yp8XPg1+zD8RP2V/wBk3wF4g+DVj+z34/8A2Q9c/aY+Ivw8/aC8TeLv 2kYvhT+z/wCO/Cfwo8ajXr79kO9n+B9/4un8FeGf+FoazrOieC/D974lTwkbq3ANKH9nX9nP4lfG b/goZq3wl/ZB/al/ZU/Yz+OH/BNb4M/B/XPEPwv/AGJfip8HvEPizx/F8ZPi1F401T4Y/s16l8Mb Lxl4j1bwt4Q8QeDbfxj4Qm+DsWo/ELQtE1iS38KeNfDGpWer6+AfrL/wSpvfGs/wO+J2n+K/gn4I +FGj6D8efE2ifDvxr4H/AGWfFf7FNt+0n4Fs/A3w5Nj8fdf/AGYvHlpZ+NPhl4n1TVpNZ+HGqpr0 SQ+KF+Gtt4u8L21h4K1vw1YWwB+nVABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAU AFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQA UAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQ AUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFAB QAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQBlvrmjR6k2jS atpyautqL5tMe9t01BbJpBCt4bNpBcC0aZlhFyY/JMzCIP5hC0AVr7xP4e00akb/AFnTrUaPYxan qnnXUa/YdPnuryxiu7n5iY4XvNPvbXeek9tNE2HUigDRTUbCQuqXtqxjaNXxPGdpmjtpYv4uRJHe WjoRkOLiHaSZFyAY7+MfCkesnw8/iTRBryzLbvo/9p2h1NJ2tUvRFJZCU3Eb/ZJYLlleNSsN1aSN hbu2MoBq2GqadqlvbXen31reW97Abm0lt5kkW4gHl7pYtpyyKZYg5A+QyIHwXAIBfoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgD5v8AiBdfBrxRqfiC18bSX+k6 jp0B8IanqM+nSrGEsY7rxbJpEd19g1OyneXRJLbX0hnSTFhr+h3NksOvTWoswDmdS8J/s5X0epJq muvPJrvhzUJLppJrmK5k8L6b401rVb+2toINLi8nTdO8Rxav9osIIFWK30+5vLmB0t7m+IA608Jf AvxTqfjnQtBtNU1XV4ZJ7jVLbTpdOVvKm8L6XfS6VojaqYtOtLa/0DxdZ2a2M5tX05zY6kjaTPa+ HdZoAnu2+Bfje8+169qGsx3ur2g1BPC2owTyf2CPiTpumWkl4Y9LsdQtoX8RMNEnju7jVdQsrHXo 7VNLl0/ULm9troAj8Cj4DaZ4ig1nw74m1c3el+LdN0a1iuHuBpdz4j8Z+H4dB0MyWVrpkQt5rmxF z4ehn1RNPurnVtNvv7VN7fW0N64B9Y0AFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFA BQAUAFABQAUAFABQBz2oeEfCmrXH2vVPDHh/Urvzp7j7Vf6Np13c/aLqzsdPuZ/PuLaSXzriw0zT bKeXfvltNOsbeRmhtLdIwD5q8V+Mvgl4Pv8Axjp+rfD7wnbal4Ltrm603SrCy0qFPEUd9o58Li2v Y7bT4dJH9o2vjLW9Jj0mebXLu00M+ItR1DTdOj/cXIB0OhfEX4X2lh408S+EvAWl2Fz4R8MeJ7i9 vbLTfDGlRvpngXRtJnfSLnW9Ma4j+xP9shsdKl0ltd0T7BZfbobr7KbaJwChoXj74Ianqq6A/gLw 3bazq2paV4UvjZaB4X1HRbyX+1L2y0gLq6Jbtf6E1zotjf6FLe2NpLd2ep+HL2w00SXQjtgD3OL4 d/D+CW2mh8DeD4prPUbbWLSaPwzoqS2ur2TmSz1S3kWyDw6jaSEyW19Gy3UEhLxSq3NAHY0AFABQ AUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQAUAFABQBVv7lrKxvLxLW5vntLW4 uVsrNFkvLxoIXlW1tY3eNHubgp5UCPIitK6hnUEsAD5mi+Knxr0pIbXW/hJJqviCXR9evjpmlSzW dvPeeH9QtLXyrLULUeJtKVNX0zVLTWYHv9ZhCGyutDs2v9auoLOIA9GHiT4n6hpFrf2XhPStIuv+ Eh8IWdzY3s2p388/h7W9B0a48Q6paRy2mgy2t34c1zWbm3S2v41W6s/DeoC7Gn3N8kdgAed6X8av iXq+s2Ohr8JZdP1YaHe61qmmXuo6qktowg1NdOt3u5fDUMEcMl7Hptpd3JUsZ7lm0WPXLOO9uLEA +jNCvL/UdD0bUNV046Rql9pWnXmpaSZjcHS7+6tIZ7zTjcGKEzmyuHktjMYYjL5W8xRltoANWgAo AKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgA oAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACg AoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKAC gAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKA CgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAKACgAoAK ACgAoAKACgAoAKACgAoA/9lQSwMEFAAGAAgAAAAhAFycRxROAQAAiQIAABEAAABwcHQvcHJlc1By b3BzLnhtbLSQzWrDMBCE74W+g9FdkWQ7dmxiBzt2odBDDu0DCFtOBNYPkvJTSt+9wnFLQy+59LbL MrPfzHpzEWNwYsZyJQtAFhgETHaq53JfgLfXJ7gCgXVU9nRUkhXgnVmwKR8f1jrXhlkmHXVeujOB N5I2pwU4OKdzhGx3YILahdJM+tugjKDOr2aPekPP/oEYUYhxggTlEsx6c49eDQPvWKO6o/AAVxPD xonEHri23276HrffOW6QSh+SXdyLdfMUHA0vwEebJts2iyuY4GgLYxKHsM7aGiYNiVKMCa7C9BN4 DYnzntuOmv5Z0D1re+4a6ugc1Z//4AneGWXV4BadEuiaE2l1ZkYrPkUleO7rRMcCYIDKNZowbxmb iFQ4CSuYZqsKxlGYwapuGljX1WqZJCFeEvzDyAZ6HN3E2Gj+X3hXzKlNP/5ufWfKLwAAAP//AwBQ SwMEFAAGAAgAAAAhAEH78+SfAQAAYwMAABEAAABwcHQvdmlld1Byb3BzLnhtbIxTy07rMBTcI/EP lveQpILeNmrKBsEGCaT2svd1TlNfJbZlm9Ly9Yzj9AUs2Pm85syM7dndtmvZhpxXRle8uM45Iy1N rXRT8b/Lh6sJZz4IXYvWaKr4jjy/m19ezGy5UfT+4hgAtC9Fxdch2DLLvFxTJ/y1saRRWxnXiYDQ NVntxDuAuzYb5fk464TSfJh3v5k3q5WSdG/kW0c6JBBHrQgg79fK+j2a/Q2adeQB00+fUZpDnI60 29deYozRG4yj+olWgfkPWHU7HuU8O60tje1L05vxuC9l33F8q2o6wspFW6eIeS3s0jw6VVcct5DC 53//SQaPdTxukkPvRriFFC3uI+V9DOYzUfotwzVObzkDSpH3LJDdfc+C2zBlS+NUozTbVvxqWow4 2+FQJHVoG5bG/c0b2D/5cDgzjMJD2G3cB2fWgOqoSOqH9iE5mewtOYJE8IMB81mkdG6PNoH8krbh xLHj8YvqKPcH2V/ScUly61Q3JiF6z/CgGM0/UGhwRwsrJJ4ykzDtD14zvokEQjriVWBykx7PJwAA AP//AwBQSwMEFAAGAAgAAAAhANj9jY+sAAAAtgAAABMAAABwcHQvdGFibGVTdHlsZXMueG1sDMxJ DoIwGEDhvYl3aP59LUNRJBTCICt36gEqlCHpQGijEuPdZfnyki/NP0qil1jsZDQD/+ABEro13aQH Bo97g2NA1nHdcWm0YLAKC3m236U8cU95c6sUV+vQpmibcAajc3NCiG1Hobg9mFno7fVmUdxtuQyk W/h705UkgecdieKTBtSJnsE3qoIgorTAp8vliGlIA1x6NMZxVNbVuan9Kix+QLI/AAAA//8DAFBL AwQUAAYACAAAACEAwJjgHmsBAACrAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLLboMwEEX3lfoPyHswJk0fFhClqbJqpEil6mNn2RNi FQyynZD8fQ0klKhddGnfO8d3ZhzPDmXh7UEbWakEkSBEHiheCanyBL1mS/8eecYyJVhRKUjQEQya pddXMa8przSsdVWDthKM50jKUF4naGttTTE2fAslM4FzKCduKl0y6446xzXjXywHHIXhLS7BMsEs wy3QrwciOiEFH5D1ThcdQHAMBZSgrMEkIPjHa0GX5s+CThk5S2mPtevpFHfMFrwXB/fByMHYNE3Q TLoYLj/B76vnl65VX6p2VhxQGgtOrbQFpOvF2pvv7NZFlZxJW6kYD2Jr4xqYrXQ6L9wkvQ/IZe84 37ejLpixK7eVjQTxeLy0/pbbCg172S41JdMYj8/uyW4Q/bsgPNca7QdxVt4mi6dsidIoJJFPQp+Q jEwomdIo/GzDX9S3rfYX5Sngf4h3WfhAI0JvyIh4BqRd4svvlX4DAAD//wMAUEsDBBQABgAIAAAA IQC+oc097wMAALkkAAAoAAAAcHB0L3ByaW50ZXJTZXR0aW5ncy9wcmludGVyU2V0dGluZ3MxLmJp buQZTW/aMJT1Bpq0644sdzBQOtiUUjEoGhJto0In7VS5icvShjhKzDr2Q/Z795zEwSQhZTuUkB4q pcbv+X1/HpVKpTfw9+59qaSe/VpY1Z/E9UxqnyrNekOpElunhmnPT5Wb2ajWVc56FfXD8Gow+66d Vx3L9FhVu/kyGQ+qSg2hvuNYBKHhbFjVJuPprAo4EDq/VKrKD8aczwg9PT3VMb9V1+mCX/SQ5lKH uGw1AWQ1AKgbzFDgmQD7Bjlwapg661XK6iNZ9QBFiMxxTZvVNTwnI+ouMHxefKWu+ZvaDFvXxFMR vw9gIXg6PDP1R8Lqukswo66AKaseA/Rz6bkHehfcVVH4W6WcidJkZNF3XbxaI8X8XyAJAAVRW3A8 zxZHAkRbvU5LRf4Hx5tJkccwIyMLzyOK4D4IkcyJ22uoSHz6BCJBoYoE2ao4e14TV65JQA8MrEo8 FrGcCn0IekhhiktciK25KcG8qGKqYwtMuThqiDEUOQLIP3d+8A2inAkKKFQ8SmEqUkIuo5EgOGY5 hx+RtjAWaSMnLuEt72ZBnnUw5P1b076nt0HETw9L2oWmDTV+d0ANcokXRNyTMue/5JFdE3pm0E5m 9LIqciMXuRHUKfAZoMnggl8Jy4h+W64oBGy8zgmkVU9L4esMFMvh5Shhw2tRFpdOfQlqFzOTzrEv 7cOV9BYeJDmbHq3hPcs6rtWNMq9vPCw9Rgx+eE10dogm/38Mci1JjgT/iZoqbtHZPwX1cPdYLgQA wj8+Ofm0cSw5xMv73I5igvhXcEOIc5i0BF95tWZ3Q3mhTrccd1vg5utSMLKATmfjOGcWAKIYQ16E NvagQ3HStLMYy318XhN/Y+NCBuidOEz65auL0OlygtPihOjdWEzawquL0Y5jFDdOb2NOitX77lni SSbsjvraGDpiPspe185hl9Vo1FtQTO42umUrR2o4Q5j4m36W5hl75re2Eu6o7crqUJO0ioYwTmoW FplSAZ8kVIzI45QKQlXkD957lSNYC/x5W4C1wJDqywVMoAOOwVenDqVWsCgQthH161kCzttiYBfG JEflexeYP/I5PHKMe8lI+aW0hUroSmmDhm1dmTAjwBhNGaKz1Ec0vruZEsZgMO2BdgbUou50Zeuw GLo3LTIeHrSSdmePa0FUUq3uSX42CAkFOeahr9QyWZIVkaNFTpLmFfiKBXu8gjmIE+eLK4S5S4L8 fWmOYtXIdD3GZ3SF0kCCq8NwiAkuoC7iTMmqaDXbnXb3+GMbZlkicex78R8LUv78GtsFc5AEV1wr 8tA6yuPx9CFl+K3Ki+omjnVvZVlY+71gayKbzrPdyV8AAAD//wMAUEsDBBQABgAIAAAAIQCYsZob TgIAAAoFAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAJxUTY/aMBC9V+p/sHJqD8HQpWyFjCmCrjiUJRJh9+zGE2I1sSPbsEt/fScJAdJFldqc 5uNlxvP8xmz6WuTkANYpoyfBoNcPCOjESKV3k2AbP4RfAuK80FLkRsMkOIILpvz9OxZZU4L1ChzB EtpNgsz7ckypSzIohOthWmMmNbYQHl27oyZNVQILk+wL0J5+6vdHFF49aAkyLM8Fg6bi+OD/t6g0 SXU+9xQfSzwwZ7HxIo9VAfx+xOjFY8/GSsfvhgNGG5PNyjJXifBICF+pxBpnUk9WIlHaG5eRyLyA jQx6jF5jkRFwOFb950M9NV/r0CUWQJNNZl7Ih+H47iOjN4AsElbsrCgzx4f3CLm4bJMrCY5/ZvRk sUfjMdBntDHYUkkJ+pTFcMdnq9U8V2WNb022SUQOc6SIpyJ3gKXPAbYEUV1/JJR1nB38+ACJN5Y4 9QsFMAzID+GgInYSHIRVQnskuII1Tm3npfOWx6gErI25xq/Na9i1rYYcLwGxaPwV2NSqpyWx8jm4 f2iBLN5qUQWbMbF3l4CmxTrFK/E3+Bhd81EfrWGjOeW6Vjx5Q8SZkmgekdneZyick+jICnxmZGeo M3xdVrq8nXvOjmTvgESzx9n0mpLz399mUWhw2UPsSreL6Cao+j2srlgSlLc1Ave507DD1R/szE1R Cn3kIsfH4esRdkpXm89om2Dflf7ptmVsFsJDq75ukG0yYUHiO9HmLwG2ROHZvCoyz4TegWwxbxPV Kj81TxsfDHt9/OqVbWPVJraPGP8NAAD//wMAUEsBAi0AFAAGAAgAAAAhAKYRNhEfAgAA1RAAABMA AAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAo+yCJg0B AADiAgAACwAAAAAAAAAAAAAAAABYBAAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAY1wjtMEA AAA3AQAAIAAAAAAAAAAAAAAAAACWBwAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEueG1sLnJlbHNQ SwECLQAUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAAAAAAAAAAAAAACVCAAAcHB0L3NsaWRlcy9f cmVscy9zbGlkZTIueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAAAAAAAA AAAAAACSCQAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTQueG1sLnJlbHNQSwECLQAUAAYACAAAACEA W3e2SG4BAAC+BwAAHwAAAAAAAAAAAAAAAACPCgAAcHB0L19yZWxzL3ByZXNlbnRhdGlvbi54bWwu cmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAAAAAAAAAAAAAAEINAABwcHQvc2xp ZGVzL19yZWxzL3NsaWRlNS54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAA AAAAAAAAAAAAAD8OAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMy54bWwucmVsc1BLAQItABQABgAI AAAAIQAuZBi/qQIAAOINAAAUAAAAAAAAAAAAAAAAADwPAABwcHQvcHJlc2VudGF0aW9uLnhtbFBL AQItABQABgAIAAAAIQAChDPFmQQAAL4LAAAVAAAAAAAAAAAAAAAAABcSAABwcHQvc2xpZGVzL3Ns aWRlNC54bWxQSwECLQAUAAYACAAAACEAkJhHd/EDAAAcCgAAFQAAAAAAAAAAAAAAAADjFgAAcHB0 L3NsaWRlcy9zbGlkZTMueG1sUEsBAi0AFAAGAAgAAAAhALFZR6IEBAAAdAoAABUAAAAAAAAAAAAA AAAABxsAAHBwdC9zbGlkZXMvc2xpZGUyLnhtbFBLAQItABQABgAIAAAAIQAWAAkHxAMAALUJAAAV AAAAAAAAAAAAAAAAAD4fAABwcHQvc2xpZGVzL3NsaWRlMS54bWxQSwECLQAUAAYACAAAACEA6nB8 +cIDAAA3CgAAFQAAAAAAAAAAAAAAAAA1IwAAcHB0L3NsaWRlcy9zbGlkZTUueG1sUEsBAi0AFAAG AAgAAAAhANXRkvG+AAAANwEAAC0AAAAAAAAAAAAAAAAAKicAAHBwdC9zbGlkZUxheW91dHMvX3Jl bHMvc2xpZGVMYXlvdXQxMS54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAA AAAAAAAAAAAAADMoAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NC54bWwucmVs c1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAADspAABwcHQvc2xpZGVM YXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0My54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAA ADcBAAAsAAAAAAAAAAAAAAAAAEMqAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0 Ni54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAEsrAABw cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NS54bWwucmVsc1BLAQItABQABgAIAAAA IQDV0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAFMsAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3Ns aWRlTGF5b3V0MS54bWwucmVsc1BLAQItABQABgAIAAAAIQBkr8KC8wcAAFguAAAhAAAAAAAAAAAA AAAAAFstAABwcHQvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWxQSwECLQAUAAYACAAAACEA S5R3NAoEAAAVDAAAIgAAAAAAAAAAAAAAAACNNQAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91 dDExLnhtbFBLAQItABQABgAIAAAAIQA0zbnOHwEAAMcHAAAsAAAAAAAAAAAAAAAAANc5AABwcHQv c2xpZGVNYXN0ZXJzL19yZWxzL3NsaWRlTWFzdGVyMS54bWwucmVsc1BLAQItABQABgAIAAAAIQDV 0ZLxvgAAADcBAAAsAAAAAAAAAAAAAAAAAEA7AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRl TGF5b3V0Mi54bWwucmVsc1BLAQItABQABgAIAAAAIQBONxzOxAMAADULAAAiAAAAAAAAAAAAAAAA AEg8AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTAueG1sUEsBAi0AFAAGAAgAAAAhAFBs tlr7BAAAzREAACEAAAAAAAAAAAAAAAAATEAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ5 LnhtbFBLAQItABQABgAIAAAAIQDueDWnlQQAAKEQAAAhAAAAAAAAAAAAAAAAAIZFAABwcHQvc2xp ZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAA AAAAAAAAAAAAAABaSgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDcueG1sLnJl bHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAABiSwAAcHB0L3NsaWRl TGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDgueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4A AAA3AQAALAAAAAAAAAAAAAAAAABqTAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91 dDkueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALQAAAAAAAAAAAAAAAAByTQAA cHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEwLnhtbC5yZWxzUEsBAi0AFAAGAAgA AAAhAMQfGQ+rAwAA/goAACEAAAAAAAAAAAAAAAAAe04AAHBwdC9zbGlkZUxheW91dHMvc2xpZGVM YXlvdXQyLnhtbFBLAQItABQABgAIAAAAIQCXtw1G4gQAAPUQAAAhAAAAAAAAAAAAAAAAAGVSAABw cHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0My54bWxQSwECLQAUAAYACAAAACEAPpdWKnQEAACP EQAAIQAAAAAAAAAAAAAAAACGVwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDQueG1sUEsB Ai0AFAAGAAgAAAAhAAhZPJNKBQAAHRIAACEAAAAAAAAAAAAAAAAAOVwAAHBwdC9zbGlkZUxheW91 dHMvc2xpZGVMYXlvdXQ4LnhtbFBLAQItABQABgAIAAAAIQBUq/QC+QIAAB0HAAAhAAAAAAAAAAAA AAAAAMJhAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ny54bWxQSwECLQAUAAYACAAAACEA SGiGOzoDAABiCAAAIQAAAAAAAAAAAAAAAAD6ZAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91 dDYueG1sUEsBAi0AFAAGAAgAAAAhAO1VcJ3PBQAARBsAACEAAAAAAAAAAAAAAAAAc2gAAHBwdC9z bGlkZUxheW91dHMvc2xpZGVMYXlvdXQ1LnhtbFBLAQItABQABgAIAAAAIQCTqn2YuwAAACQBAAAw AAAAAAAAAAAAAAAAAIFuAABwcHQvaGFuZG91dE1hc3RlcnMvX3JlbHMvaGFuZG91dE1hc3RlcjEu eG1sLnJlbHNQSwECLQAUAAYACAAAACEAJ5L2tyIEAABTDQAAJQAAAAAAAAAAAAAAAACKbwAAcHB0 L2hhbmRvdXRNYXN0ZXJzL2hhbmRvdXRNYXN0ZXIxLnhtbFBLAQItABQABgAIAAAAIQAKGrkrYgYA AGUdAAAhAAAAAAAAAAAAAAAAAO9zAABwcHQvbm90ZXNNYXN0ZXJzL25vdGVzTWFzdGVyMS54bWxQ SwECLQAUAAYACAAAACEAkwptdRMHAADnHQAAFAAAAAAAAAAAAAAAAACQegAAcHB0L3RoZW1lL3Ro ZW1lMS54bWxQSwECLQAUAAYACAAAACEAtM9YGbsAAAAkAQAALAAAAAAAAAAAAAAAAADVgQAAcHB0 L25vdGVzTWFzdGVycy9fcmVscy9ub3Rlc01hc3RlcjEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA kwptdRMHAADnHQAAFAAAAAAAAAAAAAAAAADaggAAcHB0L3RoZW1lL3RoZW1lMy54bWxQSwECLQAU AAYACAAAACEAkwptdRMHAADnHQAAFAAAAAAAAAAAAAAAAAAfigAAcHB0L3RoZW1lL3RoZW1lMi54 bWxQSwECLQAKAAAAAAAAACEAz+6hq2EkAABhJAAAFwAAAAAAAAAAAAAAAABkkQAAZG9jUHJvcHMv dGh1bWJuYWlsLmpwZWdQSwECLQAUAAYACAAAACEAXJxHFE4BAACJAgAAEQAAAAAAAAAAAAAAAAD6 tQAAcHB0L3ByZXNQcm9wcy54bWxQSwECLQAUAAYACAAAACEAQfvz5J8BAABjAwAAEQAAAAAAAAAA AAAAAAB3twAAcHB0L3ZpZXdQcm9wcy54bWxQSwECLQAUAAYACAAAACEA2P2Nj6wAAAC2AAAAEwAA AAAAAAAAAAAAAABFuQAAcHB0L3RhYmxlU3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQDAmOAeawEA AKsCAAARAAAAAAAAAAAAAAAAACK6AABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQC+ oc097wMAALkkAAAoAAAAAAAAAAAAAAAAAMS8AABwcHQvcHJpbnRlclNldHRpbmdzL3ByaW50ZXJT ZXR0aW5nczEuYmluUEsBAi0AFAAGAAgAAAAhAJixmhtOAgAACgUAABAAAAAAAAAAAAAAAAAA+cAA AGRvY1Byb3BzL2FwcC54bWxQSwUGAAAAADQANADFDwAAfcQAAAAA --Apple-Mail=_4F89AB3A-B064-4727-B5F2-54754D37218E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

--Apple-Mail=_4F89AB3A-B064-4727-B5F2-54754D37218E-- --Apple-Mail=_5353E846-2451-4131-B362-3AF5F2FFF4E9-- From alper.yegin@yegin.org Wed Oct 17 06:22:40 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4D921F87CA for ; Wed, 17 Oct 2012 06:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, 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 s7XKaPFJ0WZI for ; Wed, 17 Oct 2012 06:22:39 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id A168521F87B0 for ; Wed, 17 Oct 2012 06:22:39 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M2btd-1TfBY948aD-00sCTg; Wed, 17 Oct 2012 09:22:38 -0400 From: Alper Yegin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Oct 2012 16:22:22 +0300 Message-Id: To: pcp@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:Rr+lTjZU7wKK8dmXwEoH3u0wTT+XgVT5vP+Mx4faIFu nw0aDExTS79A2BA7X6GqpKugnzAvzmsI0iGgwhQiJ/vV/FE1cW FAb0Mu0VkNvX+4qbU39pG3mziKxhrYP+yXzMy4CtAGmwvbmtKk V9DIsczVVVBbvy8QMxlhNBCjxeOv4QL91NlVg+AaypemYxHekC lAPuv7Mi+cFC8s62hRhmv3vZOmvyZjxJ1FY4O7j1F5ScAfTEbf Psp2qtUs6mvsEVUnK2zoQmaF4I4pzllX0fcqEnv5s+RqC0twrB fQLc1ZRY3XXycnvPuJGiB5N097VRL07qrSRsi55Wk4o5yFqhIh NiEyqm+jJbO9Q27b6SP6moMeWsoME1K4c6vSYbjfvwJyA4dviL kc8V4oW5e87rQ== Subject: [pcp] Margaret's PPT 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, 17 Oct 2012 13:22:40 -0000 Folks, Margaret's PPT on the interim web is out-of date. It's from last meeting = and not reflecting the latest updates. So, I'm not sure if it'll be used in today's meeting. Nevertheless, let = me share my comments on it. - Decision tree starts with an "Architectural Model Discussion". IMO, = the starting and even determining point is whether we "re-use an = existing protocol, or re-invent it".=20 - Loosely coupled authentication and authorization They cannot be decoupled. Authentication is done for authorization. The authorized service, and the crypto keys used during that = authorization, shall have the same lifetime. This is how it is in EAP = and AAA-based systems. - Need for re-authentication If the authorized lifetime expires, the authorized service (mappings) = needs to expire as well. They are bound to each other.=20 - Asking if a client needs to remain reachable in order to defend/retain = its mapping. It's a PCP design and policy question. Whatever it's, PANA can support that. PANA-Ping is not a mandatory-to-use feature. - "EAP-PCP has no unsolicited messages that require a response" Not true for any EAP lower layer (EAP-o-PCP being one).=20 EAP is network driven, requests are sent from the network, and they = expect a response. - "Mappings survive key expiration" They shall not. Mapping lifetime and key lifetime are dictated by the = AAA server and the same. This is how it's in EAP and AAA unless you want = to do some unusual thing.=20 Possession of keys by the PCP client is the proof of authorization of = the PCP client.=20 - "Simplified PANA-link mechanism" Yes, ~20 lines of PANA-Ping and IP Reconfig is omitted in EAP-o-PCP. = Negligible amount of savings. - Bit overloading with port-sharing PANA. Not sure why it's called "overloading". To the PANA implementation, that one bit indicates the protocol is = executed over PCP port. To the PCP implementation (or a piece of demux code handling the PCP = port) , that one bit indicates the incoming packet is not PCP, it's = something else running over PCP port. With the new discovery solution we make sure PCP server does not find = itself having to process a request with unsupported version. Cheers, Alper =20= From margaretw42@gmail.com Wed Oct 17 06:51: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 715F621F8735 for ; Wed, 17 Oct 2012 06:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 YxEizwjbAjcB for ; Wed, 17 Oct 2012 06:51:13 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9005621F853B for ; Wed, 17 Oct 2012 06:51:13 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j40so467432qab.10 for ; Wed, 17 Oct 2012 06:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Gnuj2cBbWpSf8hexHaTiAqVpVAApOTi8CZJNes0Y0wE=; b=RsDgNLTIG8m96USZgg7EVOMdWieA69uU6jx0i6n+AWeIhnetOmtMwe8vDFBa+D0tB1 VpuYa5Tw04KRR2rMOHVl8b643O5VCBhwRetMPQOIL10/YAF0pXO/50iVwBdlqpKbBAj+ 6XGWkanYaSorOb53/2dYd5ms1ewizOKDVP/mmRsL6xDN2Vvzcu6JFzctnxFMjfkWuIlt Vq9MUSy+T4HRzQZCIxCmjv/nB4Z3BC1stdqOopORKBjleT3AWDzDdSkcwLg6iPFGjAA1 82cA1if/3gl22rRRokAXTLdbkD5GzecVDXCRFJJZTyP+VdWgBmIlSzsA8N/0oUKeI0EZ Fl6A== Received: by 10.49.104.9 with SMTP id ga9mr43582140qeb.39.1350481872985; Wed, 17 Oct 2012 06:51:12 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id g18sm21455367qan.1.2012.10.17.06.51.09 (version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 06:51:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: Date: Wed, 17 Oct 2012 09:51:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9E69EEA1-221C-4670-A0D8-DEC7AA423A58@lilacglade.org> References: To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Margaret's PPT 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, 17 Oct 2012 13:51:14 -0000 Hi Alper, On Oct 17, 2012, at 9:22 AM, Alper Yegin wrote: > Margaret's PPT on the interim web is out-of date. It's from last = meeting and not reflecting the latest updates. > So, I'm not sure if it'll be used in today's meeting. Nevertheless, = let me share my comments on it. I have sent any updated version to the chairs, and I think it will be = posted soon. However, it is very similar, as discussions have not = progressed much since the last call. >=20 > - Decision tree starts with an "Architectural Model Discussion". IMO, = the starting and even determining point is whether we "re-use an = existing protocol, or re-invent it".=20 You and Yoshi covered this topic in your slides, which you presented at = length in the last meeting. I don't think it would be useful to present = them again. > - Loosely coupled authentication and authorization >=20 > They cannot be decoupled. > Authentication is done for authorization. > The authorized service, and the crypto keys used during that = authorization, shall have the same lifetime. This is how it is in EAP = and AAA-based systems. > - Need for re-authentication >=20 > If the authorized lifetime expires, the authorized service (mappings) = needs to expire as well. > They are bound to each other.=20 These are your opinions. Other opinions were expressed during = discussions on the mailing list. I don't think we can know what the WG = thinks in this area without asking... > - Asking if a client needs to remain reachable in order to = defend/retain its mapping. >=20 > It's a PCP design and policy question. Exactly. That is why I am raising the question. > Whatever it's, PANA can support that. > PANA-Ping is not a mandatory-to-use feature. Correct. We can, if we choose, define a subset of PANA that removes the = need for nodes to remain reachable to defend their mapping. This would = involve dropping support for PANA "liveness checks" (which is what I = think you mean by "PANA-Ping"), and removing server-initiated = reauthentication. > - "EAP-PCP has no unsolicited messages that require a response" >=20 > Not true for any EAP lower layer (EAP-o-PCP being one).=20 > EAP is network driven, requests are sent from the network, and they = expect a response. Have you read the GSS-EAP draft that Sam Hartman referenced in his = e-mail? It is not true that all EAP lower layers need to support = server-initiated re-authentication. PANA does, but PCP could define an = EAP lower layer that doesn't, like GSS-EAP. This is something the WG = needs to discuss and consider. > - "Mappings survive key expiration" >=20 > They shall not. Mapping lifetime and key lifetime are dictated by the = AAA server and the same. This is how it's in EAP and AAA unless you want = to do some unusual thing.=20 > Possession of keys by the PCP client is the proof of authorization of = the PCP client.=20 Again, this is your opinion. We do not yet know if the WG agrees with = you. >=20 > - "Simplified PANA-link mechanism" >=20 > Yes, ~20 lines of PANA-Ping and IP Reconfig is omitted in EAP-o-PCP. = Negligible amount of savings. The entire Enforcement Point concept, session termination, = server-initiated re-authentication, and details specific to controlling = network access are also omitted in the PCP-Specific approach. If we go = with a PANA-based approach, we will need to decide what to do about each = of these things, and write a detailed description of what portions of = PANA are and are not used for PCP authentication. >=20 > - Bit overloading with port-sharing PANA. >=20 > Not sure why it's called "overloading". > To the PANA implementation, that one bit indicates the protocol is = executed over PCP port. > To the PCP implementation (or a piece of demux code handling the PCP = port) , that one bit indicates the incoming packet is not PCP, it's = something else running over PCP port. When a bit is used for more than one purpose, that is called = "overloading". In this case, the bit is part of the PCP version number, = and is also used for demultiplexing. That is what "overloading" = means... > With the new discovery solution we make sure PCP server does not find = itself having to process a request with unsupported version. This is possible, yes, at some cost in terms of complexity. Assuming = the WG reaches consensus to proceed with a PANA-based approach, the WG = needs to compare the complexity of a discovery solution against the = overhead of encapsulation, in order to make an informed choice between = those two approaches. Margaret From dthaler@microsoft.com Wed Oct 17 06:51:55 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6593C21F85F4 for ; Wed, 17 Oct 2012 06:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.363 X-Spam-Level: X-Spam-Status: No, score=-103.363 tagged_above=-999 required=5 tests=[AWL=-0.764, BAYES_00=-2.599, 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 l544lDqWr5-q for ; Wed, 17 Oct 2012 06:51:54 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.26]) by ietfa.amsl.com (Postfix) with ESMTP id A4AA521F853B for ; Wed, 17 Oct 2012 06:51:54 -0700 (PDT) Received: from BL2FFO11FD014.protection.gbl (10.173.161.201) by BL2FFO11HUB005.protection.gbl (10.173.160.225) with Microsoft SMTP Server (TLS) id 15.0.545.8; Wed, 17 Oct 2012 13:52:50 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD014.mail.protection.outlook.com (10.173.160.222) with Microsoft SMTP Server (TLS) id 15.0.516.0 via Frontend Transport; Wed, 17 Oct 2012 13:52:49 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 17 Oct 2012 13:51:21 +0000 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.111]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0318.003; Wed, 17 Oct 2012 06:51:21 -0700 From: Dave Thaler To: Alper Yegin , "pcp@ietf.org" Thread-Topic: [pcp] Margaret's PPT Thread-Index: AQHNrGp/s9YUOD7NhEeuJDj14+rhp5e9hBQr Date: Wed, 17 Oct 2012 13:51:20 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B86515C@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(51856001)(47776002)(20776001)(48376001)(47976001)(3846001)(46102001)(74502001)(42186003)(33656001)(47446002)(74662001)(4196001)(5343655001)(44976002)(16406001)(4396001)(31966008)(47736001)(1076001)(50466001)(50986001)(8716001)(2666001)(16696001)(16826001)(49866001)(316001)(3746001)(3556001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0637FCE711 Subject: Re: [pcp] Margaret's PPT 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, 17 Oct 2012 13:51:55 -0000 She sent an updated copy which I just uploaded. ________________________________________ From: pcp-bounces@ietf.org [pcp-bounces@ietf.org] on behalf of Alper Yegin = [alper.yegin@yegin.org] Sent: Wednesday, October 17, 2012 6:22 AM To: pcp@ietf.org Subject: [pcp] Margaret's PPT Folks, Margaret's PPT on the interim web is out-of date. It's from last meeting an= d not reflecting the latest updates. So, I'm not sure if it'll be used in today's meeting. Nevertheless, let me = share my comments on it. - Decision tree starts with an "Architectural Model Discussion". IMO, the s= tarting and even determining point is whether we "re-use an existing protoc= ol, or re-invent it". - Loosely coupled authentication and authorization They cannot be decoupled. Authentication is done for authorization. The authorized service, and the crypto keys used during that authorization,= shall have the same lifetime. This is how it is in EAP and AAA-based syste= ms. - Need for re-authentication If the authorized lifetime expires, the authorized service (mappings) needs= to expire as well. They are bound to each other. - Asking if a client needs to remain reachable in order to defend/retain it= s mapping. It's a PCP design and policy question. Whatever it's, PANA can support that. PANA-Ping is not a mandatory-to-use feature. - "EAP-PCP has no unsolicited messages that require a response" Not true for any EAP lower layer (EAP-o-PCP being one). EAP is network driven, requests are sent from the network, and they expect = a response. - "Mappings survive key expiration" They shall not. Mapping lifetime and key lifetime are dictated by the AAA s= erver and the same. This is how it's in EAP and AAA unless you want to do s= ome unusual thing. Possession of keys by the PCP client is the proof of authorization of the P= CP client. - "Simplified PANA-link mechanism" Yes, ~20 lines of PANA-Ping and IP Reconfig is omitted in EAP-o-PCP. Neglig= ible amount of savings. - Bit overloading with port-sharing PANA. Not sure why it's called "overloading". To the PANA implementation, that one bit indicates the protocol is executed= over PCP port. To the PCP implementation (or a piece of demux code handling the PCP port) = , that one bit indicates the incoming packet is not PCP, it's something els= e running over PCP port. With the new discovery solution we make sure PCP server does not find itsel= f having to process a request with unsupported version. Cheers, Alper _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp= From adurand@juniper.net Wed Oct 17 07:07:43 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9615321F8794 for ; Wed, 17 Oct 2012 07:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.466 X-Spam-Level: X-Spam-Status: No, score=-103.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, 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 8qkro0f3VPyS for ; Wed, 17 Oct 2012 07:07:42 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 733C321F84EA for ; Wed, 17 Oct 2012 07:07:42 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUH67rglgsldH1zIXpJrg81W9QGTcdDgQ@postini.com; Wed, 17 Oct 2012 07:07:42 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 17 Oct 2012 07:05:49 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 17 Oct 2012 07:05:48 -0700 Received: from db3outboundpool.messaging.microsoft.com (213.199.154.141) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 17 Oct 2012 07:08:13 -0700 Received: from mail14-db3-R.bigfish.com (10.3.81.244) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 17 Oct 2012 14:05:46 +0000 Received: from mail14-db3 (localhost [127.0.0.1]) by mail14-db3-R.bigfish.com (Postfix) with ESMTP id 932ABA0175 for ; Wed, 17 Oct 2012 14:05:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -19 X-BigFish: PS-19(zz9371I617Id772hc857hzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839hd25he5bhf0ah107ah1288h12a5h12bdh137ah1441hbe3k1155h) Received: from mail14-db3 (localhost.localdomain [127.0.0.1]) by mail14-db3 (MessageSwitch) id 13504827449339_27444; Wed, 17 Oct 2012 14:05:44 +0000 (UTC) Received: from DB3EHSMHS014.bigfish.com (unknown [10.3.81.247]) by mail14-db3.bigfish.com (Postfix) with ESMTP id EA5D52A0060 for ; Wed, 17 Oct 2012 14:05:43 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by DB3EHSMHS014.bigfish.com (10.3.87.114) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 17 Oct 2012 14:05:41 +0000 Received: from BL2PRD0510MB386.namprd05.prod.outlook.com ([169.254.11.81]) by BL2PRD0510HT004.namprd05.prod.outlook.com ([10.255.100.39]) with mapi id 14.16.0224.004; Wed, 17 Oct 2012 14:05:41 +0000 From: Alain Durand To: "pcp@ietf.org" Thread-Topic: Interim meeting starting now Thread-Index: Ac2scH3nulFT8GK/RgKOzoTk2czC8w== Date: Wed, 17 Oct 2012 14:05:41 +0000 Message-ID: <16D4E047-91DB-46A6-8303-98D2839773AA@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.228.209.202] Content-Type: multipart/alternative; boundary="_000_16D4E04791DB46A6830398D2839773AAjunipernet_" 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] Interim meeting starting now 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, 17 Oct 2012 14:07:43 -0000 --_000_16D4E04791DB46A6830398D2839773AAjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2Ugbm93IGhhdmUgb2ZmaWNpYWwgSUVURiBXZWJFeCBzdXBwb3J0LiAgIENvbm5lY3Rpb24gaW5m b3JtYXRpb24gaXMgYmVsb3cuDQoNCi1EYXZlDQoNClRvcGljOiBQQ1AgSW50ZXJpbSBNZWV0aW5n DQpEYXRlOiBXZWRuZXNkYXksIE9jdG9iZXIgMTcsIDIwMTINClRpbWU6IDc6MDAgYW0sIFBhY2lm aWMgRGF5bGlnaHQgVGltZTx4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzOi8vMT4gKFNhbiBGcmFuY2lz Y28sIEdNVC0wNzowMCkNCk1lZXRpbmcgTnVtYmVyOiA2NDAgODI2IDIyMjx0ZWw6NjQwJTIwODI2 JTIwMjIyPg0KTWVldGluZyBQYXNzd29yZDogMTIzNDU2Nzg8dGVsOjEyMzQ1Njc4Pg0KDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRv IGpvaW4gdGhlIG9ubGluZSBtZWV0aW5nIChOb3cgZnJvbSBtb2JpbGUgZGV2aWNlcyEpDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoxLiBH byB0byBodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/RUQ9MTYyNjEwNjU3JlVJRD0x MjgxMTkyMDM3JlBXPU5OakUxTldSbU9UVTAmUlQ9TWlNMA0KMi4gSWYgcmVxdWVzdGVkLCBlbnRl ciB5b3VyIG5hbWUgYW5kIGVtYWlsIGFkZHJlc3MuDQozLiBJZiBhIHBhc3N3b3JkIGlzIHJlcXVp cmVkLCBlbnRlciB0aGUgbWVldGluZyBwYXNzd29yZDogMTIzNDU2Nzg8dGVsOjEyMzQ1Njc4Pg0K NC4gQ2xpY2sgIkpvaW4iLg0KDQpUbyB2aWV3IGluIG90aGVyIHRpbWUgem9uZXMgb3IgbGFuZ3Vh Z2VzLCBwbGVhc2UgY2xpY2sgdGhlIGxpbms6DQpodHRwczovL2lldGYud2ViZXguY29tL2lldGYv ai5waHA/RUQ9MTYyNjEwNjU3JlVJRD0xMjgxMTkyMDM3JlBXPU5OakUxTldSbU9UVTAmT1JUPU1p TTANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KVG8gam9pbiB0aGUgYXVkaW8gY29uZmVyZW5jZSBvbmx5DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDYWxsLWluIHRvbGwgbnVt YmVyIChVUy9DYW5hZGEpOiAxLTY1MC00NzktMzIwODx0ZWw6MS02NTAtNDc5LTMyMDg+DQoNCkFj Y2VzcyBjb2RlOjY0MCA4MjYgMjIyDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkZvciBhc3Npc3RhbmNlDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoxLiBHbyB0byBodHRwczov L2lldGYud2ViZXguY29tL2lldGYvbWMNCjIuIE9uIHRoZSBsZWZ0IG5hdmlnYXRpb24gYmFyLCBj bGljayAiU3VwcG9ydCIuDQoNCllvdSBjYW4gY29udGFjdCBtZSBhdDoNCnBjcC1jaGFpcnNAdG9v bHMuaWV0Zi5vcmc8bWFpbHRvOnBjcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQoNCg0KVG8gdXBk YXRlIHRoaXMgbWVldGluZyB0byB5b3VyIGNhbGVuZGFyIHByb2dyYW0gKGZvciBleGFtcGxlIE1p Y3Jvc29mdCBPdXRsb29rKSwgY2xpY2sgdGhpcyBsaW5rOg0KaHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP0VEPTE2MjYxMDY1NyZVSUQ9MTI4MTE5MjAzNyZJQ1M9TVJTMSZMRD0xJlJE PTImU1Q9MSZTSEEyPUFBQUFBa1R5Y1JaMmEwTU9PV3huVmNqcW4wZjlzRlRTckdLZkVNUVUtcUJh YWh3WCZSVD1NaU0wDQoNCg0KV2ViRXggd2lsbCBhdXRvbWF0aWNhbGx5IHNldHVwIE1lZXRpbmcg TWFuYWdlciBmb3IgV2luZG93cyB0aGUgZmlyc3QgdGltZSB5b3Ugam9pbiBhIG1lZXRpbmcuIFRv IHNhdmUgdGltZSwgeW91IGNhbiBzZXR1cCBwcmlvciB0byB0aGUgbWVldGluZyBieSBjbGlja2lu ZyB0aGlzIGxpbms6DQpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWVldGluZ2NlbnRlci9t Y3NldHVwLnBocA0KDQoNCg0KDQpTaWduIHVwIGZvciBhIGZyZWUgdHJpYWwgb2YgV2ViRXgNCmh0 dHA6Ly93d3cud2ViZXguY29tL2dvL21jZW1mcmVldHJpYWwNCg0KaHR0cDovL3d3dy53ZWJleC5j b208aHR0cDovL3d3dy53ZWJleC5jb20vPg0KDQpDQ1A6KzE2NTA0NzkzMjA4eDY0MDgyNjIyMiMN Cg0KSU1QT1JUQU5UIE5PVElDRTogVGhpcyBXZWJFeCBzZXJ2aWNlIGluY2x1ZGVzIGEgZmVhdHVy ZSB0aGF0IGFsbG93cyBhdWRpbyBhbmQgYW55IGRvY3VtZW50cyBhbmQgb3RoZXIgbWF0ZXJpYWxz IGV4Y2hhbmdlZCBvciB2aWV3ZWQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLiBC eSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNo IHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byB0aGUgcmVjb3JkaW5nLCBkaXNj dXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgbWVldGluZyBob3N0IHByaW9yIHRvIHRoZSBzdGFy dCBvZiB0aGUgcmVjb3JkaW5nIG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLiBQbGVhc2Ugbm90 ZSB0aGF0IGFueSBzdWNoIHJlY29yZGluZ3MgbWF5IGJlIHN1YmplY3QgdG8gZGlzY292ZXJ5IGlu IHRoZSBldmVudCBvZiBsaXRpZ2F0aW9uLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnBjcCBtYWlsaW5nIGxpc3QNCnBjcEBpZXRmLm9yZzxtYWlsdG86 cGNwQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY3AN Cg0KU2VudCBmcm9tIG15IGlQYWQNCg== --_000_16D4E04791DB46A6830398D2839773AAjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24x OyAiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgIj48c3BhbiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyBiYWNrZ3Jv dW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+V2Ugbm93Jm5ic3A7aGF2ZSBvZmZp Y2lhbCBJRVRGIFdlYkV4IHN1cHBvcnQuJm5ic3A7Jm5ic3A7IENvbm5lY3Rpb24gaW5mb3JtYXRp b24gaXMgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgIj48c3BhbiBzdHlsZT0iLXdlYmtpdC10 ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAy NTUsIDApOyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7ICI+PHNwYW4gc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXpl LWFkanVzdDogYXV0bzsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsi Pi1EYXZlPGJyPg0KPGJyPg0KVG9waWM6IFBDUCBJbnRlcmltIE1lZXRpbmcmbmJzcDs8YnI+DQpE YXRlOiBXZWRuZXNkYXksIE9jdG9iZXIgMTcsIDIwMTImbmJzcDs8YnI+DQpUaW1lOiZuYnNwOzxh IGhyZWY9IngtYXBwbGUtZGF0YS1kZXRlY3RvcnM6Ly8xIiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3Jz PSJ0cnVlIiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXR5cGU9ImNhbGVuZGFyLWV2ZW50IiB4LWFw cGxlLWRhdGEtZGV0ZWN0b3JzLXJlc3VsdD0iMSI+NzowMCBhbSwgUGFjaWZpYyBEYXlsaWdodCBU aW1lPC9hPiZuYnNwOyhTYW4gRnJhbmNpc2NvLCBHTVQtMDc6MDApJm5ic3A7PGJyPg0KTWVldGlu ZyBOdW1iZXI6Jm5ic3A7PGEgaHJlZj0idGVsOjY0MCUyMDgyNiUyMDIyMiIgeC1hcHBsZS1kYXRh LWRldGVjdG9ycz0idHJ1ZSIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycy10eXBlPSJ0ZWxlcGhvbmUi IHgtYXBwbGUtZGF0YS1kZXRlY3RvcnMtcmVzdWx0PSIyIj42NDAgODI2IDIyMjwvYT4mbmJzcDs8 YnI+DQpNZWV0aW5nIFBhc3N3b3JkOiZuYnNwOzxhIGhyZWY9InRlbDoxMjM0NTY3OCIgeC1hcHBs ZS1kYXRhLWRldGVjdG9ycz0idHJ1ZSIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycy10eXBlPSJ0ZWxl cGhvbmUiIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnMtcmVzdWx0PSIzIj4xMjM0NTY3ODwvYT4mbmJz cDs8YnI+DQo8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tJm5ic3A7PGJyPg0KVG8gam9pbiB0aGUgb25saW5lIG1lZXRpbmcg KE5vdyBmcm9tIG1vYmlsZSBkZXZpY2VzISkmbmJzcDs8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJm5ic3A7PGJyPg0KMS4gR28gdG8m bmJzcDs8YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/RUQ9MTYyNjEw NjU3JmFtcDtVSUQ9MTI4MTE5MjAzNyZhbXA7UFc9Tk5qRTFOV1JtT1RVMCZhbXA7UlQ9TWlNMCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9FRD0xNjI2 MTA2NTcmYW1wO1VJRD0xMjgxMTkyMDM3JmFtcDtQVz1OTmpFMU5XUm1PVFUwJmFtcDtSVD1NaU0w PC9hPiZuYnNwOzxicj4NCjIuIElmIHJlcXVlc3RlZCwgZW50ZXIgeW91ciBuYW1lIGFuZCBlbWFp bCBhZGRyZXNzLiZuYnNwOzxicj4NCjMuIElmIGEgcGFzc3dvcmQgaXMgcmVxdWlyZWQsIGVudGVy IHRoZSBtZWV0aW5nIHBhc3N3b3JkOiZuYnNwOzxhIGhyZWY9InRlbDoxMjM0NTY3OCIgeC1hcHBs ZS1kYXRhLWRldGVjdG9ycz0idHJ1ZSIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycy10eXBlPSJ0ZWxl cGhvbmUiIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnMtcmVzdWx0PSI1Ij4xMjM0NTY3ODwvYT4mbmJz cDs8YnI+DQo0LiBDbGljayAmcXVvdDtKb2luJnF1b3Q7LiZuYnNwOzxicj4NCjxicj4NClRvIHZp ZXcgaW4gb3RoZXIgdGltZSB6b25lcyBvciBsYW5ndWFnZXMsIHBsZWFzZSBjbGljayB0aGUgbGlu azombmJzcDs8YnI+DQo8YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/ RUQ9MTYyNjEwNjU3JmFtcDtVSUQ9MTI4MTE5MjAzNyZhbXA7UFc9Tk5qRTFOV1JtT1RVMCZhbXA7 T1JUPU1pTTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5w aHA/RUQ9MTYyNjEwNjU3JmFtcDtVSUQ9MTI4MTE5MjAzNyZhbXA7UFc9Tk5qRTFOV1JtT1RVMCZh bXA7T1JUPU1pTTA8L2E+Jm5ic3A7PGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZuYnNwOzxicj4NClRvIGpvaW4gdGhlIGF1 ZGlvIGNvbmZlcmVuY2Ugb25seSZuYnNwOzxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mbmJzcDs8YnI+DQpDYWxsLWluIHRvbGwgbnVt YmVyIChVUy9DYW5hZGEpOiZuYnNwOzxhIGhyZWY9InRlbDoxLTY1MC00NzktMzIwOCIgeC1hcHBs ZS1kYXRhLWRldGVjdG9ycz0idHJ1ZSIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycy10eXBlPSJ0ZWxl cGhvbmUiIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnMtcmVzdWx0PSI3Ij4xLTY1MC00NzktMzIwODwv YT4mbmJzcDs8YnI+DQo8YnI+DQpBY2Nlc3MgY29kZTo2NDAgODI2IDIyMiZuYnNwOzxicj4NCjxi cj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0mbmJzcDs8YnI+DQpGb3IgYXNzaXN0YW5jZSZuYnNwOzxicj4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mbmJzcDs8YnI+DQoxLiBHbyB0 byZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tYyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tYzwvYT4mbmJzcDs8YnI+DQoyLiBP biB0aGUgbGVmdCBuYXZpZ2F0aW9uIGJhciwgY2xpY2sgJnF1b3Q7U3VwcG9ydCZxdW90Oy4mbmJz cDs8YnI+DQo8YnI+DQpZb3UgY2FuIGNvbnRhY3QgbWUgYXQ6Jm5ic3A7PGJyPg0KPGEgaHJlZj0i bWFpbHRvOnBjcC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPnBjcC1jaGFpcnNAdG9vbHMuaWV0Zi5v cmc8L2E+Jm5ic3A7PGJyPg0KPGJyPg0KPGJyPg0KVG8gdXBkYXRlIHRoaXMgbWVldGluZyB0byB5 b3VyIGNhbGVuZGFyIHByb2dyYW0gKGZvciBleGFtcGxlIE1pY3Jvc29mdCBPdXRsb29rKSwgY2xp Y2sgdGhpcyBsaW5rOiZuYnNwOzxicj4NCjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20v aWV0Zi9qLnBocD9FRD0xNjI2MTA2NTcmYW1wO1VJRD0xMjgxMTkyMDM3JmFtcDtJQ1M9TVJTMSZh bXA7TEQ9MSZhbXA7UkQ9MiZhbXA7U1Q9MSZhbXA7U0hBMj1BQUFBQWtUeWNSWjJhME1PT1d4blZj anFuMGY5c0ZUU3JHS2ZFTVFVLXFCYWFod1gmYW1wO1JUPU1pTTAiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/RUQ9MTYyNjEwNjU3JmFtcDtVSUQ9MTI4 MTE5MjAzNyZhbXA7SUNTPU1SUzEmYW1wO0xEPTEmYW1wO1JEPTImYW1wO1NUPTEmYW1wO1NIQTI9 QUFBQUFrVHljUloyYTBNT09XeG5WY2pxbjBmOXNGVFNyR0tmRU1RVS1xQmFhaHdYJmFtcDtSVD1N aU0wPC9hPiZuYnNwOzxicj4NCjxicj4NCjxicj4NCldlYkV4IHdpbGwgYXV0b21hdGljYWxseSBz ZXR1cCBNZWV0aW5nIE1hbmFnZXIgZm9yIFdpbmRvd3MgdGhlIGZpcnN0IHRpbWUgeW91IGpvaW4g YSBtZWV0aW5nLiBUbyBzYXZlIHRpbWUsIHlvdSBjYW4gc2V0dXAgcHJpb3IgdG8gdGhlIG1lZXRp bmcgYnkgY2xpY2tpbmcgdGhpcyBsaW5rOiZuYnNwOzxicj4NCjxhIGhyZWY9Imh0dHBzOi8vaWV0 Zi53ZWJleC5jb20vaWV0Zi9tZWV0aW5nY2VudGVyL21jc2V0dXAucGhwIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21lZXRpbmdjZW50ZXIvbWNzZXR1cC5waHA8 L2E+Jm5ic3A7PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KU2lnbiB1cCBmb3IgYSBmcmVl IHRyaWFsIG9mIFdlYkV4Jm5ic3A7PGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20v Z28vbWNlbWZyZWV0cmlhbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cud2ViZXguY29tL2dv L21jZW1mcmVldHJpYWw8L2E+Jm5ic3A7PGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy53 ZWJleC5jb20vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy53ZWJleC5jb208L2E+Jm5ic3A7 PGJyPg0KPGJyPg0KQ0NQOiYjNDM7MTY1MDQ3OTMyMDh4NjQwODI2MjIyIyZuYnNwOzxicj4NCjxi cj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoaXMgV2ViRXggc2VydmljZSBpbmNsdWRlcyBhIGZlYXR1 cmUgdGhhdCBhbGxvd3MgYXVkaW8gYW5kIGFueSBkb2N1bWVudHMgYW5kIG90aGVyIG1hdGVyaWFs cyBleGNoYW5nZWQgb3Igdmlld2VkIGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZC4g Qnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3Vj aCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQNCiB0byB0aGUgcmVjb3JkaW5nLCBk aXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgbWVldGluZyBob3N0IHByaW9yIHRvIHRoZSBz dGFydCBvZiB0aGUgcmVjb3JkaW5nIG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLiBQbGVhc2Ug bm90ZSB0aGF0IGFueSBzdWNoIHJlY29yZGluZ3MgbWF5IGJlIHN1YmplY3QgdG8gZGlzY292ZXJ5 IGluIHRoZSBldmVudCBvZiBsaXRpZ2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHNwYW4gc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgYmFja2dyb3Vu ZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcGNwIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpwY3BAaWV0Zi5vcmciIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnM9InRydWUiIHgt YXBwbGUtZGF0YS1kZXRlY3RvcnMtdHlwZT0ibGluayIgeC1hcHBsZS1kYXRhLWRldGVjdG9ycy1y ZXN1bHQ9IjE1Ij5wY3BAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wY3AiIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnM9InRydWUi IHgtYXBwbGUtZGF0YS1kZXRlY3RvcnMtdHlwZT0ibGluayIgeC1hcHBsZS1kYXRhLWRldGVjdG9y cy1yZXN1bHQ9IjE2Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjcDwv YT48L3NwYW4+PGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXplLWFkanVz dDogYXV0bzsiPlNlbnQgZnJvbSBteSBpUGFkPC9zcGFuPjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_16D4E04791DB46A6830398D2839773AAjunipernet_-- From alper.yegin@yegin.org Wed Oct 17 23:05:03 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A14A21F85AC for ; Wed, 17 Oct 2012 23:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, 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 n0xTA75MYPSU for ; Wed, 17 Oct 2012 23:05:02 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 938C221F85F4 for ; Wed, 17 Oct 2012 23:05:02 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MgsrA-1T2mWv1M00-00M9Ui; Thu, 18 Oct 2012 02:05:00 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <6569B9B2-0B82-450A-A328-D023EFC732DA@yegin.org> Date: Thu, 18 Oct 2012 09:04:43 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <36E9DFAC-47D5-4942-937F-A88CD2AD75D0@lilacglade.org> <96744887-68C7-4F9A-813E-A5563E4356E2@gmail.com> <6569B9B2-0B82-450A-A328-D023EFC732DA@yegin.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:4AaxcZ9z2S4fchTBqH0d5FJVmnyET9OXB7tv1JMcEHx AGfKJK0yGJ1W7s/gBtKU34a36r5M0n3OQ70m2pkZ1sTmCzECUd Aa5gvl0Tx4hmoeArjD6f+JX8DFpkxPH49zstSCGl1hp1BsY8i7 dNl/8DHY6cIyrOEzeP5MuLZ3zv1JKsaF/vSJksj6TbyCkpYwu7 tJQtRqAQaUDarR3ZZEmGXyTrdp/9hxTyqmYZmjpbBV312LzQbt Otdn/px/8wORk2uhtyh2moMkU/1tFFqsVPFo9WpxPn3VKdNwVn 2M1vir9Gike/tF9CDrwmpVL5p83/OWOa6eg7Z0mwIdtP+7fwmO ol+uNPnv0ktloXI2L48f3iytzQlrBtNpS8Q3aR1WkRZio+pl3j 60VYwa+HHR5+Q== Cc: pcp@ietf.org Subject: Re: [pcp] gss-eap & client-side rexmit only 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, 18 Oct 2012 06:05:03 -0000 Sam, You claimed you can design an EAP lower layer that's always client = driven, and gave GSS-EAP as an example of how you did it. So, I had already looked at it and still don't see it how. See below for the last email I sent on this matter which went = unanswered.=20 Please take a stab at it and let's progress this discussion. On Sep 20, 2012, at 4:17 PM, Alper Yegin wrote: > So, I looked at this spec. >=20 > This, too, is server-driven. Like EAP is, unlike PCP is.=20 > Retransmission do happen, not at the EAP layer but at the EAP-lower = layer. >=20 > Yep, there's no re-auth. It's absence is confirmed! :-) >=20 > - What happens if server-side needs to re-key, extend lifetime, change = authorization, re-challenge the client?=20 > Say, the acceptor receives a RADIUS CoA with EAP-Request, what's going = to do with it? >=20 > Sorry folks, gss-eap as an EAP lower layer spec is incomplete. Whether = you recognize and accept this today, or later when you start building = complete architectures/systems with it. No worries, you can always add = it. >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 From alper.yegin@yegin.org Wed Oct 17 23:23: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 560A621F8616 for ; Wed, 17 Oct 2012 23:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, 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 sUnzhCNscCYB for ; Wed, 17 Oct 2012 23:23:13 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 7A75D21F860F for ; Wed, 17 Oct 2012 23:23:13 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MIMcx-1TKclu2K3L-004Nbf; Thu, 18 Oct 2012 02:23:12 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <9E69EEA1-221C-4670-A0D8-DEC7AA423A58@lilacglade.org> Date: Thu, 18 Oct 2012 09:22:55 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1B4F8624-DD1B-4678-9398-9ADEEB6E0104@yegin.org> References: <9E69EEA1-221C-4670-A0D8-DEC7AA423A58@lilacglade.org> To: Margaret Wasserman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:dRTSk6wp1DmRKzD3+94bYcxqxwZVqnbQQPZzJ4faNGq vkRZ8T4Mk2SGsBRCJjYbM/NTfc/KI5omcPL101Xja4J3cHx7KP DkdPXVYdBsY6GDJQxUFrxikN67PRW1KkVtYkiZ66nDKu3Dy8Lb hVUBYvM0CdUpgXVbWwi4/HMYPzR7ygNQac3PPJAXs9KZVTfMIW Viiyy4idFR7A3f9VyoZ9Emc0GfIaJEfnXlYQcKu/5ZrkCU4NQA 6R9d4lY3f78ZKGevbFHUFsACe1EyG9qJJG7dBrSdXY6l8MXfuH snJ1ikecXl3F44ZIim5sy6jywcCoOY1em9u735viP8/7uJfOFc WHD61YUkiaSrxigNn26KH801aUjqdlZDkOEFR09+LPRvLfhaxG DfySEzsWFr2Sg== Cc: pcp@ietf.org Subject: Re: [pcp] Margaret's PPT 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, 18 Oct 2012 06:23:14 -0000 Hi Margaret, >> - Decision tree starts with an "Architectural Model Discussion". IMO, = the starting and even determining point is whether we "re-use an = existing protocol, or re-invent it".=20 >=20 > You and Yoshi covered this topic in your slides, which you presented = at length in the last meeting. I don't think it would be useful to = present them again. >=20 Honestly, "architectural model discussion" is good for the PCP = authentication design, but won't be helpful for the PANA vs EAP-o-PCP = discussion. The reason is, since EAP-o-PCP is re-invention of PANA, = unsurprisingly the features will be the same. Then it'll simply boil = down to my question: re-use or re-invent.=20 >> - Loosely coupled authentication and authorization >>=20 >> They cannot be decoupled. >> Authentication is done for authorization. >> The authorized service, and the crypto keys used during that = authorization, shall have the same lifetime. This is how it is in EAP = and AAA-based systems. >> - Need for re-authentication >>=20 >> If the authorized lifetime expires, the authorized service (mappings) = needs to expire as well. >> They are bound to each other.=20 >=20 > These are your opinions. Other opinions were expressed during = discussions on the mailing list. I don't think we can know what the WG = thinks in this area without asking... >=20 >> - Asking if a client needs to remain reachable in order to = defend/retain its mapping. >>=20 >> It's a PCP design and policy question. >=20 > Exactly. That is why I am raising the question. >=20 >> Whatever it's, PANA can support that. >> PANA-Ping is not a mandatory-to-use feature. >=20 > Correct. We can, if we choose, define a subset of PANA that removes = the need for nodes to remain reachable to defend their mapping. This = would involve dropping support for PANA "liveness checks" (which is what = I think you mean by "PANA-Ping"), and removing server-initiated = reauthentication. >=20 >> - "EAP-PCP has no unsolicited messages that require a response" >>=20 >> Not true for any EAP lower layer (EAP-o-PCP being one).=20 >> EAP is network driven, requests are sent from the network, and they = expect a response. >=20 > Have you read the GSS-EAP draft that Sam Hartman referenced in his = e-mail? It is not true that all EAP lower layers need to support = server-initiated re-authentication. PANA does, but PCP could define an = EAP lower layer that doesn't, like GSS-EAP. This is something the WG = needs to discuss and consider. >=20 >> - "Mappings survive key expiration" >>=20 >> They shall not. Mapping lifetime and key lifetime are dictated by the = AAA server and the same. This is how it's in EAP and AAA unless you want = to do some unusual thing.=20 >> Possession of keys by the PCP client is the proof of authorization of = the PCP client.=20 >=20 > Again, this is your opinion. We do not yet know if the WG agrees with = you. >>=20 >> - "Simplified PANA-link mechanism" >>=20 >> Yes, ~20 lines of PANA-Ping and IP Reconfig is omitted in EAP-o-PCP. = Negligible amount of savings. >=20 > The entire Enforcement Point concept, session termination, = server-initiated re-authentication, and details specific to controlling = network access are also omitted in the PCP-Specific approach. If we go = with a PANA-based approach, we will need to decide what to do about each = of these things, and write a detailed description of what portions of = PANA are and are not used for PCP authentication. >=20 > Enforcement Point concept:=20 This is the entity that performs access control on per-packet basis.=20 This is a concept. It's not a PANA protocol entity, there's no code in = PANA implementation for this. Application of that concept to PCP is the "piece of PCP code that = verifies the auth option of the incoming PCP packet before acting on the = rest of the payload". So, one thing performs "end-point authentication" (like authenticating = joe@domain), and generates crypto keys. EAP + EAP-lower-layer does that. Those crypto keys are used with per-packet security (putting a signed = hash on each packet) to perform data-origin authentication. The things = that does this check is called Enforcement Point.=20 Again, no code, no extra in PANA. > Session termination If the client decides to sign-off, or the network decides to terminate the session (e.g, when the NAS = receives a AAA Disconnect message), then you need an explicit = termination message. This is needed. > Server-initiated re-auth (will have a separate thread for that..) PANA-Ping and IP Reconfig we agreed.=20 What else?? >>=20 >> - Bit overloading with port-sharing PANA. >>=20 >> Not sure why it's called "overloading". >> To the PANA implementation, that one bit indicates the protocol is = executed over PCP port. >> To the PCP implementation (or a piece of demux code handling the PCP = port) , that one bit indicates the incoming packet is not PCP, it's = something else running over PCP port. >=20 > When a bit is used for more than one purpose, that is called = "overloading". In this case, the bit is part of the PCP version number, = and is also used for demultiplexing. That is what "overloading" = means... >=20 >> With the new discovery solution we make sure PCP server does not find = itself having to process a request with unsupported version. >=20 >=20 > This is possible, yes, at some cost in terms of complexity. Assuming = the WG reaches consensus to proceed with a PANA-based approach, the WG = needs to compare the complexity of a discovery solution against the = overhead of encapsulation, in order to make an informed choice between = those two approaches. >=20 > Margaret >=20 >=20 From alper.yegin@yegin.org Thu Oct 18 00:02:55 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A6021F860E for ; Thu, 18 Oct 2012 00:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, 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 ca6L3-igF7A6 for ; Thu, 18 Oct 2012 00:02:54 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 4E36621F8608 for ; Thu, 18 Oct 2012 00:02:54 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M0yGd-1Tc92q1ccB-00uwR3; Thu, 18 Oct 2012 03:02:53 -0400 From: Alper Yegin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Oct 2012 10:02:37 +0300 Message-Id: <67054721-2DED-4023-89E2-F8E3692A6117@yegin.org> To: pcp@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:nOI86IfNdubQTq/RiRR92XtB5dDfnrj59AH8uEjoOhh i7boTIaFNsLU/AL9tP/r3pVJmoQ67hIkVvr4ZatCLCOxgUo8qT xcJnabqZ2+sWnI3dgfexcuVfdv3mZfvF69/xuR8lc4Zb/5TEk1 1uJqKPpwcRc19zCsu+cxapfdH7do0teqixEMYypRMCLlNre8Oj u54VMBnqGpQluBjKtqhPon6azKE3gCIzETjwFfMZbr6ZSCNblu JkoZKdkHzVBVgLjdqPn5I64CSDKpocRjh4pAxV+f0oJUYOD9F2 gPpPVs2y7o1vpNhWY/yXNwOQ1rn0GiXGnSWpHttk2gHIT9Ccgq Ce3q5Z8ou4H6n5MQc0Ly2IsBpYkrm4DfFlZUisE/Elvl+amye2 4D29HZNYJEkbw== Subject: [pcp] Loosely/tightly coupled auth/authz 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, 18 Oct 2012 07:02:55 -0000 Before I enter an in-depth discussion, let me say whether we decide to = do it one way or the other does not have any impact on the PANA vs. = EAP-o-PCP discussion. PANA can support both. Having said that, PCP WG still needs to decide which way to go, so let's = discuss that below. Margaret, the reason it took us so long to understand what you are = trying to do is because of the terminology. Your PPTs are referring to authentication and authorization. Not sure if = you are aware but authentication of what and authorization of what are = extremely important at this level of discussion. Let's be very specific. EAP (in conjunction with its EAP lower layer) authenticates the identity = of the end-point ("joe@domain", or more specifically "a device used by = joe@domain") Along with that there is an authorization of the requested service (PCP = in this case). The final response from the AAA server to the NAS (PCP = server in this case) not only says "yes, this is joe", but also says = "joe is allowed to use PCP service"). In fact, it may not even say "yes, = this is joe". That info may not matter to the NAS. And its disclosure to = the NAS may even be prohibited due to privacy concerns. AAA server tells = NAS "yes, this fellow is allowed to use PCP service". This is what centralized authentication and authorization servers, AAA = servers, do. At that level, in a sense, authentication and authorization is coupled.=20= Along with that authorization comes in a session lifetime, telling the = NAS for who long this authorized service is good for. AAA is saying "this fellow is allowed to use PCP service for 1 hour." It = can say further things too: stop the service after 1 hour, or re-auth = before the end-of 1 hour, etc. This is how the current EAP and AAA-based architectures work. Now, people said they'd like the PCP server (the NAS) set the session = lifetime. NAS can reduce the lifetime it received from the AAA server, but = extending the lifetime w/o AAA server's involvement would be a problem. = Because, the "centralized" authority sets the upper limit. This is the = whole reason of using a centralized AAA server. Second A is for = Authorization. You sound like you want to use AAA server for Authentication, but not = for Authorization. If this is what you want to do, please tell us why = you want to do it that way. This is unusual. Secondly, putting aside where the "PCP authorization lifetime" comes = from, you folks want to decouple EAP session lifetime with the PCP = lifetime. What's the benefit of this de-coupling? Why would you want to toss away your EAP session when the PCP state is = still up? Tossing away would force you to re-run EAP from scratch if the = client needs to process any other PCP packet meanwhile. Unnecessary = overhead. At the end of the day, here are the three lifetimes we could be talking = about: 1- Authorized service lifetime AAA tells the NAS (PCP server). 2- Effective lifetime set on the state created for the authorized = service. (mapping lifetime) 3- EAP session lifetime (MSK and its children's lifetime) In current EAP and AAA practice, these are all the same values.=20 If you want to deviate from that, we need to understand why. Because = that deviation is going to complicate a simple system. Alper From margaretw42@gmail.com Thu Oct 18 04:36:54 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 1400C21F8625 for ; Thu, 18 Oct 2012 04:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 sG84GshyK0hu for ; Thu, 18 Oct 2012 04:36:53 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29ED121F8623 for ; Thu, 18 Oct 2012 04:36:53 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so9581333vbb.31 for ; Thu, 18 Oct 2012 04:36:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=+PjZdgw+jITuRE9KWCJh4Edprf2QueTryvvqosBm+OE=; b=BiPwLbS71l8RvfKFQR+KCOq2Mz8YjlHFZIW9VvFDxEfhf7HBO9GN8vkpKxph/hQlTj rmPA4eA/jNVeVt+Q3saIMMaETOWnQXNGFvErxKBzMD+7y/uM9YYMN93iz8R01Ee0k2bM EqGft3LwRy5t8XaaVaBLV8kBtkUpB9F43fEkpM379erR1W54OHsk4GeUQq7YnavAIrfP MWN72tt+ocXGJOnTMKRUPkAo0g1mGjRjSXinwTNd4v4cIv74MCzvEVbCfFlUURmbezd1 1Uf0XnGSdGF0mnNhk7WZbIdpXXpO4jzFO2GUQk8euM9oZ9a/1kFiRXmh+1gglOgQkrS+ 81Sw== Received: by 10.52.77.101 with SMTP id r5mr11672378vdw.25.1350560212475; Thu, 18 Oct 2012 04:36:52 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id u2sm4785024vdt.11.2012.10.18.04.36.46 (version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 04:36:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <1B4F8624-DD1B-4678-9398-9ADEEB6E0104@yegin.org> Date: Thu, 18 Oct 2012 07:36:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5FA5FA56-2D65-4DDB-955F-319118C79F4A@gmail.com> References: <9E69EEA1-221C-4670-A0D8-DEC7AA423A58@lilacglade.org> <1B4F8624-DD1B-4678-9398-9ADEEB6E0104@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Margaret's PPT 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, 18 Oct 2012 11:36:54 -0000 Hi Alper, Expressing my own opinion, not trying to represent the opinion of the WG = or any other group... On Oct 18, 2012, at 2:22 AM, Alper Yegin wrote: > Hi Margaret, >=20 >>> - Decision tree starts with an "Architectural Model Discussion". = IMO, the starting and even determining point is whether we "re-use an = existing protocol, or re-invent it".=20 >>=20 >> You and Yoshi covered this topic in your slides, which you presented = at length in the last meeting. I don't think it would be useful to = present them again. >>=20 >=20 > Honestly, "architectural model discussion" is good for the PCP = authentication design, but won't be helpful for the PANA vs EAP-o-PCP = discussion. I think it will be, because it helps us understand what the different = solutions will really look like... > The reason is, since EAP-o-PCP is re-invention of PANA, unsurprisingly = the features will be the same. Then it'll simply boil down to my = question: re-use or re-invent.=20 The PCP-specific approach is not simply a "re-invention" of PANA. = Although it was originally conceived by looking at how PANA works, there = are difference that are intended to make it more suitable for use with = PCP. These include: - Integration with PCP messages (no need to demultiplex or fully = encapsulate another protocol, clean logging and error handling). - No server-generated requests (i.e. no equivalent to liveness tests or = server-initiated re-authentication) - Retransmissions are handled at the PCP level, not by the EAP upper = layer (avoiding server-generated retransmissions) In my opinion, saying something like "use PANA", and then providing a = long list of the parts of PANA that you shouldn't use ("liveness tests", = server-initiated re-authentication, EAP-layer retransmissions, IP = address reconfiguration, session termination, etc.), or that need to be = modified to work with PCP (i.e. meaning of the flag bits, role of the = enforcement point) would be a re-invention of PANA. =20 If PANA is meant to be a general purpose UDP-over-EAP authentication = mechanism, as you seem to indicate, then why doesn't the PANA document = say that? Why isn't there a mechanism in PANA to make it usable by more = than one application at the same time? Why is all of this network = access-specific stuff (IP address reconfig, "liveness tests", etc.) = mixed together with the authentication mechanism? In fact, the whole notion that we would invent a PCP-specific way to use = PANA is confusing to me, because PANA is _not_ a general-purpose = EAP-over-UDP authentication protocol -- it is a network access = authentication protocol like IEEE 802.1x... You are actually proposing = that we re-use _some parts_ of PANA for PCP, and that we re-invent the = parts of PANA that aren't suitable for use with PCP. Yes, it would be = possible to do those things, but why would that be better than using a = PCP-Specific mechanism? =20 You seem to have given up (in your proposals) on the notion that PCP and = the network access authentication portions of PANA could share a single = instance of a PAA, since you have not included a way to indicate whether = the request for authentication is coming from PCP or from a PANA network = access application. Do you actually think that by the time we are done = subsetting PANA to only include the authentication bits that are = appropriate to PCP that it will be possible to use the same code for a = PCP PAA and a PANA PAA? ...I don't. > Again, no code, no extra in PANA. >=20 >> Session termination >=20 > If the client decides to sign-off, > or the network decides to terminate the session (e.g, when the NAS = receives a AAA Disconnect message), then you need an explicit = termination message. > This is needed. There is no notion in PCP that a client would "sign off". PCP is a = UDP-based request/response protocol. There isn't anything to "sign-off" = from... >> Server-initiated re-auth >=20 > (will have a separate thread for that..) >=20 >=20 > PANA-Ping and IP Reconfig we agreed.=20 >=20 > What else?? If you can't eliminate server-initiated re-authentication, then there is = not benefit to eliminating PANA-Ping (called "liveness tests" in the = PANA document). Margaret From margaretw42@gmail.com Thu Oct 18 04:46:34 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D6021F8685 for ; Thu, 18 Oct 2012 04:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 QeYG4xRMO1ox for ; Thu, 18 Oct 2012 04:46:34 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C106D21F8673 for ; Thu, 18 Oct 2012 04:46:33 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so9593743vbb.31 for ; Thu, 18 Oct 2012 04:46:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=wzpQAVNNaUL6vhdMpw7GVx4WGy6J9Xqbot+au1+Q3uw=; b=mm68qFpZt+76eXMXxugUZBHjoPn/cH0VSvMWz1hrq83wlt+8SqAFIz0fqSPzX1pxKu rkGFm2G6H7b/yHIPOAIw6PMnwo2tmyyHMDdtwEUisrJc393Mh1D9KY6iGlSXQPZUgHsq 8s103C3gl5TalEdkzlVwYPeGB1HFWXhVfCZJz8LlfbWf4B+QyzeysmKPI4AJ8YkcE9W2 1oCH9Y4h6XgtEt20QJMbf4khG2UJx7o1v2AHCJhESgFXYzOiH/4aojmiZpjWo16Rm0U3 giZeQLBIkFZfGEotn29k5RZ0cRhVoFVSe5v409cLKdI+8bgFOx8nL7BYzqva6YmHAv9A PVag== Received: by 10.220.227.199 with SMTP id jb7mr4711502vcb.26.1350560793320; Thu, 18 Oct 2012 04:46:33 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id r6sm3031896vdj.8.2012.10.18.04.46.22 (version=SSLv3 cipher=OTHER); Thu, 18 Oct 2012 04:46:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: Date: Thu, 18 Oct 2012 07:46:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3462171E-F143-4810-B463-9E23AA738A03@lilacglade.org> References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <36E9DFAC-47D5-4942-937F-A88CD2AD75D0@lilacglade.org> <96744887-68C7-4F9A-813E-A5563E4356E2@gmail.com> <6569B9B2-0B82-450A-A328-D023EFC732DA@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] gss-eap & client-side rexmit only 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, 18 Oct 2012 11:46:34 -0000 Hi Alper, On Oct 18, 2012, at 2:04 AM, Alper Yegin wrote: >> Yep, there's no re-auth. It's absence is confirmed! :-) Does this mean that you think it is okay not to allow server-side = reauthentication? You wrote this before the call, but seemed to say = otherwise on the call. >> - What happens if server-side needs to re-key, extend lifetime, = change authorization, re-challenge the client?=20 >> Say, the acceptor receives a RADIUS CoA with EAP-Request, what's = going to do with it? If the PCP Server determines (for any reason) that the authentication = information is invalid, it will invalidate it. There is no reason to = inform the client (or an enforcement point, or anyone else) that the = information has been invalidated at that time, because _unlike the PANA = case_ there is no need to block any ongoing session and/or any ongoing = traffic from the PCP client to other nodes. The client can find out = that the authentication information has been invalidated when/if it = sends a PCP request using the now-invalid authentication information. = This will cause the PCP Server to return an authentication error, and = the client will attempt to re-authenticate. >> Sorry folks, gss-eap as an EAP lower layer spec is incomplete. = Whether you recognize and accept this today, or later when you start = building complete architectures/systems with it. No worries, you can = always add it. This is an issue you should raise with the abfab WG, i guess. I don't = think they will agree with you. Margaret From praspati@cisco.com Thu Oct 18 05:15: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 F37EE21F8629 for ; Thu, 18 Oct 2012 05:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.846 X-Spam-Level: X-Spam-Status: No, score=-8.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 St04Dsb1nMDM for ; Thu, 18 Oct 2012 05:15:08 -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 B7DA521F8647 for ; Thu, 18 Oct 2012 05:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5686; q=dns/txt; s=iport; t=1350562507; x=1351772107; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=oGgFdrYHCq7yRjkjY07UrrR5yTxp81mrYlJOz92gRC8=; b=XEix8aXabzk61jCnfGLXL/iBBwTIZmy9arvx1sF5UfSE2HzL+sWOnaA+ 6aPeB+jkFsr8pWkSI86SS6fepoPTJBGnFprMaYrqfKv7jFkqMsS7LQE7i bXOSiAjXs2VCKhgoO7b1Cmn+XwxTuVZRljv6NUpJgUqHgN4MxQfUzTMLt U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAODxf1CtJV2a/2dsb2JhbABFhhK5NnWBCIIgAQEBBAEBAQ8BIToJAhIBCBwGIgQfBgscCQIEDgUIARIHh1ADDwucJo0aBYkoDYlUgRyJVIYTN2ADlBaCaooPgyWBa4Jvghc X-IronPort-AV: E=Sophos;i="4.80,606,1344211200"; d="scan'208";a="129978054" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 18 Oct 2012 12:15:04 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9ICF3Vu029592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Oct 2012 12:15:04 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.203]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 07:15:03 -0500 From: "Prashanth Patil (praspati)" To: GangChen Thread-Topic: [pcp] FW: New Version Notification for draft-rpcw-pcp-pmipv6-serv-discovery-01.txt Thread-Index: AQHNrEOApab0il2HMUygZlEUftqugJe/q+KA Date: Thu, 18 Oct 2012 12:15:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [72.163.206.155] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--41.829100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] FW: New Version Notification for draft-rpcw-pcp-pmipv6-serv-discovery-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, 18 Oct 2012 12:15:09 -0000 SGkgR2VuZywNClRoYW5rcyBmb3IgdGhlIHJldmlldy4NCkNvbW1lbnRzIGlubGluZS4uIA0KDQpP biAxNy8xMC8xMiAxOjMwIFBNLCAiR2FuZ0NoZW4iIDxwaGRnYW5nQGdtYWlsLmNvbT4gd3JvdGU6 DQoNCj5IZWxsbyBhdXRob3JzLA0KPg0KPkZldyBxdWVzdGlvbnMgYXJlIGJlbG93IHRyeWluZyB0 byBtYWtlIGZ1cnRoZXIgY2xhcmlmaWNhdGlvbnMuDQo+DQo+MS4gSSBoYXZlIGEgbGl0dGxlIGNv bmZ1c2lvbiBvbiB0aGUgc3RhdGVtZW50DQo+IiAgIElmIHRoZSBkeW5hbWljIG91dGJvdW5kIG1h cHBpbmcgaXMgZm9yIHRoZSBsb2NhbCBhY2Nlc3MgbmV0d29yayB0aGVuDQo+ICAgdGhlcmUgYXJl IHR3byBjYXNlcyB0byBjb25zaWRlciAtIEluIHRoZSBmaXJzdCBjYXNlIHdoZXJlIHRoZXJlIGlz IGENCj4gICBuZXN0ZWQgTkFUW0ktRC5wZW5uby1wY3AtbmVzdGVkLW5hdF0sIHRoZSBtb2JpbGUg YWNjZXNzIGdhdGV3YXkgd2lsbA0KPiAgIGZ1bmN0aW9uIGFzIGJvdGggUENQIHNlcnZlciBhbmQg UENQIHByb3h5IGZvcndhcmRpbmcgdGhlIGFjY2VwdGVkIFBDUA0KPiAgIHJlcXVlc3QgdG8gQ0dO IFBDUCBzZXJ2ZXIuICBJbiB0aGUgc2Vjb25kIGNhc2UsIHdoZXJlIHRoZXJlIGlzIG5vDQo+ICAg Q0dOLCBtb2JpbGUgYWNjZXNzIGdhdGV3YXkgd2lsbCBmdW5jdGlvbiBhcyBhIFBDUCBzZXJ2ZXIg aW4gdGhlIGxvY2FsDQo+ICAgYWNjZXNzIG5ldHdvcmsuDQo+Ig0KPldoZW4gdGhlIHRyYWZmaWMg aXMgaGVhZGluZyB0byB0aGUgTkFUIGluIGxvY2FsIGFjY2VzcyBuZXR3b3JrLCB0aGVyZQ0KPmlz IG5vIE5BVCBwcm9jZXNzaW5nIGluIGhvbWVuZXQuIFdvbmRlcmluZyB0byBrbm93IHdoYXQgaXMg dGhlIGNhc2Ugb2YNCj5uZXN0ZWQgTkFUIHlvdSByZWZlciB0bz8NCg0KWWVzLCB0aGVyZSBzaG91 bGRuqfZ0IGJlIGEgY2FzZSBmb3IgbmVzdGVkIE5BVCBhcyBwZXIgUkZDNTg0NC4gV2UnbGwNCmNv cnJlY3QgdGhpcy4NCg0KDQo+DQo+Mi4gV2hhdCBpcyB0aGUgZ29hbCBvZiBkZXNpZ25pbmcgbW9i aWxpdHkgb3B0aW9ucz8gSSByZWFkIHRoZSBTZWN0aW9uDQo+MywgaXQgc2VlbXMgYSBzbWFydCBQ Q1AgcHJveHkgaXMgc3VmZmljaWVudCB0byBoYW5kbGUgdGhlIHRyYWZmaWMNCj5kaXNwYXRjaD8g d2hhdCB0aGUgY29uc2lkZXJhdGlvbiB0byB0aGlzIG9wdGlvbj8NCg0KTW9iaWxpdHkgb3B0aW9u cyBhcmUgcmVxdWlyZWQgdG8gY29udmV5IGRvbWFpbiBuYW1lIG9mIHRoZSBQQ1AgU2VydmVyDQp3 aXRoaW4gdGhlIGhvbWUgbmV0d29yayB0byBiZSB1c2VkIGJ5IHRoZSBNQUcuIFRoZSBNQUcgaXMg dW5hd2FyZSBvZiB0aGUNClBDUCBzZXJ2ZXIgZGV0YWlscyB3aXRoaW4gdmFyaW91cyBob21lIG5l dHdvcmtzIGFuZCB0aGlzIG9wdGlvbiBhbGxvd3MgUENQDQppbmZvcm1hdGlvbiB0byBiZSBwcm9w YWdhdGVkIHRvIHRoZSBsb2NhbCBuZXR3b3JrIGZyb20gdGhlIGhvbWUgbmV0d29yaw0KdmlhIFBN SVAgc2lnbmFsaW5nLg0KDQoNCj4NCj4NCj4zLiBIb3cgZG8geW91IGhhbmRsZSB0aGUgY2FzZSBv ZiBJUHY2IG9mZmxvYWRpbmc/DQoNClBNSVB2NiBmb3Igb2ZmbG9hZGluZyBkb2VzIG5vdCBhc3N1 bWUgTlBUdjYNCihodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGV4dC1w bWlwdjYtc2lwdG8tb3B0aW9uLTA2I3NlY3Rpbw0Kbi0xKSBzbyB0aGUgUENQIHNlcnZlciBpcyBv bmx5IGZvciBmaXJld2FsbC4NCg0KRm9yIElQdjYsIGFzIHRoZSBNTiBjYW4gYmUgYXNzaWduZWQg YW4gSVB2NiBwcmVmaXggZnJvbSB0aGUgYWNjZXNzIG5ldHdvcmsNCmluIGFkZGl0aW9uIHRvIHRo ZSBJUHY2IHByZWZpeCBmcm9tIHRoZSBob21lIG5ldHdvcmssIHRoZXJlYnkgYWxsb3dpbmcgdGhl DQpNTiB0byB1c2UgYW4gSVB2NiBhZGRyZXNzIGZyb20gdGhlIGFjY2VzcyBuZXR3b3JrIGZvciB0 cmFmZmljIHRoYXQgbmVlZHMNCnRvIGJlIG9mZmxvYWRlZCBpbiB0aGUgYWNjZXNzIG5ldHdvcmsu IFRoaXMgc2NlbmFyaW8gaXMgc2ltaWxhciB0byBJUHY2DQptdWx0aWhvbWluZyBhbmQNCmh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhdGlsLXBjcC1tdWx0aWhvbWluZy0wMCNzZWN0 aW9uLTMNCmV4cGxhaW5zIFBDUCBjbGllbnQgYmVoYXZpb3IgaW4gc3VjaCBjYXNlcy4NCg0KDQpX ZSBpbnRlbmQgdG8gYWRkIElQdjYgZGV0YWlscyBpbiB0aGUgbmV4dCByZXZpc2lvbi4NCg0KLVBy YXNoYW50aA0KDQoNCg0KPg0KPkJlc3QgUmVnYXJkcw0KPg0KPkdhbmcNCj4NCj4NCj4yMDEyLzkv MTcsIFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpIDxwcmFzcGF0aUBjaXNjby5jb20+Og0KPj4g VGhpcyBpcyBhbiB1cGRhdGVkIHZlcnNpb24gYWZ0ZXIgYWNjb21tb2RhdGluZyByZXZpZXcgY29t bWVudHMuDQo+Pg0KPj4gQ29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIHdlbGNvbWUuDQo+Pg0KPj4g LVByYXNoYW50aA0KPj4NCj4+DQo+Pg0KPj4+DQo+Pj5PbiAzMS8wOC8xMiA4OjUzIFBNLCAiaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIg0KPj4+PGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCj4+ Pndyb3RlOg0KPj4+DQo+Pj4+DQo+Pj4+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXJwY3ct cGNwLXBtaXB2Ni1zZXJ2LWRpc2NvdmVyeS0wMS50eHQNCj4+Pj5oYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IFByYXNoYW50aCBQYXRpbCBhbmQgcG9zdGVkIHRvIHRoZQ0KPj4+PklF VEYgcmVwb3NpdG9yeS4NCj4+Pj4NCj4+Pj5GaWxlbmFtZToJIGRyYWZ0LXJwY3ctcGNwLXBtaXB2 Ni1zZXJ2LWRpc2NvdmVyeQ0KPj4+PlJldmlzaW9uOgkgMDENCj4+Pj5UaXRsZToJCSBQQ1AgU2Vy dmVyIERpc2NvdmVyeSB3aXRoIElQdjQgdHJhZmZpYyBvZmZsb2FkIGZvciBQcm94eQ0KPj4+Pk1v YmlsZQ0KPj4+PklQdjYNCj4+Pj5DcmVhdGlvbiBkYXRlOgkgMjAxMi0wOC0zMQ0KPj4+PldHIElE OgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPj4+Pk51bWJlciBvZiBwYWdlczogMTMNCj4+Pj5V Ukw6DQo+Pj4+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcnBjdy1w Y3AtcG1pcHY2LXNlcnYtZGlzY292ZXINCj4+Pj55LQ0KPj4+PjANCj4+Pj4xLnR4dA0KPj4+PlN0 YXR1czoNCj4+Pj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJwY3ctcGNw LXBtaXB2Ni1zZXJ2LWRpc2NvdmVyeQ0KPj4+Pkh0bWxpemVkOg0KPj4+Pmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXJwY3ctcGNwLXBtaXB2Ni1zZXJ2LWRpc2NvdmVyeS0wMQ0KPj4+ PkRpZmY6DQo+Pj4+aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtcnBjdy1w Y3AtcG1pcHY2LXNlcnYtZGlzY292ZXJ5LTANCj4+Pj4xDQo+Pj4+DQo+Pj4+QWJzdHJhY3Q6DQo+ Pj4+ICAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyBhIHNvbHV0aW9uIHRvIFBDUCBTZXJ2ZXIgRGlz Y292ZXJ5IHByb2JsZW1zDQo+Pj4+aW4NCj4+Pj4gICBQcm94eSBNb2JpbGUgSVB2NiAoUE1JUHY2 KSBuZXR3b3JrcyB3aGVuIGJvdGggaG9tZSBuZXR3b3JrIHRyYWZmaWMNCj4+Pj4gICBhbmQgdHJh ZmZpYyBvZmYtbG9hZGVkIHRvIGxvY2FsIGFjY2VzcyBuZXR3b3JrIHJlcXVpcmUgdHJhdmVyc2lu ZyBhDQo+Pj4+ICAgZ2F0ZXdheSBpbXBsZW1lbnRpbmcgTkFUIGFuZC9vciBGaXJld2FsbC4gIFRo aXMgZHJhZnQgcHJvcG9zZXMNCj4+Pj4gICBlbmhhbmNlbWVudHMgdG8gREhDUHY0IFJlbGF5IEFn ZW50IGJ5IGludHJvZHVjaW5nIGEgbmV3IHN1Yi1vcHRpb24NCj4+Pj4gICB1bmRlciBESENQdjQg UmVsYXkgT3B0aW9uIGFuZCB0byBQTUlQdjYgc2lnbmFsaW5nIHRocm91Z2ggYWRkaXRpb25hbA0K Pj4+PiAgIG9wdGlvbnMgdG8gUHJveHkgQmluZGluZyBVcGRhdGUvQWNrbm93bGVkZ2VtZW50IG1l c3NhZ2VzLg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PlRoZSBJRVRGIFNlY3Jl dGFyaWF0DQo+Pj4+DQo+Pj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4gcGNwIG1haWxpbmcgbGlzdA0KPj4gcGNwQGlldGYub3JnDQo+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BjcA0KPj4NCg0K From hartmans@painless-security.com Thu Oct 18 06:25:16 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 D40E521F8599 for ; Thu, 18 Oct 2012 06:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.364 X-Spam-Level: **** X-Spam-Status: No, score=4.364 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.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 B7LRtUZLQWGL for ; Thu, 18 Oct 2012 06:25:16 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 0062121F854F for ; Thu, 18 Oct 2012 06:25:15 -0700 (PDT) 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.suchdamage.org (Postfix) with ESMTPS id 7E00220115; Thu, 18 Oct 2012 09:24:59 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 843F04AD5; Thu, 18 Oct 2012 09:25:13 -0400 (EDT) From: Sam Hartman To: Alper Yegin References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <36E9DFAC-47D5-4942-937F-A88CD2AD75D0@lilacglade.org> <96744887-68C7-4F9A-813E-A5563E4356E2@gmail.com> <6569B9B2-0B82-450A-A328-D023EFC732DA@yegin.org> Date: Thu, 18 Oct 2012 09:25:13 -0400 In-Reply-To: (Alper Yegin's message of "Thu, 18 Oct 2012 09:04:43 +0300") 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] gss-eap & client-side rexmit only 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, 18 Oct 2012 13:25:16 -0000 >>>> "Alper" == Alper Yegin writes: Alper> Sam, You claimed you can design an EAP lower layer that's Alper> always client driven, and gave GSS-EAP as an example of how Alper> you did it. Alper> So, I had already looked at it and still don't see it how. Alper> See below for the last email I sent on this matter which went Alper> unanswered. Hi Alper. I think I've done a number of things to try and walk you through this: * We've had multiple discussions on the list where we discussed whether this was possible in the EAP spec * I pointed you at the gss-eap specification * I gave textual explanations of how it works * I went over it on the call again yesterday * During the PANA implementation discussion I pointed you at an open-source implementation of GSS-EAP and particularly pointed you at the part of the code that interacts with the EAP library. Other people do seem to be following this issue at this point, so I'm afraid we're talking past each other. I'm sorry about that, but perhaps it would make more sense for you to try and work with someone else on this issue. If there are PCP implementors on this who need to discuss this in more detail I'd be happy to try and help as I can. Date: Thu, 18 Oct 2012 09:24:51 -0400 In-Reply-To: (Alper Yegin's message of "Thu, 18 Oct 2012 09:04:43 +0300") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) From yoshihiro.ohba@toshiba.co.jp Thu Oct 18 08:32: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 5FED621F8710 for ; Thu, 18 Oct 2012 08:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.89 X-Spam-Level: X-Spam-Status: No, score=-4.89 tagged_above=-999 required=5 tests=[AWL=-0.801, 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 LjNEpdP-bnFO for ; Thu, 18 Oct 2012 08:32:03 -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 530C421F8786 for ; Thu, 18 Oct 2012 08:32:00 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q9IFVwP8023768 for ; Fri, 19 Oct 2012 00:31:58 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q9IFVwe8013044 for pcp@ietf.org; Fri, 19 Oct 2012 00:31:58 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id AAA13043; Fri, 19 Oct 2012 00:31:58 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q9IFVwmQ020141 for ; Fri, 19 Oct 2012 00:31:58 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q9IFVwVF017689; Fri, 19 Oct 2012 00:31:58 +0900 (JST) Received: from [133.199.17.24] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MC3004XIHSYPQ00@mail.po.toshiba.co.jp> for pcp@ietf.org; Fri, 19 Oct 2012 00:31:58 +0900 (JST) Date: Fri, 19 Oct 2012 00:31:56 +0900 From: Yoshihiro Ohba In-reply-to: <3462171E-F143-4810-B463-9E23AA738A03@lilacglade.org> To: pcp@ietf.org Message-id: <508020EC.3060601@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <36E9DFAC-47D5-4942-937F-A88CD2AD75D0@lilacglade.org> <96744887-68C7-4F9A-813E-A5563E4356E2@gmail.com> <6569B9B2-0B82-450A-A328-D023EFC732DA@yegin.org> <3462171E-F143-4810-B463-9E23AA738A03@lilacglade.org> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Subject: Re: [pcp] gss-eap & client-side rexmit only 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, 18 Oct 2012 15:32:04 -0000 Margaret, (2012/10/18 20:46), Margaret Wasserman wrote: > Hi Alper, > > On Oct 18, 2012, at 2:04 AM, Alper Yegin wrote: >>> Yep, there's no re-auth. It's absence is confirmed! :-) > Does this mean that you think it is okay not to allow server-side reauthentication? You wrote this before the call, but seemed to say otherwise on the call. > >>> - What happens if server-side needs to re-key, extend lifetime, change authorization, re-challenge the client? >>> Say, the acceptor receives a RADIUS CoA with EAP-Request, what's going to do with it? > If the PCP Server determines (for any reason) that the authentication information is invalid, it will invalidate it. There is no reason to inform the client (or an enforcement point, or anyone else) that the information has been invalidated at that time, because _unlike the PANA case_ there is no need to block any ongoing session and/or any ongoing traffic from the PCP client to other nodes. This is not true for tightly-coupled authentication/authorization model. Tightly-coupled authentication/authorization model (which is typical in AAA architecture) needs to be supported, and in tightly-coupled authentication/authorization model, support for server-initiated re-authentication makes a lot of sense. This does not mean clients cannot sleep. Clients can sleep but they may just miss to receive server-initiated re-authentication requests, and if that happens they will need to start full authentication, which is fine. I don't disagree with additional support of loosely coupled model, but I disagree if you say tightly-coupled authentication/authorization model is not needed. Yoshihiro Ohba > The client can find out that the authentication information has been invalidated when/if it sends a PCP request using the now-invalid authentication information. This will cause the PCP Server to return an authentication error, and the client will attempt to re-authenticate. > >>> Sorry folks, gss-eap as an EAP lower layer spec is incomplete. Whether you recognize and accept this today, or later when you start building complete architectures/systems with it. No worries, you can always add it. > This is an issue you should raise with the abfab WG, i guess. I don't think they will agree with you. > > Margaret > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From yoshihiro.ohba@toshiba.co.jp Thu Oct 18 09:01: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 0A48721F8806 for ; Thu, 18 Oct 2012 09:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.854 X-Spam-Level: X-Spam-Status: No, score=-6.854 tagged_above=-999 required=5 tests=[AWL=1.235, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, 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 w1q750xvoqoZ for ; Thu, 18 Oct 2012 09:01:13 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id C9B9221F8803 for ; Thu, 18 Oct 2012 09:01:12 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q9IG1BtO012235 for ; Fri, 19 Oct 2012 01:01:11 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q9IG1BTh004244 for pcp@ietf.org; Fri, 19 Oct 2012 01:01:11 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id BAA04243; Fri, 19 Oct 2012 01:01:11 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q9IG1AlK006484 for ; Fri, 19 Oct 2012 01:01:11 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q9IG1A4l024302; Fri, 19 Oct 2012 01:01:10 +0900 (JST) Received: from [133.199.17.24] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MC300421J5MPP10@mail.po.toshiba.co.jp> for pcp@ietf.org; Fri, 19 Oct 2012 01:01:10 +0900 (JST) Date: Fri, 19 Oct 2012 01:01:08 +0900 From: Yoshihiro Ohba In-reply-to: <5FA5FA56-2D65-4DDB-955F-319118C79F4A@gmail.com> To: pcp@ietf.org Message-id: <508027C4.7020702@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <9E69EEA1-221C-4670-A0D8-DEC7AA423A58@lilacglade.org> <1B4F8624-DD1B-4678-9398-9ADEEB6E0104@yegin.org> <5FA5FA56-2D65-4DDB-955F-319118C79F4A@gmail.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Subject: Re: [pcp] Margaret's PPT 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, 18 Oct 2012 16:01:14 -0000 Hi Margaret, (2012/10/18 20:36), Margaret Wasserman wrote: > Hi Alper, > > Expressing my own opinion, not trying to represent the opinion of the WG or any other group... > > On Oct 18, 2012, at 2:22 AM, Alper Yegin wrote: > >> Hi Margaret, >> >>>> - Decision tree starts with an "Architectural Model Discussion". IMO, the starting and even determining point is whether we "re-use an existing protocol, or re-invent it". >>> You and Yoshi covered this topic in your slides, which you presented at length in the last meeting. I don't think it would be useful to present them again. >>> >> Honestly, "architectural model discussion" is good for the PCP authentication design, but won't be helpful for the PANA vs EAP-o-PCP discussion. > I think it will be, because it helps us understand what the different solutions will really look like... > >> The reason is, since EAP-o-PCP is re-invention of PANA, unsurprisingly the features will be the same. Then it'll simply boil down to my question: re-use or re-invent. > The PCP-specific approach is not simply a "re-invention" of PANA. Although it was originally conceived by looking at how PANA works, there are difference that are intended to make it more suitable for use with PCP. These include: > > - Integration with PCP messages (no need to demultiplex or fully encapsulate another protocol, clean logging and error handling). > - No server-generated requests (i.e. no equivalent to liveness tests or server-initiated re-authentication) > - Retransmissions are handled at the PCP level, not by the EAP upper layer (avoiding server-generated retransmissions) To me these things are not attractive enough to define a new EAP transport specific to PCP compared to the benefit of reuse of a well-defined and interoperable protocol (i.e., PANA). If we decide to use either of the two PANA-based I-Ds for which some people already mentioned that they are short and workable, then I believe we can quickly get our work done. > > In my opinion, saying something like "use PANA", and then providing a long list of the parts of PANA that you shouldn't use ("liveness tests", server-initiated re-authentication, EAP-layer retransmissions, IP address reconfiguration, session termination, etc.), or that need to be modified to work with PCP (i.e. meaning of the flag bits, role of the enforcement point) would be a re-invention of PANA. I disagree. It is re-use of PANA with a specific profile of not using some optional features. (BTW, I never mentioned that server-iniated re-authentication, EAP-layer retransmision and session termination should not be used.) > > > If PANA is meant to be a general purpose UDP-over-EAP authentication mechanism, as you seem to indicate, then why doesn't the PANA document say that? Why isn't there a mechanism in PANA to make it usable by more than one application at the same time? Why is all of this network access-specific stuff (IP address reconfig, "liveness tests", etc.) mixed together with the authentication mechanism? PANA is already used as a general purpose UDP-over-EAP authentication mechanism in ETSI MSM. > > In fact, the whole notion that we would invent a PCP-specific way to use PANA is confusing to me, because PANA is _not_ a general-purpose EAP-over-UDP authentication protocol -- it is a network access authentication protocol like IEEE 802.1x... You are actually proposing that we re-use _some parts_ of PANA for PCP, and that we re-invent the parts of PANA that aren't suitable for use with PCP. Yes, it would be possible to do those things, but why would that be better than using a PCP-Specific mechanism? > > You seem to have given up (in your proposals) on the notion that PCP and the network access authentication portions of PANA could share a single instance of a PAA, since you have not included a way to indicate whether the request for authentication is coming from PCP or from a PANA network access application. Do you actually think that by the time we are done subsetting PANA to only include the authentication bits that are appropriate to PCP that it will be possible to use the same code for a PCP PAA and a PANA PAA? ...I don't. Why not? Both PANA-based approaches use port number to distinguish PCP authentication and network access authentication. Yoshihiro Ohba > >> Again, no code, no extra in PANA. >> >>> Session termination >> If the client decides to sign-off, >> or the network decides to terminate the session (e.g, when the NAS receives a AAA Disconnect message), then you need an explicit termination message. >> This is needed. > There is no notion in PCP that a client would "sign off". PCP is a UDP-based request/response protocol. There isn't anything to "sign-off" from... > >>> Server-initiated re-auth >> (will have a separate thread for that..) >> >> >> PANA-Ping and IP Reconfig we agreed. >> >> What else?? > If you can't eliminate server-initiated re-authentication, then there is not benefit to eliminating PANA-Ping (called "liveness tests" in the PANA document). > > Margaret > > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From internet-drafts@ietf.org Fri Oct 19 01:05:51 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F65621F88F7; Fri, 19 Oct 2012 01:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, 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 GEkVRqFbJOaS; Fri, 19 Oct 2012 01:05:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C2B21F8896; Fri, 19 Oct 2012 01:05:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121019080550.15043.98554.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2012 01:05:50 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action: draft-ietf-pcp-authentication-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: Fri, 19 Oct 2012 08:05:51 -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) Authentication Mechanism Author(s) : Margaret Wasserman Sam Hartman Dacheng Zhang Filename : draft-ietf-pcp-authentication-01.txt Pages : 19 Date : 2012-10-19 Abstract: An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to flexibly manage the IP address and port mapping information on Network Address Translators (NATs) or firewalls, to facilitate communications with remote hosts. However, the un-controlled generation or deletion of IP address mappings on such network devices may cause security risks and should be avoided. In some cases the client may need to prove that it is authorized to modify, create or delete PCP mappings. This document proposes an in-band authentication mechanism for PCP that can be used in those cases. The Extensible Authentication Protocol (EAP) is used to perform authentication between PCP devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pcp-authentication There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pcp-authentication-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-authentication-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hartmans@painless-security.com Fri Oct 19 06:11:16 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 DB20521F8585 for ; Fri, 19 Oct 2012 06:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.362 X-Spam-Level: **** X-Spam-Status: No, score=4.362 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.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 AQcjtLAJwNVW for ; Fri, 19 Oct 2012 06:11:16 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7F321F8594 for ; Fri, 19 Oct 2012 06:11:16 -0700 (PDT) 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.suchdamage.org (Postfix) with ESMTPS id 52FBD2010B for ; Fri, 19 Oct 2012 09:03:30 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F320C4AD5; Fri, 19 Oct 2012 09:03:45 -0400 (EDT) From: Sam Hartman To: pcp@ietf.org Date: Fri, 19 Oct 2012 09:03:45 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [pcp] Have I missed the Issue e-mails? 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, 19 Oct 2012 13:11:17 -0000 There will be mails to the list when the issues are opened, right? It would be really good to get that sooner rather than later so we don't lose momentum from Wednesday's call. I'm waiting to see those before posting thoughts. --Sam From trac@tools.ietf.org Fri Oct 19 14:42:54 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 1C20421F8830 for ; Fri, 19 Oct 2012 14:42:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTXnECtje7sE for ; Fri, 19 Oct 2012 14:42:53 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 89C2921F882E for ; Fri, 19 Oct 2012 14:42:53 -0700 (PDT) Received: from localhost ([127.0.0.1]:38957 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TPKKz-0004mL-Ui; Fri, 19 Oct 2012 23:42:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-pcp-dhcp@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Fri, 19 Oct 2012 21:42:37 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/58#comment:1 Message-ID: <092.a6e86ca842d8a263119f4580916f75d0@tools.ietf.org> References: <077.85b119a156bc4cf8903e1fb82de118fa@tools.ietf.org> X-Trac-Ticket-ID: 58 In-Reply-To: <077.85b119a156bc4cf8903e1fb82de118fa@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-dhcp@tools.ietf.org, dthaler@microsoft.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: dwing@cisco.com, mohamed.boucadair@orange.com, repenno@cisco.com Resent-Message-Id: <20121019214253.89C2921F882E@ietfa.amsl.com> Resent-Date: Fri, 19 Oct 2012 14:42:53 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #58: DHCP option issues from Margaret Wasserman X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 21:42:54 -0000 #58: DHCP option issues from Margaret Wasserman Comment (by dthaler@…): Should be done in lastest draft. -- ----------------------------------------+---------------------------------- Reporter: Margaret Wasserman | Owner: draft-ietf-pcp- Type: defect | dhcp@… Priority: major | Status: new Component: dhcp | Milestone: Severity: - | Version: Keywords: | Resolution: ----------------------------------------+---------------------------------- Ticket URL: pcp From trac@tools.ietf.org Fri Oct 19 14:43:06 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 7293C21F882A for ; Fri, 19 Oct 2012 14:43: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9l-s0GHflHt for ; Fri, 19 Oct 2012 14:43:06 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id B759621F87A2 for ; Fri, 19 Oct 2012 14:43:05 -0700 (PDT) Received: from localhost ([127.0.0.1]:39032 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TPKLO-0003uJ-Gx; Fri, 19 Oct 2012 23:43:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-pcp-dhcp@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Fri, 19 Oct 2012 21:43:02 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: https://etherpad.tools.ietf.org/wg/pcp/trac/ticket/58#comment:2 Message-ID: <092.c4587b23dfee29da5429f22ba8870a8c@tools.ietf.org> References: <077.85b119a156bc4cf8903e1fb82de118fa@tools.ietf.org> X-Trac-Ticket-ID: 58 In-Reply-To: <077.85b119a156bc4cf8903e1fb82de118fa@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-dhcp@tools.ietf.org, dthaler@microsoft.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: dwing@cisco.com, mohamed.boucadair@orange.com, repenno@cisco.com Resent-Message-Id: <20121019214305.B759621F87A2@ietfa.amsl.com> Resent-Date: Fri, 19 Oct 2012 14:43:05 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #58: DHCP option issues from Margaret Wasserman X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 21:43:06 -0000 #58: DHCP option issues from Margaret Wasserman Changes (by dthaler@…): * status: new => closed * resolution: => fixed -- ----------------------------------------+---------------------------------- Reporter: Margaret Wasserman | Owner: draft-ietf-pcp- Type: defect | dhcp@… Priority: major | Status: closed Component: dhcp | Milestone: Severity: - | Version: Keywords: | Resolution: fixed ----------------------------------------+---------------------------------- Ticket URL: pcp From trac@tools.ietf.org Fri Oct 19 14:48:20 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 8109721F882F for ; Fri, 19 Oct 2012 14:48:20 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bz0a6F7hu-S7 for ; Fri, 19 Oct 2012 14:48:19 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC7021F87DD for ; Fri, 19 Oct 2012 14:48:19 -0700 (PDT) Received: from localhost ([127.0.0.1]:39611 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TPKQ9-0003A9-Pt; Fri, 19 Oct 2012 23:47:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-pcp-authentication@tools.ietf.org, margaretw42@gmail.com X-Trac-Project: pcp Date: Fri, 19 Oct 2012 21:47:57 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://etherpad.tools.ietf.org/wg/pcp/trac/ticket/60 Message-ID: <059.ee19c749268bb0faec7a31e0aeaa28c8@tools.ietf.org> X-Trac-Ticket-ID: 60 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-authentication@tools.ietf.org, margaretw42@gmail.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: hartmans@painless-security.com, mrw@painless-security.com, zhangdacheng@huawei.com Resent-Message-Id: <20121019214819.7DC7021F87DD@ietfa.amsl.com> Resent-Date: Fri, 19 Oct 2012 14:48:19 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: [pcp] #60: Loosely coupled vs. tightly coupled authentication 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, 19 Oct 2012 21:48:20 -0000 #60: Loosely coupled vs. tightly coupled authentication Loosely coupled: – Authentication needed only at the time of a request, to create/modify a mapping. – Authorization done separately, using the same mechanism as in non- authenticated PCP • Mappings are removed when authorization is revoked – Mapping lifetime is not tied to authentication lifetime Tightly coupled: – Authentication and authorization are performed using the same mechanism, or there is a link between them – Mapping lifetime is tied to authentication lifetime • Mappings are removed when keys expire OR authorization is revoke -- ----------------------------+--------------------------------------------- Reporter: margaretw42@… | Owner: draft-ietf-pcp-authentication@… Type: defect | Status: new Priority: major | Milestone: Component: authentication | Version: Severity: - | Keywords: ----------------------------+--------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Fri Oct 19 14:49: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 2F46F21F876B for ; Fri, 19 Oct 2012 14:49:57 -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.000, BAYES_00=-2.599, 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 1tyo-NaDwW+p for ; Fri, 19 Oct 2012 14:49:56 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 32C9821F874E for ; Fri, 19 Oct 2012 14:49:56 -0700 (PDT) Received: from localhost ([127.0.0.1]:39655 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TPKS1-0008Tr-25; Fri, 19 Oct 2012 23:49:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-pcp-authentication@tools.ietf.org, margaretw42@gmail.com X-Trac-Project: pcp Date: Fri, 19 Oct 2012 21:49:53 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/61 Message-ID: <059.54331fe983d68240406025bfdbc8a50e@tools.ietf.org> X-Trac-Ticket-ID: 61 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-authentication@tools.ietf.org, margaretw42@gmail.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: hartmans@painless-security.com, mrw@painless-security.com, zhangdacheng@huawei.com Resent-Message-Id: <20121019214956.32C9821F874E@ietfa.amsl.com> Resent-Date: Fri, 19 Oct 2012 14:49:56 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: [pcp] #61: Unsolicited reauthentication 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, 19 Oct 2012 21:49:57 -0000 #61: Unsolicited reauthentication Would it be desirable to support unsolicited re-authentication? – May depend on answer to issue #60 – is there a need to renew authentication information when no requests are being issued? Or is it preferable to wait until a new mapping request is issued, and start a new authentication process then, if needed? -- ----------------------------+--------------------------------------------- Reporter: margaretw42@… | Owner: draft-ietf-pcp-authentication@… Type: defect | Status: new Priority: major | Milestone: Component: authentication | Version: Severity: - | Keywords: ----------------------------+--------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Fri Oct 19 14:57:26 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 245D521F851E for ; Fri, 19 Oct 2012 14:57:26 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGKnN3f5cicd for ; Fri, 19 Oct 2012 14:57:25 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 13D4621F8495 for ; Fri, 19 Oct 2012 14:57:25 -0700 (PDT) Received: from localhost ([127.0.0.1]:40674 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TPKZ4-0007nT-WA; Fri, 19 Oct 2012 23:57:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-pcp-authentication@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Fri, 19 Oct 2012 21:57:10 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/60#comment:1 Message-ID: <074.8929e27a7e2003f36dc67a75653b6951@tools.ietf.org> References: <059.ee19c749268bb0faec7a31e0aeaa28c8@tools.ietf.org> X-Trac-Ticket-ID: 60 In-Reply-To: <059.ee19c749268bb0faec7a31e0aeaa28c8@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-authentication@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: hartmans@painless-security.com, mrw@painless-security.com, zhangdacheng@huawei.com Resent-Message-Id: <20121019215725.13D4621F8495@ietfa.amsl.com> Resent-Date: Fri, 19 Oct 2012 14:57:25 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #60: Loosely coupled vs. tightly coupled authentication 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, 19 Oct 2012 21:57:26 -0000 #60: Loosely coupled vs. tightly coupled authentication Comment (by dthaler@…): Raw notes from Simon in December 2012 webex interim meeting: - Authentication and authorization can be loosely or tightly coupled. (slide 8) Alper: Are there examples of loosely/tightly coupled? All current designs are tightly coupled. Sam: SSH into a router, create a hole in the firewall. The hole will extend beyond the lifetime of the SSH session. Other example: Kerberos certificate ... (did not understand). Alper: Lifetime of SSH credentials cannot be shorter than the change you're making on the firewall. Margaret: That's not true. Even getting rid of the user does not remove the firewall changes. Margaret: Third party use case: make port 80 go to a web server that does not speak PCP using third-party client. You don't want to tie the mapping lifetime to the third-party client. Alper: You're referring to PANA ping? Margaret: PANA ping and server-initiated have the same effect. Sam: (did not understand) Margaret: The question is do we want the mapping lifetime to be tied to the authentication lifetime? Dave Thaler: The question is what model do we want? Tightly or loosely coupled, or both? A protocol could support both and be negotiated per session. Margaret: (did not understand) Alper: What would be different for the loosely coupled model? Margaret: Authentication would only be verified for the act of creating a mapping. Not for keeping the keeping the mapping alive. Alper: You would receive two separate timers from the AAA server? Sam: Not necessarily. Dave Thaler: PCP is an additional way of doing things. Does not change NAT implementations. Alper: AAA server determines lifetime? Dave Thaler: It can be independent. (I am missing the point of this discussion now.) Yoshi: What happens in a loosely coupled system when auth lifetime expires? Margaret: Authentication procedure is re-done to recreate auth credentials. Alper: No need to maintain the keys throughout the PCP session? Margaret: Right. Dave Thaler: PCP session only lasts for 3 seconds or so. Alper: PCP is used to maintain mapping state. That's what I call session state. Margaret: PCP is used to control a firewall or a NAT. Sam: (did not understand) Simon: A mapping can be created explicitly (PCP) and then refreshed implicitly (by traffic) indefinitly. Alper: How do we know if a client is authorized to modify another client's mapping? Sam: Server policy. Sam: (did not understand) Yoshi: Any approach can support loosely or tightly coupled model. (general agreement) Margaret: We have to specify the coupling model in the document. (general agreement) -- ----------------------------+---------------------------------------------- Reporter: margaretw42@… | Owner: draft-ietf-pcp-authentication@… Type: defect | Status: new Priority: major | Milestone: Component: authentication | Version: Severity: - | Resolution: Keywords: | ----------------------------+---------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Fri Oct 19 15:03:07 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0C321F85D5 for ; Fri, 19 Oct 2012 15:03: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=[AWL=0.000, BAYES_00=-2.599, 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 DzwiMQbCbL63 for ; Fri, 19 Oct 2012 15:03:07 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 407BA21F85AE for ; Fri, 19 Oct 2012 15:03:07 -0700 (PDT) Received: from localhost ([127.0.0.1]:41432 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TPKeb-0003bm-0y; Sat, 20 Oct 2012 00:02:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-pcp-authentication@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Fri, 19 Oct 2012 22:02:53 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: https://etherpad.tools.ietf.org/wg/pcp/trac/ticket/61#comment:1 Message-ID: <074.fe8ad6888a5bdd259ef8a519ce3c7f41@tools.ietf.org> References: <059.54331fe983d68240406025bfdbc8a50e@tools.ietf.org> X-Trac-Ticket-ID: 61 In-Reply-To: <059.54331fe983d68240406025bfdbc8a50e@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-authentication@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: hartmans@painless-security.com, mrw@painless-security.com, zhangdacheng@huawei.com Resent-Message-Id: <20121019220307.407BA21F85AE@ietfa.amsl.com> Resent-Date: Fri, 19 Oct 2012 15:03:07 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #61: Unsolicited reauthentication 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, 19 Oct 2012 22:03:08 -0000 #61: Unsolicited reauthentication Comment (by dthaler@…): From December 2012 webex interim (summary of discussion): Should a client need to remain reachable in order to defend/retain its mappings? Consider case where client periodically goes to sleep but wants the mapping to exist whenever it's awake. Is this scenario important? -- ----------------------------+---------------------------------------------- Reporter: margaretw42@… | Owner: draft-ietf-pcp-authentication@… Type: defect | Status: new Priority: major | Milestone: Component: authentication | Version: Severity: - | Resolution: Keywords: | ----------------------------+---------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Fri Oct 19 15:04:24 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 CFD3121F8607 for ; Fri, 19 Oct 2012 15:04:24 -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.000, BAYES_00=-2.599, 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 CndFaugkvYl2 for ; Fri, 19 Oct 2012 15:04:24 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 19D2B21F859E for ; Fri, 19 Oct 2012 15:04:24 -0700 (PDT) Received: from localhost ([127.0.0.1]:41745 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TPKfv-0004KK-Sc; Sat, 20 Oct 2012 00:04:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-pcp-authentication@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Fri, 19 Oct 2012 22:04:15 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://etherpad.tools.ietf.org/wg/pcp/trac/ticket/60#comment:2 Message-ID: <074.778d774dcbf6afb39a70c584be21a26b@tools.ietf.org> References: <059.ee19c749268bb0faec7a31e0aeaa28c8@tools.ietf.org> X-Trac-Ticket-ID: 60 In-Reply-To: <059.ee19c749268bb0faec7a31e0aeaa28c8@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-authentication@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: hartmans@painless-security.com, mrw@painless-security.com, zhangdacheng@huawei.com Resent-Message-Id: <20121019220424.19D2B21F859E@ietfa.amsl.com> Resent-Date: Fri, 19 Oct 2012 15:04:24 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #60: Loosely coupled vs. tightly coupled authentication 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, 19 Oct 2012 22:04:24 -0000 #60: Loosely coupled vs. tightly coupled authentication Comment (by dthaler@…): Summary of additional discussion from October 2012 webex interim meeting: Consider case of THIRD_PARTY where the PCP client is a different entity (e.g. web portal) from the node for which the mapping exists. -- ----------------------------+---------------------------------------------- Reporter: margaretw42@… | Owner: draft-ietf-pcp-authentication@… Type: defect | Status: new Priority: major | Milestone: Component: authentication | Version: Severity: - | Resolution: Keywords: | ----------------------------+---------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Fri Oct 19 15:09:55 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D654521F8780 for ; Fri, 19 Oct 2012 15:09:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWImZZKrlL3g for ; Fri, 19 Oct 2012 15:09:55 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id F33D321F8778 for ; Fri, 19 Oct 2012 15:09:54 -0700 (PDT) Received: from localhost ([127.0.0.1]:42102 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TPKlA-00054R-Sa; Sat, 20 Oct 2012 00:09:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-pcp-authentication@tools.ietf.org, alper.yegin@yegin.org X-Trac-Project: pcp Date: Fri, 19 Oct 2012 22:09:40 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/62 Message-ID: <059.9cf5d7c12f5da883f5db53fb2786e69b@tools.ietf.org> X-Trac-Ticket-ID: 62 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-authentication@tools.ietf.org, alper.yegin@yegin.org, 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: hartmans@painless-security.com, mrw@painless-security.com, zhangdacheng@huawei.com Resent-Message-Id: <20121019220954.F33D321F8778@ietfa.amsl.com> Resent-Date: Fri, 19 Oct 2012 15:09:54 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: [pcp] #62: Client-driven or server-driven auth retransmissions 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, 19 Oct 2012 22:09:56 -0000 #62: Client-driven or server-driven auth retransmissions Reported by Alper, Margaret, etc. PCP is currently a client-initiated request/response protocol with one-way notification. EAP is often server-driven retransmissions. This question centers around either having server-driven retransmissions or how to make EAP use client-driven retransmissions. Raw notes from Simon from October 2012 webex interim meeting: Slide 12: PANA Model - Requires server-initiated reauthentication. - Optionally to support liveness detection. - Tightly coupled. Alper: Retransmissions are driven by EAP. Not PANA's choice. Sam: No. You can design an EAP lower-layer where retransmissions are done by the client. Rafa Marin-Lopez: (did not understand) Sam: You can remove the reliability in EAP if we choose. Say PCP or PANA is responsible for retransmits. Rafa: You need retransmission. Sam: Yes but it can be done at either layer: EAP or elsewhere. Margaret: If we move it to the PCP layer, we can choose to do only client-initiated retransmission. Retransmissions don't need to be server-generated. Alper: You are reinventing ... (did not understand) Margaret: Send a description of how PANA can do only client-initiated retransmissions. -- ----------------------------+--------------------------------------------- Reporter: alper.yegin@… | Owner: draft-ietf-pcp-authentication@… Type: defect | Status: new Priority: major | Milestone: Component: authentication | Version: Severity: - | Keywords: ----------------------------+--------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Fri Oct 19 15:12:37 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608D621F8780 for ; Fri, 19 Oct 2012 15:12:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7Vkgg97MIhA for ; Fri, 19 Oct 2012 15:12:36 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 9A26921F8778 for ; Fri, 19 Oct 2012 15:12:36 -0700 (PDT) Received: from localhost ([127.0.0.1]:42258 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TPKnw-0007l2-Vq; Sat, 20 Oct 2012 00:12:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-pcp-authentication@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Fri, 19 Oct 2012 22:12:32 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://etherpad.tools.ietf.org/wg/pcp/trac/ticket/61#comment:2 Message-ID: <074.8491c8f47cdd0781b1caeb3494e5ba58@tools.ietf.org> References: <059.54331fe983d68240406025bfdbc8a50e@tools.ietf.org> X-Trac-Ticket-ID: 61 In-Reply-To: <059.54331fe983d68240406025bfdbc8a50e@tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-authentication@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: hartmans@painless-security.com, mrw@painless-security.com, zhangdacheng@huawei.com Resent-Message-Id: <20121019221236.9A26921F8778@ietfa.amsl.com> Resent-Date: Fri, 19 Oct 2012 15:12:36 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #61: Unsolicited reauthentication 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, 19 Oct 2012 22:12:37 -0000 #61: Unsolicited reauthentication Comment (by dthaler@…): Raw notes from Simon from October 2012 webex interim: Slide 10: Operational Model - PCP is request/response driven by the client with one-way notifications from server to client. Ralph: That makes client implementation much easier. Margaret: It also supports going to sleep. With implicit refresh, you need to send keepalives regularly. With PCP you can create longer lifetimes and go to sleep for much longer. That's one of the big points of PCP and we don't want to change that with auth. Alper: PANA doesn't require that. Margaret: It needs to be documented. Alper: I thought you were referring to PANA ping. Sam: There is a problem with it being policy: the client implementation needs to support all options. Alper: But the PCP client *has* to stay alive all the time to refresh the mapping. (general disagreement) Sam: How can I make a PCP client and PANA client that are not running all the time? For example a script that terminates after the request is done. Dave: Margaret summarized two examples where PCP client is no longer available: third-party case, and when you're going to sleep (e.g. laptop). -- ----------------------------+---------------------------------------------- Reporter: margaretw42@… | Owner: draft-ietf-pcp-authentication@… Type: defect | Status: new Priority: major | Milestone: Component: authentication | Version: Severity: - | Resolution: Keywords: | ----------------------------+---------------------------------------------- Ticket URL: pcp From margaretw42@gmail.com Sat Oct 20 12:58:34 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEB321F890B for ; Sat, 20 Oct 2012 12:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 MkVBaJsUWj8P for ; Sat, 20 Oct 2012 12:58:33 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3945121F8904 for ; Sat, 20 Oct 2012 12:58:33 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so1850092vcb.31 for ; Sat, 20 Oct 2012 12:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=PxDKIRwRTFBN7N1Yu24d0Z8GAzNsqpA+zDLuRBN5Nvk=; b=jfg7pOlhv/u4rlOTD7CYvFLTxphaFJg+ETwaddvpzQoplNPqt5jCPWTcX9ZuiLmOLI miUvF8hPes+iFMScCCm/JgRH9WJZzx7Py7zJ3ddi1HQ646jZFUPIBe1vQ06/63tNs3R3 ApmffetBaFTkUgqFnv08c43Rbl0Yena2nq4zmQkizgwygZCClIWZhxjXSxdUxHMq9iob /jDQEx6H5mCemVkqY1Ig4dL58SW3Mp04cRyiQC9RL548eosXjjQHH9WDOWIpz5rdzAfU W2zY3FdpjKUQP1AjTzwUAz47f9LoPvhOX7dXYDzinCnyMZwSiMFIkGAUG62OHs/SDkWG ZaBQ== Received: by 10.52.97.165 with SMTP id eb5mr5699492vdb.75.1350763112747; Sat, 20 Oct 2012 12:58:32 -0700 (PDT) Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id zz18sm4901070veb.4.2012.10.20.12.58.26 (version=SSLv3 cipher=OTHER); Sat, 20 Oct 2012 12:58:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-13-941234793 From: Margaret Wasserman In-Reply-To: <508027C4.7020702@toshiba.co.jp> Date: Sat, 20 Oct 2012 15:58:25 -0400 Message-Id: References: <9E69EEA1-221C-4670-A0D8-DEC7AA423A58@lilacglade.org> <1B4F8624-DD1B-4678-9398-9ADEEB6E0104@yegin.org> <5FA5FA56-2D65-4DDB-955F-319118C79F4A@gmail.com> <508027C4.7020702@toshiba.co.jp> To: Yoshihiro Ohba X-Mailer: Apple Mail (2.1084) Cc: pcp@ietf.org Subject: Re: [pcp] Margaret's PPT 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, 20 Oct 2012 19:58:34 -0000 --Apple-Mail-13-941234793 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 18, 2012, at 12:01 PM, Yoshihiro Ohba wrote: >=20 > To me these things are not attractive enough to define a new EAP = transport specific to PCP compared to > the benefit of reuse of a well-defined and interoperable protocol = (i.e., PANA). If we decide to use > either of the two PANA-based I-Ds for which some people already = mentioned that they are short and workable, then I believe we can = quickly get our work done. Unfortunately, I believe that the two PANA drafts are as short as they = are because they are incomplete. We will need to resolve the open = questions about what parts of PANA are and are not included when PANA is = used with PCP. I continue to believe that any of the three approaches could work. We = just need to decide, as a WG, which one is best for PCP. >> In my opinion, saying something like "use PANA", and then providing a = long list of the parts of PANA that you shouldn't use ("liveness tests", = server-initiated re-authentication, EAP-layer retransmissions, IP = address reconfiguration, session termination, etc.), or that need to be = modified to work with PCP (i.e. meaning of the flag bits, role of the = enforcement point) would be a re-invention of PANA. >=20 > I disagree. It is re-use of PANA with a specific profile of not using = some optional features. >=20 > (BTW, I never mentioned that server-iniated re-authentication, = EAP-layer retransmision and session termination should not be used.) Whether to use server-initiated re-authentication or retransmission is = one of our open architectural/design issues. I don't understand when/if session termination would ever be used with = PCP. Where do you picture it being used and why? >> If PANA is meant to be a general purpose UDP-over-EAP authentication = mechanism, as you seem to indicate, then why doesn't the PANA document = say that? Why isn't there a mechanism in PANA to make it usable by more = than one application at the same time? Why is all of this network = access-specific stuff (IP address reconfig, "liveness tests", etc.) = mixed together with the authentication mechanism? >=20 > PANA is already used as a general purpose UDP-over-EAP authentication = mechanism in ETSI MSM. What is ETSI MSM? Could you send a pointer to a document describing it? > In fact, the whole notion that we would invent a PCP-specific way to = use PANA is confusing to me, because PANA is _not_ a general-purpose = EAP-over-UDP authentication protocol -- it is a network access = authentication protocol like IEEE 802.1x... You are actually proposing = that we re-use _some parts_ of PANA for PCP, and that we re-invent the = parts of PANA that aren't suitable for use with PCP. Yes, it would be = possible to do those things, but why would that be better than using a = PCP-Specific mechanism? >>=20 >> You seem to have given up (in your proposals) on the notion that PCP = and the network access authentication portions of PANA could share a = single instance of a PAA, since you have not included a way to indicate = whether the request for authentication is coming from PCP or from a PANA = network access application. Do you actually think that by the time we = are done subsetting PANA to only include the authentication bits that = are appropriate to PCP that it will be possible to use the same code for = a PCP PAA and a PANA PAA? ...I don't. >=20 > Why not? Both PANA-based approaches use port number to distinguish = PCP authentication and > network access authentication. We talked about the PANA server needing to be co-resident with the PCP = Server (no proxies). The PCP port gets the message to the PCP Server, = not to the PANA Server. Current PANA implementations don't have any way = to receive PANA messages except on the PANA port, do they? So, either = you need to modify existing implementations or send them messages on the = PANA port... Margaret --Apple-Mail-13-941234793 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

To me these = things are not attractive enough to define a new EAP transport specific = to PCP compared to
the benefit of reuse of a well-defined and = interoperable protocol (i.e., PANA).  If we decide to use
either = of the two PANA-based I-Ds for which some people already mentioned that = they are short and workable, then I believe we can quickly get our work = done.

Unfortunately, I believe that = the two PANA drafts are as short as they are because they are = incomplete.  We will need to resolve the open questions about what = parts of PANA are and are not included when PANA is used with = PCP.

I continue to believe that any of the = three approaches could work.  We just need to decide, as a WG, = which one is best for PCP.

In my opinion, saying = something like "use PANA", and then providing a long list of the parts = of PANA that you shouldn't use ("liveness tests", server-initiated = re-authentication, EAP-layer retransmissions, IP address = reconfiguration, session termination, etc.), or that need to be modified = to work with PCP (i.e. meaning of the flag bits, role of the enforcement = point) would be a re-invention of PANA.

I disagree. =  It is re-use of PANA with a specific profile of not using some = optional features.

(BTW, I never mentioned that server-iniated = re-authentication, EAP-layer retransmision and session termination = should not be used.)

Whether to use = server-initiated re-authentication or retransmission is one of our open = architectural/design issues.

I don't understand = when/if session termination would ever be used with PCP.  Where do = you picture it being used and why?

If PANA is meant to be a = general purpose UDP-over-EAP authentication mechanism, as you seem to = indicate, then why doesn't the PANA document say that?  Why isn't = there a mechanism in PANA to make it usable by more than one application = at the same time?  Why is all of this network access-specific stuff = (IP address reconfig, "liveness tests", etc.) mixed together with the = authentication mechanism?

PANA is already used as a = general purpose UDP-over-EAP authentication mechanism in ETSI = MSM.

What is ETSI MSM?  Could = you send a pointer to a document describing = it?

In fact, the whole = notion that we would invent a PCP-specific way to use PANA is confusing = to me, because PANA is _not_ a general-purpose EAP-over-UDP = authentication protocol -- it is a network access authentication = protocol like IEEE 802.1x...  You are actually proposing that we = re-use _some parts_ of PANA for PCP, and that we re-invent the parts of = PANA that aren't suitable for use with PCP.  Yes, it would be = possible to do those things, but why would that be better than using a = PCP-Specific mechanism?

You seem to = have given up (in your proposals) on the notion that PCP and the network = access authentication portions of PANA could share a single instance of = a PAA, since you have not included a way to indicate whether the request = for authentication is coming from PCP or from a PANA network access = application.  Do you actually think that by the time we are done = subsetting PANA to only include the authentication bits that are = appropriate to PCP that it will be possible to use the same code for a = PCP PAA and a PANA PAA? ...I don't.

Why not? =  Both PANA-based approaches use port number to distinguish PCP = authentication and
network access = authentication.

We talked about the = PANA server needing to be co-resident with the PCP Server (no proxies). =  The PCP port gets the message to the PCP Server, not to the PANA = Server.  Current PANA implementations don't have any way to receive = PANA messages except on the PANA port, do they?  So, either you = need to modify existing implementations or send them messages on the = PANA = port...

Margaret


= --Apple-Mail-13-941234793-- From yoshihiro.ohba@toshiba.co.jp Sun Oct 21 03:15:56 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7122F21F846C for ; Sun, 21 Oct 2012 03:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.833 X-Spam-Level: X-Spam-Status: No, score=-6.833 tagged_above=-999 required=5 tests=[AWL=1.256, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, 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 Jz0YcUIkFZm3 for ; Sun, 21 Oct 2012 03:15:55 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 69E7C21F844C for ; Sun, 21 Oct 2012 03:15:55 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q9LAFqGt005839; Sun, 21 Oct 2012 19:15:52 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q9LAFqVw006131; Sun, 21 Oct 2012 19:15:52 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id VAA06130; Sun, 21 Oct 2012 19:15:52 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q9LAFq4o023494; Sun, 21 Oct 2012 19:15:52 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q9LAFpxM013278; Sun, 21 Oct 2012 19:15:51 +0900 (JST) Received: from [133.199.16.15] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MC80004JN636600@mail.po.toshiba.co.jp>; Sun, 21 Oct 2012 19:15:51 +0900 (JST) Date: Sun, 21 Oct 2012 19:15:39 +0900 From: Yoshihiro Ohba In-reply-to: To: Margaret Wasserman Message-id: <5083CB4B.4090900@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <9E69EEA1-221C-4670-A0D8-DEC7AA423A58@lilacglade.org> <1B4F8624-DD1B-4678-9398-9ADEEB6E0104@yegin.org> <5FA5FA56-2D65-4DDB-955F-319118C79F4A@gmail.com> <508027C4.7020702@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] Margaret's PPT 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, 21 Oct 2012 10:15:56 -0000 (2012/10/21 4:58), Margaret Wasserman wrote: > > >>> In my opinion, saying something like "use PANA", and then providing >>> a long list of the parts of PANA that you shouldn't use ("liveness >>> tests", server-initiated re-authentication, EAP-layer >>> retransmissions, IP address reconfiguration, session termination, >>> etc.), or that need to be modified to work with PCP (i.e. meaning of >>> the flag bits, role of the enforcement point) would be a >>> re-invention of PANA. >> >> I disagree. It is re-use of PANA with a specific profile of not >> using some optional features. >> >> (BTW, I never mentioned that server-iniated re-authentication, >> EAP-layer retransmision and session termination should not be used.) > > Whether to use server-initiated re-authentication or retransmission is > one of our open architectural/design issues. > > I don't understand when/if session termination would ever be used with > PCP. Where do you picture it being used and why? Session termination is to remove a PCP SA. A PCP SA can be terminated any time when either end wants to delete it and having explicit indication of session termination is better. > >>> If PANA is meant to be a general purpose UDP-over-EAP authentication >>> mechanism, as you seem to indicate, then why doesn't the PANA >>> document say that? Why isn't there a mechanism in PANA to make it >>> usable by more than one application at the same time? Why is all of >>> this network access-specific stuff (IP address reconfig, "liveness >>> tests", etc.) mixed together with the authentication mechanism? >> >> PANA is already used as a general purpose UDP-over-EAP authentication >> mechanism in ETSI MSM. > > What is ETSI MSM? Could you send a pointer to a document describing it? Visit http://www.etsi.org/website/technologies/m2m.aspx and look for ETSI M2M documents. > >> In fact, the whole notion that we would invent a PCP-specific way to >> use PANA is confusing to me, because PANA is _not_ a general-purpose >> EAP-over-UDP authentication protocol -- it is a network access >> authentication protocol like IEEE 802.1x... You are actually >> proposing that we re-use _some parts_ of PANA for PCP, and that we >> re-invent the parts of PANA that aren't suitable for use with PCP. >> Yes, it would be possible to do those things, but why would that be >> better than using a PCP-Specific mechanism? >>> >>> You seem to have given up (in your proposals) on the notion that PCP >>> and the network access authentication portions of PANA could share a >>> single instance of a PAA, since you have not included a way to >>> indicate whether the request for authentication is coming from PCP >>> or from a PANA network access application. Do you actually think >>> that by the time we are done subsetting PANA to only include the >>> authentication bits that are appropriate to PCP that it will be >>> possible to use the same code for a PCP PAA and a PANA PAA? ...I don't. >> >> Why not? Both PANA-based approaches use port number to distinguish >> PCP authentication and >> network access authentication. > > We talked about the PANA server needing to be co-resident with the PCP > Server (no proxies). The PCP port gets the message to the PCP Server, > not to the PANA Server. Current PANA implementations don't have any > way to receive PANA messages except on the PANA port, do they? So, > either you need to modify existing implementations or send them > messages on the PANA port... Yes, existing PANA implementations need to be modified and that is why the status of the two PANA drafts say "Updates: 5191 (if approved) ", and there is nothing wrong with it as long as it works. Yoshihiro Ohba > > Margaret > > From alper.yegin@yegin.org Mon Oct 22 02:53:41 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A595A21F8B3D for ; Mon, 22 Oct 2012 02:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, 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 bfJSqxRYcffl for ; Mon, 22 Oct 2012 02:53:40 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF8921F8B03 for ; Mon, 22 Oct 2012 02:53:40 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LymTv-1TLE8u1NuJ-015RqP; Mon, 22 Oct 2012 05:53:38 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Mon, 22 Oct 2012 12:53:21 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3BFA5ACF-FCE2-435A-BC22-2264AA0536F7@yegin.org> References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <9A2322BB-699A-4A71-89D5-9E3E48979272@yegin.org> <20FE79EA-9E75-49E7-9854-4AA24314FC7B@yegin.org> <36E9DFAC-47D5-4942-937F-A88CD2AD75D0@lilacglade.org> <96744887-68C7-4F9A-813E-A5563E4356E2@gmail.com> <6569B9B2-0B82-450A-A328-D023EFC732DA@yegin.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:UnbG91uz5AeLU0rx3IaHo/VzmWW6argeb5N4sTEpSp0 U+BmE9nb7S0DXNYJeqCzCfaICIPNq+0EC+aISrqLb93D/aaSI+ iL3wyP7S3pg5jZuPHkYO/hgcKb3TPs03eozmpa9IgJnszr0X6g 6EppoSBGSER/YX3diMTiIgEQyUPK6O8BMLYSz3mdaHi953NYls 6BVuJbFCBNyR/9np2Bxx8nNDhyZR+eC47x5a0hhWSHbep1EFKy 1RofzGMukcpcEYhyJ0MTV6UUPxEaf9JMQ+T1T8mIpND64JiQ9B NqEmeqEGNDaKDlnN/erzTk+fc2ohD26dZOAABxE8XCDvUNLVUY 3CpUBqC2qVMjDh6aqoZ6Orr6vbcBXPVJyQ3y8wRAu/a4g0t7gN Lilv8ynYr/3AA== Cc: pcp@ietf.org Subject: Re: [pcp] gss-eap & client-side rexmit only 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, 22 Oct 2012 09:53:41 -0000 Sam, >=20 >>>>> "Alper" =3D=3D Alper Yegin writes: >=20 > Alper> Sam, You claimed you can design an EAP lower layer that's > Alper> always client driven, and gave GSS-EAP as an example of how > Alper> you did it. >=20 > Alper> So, I had already looked at it and still don't see it how. > Alper> See below for the last email I sent on this matter which = went > Alper> unanswered. >=20 > Hi Alper. > I think I've done a number of things to try and walk you through this: >=20 > * We've had multiple discussions on the list where we discussed = whether > this was possible in the EAP spec EAP spec talks about delegating the reliable delivery from EAP layer to = the EAP-lower layer. it does not talk about turning the req/resp direction 180 degree from = network-driven to client-driven. So, I don't really find comfort in reading RFC 3748 when it comes to = supporting your approach. > * I pointed you at the gss-eap specification > * I gave textual explanations of how it works > * I went over it on the call again yesterday >=20 Honestly, we need to dig deeper. See the kind of example Yoshi gave in = his last email and let's see how such a thing works. > * During the PANA implementation discussion I pointed you at an > open-source implementation of GSS-EAP and particularly pointed you at > the part of the code that interacts with the EAP library. >=20 > Other people do seem to be following this issue at this point, so I'm = afraid we're talking past each other. > I'm sorry about that, but perhaps it would make more sense for you to = try and > work with someone else on this issue. > If there are PCP implementors on this who need to discuss this in more = detail > I'd be happy to try and help as I can. I have to admit I had missed your earlier email on CoA discussion, = sorry. Here's what you had said, and my comments: Alper> Ah, "ignoring CoA". CoA is the RADIUS' tool to generate an Alper> unsolicited message, more specifically for starting EAP Sam> I'd like to draw the WG's attention to RFC 5176, which defines COA. Sam> Section 4 explicitly mentions that COA cannot be used for starting Sam> re-authentication. =20 You are reading a special section on RADIUS-Diameter interworking. If you look at the table of attributes on page 21, you see the "CoA = request" can carry 0+ EAP message. So, the NAS (PCP client) can receive an asynchronous EAP request from = the AAA. Sam> Section 1.1 is an applicability statement explaining Sam> why COA is not standards-track because of security and semantic Sam> concerns. So, you want to pretend RADIUS CoA does not exist? It's used in the = industry, cannot ignore. Sam> As best I can tell only diameter has AAA support for = re-authentication. Sam> So, I'd like to draw our attention to RFC 4005, section 3.3 which Sam> defines rules for diameter re-authentication. That section = explicitly Sam> calls out re-authentication must be supported *if the underlying = service Sam> supports it*. That is, re-authentication is OPTIONAL for a given Sam> service like PCP, but if a given PCP server supports = re-authentication Sam> and diameter, then it needs to support re-authentication via = diameter. Sam> Section 3 of RFC 4072 (diameter over eap) confirms the guidelines = of RFC Sam> 4005 apply. I had said: > - What happens if server-side needs to re-key, extend lifetime, change = authorization, re-challenge the client?=20 > Say, the acceptor receives a RADIUS CoA with EAP-Request, what's going = to do with it? So, if you want to prohibit use of server-initiated re-auth, prohibit = use of CoA for now and for future, you need to tell us how none of the = above is ever needed. I think you have a very particular way of using EAP and AAA in mind, = nothing like the standard ways of using these protocols. We need to = understand your model, and why your model shall be the only model that = we'll ever see with PCP. Alper > Date: Thu, 18 Oct 2012 09:24:51 -0400 > In-Reply-To: (Alper = Yegin's > message of "Thu, 18 Oct 2012 09:04:43 +0300") > Message-ID: > User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) From alper.yegin@yegin.org Mon Oct 22 03:27: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 26A5121F861A for ; Mon, 22 Oct 2012 03:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, 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 vLgI0wtBwqbQ for ; Mon, 22 Oct 2012 03:27:56 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 3F60421F8518 for ; Mon, 22 Oct 2012 03:27:56 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MUHLm-1TrIIP1u2E-00RQt3; Mon, 22 Oct 2012 06:27:54 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <5FA5FA56-2D65-4DDB-955F-319118C79F4A@gmail.com> Date: Mon, 22 Oct 2012 13:27:37 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7E8413EC-7741-4C68-8DC6-A430EEA06694@yegin.org> References: <9E69EEA1-221C-4670-A0D8-DEC7AA423A58@lilacglade.org> <1B4F8624-DD1B-4678-9398-9ADEEB6E0104@yegin.org> <5FA5FA56-2D65-4DDB-955F-319118C79F4A@gmail.com> To: Margaret Wasserman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:maLW0wTP3tGOCay7W9g+Kpg6NRPKJLYRsyroDh5eEE8 3Lx8LSHgsii1NlHNAUJxzyOgZFSQ/SvicNBWgEtG0VAzgeF5Us wGtc9VAZ3qSWPjTDpXJZuy9pIup2XBN/fLocw1yZhd1lsSgkiz Ng6gg1Gv3vsP4dCNt8alWDZoO0hLX5KRvL247vjMSc9TK9Hmrt O7C8vPcsMVdW45pp16PUZHfXu/eiGXRvgbet0FM7ySdJwGTQ55 4tAP3pA1ASe6SNWsE8k5UQUxgVLN6fCbUcaN06ErP3S1452ioZ Sb/yq2dQkW21f3LqIxqOWGd/K1M2Zgl/mAlCU7vmI2tEdAD5jb OVYZernbHtevd/oVWf3WmpDthZE7IGRf4bhRZNnFGf2tTc6bBK uI66Fao8QuV4g== Cc: pcp@ietf.org Subject: [pcp] re-use vs re-invent( Re: Margaret's PPT) 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, 22 Oct 2012 10:27:57 -0000 Margaret, Yoshi gave very good answers to your question. Btw, some of your = questions are really repeat questions that are already answered. (Well, = this is bound to happen when we are a very small group of people = discussing w/o other (especially neutral) parties involved, and the = chairs not helping summarize the discussion=85. :-( What we are proposing is protocol re-use. If you are too concerned about = re-using a protocol that was originally designed for network access, you = should not be using EAP at all :-) You know, it's designed for network = access authentication with a whole lot more network access specific bits = in it. We gotta reset this discussion to what IETF should normally do: > For the given problem space, let's look around and see what we can use = out of our current IETF toolbox. We say there's PANA. You say it has extras. 1- PANA-Ping: OK, we don't need this. We can say it is not used with = PCP. (BTW, FYI, this is not network ping. This is liveness check on the = PANA SA. So, it's not a network thing, it's a security thing). 2- IP Reconfig: OK, we don't need this either. 3- Termination: This I claim is needed. If we are creating security = association, we shall also define an explicit way to purge them on = either end. This is again not network specific, this is simply part of a = complete security association management.=20 4- Re-auth: This is still under discussion. 1&2 are extremely small piece of PANA design that we can choose not to = use for PCP. 3&4 are under debate. Even in the case we decide not to use any of the 4 features above, how = can this justify tossing PANA away and redesigning its subset from = scratch?=20 So, before we abandon all the effort that went into IETF's standard = PANA, and embark the WG and beyond on designing PANA subset from = scratch, you need to convince the WG that this is really essential. = Otherwise this is just waste of IETF resources. Alper =20 On Oct 18, 2012, at 2:36 PM, Margaret Wasserman wrote: >=20 > Hi Alper, >=20 > Expressing my own opinion, not trying to represent the opinion of the = WG or any other group... >=20 > On Oct 18, 2012, at 2:22 AM, Alper Yegin wrote: >=20 >> Hi Margaret, >>=20 >>>> - Decision tree starts with an "Architectural Model Discussion". = IMO, the starting and even determining point is whether we "re-use an = existing protocol, or re-invent it".=20 >>>=20 >>> You and Yoshi covered this topic in your slides, which you presented = at length in the last meeting. I don't think it would be useful to = present them again. >>>=20 >>=20 >> Honestly, "architectural model discussion" is good for the PCP = authentication design, but won't be helpful for the PANA vs EAP-o-PCP = discussion. >=20 > I think it will be, because it helps us understand what the different = solutions will really look like... >=20 >> The reason is, since EAP-o-PCP is re-invention of PANA, = unsurprisingly the features will be the same. Then it'll simply boil = down to my question: re-use or re-invent.=20 >=20 > The PCP-specific approach is not simply a "re-invention" of PANA. = Although it was originally conceived by looking at how PANA works, there = are difference that are intended to make it more suitable for use with = PCP. These include: >=20 > - Integration with PCP messages (no need to demultiplex or fully = encapsulate another protocol, clean logging and error handling). > - No server-generated requests (i.e. no equivalent to liveness tests = or server-initiated re-authentication) > - Retransmissions are handled at the PCP level, not by the EAP upper = layer (avoiding server-generated retransmissions) >=20 > In my opinion, saying something like "use PANA", and then providing a = long list of the parts of PANA that you shouldn't use ("liveness tests", = server-initiated re-authentication, EAP-layer retransmissions, IP = address reconfiguration, session termination, etc.), or that need to be = modified to work with PCP (i.e. meaning of the flag bits, role of the = enforcement point) would be a re-invention of PANA. =20 >=20 > If PANA is meant to be a general purpose UDP-over-EAP authentication = mechanism, as you seem to indicate, then why doesn't the PANA document = say that? Why isn't there a mechanism in PANA to make it usable by more = than one application at the same time? Why is all of this network = access-specific stuff (IP address reconfig, "liveness tests", etc.) = mixed together with the authentication mechanism? >=20 > In fact, the whole notion that we would invent a PCP-specific way to = use PANA is confusing to me, because PANA is _not_ a general-purpose = EAP-over-UDP authentication protocol -- it is a network access = authentication protocol like IEEE 802.1x... You are actually proposing = that we re-use _some parts_ of PANA for PCP, and that we re-invent the = parts of PANA that aren't suitable for use with PCP. Yes, it would be = possible to do those things, but why would that be better than using a = PCP-Specific mechanism? =20 >=20 > You seem to have given up (in your proposals) on the notion that PCP = and the network access authentication portions of PANA could share a = single instance of a PAA, since you have not included a way to indicate = whether the request for authentication is coming from PCP or from a PANA = network access application. Do you actually think that by the time we = are done subsetting PANA to only include the authentication bits that = are appropriate to PCP that it will be possible to use the same code for = a PCP PAA and a PANA PAA? ...I don't. >=20 >> Again, no code, no extra in PANA. >>=20 >>> Session termination >>=20 >> If the client decides to sign-off, >> or the network decides to terminate the session (e.g, when the NAS = receives a AAA Disconnect message), then you need an explicit = termination message. >> This is needed. >=20 > There is no notion in PCP that a client would "sign off". PCP is a = UDP-based request/response protocol. There isn't anything to "sign-off" = from... >=20 >>> Server-initiated re-auth >>=20 >> (will have a separate thread for that..) >>=20 >>=20 >> PANA-Ping and IP Reconfig we agreed.=20 >>=20 >> What else?? >=20 > If you can't eliminate server-initiated re-authentication, then there = is not benefit to eliminating PANA-Ping (called "liveness tests" in the = PANA document). >=20 > Margaret >=20 >=20 From phdgang@gmail.com Mon Oct 22 03:48: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 680EF21F8554 for ; Mon, 22 Oct 2012 03:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.407 X-Spam-Level: X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, 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 9pizsP1J6a0r for ; Mon, 22 Oct 2012 03:48:31 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF9F21F8530 for ; Mon, 22 Oct 2012 03:48:30 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3071137vbb.31 for ; Mon, 22 Oct 2012 03:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bTsplkj1fIPJ6VoQBnkKcc+QSUZ1a3ZqH6PmUM2vZtM=; b=QBtLONHTvfdfDkhd6I1ioddhxrc4PJmYLcwuhEP3p7I9l8LW74Cwt6fR3VmTSKzrFI lXxUiKoB236XMeBvL1dg+2jGFgr01c6Aw1UoNtPE6Nbpm5svqnGf4wkTqgL/UPyzX+j6 iDd2lsdLfnljO1hm7qwiN2fLxqTtsSTMX7GGydbIVm+kvShT+PAGVGE+BVBIFwlDerzl 6/QoIPFgk98RV7iepRluZffTFyQlBIl4Q3uy/b9w8sOgzs2265W02t1lnqWvpDgCgkWh eJGSStvNX+S44ZTnvy3eJFJ8iTaSk4T10ALKAc1OYTqCn8n/VpZ5rQzXxr7MqWBIoCSU II3w== MIME-Version: 1.0 Received: by 10.52.23.199 with SMTP id o7mr11169012vdf.129.1350902910351; Mon, 22 Oct 2012 03:48:30 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Mon, 22 Oct 2012 03:48:30 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Oct 2012 18:48:30 +0800 Message-ID: From: GangChen To: "Prashanth Patil (praspati)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pcp@ietf.org" Subject: Re: [pcp] FW: New Version Notification for draft-rpcw-pcp-pmipv6-serv-discovery-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, 22 Oct 2012 10:48:35 -0000 2012/10/18, Prashanth Patil (praspati) : > Hi Geng, > Thanks for the review. > Comments inline.. > > On 17/10/12 1:30 PM, "GangChen" wrote: > >>Hello authors, >> >>Few questions are below trying to make further clarifications. >> >>1. I have a little confusion on the statement >>" If the dynamic outbound mapping is for the local access network then >> there are two cases to consider - In the first case where there is a >> nested NAT[I-D.penno-pcp-nested-nat], the mobile access gateway will >> function as both PCP server and PCP proxy forwarding the accepted PCP >> request to CGN PCP server. In the second case, where there is no >> CGN, mobile access gateway will function as a PCP server in the local >> access network. >>" >>When the traffic is heading to the NAT in local access network, there >>is no NAT processing in homenet. Wondering to know what is the case of >>nested NAT you refer to? > > Yes, there shouldn=B9t be a case for nested NAT as per RFC5844. We'll > correct this. > > >> >>2. What is the goal of designing mobility options? I read the Section >>3, it seems a smart PCP proxy is sufficient to handle the traffic >>dispatch? what the consideration to this option? > > Mobility options are required to convey domain name of the PCP Server > within the home network to be used by the MAG. The MAG is unaware of the > PCP server details within various home networks and this option allows PC= P > information to be propagated to the local network from the home network > via PMIP signaling. OK. Make sense. Thanks > >> >> >>3. How do you handle the case of IPv6 offloading? > > PMIPv6 for offloading does not assume NPTv6 > (http://tools.ietf.org/html/draft-ietf-netext-pmipv6-sipto-option-06#sect= io > n-1) so the PCP server is only for firewall. I didn't follow Netext. But, draft-ietf-netext-pmipv6-sipto-option didn't say the words of assumption of "no NPTv6". Whereas, the abstract stated "This specification defines a mechanism and a related mobility option for carrying IPv4 Offload traffic selectors between a mobile access". It seems not considering IPv6 offload at all. Therefore, I'm not sure NPTv6 should be excluded. > For IPv6, as the MN can be assigned an IPv6 prefix from the access networ= k > in addition to the IPv6 prefix from the home network, thereby allowing th= e > MN to use an IPv6 address from the access network for traffic that needs > to be offloaded in the access network. This scenario is similar to IPv6 > multihoming and > http://tools.ietf.org/html/draft-patil-pcp-multihoming-00#section-3 > explains PCP client behavior in such cases. > > > We intend to add IPv6 details in the next revision. thanks BRs Gang > -Prashanth > > > >> >>Best Regards >> >>Gang >> >> >>2012/9/17, Prashanth Patil (praspati) : >>> This is an updated version after accommodating review comments. >>> >>> Comments and suggestions welcome. >>> >>> -Prashanth >>> >>> >>> >>>> >>>>On 31/08/12 8:53 PM, "internet-drafts@ietf.org" >>>> >>>>wrote: >>>> >>>>> >>>>>A new version of I-D, draft-rpcw-pcp-pmipv6-serv-discovery-01.txt >>>>>has been successfully submitted by Prashanth Patil and posted to the >>>>>IETF repository. >>>>> >>>>>Filename: draft-rpcw-pcp-pmipv6-serv-discovery >>>>>Revision: 01 >>>>>Title: PCP Server Discovery with IPv4 traffic offload for Proxy >>>>>Mobile >>>>>IPv6 >>>>>Creation date: 2012-08-31 >>>>>WG ID: Individual Submission >>>>>Number of pages: 13 >>>>>URL: >>>>>http://www.ietf.org/internet-drafts/draft-rpcw-pcp-pmipv6-serv-discove= r >>>>>y- >>>>>0 >>>>>1.txt >>>>>Status: >>>>>http://datatracker.ietf.org/doc/draft-rpcw-pcp-pmipv6-serv-discovery >>>>>Htmlized: >>>>>http://tools.ietf.org/html/draft-rpcw-pcp-pmipv6-serv-discovery-01 >>>>>Diff: >>>>>http://www.ietf.org/rfcdiff?url2=3Ddraft-rpcw-pcp-pmipv6-serv-discover= y-0 >>>>>1 >>>>> >>>>>Abstract: >>>>> This document proposes a solution to PCP Server Discovery problems >>>>>in >>>>> Proxy Mobile IPv6 (PMIPv6) networks when both home network traffic >>>>> and traffic off-loaded to local access network require traversing a >>>>> gateway implementing NAT and/or Firewall. This draft proposes >>>>> enhancements to DHCPv4 Relay Agent by introducing a new sub-option >>>>> under DHCPv4 Relay Option and to PMIPv6 signaling through additiona= l >>>>> options to Proxy Binding Update/Acknowledgement messages. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>The IETF Secretariat >>>>> >>>> >>> >>> _______________________________________________ >>> pcp mailing list >>> pcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcp >>> > > From yoshihiro.ohba@toshiba.co.jp Mon Oct 22 06:30:37 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A2F21F8B82 for ; Mon, 22 Oct 2012 06:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.876 X-Spam-Level: X-Spam-Status: No, score=-6.876 tagged_above=-999 required=5 tests=[AWL=1.213, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, 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 PNPg6O5tv3Mi for ; Mon, 22 Oct 2012 06:30:36 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 4F86221F8B7E for ; Mon, 22 Oct 2012 06:30:35 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q9MDUV17018951 for ; Mon, 22 Oct 2012 22:30:31 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q9MDUVhf002566 for pcp@ietf.org; Mon, 22 Oct 2012 22:30:31 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id YAA02565; Mon, 22 Oct 2012 22:30:31 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q9MDUPZR013890 for ; Mon, 22 Oct 2012 22:30:30 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q9MDUPpG029398; Mon, 22 Oct 2012 22:30:25 +0900 (JST) Received: from [133.199.17.147] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MCA006LDQUKFO90@mail.po.toshiba.co.jp> for pcp@ietf.org; Mon, 22 Oct 2012 22:30:25 +0900 (JST) Date: Mon, 22 Oct 2012 22:30:21 +0900 From: Yoshihiro Ohba In-reply-to: <20121019080550.15043.98554.idtracker@ietfa.amsl.com> To: pcp@ietf.org Message-id: <50854A6D.5060801@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <20121019080550.15043.98554.idtracker@ietfa.amsl.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Subject: Re: [pcp] I-D Action: draft-ietf-pcp-authentication-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, 22 Oct 2012 13:30:37 -0000 I have some comments in Section 4 of pcp-authenication-01. [1] The following statement is incorrect because both PANA approaches use PCP port number to indicate that the PANA session was being used for PCP authentication. The sentence should be removed. "For the first approach [I-D.ohba-pcp-pana-encap], we would define an AVP for PANA to indicate that the PANA session was being used for PCP authentication, not for network access purposes. " [2] I fail to see in the following sentence what the technical problem with the existence of overlapping fields is. "The first approach introduces little change on PANA. Howerer, there are criticisms about the existence of overlapping fields on the PANA and PCP headers that need to be check for consistency." [3] The 2nd sentence of the following text should be removed for the same reason as commented in [1]. Also, depending on resolution of comment [2], the 1st sentence may also need be removed. "Compared with the first approach, the second approach does not have this problem. However, addition work needs to be done to help an PCP implementation to distinguish a PANA message from a PCP message." Regards, Yoshihiro Ohba (2012/10/19 17:05), internet-drafts@ietf.org wrote: > 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) Authentication Mechanism > Author(s) : Margaret Wasserman > Sam Hartman > Dacheng Zhang > Filename : draft-ietf-pcp-authentication-01.txt > Pages : 19 > Date : 2012-10-19 > > Abstract: > An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to > flexibly manage the IP address and port mapping information on > Network Address Translators (NATs) or firewalls, to facilitate > communications with remote hosts. However, the un-controlled > generation or deletion of IP address mappings on such network devices > may cause security risks and should be avoided. In some cases the > client may need to prove that it is authorized to modify, create or > delete PCP mappings. This document proposes an in-band > authentication mechanism for PCP that can be used in those cases. > The Extensible Authentication Protocol (EAP) is used to perform > authentication between PCP devices. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pcp-authentication > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-pcp-authentication-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-authentication-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 simon.perreault@viagenie.ca Mon Oct 22 06:31:03 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C8521F8B8A for ; Mon, 22 Oct 2012 06:31:01 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MerDGvl5rnHq for ; Mon, 22 Oct 2012 06:31: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 8D61821F8B13 for ; Mon, 22 Oct 2012 06:30:58 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8c54:f483:a6fd:5c0]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B0FCE44A83 for ; Mon, 22 Oct 2012 09:30:53 -0400 (EDT) Message-ID: <50854A8D.8020709@viagenie.ca> Date: Mon, 22 Oct 2012 09:30:53 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: pcp@ietf.org References: <059.ee19c749268bb0faec7a31e0aeaa28c8@tools.ietf.org> In-Reply-To: <059.ee19c749268bb0faec7a31e0aeaa28c8@tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] #60: Loosely coupled vs. tightly coupled authentication 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, 22 Oct 2012 13:31:03 -0000 Le 2012-10-19 17:47, pcp issue tracker a écrit : > #60: Loosely coupled vs. tightly coupled authentication > > Loosely coupled: > – Authentication needed only at the time of a request, to create/modify a > mapping. > – Authorization done separately, using the same mechanism as in non- > authenticated PCP > • Mappings are removed when authorization is revoked > – Mapping lifetime is not tied to authentication lifetime > Tightly coupled: > – Authentication and authorization are performed using the same > mechanism, or there is a link between them > – Mapping lifetime is tied to authentication lifetime > • Mappings are removed when keys expire OR authorization is revoke May I start a thread about this? From the interim discussion, it appears clear to me that we need loosely coupled auth. I don't know if we need tightly coupled auth in addition. So far I can't think of any use case for it. 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 Tue Oct 23 01:15:28 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787FB21F85A3 for ; Tue, 23 Oct 2012 01:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, 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 oSteGeAyf3Oj for ; Tue, 23 Oct 2012 01:15:27 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id BC8D521F855E for ; Tue, 23 Oct 2012 01:15:25 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MNaHi-1TWc311Oyw-007cpI; Tue, 23 Oct 2012 04:15:24 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <50854A8D.8020709@viagenie.ca> Date: Tue, 23 Oct 2012 11:15:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7302290F-C708-48E2-AF3E-38AEE21A74A3@yegin.org> References: <059.ee19c749268bb0faec7a31e0aeaa28c8@tools.ietf.org> <50854A8D.8020709@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:stL1+fhFwahv78MJ5Gh3GfV8wGiBX8aT+xOHykD5g6Y Cz09ZJZjls6qE0KrIFYVui/+RuecIfacO0+zw2r+g9SM2/To6g FPJ7FJStwPw62j6ctBBoIaugXyervilk4Etqd/DMZdpW/5EEa/ 5xrfsiHKe+NzCmFWh6Ss4Dzygofz2ORSS7aea5hAfXr28P38kL AhCY+dG69gXUnFdSZsFHLT44ACey2GSp1Kx3sKNa8hvEzJFBep J9+K6FF68QFrK4p/wfwSB26BeRVps7HZyfhpqdaA4+kpjvNVsj d4hgkuxqPGedcsA+fpFyay3J0PFsBreTYAIWcRoOrAIkhX3eXp I1t76+v9mLFCofVpcecKD0b6VU5gxop7yR6S/8UqZLxjNsJJGu 4yMXyLS6n13iA== Cc: pcp@ietf.org Subject: Re: [pcp] #60: Loosely coupled vs. tightly coupled authentication 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, 23 Oct 2012 08:15:28 -0000 On Oct 22, 2012, at 4:30 PM, Simon Perreault wrote: > Le 2012-10-19 17:47, pcp issue tracker a =E9crit : >> #60: Loosely coupled vs. tightly coupled authentication >>=20 >> Loosely coupled: >> =96 Authentication needed only at the time of a request, to = create/modify a >> mapping. >> =96 Authorization done separately, using the same mechanism as in = non- >> authenticated PCP >> =95 Mappings are removed when authorization is revoked >> =96 Mapping lifetime is not tied to authentication lifetime >> Tightly coupled: >> =96 Authentication and authorization are performed using the same >> mechanism, or there is a link between them >> =96 Mapping lifetime is tied to authentication lifetime >> =95 Mappings are removed when keys expire OR authorization is = revoke >=20 > May I start a thread about this? >=20 > =46rom the interim discussion, it appears clear to me that we need = loosely coupled auth. >=20 > I don't know if we need tightly coupled auth in addition. So far I = can't think of any use case for it. >=20 Hi, Comments on = http://www.ietf.org/mail-archive/web/pcp/current/msg02474.html would be = appreciated. We need to go deeper into why we want it certain way and what it means = in terms of authentication and authorization. I captured those aspects in that aforementioned email. Alper > 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 Tue Oct 23 06:15: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 325D321F86B5 for ; Tue, 23 Oct 2012 06:15:12 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QipCUtYEwiWz for ; Tue, 23 Oct 2012 06:15:11 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 44D2B21F86AB for ; Tue, 23 Oct 2012 06:15:11 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b59f:32fb:2de6:edf8]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B413C4128A for ; Tue, 23 Oct 2012 09:15:10 -0400 (EDT) From: Simon Perreault To: pcp@ietf.org Date: Tue, 23 Oct 2012 09:15:10 -0400 Message-ID: <3644979.ovSNnDyzia@porto.nomis80.org> Organization: =?UTF-8?B?VmlhZ8Opbmll?= User-Agent: KMail/4.9.2 (Linux/3.6.2-4.fc17.x86_64; KDE/4.9.2; x86_64; ; ) In-Reply-To: <67054721-2DED-4023-89E2-F8E3692A6117@yegin.org> References: <67054721-2DED-4023-89E2-F8E3692A6117@yegin.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Subject: Re: [pcp] Loosely/tightly coupled auth/authz 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, 23 Oct 2012 13:15:12 -0000 Le 18 octobre 2012, Alper Yegin a =C3=A9crit : > Before I enter an in-depth discussion, let me say whether we decide t= o do it > one way or the other does not have any impact on the PANA vs. EAP-o-P= CP > discussion. PANA can support both. >=20 > Having said that, PCP WG still needs to decide which way to go, so le= t's > discuss that below. >=20 > Margaret, the reason it took us so long to understand what you are tr= ying to > do is because of the terminology. Your PPTs are referring to authenti= cation > and authorization. Not sure if you are aware but authentication of wh= at and > authorization of what are extremely important at this level of discus= sion. > Let's be very specific. >=20 >=20 > EAP (in conjunction with its EAP lower layer) authenticates the ident= ity of > the end-point ("joe@domain", or more specifically "a device used by > joe@domain") Along with that there is an authorization of the request= ed > service (PCP in this case). The final response from the AAA server to= the > NAS (PCP server in this case) not only says "yes, this is joe", but a= lso > says "joe is allowed to use PCP service"). In fact, it may not even s= ay > "yes, this is joe". That info may not matter to the NAS. And its disc= losure > to the NAS may even be prohibited due to privacy concerns. AAA server= tells > NAS "yes, this fellow is allowed to use PCP service". >=20 > This is what centralized authentication and authorization servers, AA= A > servers, do. At that level, in a sense, authentication and authorizat= ion is > coupled. >=20 > Along with that authorization comes in a session lifetime, telling th= e NAS > for who long this authorized service is good for. AAA is saying "this= > fellow is allowed to use PCP service for 1 hour." It can say further = things > too: stop the service after 1 hour, or re-auth before the end-of 1 ho= ur, > etc. >=20 > This is how the current EAP and AAA-based architectures work. I'm following you up to here. > Now, people said they'd like the PCP server (the NAS) set the session= > lifetime. I don't think anyone said that. Auth lifetime is different from mapping= =20 lifetime. The AAA server is responsible for auth lifetime. The NAT is=20= responsible for the mapping lifetime. > NAS can reduce the lifetime it received from the AAA server, but > extending the lifetime w/o AAA server's involvement would be a proble= m. > Because, the "centralized" authority sets the upper limit. This is th= e > whole reason of using a centralized AAA server. Second A is for > Authorization. >=20 >=20 > You sound like you want to use AAA server for Authentication, but not= for > Authorization. If this is what you want to do, please tell us why you= want > to do it that way. This is unusual. >=20 >=20 > Secondly, putting aside where the "PCP authorization lifetime" comes = from, > you folks want to decouple EAP session lifetime with the PCP lifetime= . >=20 > What's the benefit of this de-coupling? Because PCP is just one way to manipulate NAT mappings. Others include:= - ordinary traffic using the mapping - NAT administration interface - other mapping control protocols that may be enabled simultaneously wi= th PCP > Why would you want to toss away your EAP session when the PCP state i= s still > up? There is no such "PCP state". There is only NAT state, which is indepen= dent=20 from PCP. > Tossing away would force you to re-run EAP from scratch if the client= > needs to process any other PCP packet meanwhile. Unnecessary overhead= . >=20 >=20 > At the end of the day, here are the three lifetimes we could be talki= ng > about: >=20 > 1- Authorized service lifetime AAA tells the NAS (PCP server). > 2- Effective lifetime set on the state created for the authorized ser= vice. > (mapping lifetime) 3- EAP session lifetime (MSK and its children's > lifetime) >=20 >=20 > In current EAP and AAA practice, these are all the same values. > If you want to deviate from that, we need to understand why. Because = that > deviation is going to complicate a simple system. IMHO it is technically impossible not to decouple mapping lifetime from= the=20 rest. Because that's how NAT works today, and you can't change that. 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 hartmans@painless-security.com Tue Oct 23 06:19:03 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825E321F8464 for ; Tue, 23 Oct 2012 06:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.806 X-Spam-Level: X-Spam-Status: No, score=0.806 tagged_above=-999 required=5 tests=[AWL=3.405, 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 k4sLLca403vH for ; Tue, 23 Oct 2012 06:19:02 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id AA3F721F8705 for ; Tue, 23 Oct 2012 06:19:02 -0700 (PDT) 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 509BA2010D; Tue, 23 Oct 2012 09:18:38 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D74A8412A; Tue, 23 Oct 2012 09:18:58 -0400 (EDT) From: Sam Hartman To: Simon Perreault References: <059.ee19c749268bb0faec7a31e0aeaa28c8@tools.ietf.org> <50854A8D.8020709@viagenie.ca> Date: Tue, 23 Oct 2012 09:18:58 -0400 In-Reply-To: <50854A8D.8020709@viagenie.ca> (Simon Perreault's message of "Mon, 22 Oct 2012 09:30:53 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: pcp@ietf.org Subject: Re: [pcp] #60: Loosely coupled vs. tightly coupled authentication 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, 23 Oct 2012 13:19:03 -0000 >>>>> "Simon" == Simon Perreault writes: Simon> Le 2012-10-19 17:47, pcp issue tracker a écrit : >> #60: Loosely coupled vs. tightly coupled authentication >> >> Loosely coupled: – Authentication needed only at the >> time of a request, to create/modify a mapping. – >> Authorization done separately, using the same mechanism as in >> non- authenticated PCP • Mappings are removed when >> authorization is revoked – Mapping lifetime is not >> tied to authentication lifetime Tightly coupled: – >> Authentication and authorization are performed using the same >> mechanism, or there is a link between them – Mapping >> lifetime is tied to authentication lifetime • Mappings >> are removed when keys expire OR authorization is revoke Simon> May I start a thread about this? Simon> From the interim discussion, it appears clear to me that we Simon> need loosely coupled auth. I also support loosely coupled auth as a strong requirement for PCP. Simon> I don't know if we need tightly coupled auth in addition. So Simon> far I can't think of any use case for it. I can't really think of a use case for tightly coupled auth in PCP either. However, I'm reasonably sure that you can implement tightly-coupled auth entirely in terms of existing PCP facilities and loosly coupled auth. Here's how. 1) A server is free to base mapping lifetimes on the authentication lifetime. If it does, then it can communicate those lifetimes to the client in PCP responses. 2) If a server chooses to bind authentication lifetime to mapping lifetime then a client will begin to try and reset the mappings halfway through their lifetime. The server has an option at that point. It can either ask the client to re-authenticate or renew with the existing lifetime. Presumably if it renews at the existing lifetime the client will try to renew the mapping at 75% of the original lifetime. By that point it seems like a server that wants to bind authentication lifetime to mapping lifetime should force a re-authentication. When the server forces the re-authentication the lifetime will be extended assuming the re-authentication is successful and the lifetime coming back from AAA is extended. (If AAA is clamping down the lifetime because for example the account is expiring, then the lifetime is a hard limit and nothing will increase it.) The above is enough to support RADIUS without COA, which is a fairly common deployment. COA allows a RADIUS server to change the authorization after the fact. For example, a RADIUS server can decrease the authorization lifetime. PCP supports that too; a PCP server can send an update to an existing mapping. Not all clients will respond to that. That's an explicit decision of PCP. If we wanted we could have (or could mandate for the future) that clients MUST support and process ongoing updates from the server. Right now, I believe that's a SHOULD. However COA is at best a MAY; I'm fairly sure that for RADIUS it is not even a standards-track protocol. So, I think that PCP's decisions in this space are similar to the AAA community's. Some environments need COA, we're going to have the feature present, but some deployments will be entirely fine without it. So, existing PCP mechanisms are sufficient for plain RADIUS and for RADIUS with COA. Diameter has another feature: server-initiated re-authentication. That's its own issue so I'll respond there. My conclusion though is that the PCP layer already supports all the things you'd need for tightly coupled auth. I don't think we want to rip that out of PCP. So, I think it is better to support this functionality at only one layer. For that reason I strongly prefer that we support this functionality using the existing mechanisms for implementations that find it useful. I prefer that we have no explicit tightly-coupled auth support in our authentication protocol or in PCP, because I believe it is redundant to existing functionality and overly complex. From adurand@juniper.net Tue Oct 23 12:13:34 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA2611E80EE for ; Tue, 23 Oct 2012 12:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, 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 jg8g81kt4+Qs for ; Tue, 23 Oct 2012 12:13:34 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id B7B4F11E80EA for ; Tue, 23 Oct 2012 12:13:33 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUIbsXVQi3WWV2Ob4YqiR+lJEiPHAlKIz@postini.com; Tue, 23 Oct 2012 12:13:33 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 23 Oct 2012 12:12:50 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 23 Oct 2012 12:12:49 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.185) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 23 Oct 2012 12:18:59 -0700 Received: from mail82-co1-R.bigfish.com (10.243.78.226) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Tue, 23 Oct 2012 19:12:45 +0000 Received: from mail82-co1 (localhost [127.0.0.1]) by mail82-co1-R.bigfish.com (Postfix) with ESMTP id A02D68A0146 for ; Tue, 23 Oct 2012 19:12:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 0 X-BigFish: PS0(zzzz1202h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h1155h) Received: from mail82-co1 (localhost.localdomain [127.0.0.1]) by mail82-co1 (MessageSwitch) id 1351019563165589_5237; Tue, 23 Oct 2012 19:12:43 +0000 (UTC) Received: from CO1EHSMHS021.bigfish.com (unknown [10.243.78.241]) by mail82-co1.bigfish.com (Postfix) with ESMTP id 265D27C0047; Tue, 23 Oct 2012 19:12:43 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS021.bigfish.com (10.243.66.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 23 Oct 2012 19:12:42 +0000 Received: from BL2PRD0510MB386.namprd05.prod.outlook.com ([169.254.2.166]) by BL2PRD0510HT002.namprd05.prod.outlook.com ([10.255.100.37]) with mapi id 14.16.0224.004; Tue, 23 Oct 2012 19:12:40 +0000 From: Alain Durand To: "pcp@ietf.org" Thread-Topic: Stepping down as wg chair Thread-Index: AQHNsVJelhTZSmyhdUGRCnyxUbaFVA== Date: Tue, 23 Oct 2012 19:12:39 +0000 Message-ID: <82256834F867D44BBB8E49E40D5448BB02FF4B@BL2PRD0510MB386.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.100.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <9EB144E200F9004883E1E7D0C7CEA8C6@namprd05.prod.outlook.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 X-FOPE-CONNECTOR: Id%12219$Dn%MICROSOFT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: Ralph Droms Subject: [pcp] Stepping down as wg chair 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, 23 Oct 2012 19:13:34 -0000 Dear wg, Effective immediately, I'm stepping down from chairing the PCP wg. I'd like to express my thanks and appreciations to all of you that have bee= n working with me on this project since its inception a few years ago. Ralph Droms, the wg responsible ADs, will announce a replacement shortly. Alain.= From praspati@cisco.com Tue Oct 23 16:53:18 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0D411E80FE for ; Tue, 23 Oct 2012 16:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.722 X-Spam-Level: X-Spam-Status: No, score=-9.722 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 SyZPl4U0EqAy for ; Tue, 23 Oct 2012 16:53:17 -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 A0C6A11E80A4 for ; Tue, 23 Oct 2012 16:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8178; q=dns/txt; s=iport; t=1351036397; x=1352245997; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=16C7BfOoYlADrfQBPwsfu8jMS6paU1hJopB4pfqTDAQ=; b=FAybMq5fUE1+ukDNCpSDXvN6IY71fttqe+zNm2SUmJpHJcjZUjej2ciG Xj4ts7SDMV77iLObrgzGrXOP6YY4nYl81hZocmAwXSsHcsUb8yCB89KL+ pJcuJerCWArNw9csMFnwBK6aSUwPmhrKQZcVlItv7RvvUSx1n3sCLo9B+ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJQsh1CtJV2a/2dsb2JhbABEhhS6aYECgQiCHgEBAQMBAQEBDwEhOgkCBQ0BCBgEBiIEHwYLHAkCBA4FCAESB4dQAwkGC5sMjRoFgj2GRQ2JVIEbiV6BAYUtN2ADlB2CbIoSgyWBa4JvgWMXHg X-IronPort-AV: E=Sophos;i="4.80,637,1344211200"; d="scan'208";a="134688534" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 23 Oct 2012 23:53:17 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9NNrGJt031304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 23:53:16 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.203]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 18:53:16 -0500 From: "Prashanth Patil (praspati)" To: GangChen Thread-Topic: [pcp] FW: New Version Notification for draft-rpcw-pcp-pmipv6-serv-discovery-01.txt Thread-Index: AQHNsELNiiZhyeiN+EOdguHxGNsWJJfIQqAA Date: Tue, 23 Oct 2012 23:53:16 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.164.161] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--45.482400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="euc-kr" Content-ID: <5FAF2DEEF8FFDD449E42D7603E609BCB@cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] FW: New Version Notification for draft-rpcw-pcp-pmipv6-serv-discovery-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, 23 Oct 2012 23:53:18 -0000 SGkgR2FuZywNCg0KPiBJIGRpZG4ndCBmb2xsb3cgTmV0ZXh0LiBCdXQsIGRyYWZ0LWlldGYtbmV0 ZXh0LXBtaXB2Ni1zaXB0by1vcHRpb24NCj4gZGlkbid0IHNheSB0aGUgd29yZHMgb2YgYXNzdW1w dGlvbiBvZiAibm8gIE5QVHY2Ii4gV2hlcmVhcywgdGhlDQo+IGFic3RyYWN0IHN0YXRlZCAiVGhp cyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYSBtZWNoYW5pc20gYW5kIGEgcmVsYXRlZA0KPiBtb2Jp bGl0eSBvcHRpb24gZm9yIGNhcnJ5aW5nIElQdjQgT2ZmbG9hZCB0cmFmZmljIHNlbGVjdG9ycyBi ZXR3ZWVuIGENCj4gbW9iaWxlIGFjY2VzcyIuIEl0IHNlZW1zIG5vdCBjb25zaWRlcmluZyBJUHY2 IG9mZmxvYWQgYXQgYWxsLg0KPiBUaGVyZWZvcmUsIEknbSBub3Qgc3VyZSBOUFR2NiBzaG91bGQg YmUgZXhjbHVkZWQuDQoNCg0KVGhpcyBhc3N1bXB0aW9uIGlzIGJhc2VkIG9uIHRoZSBmb2xsb3dp bmcgdGV4dCBmcm9tIGRyYWZ0DQpkcmFmdC1pZXRmLW5ldGV4dC1wbWlwdjYtc2lwdG8tb3B0aW9u IChTZWN0aW9uIDE6IEludHJvZHVjdGlvbikgOg0KDQoiVGhlcmUgYXJlIGJldHRlciB3YXlzIHRv IGFkZHJlc3MgdGhlIG9mZmxvYWQgcHJvYmxlbSBmb3IgSVB2NiBhbmQgd2l0aA0KdGhlIGdvYWwg bm90IHRvIGNyZWF0ZSBOQVQ2NiByZXF1aXJlbWVudCwgdGhpcyBzcGVjaWZpY2F0aW9uIHRoZXJl Zm9yZQ0KZG9lcyBub3Qgc3VwcG9ydCB0cmFmZmljIG9mZmxvYWQgc3VwcG9ydCBmb3IgSVB2NiBm bG93cy4iDQoNClRoaXMgd2FzIGRpc2N1c3NlZCBpbiBQTUlQdjYgKHNlYXJjaCBmb3IgJ05BVDY2 IGdhdGV3YXknKQ0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGV4dC9j dXJyZW50L21zZzAyMzEwLmh0bWwNCg0KDQpUaGFua3MsDQpQcmFzaGFudGgNCg0KT24gMjIvMTAv MTIgNDoxOCBQTSwgIkdhbmdDaGVuIiA8cGhkZ2FuZ0BnbWFpbC5jb20+IHdyb3RlOg0KDQo+MjAx Mi8xMC8xOCwgUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSkgPHByYXNwYXRpQGNpc2NvLmNvbT46 DQo+PiBIaSBHZW5nLA0KPj4gVGhhbmtzIGZvciB0aGUgcmV2aWV3Lg0KPj4gQ29tbWVudHMgaW5s aW5lLi4NCj4+DQo+PiBPbiAxNy8xMC8xMiAxOjMwIFBNLCAiR2FuZ0NoZW4iIDxwaGRnYW5nQGdt YWlsLmNvbT4gd3JvdGU6DQo+Pg0KPj4+SGVsbG8gYXV0aG9ycywNCj4+Pg0KPj4+RmV3IHF1ZXN0 aW9ucyBhcmUgYmVsb3cgdHJ5aW5nIHRvIG1ha2UgZnVydGhlciBjbGFyaWZpY2F0aW9ucy4NCj4+ Pg0KPj4+MS4gSSBoYXZlIGEgbGl0dGxlIGNvbmZ1c2lvbiBvbiB0aGUgc3RhdGVtZW50DQo+Pj4i ICAgSWYgdGhlIGR5bmFtaWMgb3V0Ym91bmQgbWFwcGluZyBpcyBmb3IgdGhlIGxvY2FsIGFjY2Vz cyBuZXR3b3JrIHRoZW4NCj4+PiAgIHRoZXJlIGFyZSB0d28gY2FzZXMgdG8gY29uc2lkZXIgLSBJ biB0aGUgZmlyc3QgY2FzZSB3aGVyZSB0aGVyZSBpcyBhDQo+Pj4gICBuZXN0ZWQgTkFUW0ktRC5w ZW5uby1wY3AtbmVzdGVkLW5hdF0sIHRoZSBtb2JpbGUgYWNjZXNzIGdhdGV3YXkgd2lsbA0KPj4+ ICAgZnVuY3Rpb24gYXMgYm90aCBQQ1Agc2VydmVyIGFuZCBQQ1AgcHJveHkgZm9yd2FyZGluZyB0 aGUgYWNjZXB0ZWQgUENQDQo+Pj4gICByZXF1ZXN0IHRvIENHTiBQQ1Agc2VydmVyLiAgSW4gdGhl IHNlY29uZCBjYXNlLCB3aGVyZSB0aGVyZSBpcyBubw0KPj4+ICAgQ0dOLCBtb2JpbGUgYWNjZXNz IGdhdGV3YXkgd2lsbCBmdW5jdGlvbiBhcyBhIFBDUCBzZXJ2ZXIgaW4gdGhlIGxvY2FsDQo+Pj4g ICBhY2Nlc3MgbmV0d29yay4NCj4+PiINCj4+PldoZW4gdGhlIHRyYWZmaWMgaXMgaGVhZGluZyB0 byB0aGUgTkFUIGluIGxvY2FsIGFjY2VzcyBuZXR3b3JrLCB0aGVyZQ0KPj4+aXMgbm8gTkFUIHBy b2Nlc3NpbmcgaW4gaG9tZW5ldC4gV29uZGVyaW5nIHRvIGtub3cgd2hhdCBpcyB0aGUgY2FzZSBv Zg0KPj4+bmVzdGVkIE5BVCB5b3UgcmVmZXIgdG8/DQo+Pg0KPj4gWWVzLCB0aGVyZSBzaG91bGRu qfZ0IGJlIGEgY2FzZSBmb3IgbmVzdGVkIE5BVCBhcyBwZXIgUkZDNTg0NC4gV2UnbGwNCj4+IGNv cnJlY3QgdGhpcy4NCj4+DQo+Pg0KPj4+DQo+Pj4yLiBXaGF0IGlzIHRoZSBnb2FsIG9mIGRlc2ln bmluZyBtb2JpbGl0eSBvcHRpb25zPyBJIHJlYWQgdGhlIFNlY3Rpb24NCj4+PjMsIGl0IHNlZW1z IGEgc21hcnQgUENQIHByb3h5IGlzIHN1ZmZpY2llbnQgdG8gaGFuZGxlIHRoZSB0cmFmZmljDQo+ Pj5kaXNwYXRjaD8gd2hhdCB0aGUgY29uc2lkZXJhdGlvbiB0byB0aGlzIG9wdGlvbj8NCj4+DQo+ PiBNb2JpbGl0eSBvcHRpb25zIGFyZSByZXF1aXJlZCB0byBjb252ZXkgZG9tYWluIG5hbWUgb2Yg dGhlIFBDUCBTZXJ2ZXINCj4+IHdpdGhpbiB0aGUgaG9tZSBuZXR3b3JrIHRvIGJlIHVzZWQgYnkg dGhlIE1BRy4gVGhlIE1BRyBpcyB1bmF3YXJlIG9mIHRoZQ0KPj4gUENQIHNlcnZlciBkZXRhaWxz IHdpdGhpbiB2YXJpb3VzIGhvbWUgbmV0d29ya3MgYW5kIHRoaXMgb3B0aW9uIGFsbG93cw0KPj5Q Q1ANCj4+IGluZm9ybWF0aW9uIHRvIGJlIHByb3BhZ2F0ZWQgdG8gdGhlIGxvY2FsIG5ldHdvcmsg ZnJvbSB0aGUgaG9tZSBuZXR3b3JrDQo+PiB2aWEgUE1JUCBzaWduYWxpbmcuDQo+DQo+T0suIE1h a2Ugc2Vuc2UuIFRoYW5rcw0KPj4NCj4+Pg0KPj4+DQo+Pj4zLiBIb3cgZG8geW91IGhhbmRsZSB0 aGUgY2FzZSBvZiBJUHY2IG9mZmxvYWRpbmc/DQo+Pg0KPj4gUE1JUHY2IGZvciBvZmZsb2FkaW5n IGRvZXMgbm90IGFzc3VtZSBOUFR2Ng0KPj4gDQo+PihodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW5ldGV4dC1wbWlwdjYtc2lwdG8tb3B0aW9uLTA2I3NlY3QNCj4+aW8NCj4+ IG4tMSkgc28gdGhlIFBDUCBzZXJ2ZXIgaXMgb25seSBmb3IgZmlyZXdhbGwuDQo+DQo+SSBkaWRu J3QgZm9sbG93IE5ldGV4dC4gQnV0LCBkcmFmdC1pZXRmLW5ldGV4dC1wbWlwdjYtc2lwdG8tb3B0 aW9uDQo+ZGlkbid0IHNheSB0aGUgd29yZHMgb2YgYXNzdW1wdGlvbiBvZiAibm8gIE5QVHY2Ii4g V2hlcmVhcywgdGhlDQo+YWJzdHJhY3Qgc3RhdGVkICJUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5l cyBhIG1lY2hhbmlzbSBhbmQgYSByZWxhdGVkDQo+bW9iaWxpdHkgb3B0aW9uIGZvciBjYXJyeWlu ZyBJUHY0IE9mZmxvYWQgdHJhZmZpYyBzZWxlY3RvcnMgYmV0d2VlbiBhDQo+bW9iaWxlIGFjY2Vz cyIuIEl0IHNlZW1zIG5vdCBjb25zaWRlcmluZyBJUHY2IG9mZmxvYWQgYXQgYWxsLg0KPlRoZXJl Zm9yZSwgSSdtIG5vdCBzdXJlIE5QVHY2IHNob3VsZCBiZSBleGNsdWRlZC4NCj4NCj4NCj4+IEZv ciBJUHY2LCBhcyB0aGUgTU4gY2FuIGJlIGFzc2lnbmVkIGFuIElQdjYgcHJlZml4IGZyb20gdGhl IGFjY2Vzcw0KPj5uZXR3b3JrDQo+PiBpbiBhZGRpdGlvbiB0byB0aGUgSVB2NiBwcmVmaXggZnJv bSB0aGUgaG9tZSBuZXR3b3JrLCB0aGVyZWJ5IGFsbG93aW5nDQo+PnRoZQ0KPj4gTU4gdG8gdXNl IGFuIElQdjYgYWRkcmVzcyBmcm9tIHRoZSBhY2Nlc3MgbmV0d29yayBmb3IgdHJhZmZpYyB0aGF0 IG5lZWRzDQo+PiB0byBiZSBvZmZsb2FkZWQgaW4gdGhlIGFjY2VzcyBuZXR3b3JrLiBUaGlzIHNj ZW5hcmlvIGlzIHNpbWlsYXIgdG8gSVB2Ng0KPj4gbXVsdGlob21pbmcgYW5kDQo+PiBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wYXRpbC1wY3AtbXVsdGlob21pbmctMDAjc2VjdGlv bi0zDQo+PiBleHBsYWlucyBQQ1AgY2xpZW50IGJlaGF2aW9yIGluIHN1Y2ggY2FzZXMuDQo+Pg0K Pj4NCj4+IFdlIGludGVuZCB0byBhZGQgSVB2NiBkZXRhaWxzIGluIHRoZSBuZXh0IHJldmlzaW9u Lg0KPg0KPg0KPnRoYW5rcw0KPg0KPkJScw0KPg0KPkdhbmcNCj4+IC1QcmFzaGFudGgNCj4+DQo+ Pg0KPj4NCj4+Pg0KPj4+QmVzdCBSZWdhcmRzDQo+Pj4NCj4+PkdhbmcNCj4+Pg0KPj4+DQo+Pj4y MDEyLzkvMTcsIFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpIDxwcmFzcGF0aUBjaXNjby5jb20+ Og0KPj4+PiBUaGlzIGlzIGFuIHVwZGF0ZWQgdmVyc2lvbiBhZnRlciBhY2NvbW1vZGF0aW5nIHJl dmlldyBjb21tZW50cy4NCj4+Pj4NCj4+Pj4gQ29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIHdlbGNv bWUuDQo+Pj4+DQo+Pj4+IC1QcmFzaGFudGgNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4+DQo+Pj4+ Pk9uIDMxLzA4LzEyIDg6NTMgUE0sICJpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciDQo+Pj4+Pjxp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQo+Pj4+Pndyb3RlOg0KPj4+Pj4NCj4+Pj4+Pg0KPj4+ Pj4+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXJwY3ctcGNwLXBtaXB2Ni1zZXJ2LWRpc2Nv dmVyeS0wMS50eHQNCj4+Pj4+PmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUHJh c2hhbnRoIFBhdGlsIGFuZCBwb3N0ZWQgdG8gdGhlDQo+Pj4+Pj5JRVRGIHJlcG9zaXRvcnkuDQo+ Pj4+Pj4NCj4+Pj4+PkZpbGVuYW1lOgkgZHJhZnQtcnBjdy1wY3AtcG1pcHY2LXNlcnYtZGlzY292 ZXJ5DQo+Pj4+Pj5SZXZpc2lvbjoJIDAxDQo+Pj4+Pj5UaXRsZToJCSBQQ1AgU2VydmVyIERpc2Nv dmVyeSB3aXRoIElQdjQgdHJhZmZpYyBvZmZsb2FkIGZvciBQcm94eQ0KPj4+Pj4+TW9iaWxlDQo+ Pj4+Pj5JUHY2DQo+Pj4+Pj5DcmVhdGlvbiBkYXRlOgkgMjAxMi0wOC0zMQ0KPj4+Pj4+V0cgSUQ6 CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+Pj4+Pj5OdW1iZXIgb2YgcGFnZXM6IDEzDQo+Pj4+ Pj5VUkw6DQo+Pj4+Pj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1y cGN3LXBjcC1wbWlwdjYtc2Vydi1kaXNjb3YNCj4+Pj4+PmVyDQo+Pj4+Pj55LQ0KPj4+Pj4+MA0K Pj4+Pj4+MS50eHQNCj4+Pj4+PlN0YXR1czoNCj4+Pj4+Pmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtcnBjdy1wY3AtcG1pcHY2LXNlcnYtZGlzY292ZXJ5DQo+Pj4+Pj5IdG1s aXplZDoNCj4+Pj4+Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJwY3ctcGNwLXBt aXB2Ni1zZXJ2LWRpc2NvdmVyeS0wMQ0KPj4+Pj4+RGlmZjoNCj4+Pj4+Pmh0dHA6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXJwY3ctcGNwLXBtaXB2Ni1zZXJ2LWRpc2NvdmVyeQ0K Pj4+Pj4+LTANCj4+Pj4+PjENCj4+Pj4+Pg0KPj4+Pj4+QWJzdHJhY3Q6DQo+Pj4+Pj4gICBUaGlz IGRvY3VtZW50IHByb3Bvc2VzIGEgc29sdXRpb24gdG8gUENQIFNlcnZlciBEaXNjb3ZlcnkgcHJv YmxlbXMNCj4+Pj4+PmluDQo+Pj4+Pj4gICBQcm94eSBNb2JpbGUgSVB2NiAoUE1JUHY2KSBuZXR3 b3JrcyB3aGVuIGJvdGggaG9tZSBuZXR3b3JrIHRyYWZmaWMNCj4+Pj4+PiAgIGFuZCB0cmFmZmlj IG9mZi1sb2FkZWQgdG8gbG9jYWwgYWNjZXNzIG5ldHdvcmsgcmVxdWlyZSB0cmF2ZXJzaW5nDQo+ Pj4+Pj5hDQo+Pj4+Pj4gICBnYXRld2F5IGltcGxlbWVudGluZyBOQVQgYW5kL29yIEZpcmV3YWxs LiAgVGhpcyBkcmFmdCBwcm9wb3Nlcw0KPj4+Pj4+ICAgZW5oYW5jZW1lbnRzIHRvIERIQ1B2NCBS ZWxheSBBZ2VudCBieSBpbnRyb2R1Y2luZyBhIG5ldyBzdWItb3B0aW9uDQo+Pj4+Pj4gICB1bmRl ciBESENQdjQgUmVsYXkgT3B0aW9uIGFuZCB0byBQTUlQdjYgc2lnbmFsaW5nIHRocm91Z2gNCj4+ Pj4+PmFkZGl0aW9uYWwNCj4+Pj4+PiAgIG9wdGlvbnMgdG8gUHJveHkgQmluZGluZyBVcGRhdGUv QWNrbm93bGVkZ2VtZW50IG1lc3NhZ2VzLg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+ DQo+Pj4+Pj4NCj4+Pj4+PlRoZSBJRVRGIFNlY3JldGFyaWF0DQo+Pj4+Pj4NCj4+Pj4+DQo+Pj4+ DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+IHBjcCBtYWlsaW5nIGxpc3QNCj4+Pj4gcGNwQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNwDQo+Pj4+DQo+Pg0KPj4NCg0K From phdgang@gmail.com Wed Oct 24 00:26: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 B528821F8457 for ; Wed, 24 Oct 2012 00:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, 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 gYJSI17iaDG3 for ; Wed, 24 Oct 2012 00:26:57 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 22A5C21F8456 for ; Wed, 24 Oct 2012 00:26:57 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so219728vcb.31 for ; Wed, 24 Oct 2012 00:26:56 -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 :content-type; bh=4SFNqnqQqeNSfIf9KTGzp1iLHIhKGlpy58jaWgdFx9g=; b=XUjrwASUVqcPRGbDXknq6JBU7n7Iqou2ZYhnX5xEbNGJaa3RZcR1bkpBCCW+AybUGV Zm82OZDiObDVou6r/uT3tgQXXWWPfEGLJ69AEUXWzpaOQ9ilrqZntKgcLQDfb1aYb3Qt 8Xt44oxpPgr5Ok2fbR9slG2Wix4RU6okgoYjXEvJN1EkGHIXiMuTXxX/ncZHCEDi3S7F +rQuedhzh9f6DuOFpteEW/3H+XzuDfVNKnsM+ZpKux8/YNs4Cx6nU/dW4WM/e/wmeA5l mc9gwXvaDq4Sz5hB3+znzGXTHdAW6vBRxaZhYkr97Sj+crM9cTPycgNW3iqEY9RrvcgY UbXA== MIME-Version: 1.0 Received: by 10.52.176.168 with SMTP id cj8mr20808295vdc.72.1351063616524; Wed, 24 Oct 2012 00:26:56 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Wed, 24 Oct 2012 00:26:56 -0700 (PDT) In-Reply-To: <20121022153431.31304.42329.idtracker@ietfa.amsl.com> References: <20121022153431.31304.42329.idtracker@ietfa.amsl.com> Date: Wed, 24 Oct 2012 15:26:56 +0800 Message-ID: From: GangChen To: "pcp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [pcp] Fwd: I-D Action: draft-chen-pcp-mobile-deployment-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: Wed, 24 Oct 2012 07:26:57 -0000 Dear folks, We have updated the draft with the comments we received so far. Your further comments are appreciated Many thanks Gang ---------- Forwarded message ---------- From: internet-drafts@ietf.org Date: Mon, 22 Oct 2012 08:34:31 -0700 Subject: I-D Action: draft-chen-pcp-mobile-deployment-02.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of Port Control Protocol in Mobile Network Author(s) : Gang Chen Zhen Cao Mohamed Boucadair Vizdal Ales Laurent Thiebaut Filename : draft-chen-pcp-mobile-deployment-02.txt Pages : 14 Date : 2012-10-22 Abstract: This memo provides a motivation description for the Port Control Protocol (PCP) deployment in a 3GPP mobile network environment. The document focuses on a mobile network specific issues (e.g. cell phone battery power consumption, keep-alive traffic reduction), PCP applicability to these issues is further studied and analysed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-chen-pcp-mobile-deployment There's also a htmlized version available at: http://tools.ietf.org/html/draft-chen-pcp-mobile-deployment-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-chen-pcp-mobile-deployment-02 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 Wed Oct 24 04:41: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 32FEE21F889A for ; Wed, 24 Oct 2012 04:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, 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 5AkmJBK9Dby4 for ; Wed, 24 Oct 2012 04:41:56 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 2606621F8B88 for ; Wed, 24 Oct 2012 04:41:55 -0700 (PDT) Received: from [192.168.2.2] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MF5uN-1TfaJp1vYZ-00GH67; Wed, 24 Oct 2012 07:41:53 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <3644979.ovSNnDyzia@porto.nomis80.org> Date: Wed, 24 Oct 2012 14:41:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <67054721-2DED-4023-89E2-F8E3692A6117@yegin.org> <3644979.ovSNnDyzia@porto.nomis80.org> To: Simon Perreault X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:ghldHbUtzfh1RxvVa+5fv+ZRzeGJaN65lnVKs/xCFOH IHS3WbCnHXkbt0cHs+p0o3C8jYk0TqC1jCTO4xRO78/abpgXuk tSSNf9NI2lclSSUjefZ6uSt7qAa28t9Vt58BL2vHwC1sMaOvuR L0cKf9zGIyvC50kgxu7kxQYPIfdb2CXPAaPKtbjOicOrFr0J92 Cki+4fRaRkvKKxmsMB6G28bY6xveaKDxQdKKhJGvGtWLk4SQDM 7PzRDe2sN4KZJGVuAR/OEx6CSan/1b+xlaTUJU9k66jv6+0J81 XBDbrdEp+Ue7voxMREZ30nLqXmh34opGxBRVGdCyIWCTUT0Cvd o2J+SgNeSilhkBrfgyFQRrlnhMAq4mj2IweryW9SkOmd4+XB2s 6RQmcAyp4YXIA== Cc: pcp@ietf.org Subject: Re: [pcp] Loosely/tightly coupled auth/authz 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, 24 Oct 2012 11:41:57 -0000 Simon, Please see below. >> Before I enter an in-depth discussion, let me say whether we decide = to do it >> one way or the other does not have any impact on the PANA vs. = EAP-o-PCP >> discussion. PANA can support both. >>=20 >> Having said that, PCP WG still needs to decide which way to go, so = let's >> discuss that below. >>=20 >> Margaret, the reason it took us so long to understand what you are = trying to >> do is because of the terminology. Your PPTs are referring to = authentication >> and authorization. Not sure if you are aware but authentication of = what and >> authorization of what are extremely important at this level of = discussion. >> Let's be very specific. >>=20 >>=20 >> EAP (in conjunction with its EAP lower layer) authenticates the = identity of >> the end-point ("joe@domain", or more specifically "a device used by >> joe@domain") Along with that there is an authorization of the = requested >> service (PCP in this case). The final response from the AAA server to = the >> NAS (PCP server in this case) not only says "yes, this is joe", but = also >> says "joe is allowed to use PCP service"). In fact, it may not even = say >> "yes, this is joe". That info may not matter to the NAS. And its = disclosure >> to the NAS may even be prohibited due to privacy concerns. AAA server = tells >> NAS "yes, this fellow is allowed to use PCP service". >>=20 >> This is what centralized authentication and authorization servers, = AAA >> servers, do. At that level, in a sense, authentication and = authorization is >> coupled. >>=20 >> Along with that authorization comes in a session lifetime, telling = the NAS >> for who long this authorized service is good for. AAA is saying "this >> fellow is allowed to use PCP service for 1 hour." It can say further = things >> too: stop the service after 1 hour, or re-auth before the end-of 1 = hour, >> etc. >>=20 >> This is how the current EAP and AAA-based architectures work. >=20 > I'm following you up to here. >=20 >> Now, people said they'd like the PCP server (the NAS) set the session >> lifetime. >=20 > I don't think anyone said that. Auth lifetime is different from = mapping=20 > lifetime. The AAA server is responsible for auth lifetime. The NAT is=20= > responsible for the mapping lifetime. >=20 When the AAA server authenticates and authorizes "joe@domain", it's = basically telling the following to the NAS (the PCP server): - This fellow is authorized to use PCP with you, - Next time he wants to send a PCP request to you, you can authenticate = and authorize him by using the following session credentials (MSK, or an = MSK child key + an id [session id]). You don't have to come back and ask = me to authenticate and authorize. - This session credential is good for duration of X. (this is the = authorized lifetime of joe to be using PCP with the PCP server). After X = has passed, throw the session credential away, it's useless.=20 - Feel free to come back to me to re-auth and re-authorize anytime = before X has passed. You'll get a new session credential, and a new = lifetime. Now, a mapping created by Joe using PCP can have a lifetime of Y. It makes a lot of sense that X =3D=3D Y. It can also be that Y < X. PCP server can have a reason to require that. And there may be cases where Y > X.=20 We need to be talking about where this makes sense. For example, in firewall configuration by an admin, this makse sense. For a mobile subscriber accessing wireless network whose apps are = creating NAP mappings, this does not make sense. Network resources are = tightly controlled, and the PCP clients come and go. >> NAS can reduce the lifetime it received from the AAA server, but >> extending the lifetime w/o AAA server's involvement would be a = problem. >> Because, the "centralized" authority sets the upper limit. This is = the >> whole reason of using a centralized AAA server. Second A is for >> Authorization. >>=20 >>=20 >> You sound like you want to use AAA server for Authentication, but not = for >> Authorization. If this is what you want to do, please tell us why you = want >> to do it that way. This is unusual. >>=20 >>=20 >> Secondly, putting aside where the "PCP authorization lifetime" comes = from, >> you folks want to decouple EAP session lifetime with the PCP = lifetime. >>=20 >> What's the benefit of this de-coupling? >=20 > Because PCP is just one way to manipulate NAT mappings. Others = include: > - ordinary traffic using the mapping > - NAT administration interface > - other mapping control protocols that may be enabled simultaneously = with PCP >=20 Please see above. We can talk about different uses of PCP and how it = may impact the relationship between X and Y. >> Why would you want to toss away your EAP session when the PCP state = is still >> up? >=20 > There is no such "PCP state". There is only NAT state, which is = independent=20 > from PCP. >=20 Let me expand on this: > There is PCP state that we now have due to PCP SA (Security = Association), > And there is the network state created by PCP signaling (which can be = NAT or firewall state). Depending on the scenario,the two may be tightly coupled, or loosely = coupled. >> Tossing away would force you to re-run EAP from scratch if the client >> needs to process any other PCP packet meanwhile. Unnecessary = overhead. >>=20 >>=20 >> At the end of the day, here are the three lifetimes we could be = talking >> about: >>=20 >> 1- Authorized service lifetime AAA tells the NAS (PCP server). >> 2- Effective lifetime set on the state created for the authorized = service. >> (mapping lifetime) 3- EAP session lifetime (MSK and its children's >> lifetime) >>=20 >>=20 >> In current EAP and AAA practice, these are all the same values. >> If you want to deviate from that, we need to understand why. Because = that >> deviation is going to complicate a simple system. >=20 > IMHO it is technically impossible not to decouple mapping lifetime = from the=20 > rest. Because that's how NAT works today, and you can't change that. >=20 We are going beyond today's NAT operation with the introduction of = "authenticated signaling setting up and maintaining NAT tables".=20 I think you are referring to the following in your above concern: - PCP creates the NAT mapping - Application traffic maintains the mapping - So, even after PCP SA is expired, we cannot remove the mapping because = now the mapping is in use and maintained by the app traffic. Is that it, or something else? I'd appreciate if you can elaborate. Alper > 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 hartmans@painless-security.com Wed Oct 24 04:59: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 0871021F8964 for ; Wed, 24 Oct 2012 04:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.662 X-Spam-Level: X-Spam-Status: No, score=0.662 tagged_above=-999 required=5 tests=[AWL=3.261, 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 CU7ro5bKSBYB for ; Wed, 24 Oct 2012 04:59:35 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id C06F521F8941 for ; Wed, 24 Oct 2012 04:59:31 -0700 (PDT) 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 A79E520167; Wed, 24 Oct 2012 07:59:05 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A2D8D412A; Wed, 24 Oct 2012 07:59:28 -0400 (EDT) From: Sam Hartman To: "pcp issue tracker" References: <059.9cf5d7c12f5da883f5db53fb2786e69b@tools.ietf.org> Date: Wed, 24 Oct 2012 07:59:28 -0400 In-Reply-To: <059.9cf5d7c12f5da883f5db53fb2786e69b@tools.ietf.org> (pcp issue tracker's message of "Fri, 19 Oct 2012 22:09:40 -0000") 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: draft-ietf-pcp-authentication@tools.ietf.org, pcp@ietf.org Subject: Re: [pcp] #62: Client-driven or server-driven auth retransmissions 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, 24 Oct 2012 11:59:36 -0000 Hi. Yoshi and I have had several rounds of discussing EAp retransmissions in the ABFAB working group. My understanding of the situation has improved. Retransmission of an EAP request will always happen I've been describing this issue incorrectly when I brought it up in the PCP group. The question is what is used to trigger retransmissions, not what party does the retransmission. The authenticator (PCP server/PAA) has the EAP request packet as part of security state it maintains. The question is whether the authenticator has a timer that causes it to retransmit the request. That's what the default behavior in EAP is. Alternatively, the EAP specification (RFC 3748) allows that timer to be set to infinite. In that case, the lower layer (PCP or PANA) is taking responsibility for reliability. If the lower layer is handling reliability, then you can use whatever trigger you like. You can have a timer on the server. Alternatively, you can have a timer on the client and retransmit the request on the server when you receive a duplicate response. So, no matter what option you pick, the server is required to hold the state. The potential advantage of picking client-triggered retransmits is that it may make it easier to match an existing implementation. We could really use input from PCP implementations about whether having the authentication retransmit timer on the client is easier than the server. From hartmans@painless-security.com Wed Oct 24 05:12:34 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C2C21F893E for ; Wed, 24 Oct 2012 05:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.616 X-Spam-Level: X-Spam-Status: No, score=0.616 tagged_above=-999 required=5 tests=[AWL=3.215, 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 b7CIdjSfhrP6 for ; Wed, 24 Oct 2012 05:12:33 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9652B21F882D for ; Wed, 24 Oct 2012 05:12:33 -0700 (PDT) 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 725FB20167; Wed, 24 Oct 2012 08:12:07 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5CB12412A; Wed, 24 Oct 2012 08:12:30 -0400 (EDT) From: Sam Hartman To: "pcp issue tracker" References: <059.54331fe983d68240406025bfdbc8a50e@tools.ietf.org> <074.8491c8f47cdd0781b1caeb3494e5ba58@tools.ietf.org> Date: Wed, 24 Oct 2012 08:12:30 -0400 In-Reply-To: <074.8491c8f47cdd0781b1caeb3494e5ba58@tools.ietf.org> (pcp issue tracker's message of "Fri, 19 Oct 2012 22:12:32 -0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pcp@ietf.org, draft-ietf-pcp-authentication@tools.ietf.org Subject: Re: [pcp] #61: Unsolicited reauthentication 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, 24 Oct 2012 12:12:34 -0000 A few comments on this. We could really use input from PCP implementors on whether being able to go to sleep/not always have a PCP implementation responding to network messages is important. It would also be very valuable to get input on what AAA technologies people would use if they implemented PCP authentication. Here are some things it would be valuable to know: A) What AAA technologies do products that might include your PCP server typically support? (RADIUS, Diameter, both, neither?) B) Would you expect to implement Diameter support for PCP if you implement PCP authentication? C) Would you expect to implement RADIUS support if you implement PCP authentication? d) Do your products support RADIUS COA (change of authorization) today? E) Would you expect your PCP implementation to support RADIUS COA if you implement PCP authentication? A few comments on this topic: 1) rather than forcing unsolicited re-authentication a server can simply discard a PCP SA and generate an authentication required error on the next request. The disadvantage of this is that the next request may take longer to execute. 2) I've heard the claim that full authentication takes longer than re-authentication. There are some confusingly named EAP features called fast reauthentication and the EAP Reauthentication Protocol (ERP) that do significantly improve performance of subsequent EAP authentications. I think these performance gains are independent of whether the server discards a SA. What's the basis for the claim that re-authentication takes shorter than full authentication? 3) Server-initiated re-authentication is an optional feature for lower layers under the existing specifications, including the Diameter EAP application, which seems to be the only standards-track way to trigger it. 4) Standard RADIUS does not support server-initiated re-authentication. 5) There's a non-standards-track extension to RADIUS called COA. It explicitly forbids use of COA for re-authentication. I haven't found an IETF-endorsed way to trigger re-authentication from the server for RADIUS. It may be that some COA implementations can somehow do this. From yoshihiro.ohba@toshiba.co.jp Wed Oct 24 05:45: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 29FA221F868C for ; Wed, 24 Oct 2012 05:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.927 X-Spam-Level: X-Spam-Status: No, score=-4.927 tagged_above=-999 required=5 tests=[AWL=-0.838, 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 yQ-hM4AFgX4Q for ; Wed, 24 Oct 2012 05:45:09 -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 523E621F86BC for ; Wed, 24 Oct 2012 05:45:09 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q9OCj8w9023822 for ; Wed, 24 Oct 2012 21:45:08 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q9OCj8P4000466 for pcp@ietf.org; Wed, 24 Oct 2012 21:45:08 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id XAA00465; Wed, 24 Oct 2012 21:45:07 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q9OCj7Ji016574 for ; Wed, 24 Oct 2012 21:45:07 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q9OCj7Nu021151; Wed, 24 Oct 2012 21:45:07 +0900 (JST) Received: from [133.199.16.209] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MCE005V1E33G320@mail.po.toshiba.co.jp> for pcp@ietf.org; Wed, 24 Oct 2012 21:45:07 +0900 (JST) Date: Wed, 24 Oct 2012 21:45:02 +0900 From: Yoshihiro Ohba In-reply-to: To: pcp@ietf.org Message-id: <5087E2CE.4090201@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <059.9cf5d7c12f5da883f5db53fb2786e69b@tools.ietf.org> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Subject: Re: [pcp] #62: Client-driven or server-driven auth retransmissions 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, 24 Oct 2012 12:45:10 -0000 Sam, Your description below did not capture DoS attack issue with client-driven retransmission that I mentioned. It would be fair if you could mention it. Yoshihiro Ohba (2012/10/24 20:59), Sam Hartman wrote: > Hi. > Yoshi and I have had several rounds of discussing EAp retransmissions in > the ABFAB working group. > My understanding of the situation has improved. > > Retransmission of an EAP request will always happen I've been describing > this issue incorrectly when I brought it up in the PCP group. > > The question is what is used to trigger retransmissions, not what party > does the retransmission. > > The authenticator (PCP server/PAA) has the EAP request packet as part of > security state it maintains. > > The question is whether the authenticator has a timer that causes it to > retransmit the request. That's what the default behavior in EAP is. > > Alternatively, the EAP specification (RFC 3748) allows that timer to be > set to infinite. In that case, the lower layer (PCP or PANA) is taking > responsibility for reliability. > > If the lower layer is handling reliability, then you can use whatever > trigger you like. > You can have a timer on the server. > Alternatively, you can have a timer on the client and retransmit the > request on the server when you receive a duplicate response. > > So, no matter what option you pick, the server is required to hold the > state. > The potential advantage of picking client-triggered retransmits is that > it may make it easier to match an existing implementation. > > We could really use input from PCP implementations about whether having > the authentication retransmit timer on the client is easier than the > server. > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp > From hartmans@painless-security.com Wed Oct 24 05:49:38 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276AC21F8847 for ; Wed, 24 Oct 2012 05:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.572 X-Spam-Level: X-Spam-Status: No, score=0.572 tagged_above=-999 required=5 tests=[AWL=3.171, 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 xq5KMr+EBVyU for ; Wed, 24 Oct 2012 05:49:33 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC3A21F86C9 for ; Wed, 24 Oct 2012 05:49:29 -0700 (PDT) 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 B6B4B20348; Wed, 24 Oct 2012 08:49:03 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C3038412A; Wed, 24 Oct 2012 08:49:26 -0400 (EDT) From: Sam Hartman To: Yoshihiro Ohba References: <059.9cf5d7c12f5da883f5db53fb2786e69b@tools.ietf.org> <5087E2CE.4090201@toshiba.co.jp> Date: Wed, 24 Oct 2012 08:49:26 -0400 In-Reply-To: <5087E2CE.4090201@toshiba.co.jp> (Yoshihiro Ohba's message of "Wed, 24 Oct 2012 21:45:02 +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] #62: Client-driven or server-driven auth retransmissions 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, 24 Oct 2012 12:49:38 -0000 >>>>> "Yoshihiro" == Yoshihiro Ohba writes: Yoshihiro> Sam, Your description below did not capture DoS attack Yoshihiro> issue with client-driven retransmission that I mentioned. Yoshihiro> It would be fair if you could mention it. Agreed, I'm waiting for that discussion to resolve itself then I'll try and capture where we are. I explicitly held off on giving an opinion about the retransmission issue with regard to PCP because I think our discussion is still open. --Sam From simon.perreault@viagenie.ca Wed Oct 24 06:21:58 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7AA21F881C for ; Wed, 24 Oct 2012 06:21:58 -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, J_CHICKENPOX_83=0.6, NO_RELAYS=-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 voW8+M7Sspl4 for ; Wed, 24 Oct 2012 06:21:57 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2D98221F87DC for ; Wed, 24 Oct 2012 06:21:43 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8891:30fb:d283:e7a7]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2199C40079; Wed, 24 Oct 2012 09:21:41 -0400 (EDT) Message-ID: <5087EB64.70607@viagenie.ca> Date: Wed, 24 Oct 2012 09:21:40 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: Alper Yegin References: <67054721-2DED-4023-89E2-F8E3692A6117@yegin.org> <3644979.ovSNnDyzia@porto.nomis80.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pcp@ietf.org Subject: Re: [pcp] Loosely/tightly coupled auth/authz 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, 24 Oct 2012 13:21:58 -0000 Le 2012-10-24 07:41, Alper Yegin a écrit : > When the AAA server authenticates and authorizes "joe@domain", it's basically telling the following to the NAS (the PCP server): > - This fellow is authorized to use PCP with you, > - Next time he wants to send a PCP request to you, you can authenticate and authorize him by using the following session credentials (MSK, or an MSK child key + an id [session id]). You don't have to come back and ask me to authenticate and authorize. > - This session credential is good for duration of X. (this is the authorized lifetime of joe to be using PCP with the PCP server). After X has passed, throw the session credential away, it's useless. > - Feel free to come back to me to re-auth and re-authorize anytime before X has passed. You'll get a new session credential, and a new lifetime. I'm following you up to here. > Now, a mapping created by Joe using PCP can have a lifetime of Y. > > It makes a lot of sense that X == Y. In my previous email I tried to explain why X == Y does not make sense to me. > It can also be that Y < X. PCP server can have a reason to require that. > > And there may be cases where Y > X. > We need to be talking about where this makes sense. > For example, in firewall configuration by an admin, this makse sense. > For a mobile subscriber accessing wireless network whose apps are creating NAP mappings, this does not make sense. Network resources are tightly controlled, and the PCP clients come and go. I would expect Y to have no link whatsoever with X, and would advise to design an auth protocol that has absolutely no expectation on Y. >> Because PCP is just one way to manipulate NAT mappings. Others include: >> - ordinary traffic using the mapping >> - NAT administration interface >> - other mapping control protocols that may be enabled simultaneously with PCP >> > > Please see above. I'm sorry but I fail to see how your reply above addresses what I wrote. > We can talk about different uses of PCP and how it may impact the relationship between X and Y. Why would there be any relationship at all? There can't be, because PCP is just one way to manipulate NAT mappings. >>> Why would you want to toss away your EAP session when the PCP state is still >>> up? >> >> There is no such "PCP state". There is only NAT state, which is independent >> from PCP. >> > Let me expand on this: > >> There is PCP state that we now have due to PCP SA (Security Association), >> And there is the network state created by PCP signaling (which can be NAT or firewall state). Right, this is a good precision. With this precision, my point is to be understood as meaning that the network state, in the NAT/firewall, has no PCP-specific component. > Depending on the scenario,the two may be tightly coupled, or loosely coupled. I'll reiterate my current position: so far it seems clear to me that we need loosely coupled, and I have seen no use case for tightly coupled. > We are going beyond today's NAT operation with the introduction of "authenticated signaling setting up and maintaining NAT tables". I'm not sure what you mean exactly by this, but I'm afraid that changing current NAT practice is going to be an uphill battle. > I think you are referring to the following in your above concern: > - PCP creates the NAT mapping > - Application traffic maintains the mapping > - So, even after PCP SA is expired, we cannot remove the mapping because now the mapping is in use and maintained by the app traffic. > > Is that it, or something else? I'd appreciate if you can elaborate. That's one use case for loosely-coupled. Others I've hinted at: - Protocols other than PCP can be used to manipulate mappings. Even more: multiple protocols can be used to manipulate a single mapping. - A NAT administrator may want to change mapping lifetimes. An administration script (cron job) could want to do this. - NATs have complex behaviours and may decide to change a mapping's lifetime because of arbitrary traffic patterns, because of load conditions, because of the time of day, because of the weather, or just because it feels like it. My point is basically that the NAT is authoritative for a mapping's lifetime. Practically, this authority can not be moved to a AAA server. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dwing@cisco.com Wed Oct 24 06:33: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 C72B621F8B7E for ; Wed, 24 Oct 2012 06:33:03 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxBiVwX0lLoV for ; Wed, 24 Oct 2012 06:33:03 -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 BD29B21F8B5B for ; Wed, 24 Oct 2012 06:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=797; q=dns/txt; s=iport; t=1351085575; x=1352295175; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=7dl3BgYe+2j1G6E0ONAmZGL+V24gT212BufSx0iceeU=; b=Dr+ki57syqTT3Rqc4ACKpgCfvg0jlm5QFoPSS0bHQ0cMMmI4gDytCmpa cZ5uOERbbAxK/KFXH2xGe8SoNYpSFhMPxWlpnpUxB3Wn2htkM8cz0bFqx T/6P7puP+fojyw2JXrAArt2vSftinUkJ35myOSDeHAcghK9S+kNplLqfZ g=; X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208";a="134847313" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 24 Oct 2012 13:32:55 +0000 Received: from DWINGWS01 ([10.32.240.194]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9ODWsC0001394; Wed, 24 Oct 2012 13:32:55 GMT From: "Dan Wing" To: "'Alain Durand'" , References: <82256834F867D44BBB8E49E40D5448BB02FF4B@BL2PRD0510MB386.namprd05.prod.outlook.com> In-Reply-To: <82256834F867D44BBB8E49E40D5448BB02FF4B@BL2PRD0510MB386.namprd05.prod.outlook.com> Date: Wed, 24 Oct 2012 06:32:54 -0700 Message-ID: <009d01cdb1ec$1304eae0$390ec0a0$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJduNkCk34UmbQLucD5xBfuZUtiIpant2mg Content-Language: en-us Cc: 'Ralph Droms' Subject: Re: [pcp] Stepping down as wg chair 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, 24 Oct 2012 13:33:04 -0000 Thanks for all your work and support getting PCP off the ground! -d > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Alain Durand > Sent: Tuesday, October 23, 2012 12:13 PM > To: pcp@ietf.org > Cc: Ralph Droms > Subject: [pcp] Stepping down as wg chair > > Dear wg, > > Effective immediately, I'm stepping down from chairing the PCP wg. > I'd like to express my thanks and appreciations to all of you that have > been working with me on this project since its inception a few years > ago. > > Ralph Droms, the wg responsible ADs, will announce a replacement > shortly. > > Alain. > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From simon.perreault@viagenie.ca Wed Oct 24 07:29:55 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0855521F869A for ; Wed, 24 Oct 2012 07:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, NO_RELAYS=-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 TtHPzlssrqbN for ; Wed, 24 Oct 2012 07:29:54 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6414E21F85BF for ; Wed, 24 Oct 2012 07:29:54 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8891:30fb:d283:e7a7]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C9BCF41A08 for ; Wed, 24 Oct 2012 10:29:52 -0400 (EDT) Message-ID: <5087FB60.6060101@viagenie.ca> Date: Wed, 24 Oct 2012 10:29:52 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: pcp@ietf.org References: <059.9cf5d7c12f5da883f5db53fb2786e69b@tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [pcp] #62: Client-driven or server-driven auth retransmissions 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, 24 Oct 2012 14:29:55 -0000 Le 2012-10-24 07:59, Sam Hartman a écrit : > We could really use input from PCP implementations about whether having > the authentication retransmit timer on the client is easier than the > server. I can't say I understand all the technical details, but here's my view: Without auth, only PCP clients do retransmissions. Servers only reply to packets, so that's less state and load on PCP servers. It would be nice if we could keep it the way it is. My 2¢CAD... 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 rdroms.ietf@gmail.com Wed Oct 24 08:09:54 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 7866421F86C4 for ; Wed, 24 Oct 2012 08:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.511 X-Spam-Level: X-Spam-Status: No, score=-103.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 IEHKMJqxPPMC for ; Wed, 24 Oct 2012 08:09:54 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C464D21F8715 for ; Wed, 24 Oct 2012 08:09:53 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so702524vcb.31 for ; Wed, 24 Oct 2012 08:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=3nr4QkzfXu3QzvzvqQ0Xn+Rz1EqkTOrsMZK9Z6R7sMo=; b=hjE73SIR5thnmwmY6MJjsBVm8uWstKGZ3RwUAh0XXPKDcckRW8DNrGeocgdo20P7m2 /4Qyb4ijnI8a97DAPhecwRLSja5K/Hy9YraUNCua0aMhyfdmQD4SzQk75QdKtSDqzhAk +L+RWstbh3cFZK7i7MT8AG2/lGoHyPlPioPpl2ctXojnV14qaQtHwoNsf206DgJ0Kk7J C/THMCOWGBNil6laoTUkMBPGkMpkcmmARd3LtbT+/SDiRW6unE4qtr84oJTptIUjAo2q UhKuIvdo0IB33zfI1ATPXdkni9HR2clmFY6b4ipTRX99Px0cxbVCId3bIYV42Cq/5HAq dtxw== Received: by 10.220.156.8 with SMTP id u8mr8485498vcw.74.1351091392111; Wed, 24 Oct 2012 08:09:52 -0700 (PDT) Received: from [10.86.245.24] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPS id v9sm15477058ves.8.2012.10.24.08.09.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Oct 2012 08:09:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <82256834F867D44BBB8E49E40D5448BB02FF4B@BL2PRD0510MB386.namprd05.prod.outlook.com> Date: Wed, 24 Oct 2012 17:09:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1BBBC90B-7FEE-4504-8F90-D4AA076A5E79@gmail.com> References: <82256834F867D44BBB8E49E40D5448BB02FF4B@BL2PRD0510MB386.namprd05.prod.outlook.com> To: Alain Durand X-Mailer: Apple Mail (2.1283) Cc: pcp@ietf.org Subject: Re: [pcp] Stepping down as wg chair 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, 24 Oct 2012 15:09:54 -0000 Alain - thank you for your leadership and hard work on PCP in your role = as co-chair. The WG has made excellent progress and I'm looking forward = to getting the PCP base specification to the RFC Editor soon. WG - Reinaldo Penno has agreed to replace Alain as pcp WG co-chair. = Thanks, Reinaldo, for taking on this responsibility. - Ralph On Oct 23, 2012, at 9:12 PM 10/23/12, Alain Durand wrote: > Dear wg, >=20 > Effective immediately, I'm stepping down from chairing the PCP wg. > I'd like to express my thanks and appreciations to all of you that = have been working > with me on this project since its inception a few years ago. >=20 > Ralph Droms, the wg responsible ADs, will announce a replacement = shortly. >=20 > Alain. From alper.yegin@yegin.org Thu Oct 25 00:34:37 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA5C21F879C for ; Thu, 25 Oct 2012 00:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 FS1fqegiwv28 for ; Thu, 25 Oct 2012 00:34:32 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id EE6A821F8634 for ; Thu, 25 Oct 2012 00:34:31 -0700 (PDT) Received: from [192.168.2.8] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Lx9Jh-1TKjNn468H-016jFT; Thu, 25 Oct 2012 03:34:28 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_101775D2-76CC-4AB0-8B84-D0B5D3DD35CC" From: Alper Yegin In-Reply-To: Date: Thu, 25 Oct 2012 10:34:08 +0300 Message-Id: References: <059.54331fe983d68240406025bfdbc8a50e@tools.ietf.org> <074.8491c8f47cdd0781b1caeb3494e5ba58@tools.ietf.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:4g+K6coWvE9buuWxf+t2JsIaBx1Y/oDNfNH0yjoae4z o8Sl/zM1cUEyYmrAv2AHDXHzlHXtLaa1SAHJvdjCSbi2UTGOX1 DCMsXaUF6JZVOrAdBS9FD7yTujkxOYUQUFyMQy27htVYfEux8/ prWw+7WoPCSYOzHEkLR4mLD3P4judFicgGLa0c59LwXbdvUOK6 Qgl8rW/6HKkVKfcpXwiM3oVV36IbDxSw67gH7tdN9wWeCvWTb8 JzGdHTwsXMHoVtOb5deM46Nlpy/T4tgbt8LhhFRI5jeik64G+6 HCxCQysvd/ios06fHxD/WdTXTFF7sZi9ox8fQavtKEDFthrMw1 4QRcRkIvvhs0h+mBog/MI7d+bhPRmQ2Vz2VGdqLLA9W/gCTgvq RO/nzpIzq/YrQ== Cc: pcp@ietf.org, pcp issue tracker , draft-ietf-pcp-authentication@tools.ietf.org Subject: Re: [pcp] #61: Unsolicited reauthentication 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, 25 Oct 2012 07:34:37 -0000 --Apple-Mail=_101775D2-76CC-4AB0-8B84-D0B5D3DD35CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sam, On Oct 24, 2012, at 3:12 PM, Sam Hartman wrote: > A few comments on this. >=20 > We could really use input from PCP implementors on whether being able = to > go to sleep/not always have a PCP implementation responding to network > messages is important. >=20 What is your definition of "sleep"? For the mobile/wireless engineers, = sleep is very specific where the mobile terminal practically detaches = from the network except for listening to paging beacons. Is this what = you mean or something else? Btw, your questions are not really for "PCP implementors" but for = "people building the nodes that are implementing PCP and whole bunch of = other stuff". In other words, NAT implementors, Firewall implementers, = etc.=20 > It would also be very valuable to get input on what AAA technologies > people would use if they implemented PCP authentication. > Here are some things it would be valuable to know: >=20 > A) What AAA technologies do products that might include your PCP = server > typically support? (RADIUS, Diameter, both, neither?) >=20 > B) Would you expect to implement Diameter support for PCP if you > implement PCP authentication? >=20 > C) Would you expect to implement RADIUS support if you implement PCP > authentication? >=20 > d) Do your products support RADIUS COA (change of authorization) = today? >=20 > E) Would you expect your PCP implementation to support RADIUS COA if > you implement PCP authentication? >=20 >=20 > A few comments on this topic: >=20 >=20 > 1) rather than forcing unsolicited re-authentication a server can = simply > discard a PCP SA and generate an authentication required error on = the > next request. > The disadvantage of this is that the next request may take longer to > execute. >=20 What is the advantage? > 2) I've heard the claim that full authentication takes longer than > re-authentication. There are some confusingly named EAP features = called > fast reauthentication and the EAP Reauthentication Protocol (ERP) that > do significantly improve performance of subsequent EAP = authentications. > I think these performance gains are independent of whether the server > discards a SA. > What's the basis for the claim that re-authentication takes shorter = than > full authentication? >=20 > 3) Server-initiated re-authentication is an optional feature for lower > layers under the existing specifications, including the Diameter EAP > application, which seems to be the only standards-track way to trigger > it. >=20 Nope! Please re-read my email. = http://www.ietf.org/mail-archive/web/pcp/current/msg02494.html If you are still not convinced, then please ask DIME + RADEXT + EMU + = EAP MLs. That's where you can get expert opinion on EAP/AAA, not PCP ML. > 4) Standard RADIUS does not support server-initiated = re-authentication. >=20 LEt me copy paste from my = http://www.ietf.org/mail-archive/web/pcp/current/msg02494.html email: "If you look at the table of attributes on page 21, you see the "CoA = request" can carry 0+ EAP message. So, the NAS (PCP client) can receive an asynchronous EAP request from = the AAA." > 5) There's a non-standards-track extension to RADIUS called COA. It > explicitly forbids use of COA for re-authentication. I haven't found = an > IETF-endorsed way to trigger re-authentication from the server for > RADIUS. It may be that some COA implementations can somehow do this. Ask RADEXT WG, please. (Not sure why your questions are still only being = circulated in PCP only=85=85.) Alper > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp --Apple-Mail=_101775D2-76CC-4AB0-8B84-D0B5D3DD35CC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
A few comments on this.

We  could really = use input from PCP implementors on whether being able to
go to = sleep/not always have a PCP implementation responding to = network
messages is = important.


What is your = definition of "sleep"? For the mobile/wireless engineers, sleep is very = specific where the mobile terminal practically detaches from the network = except for listening to paging beacons. Is this what you mean or = something else?


Btw, your = questions are not really for "PCP implementors" but for "people building = the nodes that are implementing PCP and whole bunch of other stuff". In = other words, NAT implementors, Firewall implementers, = etc. 


It would also be very valuable to get input on what = AAA technologies
people would use if they implemented PCP = authentication.
Here are some things it would be valuable to = know:

A) What AAA technologies do products that might include = your PCP server
typically support? (RADIUS, Diameter, both, = neither?)

B) Would you expect to implement Diameter support for = PCP if you
implement PCP authentication?

C) Would you expect = to implement RADIUS support if you implement = PCP
authentication?

d) Do your products support RADIUS COA = (change of authorization) today?

E) Would you expect your PCP = implementation to support RADIUS COA  if
you implement PCP = authentication?


A few comments on this topic:


1) = rather than forcing unsolicited re-authentication a server can = simply
discard a PCP SA and   generate an authentication = required error on the
next request.
The disadvantage of this is = that the next request may take longer = to
execute.


What is the = advantage?


2) I've heard the claim that full authentication = takes longer than
re-authentication. There are some confusingly named = EAP features called
fast reauthentication and the EAP = Reauthentication Protocol (ERP) that
do significantly improve = performance of subsequent EAP authentications.
I think these = performance gains are independent of whether the server
discards a = SA.
What's the basis for the claim that re-authentication takes = shorter than
full authentication?

3) Server-initiated = re-authentication is an optional feature for lower
layers under the = existing specifications, including the Diameter EAP
application, = which seems to be the only standards-track way to = trigger
it.


If you are still not convinced, then please ask DIME + RADEXT + EMU + = EAP MLs.
That's where you can get expert opinion on EAP/AAA, = not PCP = ML.




4) Standard RADIUS does not support server-initiated = re-authentication.



"If you look at the table of =
attributes on page 21, you see the "CoA request" can carry 0+ EAP =
message.
So, the NAS (PCP client) can receive an asynchronous EAP request from =
the AAA."


5) There's a non-standards-track extension to RADIUS = called COA. It
explicitly forbids use of COA for re-authentication. =  I haven't found an
IETF-endorsed way to trigger = re-authentication from the server for
RADIUS.  It may be that = some COA implementations can somehow do = this.

Ask RADEXT WG, please. = (Not sure why your questions are still only being circulated in PCP = only=85=85.)

Alper


<= /div>


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

= --Apple-Mail=_101775D2-76CC-4AB0-8B84-D0B5D3DD35CC-- From rafa@um.es Thu Oct 25 10:48:20 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 EDE0421F892C for ; Thu, 25 Oct 2012 10:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=0.900, 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 RXxcjMMxrxDK for ; Thu, 25 Oct 2012 10:48:19 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 199E221F8869 for ; Thu, 25 Oct 2012 10:48:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 53D104BF14; Thu, 25 Oct 2012 19:48:14 +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 nFDRTVHF9qFo; Thu, 25 Oct 2012 19:48:13 +0200 (CEST) Received: from inf-205-150.inf.um.es (inf-205-150.inf.um.es [155.54.205.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon12.um.es (Postfix) with ESMTPSA id 464654BF0C; Thu, 25 Oct 2012 19:48:12 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: <5087FB60.6060101@viagenie.ca> Date: Thu, 25 Oct 2012 19:48:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3BF682F6-8CD3-4EAA-A1B8-DEA50337A574@um.es> References: <059.9cf5d7c12f5da883f5db53fb2786e69b@tools.ietf.org> <5087FB60.6060101@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1283) Cc: pcp@ietf.org Subject: Re: [pcp] #62: Client-driven or server-driven auth retransmissions 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, 25 Oct 2012 17:48:20 -0000 Hi Simon: El 24/10/2012, a las 16:29, Simon Perreault escribi=F3: > Le 2012-10-24 07:59, Sam Hartman a =E9crit : >> We could really use input from PCP implementations about whether = having >> the authentication retransmit timer on the client is easier than the >> server. >=20 > I can't say I understand all the technical details, but here's my = view: >=20 > Without auth, only PCP clients do retransmissions. Servers only reply = to packets, so that's less state and load on PCP servers. It would be = nice if we could keep it the way it is. In any case, the PCP server will have to keep a state since it will have = to run an EAP authenticator state machine and a AAA client. Thus, = handling a timer should not add too much (or basically nothing), = specially when you already have a protocol that does that for you.=20 Having said that, as far as I understand it, the side-by-side PANA = solution would not touch this behavior you mention in PCP clients and = PCP server implementations. At PCP level, retransmissions will work as = usual: PCP clients do retransmissions. But performing authentication = would be run by a different protocol which is not PCP and which already = provides all the functionality required to perform with full guarantees = the authentication you need. In my opinion, using PANA to bootstrap a PCP SA is pretty straight = forward. You run PANA, you get a MSK that it is used to derive a key to = build the PCP SA. If during the PCP SA life, you need to refresh the key = used for that, you need to perform a re-authentication to obtain a new = fresh MSK and therefore a fresh PCP SA. Well, you have also that with = PANA. When you do not require the key and, therefore, the PCP SA, you = can terminate the PANA session and that's all. Hope this helps. >=20 > My 2=A2CAD... >=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 ------------------------------------------------------- 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 ------------------------------------------------------- From dthaler@microsoft.com Thu Oct 25 18:35:20 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 EB74F21F85E6 for ; Thu, 25 Oct 2012 18:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.197 X-Spam-Level: X-Spam-Status: No, score=-103.197 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_00=-2.599, 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 IGdZ712C3Mrv for ; Thu, 25 Oct 2012 18:35:20 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.23]) by ietfa.amsl.com (Postfix) with ESMTP id 82C6521F8521 for ; Thu, 25 Oct 2012 18:35:12 -0700 (PDT) Received: from BY2FFO11FD012.protection.gbl (10.1.15.203) by BY2FFO11HUB039.protection.gbl (10.1.14.122) with Microsoft SMTP Server (TLS) id 15.0.545.8; Fri, 26 Oct 2012 01:35:03 +0000 Received: from TK5EX14MLTC104.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.545.8 via Frontend Transport; Fri, 26 Oct 2012 01:35:02 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.318.3; Fri, 26 Oct 2012 01:34:52 +0000 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.112]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0318.003; Thu, 25 Oct 2012 18:34:52 -0700 From: Dave Thaler To: Ralph Droms , Alain Durand Thread-Topic: Stepping down as wg chair Thread-Index: AQHNsVJelhTZSmyhdUGRCnyxUbaFVJfJBeYAgAHK2BA= Date: Fri, 26 Oct 2012 01:34:51 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B8AC2F1@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: <82256834F867D44BBB8E49E40D5448BB02FF4B@BL2PRD0510MB386.namprd05.prod.outlook.com> <1BBBC90B-7FEE-4504-8F90-D4AA076A5E79@gmail.com> In-Reply-To: <1BBBC90B-7FEE-4504-8F90-D4AA076A5E79@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(377454001)(164054002)(24454001)(13464001)(479174001)(49866001)(46102001)(74502001)(51856001)(47446002)(31966008)(20776001)(50986001)(50466001)(53806001)(2666001)(8716001)(47776002)(3846001)(1076001)(44976002)(54316001)(54356001)(4196001)(4396001)(47736001)(48376001)(47976001)(33656001)(16406001)(16696001)(74662001)(16826001)(316001)(3556001)(3746001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 06469BCC91 Cc: "pcp@ietf.org" Subject: Re: [pcp] Stepping down as wg chair 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, 26 Oct 2012 01:35:21 -0000 I'd like to add my thanks to Alain on driving PCP to where it is today. Alain has been relentless in helping push the WG forward to get consensus o= n=20 the base spec. And thanks to Reinaldo for stepping up to fill in! -Dave > -----Original Message----- > From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > Sent: Wednesday, October 24, 2012 8:10 AM > To: Alain Durand > Cc: pcp@ietf.org; Dave Thaler; Reinaldo (repenno) Penno > Subject: Re: Stepping down as wg chair >=20 > Alain - thank you for your leadership and hard work on PCP in your role a= s co- > chair. The WG has made excellent progress and I'm looking forward to > getting the PCP base specification to the RFC Editor soon. >=20 > WG - Reinaldo Penno has agreed to replace Alain as pcp WG co-chair. > Thanks, Reinaldo, for taking on this responsibility. >=20 > - Ralph >=20 > On Oct 23, 2012, at 9:12 PM 10/23/12, Alain Durand wrote: >=20 > > Dear wg, > > > > Effective immediately, I'm stepping down from chairing the PCP wg. > > I'd like to express my thanks and appreciations to all of you that > > have been working with me on this project since its inception a few yea= rs > ago. > > > > Ralph Droms, the wg responsible ADs, will announce a replacement shortl= y. > > > > Alain. From zhangdacheng@huawei.com Fri Oct 26 01:47:50 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF13021F84E3 for ; Fri, 26 Oct 2012 01:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 g-IR1PI29HfP for ; Fri, 26 Oct 2012 01:47:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2855921F84F6 for ; Fri, 26 Oct 2012 01:47:49 -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 AKY56196; Fri, 26 Oct 2012 08:47:46 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 26 Oct 2012 09:47:28 +0100 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 26 Oct 2012 09:47:43 +0100 Received: from SZXEML528-MBX.china.huawei.com ([169.254.4.15]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Fri, 26 Oct 2012 16:45:58 +0800 From: "Zhangdacheng (Dacheng)" To: Alper Yegin , Simon Perreault Thread-Topic: [pcp] Loosely/tightly coupled auth/authz Thread-Index: AQHNrP6cIM4Er+Jol0+MUTwUr4Rk1pfGYMEAgAF4MQCAA3ftcA== Date: Fri, 26 Oct 2012 08:45:58 +0000 Message-ID: References: <67054721-2DED-4023-89E2-F8E3692A6117@yegin.org> <3644979.ovSNnDyzia@porto.nomis80.org> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pcp@ietf.org" Subject: Re: [pcp] Loosely/tightly coupled auth/authz 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, 26 Oct 2012 08:47:50 -0000 Hi, Alper:=20 I am a little confused about the following discussion. Do you imply that th= e loosely coupled auth/authz solution cannot support the cases where X=3D= =3DY and X When the AAA server authenticates and authorizes "joe@domain", it's > basically telling the following to the NAS (the PCP server): > - This fellow is authorized to use PCP with you, > - Next time he wants to send a PCP request to you, you can authenticate a= nd > authorize him by using the following session credentials (MSK, or an MSK = child > key + an id [session id]). You don't have to come back and ask me to > authenticate and authorize. > - This session credential is good for duration of X. (this is the authori= zed lifetime > of joe to be using PCP with the PCP server). After X has passed, throw th= e > session credential away, it's useless. > - Feel free to come back to me to re-auth and re-authorize anytime before= X has > passed. You'll get a new session credential, and a new lifetime. >=20 >=20 > Now, a mapping created by Joe using PCP can have a lifetime of Y. >=20 > It makes a lot of sense that X =3D=3D Y. >=20 > It can also be that Y < X. PCP server can have a reason to require that. >=20 > And there may be cases where Y > X. > We need to be talking about where this makes sense. > For example, in firewall configuration by an admin, this makse sense. > For a mobile subscriber accessing wireless network whose apps are creatin= g > NAP mappings, this does not make sense. Network resources are tightly > controlled, and the PCP clients come and go. >=20 From alper.yegin@yegin.org Sun Oct 28 14:10:39 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 3BAC821F84EA for ; Sun, 28 Oct 2012 14:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.399 X-Spam-Level: X-Spam-Status: No, score=-99.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_83=0.6, 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 k1RU3Cz3T1x2 for ; Sun, 28 Oct 2012 14:10:32 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 731E621F854E for ; Sun, 28 Oct 2012 14:10:29 -0700 (PDT) Received: from [192.168.2.8] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MEXk9-1TdJTx1em1-00FYyS; Sun, 28 Oct 2012 17:10:23 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: <5087EB64.70607@viagenie.ca> Date: Sun, 28 Oct 2012 23:10:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4C3C8A82-63E6-444F-BDD9-5A1478E54DBE@yegin.org> References: <67054721-2DED-4023-89E2-F8E3692A6117@yegin.org> <3644979.ovSNnDyzia@porto.nomis80.org> <5087EB64.70607@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:nHdcVevftg70A1Zk4skoi4/Oe+Uwb+IH4TGoJwDqrKA /C4O7T4owQFSF0vvl2jdKVRIckow/JMpYmjuBxHPxVDWsXNaFr liUrbWD8Uw/xmyP6HVab8+DneEZYr92Xtjftr9bCz1DzbHBsDn fQOyaCiF0AJDidchZ6iXXK6rf2Hl/I9AF+m8YUdmBoRYPf77X5 DhHI9GcZnfAOSLPPLVcmeNeUMCkuNgDL7WHPTwZMwG6q6ARAgt 0wBjXx8eGPupSR7X+mvChpy8Po3TBp+9cSwtbqPriGQ49DUVTV E1SW9i+pZo9vbW7t7h1oAp3Uu6YoZiI9kGl25pxi9rokFUewCt qiNZZYdCw8BJOrLN0Ex/hpIx7rlEcX8bGYd0UsLCp9AKntaHdH 6633dEDpo8G3w== Cc: pcp@ietf.org Subject: Re: [pcp] Loosely/tightly coupled auth/authz 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, 28 Oct 2012 21:10:39 -0000 > - Protocols other than PCP can be used to manipulate mappings. Even = more: multiple protocols can be used to manipulate a single mapping. >=20 > - A NAT administrator may want to change mapping lifetimes. An = administration script (cron job) could want to do this. >=20 > - NATs have complex behaviours and may decide to change a mapping's = lifetime because of arbitrary traffic patterns, because of load = conditions, because of the time of day, because of the weather, or just = because it feels like it. >=20 This is summarizing the issue. Multiple factors can affect the lifetime of a mapping that was = originally created by the PCP signal. I understand that. > My point is basically that the NAT is authoritative for a mapping's = lifetime. Practically, this authority can not be moved to a AAA server. This is where I fail to understand. What I'm saying is, there may exist = at least one scenario where the mapping lifetime is centrally controlled = by the AAA. You seem to be saying this is impossible, there's no such a case. Btw, when the PCP signal creates state on the PCP server, what value of = lifetime is assigned to that state? I think you'd say the PCP server = decides on its own. A general PCP question: Should the PCP server indicate the associated = lifetime to the PCP client at the time of state creation via PCP? And if so, should the PCP server notify the PCP client when the lifetime = changes (due to some of those external factors you listed above)? Without this knowledge, the PCP client cannot properly "maintain" the = state on the PCP server. Alper On Oct 24, 2012, at 4:21 PM, Simon Perreault wrote: > Le 2012-10-24 07:41, Alper Yegin a =E9crit : >> When the AAA server authenticates and authorizes "joe@domain", it's = basically telling the following to the NAS (the PCP server): >> - This fellow is authorized to use PCP with you, >> - Next time he wants to send a PCP request to you, you can = authenticate and authorize him by using the following session = credentials (MSK, or an MSK child key + an id [session id]). You don't = have to come back and ask me to authenticate and authorize. >> - This session credential is good for duration of X. (this is the = authorized lifetime of joe to be using PCP with the PCP server). After X = has passed, throw the session credential away, it's useless. >> - Feel free to come back to me to re-auth and re-authorize anytime = before X has passed. You'll get a new session credential, and a new = lifetime. >=20 > I'm following you up to here. >=20 >> Now, a mapping created by Joe using PCP can have a lifetime of Y. >>=20 >> It makes a lot of sense that X =3D=3D Y. >=20 > In my previous email I tried to explain why X =3D=3D Y does not make = sense to me. >=20 >> It can also be that Y < X. PCP server can have a reason to require = that. >>=20 >> And there may be cases where Y > X. >> We need to be talking about where this makes sense. >> For example, in firewall configuration by an admin, this makse sense. >> For a mobile subscriber accessing wireless network whose apps are = creating NAP mappings, this does not make sense. Network resources are = tightly controlled, and the PCP clients come and go. >=20 > I would expect Y to have no link whatsoever with X, and would advise = to design an auth protocol that has absolutely no expectation on Y. >=20 >>> Because PCP is just one way to manipulate NAT mappings. Others = include: >>> - ordinary traffic using the mapping >>> - NAT administration interface >>> - other mapping control protocols that may be enabled simultaneously = with PCP >>>=20 >>=20 >> Please see above. >=20 > I'm sorry but I fail to see how your reply above addresses what I = wrote. >=20 >> We can talk about different uses of PCP and how it may impact the = relationship between X and Y. >=20 > Why would there be any relationship at all? There can't be, because = PCP is just one way to manipulate NAT mappings. >=20 >>>> Why would you want to toss away your EAP session when the PCP state = is still >>>> up? >>>=20 >>> There is no such "PCP state". There is only NAT state, which is = independent >>> from PCP. >>>=20 >> Let me expand on this: >>=20 >>> There is PCP state that we now have due to PCP SA (Security = Association), >>> And there is the network state created by PCP signaling (which can = be NAT or firewall state). >=20 > Right, this is a good precision. With this precision, my point is to = be understood as meaning that the network state, in the NAT/firewall, = has no PCP-specific component. >=20 >> Depending on the scenario,the two may be tightly coupled, or loosely = coupled. >=20 > I'll reiterate my current position: so far it seems clear to me that = we need loosely coupled, and I have seen no use case for tightly = coupled. >=20 >> We are going beyond today's NAT operation with the introduction of = "authenticated signaling setting up and maintaining NAT tables". >=20 > I'm not sure what you mean exactly by this, but I'm afraid that = changing current NAT practice is going to be an uphill battle. >=20 >> I think you are referring to the following in your above concern: >> - PCP creates the NAT mapping >> - Application traffic maintains the mapping >> - So, even after PCP SA is expired, we cannot remove the mapping = because now the mapping is in use and maintained by the app traffic. >>=20 >> Is that it, or something else? I'd appreciate if you can elaborate. >=20 > That's one use case for loosely-coupled. Others I've hinted at: >=20 > - Protocols other than PCP can be used to manipulate mappings. Even = more: multiple protocols can be used to manipulate a single mapping. >=20 > - A NAT administrator may want to change mapping lifetimes. An = administration script (cron job) could want to do this. >=20 > - NATs have complex behaviours and may decide to change a mapping's = lifetime because of arbitrary traffic patterns, because of load = conditions, because of the time of day, because of the weather, or just = because it feels like it. >=20 > My point is basically that the NAT is authoritative for a mapping's = lifetime. Practically, this authority can not be moved to a AAA server. >=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 From alper.yegin@yegin.org Sun Oct 28 14:27:58 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E60A21F84A7 for ; Sun, 28 Oct 2012 14:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.699 X-Spam-Level: X-Spam-Status: No, score=-99.699 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001, 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 6HJe7II888OK for ; Sun, 28 Oct 2012 14:27:58 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id ED69821F86ED for ; Sun, 28 Oct 2012 14:27:57 -0700 (PDT) Received: from [192.168.2.8] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MLf11-1TSrF90kHj-000Ty6; Sun, 28 Oct 2012 17:27:45 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: Date: Sun, 28 Oct 2012 23:27:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <059.9cf5d7c12f5da883f5db53fb2786e69b@tools.ietf.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:22x2m5LKDuqGwJyPrO2eCBNGHNK9F4b78gnGM7yVrX/ TBlWyvMtD6+4wRCMAkc9G2nG09kWi+UHHy5pbbv7TUGwWhtTWh 14PkA38RUO9GqLijcffMT9HvCJPq8Jt2htfvKl+KvXNtl35bZ2 Xsah+0Y91j9GdI9uRGnBlJcpOPHom12MOgEk1rgSzlNrfsciGs uaOW9s8JhWgCzeYek/pyFZSlJ511nTDecR3FvhQ6LJk20iLkQF y5+kzk+dm7sJxSXkjt5GHAsMzN6/6fmIGmNNctfbQhGNsjk3DV g9UM53T5UrTYP9bVRhi7cXXjRtwuJDqO39TFjKtSOMcHpM+Xkc zFLN02IO/FMn2+kZIMMvmKKqPBuStvdJiLAiSoZCbmdFXlIAQg 3042TTupTb9Tg== Cc: pcp@ietf.org, pcp issue tracker , draft-ietf-pcp-authentication@tools.ietf.org Subject: Re: [pcp] #62: Client-driven or server-driven auth retransmissions 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, 28 Oct 2012 21:27:58 -0000 On Oct 24, 2012, at 2:59 PM, Sam Hartman wrote: > Hi. > Yoshi and I have had several rounds of discussing EAp retransmissions = in > the ABFAB working group. > My understanding of the situation has improved. >=20 > Retransmission of an EAP request will always happen I've been = describing > this issue incorrectly when I brought it up in the PCP group. >=20 > The question is what is used to trigger retransmissions, not what = party > does the retransmission. >=20 > The authenticator (PCP server/PAA) has the EAP request packet as part = of > security state it maintains. >=20 > The question is whether the authenticator has a timer that causes it = to > retransmit the request. That's what the default behavior in EAP is. >=20 Right. > Alternatively, the EAP specification (RFC 3748) allows that timer to = be > set to infinite. In that case, the lower layer (PCP or PANA) is = taking > responsibility for reliability. >=20 "EAP Request" needs to be re-transmitted until the EAP authenticator = receives a response. That can be done either by performing the rexmits at the EAP-layer on = the EAP authenticator, or by performing the rexmits at the EAP-lower layer on the EAP = authenticator (the infinite timer at the EAP layer case). Either way it is the "EAP Request" being rexmited by the EAP = authenticator (which is the PCP server in this case). > If the lower layer is handling reliability, then you can use whatever > trigger you like. > You can have a timer on the server. > Alternatively, you can have a timer on the client and retransmit the > request on the server when you receive a duplicate response. >=20 In this "reverse the request direction" case of yours, the PCP client = needs to rexmit "EAP-Response[i-1]" until it receives the = "EAP-Request[i]". Right? So, the "PCP server" needs to cache both "EAP-Response[i-1]" and = "EAP-Request[i]" at any time.=20 If it ever receives the EAP-Response[i-1] again, it'll rexmit the cached = EAP-Request[i]. Right? > So, no matter what option you pick, the server is required to hold the > state. > The potential advantage of picking client-triggered retransmits is = that > it may make it easier to match an existing implementation. >=20 "=85 to match an existing implementation of PCP" you mean. With PANA solutions, PANA is the implementation that takes care of = rexmits of EAP, hence this has no impact whatsoever on the PCP = implementation. No per-request state is maintained, no timers are set in the PCP = implementation for EAP state machine. > We could really use input from PCP implementations about whether = having > the authentication retransmit timer on the client is easier than the > server. Alper From alper.yegin@yegin.org Sun Oct 28 14:31:33 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 EFA9E21F85B0 for ; Sun, 28 Oct 2012 14:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.149 X-Spam-Level: X-Spam-Status: No, score=-101.149 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, 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 QocDVDKMQxAJ for ; Sun, 28 Oct 2012 14:31:33 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 3B50021F8566 for ; Sun, 28 Oct 2012 14:31:33 -0700 (PDT) Received: from [192.168.2.8] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LmKCI-1Stnvv1kqw-00Zqve; Sun, 28 Oct 2012 17:31:32 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: <5087FB60.6060101@viagenie.ca> Date: Sun, 28 Oct 2012 23:31:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <35F6E6D8-6AF8-46EA-B445-44EB48113389@yegin.org> References: <059.9cf5d7c12f5da883f5db53fb2786e69b@tools.ietf.org> <5087FB60.6060101@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:Ud34HyQKKFt8glFi4J5zFMQJTJaitLNUtPoxqpv5xUo u3ytbSJQeBhbyR9waE9EiZgZuR1UDE4E2kU3J4zsCXdR00wMuV /baTiCBhlFXUAwlttcjb/VPs4h3E14vDN9aQrw51dnQiQ5E3KM UFwuEqBDbUJww+GpKbShabH9WB5PdoDw9URvfWbBuNn6eci6X4 2epzc3WtvSKWJlLQFVPTIbTu8A8Z7PuWkLe71MuPWonzM6tnJx U9jU5ScGNQa+IYIoYOj4EJgmeLWwhV9NKvYBUVqdd9kZQJp8Qj ZDnA/WvCLLDOyI+bg7j37ktB8zqwnGzXZKIjhy0VOxcPZ00ut0 +bM5keZnoYFKBsA4fQN8YzG5t/ahCTE6WDXi6mQ2liMhCmswvq 7GI5dk/4rt5Sg== Cc: pcp@ietf.org Subject: Re: [pcp] #62: Client-driven or server-driven auth retransmissions 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, 28 Oct 2012 21:31:34 -0000 With EAP-o-PCP, PCP server has to maintain state (as Sam already = acknowledged). PCP server has to cache the EAP-Request, in case the PCP client asks for = it again. In fact, the PCP server even has to cache the previous EAP-Request, so = that I can recognize the repeat request. On the other hand, if authentication is handled by "PANA", PCP server = does not concern itself with any of the caching and rexmit timers. On Oct 24, 2012, at 5:29 PM, Simon Perreault wrote: > Le 2012-10-24 07:59, Sam Hartman a =E9crit : >> We could really use input from PCP implementations about whether = having >> the authentication retransmit timer on the client is easier than the >> server. >=20 > I can't say I understand all the technical details, but here's my = view: >=20 > Without auth, only PCP clients do retransmissions. Servers only reply = to packets, so that's less state and load on PCP servers. It would be = nice if we could keep it the way it is. >=20 > My 2=A2CAD... >=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 simon.perreault@viagenie.ca Sun Oct 28 15:00:50 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0FE21F8650 for ; Sun, 28 Oct 2012 15:00:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPVFgsyZ+xZP for ; Sun, 28 Oct 2012 15:00:49 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 69C9921F8581 for ; Sun, 28 Oct 2012 15:00:49 -0700 (PDT) Received: from porto.nomis80.org (unknown [64.235.195.26]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 505A740096; Sun, 28 Oct 2012 18:00:48 -0400 (EDT) Message-ID: <508DAB0E.9030402@viagenie.ca> Date: Sun, 28 Oct 2012 18:00:46 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: Alper Yegin References: <67054721-2DED-4023-89E2-F8E3692A6117@yegin.org> <3644979.ovSNnDyzia@porto.nomis80.org> <5087EB64.70607@viagenie.ca> <4C3C8A82-63E6-444F-BDD9-5A1478E54DBE@yegin.org> In-Reply-To: <4C3C8A82-63E6-444F-BDD9-5A1478E54DBE@yegin.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: pcp@ietf.org Subject: Re: [pcp] Loosely/tightly coupled auth/authz 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, 28 Oct 2012 22:00:50 -0000 Le 2012-10-28 17:10, Alper Yegin a écrit : >> My point is basically that the NAT is authoritative for a mapping's lifetime. Practically, this authority can not be moved to a AAA server. > > This is where I fail to understand. What I'm saying is, there may exist at least one scenario where the mapping lifetime is centrally controlled by the AAA. What is this scenario? > You seem to be saying this is impossible, there's no such a case. The important word is "practially". Given the current state of NAT affairs, I don't see how it would be practically possible to move authority over a NAT mapping's lifetime to a AAA server. > Btw, when the PCP signal creates state on the PCP server, what value of lifetime is assigned to that state? I think you'd say the PCP server decides on its own. Yes and no. The PCP server is most probably operated by the same entity that operates the NAT. So their configurations can be expected to agree with each other. But if their is disagreement, the NAT has the final say. > A general PCP question: Should the PCP server indicate the associated lifetime to the PCP client at the time of state creation via PCP? Unless I'm misunderstanding, it already does. A successful MAP response contains the created mapping's lifetime. > And if so, should the PCP server notify the PCP client when the lifetime changes (due to some of those external factors you listed above)? > Without this knowledge, the PCP client cannot properly "maintain" the state on the PCP server. Everything about NAT is a hack. 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 zhangdacheng@huawei.com Sun Oct 28 18:52: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 CDD9821F84E3 for ; Sun, 28 Oct 2012 18:52:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf+bupSExbnk for ; Sun, 28 Oct 2012 18:52:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED3221F84A8 for ; Sun, 28 Oct 2012 18:52:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMD25563; Mon, 29 Oct 2012 01:52:00 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 29 Oct 2012 01:51:34 +0000 Received: from SZXEML425-HUB.china.huawei.com (10.72.61.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 29 Oct 2012 01:51:57 +0000 Received: from SZXEML528-MBX.china.huawei.com ([169.254.4.15]) by szxeml425-hub.china.huawei.com ([10.72.61.33]) with mapi id 14.01.0323.003; Mon, 29 Oct 2012 09:51:51 +0800 From: "Zhangdacheng (Dacheng)" To: Simon Perreault , Alper Yegin Thread-Topic: [pcp] Loosely/tightly coupled auth/authz Thread-Index: AQHNrP6cIM4Er+Jol0+MUTwUr4Rk1pfGYMEAgAF4MQCAABv1AIAGzDQAgAAOKACAAMTVgA== Date: Mon, 29 Oct 2012 01:51:51 +0000 Message-ID: References: <67054721-2DED-4023-89E2-F8E3692A6117@yegin.org> <3644979.ovSNnDyzia@porto.nomis80.org> <5087EB64.70607@viagenie.ca> <4C3C8A82-63E6-444F-BDD9-5A1478E54DBE@yegin.org> <508DAB0E.9030402@viagenie.ca> In-Reply-To: <508DAB0E.9030402@viagenie.ca> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.139] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "pcp@ietf.org" Subject: Re: [pcp] Loosely/tightly coupled auth/authz 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, 29 Oct 2012 01:52:05 -0000 >=20 > Le 2012-10-28 17:10, Alper Yegin a =E9crit : > >> My point is basically that the NAT is authoritative for a mapping's li= fetime. > Practically, this authority can not be moved to a AAA server. > > > > This is where I fail to understand. What I'm saying is, there may exist= at least > one scenario where the mapping lifetime is centrally controlled by the AA= A. >=20 > What is this scenario? Support that It should be the NAT itself to decide the life period of a map= ping. In addition, the loosely coupled auth/authz solution can work well wi= thin the scenarios where X=3DY (if there is any), right? >=20 > > You seem to be saying this is impossible, there's no such a case. >=20 > The important word is "practially". Given the current state of NAT > affairs, I don't see how it would be practically possible to move > authority over a NAT mapping's lifetime to a AAA server. >=20 > > Btw, when the PCP signal creates state on the PCP server, what value of > lifetime is assigned to that state? I think you'd say the PCP server deci= des on its > own. >=20 > Yes and no. The PCP server is most probably operated by the same entity > that operates the NAT. So their configurations can be expected to agree > with each other. But if their is disagreement, the NAT has the final say. >=20 > > A general PCP question: Should the PCP server indicate the associated > lifetime to the PCP client at the time of state creation via PCP? >=20 > Unless I'm misunderstanding, it already does. A successful MAP response > contains the created mapping's lifetime. >=20 > > And if so, should the PCP server notify the PCP client when the lifetim= e > changes (due to some of those external factors you listed above)? > > Without this knowledge, the PCP client cannot properly "maintain" the s= tate > on the PCP server. >=20 > Everything about NAT is a hack. >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From repenno@cisco.com Mon Oct 29 00:43:32 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382CF21F86D5 for ; Mon, 29 Oct 2012 00:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_83=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 SzTDKnT5adqq for ; Mon, 29 Oct 2012 00:43:31 -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 30BF621F86D4 for ; Mon, 29 Oct 2012 00:43:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7339; q=dns/txt; s=iport; t=1351496611; x=1352706211; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+vQRP5jtm969Q/GWSOITDgfU96AWxPrHEts2v369SVc=; b=B7iRZ18MFts3OVwgqrYg52+uMf9oBReb2BXkHEhToPsvCoeElWx85+0t 8JLGMxdl99rzhWzmjcrAmf8zHq+ZzshLAS/kxpD7rGF42zfPzV5ChrBo6 VbgPOTnXk+0q7zGI9FZJGG6BzrkwE6F6lzVs2spvTevSgaTJ+aevndOvD I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMwyjlCtJV2a/2dsb2JhbABEwmKBCIIeAQEBBAEBAQ8BFEcEBxIBCBgKSwslAgQBDQUIGodkC5wWnzaLdQGFe2EDiCSOao09gWuCb4FkFx4 X-IronPort-AV: E=Sophos;i="4.80,669,1344211200"; d="scan'208";a="136136137" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 29 Oct 2012 07:43:30 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9T7hUSA020736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Oct 2012 07:43:30 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Mon, 29 Oct 2012 02:43:30 -0500 From: "Reinaldo Penno (repenno)" To: Alper Yegin , Simon Perreault Thread-Topic: [pcp] Loosely/tightly coupled auth/authz Thread-Index: AQHNsdyVtswI/+IU10qf3AgxfW2hspfIxRkAgAbMNACAADugAA== Date: Mon, 29 Oct 2012 07:43:29 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604132EAB@xmb-rcd-x04.cisco.com> In-Reply-To: <4C3C8A82-63E6-444F-BDD9-5A1478E54DBE@yegin.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.69.133] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19318.004 x-tm-as-result: No--72.969400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <87819741DB05BB42BEA30F7891180A31@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Loosely/tightly coupled auth/authz 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, 29 Oct 2012 07:43:32 -0000 On 10/28/12 2:10 PM, "Alper Yegin" wrote: >> - Protocols other than PCP can be used to manipulate mappings. Even >>more: multiple protocols can be used to manipulate a single mapping. >>=20 >> - A NAT administrator may want to change mapping lifetimes. An >>administration script (cron job) could want to do this. >>=20 >> - NATs have complex behaviours and may decide to change a mapping's >>lifetime because of arbitrary traffic patterns, because of load >>conditions, because of the time of day, because of the weather, or just >>because it feels like it. >>=20 > >This is summarizing the issue. >Multiple factors can affect the lifetime of a mapping that was originally >created by the PCP signal. >I understand that. > >> My point is basically that the NAT is authoritative for a mapping's >>lifetime. Practically, this authority can not be moved to a AAA server. > > >This is where I fail to understand. What I'm saying is, there may exist >at least one scenario where the mapping lifetime is centrally controlled >by the AAA. >You seem to be saying this is impossible, there's no such a case. [Reinaldo] Hi Alper, I'm not sure we are saying is impossible, certainly if we dig we can find a scenario. But I believe we need to gauge if this scenario is practical and will be used by people deploying PCP. The authentication work was meant to meet security requirements spelled out in pcp-base.=20 > > >Btw, when the PCP signal creates state on the PCP server, what value of >lifetime is assigned to that state? I think you'd say the PCP server >decides on its own. >A general PCP question: Should the PCP server indicate the associated >lifetime to the PCP client at the time of state creation via PCP? It is already part of the protocol. >And if so, should the PCP server notify the PCP client when the lifetime >changes (due to some of those external factors you listed above)? It is also part of the protocol. We have unsolicited notifications due to mapping updates. >Without this knowledge, the PCP client cannot properly "maintain" the >state on the PCP server. > >Alper > > >On Oct 24, 2012, at 4:21 PM, Simon Perreault wrote: > >> Le 2012-10-24 07:41, Alper Yegin a =E9crit : >>> When the AAA server authenticates and authorizes "joe@domain", it's >>>basically telling the following to the NAS (the PCP server): >>> - This fellow is authorized to use PCP with you, >>> - Next time he wants to send a PCP request to you, you can >>>authenticate and authorize him by using the following session >>>credentials (MSK, or an MSK child key + an id [session id]). You don't >>>have to come back and ask me to authenticate and authorize. >>> - This session credential is good for duration of X. (this is the >>>authorized lifetime of joe to be using PCP with the PCP server). After >>>X has passed, throw the session credential away, it's useless. >>> - Feel free to come back to me to re-auth and re-authorize anytime >>>before X has passed. You'll get a new session credential, and a new >>>lifetime. >>=20 >> I'm following you up to here. >>=20 >>> Now, a mapping created by Joe using PCP can have a lifetime of Y. >>>=20 >>> It makes a lot of sense that X =3D=3D Y. >>=20 >> In my previous email I tried to explain why X =3D=3D Y does not make sen= se >>to me. >>=20 >>> It can also be that Y < X. PCP server can have a reason to require >>>that. >>>=20 >>> And there may be cases where Y > X. >>> We need to be talking about where this makes sense. >>> For example, in firewall configuration by an admin, this makse sense. >>> For a mobile subscriber accessing wireless network whose apps are >>>creating NAP mappings, this does not make sense. Network resources are >>>tightly controlled, and the PCP clients come and go. >>=20 >> I would expect Y to have no link whatsoever with X, and would advise to >>design an auth protocol that has absolutely no expectation on Y. >>=20 >>>> Because PCP is just one way to manipulate NAT mappings. Others >>>>include: >>>> - ordinary traffic using the mapping >>>> - NAT administration interface >>>> - other mapping control protocols that may be enabled simultaneously >>>>with PCP >>>>=20 >>>=20 >>> Please see above. >>=20 >> I'm sorry but I fail to see how your reply above addresses what I wrote. >>=20 >>> We can talk about different uses of PCP and how it may impact the >>>relationship between X and Y. >>=20 >> Why would there be any relationship at all? There can't be, because PCP >>is just one way to manipulate NAT mappings. >>=20 >>>>> Why would you want to toss away your EAP session when the PCP state >>>>>is still >>>>> up? >>>>=20 >>>> There is no such "PCP state". There is only NAT state, which is >>>>independent >>>> from PCP. >>>>=20 >>> Let me expand on this: >>>=20 >>>> There is PCP state that we now have due to PCP SA (Security >>>>Association), >>>> And there is the network state created by PCP signaling (which can be >>>>NAT or firewall state). >>=20 >> Right, this is a good precision. With this precision, my point is to be >>understood as meaning that the network state, in the NAT/firewall, has >>no PCP-specific component. >>=20 >>> Depending on the scenario,the two may be tightly coupled, or loosely >>>coupled. >>=20 >> I'll reiterate my current position: so far it seems clear to me that we >>need loosely coupled, and I have seen no use case for tightly coupled. >>=20 >>> We are going beyond today's NAT operation with the introduction of >>>"authenticated signaling setting up and maintaining NAT tables". >>=20 >> I'm not sure what you mean exactly by this, but I'm afraid that >>changing current NAT practice is going to be an uphill battle. >>=20 >>> I think you are referring to the following in your above concern: >>> - PCP creates the NAT mapping >>> - Application traffic maintains the mapping >>> - So, even after PCP SA is expired, we cannot remove the mapping >>>because now the mapping is in use and maintained by the app traffic. >>>=20 >>> Is that it, or something else? I'd appreciate if you can elaborate. >>=20 >> That's one use case for loosely-coupled. Others I've hinted at: >>=20 >> - Protocols other than PCP can be used to manipulate mappings. Even >>more: multiple protocols can be used to manipulate a single mapping. >>=20 >> - A NAT administrator may want to change mapping lifetimes. An >>administration script (cron job) could want to do this. >>=20 >> - NATs have complex behaviours and may decide to change a mapping's >>lifetime because of arbitrary traffic patterns, because of load >>conditions, because of the time of day, because of the weather, or just >>because it feels like it. >>=20 >> My point is basically that the NAT is authoritative for a mapping's >>lifetime. Practically, this authority can not be moved to a AAA server. >>=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 alper.yegin@yegin.org Mon Oct 29 03:45: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 6074A21F861B for ; Mon, 29 Oct 2012 03:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.632 X-Spam-Level: X-Spam-Status: No, score=-101.632 tagged_above=-999 required=5 tests=[AWL=0.967, BAYES_00=-2.599, 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 TWk1FDqf3os6 for ; Mon, 29 Oct 2012 03:45:34 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 9A26921F85FA for ; Mon, 29 Oct 2012 03:45:34 -0700 (PDT) Received: from [192.168.2.6] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MSN8d-1TqfMP2RGl-00T6Vv; Mon, 29 Oct 2012 06:45:33 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: <508DAB0E.9030402@viagenie.ca> Date: Mon, 29 Oct 2012 12:44:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9BE09125-51BA-4239-8863-15005B7800B4@yegin.org> References: <67054721-2DED-4023-89E2-F8E3692A6117@yegin.org> <3644979.ovSNnDyzia@porto.nomis80.org> <5087EB64.70607@viagenie.ca> <4C3C8A82-63E6-444F-BDD9-5A1478E54DBE@yegin.org> <508DAB0E.9030402@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:77k/z+ztpoO1DIh3PUJcpVj0vzTyzYfSNu8FRVEimOl z+WykHkED2oRTGll1PLx8HMGQmMFfGavU5t/i1goe4Ft0hSxI1 AMTXkZ65RiuWJYdpV5wjS4gEJLeHDEA534n3h/e3yLgYEuzcZN NGim9nHCaa2PzuZ7uQpPqP62b7Wb7aF78P0UiiBfG1GGONf+k5 UgVRi/mhwK4ZII7vOdtC2glhc5P7XyXblMM2DuhSazlIzGxYQz l+NCVVte0n/4Df8UilSQVwpSu7o9R3WYDtvg21Tn4oDyCuuibS HxEvgg6bDy+j3BaPUSbhvmfyf9QfhuGR9T1YkD97dR+mVa8t82 FDDzbOl4Su09JCuVuPI96nLBftIuRjuM7b5ATHZVg/D3zWFMS7 K0T1X4782xt4g== Cc: pcp@ietf.org Subject: Re: [pcp] Loosely/tightly coupled auth/authz 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, 29 Oct 2012 10:45:35 -0000 >>> My point is basically that the NAT is authoritative for a mapping's = lifetime. Practically, this authority can not be moved to a AAA server. >>=20 >> This is where I fail to understand. What I'm saying is, there may = exist at least one scenario where the mapping lifetime is centrally = controlled by the AAA. >=20 > What is this scenario? >=20 Here's the scenario: Consider a mobile/wireless network (WiFi hotspots, 3G/4G, etc.). Mobile host's network access session is AAA'ed by a AAA server and = granted lifetime =3D=3D A. If and when the host uses PCP to set up NAT state or firewall state, = it'll be AAA'ed by the same AAA server and granted lifetime =3D=3D = remainder of A. Network access session, PCP session (I mean, the state associated with PCP, which is PCP SA, = etc.), and the state created by the PCP (the NAT mapping, firewall rules) are all = synchronized. They all expire at the same time. This is typically how sessions are managed in mobile/wireless network = architectures and deployments. >> You seem to be saying this is impossible, there's no such a case. >=20 > The important word is "practially". Given the current state of NAT = affairs, I don't see how it would be practically possible to move = authority over a NAT mapping's lifetime to a AAA server. >=20 >> Btw, when the PCP signal creates state on the PCP server, what value = of lifetime is assigned to that state? I think you'd say the PCP server = decides on its own. >=20 > Yes and no. The PCP server is most probably operated by the same = entity that operates the NAT. So their configurations can be expected to = agree with each other. But if their is disagreement, the NAT has the = final say. >=20 >> A general PCP question: Should the PCP server indicate the associated = lifetime to the PCP client at the time of state creation via PCP? >=20 > Unless I'm misunderstanding, it already does. A successful MAP = response contains the created mapping's lifetime. >=20 >> And if so, should the PCP server notify the PCP client when the = lifetime changes (due to some of those external factors you listed = above)? >> Without this knowledge, the PCP client cannot properly "maintain" the = state on the PCP server. >=20 > Everything about NAT is a hack. >=20 :-) I'm seeing PCP bringing some determinism to this. PCP is setting up = state on the NAT/Firewall, learning the granted lifetime, and even = getting notified when that lifetime changes, etc. This is becoming more = managed/manageable. Alper > 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 alper.yegin@yegin.org Mon Oct 29 03:53:07 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E19121F85B3 for ; Mon, 29 Oct 2012 03:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.574 X-Spam-Level: X-Spam-Status: No, score=-101.574 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, 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 ivf2uXZrmoxz for ; Mon, 29 Oct 2012 03:53:06 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 83C7B21F8481 for ; Mon, 29 Oct 2012 03:53:06 -0700 (PDT) Received: from [192.168.2.6] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0M6k9s-1TEa4N1HAi-00whG7; Mon, 29 Oct 2012 06:53:04 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604132EAB@xmb-rcd-x04.cisco.com> Date: Mon, 29 Oct 2012 12:52:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6BBC26DE-15D8-497A-A498-B789BB0575BD@yegin.org> References: <45A697A8FFD7CF48BCF2BE7E106F0604132EAB@xmb-rcd-x04.cisco.com> To: Reinaldo Penno (repenno) X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:WTJTg7O4I4CyOnXJc9r6B+ssQvqRG39Not/8GuV1sSv HK3XMyqDBm5HDnlFBal3rOx+3oD9wPItOMVSCBSzztZ2Q0CcX8 PCDRIBwUjHpFoSwBrnEDg6Im4YMljbV+kcQB0GVFz806dkxpFR LYYBE9XF7V0wAv8OErnbhB5Nv7X4PvgcsiZ5qq1vjJp6zEYV/Y ha4NSPA7wyMJl3DdByzyFW/o5wUQJPl0athz7O9MhhCD22sOVc 4PFt8U17faGJG+wM3BqwaLHX7sYn4Hh9eTElPodCCUnwxxcOM5 1sKbPk951/41e1WCGW6AjWNxKheW+05iUlw4luEju/W457BpvO 7D6yWmKLu2TkAEbFh3Dc+dOf8DfS3hXJIM5XPVnkA+L7BPOujb rClb2O1D/x+Bw== Cc: "pcp@ietf.org" Subject: Re: [pcp] Loosely/tightly coupled auth/authz 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, 29 Oct 2012 10:53:07 -0000 Hi Simon, >>=20 >> Btw, when the PCP signal creates state on the PCP server, what value = of >> lifetime is assigned to that state? I think you'd say the PCP server >> decides on its own. >> A general PCP question: Should the PCP server indicate the associated >> lifetime to the PCP client at the time of state creation via PCP? >=20 >=20 > It is already part of the protocol. >=20 >> And if so, should the PCP server notify the PCP client when the = lifetime >> changes (due to some of those external factors you listed above)? >=20 >=20 > It is also part of the protocol. We have unsolicited notifications due = to > mapping updates. This brings up an interesting issue. Such notifications need to be secured as well.=20 So, tossing away the PCP SA as soon as PCP signaling is done (like Sam = was suggesting) cannot be done because the PCP Server may be sending = such unsolicited notifications anytime. Or, if you insist on tossing the PCP SA right away, we certainly need = server-initiated EAP re-auth to cover for the case there is no PCP SA = when the server needs to send an unsolicited notification. Alper >=20 >> Without this knowledge, the PCP client cannot properly "maintain" the >> state on the PCP server. >>=20 >> Alper >>=20 >>=20 >> On Oct 24, 2012, at 4:21 PM, Simon Perreault wrote: >>=20 >>> Le 2012-10-24 07:41, Alper Yegin a =E9crit : >>>> When the AAA server authenticates and authorizes "joe@domain", it's >>>> basically telling the following to the NAS (the PCP server): >>>> - This fellow is authorized to use PCP with you, >>>> - Next time he wants to send a PCP request to you, you can >>>> authenticate and authorize him by using the following session >>>> credentials (MSK, or an MSK child key + an id [session id]). You = don't >>>> have to come back and ask me to authenticate and authorize. >>>> - This session credential is good for duration of X. (this is the >>>> authorized lifetime of joe to be using PCP with the PCP server). = After >>>> X has passed, throw the session credential away, it's useless. >>>> - Feel free to come back to me to re-auth and re-authorize anytime >>>> before X has passed. You'll get a new session credential, and a new >>>> lifetime. >>>=20 >>> I'm following you up to here. >>>=20 >>>> Now, a mapping created by Joe using PCP can have a lifetime of Y. >>>>=20 >>>> It makes a lot of sense that X =3D=3D Y. >>>=20 >>> In my previous email I tried to explain why X =3D=3D Y does not make = sense >>> to me. >>>=20 >>>> It can also be that Y < X. PCP server can have a reason to require >>>> that. >>>>=20 >>>> And there may be cases where Y > X. >>>> We need to be talking about where this makes sense. >>>> For example, in firewall configuration by an admin, this makse = sense. >>>> For a mobile subscriber accessing wireless network whose apps are >>>> creating NAP mappings, this does not make sense. Network resources = are >>>> tightly controlled, and the PCP clients come and go. >>>=20 >>> I would expect Y to have no link whatsoever with X, and would advise = to >>> design an auth protocol that has absolutely no expectation on Y. >>>=20 >>>>> Because PCP is just one way to manipulate NAT mappings. Others >>>>> include: >>>>> - ordinary traffic using the mapping >>>>> - NAT administration interface >>>>> - other mapping control protocols that may be enabled = simultaneously >>>>> with PCP >>>>>=20 >>>>=20 >>>> Please see above. >>>=20 >>> I'm sorry but I fail to see how your reply above addresses what I = wrote. >>>=20 >>>> We can talk about different uses of PCP and how it may impact the >>>> relationship between X and Y. >>>=20 >>> Why would there be any relationship at all? There can't be, because = PCP >>> is just one way to manipulate NAT mappings. >>>=20 >>>>>> Why would you want to toss away your EAP session when the PCP = state >>>>>> is still >>>>>> up? >>>>>=20 >>>>> There is no such "PCP state". There is only NAT state, which is >>>>> independent >>>>> from PCP. >>>>>=20 >>>> Let me expand on this: >>>>=20 >>>>> There is PCP state that we now have due to PCP SA (Security >>>>> Association), >>>>> And there is the network state created by PCP signaling (which can = be >>>>> NAT or firewall state). >>>=20 >>> Right, this is a good precision. With this precision, my point is to = be >>> understood as meaning that the network state, in the NAT/firewall, = has >>> no PCP-specific component. >>>=20 >>>> Depending on the scenario,the two may be tightly coupled, or = loosely >>>> coupled. >>>=20 >>> I'll reiterate my current position: so far it seems clear to me that = we >>> need loosely coupled, and I have seen no use case for tightly = coupled. >>>=20 >>>> We are going beyond today's NAT operation with the introduction of >>>> "authenticated signaling setting up and maintaining NAT tables". >>>=20 >>> I'm not sure what you mean exactly by this, but I'm afraid that >>> changing current NAT practice is going to be an uphill battle. >>>=20 >>>> I think you are referring to the following in your above concern: >>>> - PCP creates the NAT mapping >>>> - Application traffic maintains the mapping >>>> - So, even after PCP SA is expired, we cannot remove the mapping >>>> because now the mapping is in use and maintained by the app = traffic. >>>>=20 >>>> Is that it, or something else? I'd appreciate if you can elaborate. >>>=20 >>> That's one use case for loosely-coupled. Others I've hinted at: >>>=20 >>> - Protocols other than PCP can be used to manipulate mappings. Even >>> more: multiple protocols can be used to manipulate a single mapping. >>>=20 >>> - A NAT administrator may want to change mapping lifetimes. An >>> administration script (cron job) could want to do this. >>>=20 >>> - NATs have complex behaviours and may decide to change a mapping's >>> lifetime because of arbitrary traffic patterns, because of load >>> conditions, because of the time of day, because of the weather, or = just >>> because it feels like it. >>>=20 >>> My point is basically that the NAT is authoritative for a mapping's >>> lifetime. Practically, this authority can not be moved to a AAA = server. >>>=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 >=20 From repenno@cisco.com Mon Oct 29 16:59: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 54DCC21F8669 for ; Mon, 29 Oct 2012 16:59:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTVrj0gAE274 for ; Mon, 29 Oct 2012 16:59:13 -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 17E7721F86A1 for ; Mon, 29 Oct 2012 16:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4638; q=dns/txt; s=iport; t=1351555153; x=1352764753; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=18pty/eSZLXCiOV4xiqrwBaQsOfhBpOcgAvIKmgerCo=; b=iK9mHO6LQQfEeqmu9NnVPIcRBk0cTwox1Unlks8aU3ncbqYivG+LlbM5 Zvrs2hehXQBdAVmP9CH30itJX+qKeUBxVRuTh1UyjhMcXHFAHTAC8c03Z xhlDPq5qFIsRyb09nQnL4Zx3sIdyOpPa/fTzJxPQw3h3nhoU+VewQ0ib9 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIoXj1CtJV2b/2dsb2JhbABEwwmBCIIgAQQBAQEPARQTMwELEgEIIhQ3CyUCBAENBQgTB4dkC5t7oAePeIF5YQOXDo09gWuCYg2CGQ X-IronPort-AV: E=Sophos;i="4.80,675,1344211200"; d="scan'208";a="136709981" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 29 Oct 2012 23:59:12 +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 q9TNxChU011543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Oct 2012 23:59:12 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Mon, 29 Oct 2012 18:59:12 -0500 From: "Reinaldo Penno (repenno)" To: Alper Yegin , Simon Perreault Thread-Topic: [pcp] Loosely/tightly coupled auth/authz Thread-Index: AQHNsdyVtswI/+IU10qf3AgxfW2hspfIxRkAgAbMNACAAA4oAIAA1YWAgABojYA= Date: Mon, 29 Oct 2012 23:59:12 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604133314@xmb-rcd-x04.cisco.com> In-Reply-To: <9BE09125-51BA-4239-8863-15005B7800B4@yegin.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.155.68.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19318.004 x-tm-as-result: No--50.675900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No 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] Loosely/tightly coupled auth/authz 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, 29 Oct 2012 23:59:14 -0000 Some comments inline... On 10/29/12 3:44 AM, "Alper Yegin" wrote: >>>> My point is basically that the NAT is authoritative for a mapping's >>>>lifetime. Practically, this authority can not be moved to a AAA server. >>>=20 >>> This is where I fail to understand. What I'm saying is, there may >>>exist at least one scenario where the mapping lifetime is centrally >>>controlled by the AAA. >>=20 >> What is this scenario? >>=20 > >Here's the scenario: > >Consider a mobile/wireless network (WiFi hotspots, 3G/4G, etc.). >Mobile host's network access session is AAA'ed by a AAA server and >granted lifetime =3D=3D A. >If and when the host uses PCP to set up NAT state or firewall state, >it'll be AAA'ed by the same AAA server and granted lifetime =3D=3D remaind= er >of A. [Reinaldo] It seems we are going off track. The authentication work was meant to meet certain set of requirements. What would be the leanest solution that meets those requirements? Extra functionality, albeit nice, needs further discussion. Having said that, certainly we do not want mappings to survive (much) longer than the Mobile session. There is some text on PCP-base about it. "To help clean PCP state, it is RECOMMENDED that devices which combine IP address assignment (e.g., DHCP server) with the PCP server function (e.g., such as a residential CPE) flush PCP state when an IP address is allocated to a new host, because the new host will be unable perform the functions described in the previous paragaph because the new host does not know the previous host's Mapping Nonce value. It is good hygiene to also flush TCP and UDP flow state of NAT or fireall functions, although out of scope of this document." In other words, when detecting that a Mobile host disconnects the address allocation function can flush state by some other means. > >Network access session, >PCP session (I mean, the state associated with PCP, which is PCP SA, >etc.), and >the state created by the PCP (the NAT mapping, firewall rules) are all >synchronized. > >They all expire at the same time. > >This is typically how sessions are managed in mobile/wireless network >architectures and deployments. [Reinaldo] Today CGN is heavily deployed in wireless networks and in general NAT or Firewall mappings survive after user disconnects. They go away due to idle Timeouts.=20 There are a few CGN implementations with subscriber awareness that on receiving a Radius=20 Stop flush all NAT state. But I'm personally not aware of any implementation where the NAT mapping time is the=20 remainder of the Mobile Host session time. > > >>> You seem to be saying this is impossible, there's no such a case. >>=20 >> The important word is "practially". Given the current state of NAT >>affairs, I don't see how it would be practically possible to move >>authority over a NAT mapping's lifetime to a AAA server. >>=20 >>> Btw, when the PCP signal creates state on the PCP server, what value >>>of lifetime is assigned to that state? I think you'd say the PCP server >>>decides on its own. >>=20 >> Yes and no. The PCP server is most probably operated by the same entity >>that operates the NAT. So their configurations can be expected to agree >>with each other. But if their is disagreement, the NAT has the final say. >>=20 >>> A general PCP question: Should the PCP server indicate the associated >>>lifetime to the PCP client at the time of state creation via PCP? >>=20 >> Unless I'm misunderstanding, it already does. A successful MAP response >>contains the created mapping's lifetime. >>=20 >>> And if so, should the PCP server notify the PCP client when the >>>lifetime changes (due to some of those external factors you listed >>>above)? >>> Without this knowledge, the PCP client cannot properly "maintain" the >>>state on the PCP server. >>=20 >> Everything about NAT is a hack. >>=20 > >:-) > >I'm seeing PCP bringing some determinism to this. PCP is setting up state >on the NAT/Firewall, learning the granted lifetime, and even getting >notified when that lifetime changes, etc. This is becoming more >managed/manageable. > >Alper > > > > > >> 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 hartmans@painless-security.com Mon Oct 29 17:37:23 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F28621F86BE for ; Mon, 29 Oct 2012 17:37:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqcCOOwyt8OY for ; Mon, 29 Oct 2012 17:37:22 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5801621F866D for ; Mon, 29 Oct 2012 17:37:22 -0700 (PDT) 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 3491120200; Mon, 29 Oct 2012 20:36:44 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E4923412A; Mon, 29 Oct 2012 20:37:18 -0400 (EDT) From: Sam Hartman To: "Reinaldo Penno \(repenno\)" References: <45A697A8FFD7CF48BCF2BE7E106F0604133314@xmb-rcd-x04.cisco.com> Date: Mon, 29 Oct 2012 20:37:18 -0400 In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604133314@xmb-rcd-x04.cisco.com> (Reinaldo Penno's message of "Mon, 29 Oct 2012 23:59:12 +0000") 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] Loosely/tightly coupled auth/authz 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, 30 Oct 2012 00:37:23 -0000 >>>>> "Reinaldo" == Reinaldo Penno (repenno) writes: Reinaldo> It seems we are going off track. The authentication work Reinaldo> was meant to meet certain set of requirements. Reinaldo> What would be the leanest solution that meets those Reinaldo> requirements? Extra functionality, albeit nice, needs Reinaldo> further discussion. Reinaldo> Having said that, certainly we do not want mappings to Reinaldo> survive (much) longer than the Mobile session. There is Reinaldo> some text on PCP-base about it. Reinaldo> "To help clean PCP state, it is RECOMMENDED that devices Reinaldo> which combine IP address assignment (e.g., DHCP server) Reinaldo> with the PCP server function (e.g., such as a residential Reinaldo> CPE) flush PCP state when an IP address is allocated to a Reinaldo> new host, because the new host will be unable perform the Reinaldo> functions described in the previous paragaph because the Reinaldo> new host does not know the previous host's Mapping Nonce Reinaldo> value. It is good hygiene to also flush TCP and UDP flow Reinaldo> state of NAT or fireall functions, although out of scope Reinaldo> of this document." Reinaldo> In other words, when detecting that a Mobile host Reinaldo> disconnects the address allocation function can flush Reinaldo> state by some other means. I think this is a really interesting point. In the mobile/wireless use case, it doesn't make sense for the mapping lifetime to come from PCP authentication; instead it needs to come from the address allocation. That may involve an EAP authentication or not. The interesting thing here is that we want to tie the mapping lifetime to the network access lifetime, not to the PCP authentication lifetime. The NAT administrator wants to tie the mappings to the network access lifetime even ifthe mappings are implicit, configured with some protocol other than PCP or configured with PCP. Even if they are configured with PCP, some mappings may be configured using unauthenticated PCP. If authenticated PCP is involved in this use case, I find it strange that we'd want to tie the mapping lifetime to the PCP authentication lifetime. I wouldn't find it strange if the PCP authentication lifetime happened to be tied to session lifetime, but that's a policy for the AAA server to implement or not. Also, as several of us have mentioned, a PCP server can tie the two lifetimes together if it likes. I see no reason why the PCP authentication protocol need concern itself with the mapping lifetime. --Sam From bingxuere@gmail.com Wed Oct 31 00:41: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 C6E3321F8634 for ; Wed, 31 Oct 2012 00:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6w7-dCoY+f6 for ; Wed, 31 Oct 2012 00:41:58 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 457A521F84D6 for ; Wed, 31 Oct 2012 00:41:57 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so1854649iec.31 for ; Wed, 31 Oct 2012 00:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=FaI8ssM5d3UU6cgvyjvLw+v8onlXXHNf8g3h34fCVBU=; b=X1UKdMPgoCF/GgidVsA00YWiu2Q1YaFZyJgcRNN0PxP6WenAzSUTKirV7HIRjLe71F zy8AueuES16mPgDSE4IVz9R7cpyiJg4kKf8bvGiV3Fwc8l9JN7ZeyV7sdn8ljQx8ThKq ViKTjRzes41ZAL9DYL3My7H/PWKzBu4X8xjvBeeOHBB5Tss3jiJwXdi9xxGwrUerBSeK cpUAGin3T1RJ90cBvs8BBXVEnIfewzY+zQkskihPiHmMvtiYYFZY4zsyaQ/+rA3s99TV N0uK67le5saQ3YXnGqV8c8aQGdpqIj0DTj4f3cHHGiVUv6GA/liBK+blVJus7K7TFLTF trWg== Received: by 10.50.185.195 with SMTP id fe3mr606980igc.25.1351669316774; Wed, 31 Oct 2012 00:41:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.76.200 with HTTP; Wed, 31 Oct 2012 00:41:16 -0700 (PDT) From: Qiong Date: Wed, 31 Oct 2012 15:41:16 +0800 Message-ID: To: "pcp@ietf.org" Content-Type: multipart/alternative; boundary=14dae93408b97aeb8204cd560977 Subject: [pcp] Fw:I-D Action: New Version Notification for draft-tsou-pcp-natcoord-08.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, 31 Oct 2012 07:41:59 -0000 --14dae93408b97aeb8204cd560977 Content-Type: text/plain; charset=UTF-8 Dear all, We have updated the pcp-natcoord draft according to the comments from the wg before. The major changes in this version is as follows: 1) Update the PORT_SET_Nonce field and be consistent with the latest pcp-base draft 2) Encode the port-set in contiguous port mask, and remove the Cryptographically_Random_Port_Range option 3) Add coexistence with MAP. 4) Add security consideration and failover consideration Your further comments are appreciated. BTW, you can also find the opensource project in sourceforge: * http://sourceforge.net/projects/pcpportsetdemo/ * Thanks a lot! Best wishes -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --14dae93408b97aeb8204cd560977 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all,

We have updated the pcp-natcoord draft according to the co= mments from the wg before. The major changes in this version is as follows:=
1)=C2=A0Update=C2=A0the=C2=A0PORT_SET_Nonce=C2=A0field and be cons= istent with the latest pcp-base draft
2) Encode the port-set in contiguous port mask, and remove the Cryptographi= cally_Random_Port_Range option
3) Add=C2=A0coexistence=C2=A0with= =C2=A0MAP.
4)=C2=A0Add=C2=A0security=C2=A0consideration and failover co= nsideration

Your further comments are appreciated.

BTW, you can also find the opensource project in sourceforge: htt= p://sourceforge.net/projects/pcpportsetdemo/


Thanks a l= ot!

Best wishes

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 Res= earch Institude


Open source code:
lightweight 4over6: http://sou= rceforge.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

--14dae93408b97aeb8204cd560977-- From bingxuere@gmail.com Wed Oct 31 00:45:03 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED21921F86A3 for ; Wed, 31 Oct 2012 00:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id df6elwGbMoRP for ; Wed, 31 Oct 2012 00:45:03 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADBE21F8695 for ; Wed, 31 Oct 2012 00:45:03 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so1857642iec.31 for ; Wed, 31 Oct 2012 00:45:02 -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 :content-type; bh=gMQ6EdvEOU4cIxVo1QBVQHU3V5O+FWwU0ndodgu9KYM=; b=QTXU6OBVzLRnc8dTDFqyqJVov4rJNuidvbRtU0J39AHs77rCaRTARva5hXS7f8gwUs 88FwcqOfieA5tzYnNttdgjqBMxpIF8kDqY0K5LG+JGGB5xsMOPp+wWOK6yiv4xizegEx f/tGehS3WMN330ZDgTBRgIM8CeiZtwXYolishuDm++hU99YkkKW++ob+s2jCXa43QpSz 8aupwrIHhgbt6O+6OUy08+yi6UKl+tJ5Y3ttcfMrpu+6nKhqFI9fL/eh1ONAih7w+psL oflHd1FLB1c2ZgX8AnjbTqMInI6huzPYU8c97m4rlVJJ+abNWmoz1Th7Fmv1XBmpuoG4 kIzw== Received: by 10.50.36.200 with SMTP id s8mr536124igj.25.1351669502789; Wed, 31 Oct 2012 00:45:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.76.200 with HTTP; Wed, 31 Oct 2012 00:44:22 -0700 (PDT) In-Reply-To: References: From: Qiong Date: Wed, 31 Oct 2012 15:44:22 +0800 Message-ID: To: "pcp@ietf.org" Content-Type: multipart/alternative; boundary=14dae934082791473004cd5614c2 Subject: Re: [pcp] Fw:I-D Action: New Version Notification for draft-tsou-pcp-natcoord-08.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, 31 Oct 2012 07:45:04 -0000 --14dae934082791473004cd5614c2 Content-Type: text/plain; charset=UTF-8 Dear all, The following is the forwarded message for the updated pcp-natcoord draft:) ================================================== A new version of I-D, draft-tsou-pcp-natcoord-08.txt has been successfully submitted by Qiong Sun and posted to the IETF repository. Filename: draft-tsou-pcp-natcoord Revision: 08 Title: Lightweight 4over6 Port-set Allocation: Using PCP To Coordinate Between the CGN and Home Gateway Creation date: 2012-10-22 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-tsou-pcp-natcoord-08.txt Status: http://datatracker.ietf.org/doc/draft-tsou-pcp-natcoord Htmlized: http://tools.ietf.org/html/draft-tsou-pcp-natcoord-08 Diff: http://www.ietf.org/rfcdiff?url2=draft-tsou-pcp-natcoord-08 Abstract: This document defines an extension to the base PCP. New OpCode is defined to enhance PCP with the ability to reserve port sets for internal hosts. The IETF Secretariat On Wed, Oct 31, 2012 at 3:41 PM, Qiong wrote: > Dear all, > > We have updated the pcp-natcoord draft according to the comments from the > wg before. The major changes in this version is as follows: > 1) Update the PORT_SET_Nonce field and be consistent with the latest > pcp-base draft > 2) Encode the port-set in contiguous port mask, and remove the > Cryptographically_Random_Port_Range option > 3) Add coexistence with MAP. > 4) Add security consideration and failover consideration > > Your further comments are appreciated. > > BTW, you can also find the opensource project in sourceforge: * > http://sourceforge.net/projects/pcpportsetdemo/ > > * > Thanks a lot! > > Best wishes > > -- > ============================================== > Qiong Sun > China Telecom Beijing Research Institude > > > Open source code: > lightweight 4over6: *http://sourceforge.net/projects/laft6/* > PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * > =============================================== > > > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --14dae934082791473004cd5614c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

The following is the forwarded message for the updated= pcp-natcoord draft:)


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

A new version of I-D, draft-tsou-p= cp-natcoord-08.txt
has been successfully submitted by Qiong Sun and posted to the
IETF repo= sitory.
=C2=A0
Filename:=C2=A0 draft-tsou-pcp-natcoord
Revision:= =C2=A0 08
Title:=C2=A0 Lightweight 4over6 Port-set Allocation: Using PCP= To Coordinate Between the CGN and Home Gateway
Creation date:=C2=A0 2012-10-22
WG ID:=C2=A0 Individual Submission
Nu= mber of pages: 13
URL: http://www.ietf.org/internet-drafts/draft-tso= u-pcp-natcoord-08.txt
Status: http://datatracker.ietf.org/doc/draft-tsou-pcp-natcoord
Htmlized: <= a href=3D"http://tools.ietf.org/html/draft-tsou-pcp-natcoord-08">http://too= ls.ietf.org/html/draft-tsou-pcp-natcoord-08
Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-tsou-pcp-natcoord-08
= =C2=A0
Abstract:
=C2=A0=C2=A0 This document defines an extension to t= he base PCP.=C2=A0 New OpCode is
=C2=A0=C2=A0 defined to enhance PCP with the ability to reserve port sets f= or
=C2=A0=C2=A0 internal hosts.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0
=C2=A0
=C2=A0
The IETF Secretariat



On Wed, Oct 3= 1, 2012 at 3:41 PM, Qiong <bingxuere@gmail.com> wrote:
=
Dear all,

We have updated the pcp-natcoord draft according to the co= mments from the wg before. The major changes in this version is as follows:=
1)=C2=A0Update=C2=A0the=C2=A0PORT_SET_Nonce=C2=A0field and be cons= istent with the latest pcp-base draft
2) Encode the port-set in contiguous port mask, and remove the Cryptographi= cally_Random_Port_Range option
3) Add=C2=A0coexistence=C2=A0with= =C2=A0MAP.
4)=C2=A0Add=C2=A0security=C2=A0consideration and failover co= nsideration

Your further comments are appreciated.

BTW, you can also find the opensource project in sourceforge: htt= p://sourceforge.net/projects/pcpportsetdemo/


Thanks a l= ot!

Best wishes

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=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
Chin= a Telecom Beijing Research Institude


Open source code:
lightw= eight 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

--14dae934082791473004cd5614c2-- From alper.yegin@yegin.org Wed Oct 31 02:37:01 2012 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EA621F874E for ; Wed, 31 Oct 2012 02:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.243 X-Spam-Level: X-Spam-Status: No, score=-102.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, 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 g-IkP9Nx0j26 for ; Wed, 31 Oct 2012 02:37:00 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7333121F872C for ; Wed, 31 Oct 2012 02:37:00 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0LgJOG-1Szc0o2IZ2-00nhOR; Wed, 31 Oct 2012 05:36:58 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604133314@xmb-rcd-x04.cisco.com> Date: Wed, 31 Oct 2012 11:36:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E0A6E89-26D0-4BBE-9D24-DC499211FAF7@yegin.org> References: <45A697A8FFD7CF48BCF2BE7E106F0604133314@xmb-rcd-x04.cisco.com> To: Reinaldo Penno (repenno) X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:zXZEk3rEs69NIAlYkYO1tOjFnBGizNeM/i/+Ij43zm9 2wleLkY36ZDN1N/27o1mlGBSp4gMKypEoTQdLO6u3OvP0tHSVJ nPBYV34kISlne13NEifVYR5KNiLs3TLP5kvbxmstqWIRmVfFbI yciUcgzAMcQauW5DziMbsuMuJ0oH4F1G6PXt0o/+mwkE8Fhiww nIBJffkMTvhiy1G8/2SIvYux/NLsIh92M0cQOQL5USdVzDfgrD rHmxqajyklPCNnbdlUpPfhuyEcGrBMcFXuanq+i0UdKFwx1JwE DI6R1q3WM1zOptAfDeIkcMj5l2f9HBMHKfaWu2uJYNdaLhSZ3y kbDyU15wF9i9xeWPABc6KXW2B4Nh37QIFvHmfRJErNc6ZyMrad EZBm8hJ3oog1g== Cc: "pcp@ietf.org" Subject: Re: [pcp] Loosely/tightly coupled auth/authz 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, 31 Oct 2012 09:37:01 -0000 > Some comments inline... >=20 > On 10/29/12 3:44 AM, "Alper Yegin" wrote: >=20 >>>>> My point is basically that the NAT is authoritative for a = mapping's >>>>> lifetime. Practically, this authority can not be moved to a AAA = server. >>>>=20 >>>> This is where I fail to understand. What I'm saying is, there may >>>> exist at least one scenario where the mapping lifetime is centrally >>>> controlled by the AAA. >>>=20 >>> What is this scenario? >>>=20 >>=20 >> Here's the scenario: >>=20 >> Consider a mobile/wireless network (WiFi hotspots, 3G/4G, etc.). >> Mobile host's network access session is AAA'ed by a AAA server and >> granted lifetime =3D=3D A. >> If and when the host uses PCP to set up NAT state or firewall state, >> it'll be AAA'ed by the same AAA server and granted lifetime =3D=3D = remainder >> of A. >=20 > [Reinaldo] >=20 > It seems we are going off track. The authentication work was meant to = meet > certain set of requirements. >=20 > What would be the leanest solution that meets those requirements? = Extra > functionality, albeit nice, needs further discussion. >=20 > Having said that, certainly we do not want mappings to survive (much) > longer than the Mobile > session. There is some text on PCP-base about it. >=20 > "To help clean PCP state, it is RECOMMENDED that devices which combine > IP address assignment (e.g., DHCP server) with the PCP server > function (e.g., such as a residential CPE) flush PCP state when an = IP > address is allocated to a new host, because the new host will be > unable perform the functions described in the previous paragaph > because the new host does not know the previous host's Mapping Nonce > value. It is good hygiene to also flush TCP and UDP flow state of > NAT or fireall functions, although out of scope of this document." >=20 >=20 > In other words, when detecting that a Mobile host disconnects the = address > allocation function can flush state by some other means. >=20 You are talking about something else. Cleaning state when the MS leaves. I'm talking about setting the lifetime of state when it's created.=20 I'm saying the network operator can assign lifetime to various states = such that they are all aligned with the "mobile host's network access = session". This is how we typically design the cellular architectures (3GPP, 3GPP2, = WiMAX, etc.) FYI. >=20 >>=20 >> Network access session, >> PCP session (I mean, the state associated with PCP, which is PCP SA, >> etc.), and >> the state created by the PCP (the NAT mapping, firewall rules) are = all >> synchronized. >>=20 >> They all expire at the same time. >>=20 >> This is typically how sessions are managed in mobile/wireless network >> architectures and deployments. >=20 >=20 > [Reinaldo] >=20 > Today CGN is heavily deployed in wireless networks and in general NAT = or > Firewall mappings survive after user disconnects. They go away due to = idle > Timeouts.=20 >=20 > There are a few CGN implementations with subscriber awareness that on > receiving a Radius=20 > Stop flush all NAT state. >=20 > But I'm personally not aware of any implementation where the NAT = mapping > time is the=20 > remainder of the Mobile Host session time. >=20 Because, none of those "legacy" solutions involve host/subscriber = authentication with AAA and explicit signaling with the host to maintain = state. So, I'd not be surprised if we are deviating from todays NAT state = management. After all, this whole PCP thing is for that=85.. Alper >=20 >>=20 >>=20 >>>> You seem to be saying this is impossible, there's no such a case. >>>=20 >>> The important word is "practially". Given the current state of NAT >>> affairs, I don't see how it would be practically possible to move >>> authority over a NAT mapping's lifetime to a AAA server. >>>=20 >>>> Btw, when the PCP signal creates state on the PCP server, what = value >>>> of lifetime is assigned to that state? I think you'd say the PCP = server >>>> decides on its own. >>>=20 >>> Yes and no. The PCP server is most probably operated by the same = entity >>> that operates the NAT. So their configurations can be expected to = agree >>> with each other. But if their is disagreement, the NAT has the final = say. >>>=20 >>>> A general PCP question: Should the PCP server indicate the = associated >>>> lifetime to the PCP client at the time of state creation via PCP? >>>=20 >>> Unless I'm misunderstanding, it already does. A successful MAP = response >>> contains the created mapping's lifetime. >>>=20 >>>> And if so, should the PCP server notify the PCP client when the >>>> lifetime changes (due to some of those external factors you listed >>>> above)? >>>> Without this knowledge, the PCP client cannot properly "maintain" = the >>>> state on the PCP server. >>>=20 >>> Everything about NAT is a hack. >>>=20 >>=20 >> :-) >>=20 >> I'm seeing PCP bringing some determinism to this. PCP is setting up = state >> on the NAT/Firewall, learning the granted lifetime, and even getting >> notified when that lifetime changes, etc. This is becoming more >> managed/manageable. >>=20 >> Alper >>=20 >>=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 >=20 From alper.yegin@yegin.org Wed Oct 31 03:19: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 9D1CC21F8789 for ; Wed, 31 Oct 2012 03:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.278 X-Spam-Level: X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 KJAAmDWIG5oY for ; Wed, 31 Oct 2012 03:19:58 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3F621F877F for ; Wed, 31 Oct 2012 03:19:58 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Lfkck-1T1G4Q2wWY-00pFx6; Wed, 31 Oct 2012 06:19:48 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_BFEF941F-5AA7-4C58-9D9D-09F993866358" From: Alper Yegin In-Reply-To: <50854A6D.5060801@toshiba.co.jp> Date: Wed, 31 Oct 2012 12:19:30 +0200 Message-Id: <0AE0D2CA-70BE-40C0-B269-417E453DD9D8@yegin.org> References: <20121019080550.15043.98554.idtracker@ietfa.amsl.com> <50854A6D.5060801@toshiba.co.jp> To: Yoshihiro Ohba X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:a4pTWcOCgCy6vxkdk0bT86myJXSaVJ3meVElrTFzNs8 33mcJPG0O02qj8vtTGl2kWEtRWjgYD4F0TSyAo0esTbtopfY80 e07P+BYcoRA2R4aGwVFPqqfWBIp9AMAByaXjAv2qXPOT391JVV tMtebCvM/lAWPODvk+vNTqe87l71ibrzOx8BEZDRbDp5VKEMyE zZoTmRXf1ZObEqbo0Y4N9P6Izi3kmvPT4EZHGdp2Xg9E6NHzkk zBYsrte0dgzmRJpQ0s8bcGHhyErwZ5H8Pd/V0yF5UgLEVL1W5R TZmWvELs8V/jMi+dvE2Yz6cyafYP7NqeVVvhbhAdK5evjBwhCi r3yT5qUqJ68qPm28ih0/mfmAZso8TdhjtetkyaJ3ihDDQ6iQSP msgepTgh/Drtw== Cc: pcp@ietf.org Subject: Re: [pcp] I-D Action: draft-ietf-pcp-authentication-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, 31 Oct 2012 10:19:59 -0000 --Apple-Mail=_BFEF941F-5AA7-4C58-9D9D-09F993866358 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Furthermore: In pricinpal, the PANA message can be transported either through the PCP port or through an different port. The latter option has been abandoned by the working group since it may impose unnecessary management burdens and cause issues in securely binding the PCP session to the PANA session initiation. I think this last part is based on a misunderstanding. I had challenged = that issue on the reflector, but didn't see anyone coming forward with = an explanation. Use of same or different port adds no value to "crypto = binding". This may not affect the ongoing discussions, but I'd rather = not leave a trail of misconceptions in published documents. There are some functions of PANA which are not necessary for PCP. For example, it would not be necessary for these servers to support IP Address Reconfiguration and re-authentication. Well, the re-auth discussion is still open. We shall not add that under = the clause "are not necessary". Thanks. Alper On Oct 22, 2012, at 4:30 PM, Yoshihiro Ohba wrote: > I have some comments in Section 4 of pcp-authenication-01. >=20 > [1] The following statement is incorrect because both PANA approaches = use > PCP port number to indicate that the PANA session was being used for = PCP > authentication. The sentence should be removed. >=20 > "For the first approach [I-D.ohba-pcp-pana-encap], we would define an = AVP for > PANA to indicate that the PANA session was being used for PCP > authentication, not for network access purposes. " >=20 > [2] I fail to see in the following sentence what the technical = problem > with the existence of overlapping fields is. >=20 > "The first approach introduces little change on PANA. Howerer, there > are criticisms about the existence of overlapping fields on the PANA > and PCP headers that need to be check for consistency." >=20 > [3] The 2nd sentence of the following text should be removed for the = same reason as commented in [1]. Also, depending on resolution of = comment [2], the 1st sentence may also need be removed. >=20 > "Compared with the first approach, the second approach does not have = this problem. However, addition work needs to be done to help an PCP = implementation to distinguish a PANA message from a PCP message." >=20 > Regards, > Yoshihiro Ohba >=20 > (2012/10/19 17:05), internet-drafts@ietf.org wrote: >> 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. >>=20 >> Title : Port Control Protocol (PCP) Authentication = Mechanism >> Author(s) : Margaret Wasserman >> Sam Hartman >> Dacheng Zhang >> Filename : draft-ietf-pcp-authentication-01.txt >> Pages : 19 >> Date : 2012-10-19 >>=20 >> Abstract: >> An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to >> flexibly manage the IP address and port mapping information on >> Network Address Translators (NATs) or firewalls, to facilitate >> communications with remote hosts. However, the un-controlled >> generation or deletion of IP address mappings on such network = devices >> may cause security risks and should be avoided. In some cases the >> client may need to prove that it is authorized to modify, create = or >> delete PCP mappings. This document proposes an in-band >> authentication mechanism for PCP that can be used in those cases. >> The Extensible Authentication Protocol (EAP) is used to perform >> authentication between PCP devices. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-pcp-authentication >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-pcp-authentication-01 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcp-authentication-01 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >>=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp --Apple-Mail=_BFEF941F-5AA7-4C58-9D9D-09F993866358 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii In pricinpal, the = PANA message can be transported either through the PCP port or through an different port. The latter option has been abandoned by the working group since it may impose unnecessary management burdens and cause issues in securely binding the PCP session to the PANA session initiation.

I think this last part is based on a = misunderstanding. I had challenged that issue on the reflector, but = didn't see anyone coming forward with an explanation. Use of same or = different port adds no value to "crypto binding". This may not affect = the ongoing discussions, but I'd rather not leave a trail of = misconceptions in published = documents.


There are some = functions of PANA which are not necessary for PCP. For example, it would not be necessary for these servers to support IP Address Reconfiguration and re-authentication.

Well, the re-auth discussion is still open. We shall not add that = under the clause "are not = necessary".

Thanks.

Alpe= r

I = have some comments in Section 4 of pcp-authenication-01.

[1] The = following statement is incorrect because both PANA approaches use
PCP = port number to indicate that the PANA session was being used for = PCP
authentication.  The sentence should be removed.

"For = the first approach [I-D.ohba-pcp-pana-encap], we would define an AVP = for
PANA to indicate that the PANA session was being used for = PCP
authentication, not for network access purposes. =  "

[2]  I fail to see in the following sentence what = the technical problem
with the existence of overlapping fields = is.

"The first approach introduces little change on PANA. =  Howerer, there
are criticisms about the existence of = overlapping fields on the PANA
and PCP headers that need to be check = for consistency."

[3] The 2nd sentence of the following text = should be removed for the same reason as commented in [1].  Also, = depending on resolution of comment [2], the 1st sentence may also need = be removed.

"Compared with the first approach, the second = approach does not have this problem. However, addition work needs to be = done to help an PCP implementation to distinguish a PANA message from a = PCP message."

Regards,
Yoshihiro Ohba

(2012/10/19 = 17:05), internet-drafts@ietf.org = wrote:
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) Authentication = Mechanism
Author(s) =       : Margaret = Wasserman
=             &n= bsp;           &nbs= p; Sam Hartman
=             &n= bsp;           &nbs= p; Dacheng Zhang
Filename =        : = draft-ietf-pcp-authentication-01.txt
= Pages =           : = 19
Date =            : = 2012-10-19

Abstract:
=    An IPv4 or IPv6 host can use the Port Control Protocol = (PCP) to
=    flexibly manage the IP address and port mapping = information on
=    Network Address Translators (NATs) or firewalls, to = facilitate
=    communications with remote hosts.  However, the = un-controlled
=    generation or deletion of IP address mappings on such = network devices
=    may cause security risks and should be avoided. =  In some cases the
=    client may need to prove that it is authorized to = modify, create or
=    delete PCP mappings.  This document proposes an = in-band
=    authentication mechanism for PCP that can be used in = those cases.
=    The Extensible Authentication Protocol (EAP) is used = to perform
=    authentication between PCP = devices.


The IETF = datatracker status page for this draft is:
ht= tps://datatracker.ietf.org/doc/draft-ietf-pcp-authentication

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

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


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

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


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

= --Apple-Mail=_BFEF941F-5AA7-4C58-9D9D-09F993866358-- From repenno@cisco.com Wed Oct 31 04:04:20 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 7889921F8716 for ; Wed, 31 Oct 2012 04:04:20 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwr6nGrESsAV for ; Wed, 31 Oct 2012 04:04:19 -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 71C0621F86FC for ; Wed, 31 Oct 2012 04:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6417; q=dns/txt; s=iport; t=1351681459; x=1352891059; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=V7Qjfs2TZEBqP2hiVEbjsPUUZ8e5AkC4K7hBYf4dD0c=; b=b0sMAzi74j2YEGQswD4O5IPWkmy26mrBux95waXoXl+0fksKZx6Qd3EK jcQ13pqQmodVC3OpFDBafX7KqYCnsUfXzPZiiRPUs3afafACba6clh50X ZcjqrD/f10FyS+nCsUyzmmOvmhZ6gi/sQ1rN0XhFb8NQnSZSrgxras5lk w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHwEkVCtJV2a/2dsb2JhbABEw22BCIIeAQEBAwEBAQEPARRGAQsSAQgYCksLJQIEDgUIEweHXgYLm2qgBpFSYQOXEI09gWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="137278932" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 31 Oct 2012 11:04:19 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9VB4Inj002796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 11:04:18 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 06:04:18 -0500 From: "Reinaldo Penno (repenno)" To: Alper Yegin Thread-Topic: [pcp] Loosely/tightly coupled auth/authz Thread-Index: AQHNsdyVtswI/+IU10qf3AgxfW2hspfIxRkAgAbMNACAAA4oAIAA1YWAgABojYCAAqkHAP//oseA Date: Wed, 31 Oct 2012 11:04:17 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06041342A7@xmb-rcd-x04.cisco.com> In-Reply-To: <8E0A6E89-26D0-4BBE-9D24-DC499211FAF7@yegin.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.84.141] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001 x-tm-as-result: No--54.189800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] Loosely/tightly coupled auth/authz 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, 31 Oct 2012 11:04:20 -0000 Hello, Inline... On 10/31/12 2:36 AM, "Alper Yegin" wrote: >> Some comments inline... >>=20 >> On 10/29/12 3:44 AM, "Alper Yegin" wrote: >>=20 >>>>>> My point is basically that the NAT is authoritative for a mapping's >>>>>> lifetime. Practically, this authority can not be moved to a AAA >>>>>>server. >>>>>=20 >>>>> This is where I fail to understand. What I'm saying is, there may >>>>> exist at least one scenario where the mapping lifetime is centrally >>>>> controlled by the AAA. >>>>=20 >>>> What is this scenario? >>>>=20 >>>=20 >>> Here's the scenario: >>>=20 >>> Consider a mobile/wireless network (WiFi hotspots, 3G/4G, etc.). >>> Mobile host's network access session is AAA'ed by a AAA server and >>> granted lifetime =3D=3D A. >>> If and when the host uses PCP to set up NAT state or firewall state, >>> it'll be AAA'ed by the same AAA server and granted lifetime =3D=3D >>>remainder >>> of A. >>=20 >> [Reinaldo] >>=20 >> It seems we are going off track. The authentication work was meant to >>meet >> certain set of requirements. >>=20 >> What would be the leanest solution that meets those requirements? Extra >> functionality, albeit nice, needs further discussion. >>=20 >> Having said that, certainly we do not want mappings to survive (much) >> longer than the Mobile >> session. There is some text on PCP-base about it. >>=20 >> "To help clean PCP state, it is RECOMMENDED that devices which combine >> IP address assignment (e.g., DHCP server) with the PCP server >> function (e.g., such as a residential CPE) flush PCP state when an IP >> address is allocated to a new host, because the new host will be >> unable perform the functions described in the previous paragaph >> because the new host does not know the previous host's Mapping Nonce >> value. It is good hygiene to also flush TCP and UDP flow state of >> NAT or fireall functions, although out of scope of this document." >>=20 >>=20 >> In other words, when detecting that a Mobile host disconnects the >>address >> allocation function can flush state by some other means. >>=20 > >You are talking about something else. Cleaning state when the MS leaves. >I'm talking about setting the lifetime of state when it's created. [Reinaldo] I'm assuming you want to do that so there is no state when Mobile user disconnects. Otherwise could you explain what is the driver? >=20 >I'm saying the network operator can assign lifetime to various states >such that they are all aligned with the "mobile host's network access >session". >This is how we typically design the cellular architectures (3GPP, 3GPP2, >WiMAX, etc.) FYI. > >>=20 >>>=20 >>> Network access session, >>> PCP session (I mean, the state associated with PCP, which is PCP SA, >>> etc.), and >>> the state created by the PCP (the NAT mapping, firewall rules) are all >>> synchronized. >>>=20 >>> They all expire at the same time. >>>=20 >>> This is typically how sessions are managed in mobile/wireless network >>> architectures and deployments. >>=20 >>=20 >> [Reinaldo] >>=20 >> Today CGN is heavily deployed in wireless networks and in general NAT or >> Firewall mappings survive after user disconnects. They go away due to >>idle >> Timeouts.=20 >>=20 >> There are a few CGN implementations with subscriber awareness that on >> receiving a Radius >> Stop flush all NAT state. >>=20 >> But I'm personally not aware of any implementation where the NAT mapping >> time is the=20 >> remainder of the Mobile Host session time. >>=20 > >Because, none of those "legacy" solutions involve host/subscriber >authentication with AAA and explicit signaling with the host to maintain >state. >So, I'd not be surprised if we are deviating from todays NAT state >management. After all, this whole PCP thing is for that=8A.. [Reinaldo] Are you suggesting that 'legacy' mappings will go away and only authenticated PCP mappings will be used? I would say that a FW or NAT will have regular outbound mappings, port forwarding, non-authenticated PCP PEER and MAP, authenticated PCP PEER and MAP. You can only control lifetime through AAA for the latter two. > >Alper > > > > > >>=20 >>>=20 >>>=20 >>>>> You seem to be saying this is impossible, there's no such a case. >>>>=20 >>>> The important word is "practially". Given the current state of NAT >>>> affairs, I don't see how it would be practically possible to move >>>> authority over a NAT mapping's lifetime to a AAA server. >>>>=20 >>>>> Btw, when the PCP signal creates state on the PCP server, what value >>>>> of lifetime is assigned to that state? I think you'd say the PCP >>>>>server >>>>> decides on its own. >>>>=20 >>>> Yes and no. The PCP server is most probably operated by the same >>>>entity >>>> that operates the NAT. So their configurations can be expected to >>>>agree >>>> with each other. But if their is disagreement, the NAT has the final >>>>say. >>>>=20 >>>>> A general PCP question: Should the PCP server indicate the associated >>>>> lifetime to the PCP client at the time of state creation via PCP? >>>>=20 >>>> Unless I'm misunderstanding, it already does. A successful MAP >>>>response >>>> contains the created mapping's lifetime. >>>>=20 >>>>> And if so, should the PCP server notify the PCP client when the >>>>> lifetime changes (due to some of those external factors you listed >>>>> above)? >>>>> Without this knowledge, the PCP client cannot properly "maintain" the >>>>> state on the PCP server. >>>>=20 >>>> Everything about NAT is a hack. >>>>=20 >>>=20 >>> :-) >>>=20 >>> I'm seeing PCP bringing some determinism to this. PCP is setting up >>>state >>> on the NAT/Firewall, learning the granted lifetime, and even getting >>> notified when that lifetime changes, etc. This is becoming more >>> managed/manageable. >>>=20 >>> Alper >>>=20 >>>=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 >>=20 > From dwing@cisco.com Wed Oct 31 11:07:16 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 8292C21F8887 for ; Wed, 31 Oct 2012 11:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.509 X-Spam-Level: X-Spam-Status: No, score=-110.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 nRTewsF6hHsE for ; Wed, 31 Oct 2012 11:07:16 -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 E266621F8858 for ; Wed, 31 Oct 2012 11:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3558; q=dns/txt; s=iport; t=1351706835; x=1352916435; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=EVp9D2s9thlNFuCPBX7ydgo+8FHg2tB2dMfQKxULBjU=; b=JhyGbSgneJ+ZRwaRjlUsg6FOi25M/AUZ2Z4tYDk2bHHt7PHu7ymvx+AA CpARegAQlGgIh928kdij3P3mJnO5IwAO14sTRjdibBilD+zdGXhVhs4+H 4LbGgNRbIbgQQtsJl7It5/2vZwSdN3n9cPE31E4+BvMeElzUiKtoHJYiU 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIRnkVCrRDoH/2dsb2JhbAA7CYYXvUGBCIIeAQEBAwEIAggBEE8FBwcBAwIJEQQBAQMCIwMCAhktCQgCBAESCwULB4deBQybao0pknSBIIpYEYUXgRMDiFqFFogGgRqNPYFrgw8 X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="59701475" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 31 Oct 2012 18:07:15 +0000 Received: from DWINGWS01 ([10.156.0.16]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9VI7F3e015654; Wed, 31 Oct 2012 18:07:15 GMT From: "Dan Wing" To: "'Qiong'" , References: In-Reply-To: Date: Wed, 31 Oct 2012 11:07:15 -0700 Message-ID: <0c8701cdb792$8ee8c4a0$acba4de0$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNPFg3hnot8iaQn7dMg74vbEf4q55TQ7s8A Content-Language: en-us Subject: Re: [pcp] Fw:I-D Action: New Version Notification for draft-tsou-pcp-natcoord-08.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, 31 Oct 2012 18:07:16 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Qiong > Sent: Wednesday, October 31, 2012 12:41 AM > To: pcp@ietf.org > Subject: [pcp] Fw:I-D Action: New Version Notification for draft-tsou- > pcp-natcoord-08.txt > > Dear all, > > We have updated the pcp-natcoord draft according to the comments from > the wg before. The major changes in this version is as follows: > > 1) Update the PORT_SET_Nonce field and be consistent with the latest > pcp-base draft > 2) Encode the port-set in contiguous port mask, and remove the > Cryptographically_Random_Port_Range option > > 3) Add coexistence with MAP. > 4) Add security consideration and failover consideration > > > Your further comments are appreciated. draft-tsou-pcp-natcoord-08 says: Using individual MAP requests to reserve all individual ports of a given port set can not achieve this goal because an additional indication is needed to instruct the PCP-controlled device to not enforce a NAT for packets matching these ports. A candidate solution is to define a new Option to request for this feature be enforced by the PCP-controlled device. The sentences above are not accurate. A PCP-controlled device that does not NAT will simply return the same IP address and port for the externally-mapped IP address, as described in draft-ietf-pcp-base-28: Mapping, Port Mapping, Port Forwarding: A NAT mapping creates a relationship between an internal IP address, protocol, and port, and an external IP address, protocol, and port. More specifically, it creates a translation rule where packets destined to the external IP and port are translated to the internal IP address, protocol, and port, and vice versa. In the case of a pure firewall, the "Mapping" is the identity function, translating an internal IP address, protocol, and port number to the same external IP address, protocol, and port number. Firewall filtering, applied in addition to that identity mapping function, is separate from the mapping itself. draft-tsou-pcp-natcoord-08 says: Another issue, is when no NAT is enforced in the PCP-controlled device but only a Port Range Router (PRR) function, the request has not to indicate the internal ports. But then how does pcp-natcoord ensure the subscriber's equipment and the service provider equipment have the same configuration of the subscriber's port number range? Seems it doesn't ensure the configurations are the same; something else does? The draft needs to consider what happens when the port-sets overlap or are supersets of each other. Especially how the Mapping Nonce is handled in that situation. draft-tsou-pcp-natcoord-08 says: The Client MUST use a different Mapping Nonce for different MAP_PORT_SET requests. This is a MUST, which means there must be something that breaks if it violates that requirement. What breaks? -d > BTW, you can also find the opensource project in sourceforge: > http://sourceforge.net/projects/pcpportsetdemo/ > > > Thanks a lot! > > Best wishes > > -- > ============================================== > Qiong Sun > China Telecom Beijing Research Institude > > > Open source code: > lightweight 4over6: http://sourceforge.net/projects/laft6/ > PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ > =============================================== > >